金融行业的知识管理一直是个"看着简单做着要命"的活儿。表面上无非是把制度文件、产品手册、风控规则、监管报送口径这些东西存起来、查得到，但真到了业务一线，柜员问一句"这笔跨境结算的展业三原则怎么落地"，后台可能要翻三套系统、问两个部门、等半天回复。大模型火了之后，很多团队第一反应是"接个通用问答机器人不就完了"，结果一上线就翻车：答得似是而非、引用查无出处、监管口径对不上、跨文档的关联关系完全理不清。这篇就围绕"信雅达 AI + 悦数 Graph RAG 搭建大模型知识管理平台"这个方向，把金融行业落地知识管理平台时，为什么单纯向量检索不够、图增强检索（Graph RAG）到底补了哪块短板、平台从数据接入到问答链路的完整设计思路，以及实操中那些文档里不会写的坑，掰开揉碎讲清楚。适合正在做金融知识库、智能客服、合规问答、投研助手的技术负责人和一线开发参考，也适合刚接触 RAG、想搞明白"图到底加在哪"的工程师。

1. 金融知识管理的真实痛点：为什么通用问答一上线就露馅

1.1 金融知识的三个"反常识"特征

做通用领域 RAG 的人转到金融，最容易犯的错是拿做百科问答的经验直接套。金融知识有三个特征，跟通用语料完全不是一回事。

第一是强关联、多跳。一条业务规则往往不是孤立存在的：某个产品的适当性管理要求，牵扯到客户风险等级评定办法、产品风险等级划分标准、销售流程留痕规范，这几份文件分散在不同制度里，彼此通过"引用条款"关联。用户问"某类客户能不能买某类产品"，答案需要跨三份文档做推理，单靠向量相似度召回，很可能只捞到其中一份，答出来的结论就是残缺甚至错误的。

第二是口径必须精确、可追溯。金融场景里"大概对"等于"错"。监管报送的一个字段口径、风控模型的一个阈值定义，差一个字可能就是合规事故。所以知识管理平台不能只给答案，必须给出答案出自哪份文件、哪一条、哪个版本，而且要能点回去核对原文。这对检索链路的可解释性要求极高。

第三是版本与时效敏感。制度文件更新频繁，旧版本必须能追溯但不能误导当前问答。通用 RAG 里文档更新就是重新灌一遍向量库，但在金融场景，你得清楚哪些问答依赖的是已废止条款，哪些是新旧过渡期的特殊处理。

我见过一个典型翻车案例：某团队用纯向量方案做合规问答，用户问"某类跨境业务的尽职调查要求"，系统召回了一段旧版制度里的表述，答得头头是道，但那份制度半年前已经修订。问题不在于模型笨，而在于检索层根本没有"版本有效性"这个概念。

1.2 纯向量检索在金融语料上的失效点

向量检索的本质是"语义相近"，它擅长处理"问法和答案表述不同但意思一样"的情况，比如用户口语化提问、文档用书面语表述。但金融知识管理里大量查询不是"语义相近"能解决的，而是"结构关联"问题。

举个具体例子。用户问："A 类客户的授信审批需要经过哪几级？"向量检索会把"授信审批流程"这份文档召回，但"哪几级"取决于客户分类，而客户分类的定义在另一份《客户分级管理办法》里。向量检索很难保证同时召回这两份文档并建立"客户等级→审批层级"的映射，因为它不理解"分级"和"审批"之间的实体关系。

再比如实体消歧。金融文档里"敞口""头寸""额度"这些词在不同业务线含义不同，向量检索容易把不同语境的内容混在一起召回。而图结构天然能表达"这个实体属于哪个业务域、关联哪些属性"，消歧能力强得多。

这就是 Graph RAG 要解决的问题：在向量语义召回之外，补上一层基于实体和关系的结构化检索，让"多跳关联"和"精确口径"这两件事有地方落脚。

1.3 平台要解决的核心命题

把痛点收敛一下，一个金融大模型知识管理平台要同时满足四件事：

这张表基本就是选型决策的依据。下面几节就围绕"怎么把这张表落地"展开。

2. Graph RAG 到底在图什么：向量检索与图检索的分工逻辑

2.1 一句话讲清 Graph RAG 的定位

很多人把 Graph RAG 理解成"用图数据库替代向量库"，这是误解。Graph RAG 的正确定位是在检索阶段引入图结构作为补充通道，向量检索负责"语义模糊匹配"，图检索负责"实体关系精确导航"，两者是并联而非替代关系。

