8.0
热点
AI SCORE
技术实践2026-08-19 04:44
RAG 效果差？先审计知识库内容一致性，别急着调参
dev.to · AI#RAG#AI工程#知识库
Editor brief · 编辑速览
多数 RAG 问题根源不在检索架构，而是知识库内部存在矛盾（同一问题有两个答案）或内容过期。工程团队应先对知识库做内容审计，再动手调 chunk size 或 embedding 模型。
一名客服助理给了客户错误的退款窗口期。写的是十四天，而政策其实是三十天。
工程的反应在意料之中。检查一下 chunk 大小试试语义分块。加一个 reranker。调一调 top-k。也许 embedding 模型对这个领域不合适。也许试试混合 BM25 加 dense 的方案。
这些都是合理的做法。在我看过的大多数案例中，它们都不是真正的问题。
真正的问题是知识库里有两篇文章。一篇说十四天，一篇说三十天。两篇都被索引了。两篇都看似合理。检索器完美地完成了它的任务，返回了一篇说十四天的文档——因为那篇文档确实存在，而在 2024 年政策变更时，没有人删掉它。
没有任何检索架构能拯救一个自我矛盾的语料库。
在调参之前先做一次审计。发现的问题在各个组织中高度一致。
矛盾内容。同一个问题在两个地方得到了不同答案，因为其中一个更新了，另一个没有。没人知道第二篇的存在。
过时内容。政策变了，产品停产了，流程替换了。文章依然在，依然被索引，依然和正确的内容竞争检索——而且经常胜出，因为旧内容的措辞有更长时间来积累与客户提问方式相匹配的表述。
缺失区分符。一份答案对一个市场正确、对另一个市场错误，但文档里没有任何东西把它们区分开来。检索器无法过滤不存在的信息。
受众错配。为内部员工编写的内容（他们本身已有上下文），却被推送给没有上下文的客户。技术上正确，实际上没用，偶尔还让人警觉。
孤立片段。从长文档中切出的章节，被单独检索时毫无意义，因为它们依赖于上方三个标题处的上下文。
模型选择解决不了以上任何一个问题。分块策略也不行。
大多数客服场景的检索失败，本质上是过滤失败——只是穿上了相关性的外衣。你想要的那份文档在索引里；你不想的那份排在它前面。
每份文档最低限度需要的元数据：
market: [UK, IE] # or ALL
product: [premium, plus] # or ALL
effective_from: 2024-06-01
effective_to: null # null = current
audience: customer # customer | internal
owner: billing-team # who keeps it correct
last_verified: 2026-07-14
有了这些，检索就变成了「先过滤再搜索」，而不是「搜索然后祈祷」：
candidates = index.search(
query,
filter={
"market": user.market,
"product": user.product,
"audience": "customer",
"effective_from": {"$lte": today},
"$or": [{"effective_to": None},
{"effective_to": {"$gte": today}}],
},
top_k=8,
)
仅 effective_to 字段就能消除大量错误答案，因为它让被取代的内容留在存档里，而不必与正确内容竞争检索。
last_verified 给你提供了一样你目前可能根本没有的东西：一个可量化的语料库衰减指标。没人确认过的文档集中在哪里，哪里就是错误答案的聚集地。
你不可能读完一万篇文章。但你可以找出那些存在分歧的文章。
1. 对每份文档，生成它所支持的问题-答案对集合。
2. 对问题进行语义聚类。
3. 在每个聚类内，比较答案。
4. 答案出现分歧的地方，标记给人工审核。
这样就能在没有人工逐篇审核语料库的情况下，发现「十四天对三十天」的问题，而且这正是那种高量低判断的工作——现在跑起来成本极低。
输出的是一个审核队列，而不是修复方案。人类决定哪个答案正确——而这个决定通常需要业务侧的人而不是内容团队的人来做，这本身就是一个值得暴露的发现。
审计会衰减。三月份清理过的语料库，到九月份又脏了——除非有东西在维护它。
有效的机制是文档级别的所有权加上审核节奏。每份文档有一个负责团队，该团队按计划确认或更新它。超过审核日期的文档会被标记，最终在检索中被降低优先级——而不是悄无声息地提供过时答案。
这是一个穿着 AI 项目外衣的内容运营投入，而且这是预算中最常缺失的部分。团队为工程买单，而不是为内容整理买单，然后在上线后的季度里质量下降时感到困惑。
在调参之前，先确定是检索还是生成在出问题。它们需要不同的修复方案，却经常被混为一谈。
取一批错误答案手工检查：正确文档是否在检索结果集中？
正确文档被检索到了，答案仍然错误 → 生成问题
（prompt、模型、上下文长度）
正确文档没有被检索到，但它存在 → 检索问题
（元数据、分块、排序）
正确文档不存在或存在矛盾 → 内容问题
（最常见）
在我审查过的部署中，第三行占主导——而且这是任何工程努力都无法解决的一类。
完整指南——隔离与解决、升级设计、Agent 辅助、成本曲线和排序：AI Customer Experience。我们也在部署前审计知识语料库。
为什么我的 RAG 系统会给出自信的错误答案？
通常是因为语料库包含矛盾或过时内容，而检索忠实地返回了它们。生成的答案读起来很流畅，无论来源质量如何——这使得劣质内容比关键字搜索时代更难被发现。
我如何判断问题是出在检索还是内容？
取错误答案样本，检查正确文档是否在检索结果集中。被检索到但答案错误是生成问题；没被检索到但文档存在是检索问题；文档不存在或存在矛盾是内容问题——而且这是最常见的情况。
支持知识库需要哪些元数据？
至少需要市场、产品、生效日期、受众、所有者和最后验证日期。生效日期这一项单独就能消除大量错误答案——通过让被取代的内容留在存档中而不必竞争检索排名。
如何在不读完所有内容的情况下找出矛盾？
为每份文档生成问题-答案对，对问题进行语义聚类，在每个聚类内比较答案。出现分歧的交给人工审核队列——通常需要业务侧的人而不是内容团队的人。
如何阻止语料库再次衰减？
文档级别的所有权加上审核节奏。标记超过审核日期的文档，在检索中降低其优先级——而不是让它们悄无声息地提供过时答案。
在调参检索之前应该先修复内容吗？
是的。分块策略和 reranker 无法解决自我矛盾的语料库，针对劣质内容调优只会更可靠地检索到错误的文档。