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见到名词就建类定义对象是什么、不是什么、边界和正反例产品是菜品或饮料不包括套餐把一句描述当正式定义关系主体、关系、客体、方向、基数、范围套餐通过组成关系引用产品把语法顺序当关系方向状态与事件对象状态、触发变化的业务事件门店可售关系进入临时停售把活动、事件和状态混为一谈规则条件、判断、结果、责任人和生效范围未批准物料不得进入正式配方把系统校验当业务规则例外何时不适用、谁批准、何时结束紧急试点须经OA例外审批自动把例外扩成普遍规则证据原文、位置、来源、发言人和上下文访谈3.3第2轮问答只保存摘要不保存原句每条输出只能表达一个可判断的主张。例如“供应商SKU对应食材物料且不得对应产品或套餐”最好拆成两条供应商SKU映射食材物料供应商SKU不得映射产品或套餐。前者是候选关系后者是候选约束审核方式并不相同。还要区分直接陈述与模型推断。原文说“新规格创建新物料编码”这是直接证据AI由此推断“物料编码的规格在生命周期内不可变”是值得讨论的语义候选但不能伪装成原文。Ontology Development 101强调术语清单只是建模起点类、属性、约束和实例要在应用问题与专家验证中迭代形成。AI的结构化能力可以加速清单与草图却不能跳过概念边界的选择。四、自动化边界要分成绿、黄、红三档《本体驱动的 AI 数据管理》提出“人机协同、逐层精炼”AI提炼显性知识专家补充隐性知识再通过校验、审核和场景测试收敛。《企业本体建模方法与实战指南》则把Owner、版本、评测和审计放进模型治理。结合这两点可以把任务分为三档。绿档可以自动执行但输出仍须留痕适合绿档的是规则明确、错误容易检测、不会直接改变正式语义的工作识别文件与章节、提取版本字段、切分段落和表格、生成证据坐标、校验输出结构、发现完全重复项、把更新文档关联到待复核候选项。这里的“自动”不等于没有质量控制。页面或表格解析错位会让正确引用落到错误行因此仍要保留原文件、解析版本、运行日志和异常队列。黄档AI提出建议人工确认或修订术语候选、关系方向、同义词聚类、定义草案、状态候选、规则条件拆解、跨文档冲突发现和下一轮问题都属于黄档。AI擅长横向扫描大量材料但审核者要判断它是否遗漏上下文、把角色当类型、把数据字段当概念或把建议方案当成业务事实。例如“采购品”和“库存品”在访谈中频繁出现。AI可能把它们建成两个物料子类业务专家却会指出同一个食材物料在采购关系中扮演采购对象在库存地点中形成库存批次。这更可能是角色或情境而不是两种永久类型。红档必须由人裁决并批准正式概念定义、分类边界、同名异义处理、关系基数、关键语义约束、业务规则适用范围、例外权限、跨版本冲突以及发布、合并、拆分和废止都应进入红档。模型可以整理备选方案和证据却不能替代市场、研发、供应链、质量、门店运营等责任人的业务承诺。红档不是“AI能力不足清单”而是组织授权边界。即使模型百分之百复述了材料也不能替企业决定哪份草案正式生效。五、跨文档冲突不能靠投票要形成“冲突包”食味里第一轮人工分析已经确认了若干语义决定产品只指菜品或饮料套餐是独立销售对象并引用产品供应商SKU只映射食材物料规格变化创建新物料编码门店可售状态独立于总部产品状态订单取消与退款完成是两个事件和状态。当AI读取旧接口、会议纪要和新制度时不应直接把相似词合并而应先识别六种冲突名称冲突、定义冲突、关系方向冲突、分类冲突、规则冲突以及版本或适用范围冲突。以“产品”为例市场方案可能把整套新品称为产品数据字典把product_id限定为菜品或饮料POS文档又把套餐和产品都放在“销售项目”表中。正确处理不是让AI选择出现次数最多的意思而是建立一个冲突包列出各候选主张及原文证据标记文档版本、状态、责任部门和适用系统指出它们冲突在名称、定义、范围还是实现关联已有语义决策与受影响的需求、接口、数据和测试生成必须由谁回答的裁决问题保留最终决定、理由、生效时间和被驳回方案。这样AI不是“替人判案”而是把散落证据组织成可判的案卷。BABOK所说的核实发掘结果本质上也包括比较多次发掘结果、发现遗漏、不一致与冲突并在必要时继续发掘。冲突不是清洗时应被抹平的噪声而是下一轮分析最有价值的入口。六、结构化输出不能只有一个置信度一个可用的候选记录至少应包含候选编号、类型、原始表述、规范化主语—关系—宾语、定义草案、适用范围、来源文档及版本、证据位置与原文、直接证据或推断、冲突编号、待回答问题、建议责任人、审核状态和发布状态。JSON Schema可以约束这些字段是否存在、类型是否正确、枚举是否合法从而让不同批次输出具有一致结构。但结构合法只说明“机器按格式交卷”不说明业务含义正确。尤其不要用一个confidence0.92掩盖三件不同的事模型对自己抽取结果有多确定证据是否直接支持该主张业务人员是否已经确认。更清楚的设计是分开记录提取置信状态模型是否能稳定识别文本结构仅用于排序证据状态直接陈述、跨句归纳、模型推断或无直接证据审核状态待审核、需修订、有冲突、已确认或已驳回发布状态候选、已批准、已生效、已废止。还要记录每次提取运行使用的来源包版本、解析器、模型、提示模板、输出Schema和参数。Palantir Model Studio并不是本体抽取工具但其设计很值得借鉴模型版本关联实验、参数和指标运行尊重数据血缘输入标记能够传播到输出。AI知识提取也应把一次运行当作可复现的生产活动而不是一个无法解释的聊天窗口。最终的证据链应当是原始文档 → 来源版本 → 证据片段 → AI提取运行 → 候选主张 → 冲突与人工裁决 → 正式本体项 → 使用它的AI任务或测试用例。七、锁定业务正确建立第一套评测基准评测不能等本体发布后才开始。食味里可以把前期通过访谈、流程、用户故事、规则和专家澄清形成的人工结果冻结为一套小型“金标准”。它不追求覆盖全部业务而是刻意包含容易混淆的样本套餐—产品方向、供应商SKU—物料映射、配方版本范围、新旧物料替代、门店可售独立状态、取消与退款分离以及“采购品/库存品究竟是类型还是角色”。然后让AI只读取形成这些结论之前的原始需求包比较它是否找到相同候选、证据是否指向正确位置、是否发现冲突以及是否产生了错误关系。至少评价四项指标准确率AI给出的候选中有多少经人工判定为正确召回率金标准中的知识项有多少被AI找到证据覆盖率候选项中有多少带可核验的直接证据或明确标记为推断人工接受率审核结果中有多少可以直接接受或轻微修订后接受。四个数字不能互相替代。高召回可能来自过度生成导致大量无用候选高准确率可能因为模型只抽最容易的术语漏掉关系、状态和例外证据覆盖率高也可能引用了一段并不支持结论的文字。因此还应抽查“证据命中率”统计冲突发现率、严重错误类型和每百条候选的人工审核时间。食味里的演示性回放不必急着公布一个漂亮分数。更有价值的是暴露误差结构AI通常容易找到“产品、套餐、物料”等高频名词也能识别显式规则对关系方向、角色与类型、跨段落例外、旧文档与新制度的优先关系更容易失误。团队应据此调整来源分类、提取任务、Schema和审核规则再用同一金标准回归测试。高风险项还要设置单独门槛。涉及正式概念发布、食品安全相关规则、门店自动停售或物料替代批准的候选即使整体指标达标也必须具备完整证据并经责任人确认。评测的目的不是证明“AI已经可以替代BA”而是判断哪些步骤可以安全提速哪些错误会把业务带向错误方向。结语AI负责扩大视野人负责承担语义承诺从需求文档到业务本体不是一条“上传—生成—发布”的直线而是一条“来源登记—原子提取—证据绑定—冲突归并—人工裁决—版本发布—持续评测”的管道。AI最适合做规模化阅读从长文档中发现候选术语、关系、状态、规则和例外把相近表达放在一起把冲突摆到桌面上并提出下一轮需要澄清的问题。BA负责设计分析任务、维护证据与追溯、组织核实领域专家负责定义和边界语义责任人负责版本与发布系统和数据团队负责把已批准语义正确落地。《本体驱动的 AI 数据管理》所说的“人机协同、逐层精炼”与《企业本体建模方法与实战指南》强调的场景、Owner、版本、评测和审计在这里可以合成一句更具体的方法先让AI把候选知识找全再让证据把推断钉住最后由有授权的人对正式语义作出承诺。企业真正需要的不是让AI一次画出一张看似完整的本体图而是建立一套可以反复运行、知道自己依据什么、错在哪里、由谁确认的知识生产机制。