07|从需求文档到业务本体:哪些信息适合交给AI提取?

数字化部门把“川香鸡腿饭套餐”的新品需求包交给AI，里面有需求说明、五方访谈纪要、新品制度、数据字典、接口文档和十几条用户故事。一次演示性试跑后，AI生成了一份颇为壮观的结果：产品、套餐、SKU、采购品、库存品、配方版本、单位换算版本……概念、关系和规则一应俱全。

看上去，几周的本体分析工作被压缩成了一次批处理。

可业务人员很快发现三个问题：AI把供应商SKU连到了产品，把“产品组成套餐”的方向画反了，还根据一份旧需求建议给同一物料维护“带版本的单位换算”。这些答案在原文里都能找到相似说法，却与食味里已经确认的业务语义冲突：套餐通过组成关系引用产品；供应商SKU只映射食材物料；规格变化要创建新物料编码，再维护替代关系。

问题不在于AI不会抽取，而在于团队把“从文档中找到一种说法”误当成了“确认企业承认的业务事实”。

需求材料保存的是不同时间、不同角色、不同目的下的表达。AI可以高效率地生成候选项、聚类、比较和追问，却没有天然权力决定哪个定义正式、哪个版本有效、哪个例外可以执行。要把文档变成业务本体的输入，真正需要的不是一个更长的提示词，而是一条可追溯、可评测、有人裁决的提取管道。

一、同一个需求包，装着五种不同性质的“真相”

食味里的新品需求包至少混合了五类材料。

需求说明描述希望解决什么问题，以及解决方案必须提供什么能力。它可以说明“系统应支持门店配置新品可售范围”，但这不等于“门店可售关系”已经被正式定义。

会议纪要和访谈逐字稿保存相关方的说法。市场部说“产品可以进入多个套餐”，采购人员说“SKU对应物料”，门店说“上架就是菜单能看见而且可以卖”。这些都是发现语义的证据，但其中还混有事实、观点、诉求、假设和解决方案建议。

制度与规则目录表达组织希望遵循的政策，权威性通常更高，却仍要检查批准状态、生效时间、适用区域和是否已被新制度替代。制度中一句“规格调整后更新物料资料”，也可能因为表达过于简略而被误读为覆盖旧编码。

接口文档描述系统目前交换什么字段。例如接口中出现product_code，只能证明接口使用了这个字段名，不能证明它在市场、研发、POS和ERP中都指向同一种业务对象。接口是实现证据，不自动是领域定义。

数据字典提供字段、类型、示例和权威来源，是识别属性与数据落点的重要材料。但表名和字段名往往继承历史系统设计。把每张表变成类、每个外键变成语义关系，只会得到一份披着业务名称的数据模型。

BABOK 3.0把文件分析视为发掘信息、理解现状并交叉核实发现的技术，同时提醒我们检查材料是否相关、及时、真实、可信和可理解，并记录矛盾、重复与知识缺口。《PMI商业分析指南》也把文件分析、模型创建、需求核实确认和追溯放在一条分析链上。两套方法共同指向一个结论：文档不是同等权威的事实仓库，而是需要被核实的多源证据。

二、先登记来源，再让AI读取内容

很多团队的第一步是把文件全部拖进模型。更稳妥的第一步，是建立“来源登记册”。每份材料进入提取队列前，至少记录：

• 文档编号、名称、类型和原始位置；

• 版本、状态、发布日期、生效与失效时间；

• 作者、批准人、业务责任部门和维护人；

• 适用产品、组织、区域、渠道、系统和流程；

• 它替代了什么、被什么替代；

• 保密级别、访问范围以及文件指纹；

• 对哪些语义主题具有裁决权。

最后一项尤其重要。来源权威性不是一张从高到低的总排行榜，而要按问题判断。研发部对配方定义更有裁决权，供应链部对供应商SKU与物料映射更有裁决权，门店运营部对临时停售流程更有裁决权；POS接口文档可以说明当前字段实现，却不能单独推翻三方已批准的业务定义。

因此，“最新版优先”和“出现次数最多的说法优先”都不可靠。最新版接口可能仍在沿用旧语义，一条错误说法也可能被复制进十份文档。来源登记的目的，不是给文档打一个神秘的可信度分数，而是让后续裁决能够回答：这是谁在什么范围、什么时间、以什么身份说的？

这与W3C的PROV-O思路相通：一个结果应能追溯到所使用的实体、产生它的活动和承担责任的主体。应用到AI提取中，候选知识是实体，提取运行是活动，文档作者、模型服务、审核人与语义责任人是不同主体。只有把这些关系留住，团队才能在文档更新、模型更换或结论被质疑时复盘。

