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_k20召回然后进入重排序。这里有个细节向量检索的相似度分数在不同查询之间不可比不能直接拿分数做阈值过滤必须经过重排序模型统一打分后才能做截断。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 这条路线模型是最后一步的“翻译官”真正决定效果的是前面的知识组织质量。把图谱建扎实、把检索调准、把约束写清楚中等规模的模型也能给出让一线员工敢用的答案。反过来图谱稀烂、检索跑偏再大的模型也救不回来。