Module 14.1 taught RAG, embeddings, vector search, and indexing. Now you need somewhere to store and query those vectors at speed.
FAISS (Facebook AI Similarity Search) opens Module 14.2. It is a local library—not a networked database—optimized for billion-scale nearest-neighbor search on CPU/GPU. Every managed store you meet next (Chroma, Pinecone, Milvus, Weaviate, Qdrant) either wraps similar index math or sits beside FAISS in hybrid stacks.
Learning Objectives
By the end of this lesson, students should be able to:
- Explain what FAISS is and why it is a library rather than a database server.
- Build a flat L2 / inner-product index and run
searchfor top-k neighbors. - Choose among Flat, IVF, HNSW, and PQ indexes for recall vs latency trade-offs.
- Persist and reload indexes with
write_index/read_index. - Decide when local FAISS is enough versus when a managed vector DB is required.
- Relate FAISS gaps (metadata filters, multi-tenant APIs) to later Module 14.2 tools.
FAISS is an open-source C++/Python library for efficient similarity search and clustering of dense vectors. It provides index types (exact and approximate) that live in process memory or on disk—you own persistence, concurrency, and metadata.
Local Library vs Managed Vector Database
FAISS answers: “Given this query vector, which stored vectors are nearest?” It does not answer: “Filter by tenant_id = 42 and updated_at > yesterday,” or “serve 50 teams with ACLs over HTTPS.” Those needs push you toward Chroma/Qdrant/Pinecone.
| Need | FAISS (local) | Managed / DB (later lectures) |
|---|---|---|
| Prototyping & offline eval | Excellent | Overkill early on |
| Billion-scale ANN on GPU | Excellent | Varies by product |
| Rich metadata filters | DIY (side store) | Built-in |
| Multi-tenant SaaS APIs | You build it | Product feature |
| Ops (backups, HA, auth) | Your problem | Vendor / self-host stack |
Minimal Exact Search
Start with a flat index—exact search, no training. Inner product suits normalized embeddings used as cosine proxies; L2 is Euclidean distance.
Approximate Indexes: Speed vs Recall
Flat
- Exact, simple
- O(n) per query
- Best for <~1M vectors
IVF
- Cluster then search cells
- Needs
train - Tune
nprobe
HNSW / PQ
- Graph or quantized
- High recall at scale
- More RAM / build cost
Metadata and Filtering Reality
FAISS IDs are integers into your vector matrix. Document text, source URLs, and ACLs live in a parallel store (SQLite, Postgres, dict). Filter before search (candidate set) or after (retrieve more, drop mismatches)—FAISS itself has no first-class metadata query language.
Strengths
- Battle-tested ANN algorithms
- CPU and GPU backends
- Free, embeddable, no network hop
- Ideal for batch jobs and research
Tradeoffs
- No built-in metadata filters
- You handle CRUD, auth, HA
- Process-local by default
- Steep index-tuning curve
“FAISS is a drop-in vector database.” It is a search library. Production RAG still needs chunk storage, metadata, upserts, and often a service layer—exactly what Module 14.2’s databases add on top of (or instead of) raw FAISS.
Knowledge Check
- Short Answer: What does FAISS stand for? Answer: Facebook AI Similarity Search.
- True/False: FAISS is primarily a networked multi-tenant database server. Answer: False—it is an in-process library.
- Multiple Choice:
IndexFlatIPperforms: (a) approximate only, (b) exact inner-product search, (c) BM25. Answer: (b). - Short Answer: Why normalize vectors before IP search for cosine? Answer: For unit vectors, inner product equals cosine similarity.
- True/False: IVF indexes require a
trainstep beforeadd. Answer: True. - Multiple Choice: Raising
nprobetypically: (a) lowers recall, (b) raises recall and latency, (c) deletes vectors. Answer: (b). - Short Answer: How do you usually attach document metadata with FAISS? Answer: Parallel side store keyed by FAISS ids.
- Short Answer: Name one method to save an index to disk. Answer: faiss.write_index (and read_index to load).
- Multiple Choice: FAISS is strongest for: (a) GraphQL ACLs, (b) raw ANN at scale, (c) SQL joins. Answer: (b).
- True/False: Managed vector DBs often wrap similar ANN ideas under a service API. Answer: True.
Key Takeaways
- FAISS is the reference local ANN library for dense retrieval experiments and high-throughput search.
- Pick Flat for exact/small; IVF/HNSW/PQ when n grows and approximate search is acceptable.
- Metadata filtering and multi-tenant ops are your responsibility—or a vector DB’s.
- Use FAISS to learn index trade-offs; then graduate to stores that add filters and APIs.
- Next: Chroma / ChromaDB—developer-friendly local DB with collections and metadata.
Lab: Build Flat vs IVF on the same embeddings; plot recall@10 vs latency while sweeping nprobe.
Discussion: When would you keep FAISS in production (batch nightly rebuild) versus switch to Qdrant/Pinecone for online upserts?
Recap: FAISS gives you world-class local similarity search without a database. Continue with Chroma / ChromaDB.