每次看到同事参与可研报告评审，我都会共情他们那种熟悉的疲惫感：一边翻着厚厚的 PDF， 一边在不同章节里来回确认“这个总投资到底是哪一个版本”“这里的年发电量和前面说的是不是同一个口径”。

很多时候，明知道问题可能藏在“容量—利用小时—发电量—IRR”这条链路上，但人的注意力和时间都很有限， 只能挑几个关键点“感性扫一遍”，心里多少有点不踏实。

也正因为他们这种无力感，我开始认真思考：能不能把那些散落在报告各处的数字、指标和结论，从文档里“拎出来”， 变成一张结构化的、能被程序检查和追踪的“关系网”？

这篇文章就是一次偏工程化的尝试，不谈虚的“颠覆评审方式”， 而是脚踏实地地看看：在现实的可研评审场景里，知识图谱到底能帮我们多做一点什么。

为什么需要知识图谱？

可行性研究报告的几个典型特点：

  • 信息高度碎片化： 项目概况、资源条件、接入系统、投资估算、财务测算、风险分析…… 同一个指标（如总投资、建设规模、年发电量），在不同章节会被多次引用甚至“改口”。

  • 跨章节长距离依赖：

    比如：

    • “容量、利用小时 → 年发电量 → 收入 → 财务指标”；
    • “接入点、电压等级 → 线路长度、造价 → 接网投资”。

  • 多版本、多参与方： 设计院、业主、咨询方来回修订，容易出现“正文改了，表没改”“指标更新了一半”的情况。

  • 审查压力大： 专家通常时间有限，只能靠经验“扫一遍关键章节”，很多隐藏的不一致很难一眼看出。

知识图谱的优势刚好在于： 把“分散在文档各处的实体、数值和关系抽出来，放进一张可计算、可查询的图里”。

类似思路已经在财报、金融分析等场景里被证明有价值，例如用知识图谱去统一财务报表数据、做跨文档一致性检验、支持复杂查询与分析。

从可研报告到知识图谱

文本预处理

  • 分章节、分段、分句：按目录结构切出“章节—小节—段落—句子”层级。
  • 做基础清洗：去掉无信息的格式符号、页眉页脚、重复页码等。
  • 适度简化复杂长句： 例如把“本项目拟在 XX 县 YY 镇布置装机容量约 100MW 的风电场，接入 ZZ 变电站 220kV 母线” 拆成两句，方便后面的实体、关系抽取。

这一层更多是工程问题，但决定了后面图谱的干净程度。

实体识别

用 LLM + 规则，识别出报告中的关键实体（可按领域自定义）：

  • 项目相关实体：项目名称、阶段（可研、初设）、建设地点、建设规模等；
  • 技术实体：风机/组件型号、塔筒高度、逆变器型号、接入电压等级、线路长度等；
  • 经济实体：静态总投资、资本金、单位造价、上网电价、度电成本、IRR、NPV 等；
  • 时间与场景：基准年、测算期年限、建设期、不同情景等。

在知识图谱里，这些实体会变成节点。

这一步与常规 NER 类似，只是需要结合领域词表与本地规则。

关系抽取

在可研语境下，最常见的关系大致可以归为几类：

  • 数值归属关系：

    • （项目 A）—静态总投资→（8.5 亿元）
    • （风电场 A）—装机容量→（100 MW）

  • 结构分解关系：

    • （总投资）—由…构成→（风电工程投资）、（送出工程投资）、（建设期利息）
    • （风电工程投资）—包含→（风机采购）、（升压站工程）…

  • 逻辑依赖关系：

    • （年发电量）—由…计算→（装机容量）、（利用小时数）
    • （财务内部收益率）—由…决定→（总投资）、（电价）、（年发电量）、（运营成本）

  • 跨章节引用关系：

    • （3.2 节：项目概况）—引用→（装机容量：100MW）
    • （8.1 节：财务评价）—引用→（装机容量：100MW）

在实现上，可以用 LLM 提取“主语-谓语-宾语”三元组，再根据领域模板进行筛选与规范化。 类似的三元组抽取已广泛用于构建金融和医疗知识图谱，用来支撑图查询和下游推理。

4. 图结构构建与增强

基于前面的实体和关系，构建一个项目级的知识图谱：

  • 每个实体是一个节点，挂上属性（数值、单位、章节位置、页码、来源版本等）；
  • 每个关系是一条边，标记关系类型（“引用”“由…计算”“分解为” 等）；

  • 可以进一步引入简单规则和推理：

    例如：

    • 若“年度发电量 ≈ 装机容量 × 利用小时数”
    • 若“静态总投资 ≈ 各分项投资之和＋建设期利息”。

图构建好之后，就可以利用图算法、规则引擎去做一致性检查、冲突检测等工作。 这类用知识图谱做一致性检测和冲突定位的思路，在网络安全策略、图数据库一致性研究里已经比较成熟。

知识图谱在可研报告评审中的三个实用场景

1. 数值与指标一致性

目标： 快速发现“前后数字打架”“章节间引用不一致”“分项与汇总不平衡”等问题。

