第 1 章 — RAG 架构的演进
LLM Primer III: Enhancing Enterprise AI with RAG 章节走读的第一篇。一个基础模型有两条结构性的限 — 知识封冻在训练截止那天、来源不可指认 — 居然有同一个架构上的答案;而这个答案,三年里长出了四张脸。
这一章为什么存在
一个 transformer 在固定语料上训出来之后,有两条限,后续再训也擦不干净。它的知识终止在语料结束的那一天。它也说不清某一句话出自哪份文档,因为那一句不是从某一份里照搬过来的,它是很多份文档在统计上的平均。前一条限造成它对一切新近事物自信地答错;后一条造成它自信地给出错的引用。两条合在一起,就长出企业里那个老熟人:一段读起来很有底气的回答,链接指向一条不存在的条款。
RAG 是同时回答这两条限的那个架构。你不再要求模型一切都先记住,你在推理时把相关材料 — 从你能控制的语料里捞出来 — 递到它面前。语料不重训也能更新;捞出来的段落天然就是引用,因为是你刻意去取的;模型的活由「记住」缩小到「整合」。这一章接下来,就是这个简单动作,在三年里怎么长成了四种能力一档比一档高的架构。
1.1 Naive RAG:嵌入、检索、塞
最简单的那一种,每一篇公开教程现在还在讲。离线:把语料切块,逐块嵌入,把向量写进索引。在线:把用户的查询嵌入,捞最相邻的 top-k 个块,串成 prompt 喂给模型,模型给出回答,把这几个块挂在底下当引用。两次函数调用,加一次向量搜索。
Demo 跑得起来。产品很少跑得起来。最近邻相似度只是「相关性」的一个代理,不是它的测量;嵌入模型是在公开网页上训出来的,会把 苹果园的产量 和 苹果公司的季度财报 混到一起。切块器没有任何信号告诉它句子在哪里收尾、表格在哪里开始。一次检索,根本撑不住一个答案散落在三份文档里的问题。检索一旦失手,模型就在捞回来的那点东西上自由发挥 — 引用是真的,可那段回答,这些引用一句也撑不起来。
1.2 Advanced RAG:在同一条流水线上加启发式
第二种姿态保留嵌入—检索—生成那根主干,在检索那一刀前后各塞一些处理。检索之前的那一类对着查询动手:改写、扩展、分解、HyDE(让小模型先写一个假设性回答,把这个假回答而不是问题去嵌入)。检索之后的那一类对着候选动手:用 cross-encoder 重排,把查询和段落放在一起打分而不是分开嵌入;去重;按元数据过滤;把上下文压缩一下。
这些收益不算小。一个 bi-encoder 检索器顶上挂一个 cross-encoder 重排,top-5 相关性通常能从 50–70% 那一档跳到 75–90%。查询改写在原话歧义重的场景里,再加 5 到 10 个点。现在生产里挂着「RAG」这块牌子的系统,大多就跑这套架构;对相当大一类企业场景 — 内部文档问答、客服分流、知识库搜索 — 这就是该投到的那一档。它给不出的,是灵活性。每一条查询,都要走同一条流水线。
1.3 Modular RAG:可组合的组件、显式的路由
到 2024 年,研究和工具链都收敛到了 Modular RAG 这里。同一套技术还在,只是被拆成一颗一颗可换的组件,流水线在每一次请求时按需拼出来。一个路由器决定调哪些检索器 — 也许是稠密向量索引,也许是 BM25 索引,也许是某张 SQL 表,也许是某个外部 API — 结果再融合,通常用 reciprocal rank fusion。重排器按查询类型选;生成器按要的质量档位选。整条架构从一根线变成了一张组件图。
两个实际的后果。一,这个系统真的可测了 — 每一颗组件都能独立评测、独立替换。二,这个系统按查询类别可调:一个事实问询走快检索器加小生成器,一个跨文档综合走多检索器加大生成器,两者从同一座组件库里取件。代价在运维上。一旦答案错了,「错在哪一步」这个问题现在有很多种可能的答案,团队就得有能把锅落到某一颗组件上的可观测性。在上模块化架构之前,先把这套可观测性做起来,而不是反过来。
1.4 Agentic RAG:让 LLM 自己跑这条流水线
第四种姿态把前三种悄悄共享的那个假设翻了过来 — 那个假设是,LLM 是最后一步。在 Agentic RAG 里,LLM 自己跑 这条流水线。给它一份工具目录(向量搜索、SQL、抓网页、重排、计算器),模型想一想,挑一件工具,看一眼结果,再想一想,直到有答案或者撞到步数上限。架构不再是一条流水线,而是一个小程序,模型为每一次查询现写一份。
买到的是多步规划、动态选工具、planner/retriever/critic/writer 这一类多智能体协作。付出的是延迟、token 花销、可复现性 — 一次查询不再是固定序列,而是一棵决策树;病态查询能在出答案之前空转许多轮。生产里跑 agentic 的系统,要有预算控制、步数上限、超时策略,这些是固定流水线根本不必想的。该用 agentic 的场景,是深度参差不齐、不可预测的那种问题:研究综述、法条检索、文献回顾。不该用 agentic 的场景,是稳定不变的客服机器人 — 这种负载本来不需要那个循环,加上去只是多一层方差。
1.5 RAG 与微调
每个团队迟早都要问的那个问题。诚实的说法是,它们解决的不是同一个问题。RAG 解的是知识问题 — 模型不知道 X,X 还在变,用户要的还是带出处的答案。微调解的是行为问题 — 模型知道答案,可格式不对,不按公司模板走,该简短的地方絮叨。RAG 上手便宜,每次查询贵;微调一次性贵,每次查询便宜。RAG 迭代以分钟计(换一份文档);微调迭代以天计。一条好用的启发式:失败是「模型不知道」,伸手够 RAG;失败是「模型知道但做得不对」,伸手够微调。成熟的系统往往两样都做,但起手先做 RAG — 企业里绝大多数翻车,是知识翻车,不是行为翻车。
第 1 章接下去会怎么走
四种 RAG 架构,不管挑哪一种,它能走多远都被一件事卡死:它能多好地读懂它的源文档。一个最先进的 Modular 流水线挂着 agentic 调度器,顶上跑的还是某一步解析器吐出来的那一堆块。如果那一步把表格结构丢了、多栏阅读顺序串了、图说替成了乱码 OCR,下游每一颗组件都在错的输入上推理。架构定的是天花板。解析器定的是地板。在大多数生产系统里,地板更要紧 — 因为大多数生产系统离天花板还远着。
明天 — 第 2 章:智能文档解析。为什么一个朴素的 PDF-to-text 工具会悄悄毁掉检索质量、版面感知的解析器到底保住了什么,以及那一条让模型直接读页面图像的多模态替代路。
