14.1.7 为什么“有知识库”不等于“知识真的可用”？

先给结论：知识库可用性不取决于“是否存了数据”，而取决于“是否能被稳定召回、被正确过滤、被及时更新”。

很多团队做完第一版系统后，会很自然地产生一种满足感：
“文档都已经入库了，知识库已经建好了。”

但真正上线后，你会发现“有知识库”和“知识真的可用”之间差得非常远。
因为从用户视角看，知识库是否可用，只取决于一件事：
在当前场景下，它能不能稳定给出正确、合规、最新的证据。

知识库为什么会“看起来有，实际上不可用”

1. 召回不可控

文档进了库，不代表能稳定搜到。
如果典型问题总是检索不到关键证据，或者同一个问题换个说法就漂，那这个知识库对用户来说就是不可用的。

这类问题很常见，因为“入库成功”只是数据层面的状态，不代表检索层面的能力已经成立。

2. 权限与范围不可控

生产环境里，知识不仅要“能搜到”，还要“只能搜到该看的那部分”。

这里的范围控制，往往包括：

• 租户隔离
• 产品线隔离
• 版本隔离
• 套餐隔离
• 区域或国家范围隔离

如果这些边界没有进入检索逻辑本身，而只是依赖前端展示层处理，那么系统表面上能跑，实际上并不可靠。

3. 数据更新不可控

很多知识库刚建好时看起来没问题，但用一段时间后开始明显变差。
最常见的原因就是更新链路没设计好：

• 旧文档没有及时失效
• 新版本没有覆盖旧索引
• 重复内容越来越多
• 删除后的内容仍然能被召回

这时候问题不是“知识不够多”，而是“知识开始失真”。

怎样才算“真的可用”

你可以用下面三个问题判断：

1. 高频问题是否能稳定召回正确证据
2. 不同用户是否只看到自己权限范围内的内容
3. 文档更新后，结果是否能在合理时间内同步变化

只要其中任意一项不成立，就不能把这个知识库称为真正可用。

一个更落地的验收方式

如果你想做最小可用性验收，可以这样检查：

1. 选一组高频问题，看是否稳定命中正确证据
2. 换不同身份和不同业务条件，观察检索结果是否正确收缩
3. 更新一条知识后，验证旧内容是否退出结果集
4. 删除一条知识后，验证它是否真的不再被召回

通过这四步，你看到的就不再是“知识库有没有建起来”，而是“知识能不能真正被系统可靠使用”。

一个更可靠的实现思路

知识库要想真正可用，至少要同时建设下面几层：

• 数据层：清洗、去重、版本管理
• 索引层：切块、metadata、可过滤字段设计
• 检索层：召回、过滤、必要时重排
• 更新层：增量同步、失效处理、回滚能力
• 验证层：高频问题回归测试

例如，把权限和范围前置到检索过滤中：

results = client.query_points(
    collection_name="docs",
    query=query_vector,
    query_filter={
        "must": [
            {"key": "tenant_id", "match": {"value": tenant_id}},
            {"key": "product", "match": {"value": product_name}},
            {"key": "doc_status", "match": {"value": "active"}},
        ]
    },
    limit=8,
)

关键不在于你具体用哪一家向量库，而在于这个原则：
权限、版本、状态、业务范围这些边界，必须进入检索层本身。

一句话总结

有知识库只是起点。只有做到“可召回、可过滤、可更新”，知识才算真的可用。