15|企业AI为什么不能只靠文档检索:本体如何补上业务语义?

2026年6月15日11点30分，食味里门店运营部向AI助手问了一个看似简单的问题：

上海SH-001门店现在能不能销售川香鸡腿饭？

AI很快从知识库里找到了三段材料：新品项目简报写着“计划6月15日上线”；市场通知写着“产品和菜单已经发布”；操作手册写着“关键物料不足时可以使用批准的替代物料”。于是它回答：“可以销售，如原鸡腿肉不足，可切换为新规格。”

这段回答有引用，语言也很完整，却做出了两个危险跳跃：计划上线不等于门店此刻可售；“可以替代”也不等于眼前这批新规格已经获得批准。

为了演示，我们给案例底稿2.0补充一份当日模拟快照：PRD-1001“川香鸡腿饭”的有效配方V1.0，每份需要0.180kg的MAT-CHKN-012旧规格鸡腿肉；SH-001门店当前可分配量只有0.120kg。门店虽然有MAT-CHKN-010新规格库存，但替代关系ALT-CHKN-001在这个时点仍是待批准；BOH中的门店可售关系已经进入“临时停售”。

文档检索没有失效。它找到了“计划”“通知”和“操作手册”。真正缺失的是：文字对应哪个对象，适用什么范围和时间，哪些是规则、哪些是实时事实，以及怎样组合成可复核判断。

[!important] 案例边界 食味里及本文中的门店、时间、库存、规则与结论均为虚构或模拟数据，只用于说明企业AI上下文设计，不代表现实餐饮规则或食品安全结论。

一、RAG解决找材料，但“找到”不等于“完成判断”

RAG的经典工作把语言模型的参数化记忆与外部非参数化记忆结合，使生成能够使用检索资料，并为知识更新和来源关联提供路径。

但在企业项目里，不宜把RAG简化成“向量库”，也不宜把它神化成“企业理解层”。检索可以使用关键词、向量、元数据过滤、数据库查询、图遍历或多种方式组合；无论采用什么技术，检索步骤的核心任务仍是为当前问题找到相关上下文。它不会自动替企业完成概念治理、对象识别和规则批准。

以“门店现在能不能卖”为例，文档RAG可以找到新品制度、上线简报、操作手册、会议纪要和异常案例，却仍要面对四个问题：

• 找到的“上架”是总部启用、渠道可见，还是门店可售？

• “有库存”指区域配送中心、门店现货，还是质量状态合格且未被占用的可分配量？

• “可替代”是一般制度说明，还是对当前产品、区域、时间和两个物料编码均有效的批准关系？

• 材料形成于上周，能否证明11点30分的当前状态？

文档证据回答“哪里曾经这样说”；业务判断还要回答“说的是谁、现在是否成立、与哪些事实共同成立”。

BABOK 3.0中，文档分析发现和核实来源，术语表与概念建模定义术语和关系，数据字典记录定义、来源与用途，决策建模表现判断要素。《PMI商业分析指南》也把范围、过程、规则、数据和界面模型作为互补视图，并要求信息关系与依赖可核实、可追踪。企业AI不能因引用了一份文档，就省略对象、规则、数据和时间。

二、企业AI至少要分清五类业务上下文

同一个问题需要的上下文，变化速度和权威来源并不相同。

五类内容不能互相顶替。原始文档保留背景、理由和完整语境；术语表减少叫错名字；本体提供稳定身份、关系和状态归属；规则把多个事实组合成判断；实时系统提供当前值。

只保存文档，AI会在片段间猜关系；只保存本体，政策原文和例外理由会丢失；只有实时数据，字段值缺少含义；只有规则，没有可信输入，判断也无法运行。

《企业本体建模方法与实战指南》对此给出了清晰边界：RAG适合制度、手册、报告、合同、邮件和会议纪要等文档知识；本体处理对象、关系、状态、逻辑与行动；生产系统和数据平台继续提供事实。本体的作用不是把其他层收编，而是把它们组织到同一业务对象和运行链路中。

《本体驱动的 AI 数据管理》提出“事实—事理—行动”模型。库存、培训和可售状态是事实，BR-012与BR-014承担判断，维持停售、提出建议或创建任务才是行动。检索到“缺料可替代”，尚未完成事实校验和受控行动。

三、五种上下文供给方式，解决的问题并不相同