基于知识图谱可以做几类检查：

  1. 跨章节引用一致性

    • 同一个实体（如“装机容量 100MW”）在不同章节多次出现时，通过图谱可以列出“所有引用点”，自动比对是否一致。
    • 一旦发现“某处是 100MW，另一个地方写成了 120MW”，可以标记为高优先级问题。

  2. 结构化汇总校验

    • 利用“总投资—分项投资”的分解关系，校验：

      总投资 ≈ 各分项投资之和 ± 舍入误差

    • 利用“年度发电量—利用小时—装机容量”的关系，校验：

      报告中给出的年发电量是否与这些基础参数匹配（至少在合理误差范围内）。

  3. 预测 vs 实际/不同方案对比

    若报告中同时给出“基准方案、优化方案、敏感性分析”，可以在图中区分不同情景，检查： 参数变化是否合乎逻辑（例如电价下降却 IRR 上升就很值得怀疑）。

    类似做法在财务报表知识图谱中已经用于支持复杂查询和跨报表校验。

从使用体验上看，甚至可以考虑给审查专家一个简单界面：

选择“静态总投资”节点 → 一键展开所有构成项、引用位置和版本；

系统自动用颜色标出“不平衡”“前后不一致”的地方，减少“来回翻 PDF + 手算”的时间。

文本与语义一致性

可研报告虽不以文学见长，但语义不一致也是常见问题，知识图谱可以帮忙做：

  1. 术语与命名统一

把“某 220kV 变电站”的各种说法（“XX 变”“220kV 变电站”“本期新建变电站”）通过实体对齐成同一个节点；

当不同说法被错误地连到不同节点时，就可以提示“可能存在命名不一致或重复实体”。

  1. 代词与指代链检查

    把“它”“该项目”“本工程”等代词与其所指实体连起来；

    当跨段、跨页指代链很长时，可以检测“指代不清/有歧义”的句子，提示人工重点查看。

  2. 语义矛盾检测（粗粒度）

    通过抽取“结论/判断”的三元组，例如：

    • （项目经济性）—评价→（良好）
    • （项目经济性）—评价→（一般）

    如果同一实体被不同结论关系连接，或者相关前提条件不一致，就可以作为“潜在逻辑冲突”提示出来。

在知识图谱研究里，如何度量和修复图中的不一致性已经形成了一套方法论，也可以迁移到“文本 → 图 → 一致性分析”的场景中。

3. 逻辑结构与论证链

可研报告本质上是一份“论证文”， 它要从资源条件、技术方案、投资估算和外部环境等方面，论证项目是“可行”的。

用知识图谱，可以把这种论证链条显式化，例如：

flowchart LR
  A[资源条件良好] --> B[预计利用小时数较高] --> C[年发电量大] --> D[收入高] --> E[IRR 达标]

flowchart LR
  F[接网条件成熟] --> G[送出工程投资合理] --> H[总投资控制在 ×× 水平] --> I[度电成本可接受]

在图上，你可以：

  • 顺着“IRR 达标”这个节点往前追：看看它依赖了哪些参数、结论是否站得住脚；
  • 对比不同方案/版本的论证链，识别“参数变了但结论没动”的可疑情况。

知识图谱结合规则和推理，在复杂领域（如金融分析、医疗决策）已经用来提升逻辑一致性和可解释性，同样思路可以迁移到可研评审上。

一个可落地的自动化评审流程雏形

可以把前面的内容收拢成一个可工程化的流程管线，后续实现时逐步替换具体技术栈：

  1. 文本解析模块

输入：Word / PDF / Markdown 等可研报告原文；

输出：结构化文本（章节、段落、句子），附带页码、标题等元信息。

  1. 信息抽取与图谱构建模块

LLM + 规则，抽取：实体、数值、关系；

写入图数据库（如 Neo4j、JanusGraph 等），构建项目级知识图谱。

  1. 规则与一致性检查模块

定义一小批高价值规则，例如：

- 投资结构平衡约束；
- 重复指标一致性约束；
- 关键技术参数在“概况—技术方案—经济分析”三处的一致性约束；

用图查询 + 简单推理跑规则，输出“可能存在问题的节点/边”。

  1. 问题报告与审查界面

把检测结果整理成“机器审查意见”：

- 类型（数值不一致 / 术语不统一 / 逻辑矛盾 / 引用缺失…）；
- 位置（章节、页码、原文片段）；
- 相关实体和关系在图上的局部截图/视图。

给专家一个“从问题跳回原文”的入口，始终让人做最后决策。

长期来看，还可以把这一套和 RAG/LLM 问答整合成图增强问答： 既能让模型“看懂”报告内容，又能利用图来约束和校验回答，减少胡说八道。

实用建议

如果要真做一个 Demo 或内部工具，可以按这个顺序来：

  1. 从一个子场景切入

例如：先只做“投资与财务指标的一致性检查”，不碰全报告。 这样实体和关系类型有限，方便快速迭代。

  1. 先定“领域 schema”，再写抽取 prompt

把你想要的节点和边先画成一个小型领域模型：

- 节点：项目、子工程、费用项、经济指标、参数；
- 边：分解、引用、计算依赖、情景归属。

然后围绕这个 schema 设计 LLM 的抽取格式，减少“乱七八糟的三元组”。

  1. 把规则做成“可配置资产”

不要把所有规则写死在代码里，最好用 YAML / JSON 等形式描述；

让业务侧（比如熟悉可研规范的工程师）可以在一定程度上编辑和扩展规则。

  1. 从“辅助审稿工具”而不是“自动裁决系统”做起

明确定位：给专家“打灯、划重点”，而不是替他签字；

所有审查结论都以“提示/疑似问题”的形式呈现，由人来确认。