AMZ
用户中心
AI 与自动化

AI知识库质量优化：为什么你的知识库问不准、答不全、经常胡说

别急着换模型，先把错误拆回资料、切片、元数据、检索、重排、提示词和日志评测

公众号文章库2026/7/718 分钟阅读

别急着换模型，先把错误拆回资料、切片、元数据、检索、重排、提示词和日志评测

**摘要：**修好知识库幻觉

**关键词：**RAG优化、知识库不准确、AI幻觉、知识库评测、RAG质量诊断

封面：AI知识库质量优化：为什么你的知识库问不准、答不全、经常胡说

本文是「AI知识库完整教程」第 13 课。

知识库上线后不准，别第一反应就换模型

很多跨境团队搭完 AI 知识库后，会遇到同一个挫败感：资料明明上传了，机器人还是问不准、答不全、经常胡说。

客服问“便携榨汁杯盖子裂了怎么处理”，它把“瓶身破损退货 SOP”拿来回答；运营问“6 月 broad campaign ACOS 为什么上升”，它只给一段泛泛广告优化建议；新人问“德国站标题能不能写 BPA free”，它把美国站资料混进来。

这时很多人会说：是不是模型不行？是不是要换更贵的模型？

不一定。RAG 知识库的失败，通常不是一个点坏了，而是一条链路里某个环节失真：源资料乱、切片丢上下文、元数据缺失、检索没召回、重排没排对、提示词没约束、上线后没有评测和日志复盘。

这篇的目标很直接：给你一套商业级排查框架，让你能把“AI 胡说”拆回可修的问题。

先把错误分成三类：找不到、找错、找到了但乱说

知识库错误不能只写一句“回答不准”。要先分类。

第一类是找不到：知识库里有资料，但检索没有召回；或者知识库根本没有这份资料。表现为回答很泛、说没有资料、或者绕开关键问题。

第二类是找错：检索召回了类似资料，但不是正确资料。比如召回旧版本、错站点、错 SKU、错产品线、错场景。

第三类是找到了但乱说：检索结果正确，但模型生成时过度推断、忽略冲突、没有引用来源，或者把建议说成事实。

这三类对应的修复动作完全不同。找不到要查资料和召回；找错要查 metadata、切片、混合搜索和重排；找到了还乱说，要查提示词、回答结构和人工确认边界。

  • 找不到：资料缺口、切片错误、检索策略不匹配。
  • 找错：站点、SKU、版本、文档类型、时间窗口过滤失败。
  • 乱说：LLM 没有被要求基于来源、列冲突、拒答和转人工。
  • 先分类，再修复；不要把所有问题都归因于模型。

第一层：源资料质量，决定知识库天花板

资料乱，是知识库不准的第一原因。

跨境团队的资料里经常混着旧 SOP、新 SOP、草稿、正式版、运营临时口径、客服聊天截图、供应商说明、平台规则、广告复盘和老板备注。人还能凭经验判断哪个是最新的，AI 不一定能。

如果旧版售后政策和新版售后政策同时在默认检索范围内，机器人就可能把两者拼在一起。更麻烦的是，它会说得很自然，让一线客服误以为这是最新规则。

第一步不是调参数，而是做资料分层。正式资料、参考资料、历史资料、待确认资料，不能放在同一个默认检索池里。每份资料都要有状态：current、draft、archived、needs_review。

  • 正式资料：可以默认参与回答。
  • 参考资料：只能辅助解释，不能作为最终规则。
  • 历史资料：默认不参与回答，只用于版本追溯。
  • 待确认资料：必须提示人工确认，不得直接生成结论。
  • 敏感资料：先脱敏，并限制检索范围和日志访问。

第二层：切片和上下文，不是按字数机械切

Anthropic 在 Contextual Retrieval 文章中指出，传统 RAG 往往在编码片段时移除上下文，导致检索不到正确资料。它给的例子是一个片段写着“收入增长 3%”，但如果片段没有公司和季度信息，就很难被正确检索和使用。

跨境资料里同样常见。一个 chunk 只写“客户需要提供照片”，但没有说明这是破损到货、退货申请还是保修申请，机器人就可能在错误场景里要求客户提供照片。

切片不是越小越好。好的 chunk 要能回答一个完整业务问题，同时带上业务上下文：站点、产品、场景、版本、适用条件、禁止事项。

