Bosch制造知识查询：先决定模型能看见哪些关系，再评价查询对不对

把自然语言转换成能运行的查询，仍可能没有回答业务问题。Bosch 的研究把这个困难拆成两个接口：企业知识图谱怎样变成模型能用的上下文，模型生成的 SPARQL 查询又怎样检查。SPARQL 是查询图谱的语言；真正容易出错的，是把业务中的工厂、产线、材料等概念接到正确关系上。

本案不只给出“相关上下文更好”这个原则。论文比较了实际保留哪些结构、怎样表示、给什么示例，以及不同评价究竟测到了什么。它适合已有结构化知识系统、正在判断是否需要自然语言查询的团队。论文v1，§3–4

先把查询任务放回数据模型

实验整理了17个业务问题，每个问题在两套本体上都有对应标准查询。本体是对对象类型、属性与关系的明确说明；LIS偏向实际数据源的抽象，CIMM提供更丰富的制造领域语义。它们不是两份可以随意互换的文档。

问题来自不同岗位：统计某产线的设备、找材料编号、寻找共享工艺的其他产线、定位可供分析的交易数据。用户的说法短，但正确查询需要知道相应对象和关系怎样定义。表1只给出了部分问题，并没有在表内展开完整标准查询；不能据此补造一条声称来自 Bosch 的 SPARQL。§4.1、表1

四种上下文，差别在信息什么时候被丢掉

作者用四种输入安排比较“缩短”与“保留语义”两件事。这组配置使用GPT4-32K，OntA的整体简化首先服务于其32K上下文限制：

这里的25是实验设置，不是所有企业查询都应采用的检索参数。重要机制是顺序：如果先去掉定义，再从简化版本检索，相关词找到了，也可能没有足够信息解释它的关系。OntC 将相关概念与完整语义一起选入，避免这类先丢后找的损失。§4.2.1

检索的也不是随意找几段资料。系统要向模型传达本体允许怎样连接对象，供它生成正式查询；如果企业尚未维护这些关系，增加提示词不能替代数据模型建设。

表示格式决定哪些联系仍然可见

选完内容还要决定怎样交给模型。论文实验使用三种结构化表示：Turtle 图表示，分开列出类／对象属性／数据属性的表表示，以及把属性归到各类下面的排序表表示。

三者并非同一内容换个排版。独立列表更简短，却可能让类与属性的对应关系不明显；按类排序把归属重新表达出来；图表示保留正式关系，但长 URI 与三元组会消耗窗口。论文还讨论文本摘要，但本次格式对照集中在结构化表示，不能把讨论过的每种方法都当成已测方案。§3.1.3、§4.2.2

因此“换成表格”不是无条件优化。应检查缩短以后，回答该问题所需的对象归属、方向和限制是否仍能被理解，而不是只计算 token 少了多少。

Prompt里的变化有明确输入，而非一组技巧口号

原始简单提示的骨架直接说明输入：

Write a SPARQL query to answer the following question: {question}. Use the following ontology as schema for your query: {ontology}.

上面是论文§4.2.3的短原文。另两种配置分别加入通用查询例和本领域问句／查询例。领域例使用某工厂、某产线的材料编号问题，让示例展示本体中的具体组织方式，而不只教模型 SPARQL 的语法形状。原始提示配置

可以把这次模型输入理解为问题、选定本体、表示方式和示例的组合。任何一项变化，都可能改变查询。因此评审生成质量时应保留整组配置；只有一个最终 Prompt 文件，难以解释错误来自检索、表示还是示例。

词项准确率与专家评价，不能互相替代

定量检查把生成查询里的主体、谓词、对象与本体对照，计算匹配词项占比。它适合发现不存在的概念或关系，却不能证明组合方式和筛选条件符合用户意思。实验重复五次，报告均值；这些重复仍围绕那组特定业务问题。§4.3

作者再请三位知识工程及领域专家评价正确性和完整性。正确性0至4分，区分生成失败、语法错、语法对但语义错、语义基本对但不符本体意图、完整正确；完整性关注还需多大修改。两类评分的专家一致程度不同：κ分别为0.54和0.29，说明“完成了多少”本身就需要更明确的业务判断。

在这一设置下，相关子本体比整体缩减输入表现更好，从完整定义选取又带来改善；已有丰富定义时，额外语义增强未显示明显增益。表示格式与示例也没有给出一个适用于所有指标的统一赢家。结果只适用于这些子本体、提示与实验配置。§4.4、表5

迁移时要把空结果拆开处理

本研究支持的是查询生成机制，不是完整生产查询服务的成功率。执行权限、资源预算、超时、用户澄清和结果分享怎样实现，不能从这些实验自动补齐。

在自己的系统中，可以选一组获准使用、已有数据负责人认可答案的问题，保留问句、范围、本体版本、选入概念、生成查询和实际结果。把不存在的词项、关系错位、过滤条件遗漏、执行失败与真正无数据分别记录。查询空了，先核对问题范围与关系，再决定能否向用户说“没有”。

若需求一直是固定报表，参数化查询或表单可能更省成本。自然语言入口值得投入的前提，是它能减少变化问题的查询负担，同时没有把语法工作转变成更难发现的语义纠错。