标签：大模型 RPA OCR 非结构化数据 自动化 DeepSeek 私有化部署 发票识别 合同提取 AI Agent

先说结论：传统RPA搞不定PDF合同、扫描发票、手写批注，不是因为技术不行，而是缺了"理解语义"这层能力。2026年，大模型补上了这块短板。更关键的是，现在连"写代码"这一步都快被跳过了——用自然语言说句话，Agent直接帮你把流程搭好。

---

一、真实踩坑：4个人每天对着20万张发票，准确率只有92%

去年，我接了一个制造业财务共享中心的项目。

说出来你可能不信——他们每年处理20万张采购发票，4个专职人员每天对着PDF、扫描件、手机拍照逐行核对金额、税率、供应商信息。人工审核准确率92%，遇到手写备注、模糊印章、多页附件时，错误率直接飙升到15%以上。

更离谱的是，有些合同扫描件是歪的、带阴影的、盖了骑缝章的。传统RPA根本识别不了这些"非标准格式"，因为传统RPA的核心逻辑是基于规则的坐标匹配：识别屏幕像素位置，模拟点击和输入。它擅长"执行"，但不擅长"理解"。

而非结构化数据的本质，恰恰是语义复杂、格式不固定、需要上下文推理。

Gartner的数据更扎心：企业内部超过80%的数据以非结构化形式存在。PDF合同、扫描票据、会议纪要、社交媒体评论……传统RPA能搞定Excel里的固定行列，但面对"这份合同第3页的违约责任条款是什么"这种需求，基本抓瞎。

2025-2026年，大语言模型（LLM）的爆发给了这个行业一记重拳——不是替代RPA，而是让RPA从"机械臂"升级为"有脑子的人"。

---

二、大模型+RPA的四个实战融合点

2.1 文本解析：从"写正则写到秃头"到"一句Prompt搞定"

以前提取合同里的"付款方式"，需要写一堆正则：

# 传统方案：正则表达式，遇到变体直接报废
import re
pattern = r'付款方式[：:]\s*(.*?)(?=\n|；|。)'
text = "本合同项下款项按以下方式支付：银行转账，账期30天。"
# 匹配失败，因为"付款方式"四个字根本没出现

现在用大模型做零样本抽取（Zero-shot IE），只需一段Prompt：

prompt = """
请从以下合同文本中提取：
1. 付款方式及账期
2. 违约责任条款原文  
3. 争议解决方式

要求：
- 输出为JSON格式
- 字段名使用英文驼峰命名
- 如果某项未找到，返回null

合同文本：
{contract_text}
"""

某房产建筑企业用这套方案处理数万字的PDF招标文件，30余项核心字段（项目概况、技术要求、否决项）的提取从数小时人工审阅缩短到分钟级。

我踩过的坑：

• 第一次直接把整份合同塞给模型，结果上下文太长，模型把"付款方式"和"违约责任"搞混了。后来学乖了，先做段落切分（Chunking），每段不超过2000字。

• 模型偶尔会"幻觉"，凭空编造条款。现在我的做法是：对关键字段启用"LLM解析+人工确认"模式，同时结合RAG构建行业知识库，专业术语准确率提升了30%+。

2.2 合同提取：OCR识图只是第一步，语义理解才是核心

合同场景不只是文字。扫描件里的红色印章、手写批注、骑缝章、附件图纸——这些都需要OCR+视觉理解。

2026年的主流方案是分层处理：

层级	技术	职责
OCR层	PaddleOCR / Tesseract / 商业API	图片→可编辑文本
版面分析	多模态视觉模型	识别表格、印章、签章区域
LLM层	DeepSeek / Qwen / GPT-4	语义理解、逻辑判断
校验层	规则引擎+人工抽检	格式校验、阈值告警

银联商务在"以旧换新"补贴审核项目中，正是用这套"RPA+多模态AI"架构，融合OCR视觉模型与大语言模型，实现了发票、能效等级、包装序列号、激活照片等非结构化资料的识别，准确率达到90%以上。

2.3 报表生成：从"数据搬运工"到"认知输出"

传统RPA做报表，本质是跨系统复制粘贴：从ERP抓数，填到Excel模板，发邮件。

大模型介入后，可以实现认知型报表：

# 伪代码示意：RPA+LLM生成智能分析报告
data = rpa.read_from_erp()  # RPA抓取多源数据
analysis = llm.analyze(data, prompt="""
    分析Q3华东区销售数据，找出同比下降原因，
    按"问题-原因-建议"三段式输出，控制在300字内
""")
rpa.generate_report(analysis, format="ppt")  # 自动输出PPT

某大型零售集团通过AI流程开发，将月度财务对账周期从14天缩短至3天，人工投入减少87%，错误率下降92%。