如果平台支持 contextual chunk，可以给每个 chunk 增加一段简短上下文；如果不支持，就把上下文写进标题或文档开头。不要让重要限制落在另一个 chunk 里。

  • 客服 SOP：按问题场景切，不按整本手册切。
  • 产品资料：按产品线、功能、配件、安全限制切。
  • 广告复盘：按时间窗口、活动、搜索词组和动作切。
  • 规则资料：按站点、政策主题和生效日期切。
  • 每个 chunk 标题要包含业务对象，不只写“注意事项”。

第三层：元数据缺失，会让正确资料被错误使用

Dify Metadata 文档说明，metadata 可以用来描述文档上下文，帮助过滤、组织数据、控制敏感内容和自动化工作流。对跨境团队来说，metadata 是知识库的业务护栏。

很多错误并不是资料内容错，而是资料被用错了地方。美国站资料被拿去回答德国站，旧包装参数被拿去回答新包装，草稿 SOP 被拿去给客服生成话术。

所以元数据不是可选项。一个商用知识库至少要有：market、sku_family、product_version、document_type、status、effective_date、owner、sensitive_level、source_url、review_cycle。

没有这些字段，Hybrid Search 和 Rerank 再强，也是在错误资料池里找最相似内容。相似不等于适用。

  • market：防止 US、DE、UK、JP 规则混用。
  • sku_family/product_version：防止新旧产品混用。
  • document_type：区分 SOP、FAQ、产品事实、广告复盘、平台规则。
  • status：只让 current 资料默认回答。
  • sensitive_level：决定是否可回答、是否转人工、是否进日志。

第四层：检索设置，要用真实问题测试

Dify 检索设置文档明确说明，检索方法会影响 LLM 回答的准确性和可信度。High Quality 索引支持 Vector Search、Full-Text Search 和 Hybrid Search，还涉及 Rerank、TopK、Score Threshold 等设置。

如果你的资料里有大量 SKU、ASIN、型号、站点、日期、广告活动名，纯语义检索可能不够；如果用户问题表达很口语化，纯关键词搜索也不够。

客服 SOP、产品资料、广告复盘这类资料，通常要测试 Hybrid Search。语义负责理解“客户说法不同但意思接近”，关键词负责命中“具体 SKU、站点、法规词、广告词”。

不要只用平台默认参数。Dify 支持测试知识库检索，你应该用真实问题模拟检索结果，看正确 chunk 是否进入前 3，而不是只看最终回答是否看起来顺。

  • Vector Search 失败：看是否漏掉精确术语、SKU、日期。
  • Full-Text Search 失败：看用户是否换了一种说法。
  • Hybrid Search 失败：看权重、metadata 过滤和 chunk 标题。
  • Rerank 失败：看正确资料是否被相似但错误的 chunk 压下去。
  • Score Threshold 失败：看资料不足时是否还硬答。

第五层：Rerank 能救顺序，但不能救烂资料

Pinecone 文档说明，Rerank 会根据 query 对候选文档重新排序。Anthropic 的 Contextual Retrieval 文章也指出，Reranking 可以进一步减少检索失败，但会带来成本和延迟，需要按具体场景实验。

业务上可以这样理解：第一轮检索是把可能相关的资料捞出来，Rerank 是二审，把真正应该给模型看的资料排到前面。

它适合资料量大、相似文档多、用户问题复杂的场景。比如售后知识库里有破损、裂痕、漏水、退货、换货、保修，很多 chunk 都看起来相似，Rerank 能帮助排序。

但 Rerank 不是万能。如果旧 SOP 和新 SOP 都在 current 资料池里，Rerank 只是在两个相似错误中重新排序。先治理资料，再谈重排。

  • 适合加 Rerank：相似文档多、误召回多、正确资料常排在后面。
  • 不急着加 Rerank：资料少、场景窄、检索结果已经稳定。
  • 必须监控：延迟、成本、正确资料进入前 3 的比例。
  • 不能替代：版本管理、metadata、敏感资料隔离。

第六层：提示词要把“不会回答”写清楚

很多知识库幻觉，不是检索没找到，而是 LLM 拿到一点点资料后开始补脑。

商用知识库的提示词必须写清：只基于检索结果回答；没有资料就说资料不足；资料冲突就列出冲突；涉及价格、退款、法律、平台政策、医疗安全、认证、账号风险，必须转人工或要求人工确认。

对客服场景，建议输出两层：内部判断和客户话术。内部判断可以写依据、限制和风险；客户话术必须谨慎，不能暴露内部成本、供应商、账号风险和未确认政策。

对广告复盘场景，要要求模型区分事实、推断和建议：报表明确显示什么，我们合理推断什么，下一步要做什么测试。不要让它把“可能原因”说成“确定原因”。

一份可直接放进知识库应用的质量提示词

