RAG 是检索增强生成：先从资料中找出与问题相关的内容，再把这些内容提供给模型，用于组织回答。 它适合需要反复查询产品文档、内部流程或专业资料的场景。
可以把它理解为“先翻资料，再作答”。但知识库不是把文件上传后就自动完成的黑盒：文档质量、切分方式、检索结果和回答要求，都会影响效果。本文用一个虚构产品 FAQ，解释怎样判断知识库是否真的可用。
一、RAG 的完整链路
Google Cloud 的 RAG 概述将资料处理、检索和增强生成组织为一个工作过程。实际系统可能使用向量检索、关键词检索或组合方案，不必把某一种数据库等同于 RAG 本身。
- 整理资料：导入文档并提取文字，保留标题、版本和权限等信息。
- 切分与建索引：把资料整理为便于检索的片段，并保存原文定位信息。
- 根据问题检索：找出候选内容，必要时再筛选或重排。
- 组织回答：将问题与相关资料提供给模型，要求答案有依据并说明出处。
- 检查结果：确认检索找对了内容，回答没有超出资料支持的范围。
二、它适合什么，不适合什么
适合的情况包括：资料经常更新、需要回答带来源的问题、同一批文档会被反复查询、不同用户应看到不同范围的内容。
如果只需要总结一份短文件，直接提供上下文可能已经够用；如果问题主要是文风或格式不稳定，也应先检查提示词和任务定义。先确认问题属于“缺少可用资料”，再考虑搭建知识库。
RAG 通常在回答时利用外部资料，并不意味着这些资料已经永久写入模型参数。微调主要涉及通过训练调整模型行为，两者的工作方式与维护成本不同，也可能结合使用。
三、用 FAQ 示例理解切分
假设资料写着：“示例产品 B 的个人版最多添加 3 位成员；团队版的成员数量与合同约定有关。”这是虚构规则，只用于解释方法。
如果把“个人版最多 3 位”与后面的产品名称、版本信息分开，检索后就可能失去适用范围。更稳妥的片段应保留产品名、套餐名、完整规则与来源位置。
切分时的实际检查点
- 标题与它解释的正文是否仍然关联。
- 表格是否保留列名、单位和脚注。
- 一个完整操作步骤是否被拆散。
- 资料更新后，旧版本是否仍然可能被检索出来。
不存在适合所有文档的固定片段长度。可以先按自然章节切分，再用真实问题检查召回结果，逐步调整。
四、检索正确，回答仍可能错误
当用户问“个人版能加几个人”时，系统可能找到正确片段，却把“最多 3 位”理解成“购买后默认附带 3 个额外席位”。这属于生成阶段的解释偏差。
另一种情况是系统找到了旧版资料。即使模型忠实复述，结果也可能不适用于当前版本。因此排查时应分开看：原文是否正确、检索是否选对、回答是否忠实。
不要只看最终答案。 先打开系统实际引用的片段，很多问题会更容易定位。
五、先做一组小而明确的验收问题
至少覆盖下面几类：
- 资料里有直接答案：检查能否准确找到并引用。
- 需要结合两段资料：检查能否合并，同时保留各自条件。
- 存在旧版本或相似产品：检查是否选错内容。
- 资料没有答案：检查是否明确说明无法确认。
- 用户没有权限：检查资料访问与检索范围是否受到约束。
每个问题记录预期答案、对应来源和允许的不确定表达。初期可以从十几条覆盖核心场景的问题开始，后续把真实失败案例加入测试集。数量只是起点，关键是覆盖实际业务。
六、上线后要维护什么
- 资料更新：新旧版本如何替换，错误内容由谁修正。
- 检索效果：哪些问题经常找不到正确片段。
- 回答质量：引用正确但解释错误的情况有哪些。
- 权限边界：不同用户是否只能检索允许的资料。
- 成本与速度：索引维护、查询和模型调用是否符合使用规模。
不要为了提高回答率而强迫系统回答所有问题。对资料不足的请求给出明确说明，并引导人工处理，往往比生成完整但错误的答案更有价值。
常见问题
上传更多文档就一定更好吗
不一定。重复、冲突和过时文档会增加干扰。先整理有效资料，再增加规模。
有引用就说明答案正确吗
不一定。引用可能不支持结论，也可能只覆盖部分条件。要检查答案与原文的对应关系。
必须自己开发向量数据库吗
不需要。可以使用已有知识库或应用平台，也可以开发自己的系统。选择取决于资料规模、权限要求、维护能力和预算，而不是功能名是否热门。
还没有公开评论，欢迎分享你的想法。