Module 6: Designing Search Systems
8. Capstone Exercise: Designing a Search System
Exercise overview
This is the capstone exercise for Module 6. Here you're going to design a complete search system for a specific case, making decisions about chunking, embeddings, the vector DB, ranking, and metrics.
The case: An academic search engine
Context:
A university wants an internal search engine for 100K scientific papers (PDF) across multiple disciplines (CS, physics, biology, mathematics).
Requirements:
-
Typical queries:
- Conceptual: "optimization methods in machine learning"
- Exact: "Hinton's 2012 paper"
- Exploratory: "the latest advances in quantum computing"
-
Features:
- Search by author, year, discipline
- Suggest related papers (diversity)
- Prefer recent papers (a time boost)
-
Constraints:
- Latency < 1 second
- A limited budget (prefer local models if possible)
- High precision (academics are demanding users)
The task: Design the architecture
For each component, decide:
1. Chunking strategy
See the suggested solution
Strategy: Hierarchical (by section)
Justification:
- Papers have structure: Abstract, Introduction, Methods, Results, Conclusion
- Each section is a chunk (complete context)
- If a section is > 1000 tokens → split it by paragraph
Size: 800-1200 tokens per chunk
Overlap: 100 tokens (for the transitions between sections)
Metadata per chunk:
paper_id: The ID of the original papersection: Abstract, Introduction, etc.author: The list of authorsyear: The year of publicationdiscipline: CS, Physics, etc.
2. Embedding model
See the suggested solution
Model: A local Sentence-BERT (allenai-specter, specialized in scientific papers)
Justification:
- SPECTER: Trained on a scientific corpus (better than ada-002 for academics)
- Local: $0 cost after setup (a limited budget)
- Dimensions: 768D (lower than OpenAI but enough)
Alternative: OpenAI text-embedding-3-large (3072D) if the budget allows (better quality).
3. Vector database
See the suggested solution
Database: Weaviate (self-hosted)
Justification:
- Open-source: No license cost
- HNSW: Fast for 100K papers (~1M chunks)
- Metadata filters: It supports filters by author, year, discipline
- Hybrid search: Keyword + semantic, natively
Alternative: Qdrant (also open-source, similar features).
4. Search strategy
See the suggested solution
Strategy: Hybrid (keyword + semantic) with pattern detection
The algorithm:
1. Detect the query pattern:
Does it contain "[author]'s [year] paper"?
→ Exact filter: author + year + semantic search
Does it contain a discipline ("in CS")?
→ Filter: discipline=CS + semantic search
Otherwise:
→ Hybrid search (α=0.7, favoring semantic)
2. Run the search (top-100)
3. MMR (λ=0.6, diversify by discipline and author)
4. Time boost (papers < 2 years old: 1.3x)
5. Return the top-20
5. Ranking strategy
See the suggested solution
Combined strategies:
a. Hybrid (RRF):
Keyword + semantic fusion
→ RRF with k=60
b. MMR (diversity):
λ = 0.6
Diversify by:
- Discipline (not 20 CS papers if the query is general)
- Author (not 20 papers from the same group)
c. Time boost:
Papers < 2 years old: 1.3x
Papers 2-5 years old: 1.1x
Papers > 5 years old: 1.0x
6. Query processing latency
See the suggested solution
The breakdown:
1. Embedding the query (local SPECTER): 50ms
2. kNN search (Weaviate HNSW): 80ms
3. MMR (diversifying 100 → 20): 100ms
4. Total: ~230ms
Optimizations:
- Cache the embeddings of frequent queries
- Pre-compute the paper embeddings (offline)
- Run keyword + semantic in parallel
Expected final latency: 200-300ms ✅ (< 1 second)
7. Evaluation metrics
See the suggested solution
Metrics:
a. Precision@10:
Of the first 10 results, how many are relevant?
Target: > 0.80
b. NDCG@20:
The quality of the ranking (order matters).
Target: > 0.75
c. Diversity (disciplines in the top-20):
How many different disciplines appear?
Target: ≥ 3 (if the query is interdisciplinary)
d. Latency:
Target: < 500ms (p95)
Evaluation set:
- 100 queries labeled by academics
- Coverage across disciplines and query types
Architecture diagram (the solution)
┌─────────────────────────────────────────────────┐
│ 100K PAPERS (PDF) │
└────────────┬────────────────────────────────────┘
│
v
┌────────────────┐
│ Hierarchical │ (By section)
│ Chunking │
└────────┬───────┘
│
v
┌────────────────┐
│ SPECTER │ (Local embeddings)
│ 768D │
└────────┬───────┘
│
v
┌─────────────────────────────────────┐
│ WEAVIATE (self-hosted) │
│ - HNSW index │
│ - Metadata: author, year, discipline│
└────────┬────────────────────────────┘
│
│
┌────────┴────────┐
│ │
v v
┌─────────┐ ┌──────────────┐
│ Keyword │ │ Semantic │
│ BM25 │ │ (cosine) │
└────┬────┘ └──────┬───────┘
│ │
└────────┬───────┘
│
v
┌────────────────┐
│ RRF Fusion │
└────────┬───────┘
│
v
┌────────────────┐
│ MMR │ (λ=0.6, diversity)
└────────┬───────┘
│
v
┌────────────────┐
│ Time Boost │ (< 2 years: 1.3x)
└────────┬───────┘
│
v
┌────────────────┐
│ Top-20 │
└────────────────┘
Exercise summary
What you did:
- ✅ You designed a chunking strategy (hierarchical)
- ✅ You chose an embedding model (local SPECTER)
- ✅ You selected a vector DB (Weaviate)
- ✅ You defined a search strategy (hybrid + MMR)
- ✅ You established a ranking approach (RRF + MMR + boost)
- ✅ You estimated the latency (200-300ms)
- ✅ You defined the metrics (Precision, NDCG, diversity)
The intuition, consolidated:
"Designing a search system requires informed decisions at every component: chunking, embeddings, the vector DB, ranking. There's no single solution; it depends on the requirements (latency, budget, precision) and the type of queries."
Module 6 conclusion
Congratulations on completing Module 6: Designing Search Systems. 🎉
What you achieved:
- ✅ You understand end-to-end architecture (indexing, query processing)
- ✅ You can design an indexing pipeline (chunking, embeddings)
- ✅ You can optimize query processing (kNN, reranking)
- ✅ You can implement advanced ranking (RRF, MMR, boost)
- ✅ You can evaluate quality (precision, recall, MRR, NDCG)
- ✅ You can analyze case studies (RAG, e-commerce, support)
The module's key intuition:
An effective search system integrates multiple techniques (chunking, embeddings, ANN, ranking, filters) into a coherent architecture. The design decisions depend on specific requirements: latency, budget, the type of queries, and the expected precision.
Next module: Module 7: RAG (Retrieval-Augmented Generation) — Full integration with LLMs.