下面这份适合内部知识库应用，你可以放进 Dify、ChatGPT Project 或其他 RAG 应用的系统提示词里，再按业务调整。

你是内部知识库质量审核员。请只基于检索结果和已提供资料进行判断。

回答规则：
1. 如果检索结果不足，必须回答“资料不足”，并列出缺少什么；
2. 如果检索结果冲突，必须列出冲突来源，不得自行选择一个说法当结论；
3. 所有内容分成三类：来源明确写到、可以合理推断、必须人工确认；
4. 涉及价格、退款、平台政策、法律、认证、安全、医疗、账号风险，必须提示人工确认；
5. 不得把建议写成事实，不得把单条评论写成市场结论；
6. 输出必须包含：答案、引用依据、风险边界、下一步动作、是否需要转人工。

用户问题：
{{query}}

检索结果：
{{retrieved_context}}

评测不是问几个样例，而是做测试集

AWS Bedrock 的 RAG 评估文档说明，可以用计算指标评估 RAG 是否有效检索相关信息，以及生成回答是否有效回答问题。LangSmith 的 RAG 评估教程也强调要创建测试数据集、运行应用评估。

这对业务团队的启发很明确：不要用一个成功样例证明知识库稳定，也不要用一次失败就判断模型不行。

你至少要准备 50 个真实问题，最好按使用场景分层：客服 SOP、产品资料、广告复盘、Listing 规则、新人培训。每个问题都要有预期命中文档、标准答案、必须拒答或转人工的边界。

评测表不要只记录最终答案。要记录：召回 chunks、正确 chunk 是否进入前 3、回答是否引用来源、是否遗漏关键限制、是否把推断说成事实、是否触发人工确认。

  • 检索指标：正确资料是否被召回，是否进入前 3。
  • 生成指标：回答是否基于来源，是否答到问题。
  • 边界指标：无资料、冲突资料、敏感问题是否拒答或转人工。
  • 业务指标：客服能否执行，运营能否决策，老板能否复盘。

上线后真正有价值的是日志闭环

Dify Logs 文档说明，日志会记录 Web app 或 API 中的用户交互、输入输出、响应时间、用户反馈和系统信息，可用于调试和持续改进。同时文档也提醒，日志可能包含敏感信息，需要控制访问和遵守隐私要求。

上线后不要只看“有没有人用”。要看哪些问题反复被问、哪些回答被点踩、哪些问题没有召回资料、哪些问题触发人工、哪些回答耗时过长。

每周把日志错误分成五类：资料缺口、切片问题、元数据问题、检索/重排问题、提示词问题。

然后一类一类修。资料缺口就补资料；切片问题就重拆；元数据问题就补字段；检索问题就调 Hybrid 权重、TopK、Score Threshold、Rerank；提示词问题就收紧边界。不要把所有日志问题都甩给模型。

  • 每周抽样 50 条真实问答。
  • 保留错误原文、召回内容、最终回答和用户反馈。
  • 错误必须归因到一个可修环节。
  • 修复后用测试集回归验证。
  • 日志含敏感内容时，限制查看权限并定期脱敏或清理。

跨境实战：美国站客服机器人为什么老答错

假设你给美国站客服搭了一个 SOP 机器人。上线后，客服反馈三个问题：破损问题答成退货政策，旧款配件规则混进新款，资料没有写的时候机器人还会编一个看似合理的话术。

按本文框架拆：破损答成退货政策，先看 chunk 是否把破损、退货、换货、保修写在同一个长文档里，再看 problem_type metadata 是否存在。旧款混新款，先看 product_version 和 status 是否能过滤。无资料还编，先看提示词有没有要求资料不足时拒答，再看 Score Threshold 是否太低。

不要让运营拍脑袋改 Prompt。先打开检索结果，看机器人到底拿到了什么资料。如果召回错了，改知识库和检索；如果召回对了但回答错了，再改提示词和回答模板。

这套流程跑通后，客服机器人会从“看起来会说话”变成“知道什么时候该回答、什么时候该引用、什么时候该转人工”。

跨境实战：广告复盘机器人为什么只会泛泛而谈

广告复盘知识库也很容易答得很泛。

比如你问“6 月便携榨汁杯 broad campaign ACOS 为什么上升”，机器人只回答“优化关键词、调整预算、否定无效词”。这种回答没有业务价值。

真正应该召回的资料包括：6 月 Search term report 摘要、上月对照、Listing 改版记录、竞品价格变化、否词记录、预算调整记录。Amazon Ads 官方说明 Search term report 可以查看客户搜索词或与商品最佳匹配的搜索词，这类资料必须按时间窗口和广告活动组织好。

