Rag Implementer

RAG Implementer

Build production-ready retrieval-augmented generation systems. RAG = Retrieval + Context Assembly + Generation. Use RAG when LLMs need access to fresh, domain-specific, or proprietary knowledge not in their training data. Do not use RAG when simpler alternatives (FAQ pages, keyword search, semantic search) suffice. For KB architecture selection and governance, use the knowledge-base-manager skill. For knowledge graph implementation, use the knowledge-graph-builder skill.

Overview

Before building RAG, validate the need: try FAQ pages, keyword search, concierge MVP, or simple semantic search first. Only proceed with RAG for 50k+ documents with validated user demand and $200-500/month budget. RAG systems range from Naive (prototype) through Advanced (production) to Modular (enterprise), each tier adding complexity and cost.

The RAG pipeline has three core stages. First, retrieval finds relevant documents using hybrid search (semantic + keyword). Second, context assembly ranks, deduplicates, and compresses retrieved chunks into an optimal prompt. Third, generation produces a grounded response with source attribution. Each stage has distinct failure modes: retrieval can miss relevant documents (low recall), context assembly can overwhelm the model (lost in the middle), and generation can hallucinate despite good context (low faithfulness).

Modern RAG extends beyond basic vector similarity. Hybrid search combining dense embeddings with sparse BM25 is now the baseline. Re-ranking with cross-encoders improves precision after initial retrieval. Contextual chunking and late chunking preserve document-level semantics that fixed-size chunking loses. GraphRAG enables multi-hop reasoning over entity relationships by building knowledge graphs from documents. Proposition chunking breaks documents into atomic facts for precise retrieval of individual claims.

Choose techniques based on your query complexity and document structure. Start with hybrid search and re-ranking as the foundation, then layer contextual chunking, GraphRAG, or query expansion as needed. Measure everything: Precision@K, Recall@K, faithfulness, and end-to-end latency. The difference between a good and bad chunking strategy alone can create a 9% gap in recall performance.

Quick Reference

Common Mistakes

Embedding Model Notes

text-embedding-3-large (3072 dimensions) remains OpenAI's most capable embedding model. It supports Matryoshka dimensionality reduction via the dimensions API parameter -- 1024 dimensions often delivers near-full accuracy at one-third storage cost. text-embedding-3-small (1536 dimensions) is a cost-effective alternative at $0.02 per million tokens. For code search, Voyage Code 3 outperforms general-purpose models. For multilingual workloads, consider multilingual-e5-large or Cohere embed-v4. Always benchmark on your domain data; general benchmarks do not predict domain-specific performance.

Vector Store Notes

Pinecone for managed simplicity, Weaviate or Qdrant for self-hosted with hybrid search, Chroma for prototyping, pgvector for teams already on PostgreSQL (practical limit around 10-100M vectors), and Milvus/Zilliz for billion-scale deployments. Choose index type based on tradeoffs: HNSW for speed (higher memory), IVF for scale (requires training), flat for exact search on small datasets only.

Most vector databases now achieve 10-100ms query latency on 1-10M vector datasets. Start with the simplest option that fits your scale requirements and migrate only when you hit concrete performance limits.

Delegation

• Discover data sources and assess knowledge base quality: Use Explore agent to catalog documents, evaluate data freshness, and identify authoritative content
• Implement retrieval pipeline with hybrid search and re-ranking: Use Task agent to build embedding, indexing, retrieval, and evaluation components
• Design RAG architecture and vector store topology: Use Plan agent to select embedding models, vector databases, chunking strategies, and deployment architecture

For KB architecture selection, curation workflows, and governance, use the knowledge-base-manager skill. For knowledge graph implementation (ontology, entity extraction, graph databases), use the knowledge-graph-builder skill.

References

• Architecture patterns and prerequisites
• Chunking strategies and knowledge base design
• Retrieval methods and pipeline design
• Evaluation metrics and quality gates
• Production deployment and continuous improvement

Architecture Patterns and Prerequisites

Prerequisites: Validate the Need for RAG

Before implementing RAG, confirm:

• Problem validated with users
• Users need AI search (tested with simpler alternatives)
• ROI justified (cost vs benefit calculated)

Try These FIRST (Before RAG)

1. FAQ Page / Documentation (1 day, $0)

• Create well-organized FAQ or docs
• Add search with Cmd+F
• Works for: <50 common questions, static content