把问题换成生产式问答，可以看到五种上下文供给方式的递进关系。

本文所说的Context Pack不是新的知识库，而是一次任务的上下文交付单元：任务、对象标识、范围、证据、本体切片、规则版本、事实快照、新鲜度、权限、禁止推断项和输出格式。

本体是可复用的长期语义资产，Context Pack是按问题组装的运行时切片。把整套企业本体、全部制度和所有实时表一股脑塞进提示词，不叫上下文工程，只是把信息过载转移给模型。

“门店可售Context Pack”至少应声明：对象是PRD-1001还是SET-1001，门店是否为SH-001，判断时间、区域和渠道是什么，使用哪版配方、本体和规则，数据截至何时，缺什么必须停止推断，以及答案需包含哪些证据。

上下文还要最小化。与SH-001无关的加盟结算、其他门店库存和全部历史纪要不应进入本次运行。关键是相关、清楚、无冲突，而非资料越多越好。

四、GraphRAG更会沿文档关系找，但不自动成为正式本体

普通文档切片可能把一个对象的定义、例外和影响分散在不同材料中。GraphRAG尝试从非结构化文本中提取实体、关系和陈述，形成图结构、社区及摘要，再用这些结构组织检索上下文。微软当前GraphRAG官方文档把它定位为研究RAG索引方法的平台，其标准流程包含实体、关系、可选陈述和社区报告等抽取。

它可以从访谈、工单和纪要中发现“新规格鸡腿肉—替代关系—华南试点—配方V1.1”的关联，并聚合跨文档证据。

但从文本抽出的图首先是“文档声称的关系”，未必是企业已经批准的业务关系。它可能缺少稳定业务ID、有效时间、权威来源、当前状态、权限与审批。ALT-CHKN-001在会议里被讨论过，不等于它已经获批；文档中出现SH-001和新物料，也不等于门店此刻允许使用它。

因此，GraphRAG可以成为文档检索的结构增强层，也可以为本体建设发现候选对象和关系；正式本体仍需要领域专家确认定义、边界、关系方向、基数、范围和治理状态。不要把“图里有一条边”误读成“业务上已经允许”。

Ontology Development 101强调，本体是为具体应用服务的共享、显式知识模型，不存在脱离任务的唯一正确设计，还要用能力问题、实例和专家评审反复验证。GraphRAG抽取可以提供候选项，却不能跳过这一建模与确认过程。

五、本体补的是语义骨架，不替代文档和实时数据

对“SH-001能否销售PRD-1001”，最小本体切片可以表达以下路径：

门店通过门店可售关系关联产品；门店制作产品使用在当前范围和时间有效的配方版本；配方成分引用食材物料或已批准替代关系；库存可用性属于物料、地点、时间和用途的情境化事实；可售判断还引用菜单、价格、培训和设备准备。

这条路径能阻止几个常见误判：总部产品启用不能推出门店可售；区域配送中心有库存不能推出门店有料；新物料名称相似不能推出可替代；套餐可售也不能只检查主餐，还要检查套餐组成与允许选择。

可是，本体只定义“应当沿什么关系找”。它不能凭空提供SH-001的0.120kg库存，也不能替HR证明员工培训完成，更不能替门店运营部批准一次例外。对象实例和状态仍要从POS、BOH、WMS、ERP与HR等权威来源读取。

原始文档同样不可删除。为什么BR-014规定“数据不可靠时只提示、不自动执行”？某次例外为何获批？规则变更考虑了哪些风险？这些解释性内容很难全部压进类、属性和关系中，仍应由制度、决策记录和证据账本保存。

本体也会过期或建错。若配方更新而映射未同步，结构化答案可能稳定地出错。因此，本体需要版本、Owner、来源映射、测试实例、发布日期和失效机制。缺少治理，它只是另一种待维护的知识资产。

还要注意“没查到”不自动等于“没有”。如果WMS接口超时，AI不能把缺失记录解释成库存为零；如果本体没有某个新概念，也不能断言业务世界不存在它。生产式问答必须区分事实为否、证据缺失、来源冲突和不在模型范围。

六、把检索、语义、规则和人工确认串成一条链

一个更可靠的企业问答流程可以分成七步。

步骤一：定义问题和时点。把“能不能卖”解析为门店可售判断，确认对象、门店、渠道、时间和提问人权限。

