技术思考问题38：企业知识库越大为何还答错？

企业知识库堆得越多，客服为什么越答错？

知识越多不等于答案越可信，边界失守才是真风险。

[读者] 正在做企业知识库与客服 RAG 的架构师
[痛点] 文档越接越多，答案却越难解释、越容易越权
[现在读] 因为检索增强已经进入权限与生命周期治理阶段
[读完] 能设计先过滤、可追溯、可拒答的知识库 V1/V2

[旧方案] 把所有文档切片入库，按相似度召回
    |
    v
[新需求] 多租户、多版本、跨项目权限、过期制度
    |
    v
[冲突] 检索只优化相关性，不治理权属与时效
    |
    v
[后果] 召回越多，越可能把过期或越权内容送进答案

我是老李，做企业知识库和客服系统。任务是让客服机器人基于制度、产品和工单文档回答客户问题。

一开始团队的想法很直接：文档越多，覆盖越全；切片越细，召回越高。直到客服把一份旧制度、另一个项目的报价和当前活动文档混在一起回答，问题才暴露。

知识量能代表可信度吗？

如果检索结果本身不属于当前租户、不是当前版本、已经过期，相似度再高又有什么用？

继续只堆文档、不补权限和生命周期，会得到更聪明的客服，还是更难追责的答案？

01、故事

现场是一个多项目客服知识库：产品手册、价格政策、售后规则、项目合同摘要都进了同一个向量库。最初只服务一个项目，权限简单，文档也少。

业务扩展后，同一套机器人要服务多个租户。运营希望“多接文档”，研发希望“少改链路”，客服希望“回答更快”。三个目标叠在一起，最容易被省略的就是登记、过滤和证据链。

V1 很快上线：上传、切片、向量化、相似度召回、拼接提示词。它解决了“找不到资料”的问题，却留下一个更麻烦的问题：找来的资料不一定该给这个用户看，也不一定还是有效版本。

这就是逆向思维的入口：先问答案可能怎样错，再反推知识体系必须具备哪些控制。也是能力圈的提醒：资料知道什么、不知道什么，模型不能替它越界推断。

先问何处错
再定何可控
知识有边界
答案才可信

02、问题

旧方案失效不在“召回率低”，而在“可信边界缺失”。业务影响是客服答案无法解释来源，跨项目问题可能泄露权限内信息，过期制度会被当作当前规则。

技术表现有四个：文档没有租户字段；版本只靠文件名；有效期没有结构化；检索先算相似度，权限过滤放在生成前甚至没有。

可验证的完成标准可以写成四条：任一答案能回到具体文档与版本；越权文档在检索前被过滤；过期文档不进入当前答案；低置信问题能拒答或转人工。

这些标准不是让知识库“更大”，而是让它“更可管”。如果完成不了，文档越多，维护成本与风险暴露面只会同步增长。

失效非不查
失效在越界
标准先立住
规模才有义

03、原理

RAG 的基本链路是检索、增强、生成。微软 RAG 概览强调检索质量与上下文控制，具体能力需按当前官方文档核验：https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview 。关键不是把更多上下文塞给模型，而是把“该用的上下文”筛出来。

反直觉判断：知识库的可信度不由文档总量决定，而由权属、版本、有效期、权限和证据链共同决定。检索结果越多，如果没有治理，噪音和越权面也越大。

这对应芒格的能力圈：模型只能基于被允许、仍有效、可追溯的资料回答；资料没有覆盖的问题，应承认不知道，而不是用相似文本补洞。逆向思维则要求先列出错误答案的形态：越权、过期、版本冲突、无引用、过度推断。

所以知识库要像数据产品一样管理生命周期：登记、发布、生效、过期、下线、审计。否则它只是一个更大的文本池，不是一个可运营的知识系统。

相似非许可
召回非可信
能力有边界
拒答也是答

04、架构

[输入] 客服问题 + 租户/项目/角色
    |
    v
[模块] 权限过滤器 + 版本解析器 + 混合检索器
    |
    v
[数据/状态] 文档租户、版本、有效期、权限标签
    |
    v
[处理] 先过滤，再召回与重排，附引用与置信判断
    |
    v
[输出] 有证据答案 / 拒答 / 转人工

边界是：权限过滤必须在召回前完成；版本解析必须绑定业务时间；引用必须回到文档片段。收益是答案可解释、越权面收窄、过期内容可下线。代价是要维护元数据、回归集和人工兜底。

适用条件是文档有明确租户与权限来源；如果权限本身混乱，先治理权限源，不要把复杂度全压给检索层。对于公开知识，可放宽权限过滤，但版本与有效期仍不能省。