2. Simple Keyword Search (2-3 days, $0-20/month)

• Use Algolia, Typesense, or PostgreSQL full-text search
• Good enough for 80% of use cases
• Works for: <100k documents, keyword matching sufficient

3. Manual Curation / Concierge MVP (1 week, $0)

• Manually answer user questions
• Build FAQ from common questions
• Works for: <100 users, validating if users want AI

4. Simple Semantic Search (1 week, $30-50/month)

• Use OpenAI embeddings + Postgres pgvector
• Skip complex retrieval, re-ranking, etc.
• Works for: <50k documents, basic semantic search

Decision Tree

Do users need to search your content?
|
+- No -> Don't build RAG
|
+- Yes
   +- <50 items? -> FAQ page ($0)
   |
   +- >50 items?
      +- Keyword search enough? -> Use Algolia ($0-20/mo)
      |
      +- Need semantic understanding?
         +- <50k docs? -> Simple semantic search via pgvector ($30/mo)
         |
         +- >50k docs?
            +- Validated with users? -> Build RAG
            +- Not validated? -> Test with Concierge MVP first

Architecture Tiers

Naive RAG (Prototype)

• Time: 1-2 weeks
• Cost: $50-150/month
• Scale: <10k documents
• Components: Basic embedding + vector store + simple retrieval

Advanced RAG (Production)

• Time: 3-4 weeks
• Cost: $200-500/month
• Scale: 10k-1M documents
• Components: Hybrid search, re-ranking, monitoring

Modular RAG (Enterprise)

• Time: 6-8 weeks
• Cost: $500-2000+/month
• Scale: 1M+ documents
• Components: Multiple knowledge bases, specialized modules

Modular RAG Architecture

• Search Module: Query understanding, reformulation, and hybrid retrieval
• Memory Module: Long-term conversation persistence and context accumulation
• Routing Module: Query routing to specialized knowledge bases or retrieval strategies
• Predict Module: Anticipatory pre-loading based on context
• Graph Module: Knowledge graph traversal for multi-hop reasoning (GraphRAG)

Hybrid RAG + Fine-tuning

• RAG for dynamic, frequently changing knowledge
• Fine-tuning for domain-specific reasoning patterns
• Combine strengths for maximum effectiveness

GraphRAG

• Build knowledge graphs by extracting entities and relationships from documents
• Enable multi-hop reasoning: "What projects did employees in department X work on?"
• Combine graph traversal with vector similarity for structured + unstructured queries
• Best suited for datasets with rich entity relationships (org charts, product catalogs, research papers)

Key RAG Principles

1. Relevance Over Volume -- Quality curation over massive datasets; remove outdated content continuously 2. Semantic Understanding -- Use embeddings for true semantic matching, recognize query intent 3. Multi-Modal Intelligence -- Handle text, images, code, tables; enable cross-modal retrieval 4. Temporal Awareness -- Prioritize recent info for time-sensitive topics 5. Transparency and Trust -- Always provide source citations and confidence levels

Chunking Strategies and Knowledge Base Design

Phase 1: Knowledge Base Design

Goal: Create well-structured knowledge foundation

Actions:

• Map data sources (internal: docs, databases, APIs / external: web, feeds)
• Filter noise, select authoritative content (prevent "data dump fallacy")
• Define chunking strategy: semantic chunking based on structure
• Add metadata: tags, timestamps, source identifiers, categories

Validation:

• All data sources catalogued and prioritized
• Data quality assessed (accuracy, completeness, freshness)
• Chunking strategy tested with sample documents
• Metadata schema validated for search effectiveness

Chunking Strategies

Fixed-Size Chunking

• 500-1000 tokens per chunk
• 50-100 token overlap between chunks
• Simple to implement, works well for uniform content
• Risk: splits may break semantic boundaries

Semantic Chunking

• Split by paragraph, section headers, or topic boundaries
• Preserves meaning within chunks
• Better for structured documents (technical docs, articles)

Recursive Chunking

• Split by structure: markdown headers, code blocks, list items
• Falls back to smaller units when chunks are too large
• Best for mixed-format documents

Contextual Chunking

• Chunk first, then use an LLM to generate a brief context summary for each chunk
• Prepend the summary to the chunk before embedding (e.g., "This chunk discusses authentication in a Node.js API guide")
• Resolves ambiguous references (pronouns, acronyms) that lose meaning when isolated
• Higher computational cost at indexing time but improves retrieval accuracy

