知识图谱_三条工程路线打通RAG

知识图谱不再是画出来好看三条工程路线打通 RAG 的语义断层摘要向量检索的语义漂移是 RAG 在金融、ERP 这类强关系场景失准的根因。本文给出知识图谱三条落地方案API 元数据建图SPARQL、金融文档图谱Cypher 生成、多智能体自动建图实体对齐附可复用代码与避坑要点。真实项目 生产环境验证。一、先说结论向量检索解决不了关系RAG 在通用问答上表现不错一到强关系场景就出问题。举个具体的问某公司的机构投资者有哪些向量检索可能召回一段讲客户基础的文本——因为investor和customer base在语义空间中很近。答案看起来像那么回事实际完全不是那回事。这不是模型的问题。向量检索按语义相似度找片段它天然不擅长回答谁持有谁“哪个部件装在哪台设备上”哪个 API 依赖哪个 API这类结构化关系问题。知识图谱补的正是这一块把关系显式建成边将模型的注意力强制锚定在合规的实体关系上。本质是用符号逻辑校准统计学习。下面三条路线按落地难度从低到高。二、路线一API 元数据建图解决 Agent 找错接口痛点很具体企业有几十上百个 API 服务Agent 每次回答都要花大量 token 和时间试错找接口。图能把这件事的搜索空间直接缩掉。真实数据规模真实项目 生产环境验证39 个服务、101 个实体集、120 个导航关系、2000 属性定义。这个规模的元数据用文档描述没人看得完建成图后可查询。图谱的模式直接来自 OData 的 EDMX 规范Service 服务 │ contains ▼ EntityType 实体类型 ──nav──► EntityType多重性 1 或 * │ has ▼ Property 属性类型/最大长度/是否主键/是否可查询 │ belongs to ▼ EntitySet 实体集实体类型实例的逻辑容器每个实体类型恰好属于一个实体集。导航属性定义了一端到另一端的路径比如采购订单项 → 采购订单多重性为 1一项恰好属于一单采购订单 → 采购订单项多重性为*一单可有多个项。用 SPARQL 的 CONSTRUCT 查询建图不是 SELECT——SELECT 只返回结果表CONSTRUCT 才输出新三元组CONSTRUCT { ?service a :Service ; :name ?serviceName ; :description ?desc ; :version ?ver . } WHERE { ?s a :RawService ; :serviceName ?serviceName ; :description ?desc ; :version ?ver . BIND(IRI(CONCAT(http://ex/, ?serviceName)) AS ?service) }WHERE子句定义要在输入数据中匹配的图模式BIND生成新标识符CONSTRUCT定义输出图的结构。这套映射方法的适用范围不限于 OData——任何有规范描述的 API 都能这么建图。避坑要点建图的价值不在图在缩小搜索空间。如果只是把 API 文档搬进图数据库但不定义导航关系Agent 依然要遍历全部节点等于没建。关系边才是资产。三、路线二金融文档图谱三段式构建 Cypher 生成场景SEC 的 10-K 财报非结构化 13-F 持仓表结构化目标是回答投资分析类问题。构建提取 → 增强 → 扩展这个三段式是整个方法论里最可复用的部分。阶段做什么提取10-K 文本分块chunking生成文本节点13-F CSV 抽取公司与基金经理实体地址字符串解析成结构化地址节点增强文本块加向量嵌入地址节点加经纬度 point 字段并建地理空间索引扩展建关系边串联公司→表单→章节→文本块、经理→地址、经理→持股公司具体到关系设计这是最需要产品思维的地方(chunk)-[:PART_OF]-(form) # 文本块属于表单 (chunk)-[:NEXT]-(chunk) # 同节内的块按 sequenceID 串成链表 (form)-[:SECTION]-(chunk) # 表单直连每节首块sequenceID0用于快速导航 (manager)-[:OWNS_STOCK_IN]-(company) # 带 reportCalendarOrQuarter / shares / value (company)-[:FILED]-(form) # 公司提交了表单 (manager)-[:LOCATED_AT]-(address) # 地理关系SECTION这条边是个很巧的设计没有它从表单找某一节要顺着NEXT链表一路走有了它直接跳到sequenceID 0的块。检索两条链的对比真实项目里跑了两条链做对照真实项目 生产环境验证基础链只返回向量匹配的单个 chunk投资链从 chunk 出发经PART_OF → FILED → OWNS_STOCK_IN路径提取 Top 10 投资者格式化成自然语言句子“X 机构持有 Y 股市值 Z”前置到 LLM 输入结果很典型问题类型基础链投资链“某公司主营业务”相近相近“某公司的投资者有哪些”生成模糊推断机构名是编的精准列出真实机构名单结论很清楚文本型问题和关系型问题需要两套检索路径。只做一套必然有一类问题答不准。两个可以抄的工程细节① chunk 窗口用变长路径而不是固定长度。MATCH (c:chunk {id: $chunkId})-[:NEXT*0..2]-(neighbor) RETURN neighbor固定长度的NEXT路径在首块/末块上会失败没有前驱或后继。[:NEXT*0..2]自适应捕获 0 到 2 跳所有块都能生成有效窗口。这个模式应该作为图谱 RAG 的标准写法。② 金融数值必须转整数并做千分位格式化。f{int(value):,}# 而不是直接拼 str(value)原因原始字符串可能是123456789.0模型会误读加了千分位123,456,789后模型对量级的理解明显改善。所有金融数值注入环节都应该强制这一步。避坑要点分块时按sequenceID 0判断节首块会踩坑——同一份表单的不同 Part如 Item 7 和 Item 7A都有 sequenceID 为 0 的块。要用(form, item)组合做唯一判定否则导航会串节。Cypher 生成少量示例就够了用少样本提示引导模型生成 Cypher实测的递进关系很清晰示例数量模型能力1 个“某城市的投资公司”能正确替换 WHERE 里的城市名2 个增加某地附近的投资公司自主调用空间距离函数构造地理查询3 个增加某公司的业务描述组合全文检索 多跳遍历公司→表单→章节→文本块并返回摘要少量高质量示例 严格 schema 约束 链式编排就能稳定产出生产级 Cypher。不需要几十个示例需要的是示例覆盖查询类型而不是查询内容。地理查询这块还有个实用能力拼写纠错 10 公里围栏的组合构成语义容错 空间校验的双重消歧。在命名不规范、地址格式混乱的文档场景里这一招比纯字符串匹配强得多。四、路线三多智能体自动建图把 LLM 幻觉隔离在提案阶段前两条路线是人工设计 schema这条是让 Agent 自动提案。适用于业务复杂到人设计不过来的情况。三层代理架构┌──────────────────┐ │ Root Agent │ 用户交互 任务分发 └────────┬─────────┘ ┌────────────┴────────────┐ ▼ ▼ 结构化数据代理 非结构化数据代理 (CSV/JSON) (Markdown) │ │ ▼ ▼ 意图澄清 → 文件采样 意图澄清 → 文件定位 → Schema 提案/评审 → 实体与事实抽取提案 │ │ └────────────┬────────────┘ ▼ Graph Builder工具引擎关键设计代理之间靠**委托delegation**协作不是简单工具调用。协调代理识别意图后把控制权交给专用子代理对话历史和状态在代理间透传。三个决定成败的机制① Proposer / Critic 双代理对抗。Schema 不是生成一次就完事而是提案 → 评审 → 迭代。Critic 不只看语法对不对还要验证 schema 能不能满足用户的原始目标。比如目标是支持根因分析那 schema 必须包含 供应商 → 部件 → 产品 → 投诉 的完整链路。② 提案阶段禁止出现具体实例。事实类型抽取只提通用三元组模式✅ (product)-[has_issue]-(issue) ✅ (person)-[likes]-(beverage) ❌ (某产品名)-[likes]-(咖啡)这条约束看起来是细节实际上决定了整个方案的可控性。提案只定义什么可被提取具体提取由后续工具执行。职责分离后LLM 幻觉被隔离在提案环节不会污染数据导入。③ 所有关键决策写入 Session State不依赖对话历史。用户目标确认、文件推荐批准这类决策必须通过工具写入状态如approved_user_goal键而不是靠 LLM 记住对话内容。这条是整个架构里最重要的工程原则LLM 负责设计代码负责实施。状态一旦落库系统就具备可审计性和可回溯性。数据导入先节点后关系1. 建唯一性约束 CREATE CONSTRAINT ON (p:Product) ASSERT p.productId IS UNIQUE 2. 节点批量导入 LOAD CSV WITH HEADERS ... MERGE1000 行/批事务化 依据唯一列去重动态 SET n {props} 3. 关系批量导入 MATCH定位两端→ MERGE建关系→ SET赋属性 关系不需要唯一约束靠两端节点唯一性兜底MERGE天然幂等多条同一人喜欢同一饮品的记录只留一条。这比纯 LLM 驱动的数据清洗在工程上稳得多。导完之后一定要做采样验证把所有预期的关系类型展开逐个模式匹配确认每种关系至少存在一个实例。不验证就导库后面出问题极难定位。跨图实体对齐四步闭环当结构化域图谱CSV和文本域图谱Markdown需要连通时就得做实体对齐。步骤做法动态 Schema 发现查 Cypher 实时提取两边同类节点的全部属性键不预设对齐字段键名归一化统一处理前缀product_name→name、大小写、空格模糊匹配用模糊相似度算法阈值 0.9自动配对高相关键字符串距离验证用编辑距离算法阈值 0.1触发MERGE创建CORRESPONDS_TO关系记录创建/更新时间避坑要点不要对所有实体类型用同一套阈值。产品名匹配精度高问题描述这类自由文本差异大统一阈值会漏联关键实体。合理策略是分层强标识字段ID、名称用高阈值0.05弱标识字段自由文本摘要引入向量相似度做二次校验。五、写在最后知识图谱在 RAG 里的位置已经清楚了它不是让演示更漂亮的可视化是补向量检索的语义断层。三条路线的选择很简单有规范描述的 API/元数据 → 路线一SPARQL 建图有强关系需求的垂直文档 → 路线二三段式 Cypher 生成业务复杂到 schema 设计不过来 → 路线三多 Agent 提案 评审三个可以马上做的动作把[:NEXT*0..2]变长路径加进现有的图谱检索解决首末块的窗口缺失金融/数值字段全部改成整数 千分位再注入 LLM挑一个向量检索老答错的问题看看是不是关系型问题——如果是别调提示词了缺的是边。