先滤后召回
先权后相似
状态随文走
答案有来路

05、实战一次

环境：Python 3.11，标准库实现最小 V1。依赖为零，配置写在代码内。核心目标是先跑通“登记—过滤—召回—引用”的闭环。

from dataclasses import dataclass
from datetime import date

@dataclass
class Doc:
    doc_id: str
    tenant: str
    version: int
    valid_to: date
    acl: set[str]
    text: str

DOCS = [
    Doc('d1', 't1', 2, date(2026, 12, 31), {'agent'}, '退款需在签收后七天提交申请'),
    Doc('d2', 't1', 1, date(2024, 12, 31), {'agent'}, '退款需在签收后三天提交申请'),
    Doc('d3', 't2', 1, date(2026, 12, 31), {'agent'}, '跨项目报价仅限本项目客服查看'),
]

def search(question: str, tenant: str, role: str, today: date):
    allowed = [
        d for d in DOCS
        if d.tenant == tenant and role in d.acl and d.valid_to >= today
    ]
    scored = []
    for d in allowed:
        score = sum(1 for ch in set(question) if ch in d.text)
        if score > 0:
            scored.append((score, d))
    scored.sort(key=lambda x: (x[0], x[1].version), reverse=True)
    return scored

if __name__ == '__main__':
    result = search('退款几天内提交', 't1', 'agent', date(2025, 6, 1))
    for score, doc in result:
        print({'score': score, 'doc_id': doc.doc_id,
               'version': doc.version, 'text': doc.text})

启动：python kb_v1.py。请求是租户 t1、角色 agent、问题“退款几天内提交”。未在当前环境实测，以下为预期结果。

示例输出：

score=6 doc_id=d1 version=2

验证点：d2 因过期被排除，d3 因跨租户被排除，d1 作为当前版本返回。V1 已能跑通，但它还没有处理版本冲突解释、低置信拒答和跨文档引用。

先跑通闭环
再暴露缺口
最小可验证
才可谈优化

06、排查

现象一：客服答案引用了另一个项目的报价。怀疑是召回跨租户。检查 search 的过滤顺序与文档字段，证据是 d3 的 tenant 为 t2，但旧链路在召回后才过滤。根因是权限过滤位置错误。修复是把租户与角色过滤前置到候选集生成之前。

现象二：同一退款问题出现“三天”和“七天”两个答案。怀疑是版本冲突。检查文档版本与有效期，证据是 d2 已过期但仍在库。根因是缺少有效期判断与版本优先级。修复是过滤过期文档，并按业务生效时间解析当前版本。

错误尝试： 一开始想用提示词要求模型“不要引用过期文档”。这为什么错？因为模型看到的是已经召回的上下文，它无法知道未传入的权限与有效期；把治理责任推给生成阶段，只会让错误更隐蔽。

现象三：答案没有引用，客服无法复核。怀疑是输出只拼文本。检查返回结构，证据是只有答案没有 doc_id。根因是链路没有证据字段。修复是答案必须带引用，低置信时拒答或转人工。

错在滤太晚
错在证不足
根因先定位
修复才有效

07、优化

基于第 06 章证据形成 V2：第一，文档登记租户、版本、有效期和 ACL；第二，先权限过滤，再混合检索与重排；第三，答案附引用，置信不足时拒答或转人工；第四，建立覆盖正确率、越权和过期知识的回归集。

修改点是新增 resolve_version 与 answer：前者按租户和业务日期取当前有效版本，后者在无候选或分数过低时返回拒答。原因是把“能不能答”和“该不该答”分开处理。

新行为是：过期文档不进入候选；跨租户文档不进入候选；答案携带 doc_id 与 version；低置信问题输出“需人工确认”。验证方式是用固定回归集检查四条：正确引用、越权拦截、过期拦截、拒答触发。

def resolve_version(docs, today):
    valid = [d for d in docs if d.valid_to >= today]
    return max(valid, key=lambda d: d.version) if valid else None

def answer(question, tenant, role, today, min_score=2):
    hits = search(question, tenant, role, today)
    if not hits or hits[0][0] < min_score:
        return {'answer': '需人工确认', 'refs': [], 'reason': 'low_confidence'}
    score, doc = hits[0]
    return {'answer': doc.text, 'refs': [{'doc_id': doc.doc_id,
            'version': doc.version}], 'score': score}

未在当前环境实测，以上为预期行为。优化不以“回答更多”为目标，而以“错得更少、错得可查”为目标。