Late Chunking

• Embed the full document first so every token captures complete document context
• Pool token embeddings within chunk boundaries after full-document encoding
• Improves retrieval accuracy by 10-12% on documents with anaphoric references
• More efficient than contextual chunking but may sacrifice some relevance

Proposition Chunking

• Break content into atomic, self-contained factual statements
• Each proposition stands alone without needing surrounding context
• Best for fact-dense documents (knowledge bases, encyclopedias, technical specs)
• Significantly improves precision for factual queries

Phase 2: Embedding Strategy

Goal: Choose optimal embedding approach for semantic understanding

Actions:

• Select embedding model based on domain
• Plan multi-modal needs (text, code, images, tables)
• Decide on fine-tuning: use domain data if general embeddings underperform
• Establish similarity benchmarks

Model Selection

Both OpenAI embedding models support Matryoshka dimensionality reduction via the dimensions API parameter. For text-embedding-3-large, 1024 dimensions offers near-full accuracy at one-third the storage cost.

Phase 3: Vector Store Architecture

Goal: Implement scalable vector database

Actions:

• Choose vector DB based on requirements
• Configure index: HNSW for speed, IVF for scale
• Plan scalability: data growth and query volume
• Implement backup, recovery, security

Vector DB Decision Matrix

Index Configuration

• HNSW: Best for speed, higher memory usage
• IVF: Better for large-scale, requires training step
• Flat: Exact search, only viable for small datasets

Evaluation Metrics and Quality Gates

Phase 6: Evaluation and Metrics

Goal: Measure RAG system performance across all dimensions

Retrieval Quality

• Precision@K: Fraction of top-K results that are relevant
• Recall@K: Fraction of relevant docs in top-K
• MRR (Mean Reciprocal Rank): Average rank of first relevant result
• NDCG: Ranking quality with graded relevance

Generation Quality

• Faithfulness: Generated content accuracy vs. sources
• Answer Relevance: Response relevance to query
• Context Utilization: How effectively LLM uses retrieved info
• Hallucination Rate: Frequency of unsupported claims

System Performance

• End-to-End Latency: Query to answer (<3 seconds target)
• Retrieval Latency: Time to retrieve and rank (<500ms)
• Token Efficiency: Information density per token
• Cost Per Query: Combined retrieval + generation costs

Validation

• Baseline metrics established
• A/B testing framework for config comparisons
• Automated evaluation pipeline deployed
• Human evaluation protocols for ground truth

Quality Gates

Before Production

• Accuracy >85% on evaluation dataset
• End-to-end latency 95th percentile <5 seconds
• Retrieval latency <500ms

Ongoing Monitoring

• User satisfaction >4.0/5.0
• Reliability: 99.5% uptime
• Cost: Within 10% of budget

Critical Success Rules

Non-Negotiable:

1. Source attribution for every response 2. Validate generated content against sources (prevent hallucination) 3. Filter sensitive data before retrieval 4. Respond within latency thresholds (<3 seconds) 5. Monitor and optimize costs continuously 6. Comply with security policies 7. Graceful degradation on failures 8. Full testing before production

Production Deployment and Continuous Improvement

Phase 7: Production Deployment

Goal: Deploy with enterprise-grade reliability and security

Deployment

• Containerize with Docker/Kubernetes
• Implement load balancing across RAG instances
• Add caching for frequent queries
• Graceful degradation: fallback to base model on component failure

Security

• Role-based access controls for knowledge base
• Data masking and PII protection
• Audit logging for compliance
• Prompt injection defense

Monitoring

• Real-time metrics dashboard (latency, cost, accuracy)
• Query analysis for patterns and failure modes
• Cost tracking and optimization alerts
• Performance profiling for bottlenecks

Validation

• Production handles expected traffic
• Security prevents unauthorized access
• Monitoring provides actionable insights
• Incident response procedures tested

Phase 8: Continuous Improvement

Goal: Establish processes for ongoing enhancement

Data Pipeline

• Automated knowledge base updates (real-time or scheduled)
• Quality monitoring: detect data drift and degradation
• Source diversification: add new data sources
• Feedback integration: user corrections and preferences

Model Evolution

• Evaluate and migrate to improved embeddings
• Fine-tune on domain data regularly
• Upgrade architecture: Naive to Advanced to Modular RAG
• Expand multi-modal support (images, audio, video)

