Graph RAG在金融知识管理中的落地实践：从图谱构建到双路召回

金融行业的知识管理，过去十年基本是在“文档堆里刨食”。一份信贷政策文件从总行下发到分支行，中间要经过解读、拆解、培训、考核四道关，等一线客户经理真正用上，往往已经过去两三周。更麻烦的是，同一个问题问三个部门，可能得到三种口径的答案——不是谁故意藏着掖着，而是知识散落在制度文件、产品手册、会议纪要、邮件往来里，没人能完整拼出全貌。大模型来了之后，很多人第一反应是“直接接个通用模型问答不就行了”，实测下来问题更大：模型会编造监管条款，会把旧版利率说成现行利率，会在多跳推理时把两个不相干的制度条款强行关联。Graph RAG这条技术路线，本质上就是给大模型配一张“经过校验的知识地图”，让它回答问题时先沿着图谱找到确凿的证据链，再组织语言。我参与过一个金融知识管理平台的落地项目，核心架构就是AI 大模型 + 图数据库的组合，下面把从选型到上线的完整过程拆开讲，包括踩过的坑和最终跑通的参数配置。

1. 为什么金融知识管理不能直接上通用大模型

1.1 通用模型的三个硬伤在金融场景会被放大

先说清楚问题，才能理解后面为什么选 Graph RAG 而不是别的方案。通用大模型在开放域问答上表现不错，但金融知识管理有三个特殊约束，会把模型的弱点成倍放大。

第一个是事实精确性。金融业务里一个数字错了就是事故。比如“某类贷款当前执行利率”这种问题，通用模型可能给出一个训练数据里的历史值，或者把两个相似产品的利率混在一起。它不知道“当前”意味着要查最新发文，也不知道“某类贷款”在内部有严格的科目编码定义。第二个是多跳推理的可靠性。一线员工的问题往往不是单点查询，而是“A 客户符合 B 政策的前提下，能不能走 C 流程”。这需要跨三四个制度文件做条件判断，通用模型在多跳推理时容易“跳步”，把中间某个前提默认成立，最后给出一个看似合理实则错误的结论。第三个是可追溯性。监管检查时，每一个业务答复都要能说清楚“依据哪份文件的哪一条”。通用模型给不出引用来源，或者给出的来源是编的，这在金融场景里是不可接受的。

注意：不要试图用“提示词里强调不要编造”来解决事实性问题。提示词约束的是表达风格，约束不了模型内部的知识边界。模型不知道某份内部文件的存在，你再怎么强调它也编不出来。

1.2 Graph RAG 与普通 RAG 的本质区别

普通 RAG 的做法是：把文档切块、向量化、存进向量库，用户提问时检索最相似的几个块，塞进提示词让模型回答。这套方案在“找相似段落”上够用，但金融知识管理的核心诉求不是“找相似”，而是“找关联且确凿的证据”。

举个具体例子。用户问：“小微企业续贷业务中，如果抵押物评估值下降超过 20%，需要触发什么流程？”普通 RAG 会检索到“抵押物评估”相关的段落和“续贷流程”相关的段落，但这两段可能来自不同文件，模型需要自己判断它们之间的逻辑关系——而这个判断恰恰是最容易出错的环节。Graph RAG 的做法是预先在知识图谱里建好实体和关系：小微企业续贷—触发条件→抵押物评估值下降超20%—关联流程→重新评估与审批升级。检索时沿着图谱路径走，拿到的是一条完整的证据链，模型只需要把证据链翻译成自然语言，不需要自己做逻辑拼接。

这个区别在技术实现上对应着完全不同的数据准备流程：普通 RAG 重点是切块策略和向量模型选型，Graph RAG 重点是实体识别、关系抽取和图谱 schema 设计。后者前期投入大得多，但在金融这种强关联、强约束的领域，前期的图谱建设成本会在后续的问答准确率上成倍收回。

1.3 图数据库在其中的角色定位