先权后相似
先证后生成
低信可拒答
系统才可控

08、演进

[同一输入]
    |
    +--[V1] 全库召回后拼接 / 代价：越权、过期、无引用
    |
    +--[V2] 先过滤再召回并附证据 / 代价：元数据与回归集成本
    |
[Trade-off]
得到可追溯与权限边界，失去部分召回自由度，适用于多租户知识库

正确性上，V2 把权限、版本、有效期变成硬约束；稳定性上，拒答与转人工降低错误外溢；复杂度上，需要维护元数据和评测集；成本上，登记与治理是持续投入；适用范围上，多租户、强权限、制度频繁变更的场景收益更明显。

遗留问题是权限源本身可能不准，混合检索的重排策略仍需按业务评测。V2 不是终点，而是把知识库从“文本池”推进到“可运营数据产品”的一步。

旧法求更多
新法求更准
取舍在边界
演进在治理

09、洞见

9.1 知识量不是可信度

反直觉判断：文档越多，答案不一定越可信；没有权属、版本和有效期的文档越多，错误候选也越多。可信度来自可验证的边界，而不是上下文长度。

9.2 权限过滤必须前置

反直觉判断：把权限过滤放在生成前，看似省事，实际把越权风险藏进上下文。先按租户、角色、项目过滤，再做召回与重排，才是可审计的顺序。

9.3 拒答是能力圈的产品化

模型要知道资料“不知道什么”。低置信拒答、无引用不答、转人工兜底，不是能力不足，而是能力圈被写进系统。

9.4 生命周期管理决定长期成本

知识库需要登记、发布、生效、过期、下线、审计。公开页面仅可完整核验标题与概述；文中“90%”来自文章标题措辞，不能当作经验证统计结论。参考：https://cloud.tencent.com/developer/article/2764143 。

多不等于准
权先于相似
拒答有边界
治理见长期

10、系统落地

原来有一个能上传、切片、召回的知识库 V1；本篇新增租户、版本、有效期、ACL、引用、拒答与回归集。

现在能做的，是让客服答案回到具体文档与版本，让越权和过期内容在检索前被挡住，让低置信问题进入人工通道。

还缺的是权限源治理、重排策略评测、文档发布流程和持续回归。下一步先把“文档登记表”作为唯一入口，再把回归集纳入发布门禁，最后按业务反馈调整拒答阈值。

先补元数据
再补回归集
边界进流程
系统可运营

11、小结

Q1 → 知识量能代表可信度吗？不能，权属、版本、有效期与证据链才决定可信边界。
Q2 → 相似度高就能回答吗？不能，未授权或过期内容必须先被过滤。
Q3 → 只堆文档会怎样？越堆越难追责，越可能把错误上下文送进答案。
状态 → 已形成先过滤、可引用、可拒答、可回归的知识库 V2 路径。

问题在边界
答案在证据
优化在顺序
落地在流程

12、作业

12.1 理解题：为什么“文档更多”可能让客服更容易答错？

参考答案：更多文档带来更多候选，如果缺少租户、版本、有效期和权限治理，召回会把不该用或已过期的内容送进上下文；错误不是生成时才发生，而是在检索候选阶段已埋下。

12.2 实战题：给现有知识库补一个最小登记表，应包含哪些字段？

参考答案：至少包含 doc_id、租户/项目、版本、生效时间、失效时间、ACL、来源、负责人、状态。检索前先用租户、角色和有效期过滤，再进入召回与重排。

12.3 排障题：同一制度出现两个答案，如何定位？

参考答案：先查两份文档的版本与有效期，再查当前业务日期和版本解析逻辑；如果过期文档仍被召回，根因在过滤顺序或有效期缺失，修复应前置过滤并附引用。

12.4 架构判断题：低置信拒答会不会降低客服效率？

参考答案：短期可能增加转人工量，但长期减少错误承诺与越权风险。关键是把拒答阈值、转人工入口和回归集一起设计，而不是让模型在能力圈外硬答。

题在验边界
答在找证据
练在改顺序
成在可回归

13、思考

企业知识库的核心矛盾，不是“资料够不够多”，而是“资料该不该被这个用户、在这个时间、以这个版本看到”。逆向思维让我们先列错误答案，能力圈让我们承认不知道；两者合起来，才是知识库的可信边界。

可复用的工程判断是：先治理权属、版本、权限、证据与评测，再谈召回和生成；先过滤，再检索；先引用，再回答；先能拒答，再谈智能。知识库要管得好，不能只堆得大。

先问何处错
再划能力圈
权属先于量
可信方能答