Optimization

• Analyze query patterns, optimize for common needs
• Improve cache hit rates
• Tune vector indices regularly
• Balance performance vs. costs

Validation

• Automated improvement pipelines functioning
• Performance trends show improvement
• User satisfaction increasing
• System adapts to changing needs

Related Resources

Related Skills:

• multi-agent-architect - For complex RAG orchestration
• knowledge-graph-builder - For structured knowledge integration
• performance-optimizer - For RAG system optimization

Retrieval Methods and Pipeline Design

Phase 4: Retrieval Pipeline

Goal: Build sophisticated retrieval beyond simple similarity search

Actions:

• Implement hybrid retrieval: semantic search + keyword (BM25)
• Add query enhancement: expansion, reformulation, multi-query
• Apply contextual filtering: metadata, temporal constraints, relevance ranking
• Design for query types: factual (precision), analytical (breadth), creative (diversity)
• Handle edge cases: no relevant results found

Advanced Techniques

• Re-ranking: Use cross-encoder after initial retrieval (e.g., cross-encoder/ms-marco-MiniLM-L-12-v2) to improve precision
• Query routing: Route different query types to specialized retrieval strategies
• Ensemble methods: Combine multiple retrieval approaches with reciprocal rank fusion
• Adaptive retrieval: Adjust top-k based on query complexity
• Query expansion / HyDE: Generate hypothetical answers to expand sparse queries into richer representations
• GraphRAG: Build knowledge graphs from documents; traverse entity relationships for multi-hop reasoning queries
• Contextual retrieval: Prepend LLM-generated context summaries to chunks before embedding to resolve ambiguous references
• ColBERT-style late interaction: Token-level similarity scoring between queries and documents for fine-grained matching

Validation

• Retrieval accuracy tested across diverse query types
• Hybrid retrieval outperforms single-method baselines
• Query latency meets requirements (<500ms ideal)
• Edge cases and fallbacks tested

Parent Document Retriever

Store small chunks for embedding and retrieval but return the full parent document (or a larger section) for context. Small chunks produce more precise embeddings; large context windows give the LLM enough surrounding information to generate accurate answers.

When to use: Long documents where individual passages lose meaning without surrounding context. Legal contracts, technical manuals, research papers with cross-referencing sections.

When to avoid: Short documents where chunks already capture the full context, or when token budget is tight.

interface ParentDocumentStore {
  parentDocuments: Map<string, string>;
  childChunks: Map<string, { text: string; parentId: string }>;
}

function buildParentDocumentIndex(
  documents: { id: string; text: string }[],
  chunkSize: number,
  chunkOverlap: number,
): ParentDocumentStore {
  const store: ParentDocumentStore = {
    parentDocuments: new Map(),
    childChunks: new Map(),
  };

  for (const doc of documents) {
    store.parentDocuments.set(doc.id, doc.text);

    const chunks = splitIntoChunks(doc.text, chunkSize, chunkOverlap);
    for (let i = 0; i < chunks.length; i++) {
      const chunkId = `${doc.id}_chunk_${i}`;
      store.childChunks.set(chunkId, {
        text: chunks[i],
        parentId: doc.id,
      });
    }
  }

  return store;
}

async function parentDocumentRetrieval(
  query: string,
  store: ParentDocumentStore,
  vectorDb: VectorStore,
  topK: number,
): Promise<string[]> {
  const childResults = await vectorDb.similaritySearch(query, topK);

  const parentIds = new Set<string>();
  for (const result of childResults) {
    const chunk = store.childChunks.get(result.id);
    if (chunk) parentIds.add(chunk.parentId);
  }

  return [...parentIds].map((id) => store.parentDocuments.get(id)!);
}

A common variant uses a mid-level parent: instead of returning the full document, return the section or page containing the matched chunk. This balances precision with context.

Contextual Compression

After retrieval, extract only the relevant portions from each document using an LLM. Reduces noise in the context window so the generator sees focused, high-signal content.

When to use: Retrieved chunks contain relevant information buried inside irrelevant surrounding text. Common with larger chunk sizes or parent document retrieval.

When to avoid: Latency-sensitive pipelines where the extra LLM call is too expensive, or when chunks are already tightly scoped (proposition chunking).