打个生活化的比方：向量检索像"按感觉找书"，你说"我想找本讲风险管理的书"，它把书架上封面、简介相关的都推给你；图检索像"按索引找书"，你明确知道"我要找 A 作者写的、属于 B 系列、引用过 C 的那本"，它沿着索引关系精准定位。金融问答里这两种需求都存在，所以两条通道都得有。

悦数图数据库在这套方案里承担的就是"图检索通道"的角色，它负责存储实体、关系、属性，并支持多跳查询；信雅达的 AI 能力则负责把非结构化文档解析成结构化知识、把用户问题转成查询意图、把检索结果组织成可信答案。两者结合，才构成完整的 Graph RAG 链路。

2.2 知识图谱在金融场景里长什么样

要落地，先得想清楚图里到底存什么。金融知识图谱的 schema 设计是整套方案的地基，设计歪了后面全歪。基于常见实践，核心实体和关系大致这么几类：

实体类型（节点）：

• 制度文件（Document）：文件名、版本号、生效日期、废止日期、发布部门
• 条款（Clause）：条款编号、条款正文、所属文件
• 业务概念（Concept）：如"客户风险等级""产品风险等级""授信额度"
• 业务实体（Entity）：如具体产品、具体流程节点、具体角色岗位
• 监管要求（Requirement）：监管条目、对应落地动作

关系类型（边）：

• 文件包含条款
• 条款引用条款（跨文件引用是重点）
• 条款定义概念
• 概念约束业务实体
• 监管要求映射到条款

这套 schema 的关键在于把"引用关系"显式建出来。金融制度里大量"依据《XX办法》第 X 条"的表述，这些引用就是多跳检索的路径。建图时把引用抽出来连成边，用户问一个跨文件的问题，图检索就能沿着"条款→引用条款→再引用条款"一路扩展，把相关条款全捞出来。

实操提醒：schema 不要一上来追求大而全。我建议先聚焦 2-3 类高频业务域（比如授信、适当性管理），把这几类的实体关系建扎实，跑通问答闭环，再横向扩展。贪多求全的 schema 往往建到一半发现关系类型爆炸，维护成本失控。

2.3 两条检索通道怎么协同

协同逻辑是 Graph RAG 的核心。一个可落地的流程是这样的：

1. 问题解析：用户提问后，先用大模型做意图识别和实体抽取，判断这个问题是"语义模糊型"（如"什么是适当性管理"）还是"关系导航型"（如"某产品对应哪级审批"）。
2. 双通道召回：语义型走向量检索召回文档块；关系型走图检索，从识别出的实体出发做多跳查询。
3. 结果融合：两路结果按相关度、时效性、来源权威性加权融合，去重后送入生成环节。
4. 生成与溯源：大模型基于融合后的上下文生成答案，同时把引用的条款、文件版本一并输出。

这里有个容易忽略的点：融合不是简单拼接。向量召回的结果是文本块，图召回的结果是结构化路径，两者格式不同，需要统一成"带出处的证据片段"再喂给模型。我的做法是给每个证据片段打上source_type（vector/graph）、doc_id、clause_id、version标签，生成时要求模型在答案里标注引用编号，前端再把这些编号映射回原文链接。

3. 从文档到图谱：知识抽取流水线的工程细节

3.1 文档解析：金融 PDF 是最难啃的骨头

金融制度文件大多是 PDF，而且排版复杂：多栏、表格、页眉页脚、扫描件混排。解析质量直接决定后面抽取的成败。这一步的坑比想象中多。

表格是重灾区。制度文件里的"审批权限表""风险等级对照表"往往承载核心信息，但普通 PDF 解析器会把表格拍平成乱序文本，行列关系全丢。我的经验是：表格必须单独走表格识别通道，识别成结构化数据（行列对齐），再决定是存成图的属性还是单独建节点。比如"客户等级-审批层级"对照表，解析后应该变成一组(客户等级, 审批层级)的映射关系，直接进图。

页眉页脚和条款编号要保留。条款编号（如"第 X 条"）是溯源的关键锚点，解析时不能当噪声删掉。我一般会在解析阶段就把条款切分出来，每个条款作为一个独立单元，带上所属文件、条款号、页码，这样后面建图时条款节点天然就有出处信息。

扫描件要单独处理。纯图片 PDF 得先走 OCR，OCR 之后再走同样的结构化解析。OCR 的错字率在金融术语上偏高（"敞口"识别成"敝口"之类），建议对高频术语建一个纠错词典做后处理。

