Skip to main content
SAP HANA Cloud Vector Engine is a vector store fully integrated into the SAP HANA Cloud database.

Setup

Install the langchain-hana external integration package, as well as the other packages used throughout this notebook.

Credentials

Ensure your SAP HANA instance is running. Load your credentials from environment variables and create a connection:
Learn more about SAP HANA in What is SAP HANA?.

Initialization

To initialize a HanaDB vector store, you need a database connection and an embedding instance. SAP HANA Cloud Vector Engine supports both external and internal embeddings.
  • Using External Embeddings

  • Using Internal Embeddings

Alternatively, you can compute embeddings directly in SAP HANA using its native VECTOR_EMBEDDING() function. To enable this, create an instance of HanaInternalEmbeddings with your internal model ID and pass it to HanaDB. Note that the HanaInternalEmbeddings instance is specifically designed for use with HanaDB and is not intended for use with other vector store implementations. For more information about internal embedding, see the SAP HANA VECTOR_EMBEDDING Function.
Caution: Ensure NLP is enabled in your SAP HANA Cloud instance.
Once you have your connection and embedding instance, create the vector store by passing them to HanaDB along with a table name for storing vectors:

Example

Load the sample document “state_of_the_union.txt” and create chunks from it.
Add the loaded document chunks to the table. For this example, we delete any previous content from the table which might exist from previous runs.
Perform a query to get the two best-matching document chunks from the ones that were added in the previous step. By default “Cosine Similarity” is used for the search.
Query the same content with “Euclidian Distance”. The results shoud be the same as with “Cosine Similarity”.

Maximal Marginal Relevance Search (MMR)

Maximal marginal relevance optimizes for similarity to query AND diversity among selected documents. The first 20 (fetch_k) items will be retrieved from the DB. The MMR algorithm will then find the best 2 (k) matches.

Creating an HNSW Vector Index

A vector index can significantly speed up top-k nearest neighbor queries for vectors. Users can create a Hierarchical Navigable Small World (HNSW) vector index using the create_hnsw_index function. For more information about creating an index at the database level, please refer to the official documentation.
Key Points:
  • Similarity Function: The similarity function for the index is cosine similarity by default. If you want to use a different similarity function (e.g., L2 distance), you need to specify it when initializing the HanaDB instance.
  • Default Parameters: In the create_hnsw_index function, if the user does not provide custom values for parameters like m, ef_construction, or ef_search, the default values (e.g., m=64, ef_construction=128, ef_search=200) will be used automatically. These values ensure the index is created with reasonable performance without requiring user intervention.

Basic Vectorstore Operations

We can add simple text documents to the existing table.
Add documents with metadata.
Query documents with specific metadata.
Delete documents with specific metadata.

Advanced filtering

In addition to the basic value-based filtering capabilities, it is possible to use more advanced filtering. The table below shows the available filter operators.
Filtering with $ne, $gt, $gte, $lt, $lte
Filtering with $between, $in, $nin
Text filtering with $like
Text filtering with $contains
Combined filtering with $and, $or

Using a VectorStore as a retriever in chains for retrieval augmented generation (RAG)

Define the prompt.
Create the ConversationalRetrievalChain, which handles the chat history and the retrieval of similar document chunks to be added to the prompt.
Ask the first question (and verify how many text chunks have been used).
Examine the used chunks of the chain in detail. Check if the best ranked chunk contains info about “Mexico and Guatemala” as mentioned in the question.
Ask another question on the same conversational chain. The answer should relate to the previous answer given.

Standard tables vs. “custom” tables with vector data

As default behaviour, the table for the embeddings is created with 3 columns:
  • A column VEC_TEXT, which contains the text of the Document
  • A column VEC_META, which contains the metadata of the Document
  • A column VEC_VECTOR, which contains the embeddings-vector of the Document’s text
Show the columns in table “LANGCHAIN_DEMO_NEW_TABLE”
Show the value of the inserted document in the three columns
Custom tables must have at least three columns that match the semantics of a standard table
  • A column with type NCLOB or NVARCHAR for the text/context of the embeddings
  • A column with type NCLOB or NVARCHAR for the metadata
  • A column with type REAL_VECTOR for the embedding vector
The table can contain additional columns. When new Documents are inserted into the table, these additional columns must allow NULL values.
Add another document and perform a similarity search on the custom table.

Filter Performance Optimization with Custom Columns

To allow flexible metadata values, all metadata is stored as JSON in the metadata column by default. If some of the used metadata keys and value types are known, they can be stored in additional columns instead by creating the target table with the key names as column names and passing them to the HanaDB constructor via the specific_metadata_columns list. Metadata keys that match those values are copied into the special column during insert. Filters use the special columns instead of the metadata JSON column for keys in the specific_metadata_columns list.
The special columns are completely transparent to the rest of the langchain interface. Everything works as it did before, just more performant.