OpenSearch supports a variety of algorithms for document embedding (the process of converting text to vectors) and search (the process of finding the nearest neighbors). These are typically categorized into **Vector Engines** (the storage and retrieval backends) and **Algorithm Types** (the logic used to traverse the data).
### 1. Vector Search Engines (Backends)
OpenSearch uses two primary "engines" to handle vector data. The choice between them dictates what algorithms you can use:
* **Lucene:** The default, native OpenSearch engine. It is tightly integrated, meaning it excels at **hybrid search** (filtering by metadata like `date` or `category` *while* performing a vector search).
* **Faiss (Facebook AI Similarity Search):** A high-performance library built for scale. It offers more sophisticated compression algorithms and is generally faster for very large datasets, though it can be slightly less flexible with complex metadata filtering compared to Lucene.
---
### 2. Approximate Nearest Neighbor (ANN) Algorithms
Since searching through millions of vectors exactly (Exact k-NN) is computationally expensive, OpenSearch uses ANN algorithms to provide fast, near-accurate results.
* **HNSW (Hierarchical Navigable Small World):**
* **How it works:** It builds a multi-layered graph where the top layers are "expressways" for long-distance jumps and the bottom layer contains all data points for local connections.
* **Best for:** General use cases requiring high performance and low latency. It is the most common default.
* **IVF (Inverted File Index):**
* **How it works:** It partitions the vector space into clusters (Voronoi cells). At search time, it only scans the clusters closest to the query vector.
* **Best for:** Extremely large datasets where you need to balance memory consumption and search speed by only searching a subset of the data.
---
### 3. Compression and Optimization Algorithms (Faiss Specific)
If you are using the **Faiss** engine, you can apply compression to fit massive vector indexes into RAM:
* **PQ (Product Quantization):** Breaks vectors into small chunks and compresses each chunk. This dramatically reduces memory footprint at the cost of a slight drop in search precision.
* **SQ (Scalar Quantization):** Converts high-precision floating-point numbers into 8-bit integers. This is highly effective for reducing memory usage while maintaining a high level of search accuracy.
---
### 4. Similarity Metrics (Distance Functions)
The "algorithm" for calculating how similar two vectors are depends on your distance metric, specified via `space_type`:
| Metric | Best For |
| --- | --- |
| **L2 (Euclidean)** | General-purpose spatial similarity. |
| **Cosine Similarity** | Semantic text similarity (especially when document length varies). |
| **Inner Product** | Models that are already normalized (often equivalent to Cosine similarity). |
---
### 5. Integration Strategies for Embeddings
To get your data *into* the vector space, you must choose an embedding model strategy:
* **External Embedding (Client-side):** You use a service like OpenAI, Cohere, or an internal Python script to convert text to vectors *before* sending it to OpenSearch.
* **ML Commons (In-cluster):** OpenSearch hosts the model directly. This is the "Gold Standard" because it creates an **Ingest Pipeline** where you send raw text, and OpenSearch automatically uses an internal model (e.g., BERT, RoBERTa) to generate the embedding upon arrival.
---
### Summary Checklist for Choosing
1. **Need metadata filtering?** Use the **Lucene** engine with **HNSW**.
2. **Need maximum scale/memory efficiency?** Use the **Faiss** engine with **IVF + PQ/SQ**.
3. **Accuracy vs. Latency?** Adjust `ef_search` (the number of candidates explored). Higher values increase accuracy but increase search time.
Would you like to see how to configure an Ingest Pipeline using ML Commons to automate this embedding process?
