一、项目背景

我们当时接手的是某省级国资集团的内部制度与资产知识问答项目。客户的诉求很明确：让业务人员用自然语言直接问"某子公司去年采购了哪些受限类物资""A 部门和 B 子公司之间的审批链条是什么"，系统要能给出准确、可溯源的答案。项目初期我们沿用了团队最熟悉的纯向量 RAG 方案——把制度文档、采购台账切片后统一 embedding，存进我们采用的私有化 AI 底座里的向量库，检索时做相似度召回再喂给大模型生成答案。

但这套方案在实际压测和灰度试用中很快暴露了短板。纯向量检索本质上是"语义邻近"匹配，对"子公司—物资—审批—预算"这种需要跨越多个实体、多跳关联的查询几乎无能为力。比如用户问"去年三季度被叫停的那批进口仪器的采购申请，最终是卡在集团哪一级审批节点"，向量召回回来的往往是一堆含"进口仪器""采购申请"字眼的段落，却完全无法把"叫停事件—申请单—审批流—责任节点"这几跳关系串起来，导致大模型只能靠自身记忆硬编，答非所问甚至编造节点名称。我们统计灰度期约 1200 条真实提问，多跳类问题（需要 2 跳及以上实体关联）的准确率只有约四成，幻觉率明显偏高，业务部门反馈"敢问的不敢信"。这个项目里我们痛定思痛，决定引入 GraphRAG 思路，把图谱的结构化关系补到向量检索之上。

二、落地场景

在这个项目里，GraphRAG 主要落地在三块场景。

第一是知识图谱构建。我们把制度文档、采购台账、组织架构表、历史审批流做了结构化抽取，形成"实体—关系—实体"三元组，构建出一张覆盖集团组织树、物资目录、审批规则、预算科目的领域图谱，落在我们采用的私有化 AI 底座的图存储组件中。

第二是图谱+向量混合检索。线上问答时，一条用户问题会同时走两条链路：一条是传统向量召回，负责抓语义相近的文档片段；另一条是图谱检索，先把问题里的实体（如"某子公司""进口仪器"）做实体链接（Entity Linking）挂到图谱节点，再以这些节点为起点做 1–3 跳的关系遍历，把路径上的子图抽取成上下文。两条链路的候选结果在重排阶段融合打分。

第三是多跳推理增强与可解释回答。我们让大模型在生成答案时显式引用图谱路径，例如回答"卡在集团采购管理委员会终审节点"时，必须带上"申请单 S2023-0912 → 子公司 X 初审 → 集团招采中心复核 → 管委会终审（叫停）"这样的路径证据，从而把答案从"黑盒生成"变成"可溯源的推理结论"。

三、关键技术挑战与解决思路

实体关系抽取与建图。 国企的制度文档格式杂、表格多、同义词泛滥（"子公司""权属企业""下属单位"指代同一概念）。我们当时没有盲目上大模型全量抽取，而是先用规则+词典做实体归一，再用我们采用的大模型底座做关系抽取校验，对低置信度的三元组人工抽检。建图阶段最坑的是"一对多"和"上下级"关系容易错挂，我们专门加了一层组织树校验脚本，拿 HR 系统的标准组织主数据去比对图谱父子关系，不一致的直接落待审队列。最终图谱规模约 8 万节点、约 23 万条边，建图耗时从一开始的全量 6 小时压到增量 15 分钟级。

图谱+向量融合检索。 两条链路打分维度不同，直接拼接会互相打架。我们的做法是引入一个轻量级交叉编码器（cross-encoder）做融合重排：把"问题+向量片段"和"问题+图谱子图摘要"各编码成 pair，统一打相关性分，再按 0.6/0.4 的权重融合（向量侧重语义、图谱侧重结构）。检索层前置在我们采用的 AI 网关之后，由网关做统一的请求归一化和限流，避免图谱遍历把后端图库打爆。实测融合后 Recall@10 比纯向量提升约 18 个百分点。

多跳推理与可解释。 单纯把子图丢给大模型，模型经常会"抄近路"忽略中间跳。我们在提示里强制约束推理链必须包含实体路径，并加了一个后校验模块：用图谱查询语言（Cypher）回查模型声称的路径是否真实存在，不存在的路径直接判为幻觉并触发降级回答。这一招把多跳幻觉率从约 27% 压到约 9%。

图谱更新维护。 制度半年一变、组织季度调整，图谱如果靠人工重建迟早烂尾。我们把更新做成流水线：文档变更事件触发增量抽取，新增/变更三元组做 diff 后灰度入图，旧关系打失效标记而非直接删除，保证历史回答仍可溯源。配合我们采用的私有化底座的监控能力，图库写入延迟、遍历耗时都进了 Grafana 看板。

四、效果数据

灰度上线约两个月、覆盖约 600 名业务用户后，我们拉了一版对照数据（脱敏示意值，对比纯向量 RAG 基线）：

时延上升主要来自图谱遍历，但我们通过限制最大跳数（3 跳）和子图剪枝把 P95 控制在可接受区间，整体端到端回答时延仍在用户容忍范围内。

五、可复用经验总结

第一，图谱补关系、向量补语义，两者不是替代而是互补——纯向量搞不定的多跳和结构约束，恰恰是该上图谱的地方，但纯图谱又表达不了模糊语义，融合才是正解。第二，多跳一定要可解释，强制路径回查比任何"模型自我约束"都靠谱。第三，建图别追求一次完美，先用规则兜住主干、再让模型补细节、靠主数据校验兜底，比一上来全量大模型抽取稳得多。第四，图谱更新必须做成增量流水线，否则半年后就是一地鸡毛。这个项目的经验后来被我们复用到同类的制度问答和供应链溯源场景，骨架基本可以直接平移。

案例片段（已脱敏）： 融合检索的重排配置片段（节选自我们采用的 AI 底座检索服务配置）：yaml fusion:  strategy: cross_encoder_rerank  candidates_per_path:    vector: 10    graph: 8  weights:    vector_semantic: 0.6    graph_structural: 0.4  graph_traversal:    max_hops: 3    prune_by_degree: 200      # 单节点出度超过则剪枝，防爆炸    entity_link_threshold: 0.82  fallback:    on_graph_empty: use_vector_only    on_low_conf: human_review_queue

案例片段（已脱敏）： 多跳路径回查的 Cypher 校验片段（拦截一次幻觉的日志）： ```

模型声称路径: 申请单S2023-0912 → 子公司X初审 → 管委会终审

MATCH p=(s:Apply{id:'S2023-0912'})-[:初审]->(x)-[:终审]->(m:Committee) RETURN p

执行结果: 0 rows  => 路径不存在，判定为幻觉，触发降级回答

[guard] hop_path_not_found=true latency=12ms action=degrade_to_safe_answer ```