3.2 实体与关系抽取：规则 + 模型双管齐下

抽取环节纯靠大模型做，成本高且不稳定；纯靠规则，覆盖不全。实操里最稳的是规则打底、模型补漏。

规则层负责高置信度的结构化抽取：

• 条款引用：正则匹配"依据《...》第 X 条""参照...规定"等模式，抽出引用关系。
• 条款编号与层级：按"章-节-条"的编号规律切分。
• 定义句：匹配"XX 是指...""本办法所称 XX..."，抽出概念定义。

模型层负责规则覆盖不到的语义抽取：

• 用大模型对条款做实体识别，抽出业务概念、角色、流程节点。
• 用大模型判断条款之间的隐含关系（比如两条条款讲的是同一件事的不同侧面）。

这里的关键设计是抽取结果要带置信度和来源。规则抽的标confidence=high，模型抽的标confidence=medium，低置信度的关系进图前要人工抽检。金融场景宁可少建边，不可建错边——一条错误的引用关系会让多跳检索把用户带到完全无关的条款上。

一个实用技巧：抽取流水线做成"可回放"的。每份文档的解析结果、抽取结果、进图结果都留中间产物，出问题时能定位是解析错了、抽取漏了还是入库写错了。金融知识库的调试，没有中间产物基本没法查。

3.3 入库建模：节点、边、属性的取舍

进图建模时，最纠结的是"什么该做成节点，什么该做成属性"。经验法则：

• 需要被独立查询、被多条边连接的，做成节点。比如"条款"要被引用关系连接，必须是节点。
• 只作为描述信息、不参与关系导航的，做成属性。比如文件的"发布部门"，如果不需要按部门做关系查询，存成文件节点的属性即可。
• 高频作为查询起点的，即使简单也做成节点。比如"业务概念"，用户经常从概念出发问"哪些条款定义了它"，那就得是节点。

版本管理在建模时要提前设计。我的做法是给文件和条款节点都加version、effective_date、expire_date属性，检索时默认只查expire_date为空或晚于当前日期的节点。这样旧版本还在图里可追溯，但不会污染当前问答。

4. 问答链路设计：让答案既准又能溯源

4.1 意图路由：先判断该走哪条路

不是所有问题都需要图检索。一个"什么是风险敞口"的定义型问题，向量检索足够；一个"某类业务要经过哪几级审批"的流程型问题，必须走图。所以问答链路第一步是意图路由。

路由用一个小模型或规则+大模型分类即可，把问题分成几类：

• 定义解释型 → 向量为主
• 流程/权限/关联型 → 图为主
• 混合型 → 双通道并行

路由判断错了会怎样？定义型问题走图检索，可能因为实体没建全而召回为空；流程型问题只走向量，会漏掉跨文档关联。所以路由的准确率要重点测，建议用一批真实业务问题做标注集来调。

4.2 多跳查询的展开策略

图检索的核心是"从哪出发、跳几跳、怎么剪枝"。展开策略直接决定召回质量和性能。

起点确定：从问题里抽出的实体作为起点。如果抽出多个实体，分别作为起点并行查。

跳数控制：金融知识的多跳一般 2-3 跳足够。1 跳只能拿到直接关联，3 跳以上容易引入噪声且性能下降。我的做法是默认 2 跳，对"引用链"这种明确需要深挖的关系允许 3 跳，并设一个结果数量上限（比如 50 个节点）防止爆炸。

剪枝规则：不是所有边都值得跟。比如"文件包含条款"这种结构性边，在找条款内容时不必展开；而"条款引用条款"这种语义边，是重点展开对象。剪枝规则要按关系类型配置。

时效过滤：查询时带上版本条件，已废止节点不参与扩展。这一步在 Cypher 查询里用WHERE条件实现，别在应用层过滤，否则性能吃亏。

4.3 生成阶段的"证据约束"

大模型生成答案时最大的风险是"自由发挥"。金融场景必须给模型套上缰绳：只允许基于检索到的证据作答，证据不足时明确说"未找到依据"而不是编。

具体做法是在 prompt 里做几件事：

• 把证据片段编号列出，要求模型每个结论后标注引用编号。
• 明确指令："若证据不足以回答，输出'根据现有知识库未找到明确依据'，不得推测。"
• 对数字、阈值、条款号这类关键信息，要求模型原样引用，不得改写。

生成后还要做一道引用校验：检查模型输出的引用编号是否真实存在于证据列表里，防止模型"幻觉引用"。校验不通过的答案打回重生成或降级为"仅展示检索结果"。