步骤二：解析对象。把“川香鸡腿饭”解析为PRD-1001，避免误取SET-1001或鸡腿肉物料。

步骤三：检索证据。查找制度、审批、异常说明和决策，保留来源、版本、位置与范围。

步骤四：获取本体切片。沿“门店—可售关系—产品—配方—物料—库存/替代”确定必要对象与连接。

步骤五：读取实时事实。从责任系统取得当前状态，检查时间、质量、主键、范围和权限；文档库存不能替代实时查询。

步骤六：执行规则。使用当前有效的BR-012、BR-014，输出可售、不可售或待确认，并记录输入及来源。

步骤七：生成可审计答案。输出结论、时点、对象ID、判断路径、来源、规则版本、缺失项和责任人。修改可售状态或替代物料必须进入授权流程。

Palantir Model Studio不是RAG或本体工具，但其精读笔记、双语证据稿及当前官方文档提供了工程类比：训练运行记录输入映射、配置与模型版本、实验和血缘。企业问答也应保存检索片段、本体和规则版本、事实快照、配置、输出及人工修改，才能解释答案为何变化。

七、什么场景值得用本体，什么场景不必急着上

不是所有企业问答都需要本体。

若员工只问“差旅制度在哪里”“手册如何描述某步骤”，答案来自一两份权威文档，不涉及跨对象与实时状态，做好文档治理、权限、检索和引用通常已经足够。

当问题具备以下特征时，本体价值更高：同一词在多系统含义不同；需要识别稳定业务对象；必须跨三类以上对象或系统走多跳关系；结论依赖状态、范围、有效时间和版本；需要重复执行规则；结果会影响流程、权限或业务动作；错误答案的人工核查成本较高。

暂不适合正式本体的场景包括：一次性创意讨论、没有稳定对象和重复关系的总结、权威来源与Owner未定、规则频繁变化却无人维护，或建模成本明显高于重复错误成本。

判断是否引入本体，可以先问五个问题：是否存在必须分清的对象？是否需要沿稳定关系跨系统取数？是否有可复用的状态或规则？是否需要说明结论为什么成立？是否会据此触发高影响行动？如果大多回答“否”，先把文档RAG做好；如果大多回答“是”，只堆更多文档片段通常不会解决根因。

八、回到SH-001：一份合格答案应该长什么样

经过组合流程，AI最终输出的不只是“不能卖”，而是一份可复核的判断：

结论：当前不可售。

判断对象为SH-001门店与PRD-1001产品之间的门店可售关系；事实截至2026-06-15 11:30。菜单、价格、培训和设备已就绪，但有效配方RCP-PRD1001-10每份需要0.180kg的MAT-CHKN-012，门店当前可分配量为0.120kg。MAT-CHKN-010虽有库存，ALT-CHKN-001尚未批准，不能作为当前配方可用物料。依据BR-012与BR-014，维持“临时停售”。若要启用新规格，应由研发、供应链和质量完成替代关系批准，或由门店运营按授权流程处理例外。

同时附上三类证据：操作手册与规则原文负责解释“为什么”；本体路径负责说明“检查了哪些对象和关系”；POS、BOH、WMS、ERP、HR快照负责证明“此刻的事实”。如果任一权威接口不可用，结论应降级为“信息不足，需人工确认”，而不是用昨天的文档片段补齐今天的状态。

Context Pack交付的不是更多文本，而是与问题匹配、来源明确、时点一致、语义相容、权限允许的上下文。

结语：企业AI缺的往往不是知识数量，而是知识之间的分工

RAG让AI知道去哪里找材料，本体让它知道材料中的对象分别是什么、可以沿哪些关系连接、哪些状态和约束不能混用；规则把事实组合成判断，实时系统提供当前值，Context Pack则把本次任务需要的最小切片交付给模型。

这几层不是竞争关系。企业AI既要引用原文、识别对象和读懂规则，也要承认数据缺失，并说明判断依据与人工责任。

下一次知识库回答“可以”“不可以”“已完成”“有库存”时，不妨继续追问：说的是哪个对象？适用什么时间和范围？依据的是文档陈述还是当前事实？规则由谁批准？缺少证据时系统会停止，还是继续猜？这五个问题，往往比再增加一批文档更接近企业AI的真正瓶颈。