面对RAG面试，死记硬背远不如理解其背后的设计思想。这份梳理深入剖析了七个核心问题，从选择RAG的初衷到细节优化，旨在帮助构建完整知识体系，从容应对技术深挖。
智能速览
RAG通过外挂知识库降低幻觉，比微调成本更低、更新更快。
混合检索结合语义与字面匹配，能解决单一BM25召回率低的问题。
800-1000 tokens的Chunk size在保证语义完整与减少噪音间取得了平衡。
利用RAGAS框架评测，并根据Recall和Precision等指标针对性优化。
精华内容
要真正掌握RAG，必须理解每个技术选型背后的权衡与取舍。下面将深入探讨七个核心环节的设计逻辑。
选择RAG的缘由
为何选择RAG而非微调？大模型虽具备通用常识，却缺乏企业私有知识且易产生幻觉。微调方案不仅成本高昂，且知识更新时需要重新训练，对事实记忆的稳定性也不足。
RAG则为模型外挂一个实时的知识库，使其能像“开卷考试”一样回答问题，既能溯源引用以降低幻觉，又便于知识库的维护与更新。
既然有检索，为何不直接用BM25全文检索？因为BM25依赖字面匹配，对于“断电”和“掉电”等同义表达容易召回失败。因此，生产环境通常采用混合检索，即结合向量语义检索与BM25，再通过Rerank模型进行融合，以提升召回的准确率和覆盖率。
工程实现细节
向量库选型需分场景考虑。在概念验证（POC）阶段，轻量级的Chroma或FAISS是首选；而在生产环境中，则需考虑Milvus、Qdrant或Elasticsearch 8.x这类高性能系统，评测时需重点关注QPS、延迟、元数据过滤能力及运维成本。
Embedding维度的选择是区分度与成本的直接博弈。维度过低则语义区分能力差，过高则会增加存储和检索开销。部分模型支持向量截断，以在速度和成本间取得平衡。
文档切分方面，800-1000 tokens的Chunk size成为常见实践，因为它能较好地平衡语义完整性与信息噪音。切分时常采用递归策略，从段落逐级降级至句子，并设置10%-20%的Overlap，防止上下文逻辑被意外切断。
评测与优化路径
如何科学评测并优化RAG系统？可以借助RAGAS或TruLens这类专业框架。核心评测指标包括：Context Recall（检索到的上下文是否足够全面）、Context Precision（上下文中噪音信息占比是否过高）以及Faithfulness（生成的答案是否完全基于上下文）。
针对不同指标，有明确的优化路径。若Context Recall偏低，应考虑引入混合检索或进行查询改写；若Context Precision不佳，可引入Reranker模型进行重排序和过滤；若答案质量不高，则可尝试Parent-Child分块策略，为模型提供更丰富的上下文信息。
掌握RAG的核心在于理解其设计哲学与工程实践中的权衡。随着技术演进，未来的RAG系统将如何更智能地融合检索与生成？