4.4 溯源展示：把"可信"做成产品能力

溯源不是技术细节，是产品能力。用户看到答案后，要能一键展开"这个结论出自哪份文件第几条、什么版本、原文是什么"。前端设计上，我建议：

• 答案里每个引用编号做成可点击的角标。
• 点击后侧边栏展示原文片段，高亮关键句。
• 显示文件版本和生效日期，旧版本明确标注"已废止，仅供参考"。

这套展示对金融用户的说服力，比答案本身还重要。业务人员信不信这个系统，很大程度取决于能不能快速核对原文。

5. 落地过程中那些文档不会写的坑

5.1 抽取质量的天花板在文档本身

很多人以为抽取效果差是模型不行，其实大半问题出在源文档。金融制度文件里大量"见附件""按第 X 条规定执行""参照相关办法"这类指代，附件可能根本没进库，相关办法可能是另一份没纳入范围的文件。这些"悬空引用"会让图检索走到死胡同。

应对办法：建图时对悬空引用做标记，检索时遇到悬空引用要么跳过、要么在答案里提示"该条款引用的附件未纳入知识库"。同时推动文档治理，把高频引用的附件补齐。这是个长期活儿，别指望一次建全。

5.2 大模型抽取的稳定性问题

用大模型做实体关系抽取，同一份文档跑两次结果可能不一样，这在需要可复现的金融场景很要命。我的处理是：

• 抽取 prompt 里给 few-shot 示例，固定输出格式（JSON schema），降低随机性。
• 温度参数调到很低（接近 0）。
• 关键关系抽取跑两遍取交集，只保留两次都抽到的，牺牲召回换准确。
• 抽取结果入库前过一遍规则校验（比如引用的条款号必须真实存在）。

5.3 性能：多跳查询别把图库拖垮

图检索的性能瓶颈通常在多跳展开时的路径爆炸。几个优化点：

• 给高频查询起点建索引。
• 限制单次查询的展开节点数和跳数。
• 对"文件包含条款"这类大扇出的边，查询时用方向约束（只从条款往文件查，不从文件往条款全展开）。
• 热点问题的检索结果做缓存，金融问答的重复率其实很高。

5.4 评测：没有评测集就是盲飞

金融知识管理平台最容易被忽略的是评测。上线前必须建一个业务标注的问答评测集，覆盖定义型、流程型、多跳型、边界型（知识库没有答案的）几类问题，每条标注标准答案和应引用的条款。每次调整抽取规则、检索策略、prompt，都跑一遍评测集看指标变化。

指标上，除了答案准确率，我特别看重两个：引用准确率（引用的条款是否真的支撑答案）和拒答正确率（知识库没有的该拒答时是否拒答）。这两个指标直接对应金融场景的合规风险。

6. 一套可复用的落地节奏

把上面的东西串起来，我给一个从零到跑通闭环的节奏建议，供参考。

第一阶段：单业务域打样。选一个高频、文档相对规整的业务域（比如某类授信业务），把该域的制度文件解析、抽取、建图、问答全链路跑通。目标是验证 schema 设计和抽取流水线，不求覆盖广。

第二阶段：评测集建设。同步建这个域的问答评测集，至少 100 条，覆盖各类问题。这是后面所有优化的标尺。

第三阶段：检索策略调优。基于评测结果调意图路由、跳数、剪枝规则、融合权重。这一步最耗时，也最见功力。

第四阶段：横向扩展。schema 和流水线稳定后，按业务域逐个扩展。每扩一个域，评测集同步扩，防止新域拉低整体质量。

第五阶段：运营闭环。上线后收集用户反馈（尤其是"答错""答不全"的 case），定期回流到评测集和抽取规则里。知识管理平台不是建完就完，是个持续运营的活儿。

我个人在实际项目里的体会是：这套方案的技术难点不在某个单点（图库、大模型、向量库都是成熟组件），而在链路的衔接和质量的兜底。抽取、检索、生成每一环都有不确定性，平台的价值就在于用工程手段把这些不确定性控制在业务可接受的范围内。别追求一步到位的"智能"，先把"准"和"可追溯"做扎实，智能是水到渠成的事。

最后分享一个小技巧：上线初期，在答案旁边加一个"这条回答有帮助吗"的反馈按钮，把点"没帮助"的 case 连同检索证据一起落库。这批数据是优化检索策略最宝贵的素材，比任何离线评测都真实。