三、把一次“抽本体”拆成七类原子提取

不要给AI一个笼统任务：“请从这些文档生成业务本体。”这会把识别、归并、建模和裁决混在一次输出里。更现实的做法，是先按文档和段落抽取七类候选知识。

每条输出只能表达一个可判断的主张。例如“供应商SKU对应食材物料且不得对应产品或套餐”最好拆成两条：供应商SKU映射食材物料；供应商SKU不得映射产品或套餐。前者是候选关系，后者是候选约束，审核方式并不相同。

还要区分直接陈述与模型推断。原文说“新规格创建新物料编码”，这是直接证据；AI由此推断“物料编码的规格在生命周期内不可变”，是值得讨论的语义候选，但不能伪装成原文。Ontology Development 101强调，术语清单只是建模起点，类、属性、约束和实例要在应用问题与专家验证中迭代形成。AI的结构化能力可以加速清单与草图，却不能跳过概念边界的选择。

四、自动化边界要分成绿、黄、红三档

《本体驱动的 AI 数据管理》提出“人机协同、逐层精炼”：AI提炼显性知识，专家补充隐性知识，再通过校验、审核和场景测试收敛。《企业本体建模方法与实战指南》则把Owner、版本、评测和审计放进模型治理。结合这两点，可以把任务分为三档。

绿档：可以自动执行，但输出仍须留痕

适合绿档的，是规则明确、错误容易检测、不会直接改变正式语义的工作：识别文件与章节、提取版本字段、切分段落和表格、生成证据坐标、校验输出结构、发现完全重复项、把更新文档关联到待复核候选项。

这里的“自动”不等于没有质量控制。页面或表格解析错位，会让正确引用落到错误行；因此仍要保留原文件、解析版本、运行日志和异常队列。

黄档：AI提出建议，人工确认或修订

术语候选、关系方向、同义词聚类、定义草案、状态候选、规则条件拆解、跨文档冲突发现和下一轮问题，都属于黄档。AI擅长横向扫描大量材料，但审核者要判断它是否遗漏上下文、把角色当类型、把数据字段当概念，或把建议方案当成业务事实。

例如“采购品”和“库存品”在访谈中频繁出现。AI可能把它们建成两个物料子类；业务专家却会指出，同一个食材物料在采购关系中扮演采购对象，在库存地点中形成库存批次。这更可能是角色或情境，而不是两种永久类型。

红档：必须由人裁决并批准

正式概念定义、分类边界、同名异义处理、关系基数、关键语义约束、业务规则适用范围、例外权限、跨版本冲突以及发布、合并、拆分和废止，都应进入红档。模型可以整理备选方案和证据，却不能替代市场、研发、供应链、质量、门店运营等责任人的业务承诺。

红档不是“AI能力不足清单”，而是组织授权边界。即使模型百分之百复述了材料，也不能替企业决定哪份草案正式生效。

五、跨文档冲突不能靠投票，要形成“冲突包”

食味里第一轮人工分析已经确认了若干语义决定：产品只指菜品或饮料；套餐是独立销售对象并引用产品；供应商SKU只映射食材物料；规格变化创建新物料编码；门店可售状态独立于总部产品状态；订单取消与退款完成是两个事件和状态。

当AI读取旧接口、会议纪要和新制度时，不应直接把相似词合并，而应先识别六种冲突：名称冲突、定义冲突、关系方向冲突、分类冲突、规则冲突，以及版本或适用范围冲突。

以“产品”为例，市场方案可能把整套新品称为产品，数据字典把product_id限定为菜品或饮料，POS文档又把套餐和产品都放在“销售项目”表中。正确处理不是让AI选择出现次数最多的意思，而是建立一个冲突包：

1. 列出各候选主张及原文证据；

2. 标记文档版本、状态、责任部门和适用系统；

3. 指出它们冲突在名称、定义、范围还是实现；

4. 关联已有语义决策与受影响的需求、接口、数据和测试；

5. 生成必须由谁回答的裁决问题；

6. 保留最终决定、理由、生效时间和被驳回方案。

这样，AI不是“替人判案”，而是把散落证据组织成可判的案卷。BABOK所说的核实发掘结果，本质上也包括比较多次发掘结果、发现遗漏、不一致与冲突，并在必要时继续发掘。冲突不是清洗时应被抹平的噪声，而是下一轮分析最有价值的入口。

六、结构化输出不能只有一个置信度