修复方法是：按 campaign、ad_group、sku、match_type、date_range、action 加 metadata；按事件和时间窗口切 chunk；测试问题必须包含具体月份、活动名、SKU、指标和动作。否则机器人只能说通用广告建议。

一张管理者能看懂的质量诊断表

如果你负责团队知识库，不要只问技术同事“能不能调准一点”。你要要求每次问题都有诊断记录。

诊断表至少包含：问题原文、业务场景、正确来源、实际召回内容、错误类型、根因、修复动作、复测结果、负责人、完成日期。

这样知识库优化才会变成运营管理，而不是玄学调参。

这张表还能帮团队建立共同语言。客服知道什么叫资料缺口，运营知道什么叫错版本召回，老板知道为什么不是所有问题都能靠换模型解决。

  • 错误类型：找不到、找错、找到了但乱说。
  • 根因层级：资料、切片、元数据、检索、重排、提示词、权限。
  • 修复动作：补资料、归档旧版、重切 chunk、补 metadata、调检索、改提示词。
  • 复测结果：通过、部分通过、仍失败、转人工。

7 天 SOP：把一个不准的知识库修到可用

第 1 天，收集 30 到 50 条真实错误问答，不要只听口头反馈。

第 2 天，把错误分成找不到、找错、找到了但乱说三类。

第 3 天，检查源资料，归档旧版、删除重复、标注 current/draft/archived/needs_review。

第 4 天，检查 chunk 和 metadata，补 market、sku_family、document_type、version、status、effective_date、owner。

第 5 天，用 Dify Test Retrieval 或对应平台的检索测试，记录正确 chunk 是否进入前 3。

第 6 天，调整 Hybrid Search、TopK、Score Threshold、Rerank，并用同一批问题对照测试。

第 7 天，收紧提示词和回答格式，要求引用来源、列冲突、无资料拒答、敏感问题转人工，并建立每周日志复盘节奏。

不要误读：知识库质量不是一次性验收

知识库不是搭完就稳定。业务会变，平台规则会变，产品版本会变，客服问题会变，广告结构也会变。

所以质量优化不是上线前检查一次，而是持续运营。每周看日志，每月清理旧资料，每次产品改版后更新 metadata，每次平台规则变化后重新跑测试集。

更重要的是，知识库要允许回答“不知道”。一个知道边界的机器人，比一个什么都能编的机器人更适合商用。

  • 不要用一个成功样例证明系统可靠。
  • 不要把旧资料和正式资料放进同一个默认检索范围。
  • 不要让机器人在价格、退款、合规、法律、安全承诺上自由发挥。
  • 不要只看最终回答，要看召回内容。
  • 不要把日志开放给不该看到敏感对话的人。

可以直接复制的诊断提示词

我的 AI 知识库回答不准，请你按 RAG 质量诊断框架帮我排查。

知识库场景：【客服SOP / 产品资料 / 广告复盘 / Listing改版 / 新人培训】
错误样例：【粘贴用户问题 + AI错误回答】
正确资料：【粘贴或描述正确来源】
当前检索结果：【如果有，请粘贴召回的 chunks；如果没有，请说明】

请输出：
1. 错误属于“找不到、找错、找到了但乱说”哪一类；
2. 可能根因：源资料、Chunk、Metadata、检索、Rerank、Prompt、权限；
3. 每个根因的验证方法；
4. 最小修复动作；
5. 修复后应该用哪些测试问题回归验证；
6. 哪些问题必须转人工；
7. 一张可交给团队执行的 7 天优化计划。

明天可以照着做的清单

  • 先分类：找不到、找错、找到了但乱说。
  • 先看召回 chunks，再看最终回答。
  • 旧资料、草稿、待确认资料不要默认参与回答。
  • 每个 chunk 要保留站点、产品、版本、场景和限制。
  • 补齐 market、SKU、版本、状态、有效日期、负责人等 metadata。
  • 用真实问题测试 Hybrid Search、TopK、Score Threshold 和 Rerank。
  • 至少准备 50 个测试问题，不用单个样例判断质量。
  • 提示词必须要求无资料拒答、资料冲突列出、敏感问题转人工。
  • 上线后每周看日志，把错误归因到可修环节。
  • 日志和测试数据必须脱敏，避免泄露客户和店铺敏感信息。

结论

知识库优化不是一句“换模型”能解决的事。真正可商用的 RAG 系统，要能定位错误来自哪里：资料、切片、元数据、检索、重排、提示词还是日志运营。能定位，才有修复；能复测，才有稳定。

资料来源