知识表示一页说明
知识表示是把世界结构译成机器可一致使用的形式：概念、关系、约束、推断与版本契约，缺一就semantic drift。
· Shuai · 5 分钟阅读
模型「知道」很多字符串，不等于系统知道自己在操作什么对象。
知识表示（KR）做的，就是把世界的关节翻译成可执行、可校验、可协作的结构。
一句话定义
知识表示是把对象、关系、约束与可推断边界写成机器与人都能对齐的合同。
它解决什么问题（四类典型痛）
- 语义漂移：同一词在不同模块里指向不同实体，集成越久越像巴别塔。
- 动作无锚：agent 能调工具，但对象身份与前置条件没写清，表现为「好像对了又总偏一点」。
- 检索相关但不准：向量近似代替了类型约束，检索回来的是「像」而不是「是」。
- 规则与数据打架：业务规则在 prompt 里，真相在表里，两边从不编译到一起。
最小组成（像类型系统的五件套）
- 概念/类型：世界有哪些范畴（订单、患者、设备、合同条款……）。
- 属性：每个类型有哪些槽位，值域是什么。
- 关系：类型之间允许哪些边，基数与方向（一对多、互斥、依赖）。
- 约束：哪些组合非法，哪些状态迁移需要守卫条件。
- 可推断结构：哪些事实可由规则推导，禁止重复手写导致不一致。
工程形态速查（别混用层级）
- 属性图 / RDF 三元组：强项是显式关系与约束查询；弱项是构建与治理成本。
- 文档块 + 向量索引：强项是模糊相关；弱项是身份与否定（「不是 X」常被吃掉）。
- JSON schema / 记录模型：强项是接口契约；弱项是跨系统语义对齐仍靠人肉。
成熟系统几乎都是混合栈：结构化核 + 非结构化翼。
为什么很多项目会失败（不是「没知识」）
- 用词不统一：
user_id与customerId与「用户」混谈。 - 结构太松：一切 key-value，约束全在 prompt 里随温度漂移。
- 缺版本与血缘：知识更新后，下游 agent 仍引用旧世界。
- 把表示当论文：ontology 开会半年，业务一个字段没落地。
什么时候真的需要「重表示」
满足任两条就该认真：
- 多 agent 或多团队共享同一世界。
- 生命周期长，且错误代价高（医疗、金融、安全）。
- 实体关系复杂到 SQL 已经需要十张表才能表达「谁在什么条件下可以对谁做什么」。
- 合规要求可解释的关系链，而不是黑箱相似度。
什么时候不要过度上升
单团队、短周期、单一工作流、错误可快速人工兜底——先用 schema + 少量枚举 + 强测试，别先开本体工作坊。
用三个问题刹车：
- 真实复杂度是否出现，还是焦虑先行？
- 未来是否有多主体要读同一语义？
- 约束冲突是否已经造成线上事故？
跨域锚：知识表示 ≈ API 合同 + 数据库约束 + 类型推断
prompt 是软类型；KR 是硬类型。
软类型在 demo 里快，在规模里贵。
一句话结论
好的知识表示让系统更稳；坏的知识表示只是把混乱结构化地固化。
若你下周要建知识库，先画一张只有类型与边的草图，再讨论 embedding 维度——顺序反了，后面全在还债。