知识系统设计

大多数企业对于相同的概念，操作着多个、重叠且部分不兼容的词汇表。同一个客户在不同系统中以不同格式记录；同一个产品被销售和运营部门以不同方式分类；同一个风险被交易和合规部门用不兼容的语言描述。本体是对这些概念的明确、一致的模型——什么算作一个实例，哪些属性是强制性的，概念之间如何关联——它是下游知识系统赖以存在的基础。

我们务实而非哲学化地设计本体。目标不是世界的一个完美表示，而是系统所操作的世界部分的一个有用表示。我们从系统需要回答的查询和需要支持的决策开始，并仅对这些查询所需的概念和关系进行建模，并为新用例的出现留下明确的扩展空间。

标准——schema.org、FIBO、SNOMED CT、GS1以及行业特定的参考模型——在适用时重新使用，在几乎适用时进行调整，在不适用时则忽略。从一张白纸开始的风险大于继承累积复杂性的风险，但在长尾效应中情况正好相反。

• 领域本体和分类法设计
• 标准的重用与适应
• 语义数据集成
• 参考数据管理
• 版本控制和演进策略
• 治理和审查工具

知识图谱实现了本体在实际数据上的映射。客户、产品、供应商、交易、事件以及它们之间的关系成为一个互联、可查询的结构，下游系统（如搜索、推荐、欺诈检测、合规、生成式AI基础）可以依赖它。价值不在于图谱本身，而在于它所实现的产物。

我们根据工作负载的需要，使用适当的技术构建知识图谱——Neo4j、Amazon Neptune、JanusGraph、AnzoGraph、原生RDF存储，或者在关系型数据仓库上构建属性图层，如果它们更合适的话。我们密切关注实体解析，因为一个将同一个真实世界实体表示为多个节点的图谱，其效用甚至不如没有图谱。我们分层引入持续集成实践，以便图谱能够与上游数据和本体同步进行可预测的演进。

在用例需要时，我们通过基于嵌入的表示来扩展图谱，这些表示支持相似性搜索、推荐以及那种为大型语言模型应用提供基础的语义检索，而无需这些模型记住所有内容。结构化图谱和学习嵌入的结合异常强大，并且日益成为主流。

“图谱本身很少是最终交付物。它所实现的产物才是。”

当决策受复杂政策（如资格、定价、风险分类、法规遵从、临床路径）支配时，纯统计模型是错误的工具。政策逻辑最好以政策逻辑的形式表达：作为可读规则、结构化决策表和推理引擎，它们可以根据事实和规则主体推导出结果。其结果是一个行为完全可追溯的系统，并且可以由领域专家更新而无需重新训练模型。

我们使用现代决策管理平台（Camunda DMN、Drools、决策模型和符号工具），如果它们符合用例，并在不符合用例时使用定制规则引擎。我们特别关注编辑过程：谁可以更改规则，需要何种审查，需要对历史案例进行何种测试，以及何种分阶段推出。没有这个过程，规则库很快就会瓦解成难以辨认的积聚物。

混合架构结合了两者的优点。神经网络模型处理规则无法编写的感知或模式识别；规则引擎处理规则可以处理的策略合规性和最终决策。神经组件向规则引擎提供输入——从文档中提取的实体、经过校准的概率、一个分类——规则引擎做出一个可以在任何审计中得到辩护的决策。我们明确设计这些架构，在学习和推理组件之间有明确的分离，并在它们之间有明确的接口。

可解释性不是你在事后添加到模型中的特性。它是整个架构的一个属性。基于知识的系统通过构建就具有可解释性：每个决策都是事实和规则的产物，可以检查这些事实和规则，解释是对推理链的直接追踪，而不是事后重建。

如果机器学习组件是系统的一部分，我们会将它们与适用于模型类的解释工具配对——表格模型的特征归因、序列模型的注意力机制和理由提取、图像模型的基于原型的解释——并将这些解释与系统输出一起呈现，使用领域专家可以理解的语言。目标不是在抽象中使模型可解释；而是向人工审核员提供他们需要用来推翻或接受系统建议的证据。

我们与风险和合规职能部门紧密合作，以定义解释必须满足的标准，并在验收过程中根据实际案例测试这些标准。一个让数据科学家满意但让案例处理员困惑的解释是不合格的。

知识系统需要持续维护。本体随着业务变化而演进；图谱在连接新源时需要实体解析维护；规则库需要根据实际结果进行裁剪、去重和审查。我们与技术一起设计运营模型：编辑角色、审查周期、变更控制流程、性能监控仪表板。其结果是一个半衰期以年而非月计的系统。

我们的大多数部署都配有轻量级托管服务，负责这种持续维护，尤其是在客户内部团队掌握实践之前的早期阶段。当客户立即承担运营所有权时，我们也同样高兴；设计兼容这两种情况。