利用本体和知识图谱解决半导体文档中的RAG问题。
半导体EDA文档采用了RDF/OWL本体、Neo4j知识图谱以及基于本体的检索机制，使得RAG系统产生的后续问题减少了30%。
来源: How I Built a Semantic Layer to Ground Our RAG System…And Why Ontology Was the Missing Piece
普通RAG的缺陷所在
基于产品文档的首个检索增强生成原型通常看起来很有希望：接入向量存储，将文档分割成块，执行几次查询，得到的答案似乎也合情合理。但当验证工程师询问针对某个特定模块应采用何种节能型验证方法时，系统却满腔自信地回答了功能验证方法。这些内容在自身框架内是准确的，但却无法解决实际问题。
问题出在词汇上。在半导体验证领域，“方法论”并非常用词，它指的是特定的验证方法，每种方法都与特定的工具、阶段及执行结果相关联。该系统检索到了文本，却未能获取相关知识。因此这属于语义理解问题而非检索问题，更优的嵌入模型也无法解决此问题，唯有语义层才能解决。下文将介绍如何为EDA文档集设计并构建这样的语义层：本体、知识图谱、与RAG的连接方式以及测试结果。
文档——知识的荒漠
该场景涉及企业级验证软件，包含多个产品线中的数千个DITA XML主题，内容涵盖工具配置、执行工作流程以及方法指导。这些资料虽然存在，但仅为纯文本形式，而非结构化的知识体系。验证阶段、方法论和工具分别存在于不同的文档中，彼此之间仅依靠读者的已有知识才能关联起来。有十年相关经验的资深工程师能够应对，而试图自行查找合适信息的大型语言模型则会陷入重重困境。
我们的目标是找到一种能同时满足多项需求的解决方案：RAG技术、企业级搜索、内容发现以及长期内容管理。
首先明确问题框架
在编写任何本体代码之前，GenAI助手的团队成员——包括产品经理、验证专家、文档负责人、搜索工程师以及数据科学团队——进行了数周的讨论。这些对话以三个问题为指引。
首先，哪些业务成果是重要的？答案是更高的搜索精度、适用于LLM助手的标准化基础层，以及跨产品线的统一数据。其次，目前的失败表现是什么？关键词搜索会返回无关结果，由于初始答案未能理解上下文，用户会不断提出新的查询，而手动的内容关联方式也难以跟上需求。第三，成功的标准是什么？检索系统应当能够理解，对于需要动态验证受功率管理设计的查询，应返回与特定方法、特定验证阶段、特定工具相关的内容，而不仅仅是包含那些关键词的任意文档。
这样的基础工作能够避免本体膨胀的问题，即避免出于思维上的兴趣而建模所有看似有趣的内容，而非根据业务需求来建模。
发现概念与设计本体
本体设计始于知识发现，而非从 Protégé 或 Turtle 文件开始。其设计依赖于四类输入：
- 与验证工程师的访谈，他们阐述了对自己所使用的工具之间的关系、执行顺序及决策点的理解，这些理解往往与工具的实际工作方式不同
- 现有的文档和工具界面，其中反复出现的术语揭示了多年来一直保持稳定的概念
- 日志、配置文件以及流程定义，这些内容展示了工具、各个阶段及输出结果之间的真实关联，且常常与文档中的描述不一致
最终形成了一套核心的稳定领域概念，实际上即一种分类体系，最初特意用Excel记录下来。本体构建是协作性工作，那些需要审核模型的人——领域专家和产品经理——并不熟悉Turtle语言。电子表格使他们能够在正式编码开始之前就对模型进行验证和优化，从而建立共同的理解。
经过多轮审核后，该模型便用语义网标准进行了正式化：
- RDF将每个实体和关系都表示为三元组
- OWL提供类层次结构、属性约束及逻辑规则
- SKOS通过受控词汇表实现不同产品线之间的术语标准化
- Schematron可在Oxygen XML的编写过程中检查本体是否被正确使用
本体本身存储在TTL文件中，而Schematron规则则直接集成到编写环境中。因此，作者无法引入会破坏本体的概念，这使得规范管理成为工作流程的一部分，而非事后才考虑的事宜。所有的映射都通过DITA XML中的prolog元数据以及受控词汇表来强制执行，不允许使用自由格式的标签，也不存在“差不多就行”的情况。
知识图谱架构
本体需要一个存储空间，一个可以被查询和遍历的图结构。该设计分为多个层次：
- 模式层：TTL文件中的本体定义
- 术语层：基于SKOS的词汇表
- 实例层：由内容元数据生成的RDF三元组
- 基础设施层：用于存储和查询的Neo4j
在这些层级周围，有负责将创作内容转换为适合图结构的三元组并加载到 Neo4j 中的语义摄取管道，还有用于向 RAG 管道等用户端暴露图结构的查询与检索 API，以及为提升扩展性并实现与现有平台服务集成而提供的 Azure 云基础设施。
从内容创作到形成图结构的这一流程，使得该系统超越了单纯的本体构建范畴。作者在 Oxygen XML 中使用 DITA 编写内容，Schematron 会在他们输入内容时确保元数据符合本体规范。内容随后通过 Adobe Experience Manager 发布，这些语义元数据在传输过程中保持完整，并被导入 Neo4j，以便搜索、分析及人工智能系统对其进行查询。这体现了对从内容创作工具、图结构到 API 层的整个数据流的完整架构掌控。
将语义层集成到 RAG 中
这就是努力获得回报的地方。标准的RAG流程包括将文档切分成块、嵌入这些块、将它们存储在向量数据库中、通过相似度检索并将匹配结果传递给大语言模型。虽然这种方法可行，但它无法理解文本含义，且会不断出现三种故障模式：
- 上下文混淆，即检索在错误的上下文中找到了正确的概念，比如前文提到的验证阶段不匹配问题
- 词汇差异，工程师使用简写而文档使用正式术语，从而导致相关内容被遗漏
- 因歧义产生的幻觉，即块中的模糊术语让大语言模型用看似合理但实际上错误的领域知识来填补空白
借助知识图谱作为基础层，检索方式会在四个方面发生改变。
本体规则决定了可检索的内容范围。当查询中指定了某种验证方法时，系统首先会将该术语与本体进行匹配，然后仅检索带有该方法及其有效关联标签的内容。向量搜索依然会执行，但仅针对经过语义过滤后的子集。
系统会强制使用标准词汇表。在检索之前，用户查询会被转换为标准术语，因此“power-aware sim”会转换为“功率感知仿真”的正式术语，无论工程师如何表述问题，都能得到正确的结果。
文本块的长度遵循本体边界而非固定大小。关于某一工具在某一验证阶段作用的段落会保持完整，不会在概念中间被截断。
无效的组合会被过滤掉。本体论记录了哪些工具、方法论和阶段的组合是有效的，因此任何表示无效组合的内容片段在大型语言模型看到之前就会被降级或丢弃。
其优势立刻显现出来。答案基于经过验证且带有本体论标签的内容，而非模型对半导体验证的猜测。限制模型能看到的内容范围，消除了因检索结果模糊或缺乏上下文而产生的幻觉。每个检索到的内容片段都带有本体论元数据，因此系统能够解释其选择依据：是哪个实体、哪种关系、何种约束。此外，基于智能体的工作流可以遍历该图结构，根据真实的实体关系来规划多步骤的验证任务，而不仅仅依赖文本相似度。
技术栈
- 内容创作：结合DITA的Oxygen XML
- 验证与治理：Schematron及Schematron快速修复工具
- 本体编码：Turtle文件中的RDF、OWL和SKOS格式
- 知识图谱：Neo4j
- 发布平台：Adobe Experience Manager
- 云服务：Microsoft Azure
- RAG集成：结合Neo4j与向量搜索的自定义检索API
- 大语言模型层：专有的企业级生成式AI助手
成果
部署后有四项指标反映了实际效果：
- 后续查询量减少了30%。文档现在可作为AI助手的高精度参考依据，用户能更频繁地一次就得到正确答案。这是最关键的指标，因为它直接反映了检索质量。
- 内容复用率提升了25%。借助语义标签和关系识别功能，相同内容无需手动复制即可出现在多个产品线中。
- 手动建立链接的时间减少了60%。AEM的“相关内容”功能现在基于图结构运行，因此原本需要手动处理的链接可通过本体关系自动生成。用户的自助服务能力也提升了25%。
- 手动内容审核的周期缩短了40%。从本体中衍生的Schematron规则能在作者编辑时及时发现Oxygen中的问题，从而将质量管控提前。
类似项目的经验教训
在选择技术之前先对领域进行建模。许多团队在尚未明确实体和关系之前就直接选用Neo4j或向量数据库，这就好比在绘制平面图之前就开始建造房屋。应在初期与领域专家一起使用电子表格进行分析，虽然这种方式不够吸引人，但却是价值产生的根源。
将治理视为结构。缺乏治理的本体结构会迅速衰败，因为每一个新作者、新产品或新边缘案例都会破坏其一致性。应在内容创作工作流中内置验证机制，使其自动执行，而非依赖总是滞后进行的定期审计。
没有语义的RAG只是多步骤的搜索方式。向量相似度虽必不可少，但难以满足企业级检索的需求。当某个领域存在结构化关系、层级结构及约束条件——正如大多数企业领域那样——语义层就能将检索目标从寻找相似文本转变为寻找相关知识。
衡量企业真正关心的指标。“我们构建了一个知识图谱”并非业务成果，而“由于检索精度提高，后续查询量减少了30%”才是。每一个架构选择都应与团队外部人员看重的指标相关联。
下一步是什么
语义层是基础而非上限。本体论会持续发展，新的概念会经过测试、验证并整合进来，同时不会破坏现有的语义结构；而大语言模型工具的进步、图计算与人工智能的融合以及智能体架构的发展都可以在其基础上进一步发展。更重要的启示是，在迈向生成式人工智能的进程中，最容易被忽视的投资并非更出色的模型或更大的上下文窗口，而是更完善的语义基础。模型会不断更迭，但意义却永恒存在。
相关阅读
- 为何AI分析代理需要语义层而非原始SQL —— 直接对仓库中的原始表格进行文本转SQL操作会自行创建指标并忽略访问规则。了解如何通过Cube这样的语义层结合MCP为代理提供有业务意义的指导。
- 从初步尝试到基于SEC 10-K文件的实用RAG系统：分块处理与混合搜索 —— 为何传统的RAG流程在300页长的10-K文件上会失败，以及相应的解决方案：基于章节特征的分块、混合检索方式、交叉编码器重排序、验证机制与元数据引用。