检索增强生成：别再让大模型“张口就来”了

大模型不是万能钥匙，先给它配个“外挂书架”

说实话，我第一次被大模型坑，是让它查一个冷门法规条款。它答得飞快，语气还特别笃定。结果呢？条款编号是编的，连发布年份都能错。那一刻我盯着屏幕，脑子里就四个字：又来了。

这不是模型“笨”。它本质上是在做概率预测，靠训练语料里的模式往下接话。知识没覆盖到，它也可能硬接。行业里管这叫幻觉。你问它今天公司内部最新报销制度，它哪知道？训练数据里根本没有，或者早就过期了。

所以检索增强生成，也就是RAG，火得很有道理。别被英文缩写吓到，拆开看就三件事：先检索，再增强，最后生成。模型答题前，先去外部知识库翻资料，把相关片段找出来，塞进上下文，再让它基于这些证据说话。像开卷考试。书不一定全对，但至少比闭卷瞎蒙强。

2020年Lewis等人那篇RAG论文，算是把“检索器+生成器”联合起来做的早期代表。检索器找文档，生成器拿文档写答案。后来DPR、FiD、RETRO这些工作，把稠密检索、融合解码、大规模检索记忆往前推了不少。科研圈关心的是怎么让检索更准、生成更稳；产业圈更直接——能不能少胡说，能不能接企业私有数据。

不过话说回来，RAG不是给模型装个搜索框就完事。很多团队一上来就“向量化+余弦相似度”，跑个demo挺惊艳，上线就露馅。为啥？检索那一步，水很深。

检索这步，真不是“搜一下”那么简单

我见过最典型的翻车：用户问“差旅住宿标准”，系统召回了一堆“差旅报销流程”“住宿发票要求”。字面挺像，答案不对。原因很朴素——只靠稠密向量，语义漂了；只靠BM25，关键词匹配又太死。现在比较靠谱的做法是混合检索：稀疏检索抓关键词，稠密检索抓语义，再拿重排序模型精排。别嫌麻烦，召回错了，后面生成再花哨也是白搭。

还有切片。对，就是文档切块。切太大，噪声多；切太小，上下文断了。科研上有人研究句子级、段落级、层次化切分，产业里更常见的是按标题、表格、FAQ结构切。你以为在调模型，其实在调数据工程。挺烦的，但躲不开。

再说查询改写。用户输入经常很短、很口语，甚至带错别字。“上次那个合同模板在哪”这种问题，直接拿去检索，效果能好才怪。查询扩展、同义词改写、多查询生成，都是常见补丁。更狠一点，做多跳检索：先找线索，再顺着线索追。GraphRAG这类思路，就是把实体关系图拉进来，适合那种“A的上级部门负责的B项目里，C条款怎么规定”的绕弯问题。

行业动态也挺热闹。向量数据库这两年卷得厉害，Milvus、Weaviate、Pinecone这些名字做RAG的应该都熟。但数据库只是底座，真正拉开差距的是检索策略和评测。RAGAS、TruLens这类评测框架开始被更多团队用起来，盯上下文召回、答案忠实度、相关性。别光看“答得像不像”，要看“证据撑不撑得住”。

生成端也别摆烂：把证据嚼碎了再说话

检索回来一堆片段，直接全塞给模型？上下文窗口再大也架不住噪声。更麻烦的是，模型可能被无关片段带偏。所以生成端得约束：要求它只基于给定证据回答，证据不足就说不知道。听着简单，做起来得反复调提示词、做指令微调，甚至加后验校验。

有个细节很多人忽略：引用溯源。答案后面带原文出处，用户点开能核对。这玩意儿不只是产品体验，还是防幻觉的硬手段。模型知道要“交作业”，乱编的冲动会小一点。当然，不是万能。它也可能引用错段落。所以还得做一致性检查，看答案和证据是否对得上。

长上下文模型出来了，有人喊“RAG要死了”。我倒觉得没那么夸张。窗口再长，成本、延迟、信息密度都是问题。你把整个知识库塞进去试试？不现实。RAG更像是把“找什么”和“怎么说”分开优化。长上下文可以当补充，但替代不了检索。至少现在替代不了。

别急着吹，RAG的坑还多着呢

第一，知识更新。文档改了，索引得跟着更新。增量索引、删除同步、权限过滤，都是脏活。第二，多模态。PDF里的表格、扫描件、图片，光靠文本切片会丢信息。第三，评测。离线指标好看，线上用户照样骂。得有人工反馈、bad case回流。第四，安全。检索库里的敏感内容、越权文档，必须在检索层就拦住，别等生成完再补。

我自己的判断是，RAG接下来会往两个方向走：一是更“代理化”，让模型自己决定要不要检索、检索几轮、换什么查询；二是更“工程化”，把数据清洗、切分、混合检索、重排序、评测串成流水线。科研负责探路，工程负责填坑。谁也离不开谁。

所以，下次再看到大模型一本正经胡说八道，别光骂它。先问问：资料给了吗？检索准吗？证据够吗？检索增强生成不是魔法，它只是把“闭卷瞎猜”改成“开卷考试”。开卷考也可能考砸，但至少，你有机会翻到那一页。