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

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

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

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

需求材料保存的是不同时间、不同角色、不同目的下的表达。AI可以高效率地生成候选项、聚类、比较和追问，却没有天然权力决定哪个定义正式、哪个版本有效、哪个例外可以执行。

要把文档变成业务本体的输入，真正需要的不是一个更长的提示词，而是一条可追溯、可评测、有人裁决的提取管道。

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

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

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

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

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

描述系统目前交换什么字段。例如接口中出现

，只能证明接口使用了这个字段名，不能证明它在市场、研发、POS和ERP中都指向同一种业务对象。接口是实现证据，不自动是领域定义。

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

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

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

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

来源权威性不是一张从高到低的总排行榜，而要按问题判断。

研发部对配方定义更有裁决权，供应链部对供应商SKU与物料映射更有裁决权，门店运营部对临时停售流程更有裁决权；POS接口文档可以说明当前字段实现，却不能单独推翻三方已批准的业务定义。

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

一个结果应能追溯到所使用的实体、产生它的活动和承担责任的主体。

应用到AI提取中，候选知识是实体，提取运行是活动，文档作者、模型服务、审核人与语义责任人是不同主体。只有把这些关系留住，团队才能在文档更新、模型更换或结论被质疑时复盘。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以“产品”为例，市场方案可能把整套新品称为产品，数据字典把

限定为菜品或饮料，POS文档又把套餐和产品都放在“销售项目”表中。正确处理不是让AI选择出现次数最多的意思，而是建立一个冲突包：

AI不是“替人判案”，而是把散落证据组织成可判的案卷。

BABOK所说的核实发掘结果，本质上也包括比较多次发掘结果、发现遗漏、不一致与冲突，并在必要时继续发掘。

冲突不是清洗时应被抹平的噪声，而是下一轮分析最有价值的入口。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

《本体驱动的 AI 数据管理》所说的“人机协同、逐层精炼”，与《企业本体建模方法与实战指南》强调的场景、Owner、版本、评测和审计，在这里可以合成一句更具体的方法：

先让AI把候选知识找全，再让证据把推断钉住，最后由有授权的人对正式语义作出承诺。

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

07｜从需求文档到业务本体：哪些信息适合交给AI提取？

先让AI把候选知识找全，再让证据把推断钉住，最后由有授权的人对正式语义作出承诺。
企业真正需要的，不是让AI一次画出一张看似完整的本体图，而是建立一套可以反复运行、知道自己依据什么、错在哪里、由谁确认的知识生产机制。

副总裁

人工智能

架构设计

职业发展

建立"来源登记册"拆分七类原子提取，分绿黄红三档界定AI自动化边界，将跨文档冲突打包为可裁决案卷。用四指标评测金标准，锁定业务正确性。核心是把文档变业务本体，构建可追溯、可评测、有人裁决的提取管道。

数据管理

回归测试

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

07｜从需求文档到业务本体：哪些信息适合交给AI提取？

07｜从需求文档到业务本体：哪些信息适合交给AI提取？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