async function compressRetrievedDocuments(
  query: string,
  documents: { text: string; source: string }[],
  llm: LLMClient,
): Promise<{ text: string; source: string }[]> {
  const compressed: { text: string; source: string }[] = [];

  for (const doc of documents) {
    const extraction = await llm.complete({
      prompt: [
        `Given the following question and document, extract only the parts `,
        `of the document that are directly relevant to answering the question. `,
        `If nothing is relevant, respond with "IRRELEVANT".\n\n`,
        `Question: ${query}\n\n`,
        `Document:\n${doc.text}`,
      ].join(''),
    });

    if (extraction.trim() !== 'IRRELEVANT') {
      compressed.push({ text: extraction, source: doc.source });
    }
  }

  return compressed;
}

For higher throughput, batch the compression calls or use a smaller model (e.g., GPT-4o-mini or Claude Haiku) dedicated to extraction. The compression step typically adds 200-500ms latency per document but can reduce total context tokens by 50-70%.

Multi-Query Retrieval

Generate multiple query variations from the original question, retrieve for each, then deduplicate and merge results. Captures different facets of ambiguous or complex queries that a single embedding would miss.

async function multiQueryRetrieval(
  originalQuery: string,
  llm: LLMClient,
  vectorDb: VectorStore,
  topK: number,
  numVariations = 3,
): Promise<RetrievalResult[]> {
  const variations = await llm.complete({
    prompt: [
      `Generate ${numVariations} different versions of the following question `,
      `to help retrieve relevant documents from a vector database. `,
      `Each version should approach the question from a different angle.\n\n`,
      `Original question: ${originalQuery}\n\n`,
      `Return only the questions, one per line.`,
    ].join(''),
  });

  const queries = [originalQuery, ...variations.trim().split('\n')];

  const allResults = new Map<string, RetrievalResult>();

  for (const query of queries) {
    const results = await vectorDb.similaritySearch(query, topK);
    for (const result of results) {
      const existing = allResults.get(result.id);
      if (!existing || result.score > existing.score) {
        allResults.set(result.id, result);
      }
    }
  }

  return [...allResults.values()].sort((a, b) => b.score - a.score);
}

Multi-query retrieval pairs well with reciprocal rank fusion (below) for combining results instead of naive max-score deduplication.

Maximal Marginal Relevance (MMR)

Balance relevance and diversity in results to avoid redundant passages. MMR iteratively selects documents that are both relevant to the query and dissimilar to already-selected documents.

Formula: MMR = argmax[lambda * sim(query, doc) - (1 - lambda) * max(sim(doc, selected))]

• lambda = 1.0: pure relevance (equivalent to standard similarity search)
• lambda = 0.0: pure diversity (maximum dissimilarity from selected docs)
• lambda = 0.5-0.7: typical production range balancing both

function mmrSelection(
  queryEmbedding: number[],
  candidates: { id: string; embedding: number[]; text: string }[],
  k: number,
  lambda = 0.6,
): typeof candidates {
  const selected: typeof candidates = [];
  const remaining = [...candidates];

  for (let i = 0; i < k && remaining.length > 0; i++) {
    let bestIdx = 0;
    let bestScore = -Infinity;

    for (let j = 0; j < remaining.length; j++) {
      const relevance = cosineSimilarity(
        queryEmbedding,
        remaining[j].embedding,
      );

      let maxSimilarity = 0;
      for (const sel of selected) {
        const sim = cosineSimilarity(remaining[j].embedding, sel.embedding);
        maxSimilarity = Math.max(maxSimilarity, sim);
      }

      const mmrScore = lambda * relevance - (1 - lambda) * maxSimilarity;

      if (mmrScore > bestScore) {
        bestScore = mmrScore;
        bestIdx = j;
      }
    }

    selected.push(remaining[bestIdx]);
    remaining.splice(bestIdx, 1);
  }

  return selected;
}

MMR is especially valuable when retrieved chunks come from similar sections of the same document. Without MMR, the top-K results might all contain near-identical information, wasting context window tokens.

Cross-Encoder Reranking

Initial retrieval uses bi-encoders (separate query and document embeddings) for speed. Reranking uses a cross-encoder that processes query and document together for higher accuracy, at the cost of being ~100x slower per pair.

Pipeline: Retrieve 50-100 candidates with bi-encoder, then rerank the top candidates with a cross-encoder, return the top-K reranked results.

