我们遇到的一个问题

贷后巡检报告，是银行风险管理的核心环节。但长期以来，这份报告的生成方式本质上是一门"手艺活"——分析师从多个系统导出Excel，凭经验交叉比对数据，最终写下一段带有主观判断的风险评估。

这带来三个根本性缺陷：不一致（同一企业，不同分析师得出不同结论）、不可审计（风险评级的依据只存在于分析师的脑中）、不稳健（一个数据修正可能导致整段评估逻辑坍塌）。

当我们把目光投向大模型（LLM）时，一个自然的想法是：让AI来写报告不就行了？但问题在于，即使在AI时代，将一系列相关风险指标和提示词让大模型进行判断，也相当随意。因为——如果AI既做分析又写文字，它可能在措辞上"说得头头是道"，却在事实上"判断错了方向"。

这促使我们思考：能否找到一种方法论，让所有实质性结论在AI动笔之前就已经被确定性计算锁定，AI只负责"翻译"成可读语言？

EAR：给数据搭一副"骨架"

EAR（Entity-Attribute-Relation）本体论方法论，核心思想是用三个结构要素将业务指标组织成一张语义知识图谱：

Entity（实体） 是业务世界中可独立识别的"事物"。例如"利润表""偿债能力指标""征信查询记录"，每个实体是一组相关指标的逻辑容器。

Attribute（属性） 是实体的可观测特征。每一项原始业务指标，都精确映射为某个实体的一项属性。比如"流动比率"是偿债能力实体的一个属性，"90天内查询机构数"是征信查询实体的一个属性。

Relation（关系） 是实体之间有业务含义的连接。比如利润表与偿债能力之间存在"推导关系"（DERIVED_FROM），征信查询行为与信用卡使用之间存在"因果影响"（IMPACTS），同一企业在不同维度的指标之间存在"交叉验证"（CORRELATES_WITH）。

这三层结构的价值在于：数据决定骨架，形成了一张有脉络、有方向、可追溯的知识网络，而不再散落在孤立的表格里。

业务专家：EAR模型的真正"作者"

这里需要特别强调一点：EAR模型不是技术人员闭门造车写出来的，它的真正作者是业务专家。

实体怎么划分、指标归属哪个实体、实体之间是"因果影响"还是仅仅"交叉验证"、风险预警的阈值设在哪里——这些问题的答案，不在代码里，不在数据库里，而在资深风控专家长期积累的业务判断中。

在我们的实践中，业务专家的参与贯穿三个阶段。建模阶段，专家与技术人员共同完成"指标→实体→关系"的推导：哪些指标描述同一个业务主体、计算衍生指标是否应独立为实体、关系类型选 DERIVED_FROM 还是 IMPACTS，都经专家确认。规则定义阶段，35条预警规则的触发条件和风险等级全部来自专家经验——比如"流动比率下降超20%且速动比率低于0.8即判定为高风险"，这条规则的阈值组合不是统计回归的结果，而是专家在大量真实案例中提炼的判断标准。验证阶段，模型上线前由专家对典型企业进行"背靠背"校验：将专家独立给出的风险判断与系统输出对比，确保模型的结论与专家共识一致。

把专家脑子里的经验从隐性知识变成显性结构。沉淀到图数据库的经验就不再随人员变动而流失，也不再因个人状态波动而偏移。技术团队负责搭管道、写引擎、跑数据，业务专家决定权始终在手中。

六步流水线：从原始数据到巡检报告

基于EAR模型，我们构建了一条六步确定性流水线。每一步都有明确的输入、输出和工程化产物：

Step 0 — Schema定义： 在Neo4j图数据库中建立所有实体的约束和索引，相当于给知识图谱打地基。我们覆盖了财务分析、征信（企业和个人）情况、业务发展、经营分析、舆情分析5个维度，定义了32种实体类型和16+种关系类型。

Step 1 — 数据导入： 将企业指标数据（JSON格式）转化为Neo4j中的节点和关系。采用策略模式设计，每个维度一个导入器子类，支持幂等操作。

Step 2 — 图查询： 从企业ID出发，沿EAR拓扑遍历所有维度的实体和关系，输出结构化数据。关键能力是"跨维度传播链查询"——比如发现"应收账款偏高→现金流紧张→偿债压力增大"这条横跨三个实体的风险传导路径。

Step 3 — 规则引擎： 执行35条风险预警规则，涵盖短期偿债恶化、征信查询异常、负债膨胀、利润贡献断崖等典型场景。每条规则输出确定性的触发状态和风险等级。

Step 4 — Prompt构建： 将图数据、规则结果和EAR拓扑关系组装为结构化上下文，注入大模型的Prompt模板。

Step 5 — 报告生成： 大模型基于已锁定的结论生成可读报告。此时AI的角色不是"分析师"，而是"翻译官"。

三个关键特性

这套方法论带来了三个传统模式无法企及的特性：

确定性。 我们对规则引擎做了SHA-256哈希验证——三次独立运行产生完全相同的输出。同一份数据交给不同人、在不同时间触发，得到的风险结论完全一致。AI生成的两份报告在实质性判断上100%吻合，仅在措辞上存在同义词替换。

可审计性。 每一个风险结论都可以沿五层路径溯源：报告结论→规则逻辑→实体属性→关系拓扑→原始数据。在Neo4j中，审计人员用一条Cypher查询即可遍历整条证据链。

稳健性。 Schema约束在写入时拦截脏数据；关系隔离使单个节点的修正不会波及无关规则；阈值型规则天然具有缓冲空间——比如一个比率值为1.95而阈值为1.0，安全裕度接近100%。

一个方法论层面的启示

EAR本体论的核心主张其实很简单：在让AI"说话"之前，先用图数据库确认"事实"。 实体定义锁定了哪些数据值得关注，关系定义锁定了数据之间的逻辑方向，规则引擎锁定了风险判断的阈值和条件——而这些定义的背后站着的始终是业务专家。当这三层确定性计算完成后，大模型把专家共识翻译成人类可读的自然语言。

这种"本体论先行、AI后置"的思路，不仅适用于贷后巡检，也适用于任何需要AI参与专业判断、但又不能让AI"自由发挥"的场景——审计合规、质量评估，都有类似的方法论需求。

当行业都在讨论如何让大模型更"聪明"时，或许更值得思考的是：如何让大模型只能"说对的话"，而不是"说得像对的话"。