一个 RAG 系统回答错误时，原因可能完全不同：源文档没有更新，解析器丢了表格，切分破坏了上下文，检索没有找到证据，重排序把正确内容排到后面，生成模型忽略证据，或者前端没有把引用呈现清楚。
因此，RAG 团队不能只围绕“会不会调提示词”组建。它更像一支小型搜索与知识产品团队：每个人负责链路的一部分，但所有人共享同一套真实问题、证据和失败记录。
## 从链路而不是职位名称开始
经典 RAG 研究把参数化生成模型与外部检索器结合：先从知识库找到相关内容，再让模型根据检索结果生成答案。生产系统通常还会加入解析、元数据过滤、混合检索、重排序、引用、权限与缓存。
组建团队前，先画出自己的链路，并在每个节点写出输入、输出、负责人和可观测指标。小团队里一个人可以承担多个角色，大团队也可能把一个环节拆成多个岗位。关键不是凑齐职位，而是每类失败都有人能定位和修复。
## 角色一：领域负责人定义“什么才算对”
领域负责人可能来自产品、业务或知识运营。他要确定目标用户会问什么，哪些来源是权威的，答案必须包含哪些证据，什么时候应该承认不知道，以及哪些信息已经过期。
这个角色最重要的产物不是需求文档，而是一组带答案依据的真实问题。若团队没有领域判断，只能让另一个模型给答案打分，评测很容易变成语言流畅度比赛。
领域负责人还要维护知识源清单：每个来源的拥有者、更新时间、覆盖范围和替代关系。RAG 无法从不存在或已经失效的资料中检索出正确答案。
## 角色二：知识与数据工程负责“证据能否进入系统”
知识工程需要处理网页、PDF、扫描件、表格、图片和内部系统导出。工作包括采集、解析、去重、版本化、切分、元数据和增量更新。
这个环节常被低估。解析器如果把标题和正文分开、把表格行序打乱，后面的嵌入和模型再强也无法恢复原始语义。团队应保存原文件、解析结果和切分结果之间的可追溯关系，让每段证据能回到原文位置。
更新机制同样重要。删除或修订的文档必须能从索引中同步撤回，不能只会不断追加。否则系统会同时检索到新旧两个版本，并给出自相矛盾的答案。
## 角色三：检索工程负责“正确证据能否被找到”
检索工程师设计词法检索、向量检索、混合召回、过滤与重排序。他需要理解用户查询如何表达、文档如何切分，以及哪些元数据能缩小搜索空间。
检索不能只看最终答案。应先单独测 Recall@k、MRR 或 NDCG，检查必要证据是否进入候选集、排序是否足够靠前。BEIR 等基准展示了不同检索方法跨领域迁移的差异，但企业仍要建立自己的查询和证据对。
如果用户问题包含多个条件，单次向量相似度可能不够。系统可以先改写查询、拆分子问题，或用关键词与向量混合召回，再由重排序模型压缩候选内容。每增加一层，都要证明它改善了哪类失败，而不是只让架构更复杂。
## 角色四：模型与应用工程负责“证据如何变成可用回答”
应用工程把检索结果组织成模型上下文，设计回答格式、引用、工具调用、拒答和多轮交互。它还要处理流式输出、超时、缓存以及用户界面中的证据跳转。
上下文并非越长越好。“Lost in the Middle”研究发现，相关信息位于长上下文中间时，模型利用能力可能下降。因此应用工程应控制候选数量、去除重复、保留标题和来源，并测试证据顺序，而不是把所有文档塞进窗口。
生成端至少要区分三类问题：检索到了正确证据但模型没用；证据不足却强行回答；回答基本正确但引用定位错误。三类问题需要不同修复，不能都归结为“再调一下提示词”。
## 角色五：评测负责人把失败变成可重复实验
RAGAS、RAGChecker 等工作都强调分别评估检索与生成。评测负责人应维护固定测试集、评分规则、人工复核样本和回归报告，并把错误拆成可行动类别。
一个实用测试集要包含直接事实、跨文档综合、时间敏感、无答案、歧义问题、错别字和多轮追问。每条样本都记录必要证据，而不只是最终短答案。
自动指标适合快速回归，但模型评分器也会偏好某些表达。重要版本仍需人工盲评，并检查指标与用户反馈是否一致。若离线分数提高、真实用户却更常点开错误引用，说明评测目标需要调整。
## 角色六：平台工程负责让系统可运行、可回退
生产 RAG 需要记录查询、检索候选、重排序、模型版本、提示版本、延迟、词元和错误。平台工程还要负责容量、缓存、索引发布、灰度和回退。
日志应能回答：某条错误答案用了哪版文档、哪版索引、哪组提示和哪个模型。缺少这条链路，团队只能在当前系统上猜测过去发生了什么。
敏感资料还需要在检索前执行访问范围过滤，不能先把无权查看的内容送进模型，再依靠提示要求它不要泄露。这里的重点是系统边界清晰，而不是让语言模型承担权限判断。
## 用共享工件连接不同角色
跨职能团队最容易出现“数据说解析没问题、模型说检索不行、检索说问题定义不清”的循环。解决办法是围绕共同工件协作。
第一份工件是知识源登记表，记录来源、版本和负责人。第二份是黄金测试集，连接用户问题与必要证据。第三份是一次完整运行轨迹，保存每个阶段输入输出。第四份是失败分类账，记录问题、归因、修复和是否回归通过。第五份是发布说明，写明本版改变、指标、已知限制和回退条件。
这些工件让讨论落到证据上。领域负责人可以指出正确来源，检索工程师可以看到候选排序，应用工程师可以复现模型上下文，平台工程师可以定位版本。
## 分阶段组建，而不是一次把团队配满
探索阶段可以由领域负责人、全栈或应用工程师、数据检索工程师组成小组，先完成一条端到端窄任务。第一目标不是做漂亮聊天界面，而是让 100 个代表性问题能够被追踪和评估。
进入试点后，再补强评测、知识运营和平台能力，建立增量索引、观察面板、人工反馈和回退。使用范围扩大后，才根据真实瓶颈拆分解析、检索、模型、平台或体验岗位。
每周评审不应只看总正确率。可以选择本周最常见的五类失败，逐条查看原文、解析片段、候选结果和回答，然后决定下一轮只改一个变量。这样能够避免多个团队同时修改链路，导致无法归因。
## 常见的团队建设误区
第一个误区是先选向量数据库，再寻找问题。工具不能代替知识源、用户任务和评测定义。第二个误区是设立“提示词专家”，却没有人对解析和检索负责。第三个误区是只看最终回答，把检索缺失和生成臆测混成一个分数。
第四个误区是把文档导入当成一次性项目。知识会更新、撤回和冲突，需要持续运营。第五个误区是没有版本和回退，任何优化上线后都无法解释变化。
## 结语：团队结构应映射到失败结构
RAG 的工程价值来自把外部证据带入生成过程，但它也因此成为一条多阶段链路。有效团队不是岗位越多越好，而是知识、检索、生成、评测和运行责任没有空白。
先用小团队完成可测的垂直切片，再根据失败数据扩充角色；用共同测试集和运行轨迹连接每个人。这样建设出来的不是一套演示，而是一项能持续修正、升级和解释的知识服务。
## 参考资料