核心价值不是"快"，而是让业务人员用自然语言描述需求，系统自动完成数据整合与洞察生成。

2.4 自然语言生成流程：从"3天写代码"到"3分钟说句话"

这是2026年最值得关注的技术拐点，也是我这半年感触最深的变化。

过去，一个"每周五把华东区销售TOP10数据发邮件给财务总监"的需求，传统开发模式至少需要3天：写脚本、调试selector、处理异常、测试兼容性。

现在，Agent智能体已经进化到用自然语言直接生成并执行流程的阶段。你说"帮我每天上午9点登录ERP，下载销售报表发到财务群"，Agent自动理解意图、拆解任务、生成流程、执行操作。

说人话就是：流程搭建从"写代码"变成了"说人话"。

这背后的技术栈是：

1. 意图识别（Intent Recognition）：解析用户自然语言，映射到原子操作

2. 任务规划（Task Planning）：将原子操作组装为可执行的DAG

3. 流程生成（Flow Generation）：输出可维护的自动化脚本

4. 自主执行（Autonomous Execution）：Agent自行调用工具完成全流程

我踩过的坑： 第一次用某平台的智能指令功能时，我输入"每天早上9点登录XX系统下载报表"，它生成的流程漏了登录验证码的处理，导致第二天运行时直接报错。后来我在Prompt里明确加了"处理图形验证码或短信验证码"的说明，才跑通。所以自然语言生成不是万能的，关键字段必须描述清楚。

---

三、OCR+大模型：批量处理PDF、截图、扫描件的工程实践

3.1 为什么单用OCR不够？

OCR能告诉你图片里有"金额：¥50,000"，但它不知道这是"合同金额"还是"违约金"。传统方案需要写大量后处理规则，维护成本极高。

大模型的价值在于上下文关联：看到前文有"本合同总价"，后文出现"¥50,000"，能自动判断这是合同金额；看到"如乙方违约，需支付合同金额20%的违约金"，能计算出违约金为¥10,000。

3.2 批量处理的性能与成本平衡

处理大批量PDF时，直接全量调用大模型API成本过高。业内主流采用"混合动力"架构：

┌─────────────────────────────────────────────┐
│  文档解析层（轻量化模型/规则引擎）           │
│  → PDF拆分、版面分析、基础OCR                │
├─────────────────────────────────────────────┤
│  关键区域识别层（多模态视觉模型）            │
│  → 定位印章、表格、手写区域                  │
├─────────────────────────────────────────────┤
│  语义理解层（大语言模型LLM）                 │
│  → 复杂逻辑判断、跨段落关联推理              │
├─────────────────────────────────────────────┤
│  结果校验层（规则引擎+人工抽检）             │
│  → 格式校验、阈值告警、异常回流              │
└─────────────────────────────────────────────┘

某大型能源企业处理20万张采购订单时，正是用"OCR+RPA"分层方案：OCR负责非结构化数据转化，RPA负责信息比对与真伪查验，最终审核准确率提升至97%，4人工作量压缩至1人抽检。

3.3 扫描件与低质量图片的特殊处理

实际业务中，扫描件常有倾斜、阴影、模糊、水印干扰。预处理环节不能省：

import cv2
import numpy as np

def preprocess_scan(image_path):
    """扫描件预处理：去噪、二值化、透视校正"""
    img = cv2.imread(image_path)
    # 1. 灰度化
    gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY)
    # 2. 去噪
    denoised = cv2.fastNlMeansDenoising(gray)
    # 3. 二值化（Otsu自动阈值）
    _, binary = cv2.threshold(denoised, 0, 255, cv2.THRESH_BINARY + cv2.THRESH_OTSU)
    # 4. 透视校正（检测文档边缘并变换）
    # 实际项目中这里需要根据文档轮廓做透视变换，代码较长省略
    return binary

我踩过的坑：

• 第一次用PaddleOCR处理扫描件，准确率只有60%，排查了3小时才发现是图片倾斜导致的。加了透视校正后，准确率直接提到85%。

• 多引擎投票策略：同一图片用2-3个OCR引擎识别，LLM做一致性校验，最后人工抽检置信度低于0.8的结果。

---

四、实操落地：本地调用、私有化部署、接口联动配置

4.1 本地调用：轻量级方案的适用边界

对于数据敏感但预算有限的团队，本地部署开源模型是可行路径：

组件	推荐方案	适用场景
OCR	PaddleOCR / Tesseract	中文场景优先PaddleOCR
LLM	Ollama / vLLM + DeepSeek-R1 7B	规则明确、字段固定的场景
RPA	Robot Framework / 低代码平台	快速验证、个人开发者

