一个销售在系统里问了一句"这份合同的付款条款是什么"，答案背后其实有一条很长的链路：文件要先被找对，找到的段落要排出优先级，模型才能基于这些内容作答，而且必须说清楚这句话是从哪一段抄来的。企业级检索增强生成，简称RAG，表面看是给大模型接上一个知识库，实际上是把知识源、权限、召回、排序、生成和引用重新组织成一条可以逐段测试的流水线。这也是Cohere把Embed、Rerank和Chat做成配套组件，而不是单一模型的原因。
从一句提问到一段引用：链路上的四个责任人
企业内部的问题往往不是问给模型的，而是问给某一份文件的。文件本身要先被解析和切片，长合同、产品手册、政策文档被拆成若干段落，这一步决定了后面所有环节能看到什么颗粒度的信息。切片完成后，每一段文本要被转换成向量，这就是Embed承担的工作：Cohere区分了文档段落和用户查询两种不同的嵌入输入类型，用向量相似度做第一轮召回，把可能相关的段落先捞出来，这一步追求的是覆盖面，而不是精确排序。
召回结果往往是一批候选，谁排在前面直接影响模型看到什么。这就轮到Rerank，它接收查询、候选文档和需要返回的数量，输出重新排序后的结果、每条结果的相关性分数，以及它在原始召回结果里的位置。这个分数不是装饰，它让工程团队能够设定阈值，过滤掉相关性太低的段落，避免模型在弱相关信息上生成似是而非的回答。
最后一步落在Chat。它接收检索到的内容作为上下文，生成回答，同时可以返回引用范围和对应的文档标识，方便审核人员回看这句回答具体依据哪一段原文。整条链路里，Embed负责"找得到"，Rerank负责"排得对"，Chat负责"说得清并留痕"，三者的责任边界清楚地划开，这也是把RAG当作可测试系统而不是一次性演示的前提。
权限和更新：模型看不见的那道墙
企业场景和公开问答最大的差异，不在于模型能力，而在于谁能看到什么。同一份薪酬政策，HR和普通员工能读到的版本可能不同；一份还在审批中的合同草案，可能只有特定团队有权限查看。这类访问控制必须在检索层完成过滤，也就是说，进入Embed和Rerank流程的候选集合本身就应该已经是权限允许范围内的文档，而不是指望模型在生成阶段自己判断"这段内容你不该看到"。把权限判断留给生成模型，本质上是把安全责任交给了一个不具备权限系统上下文的组件，这在企业实施里是需要提前堵住的漏洞。
文档更新和删除同样如此。一份政策文件被修订后，旧版本的向量索引如果没有同步失效，员工问出的答案就可能建立在过期资料上，而引用标识虽然能告诉审核者答案来自哪一段，却不能替代索引层面的及时清理。这意味着企业在部署RAG时，需要为知识库设计明确的更新和删除传播机制，让检索层始终反映当前有效的文档状态，而不是把这个问题留到出现错误答案之后才发现。
检索、重排、生成与引用组成完整 RAG 工作链
验收不是一次通过，而是分段打分
一条RAG链路是否可用，不该用"回答听起来对不对"这种主观感受来验收。比较扎实的做法是分别针对召回、排序、回答质量、引用准确性、延迟和成本设置独立的评估指标，用一批离线问题集提前跑通每一段的表现------召回是否找到了正确的候选文档，重排是否把最相关的段落推到前面，生成的回答是否忠实于给定资料，引用是否指向真正支撑答案的段落。这些指标各自独立，一个环节表现好并不代表整条链路都可靠，比如召回覆盖率很高但排序错乱，模型依然可能被无关信息带偏。
回答质量之外，企业还要验证权限、成本和回退
对于正在评估企业级知识问答系统的技术负责人而言，这套拆解思路比追问"这个模型准确率多少"更有实际意义，因为准确率本身是召回、排序、生成、引用四道关卡共同作用的结果，任何一环出问题，都会体现在最终答案上，却未必能一眼看出问题出在哪一层。Cohere把Embed、Rerank和Chat作为可以分别调用、分别评估的组件提供给企业，也是为了让这种分段验收在工程上成为可能，而不是把一整套流程封装成一个不透明的黑箱交给企业照单全收。