软件不是文件：KDC 说找到材料 ≠ 获得知识
企业 AI 项目里，「建知识库」往往就是这条流水线：
上传文件 → 解析 → 切块 → 向量化 → 相似度检索 → 注入上下文 → 生成回答。
链路跑通了，团队就觉得「知识库建好了」。但 vivo 肖博在 InfoQ 上的 KDC 系列第二篇 用一个售后案例说明：材料可以被找到，不等于系统知道了什么。
反例：RAG 全绿，答案却错了
用户问售后 Agent：
活动期间购买的商品还没发货，取消订单会收手续费吗？
系统从知识库检索到一段高度相关的退款政策——活动订单取消要收服务费。检索得分高，引用片段贴切，模型也忠实依据片段作答。
答案是错的。
被召回的是半年前旧版政策。新政策已取消这项费用，但旧 PDF 仍在共享目录和向量索引里。新旧标题相似，旧版文字甚至与用户问题语义匹配更高。
从 RAG 视角，这次没有明显故障：解析、切块、Embedding、检索、生成都成功。系统找到了相关材料，却没有获得当前可用的知识。
「知识库」这个词掩盖了不同问题
文件管理解决保存与授权；搜索解决「怎么找到材料」；向量检索解决语义相近；RAG 解决「怎么装进上下文」。它们都参与知识系统，但单独都没回答：
- 这段内容来自谁？
- 当前是否有效？
- 经过什么验证？
- 与其他来源是否冲突？
- 适用于哪些对象、时间和业务条件？
- 能否用于当前判断（尤其高影响判断）？
旧政策被检索出来，召回系统完成了职责。真正缺失的是版本判断、有效性验证、冲突处理和适用边界。把一切归因于「RAG 不准」，会掩盖知识治理本身的责任。
Representation ≠ Knowledge
KDC 延续上一篇的链路：
现实 → 现实模型 → 表示（Representation）数据库、文档、API、事件、日志、向量、图谱、模型上下文——都是表示。表示可以承载知识，但表示不自动成为知识。
几个常见误区：
| 常被当成知识 | 实际是什么 |
|---|---|
| 文档表示，可能是制度、过期规则或草案 | |
| 数据库记录 | 事实记录，refund_fee=0 缺版本和适用范围就不知道能否用于当前订单 |
| 向量 / Embedding | 相似性表示，不携带来源权威性、生效时间、冲突状态 |
| RAG 片段 | 本次检索的上下文，说明「可能相关」而非「已验证」 |
| 知识图谱 | 结构化关系，无来源和证据仍是数据 |
| Memory | 历史线索，「曾喜欢小屏」不一定是当前偏好知识 |
从文件到文本、文本到向量、向量到上下文，只是表示形式变化。格式改变不等于认知成果已经形成。
KDC 如何定义「知识」
KDC 当前采用的操作性定义：
知识是已经验证、可复用，并能够降低预测、推理、决策或行动不确定性的认知成果。
四个部分不可省略：
- 认知成果 — 对事实、规律、方法、经验、约束、关系的把握，不是原始数据本身
- 需要验证 — 有证据、实践、规则、共识或人工确认；模型说得流畅、相似度得分高、被很多人转发，都不是验证
- 需要可复用 — 在明确条件下可被未来任务再次引用；没有适用边界的「知识」最容易在错误场景被复用
- 降低不确定性 — 让后续判断少猜一点；只保存检索展示却不能支撑任何判断的内容，对工程设计帮助有限
知识成熟度：不是只有「是/否」
AI 系统会持续产出总结、推测和建议；业务现实也在变。要求一切入库前就最终确定不现实；把模型输出直接写入知识库同样危险。
KDC 引入知识成熟度：
Hypothesis → Candidate Knowledge → Verified Knowledge → Canonical Knowledge这条链路可以回退：新证据推翻已验证知识、现实变化导致过期、冲突暂时阻断使用。
在开头的案例中，旧政策不是从世界上消失——它仍是历史材料，可解释过去订单。但对当前退款判断，应标记为过期或被新版本替代，而不是与现行政策以相同权重进入上下文。
成熟度会改变系统行为：Hypothesis 触发搜索验证；Candidate 可进低风险推理；Verified 支撑稳定决策；高风险行动可能需要更强证据和人工确认。
知识对象：进入软件后要能治理
定义「什么是知识」之后，工程还要解决：知识如何标识、引用、追溯和演化。
KDC 用**知识对象（Knowledge Object）**表达一组不能继续隐含的责任：
- 身份、来源、语义、上下文、证据、版本、成熟度
- 冲突状态、生命周期、责任与权限
退款场景不应只存「活动订单取消需手续费」这段文本，还应知道：哪版规则、谁发布、何时生效、适用哪些活动、与哪条新政策冲突、当前是否仍有效。
对象化不是为了把制度条款包装成复杂 JSON，而是让系统能回答：当前知道什么、为什么相信、能否用于当前任务。
RAG 的合理位置
明确知识边界不会削弱 RAG——反而让你更准确地使用它。
RAG 擅长：从大量材料召回相关内容、装配企业私有或最新材料、为回答提供可展示引用、降低模型只依赖参数记忆的风险。
完整知识系统还要处理：来源是否可信、版本是否有效、多源是否冲突、内容成熟度、权限边界、结论被哪些推理使用、现实反馈是否验证或推翻结论。
在 KDC 中，RAG 更适合定位为知识流或知识运行时的局部机制——负责材料召回和上下文装配，与搜索、图谱、规则系统、文档管理和人工审核协同，不必独自承担整个知识生命周期。
开头案例的更准确归因：不是「向量检索没用」，而是只按相似度召回，检索前后没有版本、有效期、冲突和适用范围过滤。修复也不只是调切块和阈值，要补知识身份、版本关系、来源权威性、生效状态和验证流程。
实践起点：一张 Knowledge Card
不必先建完整知识平台，也不应把所有数据「知识化」。更现实的起点：从一条会被反复使用、影响重要判断、一旦错误就有明显风险的内容开始——退款规则、审批条件、合同风险、项目经验或客户偏好。
先问六个问题：
- 来源和责任方是否明确？
- 有什么证据、规则、实践或反馈支持？
- 适用于什么场景，边界外哪里不适用？
- 当前是 Hypothesis、Candidate、Verified 还是 Canonical？
- 是否有版本、时效和冲突处理？
- 是否会被复用并降低不确定性？
然后三选一：对象化（高价值/高风险，进入知识生命周期）、保留为来源（材料有价值但未形成稳定认知）、暂不纳入（治理成本大于复用收益）。
Knowledge Card 的价值不在表格本身，而在于把「我们有这份文件」改写成「系统知道什么、为什么相信、什么时候可以用」。
对你意味着什么
企业 AI 当然需要文件、数据库、向量检索、知识图谱和 RAG。问题从来不是要不要这些技术，而是不要把局部机制的职责扩大成完整知识架构。
找到材料 ≠ 获得知识
相关片段 ≠ 可靠依据
进入上下文 ≠ 可以用于行动KDC 不是要一切变复杂，而是让高价值、高复用、高风险的认知具备最基本的来源、证据、版本、成熟度和生命周期。只有这样，AI 系统才可能知道自己当前知道什么，也知道哪些内容还不能被当作知识。
知识能被引用之后，下一问题是：如何基于知识形成判断？为什么选择某个行动？工具调用怎样从「模型想做」变成可解释、可审计、可治理的业务能力？——那是 KDC 第三篇「行动治理」的主题。
原文： InfoQ — 软件不是文件：KDC 的知识工程主张
评论