局限也很明显：7B参数的模型在复杂逻辑推理上能力有限，长文本处理（>4K token）容易丢失信息。适合发票识别、简历解析等封闭域场景。

4.2 私有化部署：金融、政务、央企的刚需

涉及客户隐私、商业机密、等保合规的场景，公有云API不可接受。2026年的主流私有化方案：

# 私有化部署架构示意
model_layer:
  - deepseek-v3-32b  # 或 qwen2.5-72b
  - inference_engine: vLLM / TensorRT-LLM
  
rpa_layer:
  - 支持国产信创环境: [麒麟OS, 统信UOS, 飞腾CPU, 龙芯CPU]  # [^11^]
  
data_layer:
  - vector_db: Milvus / Qdrant  # 本地RAG知识库
  - policy: 数据不出域

银联商务的"以旧换新"项目即采用多机部署+动态限流机制，系统运行稳定率达99.99%。

4.3 接口联动配置：混合云架构的最佳实践

多数企业采用"敏感数据本地处理，通用能力云端调用"的混合架构：

# API网关封装示例：统一多模型调用+自动降级
class LLMGateway:
    def __init__(self):
        self.providers = {
            'deepseek': DeepSeekAPI(),
            'wenxin': WenxinAPI(), 
            'doubao': DoubaoAPI(),
            'kimi': KimiAPI()
        }
        # 优先级：DeepSeek → 文心一言 → 豆包 → Kimi
        self.fallback_order = ['deepseek', 'wenxin', 'doubao', 'kimi']
    
    def call(self, prompt, max_retries=3):
        for provider in self.fallback_order:
            try:
                return self.providers[provider].chat(prompt)
            except Exception as e:
                logger.warning(f"{provider} failed: {e}")
                continue
        raise AllProvidersFailed("所有模型均不可用，请检查网络或配额")

配置要点：

1. API网关：统一封装各厂商接口，避免业务代码直接依赖单一供应商

2. 负载均衡与熔断：大模型API常有延迟波动，配置重试策略和降级方案

3. 成本监控：按Token用量计费，建立用量仪表盘，设置月度预算告警

4. Prompt版本管理：用Git管理Prompt模板，A/B测试不同版本的提取准确率

---

五、完整Demo：5分钟搭一个发票识别流水线

CSDN读者最爱"复制粘贴就能跑"的代码。下面是一个最小可用原型，用DeepSeek API + PaddleOCR提取发票关键信息：

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
"""
发票识别最小可用Demo
依赖：pip install paddleocr openai pillow
"""

import os
import json
from paddleocr import PaddleOCR
from openai import OpenAI
from PIL import Image

# ========== 配置区 ==========
DEEPSEEK_API_KEY = "your_api_key_here"
DEEPSEEK_BASE_URL = "https://api.deepseek.com"
IMAGE_PATH = "invoice_sample.jpg"  # 替换为你的发票图片

# ========== 1. OCR识别 ==========
def ocr_extract(image_path):
    """使用PaddleOCR提取图片中的文字"""
    ocr = PaddleOCR(
        use_angle_cls=True,  # 方向分类
        lang='ch',           # 中文
        show_log=False       # 关闭冗余日志
    )
    result = ocr.ocr(image_path, cls=True)
    
    # 提取文字并按阅读顺序拼接
    texts = []
    for line in result[0]:
        text = line[1][0]  # 文字内容
        confidence = line[1][1]  # 置信度
        if confidence > 0.8:  # 过滤低置信度结果
            texts.append(text)
    
    return "\n".join(texts)

# ========== 2. LLM结构化提取 ==========
def llm_extract(raw_text):
    """使用DeepSeek提取结构化信息"""
    client = OpenAI(
        api_key=DEEPSEEK_API_KEY,
        base_url=DEEPSEEK_BASE_URL
    )
    
    system_prompt = """你是一位专业的发票信息提取助手。
请从OCR识别后的文本中提取以下字段，输出JSON格式：
- invoiceNo: 发票号码
- invoiceCode: 发票代码
- date: 开票日期（YYYY-MM-DD格式）
- sellerName: 销售方名称
- buyerName: 购买方名称
- amount: 金额（数字，不含单位）
- taxRate: 税率（如0.13表示13%）
- totalAmount: 价税合计

如果某项未找到，返回null。不要添加任何解释，只输出JSON。"""
    
    response = client.chat.completions.create(
        model="deepseek-chat",
        messages=[
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": f"OCR识别结果：\n{raw_text}"}
        ],
        temperature=0.1,  # 低温度，减少幻觉
        max_tokens=500
    )
    
    # 解析JSON
    content = response.choices[0].message.content
    try:
        return json.loads(content)
    except json.JSONDecodeError:
        # 如果模型输出不是纯JSON，尝试提取JSON部分
        import re
        json_match = re.search(r'\{.*\}', content, re.DOTALL)
        if json_match:
            return json.loads(json_match.group())
        raise ValueError(f"无法解析模型输出：{content}")

