03 为什么 AI Agent 需要 Ontology（以及什么时候不需要）
AI Agent（智能体）指能理解目标、自己规划步骤、调用外部工具去完成任务的大模型程序。这一篇讨论：让 Agent 进入企业业务，为什么需要本体；哪些替代做法不够；以及哪些场景其实用不着本体。
1. 一个"技术上成功、业务上失败"的 Agent
示例商城上线了 AI 客服"小售"。一位客户发来消息："上周买的那件黑色外套不想要了，帮我退了吧，钱退回原来的卡。"
如果"小售"只连接了数据库和几个接口，它可能会这样做：
- 用手机号在订单表里搜到最近一笔订单——但客户有两个账号，外套其实在另一个账号的订单里；
- 看到订单状态是"已完成"，以为整单都能退——却没注意外套在第二个包裹里，签收时间和同单的另一件商品不同，退货资格要按它所在包裹的签收时间单独判断；
- 跳过"先建售后单、寄回验收后再退款"的流程，直接调用退款接口退了整单金额——但客户只想退外套，而且整单金额超过了需要主管审批的额度；
- 接口返回"成功"，"小售"礼貌地告诉客户"已为您办理"。
每一次接口调用都返回成功，业务结果却是错的：退错了人、退多了钱、绕过了审批。有作者把这类情况概括为"技术执行成功，业务动作失败"。问题不在模型不够聪明，而在它面对的是一堆表和接口，而不是一个有含义、有规矩的业务世界。
2. Agent 缺的不是智力，是"世界"
大模型通过海量文本学会了语言和常识，但它不知道：
- 你的词汇："已完成"在你公司指什么，"可退金额"怎么算；
- 你的地图：客户、订单、包裹、售后单、退款单之间怎么连，哪个账号属于哪个人；
- 你的规矩：退款不能超过实付减去已退，生鲜不支持无理由退货，超过阈值要主管批；
- 你的边界：它代表谁在办事、能看哪些数据、能做哪些动作、哪些只能建议。
本体正好对应这四样东西：词汇对应对象类型与属性的定义，地图对应关系，规矩对应规则，边界对应动作与权限。有作者用一个比喻概括各组件的分工：大模型是大脑，RAG 是图书管理员，知识图谱是关系地图，而本体是"地图的图例加规则手册"。
3. 为什么提示词、RAG、微调都不够
在引入本体之前，团队通常会先试三种做法。它们各有用处，但都填不上上面四个缺口。
3.1 把规则写进提示词
最直接的办法是在提示词里写："注意区分客户的多个账号""退款超过 500 元要提醒审批"。规则少时有效，规则一多就变成补丁堆：提示词越来越长、彼此冲突、没人敢删。更根本的是，提示词只是"建议"——模型可以不遵守，换一个模型或换一种问法，屏障就可能失效。
一项关于数据 Agent 的研究（EvoOntology，arXiv:2609.15779，论文作者自报数据）还观察到：把体量较大、自动生成的静态语义说明整段塞进提示词，并不能稳定提升效果，在某个模型上反而让准确率明显下降；同样的内容改为让 Agent 按需查询，则变成正收益。需要注意，这项研究针对的是只读的数据分析 Agent，没有涉及动作和写回。语义信息很重要，但"怎么给"同样重要——下文 4.1 节提到的另一项研究显示，几 KB 的精炼说明直接放进提示词也有明显收益，两者合起来看：精炼的少量说明可以常驻，大而全的语义应当按需查。
3.2 用 RAG 检索文档
RAG（检索增强生成）指先从文档库里检索相关片段，再交给模型生成回答。它擅长"找到相关资料"，但有两个局限：
- 相似不等于相关。"怎么取消订单"和"为什么订单被取消"在向量空间（把文字转成数字向量、按距离比较相似度）里很接近，但对应的动作完全不同。向量检索擅长语义相近，不擅长逻辑相关。
- 文档不等于状态。售后政策文档能告诉 Agent "签收后 7 天内可无理由退货"，却不能告诉它"这一单现在是否已签收、还剩几天"。真正的业务状态在系统里，不在文档里。
现代 RAG 也常结合关键词检索、元数据过滤和图结构（如 GraphRAG），能检索得更准，但改变不了"文档不等于业务状态"这一点。RAG 是资料层，不是业务层。它适合回答"政策是什么"，不适合承担"这件事该怎么办、能不能办"。
3.3 把业务知识微调进模型
微调（用领域数据继续训练模型）听起来能让模型"学会"公司知识。但一项发表于 EMNLP 2024 的研究比较了微调和 RAG 两种知识注入方式，发现 RAG 在新知识和已有知识上都稳定优于无监督微调，模型很难通过微调可靠地学会新事实。对企业来说还有更直接的问题：订单状态每分钟都在变，规则和权限随时调整，这些都不适合"训练进权重"。
3.4 四种做法放在一起看
| 做法 | 擅长解决 | 解决不了 | 维护方式 | 在示例商城的合适用途 |
|---|---|---|---|---|
| 提示词 | 语气、格式、少量通用原则 | 大量业务规则、强制约束 | 改文字，容易越改越长 | 规定"小售"的说话风格、先校验再办事的总原则 |
| RAG | 找到政策和文档原文 | 业务对象的当前状态、动作 | 更新文档库 | 检索售后政策条款，作为回复里的依据 |
| 微调 | 领域表达、术语习惯 | 频繁变化的事实、权限 | 重新训练 | 让回复更像示例商城的客服 |
| 本体 | 对象身份、关系、规则、动作、权限 | 文档理解、语言表达本身 | 版本化的定义和评审流程 | 判断能不能退、能退多少、谁来批、怎么办 |
这张表说明的不是"谁取代谁"，而是"谁负责哪一段"。一个成熟的 AI 客服，四种做法往往都会用到；本体负责的是其中最需要"对"的那一段。还要补一句：这四种做法的维护方式截然不同。提示词和文档谁都能改，所以变化快但容易失控；本体的变更要经过评审，所以慢一些但可靠。把需要可靠的部分放进本体，把需要灵活的部分留在提示词和文档里，是比较合理的分工。
4. 本体给 Agent 带来的五件事
| 能力 | 没有本体时 | 有本体时 |
|---|---|---|
| 理解 | 猜表名、猜状态码 | 读到"售后单.状态 = 待退款"这样有含义的定义 |
| 定位 | 按关键词搜，容易找错对象 | 先解析出唯一的客户对象，再沿关系找到订单行 |
| 取数 | 手写多表 Join，容易出错 | 沿定义好的关系遍历，或调用参数化的查询函数 |
| 办事 | 可以调用任何接口，甚至直接写库 | 只能调用本体里定义的动作，且先过规则校验 |
| 追溯 | 只有模型的对话记录 | 每一步都有对象、规则版本、执行人、审批的证据 |
4.1 准确取数：有一些公开证据
data.world 的研究者在 2023 年做过一个基准测试：在保险领域的 43 个业务问题上，GPT-4 直接对 SQL 数据库生成查询的准确率约为 16.7%，而在同样的数据之上加一层知识图谱/本体表示后，准确率提升到约 54.2%。在需要连接四张表以上的高复杂度问题上，直接写 SQL 的准确率为 0%。需要说明的是，这份基准由知识图谱厂商发布，规模较小（13 张表、每张表只有少量数据，GPT-4 零样本），更适合说明方向，而不是给出可外推的数字。错误分析也很有意思：直接写 SQL 的错误多是"编造"不存在的列、值或连接方式；而基于本体的错误多是走错了关系的路径或方向——后者更容易发现和修正。另有一项 2026 年的配对基准研究（Rumiantsau 与 Fokeev，arXiv:2604.25149）在 100 个零售分析问题上报告，在表结构之外再给模型一份约 4 KB 的手写语义说明文档，三个前沿模型的准确率都提升了 17 到 23 个百分点；注意它测的是指标语义层文档，而不是完整的本体。这些数字来自特定基准，不能直接外推，但方向是一致的：明确的语义能显著减少"理解错"。
另外两项研究给出了方向一致的结果。一项是葡萄牙研究者在 2024 年发表的工作：在一个体育场馆业务的星型模型上，用 115 个来自真实使用场景的问题测试，只给模型星型模型的结构时，正确率为 57.76%；补充了属性取值的含义、时间区间怎么处理等上下文后，提升到 88.79%。另一项来自制药企业 GSK 的药物安全团队：在一个超过 500 张表的企业数据库上，只给 GPT-4 数据库结构时，60 个问题的通过率是 8.3%；加入一份由业务专家编写的"业务上下文文档"（核心表说明、术语表、业务规则和表间关系）后，通过率提升到 78.3%。两项研究的样本都不大，各自只涉及一个领域，作者也提醒结论有待更多验证；而且后者用的是一份纯文本文档，并不是形式化的本体。它们共同说明的是：模型并不缺写 SQL 的能力，缺的是"该写什么 SQL"的依据。
4.2 安全办事：结构保证，而不是模型自觉
一位作者用"12306 购票"做过一个对比实验：同一个大模型，A 组通过本体工具访问业务（只能用"实体检索""关系遍历""动作校验""动作执行"等少数工具），B 组只有一个"执行 SQL"的工具。当用户要求"直接把余票改成 99"时，B 组的模型也拒绝了——但那是模型"自觉"，换一个较弱的模型或换一种话术（例如"运维紧急指令"），这道屏障就可能消失；而 A 组的平台上根本不存在这个动作。作者的总结是："这不是模型的选择，是系统的结构。"
放到示例商城：Agent 能调用的只有"查询售后单""试算可退金额""创建售后单（申请）"等动作；"直接修改退款金额字段"这种事，在本体里没有对应的动作，Agent 就无从做起。
4.3 权限：Agent 不能比它代表的人更大
据介绍，在 Palantir 的设计里，Agent 执行动作时不能超出调用者本人的权限；它的 MCP（模型上下文协议，一种让 Agent 发现和调用外部工具的开放协议）接入方式（第 09 篇介绍）也只把预先定义好的对象、动作和查询函数暴露给外部 Agent。国内一些平台的做法更保守：AI 只能使用已发布的语义范围，涉及数据变更的动作要经过冻结预览、人工审批和写权限复核——"AI 不是绕过业务边界的超级管理员"。
4.4 本体与 RAG 是搭档，不是替代
需要强调的是，引入本体并不意味着丢掉 RAG。两者分工不同：本体负责"统一语言、定位对象、约束动作"，向量检索负责"找到原文证据"，大模型负责"理解意图、组织答案"。一种常见的组合是：先用本体把问题里的"外套""上周""原卡"解析成具体的订单行、时间范围和支付方式，再用 RAG 检索适用的售后政策条款，最后由模型把事实、规则和政策原文一起组织成回复。有实践者把这种做法称为"由本体双向约束的检索"：检索前用本体规划查什么，检索后用本体校验结果是否自洽。
5. 什么时候不需要本体
本体不是 Agent 的标配。下面这些场景，用 RAG、提示词或现有数据工具通常就够了：
- 文档问答和总结：员工手册问答、政策查询、会议纪要总结；十几份文档的 FAQ，用 RAG 即可。
- 一次性研究和低风险推荐：做完就扔，或错了也没什么损失。
- 简单取数：问题大多不涉及多跳关系（需要沿两条以上关系连续查找才能回答），数仓已有良好的元数据和治理。有实践者在搭建了完整的本体数据 Agent 之后坦言：多数非多跳问题，元数据加数据目录治理已经够用。
- 业务还在频繁试错：模式每周都在变，本体刚建好就过时。
- 数据极差或没人长期负责：本体会成为又一个没人维护的系统。
| 判断维度 | RAG 或现有工具足够 | 需要本体 |
|---|---|---|
| 用户目标 | 找资料、要解释 | 要把事办成 |
| 数据形态 | 以文档为主 | 以业务对象和状态为主 |
| 关系复杂度 | 单表或少量关联 | 多跳关系、身份需跨系统合并 |
| 动作风险 | 只读，或错了可忽略 | 涉及钱、合同、客户触达等不可逆动作 |
| 权限粒度 | 全员可见 | 不同角色看到和能做的不同 |
| 验收方式 | 回答"像不像" | 结果和过程都要正确、可追溯 |
6. 一条务实的路线
即使确定需要本体，也不必一步到位让 Agent "全自动办事"。比较稳妥的顺序是：
- 先只读：Agent 只能查询对象、关系和规则，给出带证据的判断，所有动作由人执行。有工程实践者的系统就把 Agent 设计为"可推理但始终只读"，没有增删改工具，也不能提交任意 SQL。
- 再建议：Agent 可以起草退款申请、预填参数，由客服确认后提交。
- 最后有限执行：对低金额、可撤销的动作开放自动执行，高风险动作始终需要审批（具体做法见第 07 篇）。
最后要提醒：本体能减少错误，但不能消灭错误。本体校验通过，不代表事实一定正确；模型仍可能在理解用户意图时出错。本体的价值在于把错误限制在可发现、可拦截、可追溯的范围内。
7. 一次对话的完整拆解：有本体和没本体
回到开头那位要退外套的客户，把"小售"的每一步摊开来对比：
| 步骤 | 没有本体时"小售"怎么做 | 有本体时"小售"怎么做 |
|---|---|---|
| 1 认人 | 用手机号查订单表，只找到一个账号的订单 | 调用"解析客户"，本体按绑定关系合并两个账号，返回唯一客户 |
| 2 找东西 | 在订单里搜"外套"，命中最近一笔订单 | 沿"客户—订单—订单行—商品"找到黑色外套所在的订单行，发现在第二个包裹里 |
| 3 判资格 | 看订单状态"已完成"，以为可以退 | 读取退货规则：自签收次日起 7 天内可无理由退货（这是《消费者权益保护法》第二十五条规定的法定底线）；物流显示外套所在的第二个包裹已签收 3 天，资格成立 |
| 4 算金额 | 取订单总金额 | 调用"可退金额"函数：该订单行实付 299 元，已退 0 元 |
| 5 判审批 | 不知道有审批规则 | 试算审批要求（只用于告知，此时不提交退款）：299 元未超过示例阈值 500 元，日后发起退款时无需主管审批 |
| 6 办事 | 调退款接口退整单 | 按权限只能"申请"：经客户确认后创建退货退款售后单（AI 对"创建售后单"有申请权，对"发起退款"只有建议权，见第 07 篇）；等仓库验收、售后单进入"待退款"后，再由客服发起退款 |
| 7 回话 | "已为您办理退款" | "已为您提交外套的退货退款申请，请按页面提示寄回；仓库验收后将原路退回 299 元，您可以在订单页查看进度" |
| 8 留痕 | 只有对话记录 | 动作实例、命中规则及版本、事实快照、客户确认记录全部留存 |
右列多出来的每一步，都不是靠模型更聪明，而是靠本体提供了明确的对象、关系、规则和动作。值得注意的是第 7 步：有本体时，"小售"的回复更准确，也更保守——它知道自己只是"提交了申请"，而不是"办完了退款"。
8. 问数的两条路径：先猜含义，还是先解析语义
前面讲的多是"办事"。Agent 的另一大用途是"问数"，也就是用自然语言查数据。这里同样有两条路径：
- 经典的 Text-to-SQL：问题 → 数据库表结构 → 大模型猜含义 → SQL → 执行。
- 语义优先：问题 → 语义解析 → 企业概念 → 权限与上下文 → 数据映射 → 查询计划 → SQL 或工具执行 → 证据 → 答案。
8.1 一个问题，好几种口径
示例商城的运营主管问："本季度高价值客户的退款率是多少？"这句话看起来很清楚，拆开来却至少有五处需要确定：
| 词 | 可能的口径 | 示例商城本体里的定义 |
|---|---|---|
| 本季度 | 自然季度：今天是 10 月中旬，本季度从 10 月 1 日算起；财务季度：假设示例商城财年从 2 月开始，本财季是 8 月至 10 月；还有"季度至今"和"整季度"的区别 | 运营口径默认"自然季度至今"；财务口径必须显式指定 |
| 高价值客户 | 会员等级金卡及以上；近 12 个月实付满 5000 元；客服系统里打了"重点客户"标签 | 派生分组"高价值客户"：近 12 个月实付金额不低于 5000 元 |
| 客户 | 一个账号；还是归并后的一个人（第 10 篇场景 E 中，两个账号属于同一位客户） | 对象类型"客户"，以归并后的客户编号为准 |
| 退款率 | 按订单行数还是按金额；分母用已签收还是已支付；拒收和"仅退款"算不算 | 指标"退款率"：发生过成功退款的订单行数 ÷ 已签收订单行数（与第 05 篇 4.2 节一致） |
| 能看什么 | 能否看到具体客户名单和手机号 | 运营主管只能看汇总和脱敏名单 |
没有本体时，模型会在表结构里找到 user_level、refund_flag、create_time 这样的字段，按自己的理解拼出一条 SQL。这条 SQL 语法正确、执行成功，返回一个看起来合理的数字——但它可能按账号而不是按人统计，按下单时间而不是签收时间划分季度，还把拒收也算成了退款。这种"静默的错误"比报错更危险，因为没有人会发现。
8.2 语义优先的八个环节
| 环节 | 做什么 | 示例商城里的结果 |
|---|---|---|
| 1 语义解析 | 识别问题里的意图和业务词 | 意图是"查指标"；业务词是"本季度""高价值客户""退款率" |
| 2 企业概念 | 把词对到本体里的对象、指标和时间口径 | 高价值客户 → 客户的派生分组；退款率 → 指标 m.refund_rate；本季度 → 默认自然季度至今 |
| 3 权限与上下文 | 按提问人的身份确定能看什么 | 运营主管：可看汇总，不可看个人明细 |
| 4 数据映射 | 查每个概念由哪些表、字段实现 | 客户 → 归并后的客户表；订单行 → order_item；退款 → 退款单表 |
| 5 查询计划 | 决定连接路径、过滤条件和聚合顺序 | 先算出高价值客户集合，再在订单行上算分子分母，避免一单多行被重复计数 |
| 6 SQL 或工具执行 | 生成 SQL，或者直接调用指标层的接口 | 交给指标层或订单库只读副本执行 |
| 7 证据 | 记录用到的定义、版本和数据截止时间 | 口径版本号、季度起止日期、参与计算的订单行数 |
| 8 答案 | 用业务语言回答，并说明口径 | "按自然季度（10 月 1 日至昨天），近 12 个月实付满 5000 元的客户，退款率为 X%。如需按财务季度计算，可以告诉我。" |
如果某个词在本体里有两种常用定义、又没有默认口径（比如"高价值"既有按消费额的，也有按会员等级的），Agent 应当先反问，而不是自己挑一个。
8.3 大模型的角色变了
| 经典 Text-to-SQL | 语义优先 | |
|---|---|---|
| 大模型主要做什么 | 猜业务含义，再写 SQL | 理解意图、选择语义对象、组织查询计划 |
| 口径从哪里来 | 模型的常识和字段名 | 本体和指标层里的定义 |
| 权限在哪一步检查 | 往往在执行之后，或者全靠数据库账号 | 在生成查询之前 |
| 出错时的表现 | 返回一个看似合理的错数 | 找不到定义就反问，或者明确说明用了哪个口径 |
| 事后能否复核 | 只有一条 SQL | 有概念、版本、映射和证据可查 |
这并不是说 SQL 不重要。确定了概念、口径、权限和映射之后，SQL 只是最后一个执行步骤（第 09 篇 1.4 节讲了怎样把语义查询改写成 SQL）。4.1 节那几项研究提升准确率的办法，本质上也是把"猜含义"这一步换成"查定义"。
9. 常见问题
问：Agent 能不能自己从数据库里"学会"本体，不用人建？
部分可以。已有研究在探索让数据 Agent 自动构建和演化本体，并通过评估门槛决定是否采纳改动（见第 07 篇）；大模型也能从表结构和文档中生成本体初稿。但"客户以谁为准""某个例外算不算规则"这类判断，仍然需要人拍板。比较现实的分工是：模型出初稿和改进建议，人做裁决。
问：加了本体，Agent 会不会变慢、变贵？
会多几次工具调用，但往往能少走弯路。12306 对比实验里，裸写 SQL 的一组为了完成一次购票，反复试错猜表名，调用次数明显多于本体一组；EvoOntology 论文也自报，按需查询语义信息后，总令牌（token，模型计量文字的单位）消耗约下降 20%。是否划算，要用自己的场景测。
问：用小模型配本体，能不能替代大模型？
本体降低了对模型"猜测能力"的要求，因为对象、规则和动作都是明确给出的。不少团队会让小模型负责路由和参数填写、大模型负责复杂理解。但小模型在意图理解和多轮对话上的短板依然存在，需要实测。
问：多个 Agent 协作时，本体起什么作用？
本体是它们的"共同语言"。售后 Agent、物流 Agent、财务 Agent 如果各自理解"退款完成"，协作时就会出错；共用一套本体，就能保证它们说的是同一个对象、同一个状态。同时，每个 Agent 的动作权限也可以在本体里分别定义。
问：本体能防住提示注入吗？
提示注入指攻击者把恶意指令藏在用户输入、网页或文件里，诱导模型去做不该做的事。本体不能完全防住它，但能大幅缩小后果。即使 Agent 被诱导"想要"做一件不该做的事，只要那个动作在本体里不存在，或者被规则和权限拦下，它就做不到。第 08 篇会从安全角度进一步讨论。
本篇要点
- Agent 进入企业业务时，常见失败不是"不会调用接口"，而是"技术执行成功，业务动作失败"。
- Agent 缺的是你的词汇、地图、规矩和边界，本体正好对应这四样。
- 提示词是建议而非约束；RAG 擅长找资料但不掌握业务状态；微调不适合注入频繁变化的事实和权限。
- 公开基准显示，明确的语义能显著提升取数准确率；动作白名单和语义闸门提供的是结构保证，而不依赖模型自觉。
- 问数时，经典 Text-to-SQL 让模型猜含义；语义优先的路径先把业务词对到概念、口径、权限和映射，SQL 只是最后一步，大模型的角色变成理解意图、选择语义对象、组织执行计划。
- 有本体时，Agent 的每一步——认人、找对象、判资格、算金额、判审批、办事、回话、留痕——都有明确依据，回复也更准确、更保守。
- 文档问答、一次性研究、简单取数、频繁试错、无人维护的场景，通常不需要本体；需要时也应从只读到建议再到有限执行逐步开放。
参考引用
- 《A Benchmark to Understand the Role of Knowledge Graphs on Large Language Model's Accuracy for Question Answering on Enterprise SQL Databases》，Juan Sequeda、Dean Allemang、Bryon Jacob（data.world），2023。原文
- 《Semantic Layers for Reliable LLM-Powered Data Analytics: A Paired Benchmark of Accuracy and Hallucination Across Three Frontier Models》，Rumiantsau、Fokeev，arXiv:2604.25149，2026。原文
- 《Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs》，Oded Ovadia 等，EMNLP 2024。原文
- 《Ontology building: Overview》，Palantir Foundry 官方文档。原文
- 《Ontology MCP (OMCP): Overview》，Palantir Foundry 官方文档。原文
- 《Action Ontology：让企业 Agent 从“会调用”到“能负责”》，皓月惊鸿 Chatshouse。Cubox，原文
- 《别把RAG当架构：Ontology（本体）才是Agent的业务世界》，KK AI应用落地社。Cubox，原文
- 《为什么Agent需要Ontology？》，飞翔海马 AI手抄笔记。Cubox，原文
- 《分享一个Ontology本体论的AI实操演示，从实际业务看懂本体价值》，月夜烛峰。Cubox，原文
- 《EvoOntology 如何自动构建本体？（实战）》，王磊 噪声之下。Cubox，原文
- 《一文读懂怎么让 Agent 理解业务，别一上手就写 Prompt！》，陈思州 Datawhale。Cubox，原文
- 《从本体论到本体建模，从本体建模到 AI 原生—我这一年关于本体的系统性复盘》，何明璐 人月聊IT。Cubox，原文
- 《01-认识 Ontilio：把业务世界建模成可运行的本体》，OntologyHub。Cubox，原文
- 《我做了一套本体Ontology工程系统，让Agent能读懂企业数据》，windom Yu 硅基斥候S01。Cubox，原文
- 《Ontology（本体）Part 3：Ontology (OWL) 驱动的数据分析智能体设计与实战》，Fan 技术与艺术认知。Cubox，原文
- 《准备上知识图谱和本体（Ontology）？要什么团队、选什么场景、花多少成本 | 人人都是产品经理》，叶小钗。Cubox，原文
- 《当 WorkBuddy 接入 Jonex：本体论让企业 Agent 开始真正理解业务》，叶小钗。Cubox，原文
- 《EvoOntology: A Self-Evolving Ontology Layer for Data Agents》，Chong 等（中国人民大学），arXiv:2609.15779，2026。原文
- 《中华人民共和国消费者权益保护法》第二十五条，国家市场监督管理总局发布文本。原文
- 《Large Language Model for Querying Databases in Portuguese》，Lourenço Figueiredo、Paulo Pinheiro、Luís Cavique、Nuno Marques，EPIA 2024 会议论文（LNCS 14969）。原文
- 《Automating pharmacovigilance evidence generation: using large language models to produce context-aware structured query language》，Jeffery L. Painter 等（GSK），JAMIA Open，2025。原文
- 《企业AI真正缺的不是 SQL，而是Semantic Layer》，本体论应用 AbutionGraph（厂商文章：作者团队开发 OntoFlow 等本体产品，文中观点带有产品立场）。Cubox，原文