Vector Databases (FAISS, OpenSearch, Pinecone)
Vector Databases: FAISS, OpenSearch, and Pinecone
Learn how vector databases store, index, filter, and retrieve high-dimensional embeddings for semantic search, Retrieval-Augmented Generation, recommendation systems, image retrieval, duplicate detection, and other similarity-based applications.
Introduction
Traditional keyword search finds documents containing the words supplied by a user. This works well when the query and the relevant document use matching words, identifiers, or phrases. However, two texts may express similar meanings while using different vocabulary.
An embedding model converts text, images, audio, products, users, or other objects into numerical vectors. Semantically related objects are generally represented by vectors that are close to one another according to a selected similarity or distance measure.
A vector database or vector-search system stores these vectors together with identifiers, metadata, and source information. It uses specialized indexes to retrieve the vectors most similar to a query vector.
FAISS provides a high-performance library for building similarity-search indexes. OpenSearch combines vector retrieval with document search, filtering, and search-engine capabilities. Pinecone provides a managed vector-search platform with indexes, namespaces, records, and metadata filtering.
Learning Objectives
By the End of This Lesson
- Define a vector database
- Explain how embeddings support semantic search
- Distinguish vector search from keyword search
- Understand exact and approximate nearest-neighbor search
- Calculate cosine similarity, dot product, and Euclidean distance
- Understand top-k vector retrieval
- Explain embedding dimensionality
- Understand vector normalization
- Explain metadata and metadata filtering
- Understand namespaces and logical isolation
- Explain chunking for RAG ingestion
- Build a FAISS index
- Compare FAISS index strategies
- Create an OpenSearch vector index
- Run OpenSearch k-nearest-neighbor searches
- Create and query a Pinecone index
- Apply metadata filtering
- Understand hybrid lexical and vector retrieval
- Evaluate retrieval quality
- Apply production security and monitoring controls
Prerequisites
Recommended Knowledge
- Python programming
- NumPy arrays
- Basic linear algebra
- Vectors and matrices
- Natural Language Processing fundamentals
- Transformer models
- Text embeddings
- REST API fundamentals
- JSON documents
- Retrieval-Augmented Generation fundamentals
Packages Used in the Examples
- NumPy
- FAISS CPU
- sentence-transformers
- OpenSearch Python client
- Pinecone Python SDK
python -m pip install \
numpy \
faiss-cpu \
sentence-transformers \
opensearch-py \
pinecone
What Is a Vector?
A vector is an ordered list of numerical values. In Machine Learning, a vector can represent the learned characteristics of a sentence, document, image, product, customer, or another object.
| Term | Meaning |
|---|---|
| Vector | An ordered numerical representation |
| Dimension | The number of values contained in a vector |
| Embedding | A learned vector representation of an object |
| Vector Space | The multidimensional space containing the vectors |
| Query Vector | The embedding used to search the index |
| Neighbor | A stored vector close to the query under the selected measure |
What Is an Embedding?
An embedding is a dense numerical representation created by a trained model. Embeddings attempt to preserve useful relationships among objects in a vector space.
What Is a Vector Database?
A vector database stores embeddings and provides indexes and query operations optimized for similarity-based retrieval.
| Component | Purpose |
|---|---|
| Record ID | Uniquely identifies an indexed object or chunk |
| Vector | Stores the numerical embedding |
| Metadata | Stores searchable attributes and source context |
| Index | Organizes vectors for efficient retrieval |
| Similarity Metric | Defines how vector closeness is calculated |
| Filter | Restricts eligible records using metadata conditions |
| Namespace or Collection | Provides logical organization or isolation |
| Query Operation | Returns the nearest or highest-scoring records |
Keyword Search vs Vector Search
| Area | Keyword Search | Vector Search |
|---|---|---|
| Primary Match | Terms, tokens, and lexical patterns | Closeness between embeddings |
| Best For | Names, identifiers, exact phrases, and rare terms | Semantic similarity and paraphrased meaning |
| Input | Text query | Query embedding |
| Main Dependency | Tokenizer, analyzer, and lexical index | Embedding model, similarity measure, and vector index |
| Weakness | May miss semantically related text using different words | May miss exact identifiers or return semantically close but unsuitable content |
Nearest-Neighbor Search
Nearest-neighbor search finds stored vectors closest to a query vector according to a selected distance or similarity function.
Here, \(\mathbf{q}\) is the query vector, \(\mathbf{x}_i\) is an indexed vector, and \(d\) is the selected distance function.
Similarity and Distance Measures
| Measure | Interpretation |
|---|---|
| Cosine Similarity | Compares the direction of two vectors |
| Dot Product | Measures alignment and is influenced by vector magnitude |
| Euclidean Distance | Measures straight-line distance in vector space |
Vector Normalization
L2 normalization scales a non-zero vector to unit length.
For unit-normalized vectors, cosine similarity equals the dot product. This permits cosine-oriented retrieval using an inner-product index when normalization is applied consistently.
import numpy as np
def l2_normalize(
vectors
):
vectors = np.asarray(
vectors,
dtype=np.float32
)
norms = np.linalg.norm(
vectors,
axis=1,
keepdims=True
)
if np.any(
norms == 0
):
raise ValueError(
"Zero-length vectors cannot "
"be normalized safely."
)
return vectors / norms
Exact vs Approximate Search
Exact Search
- Evaluates every eligible vector
- Returns exact nearest neighbors under the selected measure
- Useful as a retrieval-quality baseline
- Cost grows with dataset size and vector dimension
Approximate Search
- Searches an optimized index structure
- Reduces query work
- Trades some recall for latency, memory, or throughput
- Requires index-specific configuration and evaluation
Common Vector Index Strategies
| Index Strategy | General Idea | Main Trade-Off |
|---|---|---|
| Flat | Compares the query with every vector | Exact results with increasing query cost |
| HNSW | Uses a navigable multilayer proximity graph | Fast retrieval with graph-memory and tuning requirements |
| IVF | Partitions vectors into clusters and searches selected partitions | Faster search with training and recall trade-offs |
| Product Quantization | Compresses vectors into compact representations | Lower memory use with approximation loss |
| IVF-PQ | Combines partitioning with compressed vector codes | Efficient large-scale search with additional accuracy trade-offs |
| Binary Index | Indexes binary representations | Requires a compatible encoding and distance measure |
Metadata and Filtering
Metadata describes an indexed object without forming part of the dense embedding. Metadata filters restrict the set of records eligible for similarity search.
{
"id": "document-42-chunk-3",
"vector": [
0.12,
-0.47,
0.81
],
"metadata": {
"document_id": "document-42",
"category": "technical-manual",
"language": "en",
"version": "3",
"access_group": "engineering"
}
}
Useful Metadata
- Source document identifier
- Chunk identifier
- Title or section
- Content category
- Language
- Document version
- Publication or effective date
- Tenant or business scope
- Access-control attributes
- Embedding-model version
Namespaces and Collections
Vector systems may organize records through indexes, collections, namespaces, shards, or other logical boundaries. These structures can support workload organization, lifecycle management, and retrieval isolation.
| Organization Strategy | Example Use |
|---|---|
| Separate Index | Different embedding dimensions or independent workloads |
| Namespace | Logical partition within a compatible index |
| Metadata Filter | Restrict records by category, version, tenant, or authorization |
| Document Collection | Group content sharing a lifecycle or schema |
Chunking for Vector Retrieval
Long documents are commonly divided into smaller chunks before embeddings are created. Chunking controls how much meaning and context each vector represents.
| Chunking Strategy | General Approach |
|---|---|
| Fixed Characters | Splits text by an approximate character count |
| Fixed Tokens | Splits using the embedding model's tokenizer |
| Sentence-Based | Preserves sentence boundaries |
| Paragraph-Based | Preserves paragraph structure |
| Section-Aware | Uses headings and document hierarchy |
| Semantic Chunking | Uses content changes to determine boundaries |
| Parent-Child Chunking | Retrieves small chunks while returning broader parent context |
Simple Overlapping Chunker
def create_overlapping_chunks(
text,
chunk_size,
overlap
):
if chunk_size <= 0:
raise ValueError(
"chunk_size must be positive."
)
if (
overlap < 0
or overlap >= chunk_size
):
raise ValueError(
"overlap must be greater than "
"or equal to zero and smaller "
"than chunk_size."
)
words = str(
text
).split()
step_size = (
chunk_size
-
overlap
)
chunks = []
for start_index in range(
0,
len(
words
),
step_size
):
chunk_words = words[
start_index:
start_index + chunk_size
]
if not chunk_words:
break
chunks.append(
" ".join(
chunk_words
)
)
if (
start_index
+
chunk_size
>=
len(
words
)
):
break
return chunks
Vector Ingestion Pipeline
Collect Authorized Content
Retrieve documents or records from approved sources and preserve their source identity.
Parse the Content
Extract text and approved structural information from the source format.
Clean and Normalize
Remove unsupported artifacts while preserving meaningful structure, context, and traceability.
Create Chunks
Divide content using a strategy appropriate for the document, embedding model, and retrieval objective.
Generate Embeddings
Use an approved and versioned embedding model.
Validate Records
Verify identifiers, dimensions, finite values, metadata, authorization, duplicates, and source references.
Index the Records
Store vectors and metadata in the selected vector-search system.
Record Lineage
Preserve content, parser, chunker, embedding, index, and pipeline versions.
Validate Embeddings Before Indexing
import numpy as np
def validate_embeddings(
embeddings,
expected_dimension
):
embeddings = np.asarray(
embeddings,
dtype=np.float32
)
if embeddings.ndim != 2:
raise ValueError(
"Embeddings must be a "
"two-dimensional array."
)
if embeddings.shape[
1
] != expected_dimension:
raise ValueError(
"Embedding dimension does "
"not match the index."
)
if not np.isfinite(
embeddings
).all():
raise ValueError(
"Embeddings contain non-finite values."
)
if embeddings.shape[
0
] == 0:
raise ValueError(
"At least one embedding is required."
)
return embeddings
Generate Text Embeddings
from sentence_transformers import SentenceTransformer
embedding_model_id = (
"sentence-transformers/"
"all-MiniLM-L6-v2"
)
embedding_model = SentenceTransformer(
embedding_model_id
)
documents = [
"MLOps automates and governs the Machine Learning lifecycle.",
"A feature store manages reusable features for training and inference.",
"Vector search retrieves objects using embedding similarity.",
"Model monitoring tracks production quality and operational behavior."
]
document_embeddings = (
embedding_model.encode(
documents,
convert_to_numpy=True,
normalize_embeddings=True,
show_progress_bar=False
)
.astype(
"float32"
)
)
print(
document_embeddings.shape
)
What Is FAISS?
FAISS is a similarity-search and clustering library for dense vectors. It provides multiple index structures and CPU and GPU implementations for supported workflows.
| FAISS Capability | Purpose |
|---|---|
| Flat Index | Provides exact similarity search |
| IVF Index | Provides partition-based approximate search |
| HNSW Index | Provides graph-based approximate retrieval |
| Product Quantization | Compresses indexed vector representations |
| Batch Search | Processes multiple query vectors together |
| GPU Indexes | Uses compatible accelerators for supported indexes |
Build an Exact FAISS Index
import faiss
import numpy as np
document_embeddings = np.asarray(
document_embeddings,
dtype=np.float32
)
dimension = document_embeddings.shape[
1
]
faiss_index = faiss.IndexFlatIP(
dimension
)
faiss_index.add(
document_embeddings
)
print(
{
"dimension": dimension,
"indexed_vectors": (
faiss_index.ntotal
)
}
)
Search the FAISS Index
query_text = (
"How can semantic similarity "
"be used to retrieve information?"
)
query_embedding = (
embedding_model.encode(
[
query_text
],
convert_to_numpy=True,
normalize_embeddings=True,
show_progress_bar=False
)
.astype(
"float32"
)
)
top_k = 3
scores, indices = faiss_index.search(
query_embedding,
top_k
)
results = []
for score, index_position in zip(
scores[
0
],
indices[
0
]
):
if index_position == -1:
continue
results.append(
{
"document": documents[
index_position
],
"score": float(
score
)
}
)
print(
results
)
Use Explicit IDs with FAISS
import faiss
import numpy as np
base_index = faiss.IndexFlatIP(
dimension
)
id_index = faiss.IndexIDMap2(
base_index
)
vector_ids = np.array(
[
101,
102,
103,
104
],
dtype=np.int64
)
id_index.add_with_ids(
document_embeddings,
vector_ids
)
scores, retrieved_ids = (
id_index.search(
query_embedding,
top_k
)
)
print(
retrieved_ids
)
Save and Load a FAISS Index
import faiss
from pathlib import Path
index_path = Path(
"artifacts/document_index.faiss"
)
index_path.parent.mkdir(
parents=True,
exist_ok=True
)
faiss.write_index(
id_index,
str(
index_path
)
)
loaded_index = faiss.read_index(
str(
index_path
)
)
print(
loaded_index.ntotal
)
Build a FAISS HNSW Index
import faiss
hnsw_neighbors = 32
hnsw_index = (
faiss.IndexHNSWFlat(
dimension,
hnsw_neighbors,
faiss.METRIC_INNER_PRODUCT
)
)
hnsw_index.hnsw.efConstruction = 100
hnsw_index.hnsw.efSearch = 64
hnsw_index.add(
document_embeddings
)
scores, indices = hnsw_index.search(
query_embedding,
top_k
)
Build a FAISS IVF Index
import faiss
number_of_partitions = 16
quantizer = faiss.IndexFlatIP(
dimension
)
ivf_index = faiss.IndexIVFFlat(
quantizer,
dimension,
number_of_partitions,
faiss.METRIC_INNER_PRODUCT
)
if document_embeddings.shape[
0
] < number_of_partitions:
raise ValueError(
"More representative training "
"vectors are required for this "
"IVF configuration."
)
ivf_index.train(
document_embeddings
)
ivf_index.add(
document_embeddings
)
ivf_index.nprobe = 4
scores, indices = ivf_index.search(
query_embedding,
top_k
)
Evaluate Approximate Retrieval Recall
Here, \(R_k\) is the approximate result set and \(G_k\) is the exact reference result set.
def calculate_recall_at_k(
retrieved_ids,
ground_truth_ids
):
retrieved_set = set(
retrieved_ids
)
ground_truth_set = set(
ground_truth_ids
)
if not ground_truth_set:
raise ValueError(
"Ground-truth IDs are required."
)
return (
len(
retrieved_set
&
ground_truth_set
)
/
len(
ground_truth_set
)
)
FAISS Index Selection
| Requirement | Possible Starting Point |
|---|---|
| Exact Baseline | Flat index |
| Approximate Graph Search | HNSW index |
| Partition-Based Search | IVF index |
| Memory-Constrained Large Index | Product-quantized or composite index |
| Accelerated Compatible Workload | Supported GPU index |
What Is OpenSearch Vector Search?
OpenSearch can store vector fields alongside document content and metadata. This makes it suitable for applications combining vector similarity, lexical search, filters, and document-oriented search capabilities.
OpenSearch Vector Capabilities
- Vector fields
- Approximate k-nearest-neighbor search
- Exact or scoring-based vector queries where supported
- HNSW and IVF configurations through compatible engines
- Metadata and document filtering
- Lexical search
- Hybrid search patterns
- Document lifecycle and index management
Connect to OpenSearch
import os
from opensearchpy import OpenSearch
opensearch_host = os.environ[
"OPENSEARCH_HOST"
]
opensearch_username = os.environ[
"OPENSEARCH_USERNAME"
]
opensearch_password = os.environ[
"OPENSEARCH_PASSWORD"
]
opensearch_client = OpenSearch(
hosts=[
{
"host": opensearch_host,
"port": 443
}
],
http_auth=(
opensearch_username,
opensearch_password
),
use_ssl=True,
verify_certs=True
)
Create an OpenSearch Vector Index
index_name = (
"course-articles-v1"
)
index_definition = {
"settings": {
"index": {
"knn": True
}
},
"mappings": {
"properties": {
"chunk_id": {
"type": "keyword"
},
"document_id": {
"type": "keyword"
},
"title": {
"type": "text"
},
"chunk_text": {
"type": "text"
},
"category": {
"type": "keyword"
},
"language": {
"type": "keyword"
},
"access_group": {
"type": "keyword"
},
"embedding_model": {
"type": "keyword"
},
"content_vector": {
"type": "knn_vector",
"dimension": dimension,
"method": {
"name": "hnsw",
"space_type": "cosinesimil",
"engine": "lucene",
"parameters": {
"ef_construction": 128,
"m": 24
}
}
}
}
}
}
if not opensearch_client.indices.exists(
index=index_name
):
opensearch_client.indices.create(
index=index_name,
body=index_definition
)
Index an OpenSearch Document
document_record = {
"chunk_id": "article-20-8-chunk-1",
"document_id": "article-20-8",
"title": (
"Vector Databases"
),
"chunk_text": documents[
2
],
"category": "generative-ai",
"language": "en",
"access_group": "learners",
"embedding_model": (
embedding_model_id
),
"content_vector": (
document_embeddings[
2
].tolist()
)
}
opensearch_client.index(
index=index_name,
id=document_record[
"chunk_id"
],
body=document_record,
refresh=True
)
Search OpenSearch by Vector
query_body = {
"size": 3,
"_source": [
"chunk_id",
"document_id",
"title",
"chunk_text",
"category"
],
"query": {
"knn": {
"content_vector": {
"vector": (
query_embedding[
0
].tolist()
),
"k": 3
}
}
}
}
search_response = (
opensearch_client.search(
index=index_name,
body=query_body
)
)
for hit in search_response[
"hits"
][
"hits"
]:
print(
{
"score": hit[
"_score"
],
"source": hit[
"_source"
]
}
)
OpenSearch Vector Search with a Filter
filtered_query = {
"size": 3,
"_source": [
"chunk_id",
"title",
"chunk_text",
"category",
"language"
],
"query": {
"knn": {
"content_vector": {
"vector": (
query_embedding[
0
].tolist()
),
"k": 3,
"filter": {
"bool": {
"must": [
{
"term": {
"language": "en"
}
},
{
"term": {
"access_group": (
"learners"
)
}
}
]
}
}
}
}
}
}
filtered_response = (
opensearch_client.search(
index=index_name,
body=filtered_query
)
)
Hybrid Retrieval
Hybrid retrieval combines lexical and vector signals. Lexical retrieval can preserve exact terms, while vector retrieval can identify semantically related content.
What Is Pinecone?
Pinecone is a managed vector-search platform. Applications can create an index, write records, organize them through namespaces, attach metadata, and retrieve similar records using vector or supported text-oriented search workflows.
Pinecone Concepts
- Index
- Record
- Vector
- Metadata
- Namespace
- Upsert
- Query or search
- Metadata filter
- Dense and sparse retrieval options
Connect to Pinecone
import os
from pinecone import Pinecone
pinecone_client = Pinecone(
api_key=os.environ[
"PINECONE_API_KEY"
]
)
Create a Pinecone Vector Index
from pinecone import ServerlessSpec
pinecone_index_name = (
"course-articles-v1"
)
existing_indexes = {
index_description[
"name"
]
for index_description in (
pinecone_client.list_indexes()
)
}
if (
pinecone_index_name
not in existing_indexes
):
pinecone_client.create_index(
name=pinecone_index_name,
dimension=dimension,
metric="cosine",
spec=ServerlessSpec(
cloud="aws",
region=(
"replace-with-approved-region"
)
)
)
Target the Pinecone Index
index_description = (
pinecone_client.describe_index(
pinecone_index_name
)
)
pinecone_index = (
pinecone_client.Index(
host=index_description[
"host"
]
)
)
Upsert Vectors into Pinecone
pinecone_records = []
for position, (
document_text,
embedding
) in enumerate(
zip(
documents,
document_embeddings
),
start=1
):
pinecone_records.append(
{
"id": (
f"course-chunk-{position}"
),
"values": embedding.tolist(),
"metadata": {
"document_id": (
"vector-database-lesson"
),
"chunk_number": position,
"chunk_text": document_text,
"category": "generative-ai",
"language": "en",
"access_group": "learners",
"embedding_model": (
embedding_model_id
)
}
}
)
pinecone_index.upsert(
vectors=pinecone_records,
namespace="machine-learning-course"
)
Query Pinecone
pinecone_response = (
pinecone_index.query(
namespace=(
"machine-learning-course"
),
vector=(
query_embedding[
0
].tolist()
),
top_k=3,
include_values=False,
include_metadata=True
)
)
for match in pinecone_response[
"matches"
]:
print(
{
"id": match[
"id"
],
"score": match[
"score"
],
"metadata": match[
"metadata"
]
}
)
Pinecone Metadata Filtering
filtered_pinecone_response = (
pinecone_index.query(
namespace=(
"machine-learning-course"
),
vector=(
query_embedding[
0
].tolist()
),
top_k=3,
include_metadata=True,
filter={
"$and": [
{
"language": {
"$eq": "en"
}
},
{
"access_group": {
"$eq": "learners"
}
},
{
"category": {
"$in": [
"generative-ai",
"mlops"
]
}
}
]
}
)
)
FAISS vs OpenSearch vs Pinecone
| Area | FAISS | OpenSearch | Pinecone |
|---|---|---|---|
| Product Type | Similarity-search library | Search platform with vector capabilities | Managed vector-search platform |
| Deployment | Embedded into an application or custom service | Self-managed or managed OpenSearch environment | Managed service |
| Vector Index Control | Detailed index selection and tuning | Method and engine configuration | Managed according to the selected Pinecone index and API |
| Metadata Storage | Requires application-managed metadata mapping | Stores vector fields with document fields | Stores metadata with indexed records |
| Lexical Search | Requires a separate implementation | Built into the search platform | Available according to the selected index and current search API |
| Operational Management | Application team manages persistence, APIs, scaling, and availability | Requires search-cluster operations unless managed externally | Infrastructure operations are managed by the service |
| Suitable Starting Point | Local search, research, custom systems, and exact baselines | Applications combining search, filters, and vectors | Teams preferring a managed vector-search service |
Vector Databases in RAG
| RAG Stage | Responsibility |
|---|---|
| Query Understanding | Normalizes or expands the user's information need |
| Embedding | Creates a query vector compatible with the index |
| Authorization Filter | Restricts retrieval to permitted records |
| Candidate Retrieval | Returns semantically or lexically relevant chunks |
| Reranking | Reorders candidates using a more precise relevance model or rule |
| Context Assembly | Selects and formats evidence within the context budget |
| Generation | Produces an answer grounded in the supplied context |
| Citation | Connects answer claims to retrievable source records |
Reranking
Reranking applies a second-stage model or scoring rule to the candidates returned by the initial retriever.
Reranking Benefits
- Uses richer query-document interaction
- Can improve ordering among retrieved candidates
- Can reduce weak context sent to the LLM
- Allows broad first-stage retrieval followed by focused selection
Evaluate Retrieval Quality
| Metric | Main Question |
|---|---|
| Recall at k | Did the top-k results contain the relevant evidence? |
| Precision at k | What proportion of the top-k results was relevant? |
| Mean Reciprocal Rank | How early did the first relevant result appear? |
| Mean Average Precision | How accurately were multiple relevant results ranked? |
| Normalized Discounted Cumulative Gain | How well did ranking preserve graded relevance? |
| Filter Accuracy | Were only eligible and authorized records returned? |
| Retrieval Latency | Did retrieval satisfy the operational objective? |
| Empty-Result Rate | How often did retrieval return no usable evidence? |
Calculate Retrieval Metrics
def precision_at_k(
retrieved_ids,
relevant_ids,
k
):
if k <= 0:
raise ValueError(
"k must be positive."
)
selected_ids = retrieved_ids[
:k
]
relevant_set = set(
relevant_ids
)
relevant_count = sum(
retrieved_id
in relevant_set
for retrieved_id in selected_ids
)
return (
relevant_count
/
k
)
def reciprocal_rank(
retrieved_ids,
relevant_ids
):
relevant_set = set(
relevant_ids
)
for rank, retrieved_id in enumerate(
retrieved_ids,
start=1
):
if retrieved_id in relevant_set:
return 1.0 / rank
return 0.0
Build a Retrieval Evaluation Set
{
"query_id": "query-001",
"query": "How does model monitoring detect production degradation?",
"relevant_chunk_ids": [
"monitoring-definition",
"delayed-quality",
"drift-detection"
],
"required_filters": {
"language": "en",
"access_group": "learners"
}
}
Evaluation-Set Requirements
- Representative user queries
- Simple and difficult information needs
- Exact-term queries
- Paraphrased semantic queries
- Queries requiring metadata filters
- Queries with multiple relevant documents
- Queries for which no answer exists
- Versioned relevance judgments
- Independent evaluation examples
Embedding and Index Versioning
| Asset | Why Version It? |
|---|---|
| Source Corpus | Identifies the content available for retrieval |
| Parser | Controls extracted content and structure |
| Chunker | Controls chunk boundaries and overlap |
| Embedding Model | Defines vector meaning and dimension |
| Normalization | Influences similarity calculations |
| Index Type | Controls search behavior and trade-offs |
| Index Parameters | Control speed, recall, memory, and construction |
| Metadata Schema | Controls filtering, display, and authorization |
| Reranker | Controls final candidate ordering |
| Retrieval Policy | Controls top-k, filters, thresholds, and context selection |
Re-Embedding and Index Migration
Changing the embedding model can alter vector dimensions and the geometry of the embedding space. Existing embeddings cannot generally be mixed safely with embeddings from an incompatible model.
Updates and Deletions
Lifecycle Operations
- Upsert new or changed chunks
- Preserve stable record identifiers
- Delete obsolete chunks
- Remove superseded document versions
- Propagate source deletion requests
- Recalculate embeddings after content changes
- Update metadata when authorization changes
- Verify that removed records no longer appear in search
- Record ingestion and deletion history
Security and Access Control
Required Controls
- Authenticate ingestion and query workloads
- Apply least-privilege permissions
- Encrypt network connections
- Encrypt indexed data according to policy
- Apply authorization filters before retrieval
- Separate tenants or security scopes appropriately
- Protect API keys and credentials
- Validate uploaded document types and sizes
- Prevent unauthorized index creation and deletion
- Audit queries and administrative changes
- Protect index backups
- Apply data-retention and deletion requirements
Prompt Injection and Retrieved Content
Retrieved text is untrusted data. A document may contain malicious, misleading, obsolete, or instruction-like content intended to alter the behavior of the downstream model.
RAG Security Controls
- Treat retrieved content as data rather than trusted instructions
- Separate system instructions from retrieved context
- Preserve source identifiers and citations
- Apply authorization before retrieval
- Inspect supported document types during ingestion
- Detect suspicious instruction-like content where appropriate
- Restrict tool execution and external actions
- Require confirmation for consequential operations
- Log retrieval and source-selection metadata safely
- Test prompt-injection scenarios
Vector Database Monitoring
| Monitoring Area | Example Signal |
|---|---|
| Availability | Successful query and write rates |
| Latency | P50, P95, and P99 query duration |
| Throughput | Queries and writes processed per interval |
| Index Size | Vector count, storage, and metadata volume |
| Ingestion Quality | Rejected records, duplicates, and dimension mismatches |
| Freshness | Delay between source change and searchable vector |
| Retrieval Quality | Recall, precision, ranking, and empty-result rate |
| Filter Quality | Authorization and metadata-filter correctness |
| Resource Use | CPU, memory, disk, network, and accelerator use |
| Cost | Storage, indexing, embedding, transfer, and query consumption |
Retrieval Failure Handling
| Failure | Controlled Response |
|---|---|
| Embedding Service Unavailable | Retry when safe, use approved cache, or return a controlled error |
| Dimension Mismatch | Reject the query and investigate model-index compatibility |
| Vector Service Unavailable | Use approved fallback retrieval or state that evidence is unavailable |
| No Results | Avoid unsupported generation and inform the application of insufficient evidence |
| Low-Relevance Results | Apply threshold, reranking, query rewriting, or controlled abstention |
| Unauthorized Results | Block the response, investigate policy enforcement, and preserve incident evidence |
| Stale Index | Correct ingestion and apply a controlled freshness response |
| Partial Metadata | Reject or quarantine records missing required authorization or lineage fields |
Cost and Performance Optimization
| Cost Driver | Possible Control |
|---|---|
| Embedding Generation | Cache unchanged embeddings and re-embed only modified content |
| Vector Dimension | Select an evaluated embedding model appropriate for the task |
| Duplicate Content | Remove duplicates before embedding and indexing |
| Large Metadata | Store only retrieval and governance metadata |
| High Top-k | Retrieve enough candidates for quality without unnecessary context volume |
| Exact Search | Use approximate indexes when validated scale and latency require them |
| Frequent Rebuilding | Use versioned incremental ingestion where appropriate |
| Unused Index Versions | Apply retention and retirement policies after rollback needs expire |
| Cross-Region Traffic | Align embedding, index, application, and users with approved architecture |
Responsible Vector Retrieval
Responsible-Use Requirements
- Index only authorized content
- Preserve source ownership and provenance
- Protect personal and confidential information
- Apply access-control filters before retrieval
- Preserve source version and effective dates
- Support correction and deletion workflows
- Evaluate supported languages and domains
- Measure quality across relevant query groups
- Test no-answer and ambiguous-query behavior
- Prevent unsupported claims when evidence is insufficient
- Report source citations where appropriate
- Maintain rollback and index-retirement procedures
Common Vector Database Mistakes
Troubleshooting
| Symptom | Investigation |
|---|---|
| Dimension Mismatch | Embedding model, index mapping, preprocessing, and stored vector shape |
| Irrelevant Results | Chunking, embedding model, query formulation, metric, filters, and corpus quality |
| Exact Terms Missing | Lexical retrieval and hybrid-search design |
| Repeated Results | Duplicate chunks, overlapping content, and source-version handling |
| Slow Queries | Index type, top-k, filters, searched partitions, hardware, and network |
| Low ANN Recall | Search parameters, index training, vector distribution, and compression |
| Missing Metadata | Ingestion schema, serialization, mapping, and partial failures |
| Old Content Returned | Ingestion freshness, upsert IDs, obsolete-record deletion, and cache invalidation |
| Unauthorized Results | Identity mapping, server-side filters, namespaces, and policy enforcement |
| Different Results Across Environments | Embedding revision, normalization, index version, parameters, and corpus version |
Recommended Vector Database Workflow
Define the Retrieval Objective
Identify the users, content, queries, relevance criteria, latency, scale, security, and downstream use.
Select the Embedding Model
Evaluate domain, language, dimension, metric, quality, latency, privacy, licensing, and deployment requirements.
Prepare Authorized Content
Parse, clean, deduplicate, classify, version, and protect source records.
Design the Chunking Strategy
Select boundaries, size, overlap, parent context, and metadata through retrieval experiments.
Define Metadata and Security
Select stable IDs, source fields, authorization attributes, versions, dates, and lifecycle information.
Build the Index
Generate validated embeddings and create a versioned exact or approximate index.
Evaluate Retrieval
Measure recall, precision, ranking, filtering, latency, throughput, and no-answer behavior.
Add Hybrid Retrieval and Reranking
Combine complementary retrieval signals when measured evidence shows that they improve results.
Deploy and Monitor
Track availability, latency, ingestion, freshness, quality, filters, cost, and downstream answer behavior.
Version and Improve
Rebuild and evaluate new corpus, chunker, embedding, index, and retrieval-policy versions through controlled releases.
Hands-On Practice
Create an Embedding Dataset
Prepare a small approved or synthetic document collection with stable IDs and metadata.
Build an Exact FAISS Baseline
Normalize embeddings, create a flat inner-product index, and inspect top-k results.
Build an Approximate FAISS Index
Create an HNSW or IVF index and compare its recall and latency with exact search.
Create an OpenSearch Index
Store vector, text, source, category, language, and access metadata in one document mapping.
Apply OpenSearch Filters
Restrict vector retrieval using approved server-side language, category, and authorization filters.
Create a Pinecone Index
Upsert versioned records into a namespace and query them through vector similarity.
Apply Pinecone Metadata Filtering
Limit eligible results using authorized metadata conditions.
Evaluate the Three Systems
Compare retrieval quality, latency, metadata behavior, operational responsibilities, security, portability, and cost.
Knowledge Check
What is a vector database?
Explain how it stores embeddings and retrieves nearby vectors using a similarity or distance measure.
What is an embedding?
Explain how a trained model converts an object into a numerical representation.
How does semantic search differ from keyword search?
Explain meaning-oriented vector matching compared with token-oriented lexical matching.
What does top-k retrieval return?
Explain the k closest or highest-scoring eligible records.
Why normalize vectors?
Explain how unit normalization supports consistent cosine-oriented inner-product retrieval.
How does approximate search differ from exact search?
Explain the recall, latency, memory, and throughput trade-off.
Why is metadata filtering important?
Explain how it restricts search by source, category, date, tenant, version, and authorization.
How does FAISS differ from a managed vector database?
Explain the difference between a similarity-search library and a managed storage, query, availability, and lifecycle service.
Why combine vector and lexical retrieval?
Explain how semantic similarity and exact-term matching provide complementary relevance signals.
Why rebuild an index after changing the embedding model?
Explain changes in dimension, vector geometry, model meaning, normalization, and retrieval compatibility.
Vector Database Readiness Checklist
Confirm Before Production Use
- The retrieval objective is documented
- The intended users and applications are identified
- The source corpus is authorized and versioned
- The parser and chunker are versioned
- The embedding model and immutable revision are recorded
- The vector dimension is validated
- The normalization policy is documented
- The similarity metric matches the embedding model
- Stable record and source identifiers are used
- The metadata schema is versioned
- Authorization metadata is required and validated
- Chunk size and overlap are evaluated
- Exact search provides a quality baseline
- Approximate index recall is measured
- Index-construction parameters are recorded
- Search parameters are versioned
- Representative evaluation queries are available
- Relevance judgments are versioned
- Recall, precision, ranking, and latency are measured
- Metadata filters are tested
- Unauthorized-result tests pass
- No-answer behavior is defined
- Low-relevance behavior is defined
- Hybrid-search behavior is evaluated where applicable
- Reranking is evaluated where applicable
- Ingestion is idempotent
- Duplicate chunks are controlled
- Content updates and deletions are propagated
- Index freshness is monitored
- Query and ingestion failures generate actionable alerts
- Credentials are stored securely
- Network connections use approved protection
- Backups and restoration are tested where required
- Embedding-model migration is documented
- Old indexes follow a retention and retirement policy
- Downstream RAG quality and safety are monitored
Lesson Summary
| Concept | Main Outcome |
|---|---|
| Embedding | Represents an object as a dense numerical vector |
| Vector Database | Stores and retrieves vectors using similarity search |
| Cosine Similarity | Compares vector direction |
| Dot Product | Measures vector alignment |
| Euclidean Distance | Measures straight-line vector distance |
| Exact Search | Returns exact nearest neighbors under the selected metric |
| Approximate Search | Trades some recall for lower latency or resource use |
| Metadata Filter | Restricts eligible retrieval records |
| FAISS | Provides high-performance dense-vector indexing and search |
| OpenSearch | Combines vector, document, lexical, and filtered search |
| Pinecone | Provides managed vector indexing and retrieval |
| Hybrid Search | Combines lexical and semantic relevance |
| Reranking | Improves candidate ordering using a second-stage model or rule |
| RAG | Uses retrieved evidence to ground generated responses |
| Retrieval Evaluation | Measures relevance, ranking, filtering, latency, and completeness |
| Governance | Controls content, access, lineage, updates, deletion, and retirement |
Key Takeaway
A vector database stores embeddings and retrieves records whose numerical representations are closest to a query vector. Embedding compatibility, vector dimensions, normalization, distance measures, index strategies, metadata filters, chunking, and source lineage all influence retrieval behavior. FAISS provides flexible local similarity-search indexes and detailed control. OpenSearch combines vector retrieval with document search, metadata, filtering, and lexical-search capabilities. Pinecone provides managed vector indexing, namespaces, records, and metadata-filtered retrieval. Reliable production retrieval requires more than storing vectors. It requires authorized content, point-to-source traceability, versioned embeddings, retrieval evaluation, server-side access control, freshness monitoring, deletion propagation, secure credentials, controlled migration, and responsible downstream use.
Get Machine Learning updates by email
Short, practical lessons and course updates from Rumman Ansari. No spam.