你的AI知识库61页，24页内容已失效：RAG文档腐化的致命真相

一家牙科诊所的AI接待员总报出一个“错误”的价格。其实不是错误，而是两年前的旧价格，它藏在一篇没人删除的帮助中心文章里。

我检查了该诊所的整个知识库：61个Markdown页面，最后修改时间从14天前到1100天前不等。我逐一将每个页面与实时系统——预约日历、价目表、员工名册、保险清单——进行比对。

61页中有24页（39%）包含至少一条在当时已经为假的陈述。

其中6页提到一位已离职的牙医；5页引用了已变更的价格；4页描述了诊所已停止提供的服务；3页的营业时间仍是2024年之前的正确版本；2页列出了已不再合作的保险公司；4页是其他页面的重复，但对同一问题给出了不同答案。

AI对这些页面的检索置信度高达0.94，因为检索衡量的是相似度，而非真实性。一个写着“检查费45英镑”的页面，对于“检查费多少钱”的查询是完美匹配。它不知道价格现在是62英镑。

这就是文档腐化，在RAG系统中，它是自信错误答案的最大单一来源，任何提示词工程都无法修复。

四种腐化类型，只有一种是“过时”

大多数团队把这当成一个问题——“我们应该更新文档”。但它不是单一问题，每种类型需要不同的修复方法。

腐化类型	表现	检索为何无法发现	修复方法
1. 过时事实	价格、时间、人名或政策已变，页面未变	旧文本与问题语义完美匹配	时间戳+负责人+探针
2. 幽灵页面	服务、产品或人员已不存在	仍能在相关问题中排第一	删除，而非归档
3. 分叉	两个页面对同一问题给出不同答案	检索返回排名更高者，两者都显得权威	合并为一个规范页面
4. 孤儿	产品或网站无链接，无人负责	仍被索引，仍可检索	退役或指定负责人

该诊所的24个坏页面分布为：11个过时事实、6个幽灵、4个分叉、3个孤儿。只有第一类能靠“提醒人们更新文档”解决。

幽灵页面最危险。一个已停产的服务页面不仅导致错误答案，还会让客户问出本不该能问的问题。AI提供诊所无法执行的治疗，客户却预约了。

为什么“季度审查文档”永远无效

我已在七个知识库上运行过审计：从61页到840页不等，大多在100-300页。结果一致。

指标	7次审计的典型范围
含至少一条虚假陈述的页面	31% – 44%
12个月内未编辑的页面	55% – 78%
重复主题分叉	页面总数的6% – 19%
最常被检索的20页中位年龄	210 – 640天
“负责人”字段为空或已离职员工的页面	40% – 66%

注意最后一行，也注意第四行。被检索最多的页面通常最老，因为它们写于产品初期，之后没人重写。在我打开过的几乎每个知识库中，检索量与新鲜度都呈负相关。

季度人工审查失败有结构性原因：你无法通过阅读200个页面来审查它们，因为“这仍然真实吗？”无法从页面本身回答。它只能从记录系统——价目表、日历、CRM——回答。审阅者阅读文档时，只能判断它听起来是否当前。

因此，审计必须构建为与系统的差异比对，而非阅读练习。

检索增强生成（RAG）与向量检索的相似度机制

RAG（Retrieval-Augmented Generation）系统在回答用户问题前，会先将知识库文档切分成片段并转换为向量嵌入（embedding），存入向量数据库。当用户提问时，系统把问题也转换为向量，通过余弦相似度等度量找出最接近的文档片段，再交给大语言模型生成答案。关键在于：相似度衡量的是“语义接近程度”，而非“事实正确性”。一个写有过时价格的页面，只要措辞与用户问题高度匹配，就会获得极高的检索置信度——文中诊所案例的置信度高达0.94，但内容已经是两年前的旧价格。这意味着模型会忠实地基于错误材料生成流畅答案，而任何提示词工程都无法让模型怀疑一份读起来完美无缺的文档。腐化的根源在检索层，而非生成层。

每个页面在被审计前需要的三样东西

没有基线就无法检测腐化。在每个页面的front matter中添加三个字段，包括你即将删除的页面。

---
owner: revenue-ops            # 团队，而非可能辞职的个人
source_of_truth: pricing-sheet-v3   # 事实来源
verified_at: 2026-09-30       # 上次人工或脚本确认的时间
---

• owner 必须是团队或角色。我审计过的每个以人名作为负责人的知识库，一年内都有40%以上的页面成为孤儿，因为人离开后没人继承文档。
• source_of_truth 使自动检查成为可能。如果页面的价格声明无法追溯到命名表，它们就无法被验证，只能被相信。
• verified_at 不是 updated_at。修正拼写错误不是验证。这个区别就是整个审计的核心。

