合同识别

这项能力到底在做什么

合同识别，简单说，就是把合同正文、附件、扫描件里的关键信息快速抽出来，方便后面的检索、核对、归档和审阅。

很多企业并不缺合同文件，真正缺的是“合同里重要内容找起来太慢”。
常见情况通常是这样：

想知道甲乙方是谁
想确认签订时间和金额
想查某条付款约定
想从一堆历史合同里筛出符合条件的合同

合同识别真正解决的，不是理解全部法律含义，而是先把合同里最关键、最常用的信息稳定拉出来。

它通常接收什么输入

这项能力接进来的，通常是一份合同原件或扫描件。

常见输入包括：

PDF 合同
扫描版合同
合同图片
附件页
补充协议

一起带进来的上下文，常见还有这些：

合同类型
识别字段清单
文档来源
是否含附件
页码范围
版本信息

这些上下文很关键。因为合同识别不是只把字认出来，而是要知道：

重点要抽哪些字段
主合同和附件怎么区分
哪些页最可能有关键条款

它能输出什么结果

合同识别最后交出去的，不应该只是全文文本，而应该是一份可继续用于业务流程的关键信息结果。

常见输出包括：

输出项	说明
合同主体信息	甲方、乙方、签署主体
基础字段	合同编号、金额、日期、期限等
关键条款定位	付款、验收、保密、违约等位置
文档结构结果	主合同、附件、补充协议的划分
识别置信度	哪些字段较稳、哪些不稳
来源页码	方便人工回看

这样下游拿到的，就不是一整份长合同，而是一份更可搜索、更可核对的结构化结果。

它在内部是怎么跑起来的

合同识别真正难的地方，不是认字，而是从合同这种长文档里把关键内容拉出来。
它在内部通常会经过下面这条链。

1. 先读取合同文件

系统先拿到合同正文和附件内容。

2. 再做文字抽取和版面拆分

扫描件、图片件、分页件会先被转成可读文本和结构块。

3. 再识别基础字段

比如：

合同名称
合同编号
合同双方
金额
生效时间

4. 再定位关键条款

付款、交付、验收、保密、违约等内容会尽量被定位出来。

5. 再标记不确定内容

识别不稳的字段会被单独提示，方便人工快速复查。

6. 最后输出结构化结果

这样后面的检索、审阅、归档流程都能更快接上。

详细内部流程图

flowchart TB
    A[输入合同 PDF、扫描件或图片] --> B[抽取文字并拆分页面结构]
    B --> C[识别合同主体、编号、金额和日期]
    C --> D[定位付款、验收、保密和违约等关键条款]
    D --> E[标记低置信度字段和来源页码]
    E --> F[输出结构化合同识别结果]
    F --> G[交给归档、审阅、投标和合规流程]

它最后会把什么交给下游流程

合同识别真正交给下游的，不只是文本，而是一份方便检索和核对的合同结构结果。

常见会交出去这些内容：

主体信息
编号和日期
金额与期限
关键条款位置
识别置信度
来源页码

这样后面的流程才能继续做：

招投标资料筛选
合规初审
合同归档
条款复核

它怎么接入业务才真正有价值

合同识别最怕的，不是识别不到，而是识别出来以后还是要人工重翻一遍整份文件。

真正常见、也最有价值的接法，一般有下面几种：

1. 接在历史合同库整理前面

先把关键信息抽出来，后面检索会快很多。

2. 接在投标和资质准备前面

要找符合条件的历史合同，这项能力非常实用。

3. 接在合规初审前面

关键条款先被定位出来，人工复核会更高效。

4. 接在归档流程前面

归档不是只存文件，更要存可搜索字段。

什么情况下必须转人工

合同识别虽然很适合自动化，但下面这些情况最好让人工确认：

扫描质量很差
合同排版复杂
条款表达高度非标
识别结果会直接用于重要决策
多份补充协议关系复杂
关键字段置信度偏低

真正稳的企业做法，不是把识别结果直接当终稿，而是让系统先把关键位置拉出来，让人快速复核。

为什么这项能力站得住

合同识别之所以在企业里很有价值，是因为合同文件本来就长，关键内容又分散。
谁能更快把合同里的关键信息抽出来，谁就更容易减少查找和复核时间。

1. 它先解决的是“合同能看懂，但找得慢”

这在合同量一大时特别明显。

2. 它能明显提升后续检索效率

字段一旦抽出来，查合同就会轻很多。

3. 它特别适合历史文件多的团队

文件越多，这项能力越有价值。

4. 它边界清楚，适合人工做最终判断

系统先抽字段，人再看法律含义。
这种分工很稳。