图数据库在这个架构里不是“存图谱的仓库”这么简单，它承担的是结构化检索层的职责。向量检索擅长语义相似，图检索擅长关系遍历，两者是互补关系。实际架构里通常是双路召回：向量路负责“找到语义相关的文档片段”，图路负责“找到实体之间的确定关系”，两路结果合并后做重排序，再交给大模型组织答案。

选图数据库时我重点看了几个维度：多跳查询性能、与向量检索的混合能力、以及写入时的 schema 灵活性。金融知识图谱的 schema 不是一次定死的，业务部门会不断提出新的实体类型和关系类型，如果图数据库要求严格的预定义 schema，每次调整都要做数据迁移，落地节奏会被拖死。最终选的是支持属性图模型、且能在一个查询里同时做图遍历和向量相似度计算的方案，这样双路召回可以在数据库层完成融合，减少应用层的拼接复杂度。

2. 知识图谱的 schema 设计与数据接入实操

2.1 从业务问题反推实体与关系类型

schema 设计最容易犯的错是“照着文档目录建图谱”。文档目录是给人看的，图谱是给检索和推理用的，两者的组织逻辑不一样。我的做法是从高频业务问题反推：先收集一线员工最常问的 200 个问题，人工标注每个问题需要哪些实体和关系才能回答，再归纳出 schema。

比如高频问题里有一类：“某产品当前适用的费率标准是什么，最近一次调整是什么时候，调整依据是哪份文件？”这个问题需要四个实体：产品、费率标准、调整记录、依据文件，以及三条关系：产品—适用→费率标准、费率标准—有调整→调整记录、调整记录—依据→依据文件。把这 200 个问题标注完，实体类型收敛到 18 类，关系类型收敛到 23 类，这个规模对于金融知识管理来说是比较合理的——再少覆盖不住业务，再多维护成本会失控。

这里有个经验：实体类型里一定要有“时间”和“版本”这两个维度。金融制度文件经常有新旧版本并存的情况，如果图谱里不区分版本，检索时会把旧版条款和新版条款混在一起。我的做法是给每个制度类实体加生效日期和失效日期属性，检索时默认只召回当前生效的版本，需要查历史时才放开时间过滤。

2.2 文档解析与实体抽取的工程化处理

金融文档的格式复杂度远超一般场景：有扫描件 PDF、有带复杂表格的 Word、有嵌套层级的制度汇编。解析环节如果做不好，后面的实体抽取全是垃圾进垃圾出。

我的处理流水线是这样的：先用版面分析工具把 PDF 拆成文本块、表格块、标题块，表格单独走结构化提取（金融文档里的费率表、额度表是核心知识，不能当普通文本切块），标题块用来建立文档内部的层级关系。然后对文本块做实体抽取，这里用的是“规则 + 小模型”的混合策略：制度编号、日期、金额这类强格式实体用正则规则抽，准确率接近 100%；业务概念类实体用微调过的小模型抽，召回率优先，后面再用图谱的一致性校验做过滤。

实操心得：实体抽取阶段不要追求一步到位的高准确率，先把召回率拉上去，把候选实体全部灌进图谱，再用“关系约束”做二次校验。比如抽到一个“利率”实体，如果它在图谱里找不到任何“产品”实体与它相连，大概率是抽取错误或孤立噪声，可以标记为待人工确认。这种“先宽进、后严出”的策略比一开始就卡高阈值要高效得多。

2.3 图谱写入与增量更新机制

知识图谱不是建完就完事的，金融制度文件每周都在更新。增量更新机制的设计要点是变更检测 + 局部重建，而不是全量重跑。

具体做法是给每份源文档算一个内容指纹，文档更新时指纹变化触发该文档对应的子图重建：先删除该文档贡献的所有实体和关系（通过来源文档ID属性定位），再重新抽取写入。这里要注意删除的粒度——如果两个文档都提到了同一个实体（比如同一个产品），删除时不能把实体本身删掉，只能删掉该文档贡献的那条“提及”关系。所以图谱里实体的唯一标识要用业务主键（如产品编码），而不是文档内的字符串。