没有这三个字段的页面，按定义就是无主且不可验证的。将它们视为嫌疑人，而非文档。

Front matter 与记录系统（System of Record）

Front matter 是 Markdown 文件顶部由 --- 包裹的 YAML 元数据块，通常用于存放标题、日期、标签等结构化信息，不会被渲染为正文。文中要求在 front matter 中添加 owner、source_of_truth、verified_at 三个字段，本质上是把文档变成可审计的对象。而“记录系统”指的是组织中权威的事实来源——价目表、预约日历、CRM、员工名册等。文档中的陈述只是记录系统的快照，快照会漂移。只有将页面声明与记录系统做差异比对，才能回答“这仍然真实吗？”这个问题。source_of_truth 字段的作用正是建立文档与记录系统之间的可追溯链接，使自动验证成为可能；没有它，页面内容只能被相信，无法被检查。

扫描器

在300个页面上运行约需四秒，生成工作清单。它刻意保持简单：不用LLM，不用嵌入。它找出候选，由人确认。

# rot_audit.py — python3 rot_audit.py ./kb > rot_report.csv
import os, re, sys, csv, datetime, collections

ROOT = sys.argv[1]
STALE_DAYS = 180
NUM = re.compile(r'(?:[$£€]\s?\d[\d,.]*|\b\d+(?:\.\d+)?\s?%|\b\d{1,2}:\d{2}\b)')

def front_matter(text):
    m = re.match(r'^---\n(.*?)\n---\n', text, re.S)
    if not m: return {}
    out = {}
    for line in m.group(1).splitlines():
        if ':' in line:
            k, v = line.split(':', 1)
            out[k.strip()] = v.strip().strip('"\'')
    return out

rows, seen = [], collections.defaultdict(list)
today = datetime.date.today()

for dirpath, _, files in os.walk(ROOT):
    for f in files:
        if not f.endswith(('.md', '.mdx')): continue
        p = os.path.join(dirpath, f)
        text = open(p, encoding='utf-8').read()
        fm = front_matter(text)
        body = re.sub(r'^---\n.*?\n---\n', '', text, flags=re.S)
        nums = NUM.findall(body)
        verified = fm.get('verified_at')
        age = ''
        if verified:
            try: age = (today - datetime.date.fromisoformat(verified)).days
            except ValueError: age = 'BAD_DATE'
        rows.append({
            'file': os.path.relpath(p, ROOT),
            'owner': fm.get('owner', ''),
            'source_of_truth': fm.get('source_of_truth', ''),
            'verified_at': verified or '',
            'days_since_verified': age,
            'numeric_claims': len(nums),
            'stale': 'YES' if (not verified or (isinstance(age, int) and age > STALE_DAYS)) else '',
            'risk_score': 0,
        })
        # fork detection: same title-ish heading, different numeric content
        head = (fm.get('title') or body.strip().splitlines()[0:1] or [''])[0]
        key = re.sub(r'[^a-z0-9 ]', '', str(head).lower())[:40].strip()
        if key: seen[key].append((os.path.relpath(p, ROOT), tuple(sorted(nums))))

for r in rows:
    score = 0
    if r['stale']: score += 2
    if not r['owner']: score += 2
    if not r['source_of_truth']: score += 2
    score += min(len(re.findall(r'(?i)\b(currently|now|as of|starting|from january|this year)\b', open(os.path.join(ROOT, r['file']), encoding='utf-8').read())), 3)
    r['risk_score'] = score

for key, items in seen.items():
    if len(items) > 1 and len({i[1] for i in items}) > 1:
        for f, _ in items:
            for r in rows:
                if r['file'] == f: r['risk_score'] += 3

rows.sort(key=lambda r: -r['risk_score'])
w = csv.DictWriter(sys.stdout, fieldnames=list(rows[0].keys()))
w.writeheader(); w.writerows(rows)

它标记：

• stale — 无verified_at或超过阈值。
• 无负责人/无事实来源 — 不可验证页面得分提高，排到顶部供你先读。
• 时间语言 — 页面中的“当前”、“现在”、“截至”是自我声明的过期日期。
• numeric_claims — 每个数字都是可能漂移的事实；零数字意味着低影响范围。
• 分叉 — 两个标题相同但数字不同的页面，人类阅读永远发现不了的一类。

探针集：12个问题，同时问AI和记录系统

扫描器找出可疑页面。探针找出实际谎言。写12个答案可在系统中查找到的问题——不是观点，不是摘要。对诊所而言：

