数据与知识：让任务取得有定义、有权限、够新的事实

“企业有很多数据”与“系统能完成这笔任务”之间，隔着定义、身份、更新和结果解释。客户余额应来自业务系统，补卡规定可能来自版本化制度，当前页面对象由产品提供，会话里的用户说法则是待核实输入。把它们全部塞进知识库，会丢掉各自的权威与时间语义。

本章决定每个关键事实从哪里来、怎样解释、谁能看、多久算陈旧、缺失时如何继续。先按任务列事实，再选择数据接口和检索方式，避免先建设统一向量库再寻找用途。

分开四类材料

例如合成商品任务中的供应商原文“500”是输入，不是已确认容量；类目规定capacity_ml是字段定义；运营后来取得的供应商确认是证据；保存后的商品记录才是系统事实。模型不得把候选提取结果覆盖成已确认来源。

Finch公开机制用Column Finder、Value Finder和Table Rules帮助模型取得企业数据语义。这支持一个具体判断：自然语言中的“收入”必须先确定对应指标与过滤条件，不能只依靠列名相似度。不同数据路线还需要不同查询语言和权限检查。Uber工程文章

下面是商品草稿任务的已填资料链，均为合成设计。业务与工程先确认这四行，再决定接哪些接口；找不到权威来源的字段先留空，不扩大成全企业数据建设。

事实来源表中的“有效”不是所有材料共用一个天数：规则按版本，条码按业务变更风险，权限按动作检查。下一步将这些差异写入字段和接口合同。

建立足够小的事实合同

以下沿SUP-08／SKU-017给出独立事实合同视图；确认邮件是合成补证情境，不是数据包新增文件。本结构不是运行包的字段枚举或任何案例的官方Schema：

{
  "field": "capacity_ml",
  "value": 500,
  "status": "confirmed",
  "source": {"id": "SYN-SUPPLIER-EMAIL-02", "locator": "message#paragraph-2"},
  "observed_at": "2026-10-07T08:00:00Z",
  "definition_version": "drinkware-2",
  "scope": {"supplier_id": "SUP-08", "sku": "SKU-017"},
  "access": {"tenant": "SYN-TENANT", "roles": ["catalog_editor"]}
}

confirmed表示本教学任务已得到供应商明确确认，不代表全球真值；scope防止把A款参数移给B款；定义版本说明按哪套类目规则解释。不能把模型随意填写的access作为授权，实际身份与权限由可信应用取得。

正常路径同时取得对象事实和适用规则；含糊路径保留候选并请求确认；失败路径分别返回无结果、无权限、超时和资料冲突。把四者都返回空文本，会让模型无法选择正确下一步。对动态库存或账户状态，取数超时不能用旧会话值假装当前结果；是否允许显示缓存及其日期由任务风险决定。

权限与新鲜度需要独立验证

Onyx源码提交06aa2b09cc4aa5135fa2627e5235814e996f1514，展示了文档授权与用户群组关系分别同步、查询时匹配的机制。权限写入数据库和投影到搜索索引是不同里程碑；调度间隔不能直接承诺撤权生效时间。固定版本访问模型、查询过滤实现

因此测试不仅是“能找到文档”。同一问题分别由可见用户、不可见用户、被撤权用户提问；文档从公开改为私有后再次查询；正文和授权更新失败时观察实际结果。不要在模型已读到敏感正文后才让它删除引用。

知识冲突则需要时间与用途判断。旧发布计划和新阻塞记录可以同时真实；后者未给新发布日期，就不能推断一个新承诺。可以明确返回冲突和需确认项，或者给出有时间限定的解释。引用帮助回查，但不能证明综合结论正确。

事实合同还要保留单位、否定和证据作用范围

工业采购提出“需要耐温至少120°C的零件，禁止含某材料，必须有当前适用证书”。供应商网页写“耐高温”，并不支持120°C；同系列证书不一定覆盖该SKU。IndustryLLM将需求拆成属性、操作符、值、单位、极性、显式/推断来源及证据引用，并保留关键缺失为unknown。训练模型更懂工业语言，也不能补出缺失证书。技术报告

因此上面的商品事实合同只是起点。采购任务还需requirement_id、operator、unit、polarity、evidence_scope及有效期。例：源证据“248°F”经确定性换算可支持120°C；“最高248°F但连续使用100°C”不能只截取最高值。模型提取候选，单位换算、证据适用范围和资格规则由明确函数与复核负责；原文相互矛盾时保留冲突，不在向量排序中选一个当真值。资格判断与可运行的合成例在规划与证据专题。

另一类任务是财务对账：两份数据分别按订单和结算批次统计，就算数字接近也不能直接匹配。GL Reconciler工作包先统一日期、币种和粒度再找差异，随后重取凭证、复核解释，防止把缺行叫“漏记”、把时点差叫“损失”。取数完成只证明得到表；数据可比性、差异原因和处理授权各是不同产物。固定工作包与工具专题提供具体三行任务。

数据责任也会改变架构。IBM DataStage生成ETL时，模型与验证器都需要产品元数据，算子、属性、表达式不能共用一句“字段正确”。产品允许人编辑画布，不代表生成作业已经运行。迁到商品或采购任务时，应复用“元数据给生成器和校验器”的机制，重新取得类目定义、单位、证书和写入权限，而不是照搬ETL Prompt。部署论文

先验证一条资料链

选一个关键字段，沿源系统→同步／接口→检索或取数→上下文→结果逐段检查。用合成商品样本测试容量单位缺失、类目规则更新、条码冲突、撤权和接口超时；检查输出是否保留不确定性，并能找到产生错误的那一段。只有检索命中率，无法证明业务事实被正确使用。

本章产物是事实来源表、字段定义和错误合同。它进入架构与上下文设计，检索章节再比较分块、召回和排序；工作蓝图保留任务需要的最小字段，不要求为试点建设完整企业数据平台。

本章的confirmed表示取得明确确认的事实；实操包supported表示材料支持字段候选，人的审阅另绑定候选版本。三者不可混为一个状态。可沿商品对象与状态映射检查来源改版后哪些确认失效、哪些约束必须保留。

参考资料

• Uber Finch：字段、值及表规则。
• Onyx固定版本访问模型：授权投影机制，代码可读不等于撤权时效已验证。
• IndustryLLM v1，§2、GL Reconciler固定工作包、DataStage部署论文：采购证据、对账粒度与产品元数据。

继续使用

上一章：设计产品交互 · 下一章：选择系统架构 · 五篇阅读目录。相关工具：事实、规则与维护地图。

对照案例：Bosch制造知识查询、IBM维护。