写入性能方面，批量导入时用图数据库的批量写入接口，每批 5000 条实体或关系，实测下来比逐条写入快一个数量级。增量更新时单文档重建通常在秒级完成，不影响线上查询。

3. 双路召回与重排序的完整实现

3.1 向量检索路的分块策略调优

向量路的质量取决于分块策略。金融文档的分块不能按固定字数切，要按语义完整性切。我的分块规则是：以制度条款为最小单位，一条条款不管多长都不切开（除非超过 2000 字，那种情况按自然段二次切分）；条款之间的层级关系（章、节、条）作为元数据保留，检索时可以按层级过滤。

分块大小实测下来，金融制度类文档的最佳区间是 300 到 800 字。太小了语义不完整，太大了检索精度下降。向量模型选的是对中文金融语料做过领域适配的版本，这里不展开具体型号，选型原则是看它在“制度条款相似度”任务上的表现，而不是通用语义相似度榜单——通用榜单上的高分模型在专业术语密集的文本上未必好使。

检索时用top_k=20召回，然后进入重排序。这里有个细节：向量检索的相似度分数在不同查询之间不可比，不能直接拿分数做阈值过滤，必须经过重排序模型统一打分后才能做截断。

3.2 图检索路的多跳查询设计

图检索路的查询模板是根据问题类型动态选择的。我把高频问题归成四类，每类对应一个图查询模板：

多跳查询的深度控制在 3 跳以内。实测下来超过 3 跳的路径噪声急剧增加，而且金融业务问题很少需要 4 跳以上的推理。如果查询模板跑出来路径过长，说明 schema 设计有问题，应该考虑增加中间实体来缩短路径，而不是硬查。

3.3 两路结果的融合与重排序

双路召回的结果需要融合成一个统一的证据列表。我的融合策略是：图路结果权重高于向量路，因为图路是确定性的关系证据，向量路是概率性的相似证据。具体做法是给图路结果一个基础分 0.7，向量路结果按重排序分数映射到 0 到 0.6 区间，合并后按分数排序取前 8 条作为最终证据集。

重排序模型用的是交叉编码器结构，输入是“问题 + 证据片段”，输出相关性分数。这里的关键是训练数据要覆盖金融问答场景，我用历史工单里的真实问答对做了微调，重排序的 top-3 命中率从基线的 61% 提升到了 84%。这个提升幅度在金融场景里很关键，因为 top-3 里只要混进一条错误证据，模型就可能被带偏。

注意：融合后的证据集要保留每条证据的来源信息（文档名、条款号、生效日期），这些信息会随证据一起进入提示词，模型在组织答案时需要引用它们。没有来源信息的证据，即使内容正确，在金融场景里也不应该被采用。

4. 提示词工程与答案生成的约束设计

4.1 系统提示词的结构化约束

提示词在这个架构里的角色不是“教模型知识”，而是“约束模型的表达方式”。我的系统提示词分四段：角色定义、证据使用规则、输出格式要求、拒答条件。

角色定义很简单，一句话说明“你是金融知识助手，只基于提供的证据回答问题”。重点是证据使用规则，我写了三条硬约束：第一，每个结论必须标注证据编号，格式是[证据N]；第二，如果证据之间相互矛盾，必须指出矛盾并说明以哪条为准（通常以生效日期最新的为准）；第三，如果证据不足以回答问题，直接说“现有资料无法确认”，不允许推测。

输出格式要求里，我强制模型按“结论 + 依据 + 注意事项”三段式输出。这个格式不是为了好看，是为了让一线员工能快速判断答案可信度——结论看第一段，依据看第二段，风险提示看第三段。

拒答条件的触发逻辑要写清楚：证据集为空时拒答，证据集里最高重排序分数低于阈值时拒答，问题涉及证据未覆盖的产品或业务时拒答。拒答不是失败，在金融场景里，一个明确的“不知道”比一个编造的答案有价值得多。

