知识摄取任务变绿，用户仍搜不到文档，通常不是“向量库偶尔没命中”这么简单。任务成功只说明代码走到了结束，没有证明源内容枚举完整、解析结果没截断、每个 chunk 都生成向量、索引切到了新版本，也没证明查询链路使用了这版索引。

我会沿六层做证据对账：枚举、抓取、解析、切块/embedding、发布、查询。每层都有输入输出不变量和 manifest。定位从第一个数量或版本不一致的层开始，不先调 top-k。

知识库页面显示“今天更新”，不代表用户现在问问题能检索到今天的内容。源文档变更后，要经过事件发现、抓取、解析、embedding、索引发布、复制与缓存失效。任何一段积压，答案都可能继续引用旧版本。

我把新鲜度定义为 query-visible time - source event time，再拆成各阶段延迟预算。没有源事件时间时，只能报告“平台最近一次成功观测”，不能把抓取时间冒充内容真实更新时间。

很多知识库上线时只做了导入：抓文档、切块、算向量。过几个月后，同一制度的新旧版本一起命中，已离职人员的私有文档仍能被检索，源文件删除了，向量库里还留着片段。问题不在 RAG 算法，而在内容从来没有生命周期。

我把摄取当成一条可发布的数据管道。源系统的 create、update、delete、ACL change 都变成有版本的事件；新索引先在 staging 校验，再切换 current alias；删除和撤权先用 tombstone 立即阻断查询，物理清理由后台完成。

RAG 产品加上“参考资料”区域后，答案看起来会可信很多。实际抽查时经常发现：链接确实相关，却没有支持模型写出的数字；文档说的是测试环境，答案扩展到了生产；三条引用里两条互相冲突，模型选了表达最顺的一条。

引用是展示形式，证据关系才是可验证结构。我会在最终答案前增加 Evidence 层：先拆出可核查 claim，再把每个 claim 与具体 source/version/span 对齐，标注支持、冲突或不足，最后由发布策略决定保留、降级措辞或拒答。

知识问答效果不好时，团队第一反应通常是换 embedding、调 top-k 或升级模型。我在数据平台场景里遇到的更多情况是：被索引的元数据本身不完整、没有版本，甚至彼此冲突。检索与生成只能重新排列现有信息，不能凭空修复事实链。

RAG 的上限取决于它能拿到什么证据。表名和描述只是最薄的一层；对象身份、来源、有效时间、负责人、血缘、权限和采集状态，决定答案能否从“听起来合理”走到“可以复核”。

做 RAG 时，第一个容易陷进去的参数是 chunk_size。500 字还是 1000 字、overlap 取 50 还是 100，大家常凭几个问答效果争论。这个讨论缺少一个前提：我们希望每个 chunk 保住什么证据。

我不会先从字数出发，而是整理真实问题，为每个问题标注“最小充分证据”。切块策略能让这些证据稳定被召回，条件和结论没有被拆散，同时不带进大段无关内容，才算有效。

把文档切块、算 embedding、写进向量索引，再接一个生成模型，几天就能搭出知识问答 Demo。这个 Demo 会让人产生一个错觉：只要相似度搜得准，企业知识库就建成了。实际运行一段时间后，问题往往不在向量库，而在知识从哪里来、何时失效、谁能看、答案引用了什么。

我把向量检索当成候选召回器。它回答的是“哪些片段在表示空间里接近这个问题”，不负责证明片段仍然有效，也不负责解决权限、冲突和业务口径。知识库是包含摄取、治理、检索、生成和反馈的一整条链路。