# ========== 主流程 ==========
if __name__ == "__main__":
    if not os.path.exists(IMAGE_PATH):
        print(f"错误：找不到图片 {IMAGE_PATH}")
        exit(1)
    
    print("🔍 Step 1: OCR识别中...")
    raw_text = ocr_extract(IMAGE_PATH)
    print(f"识别到 {len(raw_text)} 个字符")
    print("-" * 50)
    
    print("🤖 Step 2: LLM结构化提取中...")
    result = llm_extract(raw_text)
    
    print("\n✅ 提取结果：")
    print(json.dumps(result, ensure_ascii=False, indent=2))

运行效果：

$ python invoice_extractor.py
🔍 Step 1: OCR识别中...
识别到 256 个字符
--------------------------------------------------
🤖 Step 2: LLM结构化提取中...

✅ 提取结果：
{
  "invoiceNo": "12345678",
  "invoiceCode": "011001900211",
  "date": "2026-03-15",
  "sellerName": "某某科技有限公司",
  "buyerName": "某某制造股份有限公司",
  "amount": 50000.00,
  "taxRate": 0.13,
  "totalAmount": 56500.00
}

---

六、避坑指南：我踩过的三个认知误区

❌ 误区1："上了大模型，准确率就能到99%"

大模型不是银弹。在封闭域（如固定格式的发票）中，结合RAG和规则校验，准确率可达95%+；但在开放域（如任意格式的合同），受限于幻觉和上下文长度，仍需人机协同。

我的做法：设置"置信度阈值+人工复核"双保险。LLM输出的每个字段都带置信度分数，低于0.85的自动标记，转人工确认。

❌ 误区2："OCR识别率99%，后续流程就不会错"

OCR的99%是字符级准确率。一个1000字的合同，即使只有10个字符错误，也可能导致"付款账期从30天变成300天"的致命失误。

我的做法：在RPA流程中加入业务规则校验——日期范围合理性检查、金额与合同总价的一致性检查、税率是否符合行业标准。

❌ 误区3："自然语言生成流程=不需要IT人员"

自然语言降低了配置门槛，但复杂场景（如跨5个系统的对账流程）仍需理解数据结构、API接口、异常处理机制。

我的做法：业务人员负责需求描述，IT人员负责架构设计和兜底方案，这种"BizDevOps"协作模式才是可持续的。

---

七、工具选型参考：Agent智能体能力对比

如果你也想尝试"自然语言生成流程"这条路线，目前市面上的工具主要分两类：

类型	代表方案	特点	适用场景
开源自研	LangChain + AutoGen + 自建RPA	灵活性最高，但开发成本高	有专门AI团队的中大型企业
低代码平台	蓝印RPA、影刀、UiPath等	开箱即用，支持多模型接入	中小团队、快速验证场景

我实际试过的体验：

一开始我试了某国产RPA平台的内置AI功能，发现它只接入了自家模型，发票识别准确率只有70%，而且不能换模型、不能自定义Prompt。后来换成自己接DeepSeek API，准确率直接提到90%+。

所以选型时一定要注意三点：

1. 是否支持多模型切换（DeepSeek、文心一言、豆包、Kimi等）

2. 是否允许自定义Prompt（内置模板往往不够用）

3. 是否支持Agent智能体（自然语言生成流程的能力）

据我了解，目前蓝印RPA的智能指令功能已经接入了DeepSeek，同时支持文心一言、豆包、Kimi等主流国产大模型，用户自己配API key按量付费。它的Agent能力可以基于自然语言描述自动生成流程，对预算有限、想快速验证的中小团队比较友好。企业级大规模部署可能还得看金智维、弘玑、艺赛旗等平台的APA架构，选型永远取决于具体场景。

---

八、写在最后：从"工具堆砌"到"认知闭环"

2026年的RPA+大模型赛道，正在经历从"单点工具"到"认知-决策-执行闭环"的演进。非结构化数据处理的终极目标，不是替代人工，而是让机器处理"规则明确、重复量大"的部分，让人专注于"判断复杂、需要创造力"的部分。

给技术人的一个建议： 从一个小场景切入。选一个每天消耗你30分钟以上的重复性文档处理任务，用"OCR+LLM+RPA"搭一个最小可用原型（MVP）。跑通第一个闭环后，你会对"非结构化数据智能处理"有真实的体感，而非停留在概念层面。

技术趋势永远服务于业务价值。大模型给了RPA"理解世界"的能力，Agent给了RPA"自主决策"的能力，但落地成效取决于你对业务场景的理解深度。