RAG聊天机器人上线前检查清单：六个关键维度

RAG聊天机器人不是简单地把向量数据库挂在提示词后面——它是一条完整的数据管线。真正决定用户体验的，是每一个环节能否在上线前经受住测试：源文档准备、检索质量、答案落地、权限控制、兜底行为。原文作者来自一家AI开发公司，基于实际交付经验整理了一份面向首次生产发布的检查清单。

RAG聊天机器人上线前检查清单

一、从有边界的用例开始

在动工之前，先把三件事写清楚：谁用这个助手、它该回答什么问题、它被允许检索哪些来源。

原文给了一个很实用的判断标准：「回答当前产品手册相关的问题」是可测试的，「了解公司的一切」则不是。这看起来像是常识，但大量RAG项目恰恰死在起点——用例定义过于宽泛，导致评估无从下手。

第一版建议只选择一个团队、一两个可信来源。这样做的好处是评估范围可控，也降低了不相关信息或受限内容被混入检索结果的风险。边界先收窄，后续再扩展，比一开始就贪大要务实得多。

二、文档准备：切块之前先做减法

创建embedding之前，文档层面有几项必须完成的清理工作：

删除重复和过期文件——这是检索噪声最常见的来源
保留标题、章节名、日期、来源URL作为元数据
按有意义的章节切分，而不是纯粹按字符数切割
每个chunk保留可追溯的源引用
定义两份文档冲突时的处理规则

原文特别指出，不存在通用的正确chunk size。不同切分策略需要用真实用户可能提出的问题来测试。这一点值得展开：很多团队在chunk size上纠结很久，却从未用真实问题验证过切分效果，本质上是在用直觉替代评估。

Embedding（向量化） 是把文本转成高维数值向量的过程，语义相近的文本在向量空间中距离更近。文档必须先被切成 chunk 再送入 embedding 模型，因为模型有输入长度上限，且过长的文本会让单一向量难以精确表达其中多个主题。Chunk size 正是这一环节的核心参数：太小会丢失上下文导致检索到的片段无法支撑完整回答，太大则会稀释语义、降低召回精度。常见做法是配合重叠窗口（overlap）保留跨块语义，并通过真实问题验证切分效果，而非依赖默认值。

三、检索和生成必须分开测

这是整份清单里方法论价值最高的一条。

做法是：建一个小型评估集，包含贴近真实场景的问题；对每个问题标注「正确的来源段落应该是什么」；先单独检查检索器有没有召回那段证据，再去评估模型措辞。

评估集要覆盖几类边界情况：改写问法、需要组合两个事实的问题、包含拼写错误的查询，以及没有任何来源能回答的问题。最后这类尤其容易被忽略，但它决定系统是否会编造答案。

原文有一句判断值得记住：一个基于错误段落生成的流畅回答，依然是失败结果。把检索质量和语言质量解耦评估，才能定位问题究竟出在哪个环节。

检索器（Retriever） 负责从向量库中召回与查询最相关的 chunk，而 生成器（Generator） 负责基于召回内容组织语言作答。二者失败模式完全不同：检索失败表现为「找不到正确段落」，生成失败表现为「段落对了但答非所问或编造」。评估检索质量常用 Recall@k（前 k 条是否包含正确来源）和 MRR（正确来源的排序位置）；评估生成则通常看答案与来源的一致性、忠实度（faithfulness）。把两组指标合并成一个总分，会掩盖真正的瓶颈所在。

四、要求提供证据，并允许安全地说「我不知道」

把检索到的上下文传给模型时，需要明确的指令：必须基于该上下文作答，上下文不足时如实说明。条件允许的话，在答案旁展示对应的文档或章节，让用户可以自行核实。对于模糊或高影响的问题，需要保留转接人工的通道。

原文也提醒了一个容易犯的错误：不要假设提示词本身能保证正确性。必须保留审查失败案例的机制，并据此更新检索系统或源材料。

五、权限与时效性检查

这条在技术上最容易被低估。聊天机器人绝不能向无权访问的用户泄露文档内容——权限规则必须施加在检索环节，而不是只在UI层过滤。仅在界面做拦截，检索层仍然可能召回受限内容，这在安全审计中站不住脚。

还需要明确：文档更新、删除、权限变更后，索引如何同步反映，并且这条流程要经过测试。

对于首次发布，原文建议采用只读访问——相比允许助手修改记录或触发操作，只读模式的控制面要小得多。

在检索层做权限控制，通常意味着向量库中每个 chunk 都携带 访问控制元数据（如所属部门、密级、用户组 ID），查询时先按当前用户的权限范围过滤，再做向量相似度检索。这被称为「检索前过滤」（pre-filtering）或带权限的近似最近邻搜索，和「检索后过滤」相比代价更高但更安全——后者可能先召回了受限内容再丢弃，存在日志或缓存层面的泄露风险。权限变更后还需要触发增量重建索引，否则旧权限会随向量一直留存。

六、度量真实工作流

上线后需要跟踪的指标包括：用户能否找到正确来源、何时会改写问法、升级转接的频率、答案是否被判定有用。在隐私合规的前提下，抽查一部分真实对话。

原文提到一个常被混淆的点：能回答几个预设提示的demo，和工具在日常问题上的表现，是两回事。演示环境的问题是人挑的，生产环境的问题是随机分布的。

一个可复用的端到端测试

把整个流程串起来，可以用一个简单测试作为冒烟检查：

提一个答案确实存在于源文档中的问题
确认系统召回了正确段落
确认返回的答案有该段落支撑
确认答案附带了来源链接
再提一个证据缺失的问题，确认系统拒绝回答或转接人工

更换文档、调整切分、替换embedding模型或修改提示词之后，重复这套测试。原文作者还链接了一份Django + FAISS的RAG实现指南，涉及数据摄入和查询流程的完整路径，适合需要落地参考的团队。

小结

这份清单的核心立场是：RAG系统需要按管线思维逐段验证，而非指望提示词工程解决所有问题。六个维度——用例边界、文档准备、检索独立评估、证据与兜底、权限与时效、工作流度量——覆盖了从开发到上线的主要风险面。对准备首次发布的团队来说，可以作为一份可执行的检查框架直接使用。