TL;DR

RAG (Retrieval-Augmented Generation), proposed by Lewis et al. in 2020, retrieves relevant passages from an external knowledge base before an LLM generates an answer. It addresses hallucination, stale knowledge cutoffs, and private data. The standard pipeline: chunk documents → embed into vectors → store in a vector DB → retrieve Top-K at query time → optionally rerank → stuff into context → generate.

Pipeline

StepDetailCommon tools
1. ChunkingSplit docs into semantic chunksLangChain, LlamaIndex
2. EmbeddingConvert chunks to vectorsOpenAI, BGE, text-embedding models
3. StorageVector databasepgvector, Milvus, Qdrant, FAISS
4. RetrievalSimilarity search Top-KVector + keyword hybrid
5. RerankPrecision boost (optional)Cohere Rerank, BGE-Reranker
6. GenerationStuff passages into the promptAny LLM

RAG vs plain LLM vs fine-tuning

ApproachUpdate costHallucination riskPrivate dataBest for
Plain LLMNoneHigh (cutoff)NoGeneral Q&A
RAGLow (swap docs)Medium (retrieval-dependent)YesSupport, enterprise KB, live data
Fine-tuningHigh (training)MediumLearnable but fragileTone, format, domain terms

Common pitfalls

FAQ

RAG or fine-tuning?

Choose RAG for fast updates, document-grounded answers, and private data; choose fine-tuning to change tone, output format, or domain vocabulary. Production often combines both.

What chunk size should I use?

There is no single answer; 300–800 tokens is a common range. Aim for "one chunk can answer one question" and tune with retrieval experiments.

Does RAG eliminate hallucination?

No. It reduces hallucination substantially, but retrieval can still return wrong documents; use source citations and evaluate hit rate and faithfulness.

Sources

最后更新:2026-08-04