一个可用的候选记录，至少应包含：候选编号、类型、原始表述、规范化主语—关系—宾语、定义草案、适用范围、来源文档及版本、证据位置与原文、直接证据或推断、冲突编号、待回答问题、建议责任人、审核状态和发布状态。

JSON Schema可以约束这些字段是否存在、类型是否正确、枚举是否合法，从而让不同批次输出具有一致结构。但结构合法只说明“机器按格式交卷”，不说明业务含义正确。

尤其不要用一个confidence=0.92掩盖三件不同的事：模型对自己抽取结果有多确定；证据是否直接支持该主张；业务人员是否已经确认。更清楚的设计是分开记录：

• 提取置信状态：模型是否能稳定识别文本结构，仅用于排序；

• 证据状态：直接陈述、跨句归纳、模型推断或无直接证据；

• 审核状态：待审核、需修订、有冲突、已确认或已驳回；

• 发布状态：候选、已批准、已生效、已废止。

还要记录每次提取运行使用的来源包版本、解析器、模型、提示模板、输出Schema和参数。Palantir Model Studio并不是本体抽取工具，但其设计很值得借鉴：模型版本关联实验、参数和指标，运行尊重数据血缘，输入标记能够传播到输出。AI知识提取也应把一次运行当作可复现的生产活动，而不是一个无法解释的聊天窗口。

最终的证据链应当是：

原始文档 → 来源版本 → 证据片段 → AI提取运行 → 候选主张 → 冲突与人工裁决 → 正式本体项 → 使用它的AI任务或测试用例。

七、锁定业务正确，建立第一套评测基准

评测不能等本体发布后才开始。食味里可以把前期通过访谈、流程、用户故事、规则和专家澄清形成的人工结果，冻结为一套小型“金标准”。它不追求覆盖全部业务，而是刻意包含容易混淆的样本：套餐—产品方向、供应商SKU—物料映射、配方版本范围、新旧物料替代、门店可售独立状态、取消与退款分离，以及“采购品/库存品究竟是类型还是角色”。

然后让AI只读取形成这些结论之前的原始需求包，比较它是否找到相同候选、证据是否指向正确位置、是否发现冲突，以及是否产生了错误关系。至少评价四项指标：

• 准确率：AI给出的候选中，有多少经人工判定为正确；

• 召回率：金标准中的知识项，有多少被AI找到；

• 证据覆盖率：候选项中，有多少带可核验的直接证据或明确标记为推断；

• 人工接受率：审核结果中，有多少可以直接接受或轻微修订后接受。

四个数字不能互相替代。高召回可能来自过度生成，导致大量无用候选；高准确率可能因为模型只抽最容易的术语，漏掉关系、状态和例外；证据覆盖率高，也可能引用了一段并不支持结论的文字。因此还应抽查“证据命中率”，统计冲突发现率、严重错误类型和每百条候选的人工审核时间。

食味里的演示性回放不必急着公布一个漂亮分数。更有价值的是暴露误差结构：AI通常容易找到“产品、套餐、物料”等高频名词，也能识别显式规则；对关系方向、角色与类型、跨段落例外、旧文档与新制度的优先关系更容易失误。团队应据此调整来源分类、提取任务、Schema和审核规则，再用同一金标准回归测试。

高风险项还要设置单独门槛。涉及正式概念发布、食品安全相关规则、门店自动停售或物料替代批准的候选，即使整体指标达标，也必须具备完整证据并经责任人确认。评测的目的不是证明“AI已经可以替代BA”，而是判断哪些步骤可以安全提速，哪些错误会把业务带向错误方向。

结语：AI负责扩大视野，人负责承担语义承诺

从需求文档到业务本体，不是一条“上传—生成—发布”的直线，而是一条“来源登记—原子提取—证据绑定—冲突归并—人工裁决—版本发布—持续评测”的管道。

AI最适合做规模化阅读：从长文档中发现候选术语、关系、状态、规则和例外，把相近表达放在一起，把冲突摆到桌面上，并提出下一轮需要澄清的问题。BA负责设计分析任务、维护证据与追溯、组织核实；领域专家负责定义和边界；语义责任人负责版本与发布；系统和数据团队负责把已批准语义正确落地。

《本体驱动的 AI 数据管理》所说的“人机协同、逐层精炼”，与《企业本体建模方法与实战指南》强调的场景、Owner、版本、评测和审计，在这里可以合成一句更具体的方法：先让AI把候选知识找全，再让证据把推断钉住，最后由有授权的人对正式语义作出承诺。

企业真正需要的，不是让AI一次画出一张看似完整的本体图，而是建立一套可以反复运行、知道自己依据什么、错在哪里、由谁确认的知识生产机制。