OpenSearch Integration

The URL of the Amazon OpenSearch Service instance to connect to

The AWS access key ID for the Amazon OpenSearch Service

The AWS secret access key for the Amazon OpenSearch Service

The name of the index in the Amazon OpenSearch Service where the data will be stored

When set to true, the integration will automatically create the index if it does not exist in the Amazon OpenSearch Service instance

The AWS region where the Amazon OpenSearch Service instance is located

The AWS service name for the Amazon OpenSearch Service

When set to true, the integration will use SSL to connect to the Amazon OpenSearch Service instance

When set to true, the integration will verify SSL certificates when connecting to the Amazon OpenSearch Service instance

When enabled, the integration will use AWS4 authentication to connect to the Amazon OpenSearch Service instance.

Note: If you are connecting to an OpenSearch Service instance that is not hosted on AWS, set this to false. In this case, AWS credentials are not required and will be ignored. You can provide dummy values for awsAccessKeyId and awsSecretAccessKey.

Choose the embeddings provider to use for generating embeddings

Configure the parameters for the LangChain embedding class. Key points to consider:

1. Typically, you only need to specify the model name. For example, for OpenAI, set the model name as {"model": "text-embedding-3-small"}.

2. It's crucial to ensure that the vector size of your embeddings matches the size of embeddings in the database.

3. Always specify the model in the following format {"model": "your-embedding-model-name"}

4. Here are some examples of embedding models names:

   • OpenAI: {text-embedding-3-small, text-embedding-3-large, etc.
   • Cohere: embed-english-v3.0, embed-multilingual-light-v3.0, etc.

5. For more details about other parameters, refer to the LangChain documentation.

Value of the API KEY for the embeddings provider (if required).

For example for OpenAI it is OPENAI_API_KEY, for Cohere it is COHERE_API_KEY)

This array specifies the dataset fields to be selected and stored in the vector store. Only the fields listed here will be included in the vector store.

For instance, when using the Website Content Crawler, you might choose to include fields such as text, url, and metadata.title in the vector store.

A list of dataset fields which should be selected from the dataset and stored as metadata in the vector stores.

For example, when using the Website Content Crawler, you might want to store url in metadata. In this case, use metadataDatasetFields parameter as follows {"url": "url"}

This object allows you to store custom metadata for every item in the vector store.

For example, if you want to store the domain as metadata, use the metadataObject like this: {"domain": "apify.com"}.

Dataset ID (when running standalone without integration)

When set to true, this setting enables incremental updates for objects in the database by comparing the changes (deltas) between the crawled dataset items and the existing objects, uniquely identified by the datasetKeysToItemId field.

The integration will only add new objects and update those that have changed, reducing unnecessary updates. The datasetFields, metadataDatasetFields, and metadataObject fields are used to determine the changes.

This array contains fields that are used to uniquely identify dataset items, which helps to handle content changes across different runs.

For instance, in a web content crawling scenario, the url field could serve as a unique identifier for each item.

When set to true, delete objects from the database that have not been crawled for a specified period.

This setting allows the integration to manage the deletion of objects from the database that have not been crawled for a specified period. It is typically used in subsequent runs after the initial crawl.

When the value is greater than 0, the integration checks if objects have been seen within the last X days (determined by the expiration period). If the objects are expired, they are deleted from the database. The specific value for deletedExpiredObjectsDays depends on your use case and how frequently you crawl data.

For example, if you crawl data daily, you can set deletedExpiredObjectsDays to 7 days. If you crawl data weekly, you can set deletedExpiredObjectsDays to 30 days.

When set to true, the text will be divided into smaller chunks based on the settings provided below. Proper chunking helps optimize retrieval and ensures accurate and efficient responses.

Defines the maximum number of characters in each text chunk. Choosing the right size balances between detailed context and system performance. Optimal sizes ensure high relevancy and minimal response time.

Specifies the number of overlapping characters between consecutive text chunks. Adjusting this helps maintain context across chunks, which is crucial for accuracy in retrieval-augmented generation systems.