未来 — 分清架构转变与本周风味
这一章讲三件事: 每周都有新技术、新论文、新厂商公告砸过来,怎么分清 「有意义的架构转变」与「本周风味」(书里给的分辨框架); 书里点名的五个趋势各改什么——检索、agentic 化、数据在哪、窗口多长、合规怎么管; 以及全书收尾的那个落点:你在建的到底是搜索引擎,还是「企业的大脑」。 本章的地基句:「RAG 的未来不在某个算法——它在软件从『我们使用的工具』 到『我们协作的智能』的转变里」1。
1. 顶层全景:同一个问题,两代 RAG
作者先把过去九章收拢成一句话:一个能跑的验证原型一个周末就能搭出来, 但从本地脚本到「韧性生产系统」之间才是真工程——延迟、规模化精度、长期可维护2; 安全是纵深防御(脱敏、权限、审计三件套),成本与团队是另外两座山3。 然后话锋一转:生成式 AI 的地面每周都在动,所以这章只做一件事——把信号从噪声里分出来, 而且作者自己先给全章打了预防针:预言很难,尤其关于未来(他引了物理学家玻尔的自嘲)4。
分辨的工具就是一条主走查。书里自己给过多跳查询的例子,拿它当输入, 看它在「今天的一次检索」和「下一代管线」上分别怎么走:
查询:「Q3 报告里提到的那个供应商,和法务合规文档里列的风险因子有什么关联?」
今天的一次检索(第 11 章说的「架构局限」):
查询 ──→ 向量检索一把 ──→ top-k 里两堆块:Q3 报告的、合规文档的
「供应商 ↔ 风险因子」中间那座桥,不在任何一块里
──→ 模型要么编一座桥(幻觉),要么说「I don't know」
下一代管线(System 2),下面五节各占一步:
② LLM 拆计划:先查 Q3 报告抽出供应商名 → 再拿名字查合规文档(§3)
③ 发现缺口:合规文档躺在法务保险库里,搬不进向量库
──→ 联邦检索:数据不动,把查询发过去(§4)
④ 遗留系统只会关键词搜索,返回垃圾 → 瓶颈=给遗留系统的检索做现代化(§4)
⑤ 图检索:供应商节点沿边走到风险因子节点,路径直达(§2)
⑥ 检回的不再是碎片段,而是整章叙事块;RAG=决定什么值得模型专注的过滤器(§5)
⑦ 全程写进不可变审计日志:哪句 prompt、哪个文档版本、哪些引文(§6)
图说:同一个问题,一次检索死在「桥不在任何一块里」;下一代管线的每一步, 就是本章的一个趋势。走查里的场景串是书里的原文例子,不是我们编的5。
2. 核心原理(一):检索的四个演化方向
作者的判断:检索层不再是「够用就行」的静态零件,它正从「还行的检索」走向 「高精度仪器」6。四个方向,每个都该在你评估新工具时拿出来对号:
| 方向 | 是什么 | 代价 |
|---|---|---|
| late interaction(后期交互)嵌入 | 不把整块压成一个向量,像 ColBERT 那样每个词都留一个向量,把「算相似」推迟到查询那一刻——匹配更细 | 存储约 50 倍,查询时要做的计算也显著变多7 |
| 能听指令的重排器 | 重排器(把候选重新排序的模型,第 08 章)整体更准,而且能接受自然语言指令,按法律、医疗这类领域的口径排 | 重排本身就有延迟税(第 09 章) |
| 原生多模态检索 | 不再「图转文字再索引」,而是把多模态数据直接嵌进与文字同一个向量空间;ColPali 把 late interaction 用到视觉小块上 | 第 14 章讲过的模态对齐账 |
| 图检索自动化 | 建图、扩图的工具越来越自动,多跳问题(「Q3 供应商与合规风险因子的关联」)由图接管 | 第 15 章的警告还在:只适合稳定高价值的结构化知识8 |
前两个方向是「把第 04、08 章的零件换强」,后两个是「把第 14、15 章的进阶方向补进检索层」。 注意主走查第⑤步:那条「供应商走到风险因子」的路径,向量搜索原理上给不了, 只有图能给——这正是第 15 章说「找相似换成走路径」的延续9。
3. 核心原理(二):从 System 1 到 System 2 —— agentic 转移
现象先摆出来:主走查里那个问题,今天的管线为什么死?因为一次检索是「快而直觉」的—— 书里借心理学的说法叫 System 1:不假思索、一条线走到底、一把出结果。很多用例这样就够了, 但「多走几步才够」的问题会难住它10。
下一代的走向是 System 2:系统不只检索,还会迭代(跑一遍、看结果、修正、再跑) 地规划、推理、编排工具。LLM 的位置整个变了:从管线末端那个写答案的总结员, 变成controller(控制器)——它把模糊的请求拆成具体计划,用工具调用分步执行, 还会回头审视自己拿到的结果够不够用11。
主走查第②步就发生在这里:LLM 把「供应商与风险因子的关联」拆成 「先查 Q3 报告抽出供应商名 → 再拿名字查合规文档」两步,每步一次工具调用。 对比一次检索的死法:标准管线检索不到时只会幻觉或说「I don't know」, agentic 管线检测到缺口,改写查询再搜,反复直到找齐12。 书里给这一步的判词是:RAG 从「搜索引擎」变成了「推理引擎」13。 而且工具不只是取数据,还能做事——同一个客服 bot,答完问题还能顺手开工单、改工单优先级14。
然后是账单,书里管它叫工程税(从演示到生产要多付的那部分工程成本), 第 13 章已经逐条拆过,这里按本章视角归拢15:
| 税项 | 书里的数 |
|---|---|
| 可观测缺口 | 调试要追踪「多步推理 + 工具调用 + 自我反思」的整条轨迹,不再是单次检索 |
| 延迟与成本 | 从前两秒出答案的查询,现在可能要三十秒往上 |
| 失控风险 | 要上确定性的硬护栏:迭代次数上限、预算上限,防 agent 收不了敛的「失控循环」 |
一句话收束:agentic 转移的本质是自主与控制的权衡——用例面变宽了, 但生产环境要求的基础设施也更成熟16。主走查走到第②步,下一站是第③步: 发现要查的文档根本搬不进来。
4. 核心原理(三):数据重力与联邦检索
现象:企业上了 agentic AI 之后撞上的第一堵墙不是模型,是数据自己有「重力」—— 数据重力(data gravity):数据量越大、治理约束越多,就越挪不动17。
书里把「把企业数据全索引进向量库」直接判为幻想:财务数据在 Snowflake 里, 客户日志在 Elasticsearch 里,法规文档躺在专门的法务保险库;把 PB 级的、 带治理状态的活数据搬进 RAG 存储不只是工程噩梦,搬不好直接合规违规18。
所以方向反过来:联邦检索(federated retrieval)——数据留在原地, 把查询送到数据那边去。agentic 系统用工具(直接调,或经 MCP 服务器) 在源系统的原生环境里查,比如在数据仓库上执行 SQL。主走查第③步: 「合规文档在保险库里」被检测到,查询被发过去,而不是文档被搬出来19。
但联邦检索引入一个关键依赖:你的答案质量,现在受制于外部系统自己的检索能力。 如果 agent 通过工具调用查的是一个只会关键词搜索(BM25)的遗留文档库, 检回来一堆无关结果,agent 再聪明也只能在这些垃圾里打转——主走查第④步卡在这20。
于是书里给出一个有点反直觉、但工程上很老实的结论:联邦检索要成功, 需要的不是更聪明的 agent,而是给遗留系统的检索做现代化——把语义理解、 混合搜索、重排、text2SQL 这些本书前几章的东西,装进那些老系统里去21。
5. 核心原理(四):长上下文与边缘 —— RAG 换工作,再搬到数据边上
5.1 「窗口都百万 token 了,还要 RAG 吗?」
这是第 02 章埋下的问题,本章正式作答。书里的答案分两半:辩论本身就不该是 「RAG 对长上下文」的二选一,未来是context-aware RAG(知道上下文够不够用的 RAG); 长窗口不杀 RAG,反而让它变强——RAG 从「往 4k 窗口里塞碎片段的小工」, 升级成高精度过滤 器:喂给模型的不再是零散块,而是更大、更连贯的整章「叙事块」, 模型保得住整章的上下文,又还享受检索带来的省钱与降噪22。
为什么过滤器不可省?三个约束在窗口再大时也还在23:
| 约束 | 书里的量级 |
|---|---|
| 成本 | 每条查询都处理一千万 token,高流量场景烧不起——对照:GPT-3 时代窗口才 2048,十年涨了四个数量级,但「贵」跟着窗口一起涨24 |
| 延迟 | 让模型每答一句简单问题前先「读」六十秒文档,用户等不了23 |
| lost in the middle | 埋在大上下文中间的细节,模型就是不容易注意到(第 03 章讲过)——而且窗口再大,也装不下整个企业25 |
所以每条 RAG 查询的本质都是同一个动作:把海量企业数据过滤成一份能舒服塞进 窗口的「短名单」。书里给这个动作起了名字——context engineering (上下文工程):动态组装那条完美 prompt,把检索到的事实、用户历史、系统指令 配成一套,在压住成本与延迟的 前提下最大化准确率。判词是本章最值得背走的一句: RAG 变成了长上下文 LLM 的注意力机制——决定什么值得模型昂贵的专注26。
大窗口还解锁了一个新形态:proactive RAG(主动式 RAG)。系统把用户的整个 数字环境当作 prompt:静默观察屏幕、最近的日志、打开着的文档,在用户开口之前 就 implicit 地理解意图。书里的例子:客服人员刚打开一张「液压泵坏了」的工单, 系统实时分析屏幕,在他还没打字时就把泵的图纸和最近三张相似已解决工单 摆在侧栏里。判词:「主动式 RAG 不等着被问,它在需要的那一刻就把答案给出来」27。 书里自己也在脚注里承认了代价:隐私、持续同意、本地还是云处理——这些挑战一点不小28。
5.2 RAG at the Edge:小模型把引擎搬到数据边上
第二个老问题也换了解法。从前建高质量 RAG 是二选一:用公有云 API(牺牲数据隐私), 或者自养一大片 GPU 集群(基础设施门槛吓退大多数人);air-gapped(物理断网的内网部署) 一直可行,但代价只有 大厂付得起29。
SLM(small language model,小语言模型:通常小于 32B 参数、小到 4B/8B 的 高效模型)改变了这本账——用「远超体重级别的输出」换掉规模,让「local-first」 (数据与推理都在本地)的 air-gapped RAG 不再需要数据中心级硬件30。 三个优势,书里逐条给了理由31:
| 优势 | 为什么成立 |
|---|---|
| 生产就绪、好托管 | 生成步从「黑盒 API」变成可预测的软件组件:跑在普通硬件上,能跟着应用一起进 CI/CD 版本化、测试、发布,外部 API 停服或限流引发的级联故障直接消失 |
| 把引擎搬到数据侧 | 医疗、国防、金融里,把敏感 PII 或 IP 发给公有厂商经常是想都不用想的「不行」;SLM 让企业把推理引擎送进数据所在的边界内,敏感文档永不出库——很多卡死在 POC 阶段的隐私合规死结就此解开 |
| 改写经济模型 | 从「按 token 计价的可变成本」换成「硬件一口价」;高流量场景总拥有成本可能降几个数量级 |
书里补了两笔:这笔记账对多模态 RAG 更要紧(视觉模型的 API 账单与传输延迟都更凶, 本地多模态 SLM 一成熟,采用会加速);本地推理还省掉了网络往返,延迟直接受益32。 收束一句:SLM 越强,RAG 能进的使用场景越广——连强隐私、强延迟、高可用要求 最苛刻的那批也进得去33。主走查第⑥步:那份法务文档从检索到生成, 全程可以不出内网。
6. 核心原理(五):治理变成设计输入 —— 与「企业的大脑」
最后一节回到第 04 章那堵墙:POC 走向生产,拦路的往往不是技术, 是治理、风险与合规;而 EU AI Act 这类新监管框架正在把这堵墙从「上线后补课」 变成「设计图上的承重墙」34。书里给的口径是:RAG 系统 必须 compliance-aware by design(合规感知:合规要求作为设计输入参与架构), 三个 POC 里从不会出现的难题35:
| 难题 | 难在哪 |
|---|---|
| 数据主权 | 不能把全球数据倒进一个库;德国员工的查询要路由到法兰克福托管的向量库,数据不能非法出境36 |
| 被遗忘权(GDPR/CCPA) | 从普通数据库删人容易;从编码了文档块的向量库与词法库里删人难——必须能追踪并外科手术式移除每个衍生块,而这要求摄入层就打好元数据标签,因为全量重索引几 TB 不可行37 |
| 可审计与可解释 | 光给答案不够,要能证明答案为什么这么给:不可变审计日志记下「来源链」——那句 prompt、检索到的确切文档版本、作为引文的输出;金融与法律领域,一次幻觉就是真金白银的官司38 |
第 07 章「被遗忘权这个更硬的问题」,答案就落在第二行:删除发生在块这一层, 前提是摄入层当时就没偷懒。监管还改写了开发方式:书里明说,用评测驱动的开发 取代「vibe check」——模型或 prompt 的任何改动,不过自动化评测门 (对着 golden 数据集测忠实度与相关性)就不许上线。治理从一摞静态规则, 变成 CI/CD 管道里一道动态的自动闸门39。
然后是全书的收尾,落点超出了技术清单。开篇说 RAG 是「让模型看见企业数据」的手段, 结尾说:你不再只是在建搜索引擎或聊天机器人,你在建企业的大脑40。 理由是历史账:企业有史以来,制度性知识一直是碎的——锁在在职与离职员工的脑子里, 埋在被遗忘的文件夹里,困在互相不通话的系统里;RAG 管线要做的正是把这堆碎片 统一起来41。下一代系统会从「被动的工具」变成「主动的伙伴」: 不只回答问题,还能连上人眼会漏掉的那些点42。
组件层面,作者的临别嘱咐与第 01 章首尾呼应:核心模式——RAG、工具使用、agent、 知识图谱、评测器——是稳定地基;LLM、向量库、agentic 框架、护栏会一直换。 「不要迷恋栈,专注使命」43。主走查第⑦步在这里收口:那条审计日志里 「prompt + 文档版本 + 引文」的链条,就是「企业的大脑」能被信任的理由。
7. 作者的判断与证据
- 整章自我定位为预测:开头引玻尔「预言很难,尤其关于未来」的脚注, 相当于作者亲手把本章标成「判断,不是事实」4;
- 有书内证据链的:检索 四方向各有前章伏笔(第 04 章嵌入、第 08 章重排、 第 14 章多模态、第 15 章图谱);late interaction 的 50 倍存储写在脚注里, 是可核对的技术事实;工程税的「两秒变三十秒」是量级估计,不是实测;
- 作者明说是预期的(原文用「we expect」):图工具自动化带动图谱采用、 联邦检索成为方向、本地多模态 SLM 采用加速——这三条是下注,不是结论;
- EU AI Act 是真实存在的监管,书里拿它当治理前移的驱动力,属外部事实;
- proactive RAG 的液压泵例子是书里设想的场景,不是实测案例。
判断(我们的,不是书里的): 五个趋势的成熟度并不相同——检索元件升级 (§2)与治理前移(§6)已经在发生,有前九章的工程清单托底;agentic 转移(§3) 有第 12、13 章的工具与可观测清单托底,但税最重;proactive RAG 与边缘 SLM(§5) 最接近「下注」,书里没给任何实测。评估厂商宣传时,建议按这个顺序给信任。 如果错,会错在: 多模态 SLM 的成本曲线下降得比预期快, 边缘 RAG 反而先于「agentic 转移」在企业里铺开——届时 §5 的两条会变成最先兑现的。
8. 边界与局限
- 全章没有代码:前九章每章都有可复现的走查,这章一个 notebook 都没有—— 它是方向判断章,不是实现章;
- 数字全是时点量级:两秒/三十秒、一千万 token、六十秒、4B/8B/32B、50 倍存储, 都该按总纲说的「引方法不引数字」对待;
- ColBERT、ColPali 只给「是什么 、贵在哪」,没有实现细节——要动手, 我们书架另有专书(见总纲 §4 的四书分工);
- proactive RAG 的隐私与持续同意问题,书里只放进了一条脚注28, 正文没有展开成工程方案;
- 「联邦检索要靠遗留系统现代化」指了方向,但没给遗留系统改造的路线图—— 那是数据平台侧的事,我们书架的 rag-ready-patterns 补这一段(总纲 §4)。
9. 可带走的
- 分辨框架:评一个「新方向」,先问它是改了架构,还是只是本周风味; 本章五节就是作者给的五张信任票;
- late interaction:整块一个向量 → 每词一个向量,精度换 50 倍存储—— 选型时这是显式的账,不是黑魔法;
- System 1/System 2:一次检索是快直觉,agentic 是规划推理;LLM 从总结员 变 controller 的同时,把可观测、延迟、失控循环三笔税也带进来了;
- 数据重力:别幻想全量索引进向量库;数据搬不动,就把查询发过去—— 然后把预算花在遗留系统的检索现代化上,而不是更聪明的 agent 上;
- 长上下文的正确姿势:不是「RAG 对长上下文」,而是 context-aware RAG; RAG 的角色变成「决定什么值得模型专注」的过滤器(context engineering);
- proactive RAG:窗口够大后,系统可以在用户开口前就给出答案—— 隐私与持续同意的账单同时到来;
- SLM 三优势:可预测的软件组件、引擎进数据边界、硬件一口价—— 强隐私与高延迟敏感场景的解法;
- 合规三难题(数据主权/被遗忘权/来源链审计)是设计输入,不是上线后补课; 评测门是治理的自动化形态;
- 落点:核心模式是地基,组件会一直换——别迷恋栈,专注使命; 你在建的是企业的大脑。
10. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| POC→生产、纵深防御、TCO 回顾 | Chapter 10. The Future of RAG | text/133-ch10-chapter-10-the-future-of-rag.txt:9(搜「production-grade ecosystem」) · :12(搜「junior analyst」) · :15(搜「total cost of ownership」) |
| 分辨信号与噪声、玻尔脚注 | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:18(搜「flavor of the week」) · :21(搜「separate signal from noise」) · :320(搜「prediction is very difficult」) |
| 多跳查询例子(主走查输入) | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:49(搜「supplier mentioned in the Q3 report」) |
| 检索从「够用」到高精度 | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:28(搜「good enough」) · :54(搜「high-precision instrument」) |
| late interaction、ColBERT、50 倍存储 | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:33(搜「ColBERT」) · :322(搜「50 times more storage」) |
| 能听指令的重排器 | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:37(搜「follow instructions」) |
| ColPali、原生多模态检索 | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:43(搜「ColPali」) |
| 图检索自动化与适用边界 | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:49(搜「ontology and entity resolution」) |
| System 1 → System 2 | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:63(搜「System 1」) · :69(搜「System 2」) |
| LLM 变 controller、缺口重试 | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:72(搜「it is the controller」) · :75(搜「detects the gap」) · :78(搜「reasoning engine」) |
| 工具能行动(工单例) | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:81(搜「support ticket」) |
| 工程税、失控循环 | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:84(搜「engineering tax」;:84,搜「runaway loops」) |
| 自主与控制的权衡 | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:87(搜「autonomy and control」) |
| 数据重力、「全索引」是幻想 | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:96(搜「data gravity」) · :99(搜「often a fantasy」) |
| 联邦检索、受制于原生检索 | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:102(搜「federated retrieval」) · :105(搜「at the mercy」) |
| 遗留系统现代化 | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:108(搜「modernize retrieval in legacy systems」) |
| 长上下文之问、context-aware RAG | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:117(搜「Is RAG really necessary」) · :120(搜「context-aware RAG」) |
| 高精度过滤器、叙事块 | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:123(搜「high-precision filter」) |
| 三个约束、装不下企业数据 | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:139(搜「10 million tokens」) · :145(搜「60 seconds」) · :151(搜「middle of a massive context window」) · :156(搜「difficult to imagine」) |
| context engineering、注意力机制 | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:162(搜「context engineering」) · :165(搜「attention mechanism」) |
| GPT-3 2048、prompt caching 脚注 | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:324(搜「2048」) · :326(搜「prompt caching」) |
| proactive RAG、液压泵例 | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:181(搜「entire digital environment」) · :184(搜「proactive RAG」) · :187(搜「hydraulic pump」) · :190(搜「does not wait to be asked」) |
| proactive 的隐私脚注 | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:328(搜「continuous consent」) |
| SLM 定义与 local-first | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:201(搜「air-gapped」) · :204(搜「32B parameters」) · :207(搜「local-first」) |
| SLM 三优势 | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:213(搜「predictable software component」) · :218(搜「commodity hardware」) · :224(搜「reasoning engine to the data」) · :235(搜「flat fee」) |
| 多模态经济账、网络往返 | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:240(搜「multimodal RAG」) · :245(搜「network round trips」) · :250(搜「broader set of use cases」) |
| GRC 墙、EU AI Act、三难题 | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:259(搜「EU AI Act」) · :262(搜「compliance-aware」) |
| 法兰克福路由、被遗忘权、来源链 | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:268(搜「Frankfurt」) · :274(搜「right to be forgotten」) · :280(搜「chain of provenance」) |
| 评测门取代 vibe check | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:285(搜「evaluation gates」) |
| 企业的大脑、别迷恋栈 | 同上 | text/133-ch10-chapter-10-the-future-of-rag.txt:297(搜「corporate brain」) · :303(搜「proactive partners」) · :306(搜「attached to the stack」) · :309(搜「an intelligence we collaborate with」) |