作者：vivo 肖博
AI 合作者：ChatGPT（GPT-5.5）
创作模式：Human-led, AI-collaborated
责任声明：文章观点、理论体系及最终内容由作者负责；AI 参与讨论、推演、表达优化及部分内容生成。
研究说明：知识驱动计算（Knowledge-driven Computing, KDC）是我们正在提出和持续打磨的一套 AI 应用软件工程理论，目前仍处于开放研究阶段。上一篇讨论了应用软件为什么应该从领域现实出发，以及数据、文档、API 和事件为什么只是现实的数字表示。这一篇继续追问：表示在什么条件下，才能成为 AI 系统可以信任和复用的知识？
本文摘要：检索到相关材料，并不等于系统获得了可以用于判断的知识。本文区分 Representation、Knowledge 和 RAG 的职责，提出知识对象、来源证据、成熟度、版本与适用边界等工程要求，说明认知成果如何被验证、引用和持续更新。
KDC 系列文章：
继续说案例。
用户向售后 Agent 提出一个问题：
我在活动期间购买的商品还没有发货，现在取消订单会收手续费吗？
系统从企业知识库中检索到一段高度相关的退款政策。文档写得很清楚：活动订单取消时，需要收取一定比例的服务费。检索得分很高，引用片段与问题直接相关，模型也忠实地依据片段生成了回答。
但答案是错的。
被检索到的是半年前的旧版政策。新政策已经取消了这项费用，只是旧文件仍然保留在共享目录中，也仍然存在于向量索引里。新旧政策标题相似，旧版文字与用户问题的语义匹配甚至更高。
从 RAG 链路看，这次处理没有明显故障：文件解析成功，切块成功，Embedding 生成成功，相似度检索成功，模型也没有脱离上下文自由发挥。
然而，系统找到了相关材料，却没有获得当前可用的知识。
这个区别是企业 AI 系统中最容易被忽略、也最可能影响后续行动的区别之一。
“知识库”这个词经常掩盖了不同问题
在很多 AI 项目中，“建设知识库”通常意味着完成下面这条流程：
上传文件 -> 解析文本 -> 文档切块 -> 生成向量 -> 相似度检索 -> 注入模型上下文 -> 生成回答这条流程解决了一个真实而重要的问题：如何让模型在回答时访问外部材料，而不是只依赖参数中压缩的信息。对于企业私有文档、快速变化的制度、项目资料和专业内容，RAG 是非常有价值的工程机制。
但“材料可以被找到”与“系统知道了什么”不是同一个问题。
文件管理关注内容如何保存、共享和授权。搜索关注用户如何找到相关材料。向量检索关注语义上相似的内容如何被召回。RAG 关注相关材料如何进入模型上下文。这些机制都参与知识系统，却没有单独回答：
这段内容来自谁？
它当前是否有效？
它经过什么验证？
它与其他来源是否冲突？
它适用于哪些对象、时间和业务条件？
它能否被用于当前判断，尤其是高影响判断？
使用后的现实结果是否支持它？
如果系统无法回答这些问题，“知识库”可能只是一个可以被模型检索的材料库。
这并不是文字上的挑剔。旧政策被检索出来时，召回系统完成了自己的职责。真正缺失的是版本判断、有效性验证、冲突处理和适用边界。把所有问题都归因于“RAG 不准”，会掩盖知识治理责任本身。
从现实到表示，还没有自然地走到知识
上一篇文章建立了下面这条链路：
Domain Reality -> Reality Model -> Representation现实经过观察和建模，进入数据库、文档、API、事件、日志、图片、向量、图谱和模型上下文。这些对象都是表示（Representation）：它们以不同方式编码现实。
表示可以承载知识，但表示并不自动成为知识。
Representation 可以承载 KnowledgeRepresentation 不等于 Knowledge退款政策 PDF 是表示。它可能承载当前有效的退款规则，也可能承载已经废止的条款、未经批准的草案、错误描述或只适用于特定时期的临时安排。
数据库记录也是表示。refund_fee = 0 可以记录一个配置事实，但如果缺少适用范围、版本、生效时间和业务解释，系统仍然不知道它是否适用于当前订单。
Embedding 也是表示。它把内容编码到向量空间，帮助系统计算相似性，但相似性无法自动证明真实性、有效性或适用性。
甚至模型生成的总结也是表示。它可以准确压缩原文，也可能遗漏条件、混合不同版本，或者把推测写成确定结论。
这意味着，从文件到文本、从文本到向量、从向量到上下文，都只是表示形式的变化。格式改变不等于认知成果已经形成。
先用反例划清知识的边界
在给知识下定义之前，更可靠的方法是先检查那些经常被称为“知识”的对象，为什么又不能直接等同于知识。
PDF 不是知识
PDF 是一种文档表示。它可以承载制度、经验、方法和事实，也可以承载噪声、广告、过期规则和未经确认的观点。同一个 PDF 对文件系统而言是文件，对搜索引擎而言是索引材料，对模型而言是上下文，对员工而言可能是制度依据。
真正需要判断的不是它是不是 PDF，而是其中哪些认知成果仍然成立。
数据库不是知识
数据库保存事实记录、约束和关系，但记录不会天然解释自己对当前目标意味着什么。
订单表可以说明某位用户买过三次影像旗舰手机。“该用户在换机时更重视影像能力”则是对商品、时间、行为和场景进行解释后形成的候选认知。前者可以作为来源，后者才开始接近知识。
向量和 Embedding 不是知识
向量可以表达统计相关性和语义邻近性，却不会自动携带来源权威性、证据完整性、生效时间、冲突状态和行动边界。
两个片段很相似，只能说明它们在某个表示空间中接近，不能说明哪个更新、哪个正确，也不能说明它们能否共同成立。
RAG 片段不是知识
RAG 片段是某次检索为当前任务召回的上下文。它首先说明“这段材料可能与问题相关”，而不是“这段材料已经被验证”。
相关性是知识使用的必要条件之一，但不是充分条件。高相关的过期政策，可能比低相关的新政策更危险，因为它会让错误回答显得更有依据。
知识图谱不是知识的全部
知识图谱能够表达实体、属性和关系，是很重要的知识表示机制。但一条图谱关系如果没有来源、上下文、证据、版本和有效期，仍然可能只是结构化关系数据。
图结构解决“对象如何连接”，不自动解决“为什么相信这条连接”。
Memory 不是 Knowledge
记忆（Memory）强调历史、时间、经验和演化轨迹。用户过去说过“我喜欢小屏手机”，是一条值得保留的历史线索。它不一定是当前仍然有效的用户偏好知识。
知识可以进入记忆，记忆也可以为知识提供验证材料，但两者关注点不同。知识更关心当前能够复用的认知成果，记忆更关心过去如何影响未来。第四篇会专门讨论这个边界。
这些反例指向同一个结论：知识不能由存储介质、索引方式或调用机制定义。否则，任何被保存、向量化或检索出来的内容都会被默认升级为知识。
KDC 如何定义知识
基于前面的反例，KDC 当前采用下面这个定义：
知识（Knowledge）是已经验证、可复用，并能够降低预测、推理、决策或行动不确定性的认知成果。
这是 KDC 当前阶段的理论定义，当前成熟度为 Derived，而不是一个已经成为行业共识的最终认识论定义。它的目标也不是解决哲学上的所有知识问题，而是给 AI 应用软件提供一个可以进入工程设计的操作性边界。
这个定义包含四个不可省略的部分。
知识是认知成果
知识不是现实本身，也不是原始数据，而是系统或组织对事实、规律、方法、经验、约束、关系或模式形成的认知性把握。
订单金额 = 1000 元 是事实记录。“该订单满足无手续费取消条件”是结合订单状态、活动规则、支付情况和当前政策后形成的认知结果。
认知成果可以来自科学研究、工程实践、业务规则、组织经验、人工总结、模型推理或现实反馈。来源不同，不代表它们具有相同可信度，但它们都需要经过解释才能进入知识讨论。
知识需要验证
“已经验证”不等于永久、绝对正确。它意味着这个认知成果已经在某种成熟度上获得证据、实践、实验、规则、共识、反馈或人工确认的支持。
退款政策可以通过正式发布流程、制度 Owner 确认、生效日期、版本状态和业务系统配置交叉验证。用户偏好则可能通过多次选择、明确表达和后续反馈获得支持。不同知识需要不同验证方式。
模型说得流畅不是验证，相似度得分高不是验证，被很多人转发也不是验证。这些信号可以参与判断，但不能替代证据。
知识需要可复用
知识可以有很窄的适用边界，但不应只是一次对话中的临时输出。它应该能够在明确条件下，被未来的任务、判断或行动再次引用。
“这个用户的这笔订单现在不能退款”可能只是一次性结论。“已支付但未发货的普通订单，在用户未使用权益且不命中风控时可以无手续费取消”则更接近可复用规则。
可复用不意味着无限泛化。恰恰相反，复用需要知道适用对象、时间、地区、产品、渠道和例外条件。没有边界的“知识”最容易在错误场景中被复用。
知识需要降低不确定性
这是该定义中最关键的功能性条件。
知识之所以有价值，不是因为它被放进某种高级存储，而是因为它能够让未来的预测、推理、决策或行动少一些不确定性。
稳定的退款规则降低客服判断和用户决策的不确定性。经过验证的故障模式降低排障的不确定性。组织确认的项目风险降低资源安排的不确定性。成熟的工程规范降低实现和评审的不确定性。
如果一段内容被保存、检索和反复展示，却不能帮助任何后续判断，也不能说明自己在什么条件下成立，那么把它称为知识，对工程设计没有太大帮助。
从“正确或错误”转向知识成熟度
知识不是只有“是”与“不是”两个状态。
AI 系统会持续产生总结、分类、推测和建议。业务现实也会持续变化。要求所有内容在进入系统前就达到最终确定状态并不现实。把所有模型输出直接写入知识库同样危险。
KDC 因此引入知识成熟度（Knowledge Maturity）：
Hypothesis -> Candidate Knowledge -> Verified Knowledge -> Canonical Knowledge这条链路不是单向升级。新证据可能让已验证知识回退为候选状态，现实变化可能让知识过期，冲突可能暂时阻断使用，正式制度也可能被新版本替代。
成熟度真正重要的地方，在于它能够改变系统行为。Hypothesis 可以触发搜索和验证，Candidate Knowledge 可以进入低风险推理，Verified Knowledge 可以支撑稳定决策，高风险行动则可能要求更强证据和人工确认。
在开头的案例中，旧政策并不是因为变旧就从世界上消失。它仍然是历史材料，也可以用于解释过去的订单。但对于当前退款判断，它应该被标记为过期或被新版本替代，而不是与现行政策以相同权重进入上下文。
flowchart TB M[“文档 / 数据 / API / RAG 片段“] --> R[“Representation<br/>数字表示“] R --> S[“来源与证据“] S --> V[“版本与有效期“] V --> B[“适用边界与冲突处理“] B --> K[“Knowledge Object<br/>可治理知识对象“] K --> H[“Hypothesis“] H --> C[“Candidate Knowledge“] C --> VK[“Verified Knowledge“] VK --> CK[“Canonical Knowledge“] CK -.->|现实变化 / 新证据| C VK -.->|证据被推翻| H图 2：从 Representation 到可治理 Knowledge Object
知识进入软件之后，需要成为可管理的对象
定义知识解决的是“什么可以被称为知识”。工程系统还要解决另一个问题：知识如何被标识、引用、追溯和演化。
KDC 把知识进入 AI 应用软件后的对象化表达称为知识对象（Knowledge Object）。知识对象不是一种固定数据库 Schema，也不是要求企业把所有内容搬进新的存储系统。它表达的是一组不能继续隐含的工程责任。
一个可被运行时引用的知识对象，至少需要考虑：
身份：系统如何稳定引用同一认知成果
来源：它来自哪份文档、数据、反馈或人工判断
语义：它表达什么事实、规则、方法或经验
上下文：它适用于什么对象、时间和业务条件
证据：为什么可以相信它
版本：它如何被修改、替代或回退
成熟度：它当前可以被怎样使用
冲突状态：是否存在相互矛盾的来源或结论
生命周期：它当前是候选、有效、过期还是废弃
责任与权限：谁负责确认，谁可以访问和使用
用对象化方式表达知识，不是为了把一段制度条款包装成复杂 JSON，而是为了让系统回答三个问题：当前知道什么，为什么相信，以及这个认知能否用于当前任务。
在退款场景中，系统不应只把“活动订单取消需收取服务费”作为一段文本保存。它还应该知道：这是哪个版本的规则，谁发布，何时生效，适用于哪些活动，与哪条新政策冲突，当前是否仍有效，哪些历史订单仍然适用。
只有这些责任能够被表达，检索结果才可能从“相关片段”进一步变成“当前任务可以引用的知识证据”。
RAG 的合理位置：找到材料，而不是替材料完成验证
明确知识边界，并不会削弱 RAG 的价值。恰恰相反，它能让我们更准确地使用 RAG。
RAG 擅长解决：
从大量材料中召回与问题相关的内容
把企业私有或最新材料装配进模型上下文
为回答提供可展示的引用片段
降低模型完全依赖参数化记忆生成内容的风险
但完整知识系统还需要处理：
来源是否可信
版本是否有效
多个来源是否冲突
内容属于什么成熟度
是否满足当前任务和权限边界
哪些结论被哪些推理使用过
使用结果是否被现实反馈验证或推翻
因此，在 KDC 中，RAG 更适合被定位为知识流或知识运行时的局部机制。它负责材料召回和上下文装配，可以与搜索引擎、知识图谱、规则系统、文档管理和人工审核协同，但不必独自承担整个知识生命周期。
文章开头的错误也就有了更准确的归因：不是“向量检索完全没用”，而是系统只按相似度召回片段，没有在检索前后加入版本、有效期、冲突和适用范围过滤。
修复方式也不只是继续调切块大小和相似度阈值。团队需要补上知识身份、版本关系、来源权威性、生效状态和验证流程。检索质量仍然重要，但它不再是唯一质量。
这个定义解决的是软件工程问题
KDC 对“不确定性降低”的讨论与信息论有关，但关注的不是通信过程本身，而是系统在未来预测、推理、决策和行动中的认知不确定性。
KDC 也借鉴知识管理对知识形成、传播和复用的讨论，但不试图解决完整的人类认识论问题。这里真正关心的是：已经形成一定可信度的认知成果，如何进入 AI 应用软件，成为带有来源、证据、成熟度、版本和适用边界的知识对象，并被推理和行动链路安全地引用。
因此，KDC 不是重新发明“知识”这个概念，而是把知识定义转化为一个软件工程问题：系统当前知道什么，为什么相信，什么时候可以使用，以及现实反馈如何修正它。
实践：为一个高价值内容建立 Knowledge Card
团队不需要先建设完整知识平台，也不应该把所有数据都“知识化”。更现实的起点，是从一个会被重复使用、可能影响重要判断，或者一旦错误就会产生明显风险的内容开始。
它可以是一条退款规则、一项审批条件、一份合同风险判断、一条项目经验或一个客户偏好。
先检查六个问题：
1. 它的来源和责任方是否明确？
2. 有什么证据、规则、实践或现实反馈支持它？
3. 它适用于什么场景，又在哪些边界外不适用？
4. 它当前属于 Hypothesis、Candidate、Verified 还是 Canonical？
5. 它是否有版本、时效和冲突处理机制？
6. 它是否真的会被复用，并降低预测、推理、决策或行动的不确定性？
然后形成一张最小 Knowledge Card：
完成后，不要默认它一定要成为知识对象。团队应该做出三个明确判断之一：
对象化：内容高价值、可复用或高风险，值得进入知识生命周期
保留为来源：材料有价值，但尚未形成稳定认知成果
暂不纳入：内容价值低、噪声高、缺少边界，治理成本大于复用收益
Knowledge Card 的价值不在于表格本身，而在于把“我们有这份文件”改写为“系统知道什么、为什么相信、什么时候可以使用”。
如果团队发现来源、证据、适用边界和成熟度大多无法填写，这不是要求立刻补齐所有字段，而是在提醒：当前系统管理的可能仍然只是材料和表示，尚未形成可以进入重要判断的知识。
AI 系统需要的不是更多材料，而是更可靠的认知成果
企业 AI 系统当然需要文件、数据库、向量检索、知识图谱和 RAG。问题从来不是要不要这些技术，而是不要把局部机制承担的职责扩大成完整知识架构。
文件解决保存和访问，向量解决相似度表示，检索解决材料发现，RAG 解决上下文装配，图谱解决关系表达。知识则回答另一组问题：这个认知成果是否经过验证，能否复用，适用于什么边界，是否能降低未来判断和行动的不确定性。
因此：
找到材料 ≠ 获得知识相关片段 ≠ 可靠依据进入上下文 ≠ 可以用于行动KDC 对知识的要求不是把所有内容变得复杂，而是让高价值、高复用和高风险认知具备最基本的来源、证据、版本、成熟度和生命周期。只有这样，AI 系统才可能知道自己当前知道什么，也知道哪些内容还不能被当作知识。
但当知识能够被系统引用后，新的问题马上出现了：系统如何基于这些知识形成判断？为什么选择某个行动？一次工具调用怎样从“模型想做”变成可解释、可审计、可治理的业务能力？
这将是下一篇讨论的主题。
理论边界与开放问题
本文的知识定义、知识成熟度和知识对象来自 KDC 当前阶段的理论推导，成熟度为 Derived。知识可信度计算、冲突模型、自动抽取内容的验证方式，以及知识对象何时可以进入高风险行动链路，仍是开放问题。KDC 不要求所有数据和模型输出都成为知识对象，也不把知识运行时等同于必须独立建设的新平台。