4.2 多轮对话中的上下文管理

金融知识问答经常是多轮的，用户会追问“那如果是另一种情况呢”。多轮场景的难点是指代消解和条件继承。用户第二轮的“另一种情况”指的是什么，需要从对话历史里推断；第一轮设定的条件（比如“某类客户”），第二轮是否继续适用，也需要明确。

我的做法是在每轮对话时，先用一个小模型做“查询重写”，把当前问题改写成包含完整条件的独立问题，再走检索流程。查询重写的提示词里要求模型输出结构化结果：{实体, 条件, 问题类型}，这样检索层可以直接用结构化字段做图查询，不用再解析自然语言。

上下文窗口的管理上，我只保留最近三轮的对话历史进入提示词，更早的对话压缩成一句摘要。实测下来三轮足够覆盖绝大多数追问场景，保留太多反而会稀释当前问题的证据权重。

4.3 答案的事实性校验与兜底

模型生成答案后，还有一道校验环节：把答案里的每个数字、日期、条款编号抽出来，回查证据集，确认这些值确实出现在证据里。如果发现答案里出现了证据集中没有的数字，直接触发重新生成或降级为“无法确认”。

这道校验的逻辑不复杂，但能拦住大部分事实性错误。实测中它拦下的错误里，最常见的是模型把两个相似产品的费率搞混——证据集里两个产品的费率都有，模型在组织语言时张冠李戴，校验环节发现答案里的费率值与它引用的证据编号对不上，就能拦住。

兜底策略是分级降级：校验通过则正常输出；校验发现少量不一致则输出答案但标注“部分数据待核实”；校验发现关键数据不一致则只输出证据原文，不做模型组织。这个分级策略让系统在准确率和可用性之间有了一个可调的平衡点。

5. 上线后的效果评估与持续调优

5.1 评估指标体系的搭建

金融知识管理平台的评估不能只看“回答像不像人话”，要建一套分层指标。我用的指标体系分三层：检索层看召回率和证据准确率，生成层看答案忠实度和引用正确率，业务层看一线员工的采纳率和问题解决率。

检索层的证据准确率是核心指标，定义是“最终证据集里与标准答案相关的证据占比”。这个指标低于 70% 时，生成层再优化也没用，必须回头调检索。生成层的答案忠实度用人工抽检，每周抽 100 条，标注答案是否完全基于证据、有无编造。业务层的采纳率通过埋点统计，看员工看到答案后是直接采用还是转人工。

5.2 典型 badcase 的归因与修复

上线初期收集的 badcase 归因下来，问题分布大概是：图谱覆盖不足占 40%，分块策略不当占 25%，重排序偏差占 20%，提示词约束不够占 15%。

图谱覆盖不足的典型表现是“问题涉及的业务概念在图谱里没有对应实体”，修复方式是补充实体类型和抽取规则。分块策略不当的典型表现是“证据片段被切断，关键条件丢失”，修复方式是调整分块边界规则。重排序偏差的典型表现是“正确证据排在 top-5 之外”，修复方式是补充该场景的训练样本做微调。提示词约束不够的典型表现是“模型在证据不足时仍然给出了推测性答案”，修复方式是收紧拒答阈值。

这个归因分布说明一件事：Graph RAG 的效果瓶颈主要在知识工程侧，而不是模型侧。把图谱建好、把分块调好，效果提升比换更大的模型明显得多。

5.3 人工反馈闭环的设计

系统里内置了“答案反馈”按钮，员工可以对答案标注“有用/无用/有误”。有误的反馈会进入人工审核队列，审核确认后触发对应知识点的图谱修正或分块调整。这个闭环的关键是反馈要能定位到具体证据，所以反馈按钮是挂在每条证据上的，而不是挂在整条答案上。员工点“这条证据有误”，系统就知道要修哪个实体或哪条关系。

反馈数据的积累还能反哺重排序模型的训练。每周把新积累的反馈数据加入训练集做增量微调，重排序的准确率能保持持续爬升，不会因为业务变化而衰减。

