做因果图谱这件事前前后后试了一年多。从早期纯靠人工标注调结构到后来用规则模板硬套再到今天这套用大模型做“三步提取”的方案绕了不少弯路。这篇文章不聊什么高深论文就是把我自己调试出来的一套完整流程以及踩过的那些坑整理成一篇能直接上手的实操总结。如果你正在做可解释AI、需要从非结构化文本里挖因果链路或者想搞清楚怎么让大模型输出稳定可靠的结构化因果数据这篇内容应该能帮你省下不少折腾时间。1. 为什么大模型和因果图谱会走到一起1.1 可解释AI缺的那块拼图市面上的解释性方法像特征重要性排序、梯度热力图、注意力权重视觉化本质上都在回答一个很浅层的问题哪个输入对输出影响大。但业务方真正想知道的往往是“为什么”——为什么这个客户会流失为什么这个设备会故障为什么这个指标会在上周突然跳变。要回答这类问题靠相关性分析是不够的你得有一条清晰的因果链路。因果图谱就是干这件事的。它把业务场景里的实体、事件、因素之间的因果关系用有向图的方式显式表达出来。比如“网络延迟升高 → 服务超时率上升 → 用户满意度下降 → 流失风险增加”这样一条链既能让业务方看懂也能给下游决策系统提供推理依据。关键问题是因果图谱从哪里来。传统做法是找领域专家手动构建成本极高而且存在一致性差的毛病。我从不同资历的人那里拿到的图谱结构往往对不齐。基于统计的因果发现算法比如 PC 算法、FCI 算法又依赖高质量结构化数据在很多数据基础较弱的业务场景里基本跑不动。这就是大模型的机会。1.2 大模型能解决什么问题大模型擅长的事情是语义理解和知识抽取。它对自然语言里的因果关系其实是有相当强的隐式理解的。你用一段描述业务故障的日志、一篇技术复盘文档甚至一堆客服对话记录它能从中识别出谁导致了谁、什么前置条件触发了什么结果。这恰恰是传统因果关系建模最头疼的输入形式。但我一开始也走了一个误区以为丢给大模型一句“帮我抽因果”它就会吐出一份能用因果图。实际效果很快就教我做人了——模型确实能给出一些关系但格式千奇百怪实体命名不一致逻辑环没处理最离谱的是经常把“相关关系”错当成“因果关系”。真正能落地的方案是把这个任务拆成清晰的三步每一步用独立的提示词和校验逻辑去约束模型输出。后面我会详细讲每一步的设计。1.3 这套方法适合谁如果你满足下面几条中的任意一条可以继续往下看手头有大量非结构化文本类资料事故报告、客户反馈、试验记录、复盘文档想把里面的因果知识整理成图。正在搭建业务知识图谱尤其是偏向决策支持、风险评估、故障诊断方向。做的是可解释AI相关的产品希望给模型预测结果提供“原因说明”而不只是相关性数字。对因果推断感兴趣但苦于没有现成结构化数据来跑传统因果发现算法。我讲的这套“三步提取法”文本输入可以是句子级短文本也可以是上千字的报告。核心思路是一样的。2. 三步提取法的总体设计思路2.1 为什么拆成三步而不是一步到位这就要说说大模型的一个老毛病了——任务复杂度越高输出质量越不稳定。你让它一次性完成“抽取要素、判断因果、构建图谱”的全部工作它很容易在局部关系上发挥过头结果整体却乱七八糟。就像你让一个新员工直接负责整个项目他可能会在标注细节上花光所有精力却忽略了核心流程的控制点。我的做法是把任务拆分成三个边界清晰的子任务从纯文本中抽取事件要素谁/做了什么/发生了什么/条件是什么。判定要素之间的因果语义关系是因果关系、相关关系、时序关系、还是无关系。汇总所有因果关系完成节点归并、去环检查、信度标注输出标准图谱文件。拆完之后每一轮的产出都是下一轮的输入中间任何一个环节出了问题只用调试那一步就行。这种做法还有一个额外好处——排查和审计起来方便。比如业务方质疑某条因果链不合理我只要回溯到第二轮的判定结果就能看到模型给出的判断理由和置信度而不是面对一堆无法追溯的黑盒输出。2.2 三步之间的数据流数据流的设计我踩过不少坑这里直接给出一个稳定版本文本输入 → [第一步] 事件要素提取 → 得到事件节点集合 → [第二步] 因果语义判定 → 得到候选因果边 → [第三步] 图谱组装 → 去重、合并、环形校验 → 最终因果图谱。每一步的输入输出都设计成 JSON。为什么选 JSON因为大模型对 JSON 的生成能力经过大量训练相对稳定而且 JSON 自带结构化方便程序后续直接解析处理。我见过有人用自然语言段落做中间传输表面上省了格式化约束实际后处理要用正则去抠各种表达非常不可靠。2.3 与纯规则方案、纯人工方案的对比我最早用规则模板做因果抽取。定义一套触发词库“因为”“所以”“导致”“引发”等配合句子切分来抓因果断言。这套方案在固定语料上表现还行但换一个领域规则基本全废维护成本很高。当时为了适配新的业务术语花了大半个月去调规则结果模型的泛化需求一上来又得推翻重来。人工构建当然是最准的但一个小时能整理十对关系就算很快了根本扛不住文档量级。大模型方案处在两者中间偏上的位置效率和自动化程度接近纯规则方案准确率经过校准后可以逼近人工标注的实用水平而且跨领域适应能力天然比规则强得多。概括起来讲规则方案适合小规模、主题高度集中的场景人工方案适合质量要求极高、数据量小的场景大模型三步法适合数据量大、需要持续迭代更新的场景。下表是个直观对比基于我在模拟项目X和后来某跨平台系统里反复实测的体感数据方案构建速度一致性跨领域能力可维护性人力成本纯规则模板快高极差差中纯人工构建慢中好中极高大模型三步法快较高好好低3. 实操过程从提示词到完整图谱3.1 第一步事件要素的提取这里有一个核心认知要纠正一下因果图中的节点在业务场景里通常不是“实体”而是“事件”或者“状态”。比如“网络延迟升高”和“用户投诉增多”这两个节点本质是事件或状态而不是“网络”和“用户”这种静态实体。所以在提取阶段我们用的不是经典的实体关系三元组抽取主体-谓词-客体而是事件三元组 (触发条件, 行为主体, 结果状态)。具体提示词我提供了一个相对稳定的模板。以下是一个通用版本你们可以按自己的场景调你是事件要素提取专家。给定一段中文文本提取其中所有与业务相关的事件要素。 每个事件必须包含 - event_id: 事件唯一编号 - event_desc: 事件描述不携带因果判断只描述发生了什么 - subject: 事件的主角实体或概念 - trigger: 事件的触发条件或前置状态如果没有可留空 - effect: 事件造成的结果状态如果没有可留空 约束条件 1. 仅抽取文本中明确表达的信息不进行推测。 2. 同一个事件在不同句中重复出现时event_desc 用相同表述。 3. 返回格式为 JSON 数组。 文本内容 {文本}这里有个细节值得说为什么要求event_desc 用相同表述因为大模型对同一件事的描述天然会有各种改写比如“网络发生延迟”、“延迟升高了”、“网络卡顿严重”如果不在抽取源头约束一致性后面做节点归并时会非常痛苦。虽然第三步有基于语义相似度的归并逻辑但源头越干净后面越省事。抽取完成后你会得到一个初始事件集合。这个集合需要人工粗筛一遍把完全不相关的事件剔除。我一般会让至少两位同学各筛一轮不一致的地方一起对齐。这一步不要省筛掉无关事件对后续第二轮精度提升非常明显。3.2 第二步因果语义的判定第二步是整个流程里最容易翻车的环节。原因在于大模型对“因果关系”的边界理解跟业务方的预期经常不一致。大模型的训练语料里充斥着“因为下雨所以堵车”这类日常表达但业务场景里大量出现的是弱因果关系、间接因果关系、促成关系还有一些看起来像因果其实是共因导致的伪因果。我的做法是不给模型开放式的“找出所有因果关系”的任务而是给它一个两两对比的任务——把所有已经提取出的事件节点两两配对让模型逐一判断这两个事件之间是否存在因果关系以及关系方向。这样的好处是限制了任务边界模型不需要自己在海量事件里做自由联想只做受限判断稳定性会高很多。两两配对的代价是复杂度变成 O(N²)。事件数量到 200 以上时配对数量会达到近 2 万对大模型的调用量是个大考验。200 个事件以内是我实测最舒服的量级。超过这个量级建议先把事件聚类成几组组内跑两两判定组间只跑“跨组重点关系”判定。这里贴一段核心判定提示词你是因果语义判定专家。给定事件A和事件B判断A是否是B的因或者B是否是A的因。 判断标准 1. 因果必须满足如果A不发生B大概率不会发生。 2. A的发生时间可以早于B也可同步针对持续的并发过程。 3. 单纯的先后顺序或统计相关不构成因果。 4. 如果A和B都是由第三个因素引起的不构成直接因果。 5. 如果A部分促成了B非决定性请标注 causal_type 为 contributory并在 confidence 中使用0.5-0.7之间的分数。 返回严格JSON {relationship: A→B | B→A | none | bidirectional | unknown, reason: 简短判断依据, confidence: 0.0-1.0} 事件A{事件描述A} 事件B{事件描述B}关于第 4 条标准共因共同原因导致的伪因果非常常见。举个例子“A系统的CPU使用率升高”和“B系统的延迟降低”同时出现看起来像A影响了B实际上可能都是因为某次整体资源分配策略调整导致的。模型如果在校验阶段没有被明确要求排除共因就会给出一堆假阳性因果边图谱会越建越歪。这条标准一定要写进提示词里。另外我建议开启多轮抽样。同一个事件对让模型独立判定 3 次取置信度平均。这样做会消耗更多 token但换来的是稳定性质的提升。尤其当某条边的置信度在三轮之间呈离散分布比如 0.9、0.1、0.9时说明模型对这个关系把握不稳定策略是降低置信上限并做标记而不是相信多数票。3.3 第三步图谱组装前两步输出的是一大堆候选因果边。第三步就是把这些边转成一张干净、规范、有实际使用价值的图。这一步我按顺序做四件事第一步是节点归并。语义相同但表述不同的节点需要合并成一个规范节点。我用的是 embedding 相似度加规则双重确认。先通过文本向量算相似度找出候选重复节点再人工抽查一批阈值边界附近的case最终确认阈值。不同领域的语义相似度差异会很明显——技术文档里“宕机”和“服务不可用”相似度可能很高但客服对话里“不高兴”和“生气”形态差别大阈值就要调低。没有万能阈值只有反复对齐。第二步是方向一致化。如果 A→B 和 B→A 两条边同时出现了通过置信度对比保留高置信度方向低置信度那条翻转或者直接删除。双向因果在真实业务里确实存在比如“供需”和“价格”就是典型互因但如果两边置信度都很高我通常会保留双向标记而不是武断删掉一条。第三步是环检查。因果图中存在环在大多数业务解释场景里是无意义的先有鸡还是先有蛋的问题在有限上下文里很难回答。我用深度优先搜索检查有向图环环上的边单独导出到一个待审清单人工介入判断打断哪条边最合理。注意这一步处理的是已归并后的最终节点图不是候选边集合否则会因为临时节点重复而误报大量环。第四步是信度标注和导出。给每条边附上平均置信度、原始支持证据片段、判定轮数。导出的格式我一般用两种一是面向图数据库查询的边表节点表 CSV二是面向前端展示的 JSON 格式后面接可视化工具直接渲染。3.4 一个精简的端到端流程示例为了更直观这里贴一个 Python 伪代码流程方便你理解三步之间的衔接逻辑import json def extract_events(text, llm_client): prompt build_event_extract_prompt(text) response llm_client.chat(prompt) events json.loads(response) return events def judge_causal_relation(event_a, event_b, llm_client): prompt build_causal_judge_prompt(event_a, event_b) response llm_client.chat(prompt) return json.loads(response) def build_causal_graph(events, llm_client, max_pairs200): edges [] for i in range(len(events)): for j in range(i1, len(events)): # 实际使用时会分批调用并对关键边做多次抽样 result judge_causal_relation(events[i], events[j], llm_client) if result[relationship] in (A→B, B→A, bidirectional): edges.append({ source: events[i][event_id], target: events[j][event_id], direction: result[relationship], confidence: result[confidence], reason: result[reason] }) # 归并、去环、导出 merged merge_duplicate_nodes(events) deduped_edges merge_and_deduplicate(edges, merged) final_edges break_cycles(deduped_edges) export_graph(final_edges) text load_text(某领域故障复盘报告.txt) events extract_events(text, llm_client) build_causal_graph(events, llm_client)这个流程虽然是伪代码但核心结构就是我线上用的逻辑。真正部署时会加批处理、错误重试、限流控制但思路完全一致。4. 常见问题与排查技巧实录4.1 节点抽取太碎怎么办我最早跑的一个项目里模型把“服务异常”和“数据库锁死”拆成了两个事件节点。但实际上“数据库锁死”是“服务异常”的底层原因之一应该在事件合并阶段就处理成归属关系而不是平级节点。平级处理会让图谱节点数量膨胀到四百多个很多链路上出现冗余跳跃。后来我加了一个额外的层级分类提示让模型对每个事件标注维度标签原因类/过程类/结果类在归并阶段优先把“原因类节点”放在链路上层“结果类节点”放在下层。这本质上是让模型做一层隐式分层归并起来明显清爽很多。4.2 置信度平均传播带来的偏差如果你对每一条候选边都做三轮采样取平均置信度并对所有边设定同一个过滤阈值比如 0.7你会遇到一个问题某些单条关键边因为表述含糊被模型打了低分结果差点被过滤掉而某些冗余边被模型反复确认分数虚高。我的处理方式是分级阈值而不是统一一刀切。主干边图谱中第 2 跳以内的边也就是离核心节点最近的那些阈值下调到 0.55分支边维持 0.7。这背后的逻辑是主干边错误的影响远大于分支边与其漏掉主干不如接受一些待验证的候选配合人工抽查来弥补。0.55 这个值不是拍脑袋定的是通过对一批已知正确边和已知错误边的置信度分布对比算出来的约等于两类分布的交叉点。4.3 文本过长导致提取不完整大模型有上下文窗口限制。如果你的输入是一整篇几千字的报告直接丢给模型做事件抽取它通常会漏掉中间段落的内容而且越到文本后半段漏得越严重。这个现象本质上是注意力机制对长文本的衰减导致的不是任务本身难。我建议在第一步做文本切分。按照语义段落把长文本切成多个 500 字以内的块块与块之间保留 50 字的重叠重合部分要做去重。第一遍每个块单独做事件抽取第二遍把所有抽取结果聚合起来再做一轮跨块的重复事件合并。切分重叠这一段看似无所谓但实际很关键。如果完全没有重叠一个跨段落表达的事件很可能会在切缝处被割裂提取出两个只描述一半的残缺事件。重叠 50 字基本能覆盖多数正常句子的边界。4.4 模型把“相关”硬说成“因果”这一步是误判重灾区。写提示词时如果只告诉模型“A和B是否相关”基本等于在诱导它疯狂连线。相反要在提示词里锚定“反事实”标准——如果A不发生B会不会不一样。这是因果的第一性原理。我还做了一件额外的对抗操作在第二步判定前让模型先生成一个“表面共因候选清单”。模型列举文本里可能同时影响多个事件的隐藏因素然后第二步判定时单独抑制这些共因因素直接导致的因果边。这个操作不需要额外工具就是提示词里加一轮预筛效果立竿见影误报边数量大约下降了三成。4.5 图谱可视化阶段的混乱最后讲一个实操中的体验问题。构建完的图谱如果节点超过 50 个直接渲染会乱成一团。我常用的是先按连通分量拆分单独展示最大的几个子图再配合交互式的局部放大查看。另外给边加颜色映射层——按置信度区间设三档颜色业务方一眼就能看出哪些链路靠谱哪些还需要人工确认。4.6 问题排查参考速查表现象可能原因排查重点节点过多、过碎抽取粒度控制不足检查提取提示词中是否要求“事件级”而非“描述级”因果边误报率偏高缺少共因抑制检查第二步提示词中是否写入共因排除准则模型输出 JSON 解析失败生成长文本时截断或转义错误增加输出长度限制开启严格 JSON 模式增加失败重试实体指代混乱抽取阶段未约束统一表述检查事件描述一致性约束加重叠切分与归并图结构出现大量环归并后方向冲突未解决检查去环步骤是否在归并之后执行5. 可解释AI场景下的落地与进阶玩法5.1 因果图谱怎么解释模型预测构建因果图谱本身不是目的目的是服务解释。我的实践是通过“预测结果反查因果路径”实现的。举个例子在某个客户流失预测模型里模型预测某客户流失概率为 0.8一般的解释方法是看特征贡献度——发现“最近登录次数低”贡献最大。但业务方还想知道为什么登录次数低。这时候如果图谱里有“新功能改版 → 操作复杂度上升 → 活跃度下降 → 登录次数降低”这条链就可以直接把解释沿着因果路径向前追溯一层、两层甚至更远。这个机制实现起来并不复杂。在做预测特征归因结果出来之后把贡献度最高的那个特征当成末端节点在图谱里快速回溯它的所有上游因果节点。把这些上游节点的叙述文本拼成一段自然语言解释就形成了一个从“原因端”到“表现端”的完整说明。我自己对这种方式的理解特征归因解决的是“这个模型关注什么”因果图谱解决的是“这个关注从哪里来的”。两者结合解释的穿透力完全不一样。5.2 图谱更新与迭代机制业务世界里没有一劳永逸的图谱。需求变化、产品调整、外部环境变化都会让旧图谱失真。我建议设定一个更新周期新文档进来时先做增量提取把新事件和新边合并进旧图如果新事件跟旧图里的节点发生冲突优先保留已知图结构只在证据足够充分时做替换。这样保证图谱结构稳定变更可控不会因为一份文档就大改版。5.3 和传统因果推断算法的协作大模型给出的因果图严格来说是基于语义的先验结构知识不是通过干预数据验证过的因果结论。更严谨的工程落地方式是把大模型生成的候选因果图作为先验结构输入再叠加一些传统因果推断的检验手段去排除矛盾边其实是能得到更经得起推敲的结论的。我做过的验证是拿到候选因果图后对其中关键边抽取对应的结构化时序数据用一些基于统计的扰动检测方法具体不展开算法名了你们可以根据数据形态选择验证这些边的因果方向是否和数据表现一致。如果数据出现反向或无关证据就降低该边的置信度甚至把它从图中降级成“待定边”。这是一套“定性结构语义定量验证数据”的组合拳适合追求严谨度的项目。6. 最后分享几个实操心得整个三步提取法跑通之后我最深的体会是大模型构建因果图谱真正难的不是模型能力而是任务拆解和校验环节的设计。模型本身具备不错的因果语义理解能力但你必须给它边界清晰的子任务和可判定的输出格式不然它就会像灌了太多信息的思维泡沫什么都想说什么都说不准。几个最有价值的细节我再强调一遍第二步的两两判定模式是我尝试过的各种方式中最稳定的一种。虽然调用量大但每次任务的边界极小模型犯错的概率被压到了最低。三步之间用 JSON 做数据交换中间不穿插自然语言格式描述可以省掉大量不可控解析。置信度分级阈值一定要做不要拍脑袋定一个全局阈值。环检查务必在归并之后执行否则会产生大量误报。如果你刚开始跑这套流程我建议先用 50 条以内的事件小规模试水完整跑一遍三个步骤把所有提示词和输出格式调顺了再放大到几百条事件的真实场景。我第一次直接上大场景结果一半时间花在排查格式错误和数据错位上。这套方法后续的扩展空间也不少可以接入实时数据流做动态因果图谱可以把事件要素抽取换成领域微调过的专用模型还可以把图谱输出给大模型做基于图上下文的多跳推理问答算是知识图谱、可解释AI、Agent 决策三条线的交叉点。每次在这些方向上做一点尝试都会有一些新的收获。