Cohere Rerank API

import { CohereClient } from 'cohere-ai';

async function cohereRerank(
  query: string,
  documents: { text: string; id: string }[],
  topN: number,
): Promise<{ id: string; text: string; relevanceScore: number }[]> {
  const cohere = new CohereClient({ token: process.env.COHERE_API_KEY });

  const response = await cohere.rerank({
    query,
    documents: documents.map((d) => d.text),
    topN,
    model: 'rerank-v3.5',
  });

  return response.results.map((r) => ({
    id: documents[r.index].id,
    text: documents[r.index].text,
    relevanceScore: r.relevanceScore,
  }));
}

Local Cross-Encoder Reranking

async function crossEncoderRerank(
  query: string,
  documents: { text: string; id: string }[],
  model: CrossEncoderModel,
  topN: number,
): Promise<{ id: string; text: string; score: number }[]> {
  const pairs = documents.map((doc) => ({
    id: doc.id,
    text: doc.text,
    score: model.predict(query, doc.text),
  }));

  return pairs.sort((a, b) => b.score - a.score).slice(0, topN);
}

When to Rerank vs When Not To

Reranking typically adds 100-300ms latency. For Cohere Rerank, cost is ~$1 per 1000 search queries (reranking 100 documents each).

Reciprocal Rank Fusion (RRF)

Combine results from multiple retrieval methods (semantic search, BM25, metadata filters) into a single ranked list without needing normalized scores. RRF is score-agnostic, making it ideal for fusing results from systems with incompatible score scales.

Formula: RRF_score(doc) = sum(1 / (k + rank_i(doc))) for each retrieval method i

The constant k (typically 60) dampens the impact of high rankings from any single method.

function reciprocalRankFusion(
  rankedLists: { id: string; text: string }[][],
  k = 60,
): { id: string; text: string; score: number }[] {
  const scores = new Map<string, { text: string; score: number }>();

  for (const list of rankedLists) {
    for (let rank = 0; rank < list.length; rank++) {
      const doc = list[rank];
      const existing = scores.get(doc.id);
      const rrfScore = 1 / (k + rank + 1);

      if (existing) {
        existing.score += rrfScore;
      } else {
        scores.set(doc.id, { text: doc.text, score: rrfScore });
      }
    }
  }

  return [...scores.entries()]
    .map(([id, { text, score }]) => ({ id, text, score }))
    .sort((a, b) => b.score - a.score);
}

Hybrid Search with RRF

async function hybridSearchWithRRF(
  query: string,
  vectorDb: VectorStore,
  bm25Index: BM25Index,
  topK: number,
): Promise<{ id: string; text: string; score: number }[]> {
  const [semanticResults, keywordResults] = await Promise.all([
    vectorDb.similaritySearch(query, topK * 2),
    bm25Index.search(query, topK * 2),
  ]);

  const fused = reciprocalRankFusion([semanticResults, keywordResults]);

  return fused.slice(0, topK);
}

RRF is the default fusion method in Elasticsearch and Weaviate hybrid search. It consistently outperforms simple score averaging or weighted combination because it handles score distribution mismatches between retrieval methods.

Phase 5: Context Assembly

Goal: Transform retrieved chunks into optimal LLM context

Actions:

• Rank and select: prioritize by relevance score, recency, source authority
• Synthesize: merge related chunks, avoid redundancy
• Compress: use LLMLingua or similar for token optimization
• Mitigate "lost in the middle": place critical info at start/end
• Adapt dynamically: adjust context based on conversation history

Context Engineering Integration

• Blend RAG results with system instructions and user prompts
• Maintain conversation coherence across multi-turn interactions
• Implement context persistence for follow-up queries
• Balance context size vs. information density

Validation

• Context relevance validated against human judgments
• Token optimization maintains accuracy
• Multi-turn conversations maintain coherence
• Assembly latency <200ms

Standard RAG Response Format

{
  "answer": "Generated response incorporating retrieved information",
  "sources": [
    {
      "content": "Retrieved text chunk",
      "source": "Document/URL identifier",
      "relevance_score": 0.95,
      "chunk_id": "unique_identifier"
    }
  ],
  "confidence": 0.87,
  "retrieval_metadata": {
    "chunks_retrieved": 5,
    "retrieval_time_ms": 150,
    "generation_time_ms": 800
  }
}

Retrieval Method Selection Guide