**RAG(retrieval-augmented generation,检索增强生成)**是让 LLM 基于你的数据作答的标准架构。与其指望模型在训练时恰好记住了正确的事实,RAG 系统在查询时从你的文档里搜出与问题相关的段落,插入上下文窗口,并指示模型基于这些段落回答。模型从「先知」变成了「检索证据之上的推理层」。
四步流水线
- **索引:**把文档切成块存起来,通常以 embedding(承载语义的向量)形式存入向量数据库。
- **检索:**查询时找出与问题最相关的块——语义相似度、关键词搜索,或两者混合(hybrid)。
- **增强:**把胜出的段落和问题一起打包进 prompt。
- **生成:**模型作答,理想情况下逐条标注哪个段落支撑哪个论断。
为什么用 RAG 而不是微调或超大上下文
对比微调:检索交付的事实原文可溯、随改随新——改一份文档,下一次查询就生效;无需重训,回答还能标注出处。对比把所有东西塞进 1M token 窗口:语料涨破任何窗口后,RAG 的单次查询成本仍然平稳。不过对有界语料,长上下文确实抢走了 RAG 不少饭碗——整个知识库能舒服装下时,跳过检索流水线更简单,也越来越常见。RAG 还直接减少幻觉:模型对「眼前的文本」远比对「权重里回忆的事实」准确。
它在哪会翻车
RAG 的失败几乎都是检索的失败:正确的段落没被找到(切块不当、embedding 偏弱、用词不匹配),模型只好凭空作答。功夫在评估——度量检索是否真把对的证据端上来——以及重排序、混合检索与合理的块大小。Claude Sonnet 5、GLM-5.2 这类长上下文模型适合搭配更粗放的检索:多取一些,让模型自己分辨。