51 Document Stores

Coherence RAG supports document ingestion and vector search through one or more document stores. Each document store can be configured independently, and can use different embedding model, index type, document parser, and chunking strategy.

Document store represents a document ingestion boundary, but not necessarily a vector search boundary. In other words, documents are always ingested into a specific store, but vector search can be performed both within a single store, and in parallel, across all the stores.

This allows users to create individual stores for different documentation sets, and to limit the scope of the search to a specific store, when the context of the search is known, while still allowing search across all index content when the necessary context is missing. For example, users could index documentation for each individual product (or a project) into a separate document store, allowing them to significantly narrow down the size of the vector space that needs to be searched when they are interested in a specific product, while still being able to search across all the stores to answer questions that are not product-specific.

Security Prerequisites

Configure the RAG service’s authenticated identity, model locations and administrative policy before startup or ingestion. Model download and model/configuration administration are separate permissions from document search. Supply credentials through the supported provider configuration and make external downloads an explicit deployment decision.

For the complete configuration and policy, see Securing Coherence RAG, RAG Configuration and Model Download Policy in Securing Oracle Coherence.

• Creating a Document Store
  
• Configuring a Document Store
  
• Embedding Model
  
• Vector Indexing
  
• Hierarchical Navigable Small World (HNSW)
  
• Binary Quantization
  
• Simple Index
  
• Disabling Vector Index
  

Creating a Document Store

A document store is created automatically, based on the path of the REST request, when the set of documents that need to be ingested is submitted to it.

By default, the store will inherit global configuration settings. In most cases this is fine, but because some of the settings are immutable after the ingestion (embedding model, for example) it may be necessary to configure the store before submitting documents for ingestion.

Configuring a Document Store

To configure the store explicitly, you can use Config REST API:

PUT /api/kb/config/<storeName>

{
  "chunkOverlap":        150,
  "chunkSize":           1500,
  "embeddingModel":      "sentence-transformers/all-mpnet-base-v2",
  "index":               {
    "type": "hnsw"
  },
  "normalizeEmbeddings": true,
  "vectorStoreType":     "OracleDb"
}

In the example earlier in this topic, the store is configured to split documents into chunks of no more than 1,500 characters (with a 150 character overlap), embed them using sentence-transformers/all-mpnet-base-v2 model, normalize the embeddings, create HNSW index for them, and write all embedded document chunks to an external Oracle DB 23ai instance.

To see the current store configuration you can make a GET request to the same endpoint:

GET /api/kb/config/<storeName>

Embedding Model

The embedding model converts documents into vector representations for efficient retrieval, and is what all operations within a document store revolve around. Users can choose between local and remote models depending on their performance, cost, and privacy requirements.

Any ONNX-compatible model available on Hugging Face can be specified, and will be automatically downloaded to each Coherence RAG cluster member, and run locally using ONNX Runtime.

The syntax used to specify the model is <provider>/<modelName>. In the configuration example above, sentence-transformers is the provider, while the all-mpnet-base-v2 is the model name. Not coincidentally, this matches exactly what you get when you click on the 'Copy model name to clipboard' link next to the model name on Hugging Face.

The remote models use the same syntax, but in this case the provider is the name of the cloud provider hosting the model, such as OCI or OpenAI , while the model name is the actual name of the model as defined by the provider, such as cohere.embed-multilingual-v3.0 for OCI, or text-embedding-3-small for OpenAI.

Coherence RAG also supports Ollama, which provides somewhat a hybrid approach: a self-hosted remote model. To use the Ollama hosted model, use ollama as the provider name, and the actual name of the model hosted in Ollama as the model name.

Vector Indexing

Indexing structures optimize search efficiency, enabling fast lookup of relevant documents. Coherence RAG supports several vector indexing options, with different performance characteristics and resource cost.

Hierarchical Navigable Small World (HNSW)

Hierarchical Navigable Small World (HNSW) indexing is a graph-based approach that significantly enhances search efficiency in high-dimensional vector spaces. By structuring data in a navigable small-world graph, HNSW enables rapid nearest-neighbor searches, making it a preferred choice for large-scale vector retrieval tasks.

To configure document store to use HNSW index, post a request to the `/api/kb/<storeName>/index` endpoint and specify `HNSW` as the value of the `type` property:

 POST /api/kb/<storeName>/index

 {
    "type": "HNSW",
    "spaceName": "COSINE",
    "efConstruction": 200,
    "efSearch": 50,
    "m": 16
 }

Technically, all properties other than `type` in the payload earlier in this topic can be omitted, as they use the default values.

Binary Quantization

Binary quantization reduces the memory footprint of stored vectors by converting floating-point embeddings into compact binary representations. This approach maintains retrieval accuracy while significantly improving storage efficiency, making it suitable for resource-constrained environments and large-scale deployments.

To configure document store to use binary quantization, post a request to the /api/kb/<storeName>/index endpoint and specify BINARY as the value of the type property:

 POST /api/kb/<storeName>/index

 {
    "type": "BINARY",
    "oversamplingFactor": 3
 }

The oversamplingFactor property in the payload earlier in this topic can be omitted, as it uses a default value. Its main purpose is to show you how you can override the default.

Simple Index

Simple index is a standard Coherence index that lets you keep deserialized vectors in memory at all times. It eliminates the need for deserialization of vectors when performing brute-force searches across the cluster, thus improving performance and reducing GC activity, but it doesn't really optimize the search itself the way HNSW and BINARY indices do.

To configure document store to use binary quantization, post a request to the /api/kb/<storeName>/index endpoint and specify SIMPLE as the value of the type property:

 POST /api/kb/<storeName>/index

 {
    "type": "SIMPLE"
 }

Disabling Vector Index

To disable vector index for a store, post a request to the /api/kb/<storeName>/index endpoint and specify NONE as the value of the type property:

 POST /api/kb/<storeName>/index

 {
    "type": "NONE"
 }