基于 Arango 构建集成电路硬件设计知识图谱01

——面向硬件架构师、EDA 工具开发者和工程负责人的技术深度解析

动手练习：https://github.com/arango-solutions/hardware-design-knowledge-graph

什么是 Arango？

Arango 是一款原生多模型数据库，也是一个上下文感知的 AI 数据平台。它在单一引擎内同时支持文档、图结构（顶点和边）以及向量嵌入的存储，并可通过 AQL（ArangoDB 查询语言）或自然语言进行查询。与那些需要集成多种异构数据库的传统技术栈不同，Arango 能在同一个引擎中完成图遍历和向量相似性搜索，从而彻底消除网络往返、格式序列化以及在应用代码中手动拼接结果的麻烦。

Arango 的多样化能力可以灵活组合，支撑极为广泛的用例。在本文中，我们将深入探讨这些特性如何化繁为简，化解集成电路设计的内在复杂性。

核心成果速览

对于正在评估这一架构是否值得投入的团队，以下是基于一个多仓库 IC 数据集得到的关键结果——该数据集已扩展至横跨五个开源 RISC-V 代码库（包括 OpenRISC 1200、MOR1KX、Marocchino 和 Ibex 核心）：

• 10 倍 Token 效率提升：通过利用拓扑邻域进行过滤，将 LLM 的上下文窗口从 5000+ token 骤降至 500 token 以内。
• 时序化的概念溯源：追踪设计概念在数十年间、不同版本文档以及不同代码库中的演化历程。
• “似曾相识”的设计场景：跨五个设计自动发现相似的历史设计情境，从而避免重蹈架构级的覆辙。

基准测试条件：数据集包含约 5 万个节点和 18 万条边，覆盖三个开源 RISC-V 代码库。延迟指标取 1000 次查询中的第 95 百分位数。

问题所在：为何碎片化技术栈难以胜任 IC 设计

硬件架构师深知，一个系统级芯片/片上系统（SoC）绝非一堆文本片段的扁平罗列，而是逻辑子系统、时钟域与电源岛的深度嵌套层级。纯向量检索增强生成（RAG）把每份文档都当作一个嵌入的集合来处理——它只依据潜空间中的距离来检索文本，对结构或时间维度毫无感知。

对向量引擎而言，高层指令集架构（ISA）文档中的“时钟信号”，与某个外设 UART 模块中的“时钟信号”在语义上毫无二致。最终结果就是：AI 智能体检索到错误的 RTL 模块，大语言模型生成了一个看似合理却纯属捏造的连接，而验证工程师则不得不耗费数小时去排查一个压根不存在的需求。

这种“空间上的碎片化”又与“时间上的碎片化”相互叠加。硬件是经年累月演进的。2012 年的某个模块与其 2024 年的版本已经截然不同，而单纯通过向量嵌入去对比它们，会把变更发生的时间与原因这些关键上下文一并抹去。

这正是结构锚定缺失所带来的失败。一旦失去 IP 层次结构的图拓扑作为指引，向量引擎便如同盲飞。

为何碎片化技术栈会叠加出高延迟：在“图数据库 + 向量数据库”各自独立的传统架构（非 Arango）中，每条查询都不得不经历三次串行网络跳跃：(1) 将查询文本转为嵌入向量；(2) 到向量库中查找候选 ID；(3) 把这些 ID 送到图数据库做遍历。每一步都带来序列化开销和独立的 I/O 往返。当数据量达到 5 万节点时，这些开销层层累积，单次查询延迟飙升至 300 毫秒以上——对于交互式设计规则检查而言，这根本不可接受。

IC-Graph 架构：从规格到硅片的全程可追溯

该方案是一条自动化多阶段流水线，将非结构化的供应商 PDF 和内部规格书转化为结构化、类型安全的知识图谱。每个阶段都是确定性的——同样的输入必然产生同样的输出，从而让系统在每一环节都可审计。

Pipeline 各阶段

第 1 阶段 — document_converter.py

摄取供应商 PDF、数据手册和内部规格说明，将其转换为整洁的 Markdown 格式，同时保留表格结构、寄存器映射和端口列表——这些信息在纯文本提取中会被抹平丢失。输出文件与源 PDF 的哈希值一起进行版本管理，因此当源文件发生变更时，图谱可被确定性地重建。

• 若跳过此阶段：你将丢失表格结构和寄存器映射——而这正是任何硬件规格中最有价值的数据——实体抽取将退化为仅基于纯文本的散文式提取。

第 2 阶段 — etl_graphrag.py

硬件领域解析器，用于识别并分类各类实体：模块（Modules）、端口（Ports）、信号（Signals）、时钟域（Clock_Domains）、约束（Constraints）和规格需求（Spec_Requirements）。每个实体在入库时即被赋予严格的类型标签，下游将使用这些标签来强制实施类型兼容矩阵（Type-Compatibility Matrix）。

• 若跳过此阶段：实体将在没有类型标签的情况下进入图谱，这会破坏第 4 阶段的类型兼容矩阵，并导致架构上毫无意义的桥接得以形成。

第 3 阶段 — consolidator.py（实体解析）

执行跨文档的实体去重。它能够识别出某个模块中的 clk_i 与另一个模块中的 sys_clk 实际上是同一逻辑网络，并将它们合并为一个黄金实体（Golden Entity）。缺少这一步骤，图谱中将充斥着数百个重复的信号节点，它们会膨胀遍历的扇出并污染相似度排序。

第 4 阶段 — bridger_bulk.py（带类型安全的语义桥接）

计算规格需求节点与 RTL 黄金实体之间的语义相似度。至关重要的是，此阶段会强制实施类型兼容矩阵——一个结构化的约束表，防止那些语义相似但架构上不兼容的实体被错误链接。

• 若移除了类型兼容矩阵：一个电源管理需求与一个中断控制器之间 0.90 的相似度得分就可能被确认成一条有效链接，形成一座会将大语言模型引入虚构推理路径的危险桥梁。

类型兼容矩阵详解：在没有类型约束的情况下，若“电源管理”需求与“中断控制器”实体的向量相似度高达 0.90，系统就会创建一条桥接边，这从架构角度看是荒谬的。类型兼容矩阵是一个以（源类型，目标类型）为键的查找表，无论相似度得分多高，只有被允许的组合对才能建立桥接。当前允许的组合包括：规格需求 → 模块、规格需求 → 时钟域、模块 → 黄金实体、端口 → 信号。被禁止的组合将被记录为“已驳回候选项”，以供工程审查。

第 5 阶段 — 时序与情境 ETL

这是我们最新的阶段，它会逐条提交地解析 Git 历史，并将不同版本的文档摄入图谱。该阶段引入了两个强大的概念：

• 设计纪元（Design Epochs）：不再将代码仓库视为扁平的历史记录，而是将提交聚合并命名为不同的时期（例如 initial_commit、v1.0_release）。
• 设计情境（Design Situations）：通过基于规则的启发式方法自动检测诸如“重大重构”或“子系统添加”等模式。通过对这些情境建立索引，图谱得以跨越全部五个 IC 设计，找到相似的历史情境。

图谱模式：节点与边

知识图谱使用以下带类型的节点和边分类体系。所有节点在入库时均被强制要求携带类型字段；边类型则定义了 AQL 查询中所使用的遍历语义。

节点类型

边类型

未完待续