6. 落地过程中的几个关键取舍

6.1 图谱粒度：细到什么程度才够用

图谱粒度是个反复权衡的问题。粒度太粗，检索时定位不到具体条款；粒度太细，实体数量爆炸，维护成本失控。我的经验是以“业务可独立引用的最小单元”为粒度。一条制度条款如果可以被单独引用作为业务依据，它就值得成为一个实体；如果它只是条款内部的解释性文字，就作为属性挂在条款实体上，不单独建实体。

这个原则落地后，单份制度文件平均产生 15 到 30 个实体，整个平台的知识图谱规模在十万级实体、百万级关系。这个规模用图数据库扛起来毫无压力，查询延迟稳定在毫秒级。

6.2 大模型选型：参数规模不是唯一标准

大模型选型上，我试过不同参数规模的模型。结论是：在 Graph RAG 架构下，模型的主要职责是“把证据组织成通顺的答案”，而不是“凭记忆回答问题”，所以对模型的知识容量要求不高，对指令遵循能力和长文本处理能力要求高。最终选的是一个中等参数规模、但在指令遵循评测上表现稳定的模型，推理成本可控，响应延迟在可接受范围内。

如果换成超大参数模型，答案的通顺度会略有提升，但忠实度不一定更好——大模型有时候会“忍不住”补充证据之外的知识，反而增加校验环节的负担。这个取舍要根据实际 badcase 分布来定，不能盲目追大。

6.3 冷启动策略：先窄后宽

平台冷启动时不要追求全业务覆盖，选一个高频、边界清晰的业务域先跑通。我选的是“个人信贷产品咨询”这个域，原因是问题类型集中、制度文件相对规范、答案标准容易界定。这个域跑通后，把 schema 和流水线复用到其他域，边际成本大幅下降。

先窄后宽还有一个好处：早期 badcase 集中在少数几个域，归因和修复的效率高；如果一开始就全域铺开，badcase 分散在各处，团队会陷入“到处救火”的状态，反而拖慢整体进度。

7. 我踩过的几个坑和对应的解法

第一个坑是过度依赖自动抽取。早期想着全自动流水线，实体抽取不做人工校验直接入库，结果图谱里混进了大量同义实体（“小微企业贷款”和“小微贷款”被当成两个实体），检索时证据被割裂。解法是加了一层实体归一化：抽取后先做同义词聚类，人工确认聚类结果后再入库。这层人工介入看起来慢，实际上省掉了后面大量的图谱清洗工作。

第二个坑是向量路和图路各查各的，融合时简单拼接。早期两路结果直接合并送去重排序，没有做去重和冲突检测，导致同一知识点以不同表述出现多次，挤占了证据集的名额。解法是在融合前做语义去重，相似度超过阈值的证据只保留图路版本（因为图路带来源信息更完整）。

第三个坑是提示词里证据塞太多。一开始想着“多给点证据总没坏处”，把 top-10 全塞进去，结果模型在长证据集里迷失，抓不住重点。解法是证据集控制在 5 到 8 条，并且按重排序分数排序后，在提示词里明确标注“证据1最重要，依次递减”，引导模型优先使用高权重证据。

第四个坑是忽略冷启动期的人工兜底。系统刚上线时图谱覆盖不全，很多问题答不了，如果没有人工兜底通道，一线员工会直接放弃使用。解法是在平台里保留“转人工”入口，转人工的问题记录进待补充知识清单，形成“系统答不了→人工答→知识补录→系统下次能答”的正向循环。

这几个坑的共同点是：问题都不在模型本身，而在知识工程和系统设计的细节里。Graph RAG 这条路线，模型是最后一步的“翻译官”，真正决定效果的是前面的知识组织质量。把图谱建扎实、把检索调准、把约束写清楚，中等规模的模型也能给出让一线员工敢用的答案。反过来，图谱稀烂、检索跑偏，再大的模型也救不回来。