← 返回概念辨析

Concept Contrast Fable

检索增强生成的两个名字:同一个概念,两套口径

在技术方案和采购文档里,检索增强生成经常出现不同的命名方式和边界定义。有人把它理解成一种模型架构设计模式,有人把它理解成一个包含检索、排序、拼接和生成的完整产品系统。名字一样不代表边界一样,签约前没对齐,项目中途会因为边界理解不同翻车。

寓言

货运公司的两种全包价

两家物流行同时给一家工厂报全国配送。甲行的全包价含干线、中转、分拣、末端派送,连退货也算进去;乙行的全包价只含干线和城中分拨。报价单抬头都写得响亮,细字却藏在页脚。

采购看见两张报价单都写“全国配送”,便选了便宜四成的乙行。第一批货到了目的地城的分拨院就停下,客户迟迟收不到。销售以为路上堵车,仓库以为客户没签收,没人知道边界已经断在城门口。

工厂追问,乙行说合同里的全国配送是送到分拨院,最后一段要另签补充单。采购拿甲乙两张报价比,才发现同一个名字下面,服务边界差了一半。便宜不是白来的,少掉的环节会在交付时讨回来。

工厂为补签多花两个月,还赔了一笔延误费。老板没有只骂采购,而是让所有人把报价里的短词拆开看:干线、中转、分拣、末端、逆向、保险、异常件处理,每一项都要打勾。

第一次修补只要求供应商写“包含服务”,仍不够。有人把偏远镇算例外,有人把破损退回算另付。老板改成边界清单,凡是货物会经过的节点、会遇到的异常、会产生的责任,都必须写在同一张纸上。

后来再招标,任何服务名称旁边都必须附边界清单。叫法可以相同,勾选范围不能含糊;若投标方不交清单,报价视为无效。这条规矩很快救了几次险:有供应商名头大,却漏掉偏远镇;有供应商报价高,却把退货和异常赔付都包进去了。

采购部学到,名字相同不代表买到同一件事。越常见、越短的术语,越要把边界摊开;否则省下的价格,会在交付时变成更贵的补课。

后来工厂内部也禁用含糊口头话。凡说“全包”“一站式”“全国”这些词的人,都要在旁边补一张边界表。采购不再被熟词安抚,反而先怀疑熟词背后有没有两套口径。省心,从来不是省掉确认。

检索增强生成(架构层)

一种将外部知识检索与语言模型生成结合的技术架构模式,核心是让模型在生成时引用检索到的相关文档,关注的是架构层面的设计原则。

检索增强生成(系统层)

一个完整的RAG产品或系统实现,通常包含文档解析、向量化、检索、重排序、拼接策略和生成等端到端组件,关注的是产品功能和交付范围。

故事对应

  • 两家都用全国配送但服务范围不同:同一个概念名称下架构层和系统层的边界差异
  • 甲公司含干线中转末端全部环节:RAG作为完整系统,包含全部子组件
  • 乙公司只到城市分拨中心:RAG作为架构模式,不含某些工程化组件
  • 七项打勾矩阵表:签约前用布尔清单对齐定义边界
  • 术语定义表变成招标模板:组织级经验——同一个术语在采购前先定义子项边界

落到 Agent 项目里

在方案或合同中出现RAG这个词的时候,附带一张组件清单:文档解析、Embedding、向量库、检索策略、重排序、prompt拼接、引用标注、缓存、监控,每项标注由谁提供、谁负责。名字本身不解决交付边界问题,打勾的组件清单才能帮你算清成本、工期和运维责任。