金融行业的知识管理一直是个看着简单做着要命的活儿。表面上无非是把制度文件、产品手册、风控规则、监管报送口径这些东西存起来、查得到但真到了业务一线柜员问一句这笔跨境结算的展业三原则怎么落地后台可能要翻三套系统、问两个部门、等半天回复。大模型火了之后很多团队第一反应是接个通用问答机器人不就完了结果一上线就翻车答得似是而非、引用查无出处、监管口径对不上、跨文档的关联关系完全理不清。这篇就围绕信雅达 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 的核心。一个可落地的流程是这样的问题解析用户提问后先用大模型做意图识别和实体抽取判断这个问题是语义模糊型如什么是适当性管理还是关系导航型如某产品对应哪级审批。双通道召回语义型走向量检索召回文档块关系型走图检索从识别出的实体出发做多跳查询。结果融合两路结果按相关度、时效性、来源权威性加权融合去重后送入生成环节。生成与溯源大模型基于融合后的上下文生成答案同时把引用的条款、文件版本一并输出。这里有个容易忽略的点融合不是简单拼接。向量召回的结果是文本块图召回的结果是结构化路径两者格式不同需要统一成带出处的证据片段再喂给模型。我的做法是给每个证据片段打上source_typevector/graph、doc_id、clause_id、version标签生成时要求模型在答案里标注引用编号前端再把这些编号映射回原文链接。3. 从文档到图谱知识抽取流水线的工程细节3.1 文档解析金融 PDF 是最难啃的骨头金融制度文件大多是 PDF而且排版复杂多栏、表格、页眉页脚、扫描件混排。解析质量直接决定后面抽取的成败。这一步的坑比想象中多。表格是重灾区。制度文件里的审批权限表风险等级对照表往往承载核心信息但普通 PDF 解析器会把表格拍平成乱序文本行列关系全丢。我的经验是表格必须单独走表格识别通道识别成结构化数据行列对齐再决定是存成图的属性还是单独建节点。比如客户等级-审批层级对照表解析后应该变成一组(客户等级, 审批层级)的映射关系直接进图。页眉页脚和条款编号要保留。条款编号如第 X 条是溯源的关键锚点解析时不能当噪声删掉。我一般会在解析阶段就把条款切分出来每个条款作为一个独立单元带上所属文件、条款号、页码这样后面建图时条款节点天然就有出处信息。扫描件要单独处理。纯图片 PDF 得先走 OCROCR 之后再走同样的结构化解析。OCR 的错字率在金融术语上偏高敞口识别成敝口之类建议对高频术语建一个纠错词典做后处理。3.2 实体与关系抽取规则 模型双管齐下抽取环节纯靠大模型做成本高且不稳定纯靠规则覆盖不全。实操里最稳的是规则打底、模型补漏。规则层负责高置信度的结构化抽取条款引用正则匹配依据《...》第 X 条参照...规定等模式抽出引用关系。条款编号与层级按章-节-条的编号规律切分。定义句匹配XX 是指...本办法所称 XX...抽出概念定义。模型层负责规则覆盖不到的语义抽取用大模型对条款做实体识别抽出业务概念、角色、流程节点。用大模型判断条款之间的隐含关系比如两条条款讲的是同一件事的不同侧面。这里的关键设计是抽取结果要带置信度和来源。规则抽的标confidencehigh模型抽的标confidencemedium低置信度的关系进图前要人工抽检。金融场景宁可少建边不可建错边——一条错误的引用关系会让多跳检索把用户带到完全无关的条款上。一个实用技巧抽取流水线做成可回放的。每份文档的解析结果、抽取结果、进图结果都留中间产物出问题时能定位是解析错了、抽取漏了还是入库写错了。金融知识库的调试没有中间产物基本没法查。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 连同检索证据一起落库。这批数据是优化检索策略最宝贵的素材比任何离线评测都真实。 
长河君 · 2026/11/2 12:57:28 · 阅读 1.2k 金融知识管理平台如何落地Graph RAG：从向量检索到图增强的工程实践
金融行业的知识管理一直是个看着简单做着要命的活儿。表面上无非是把制度文件、产品手册、风控规则、监管报送口径这些东西存起来、查得到但真到了业务一线柜员问一句这笔跨境结算的展业三原则怎么落地后台可能要翻三套系统、问两个部门、等半天回复。大模型火了之后很多团队第一反应是接个通用问答机器人不就完了结果一上线就翻车答得似是而非、引用查无出处、监管口径对不上、跨文档的关联关系完全理不清。这篇就围绕信雅达 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 的核心。一个可落地的流程是这样的问题解析用户提问后先用大模型做意图识别和实体抽取判断这个问题是语义模糊型如什么是适当性管理还是关系导航型如某产品对应哪级审批。双通道召回语义型走向量检索召回文档块关系型走图检索从识别出的实体出发做多跳查询。结果融合两路结果按相关度、时效性、来源权威性加权融合去重后送入生成环节。生成与溯源大模型基于融合后的上下文生成答案同时把引用的条款、文件版本一并输出。这里有个容易忽略的点融合不是简单拼接。向量召回的结果是文本块图召回的结果是结构化路径两者格式不同需要统一成带出处的证据片段再喂给模型。我的做法是给每个证据片段打上source_typevector/graph、doc_id、clause_id、version标签生成时要求模型在答案里标注引用编号前端再把这些编号映射回原文链接。3. 从文档到图谱知识抽取流水线的工程细节3.1 文档解析金融 PDF 是最难啃的骨头金融制度文件大多是 PDF而且排版复杂多栏、表格、页眉页脚、扫描件混排。解析质量直接决定后面抽取的成败。这一步的坑比想象中多。表格是重灾区。制度文件里的审批权限表风险等级对照表往往承载核心信息但普通 PDF 解析器会把表格拍平成乱序文本行列关系全丢。我的经验是表格必须单独走表格识别通道识别成结构化数据行列对齐再决定是存成图的属性还是单独建节点。比如客户等级-审批层级对照表解析后应该变成一组(客户等级, 审批层级)的映射关系直接进图。页眉页脚和条款编号要保留。条款编号如第 X 条是溯源的关键锚点解析时不能当噪声删掉。我一般会在解析阶段就把条款切分出来每个条款作为一个独立单元带上所属文件、条款号、页码这样后面建图时条款节点天然就有出处信息。扫描件要单独处理。纯图片 PDF 得先走 OCROCR 之后再走同样的结构化解析。OCR 的错字率在金融术语上偏高敞口识别成敝口之类建议对高频术语建一个纠错词典做后处理。3.2 实体与关系抽取规则 模型双管齐下抽取环节纯靠大模型做成本高且不稳定纯靠规则覆盖不全。实操里最稳的是规则打底、模型补漏。规则层负责高置信度的结构化抽取条款引用正则匹配依据《...》第 X 条参照...规定等模式抽出引用关系。条款编号与层级按章-节-条的编号规律切分。定义句匹配XX 是指...本办法所称 XX...抽出概念定义。模型层负责规则覆盖不到的语义抽取用大模型对条款做实体识别抽出业务概念、角色、流程节点。用大模型判断条款之间的隐含关系比如两条条款讲的是同一件事的不同侧面。这里的关键设计是抽取结果要带置信度和来源。规则抽的标confidencehigh模型抽的标confidencemedium低置信度的关系进图前要人工抽检。金融场景宁可少建边不可建错边——一条错误的引用关系会让多跳检索把用户带到完全无关的条款上。一个实用技巧抽取流水线做成可回放的。每份文档的解析结果、抽取结果、进图结果都留中间产物出问题时能定位是解析错了、抽取漏了还是入库写错了。金融知识库的调试没有中间产物基本没法查。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 连同检索证据一起落库。这批数据是优化检索策略最宝贵的素材比任何离线评测都真实。