SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

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

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

寓言

货运公司的两种全包价

两家物流公司同时给一家工厂报了全国配送服务。甲公司的全包价含干线运输、中转分拣和末端派送,连退货逆向物流都算进去了。乙公司的全包价只含干线运输和城市分拨中心,最后一公里要工厂自己解决。两家在报价单上都写的是全国配送。

工厂的采购选了乙公司,因为报价低了四成。第一批货发出后,到了目的地城市分拨中心就停了。工厂打电话问客户收到没,客户说没收到。再问乙公司,乙公司说合同里的全国配送指的是送到城市分拨中心,最后一段要另外签补充协议。

工厂急了,拿乙公司的报价单去对甲公司的报价单。同一个全国配送四个字,甲公司的服务边界写了三页纸,乙公司只写了半页。价格差四成是因为服务范围差了一半。工厂在合同补签上多花了两个月和一笔预算外支出。

采购部后来定了一条死规矩:任何报价单里的服务名称必须附带一张布尔矩阵表,逐项打勾合同覆盖范围。干线、中转、分拣、末端派送、逆向、保险、异常件处理,七项各自打勾。叫不叫全国配送不重要,七行勾才决定合同到底买了什么。

这件事在工厂供应链圈子里传得很开。后来有人总结了一个规律:当两个供应商用同一个名字报价的时候,别急着比价格,先比他们各自对这个名字的定义边界。名字越短、越通用,边界就越容易出现差异。

工厂后来把这条写进了招标文件的模板:凡是技术术语类的服务项,投标方必须在报价单附一份术语定义表,列出该术语在他们理解中包含和不包含的子项。不交定义表的报价视为无效。这张表后来每年帮工厂省下的合同纠纷成本,远超当年那笔末端的补签费用。

后来采购部把新旧两套标签贴在同一排货架上:旧标签说明原来的取货流程,新标签说明升级后的检索和校验规则。仓库名可以相近,出货规矩必须写清楚,否则工人会按旧单走新货。

检索增强生成(架构层)

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

检索增强生成(系统层)

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

故事对应

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

落到 Agent 项目里

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