1. 标准检查的价格是多少？
2. 复合填充的价格是多少？
3. 周六营业时间是？
4. 哪些牙医目前接受新患者？
5. 你们接受[保险公司]吗？
6. 卫生预约等待时间多长？
7. 取消窗口和费用是多少？
8. [已停产服务]可用吗？
9. 紧急非工作时间电话号码是多少？
10. 儿童首次咨询多少钱？
11. 哪些地点周日营业？
12. 治疗计划超过1000英镑的押金是多少？

逐字向部署的AI提问每个问题。将其答案与记录系统答案并排。每个不匹配都是一个带有指纹的腐化事件：AI给出的答案告诉你哪个页面产生了它。

在诊所，12个探针返回7个不匹配，映射到24个坏页面中的9个。另外15页没有探针覆盖——这本身就是发现：没有探针触及的页面，就是你没有理由保留的页面。

每周运行探针。只需十五分钟，它能在几天内捕获漂移，而非等到第一个愤怒客户。

探针（Probe）作为端到端验证手段

探针是一组预先设计、答案可以在记录系统中明确查到的问题，用于同时询问已部署的AI和权威数据源，再比对两者答案。它与扫描器的区别在于：扫描器是静态分析，找出“可能腐化”的候选页面；探针是动态测试，直接暴露“实际错误”的输出。探针问题必须满足两个条件：一是答案是事实而非观点或摘要，二是答案能从记录系统中唯一确定。每个不匹配都构成一个可归因的腐化事件——AI给出的错误答案本身就能反向定位到产生它的那个页面。文中诊所的12个探针返回7个不匹配，映射到24个坏页面中的9个；而剩余15个页面完全没有探针覆盖，这提示它们可能根本没有保留价值。每周运行探针只需十五分钟，能在客户投诉之前捕获漂移。

分诊：每个发现实际该做什么

直觉是修复一切。不要。按此顺序修复，并根据行的类别选择操作。

发现	操作	时间
幽灵页面（服务/人员已消失）	删除文件。 不要归档——归档文件会被重新索引。	2分钟
分叉（两个答案，一个问题）	选择规范页面，将另一个的独特内容粘贴进去，删除重复	15分钟
有过时事实且有命名来源	从来源更正，更新verified_at	5分钟
有过时事实但无来源	找到负责人，获取数字，先在源系统中写入	30分钟
无负责人的孤儿	指定负责人或删除。没有第三个选项。	5分钟
过时但真实	更新verified_at并记录已检查	1分钟

诊所的24个页面共花了3小时40分钟，大部分是六个分叉。两周后，重新运行12个探针得到0个不匹配，“错误价格”投诉停止。

重新索引很重要：任何删除后，强制重新嵌入。仍在向量存储中的已删除文件是逃过驱魔的幽灵。

重新嵌入（Re-embedding）与向量库残留

删除源文件并不等于从向量数据库中删除对应的嵌入。RAG系统的向量库是独立存储的，文档被删除后，其嵌入向量可能仍然留在索引中，继续被检索命中——文中称之为“逃过驱魔的幽灵”。因此，每次删除或合并页面后，必须强制触发重新嵌入流程，确保向量库与源文档同步。孤儿页面之所以危险，部分原因也在于此：即便无人维护，它仍被索引、仍可检索。同理，幽灵页面不能“归档”而必须删除，因为归档文件往往仍会被索引管道扫描到。重新嵌入应作为删除操作的标准后续步骤写入运维流程，而非可选项。

每月数字告诉你是否有效

月份: ____________________
总页面数:                    ____
本月验证页面数:              ____   （目标：≥知识库25%，完整周期≤4个月）
无负责人页面:                ____   （目标：0）
活跃探针问题:                ____   （目标：≥12）
探针不匹配:                  ____   （目标：0）
最常检索的20页中位验证天数:  ____   （目标：<90）
已删除幽灵页面:              ____
已合并分叉:                  ____

中位天数那一行是最需要关注的。如果你最常检索的20个页面超过90天未验证，你的AI正在自信地描述你业务的旧版本——而你会从客户那里发现，而非仪表盘。

信任知识库前的十行检查

[ ] 每个页面都有owner、source_of_truth、verified_at
[ ] 没有负责人是人名
[ ] 每个含数字的页面都说明数字来源
[ ] 没有页面在没有日期的情况下说“当前”、“现在”或“截至”
[ ] 没有两个页面对同一问题给出不同答案
[ ] 没有页面描述今天无法购买的服务
[ ] 没有页面提到已离职的人
[ ] 定义了12个探针，每个都能从记录系统回答
[ ] 每周对运行中的代理运行探针，48小时内分诊不匹配
[ ] 每次删除后强制重新嵌入

这些都不是提示词工程。提示词工程改变模型说话的方式。文档腐化改变它相信的内容，没有任何指令能让模型怀疑一份读起来完美的文档。

诊所的修复不是更好的提示词。而是删除24个文件并添加三行front matter。