1. 项目概述当LLM遇上15000张发票的“硬仗”最近刚结束一个项目核心任务是用大语言模型LLM从一万五千多张格式各异的发票里自动提取关键字段。听起来挺酷对吧用AI解放人力自动化处理海量文档。但真干起来才发现这活儿远不是调个API、写个提示词那么简单。我们团队包括我自己在项目初期几乎是“踩坑踩到怀疑人生”。发票这东西看似有固定格式实则千变万化有标准增值税发票也有各种购物小票、手写收据有的扫描件清晰如印刷有的则模糊、倾斜、有污渍更别提不同公司、不同业务场景下的字段要求差异了。我们最初的想法很直接选一个性能不错的LLM设计一套“完美”的提示词把发票图片或PDF扔进去坐等结构化的JSON数据出来。结果呢准确率惨不忍睹错误五花八门。日期被识别成金额销售方名称里混进了地址信息最头疼的是面对模糊或非常规格式的发票模型要么“胡言乱语”瞎编要么直接“摆烂”说无法识别。这一万五千张发票就像一万五千个风格迥异的“考官”把我们天真的单层LLM调用方案考得体无完肤。也正是这些失败逼着我们不得不停下来思考LLM在数据提取Information Extraction, IE任务中到底有哪些固有的“坑”如何为它构建一套可靠的“防御工事”让它从一名才华横溢但容易“放飞自我”的艺术家变成一名严谨、可靠的流水线工人经过反复的试错、迭代和优化我们最终构建了一个包含六层防御机制的流水线系统将整体字段提取的准确率从最初的不到70%提升到了稳定在98%以上。这篇文章就是这场“硬仗”的完整复盘。我会详细拆解我们遇到的六个核心问题以及对应的六层防御策略是如何设计和落地的。无论你是正在考虑将LLM应用于文档处理的产品经理、算法工程师还是负责具体实施的开发者希望这些“踩坑”换来的经验能帮你少走一些弯路。2. 核心思路从“单点魔法”到“系统工程”的转变项目伊始我们犯了一个很典型的“技术乐观主义”错误过度聚焦于LLM模型本身的能力而忽视了任务本身的复杂性和对可靠性的极高要求。数据提取尤其是商业票据的数据提取是一个要求精确性、一致性和可解释性的任务。LLM的强项在于理解和生成但其输出具有概率性和不可控性。直接让它“自由发挥”无异于在关键生产环节引入了一个不受控的随机变量。我们的思路转变是从放弃“寻找一个万能提示词搞定一切”的幻想开始的。我们意识到必须将LLM嵌入到一个更大的、受控的系统中。这个系统的设计核心是分解、校验、兜底。具体来说任务分解不要求LLM一次性从一张发票中提取所有信息。而是将任务拆解为更小、更专注的子任务比如先识别发票类型再分别提取买方、卖方、金额、日期等。这降低了单次任务的复杂度也便于后续的针对性校验。多阶段校验在LLM输出后绝不直接采信。必须引入基于规则、基于外部知识库、甚至基于不同LLM交叉验证的校验层对输出进行清洗、修正和确认。分层兜底当某一层防御机制检测到异常或置信度不足时不是直接报错而是启动更复杂或更保守的备用方案如下一级LLM分析、人工复核队列确保流程最终能产生一个确定的结果无论是正确数据还是标记为需人工处理。这六层防御就是基于这个“系统工程”思想层层构建的。它们环环相扣前一层为后一层减轻压力后一层为前一层的结果提供保障。接下来我们就进入实战环节一层层拆解这些“坑”和我们的“防御工事”。3. 第一层防御输入预处理与图像增强——给LLM一双“好眼睛”核心问题垃圾进垃圾出Garbage In, Garbage Out我们接到的原始数据有扫描的PDF有手机拍摄的JPG甚至还有从邮件里转存出来的低分辨率截图。直接把这些图像扔给多模态LLM如GPT-4V、Claude-3效果极不稳定。模糊、倾斜、光照不均、背景杂乱的图片会严重干扰模型对文字和版式的识别导致提取错误。这是最底层也是最容易被忽视的一个坑。防御策略标准化输入管道我们的第一层防御是一个自动化的图像预处理流水线。目标是把千奇百怪的输入尽可能转换成干净、清晰的标准化图像。这个环节不直接使用LLM而是使用更专一、更稳定的传统计算机视觉CV和图像处理库。实操要点与工具选型格式统一与文本化所有PDF文件优先使用pdf2image配合poppler或PyMuPDF转换为高分辨率至少300 DPI的图像。这一步是关键避免了PDF内嵌字体或复杂版式导致的直接解析问题。图像增强去噪与锐化对于模糊图像使用OpenCV的cv2.fastNlMeansDenoising或cv2.GaussianBlur配合锐化滤波器提升文字边缘清晰度。二值化采用自适应阈值法如cv2.adaptiveThreshold而不是全局阈值以应对光照不均。对于彩色发票我们会先尝试提取红色印章等关键颜色区域再对整体进行灰度化和二值化。纠偏Deskew使用霍夫变换检测图像中的直线计算倾斜角度并进行旋转校正。一张摆正了的发票对后续的版式分析和字段定位有巨大帮助。关键区域裁剪可选但推荐如果发票类型相对固定可以先用模板匹配或特征检测的方法定位发票主体区域裁剪掉无关的背景如扫描仪的边框、桌面的杂物。这能减少干扰信息让LLM更专注于有效内容。注意图像增强是一把双刃剑。过度处理如过度锐化可能会引入新的噪声或造成文字断裂。我们建立了一个小样本的测试集针对不同类型的劣质图片调试出了一组相对保守的增强参数原则是“宁可增强不足不可增强过度”因为后续的LLM对清晰的原始图像也有一定的容忍度。实操心得我们曾尝试跳过预处理直接让GPT-4V处理原始扫描件。结果发现对于质量稍差的图片其提取结果波动很大。而经过预处理后同一份文件多次调用的结果一致性显著提升。这层防御的成本很低主要是计算资源但收益很高它为后续所有环节提供了一个质量可控的输入基础。可以说这是整个系统稳定性的“地基”。4. 第二层防御结构化提示工程与输出约束——给LLM一套“标准作业程序”核心问题LLM的“自由发挥”与格式灾难即使有了清晰的图片如果只是简单地问“请从这张发票中提取信息”LLM返回的结果也是天马行空。可能是纯文本描述可能是一段JSON但字段名不统一可能混入大量解释性文字甚至可能因为图片某个角落的无关信息而“脑补”出错误内容。我们需要的是严格遵循预定 schema 的结构化数据。防御策略精确的提示词与强格式约束这一层的核心是通过精心设计的提示词Prompt限制LLM的思考范围并强制其以特定格式输出。这不仅仅是技术更是与模型“沟通”的艺术。实操要点与方案设计角色定义与任务明确在提示词开头就给LLM定义一个明确的角色例如“你是一个专业的财务票据处理专家擅长从各类发票中精确提取结构化信息。”提供结构化输出示例Few-Shot Learning这是提升准确率最有效的手段之一。在提示词中我们不仅描述格式更直接给出1-2个正确范例。// 这是提示词的一部分提供给LLM的示例 你需要提取以下字段并以严格的JSON格式输出键名必须如下所示 { invoice_type: 增值税专用发票, invoice_code: 发票代码如144031800111, invoice_number: 发票号码如12345678, issue_date: 开票日期格式YYYY-MM-DD, seller_name: 销售方名称全称, seller_tax_id: 销售方纳税人识别号, buyer_name: 购买方名称全称, buyer_tax_id: 购买方纳税人识别号, amount_before_tax: 不含税金额数字, tax_amount: 税额数字, total_amount: 价税合计大写, total_amount_num: 价税合计小写数字 } 示例1 输入发票[发票图片A] 输出 { invoice_type: 增值税普通发票, invoice_code: 144031800111, invoice_number: 87654321, ... // 其他字段 }指令清晰化明确边界“只提取发票图片中明确显示的信息不要推断或猜测。”处理缺失“如果某个字段在图片中无法找到或清晰识别该字段的值设为空字符串。”格式强制“你的输出必须是且仅是一个合法的JSON对象不要包含任何其他解释、前缀或后缀。”利用系统提示System Prompt对于支持系统提示的API如OpenAI将最核心的、不变的指令放在系统提示中将具体的任务和示例放在用户提示中。这有助于模型更好地维持指令的上下文。实操心得我们对比了只给格式要求、只给示例、以及两者结合的效果。发现“格式要求少量示例”的组合拳效果最好。示例相当于给了模型一个“模板”极大地减少了输出格式的随机性。此外我们为不同类型的发票增值税专票、普票、火车票、出租车票设计了略微不同的提示词模板和输出schema在调用前会用一个简单的分类器可以是基于规则也可以是小模型先判断发票类型再选择对应的提示词这比用一个通用提示词去处理所有类型效果要好得多。这一层防御是将LLM的“创造力”引导至我们需要的“生产力”的关键一步。5. 第三层防御基于规则的输出清洗与校验——设置“逻辑安检门”核心问题LLM的“低级错误”与常识性违背即使有了好的提示词LLM的输出依然可能包含明显错误。例如将日期识别为“2023年13月45日”纳税人识别号位数不对或者金额的小写数字与大写文字对不上。这些错误往往违背了简单的业务规则或常识。防御策略规则引擎后处理在LLM输出JSON后我们立即将其送入一个规则校验层。这层不依赖AI只依赖明确的、可编码的业务规则。它的作用是过滤掉那些“一眼假”的结果并进行初步修正。实操要点与规则设计格式校验日期正则表达式校验是否符合YYYY-MM-DD或YYYY年MM月DD日格式并检查月份是否在1-12之间日期是否合理如2月不超过29天需结合闰年判断这里我们做了简化。纳税人识别号校验长度15、17、18或20位和字符组成数字或数字字母。发票代码/号码校验是否为纯数字且长度固定如12位代码8位号码。逻辑校验金额一致性如果提取到了“不含税金额”、“税额”和“价税合计小写”则校验abs((amount_before_tax tax_amount) - total_amount_num) 0.01考虑浮点数误差。如果不一致则记录冲突。大小写金额核对将提取的“价税合计大写”通过规则字典转换为数字与“价税合计小写”进行比对。这是一个非常有效的纠错手段。取值范围校验对于某些字段如税率检查是否在合理的列表内如0.03, 0.06, 0.09, 0.13等。我们设计了一个规则引擎每条规则对应一个校验函数和一个严重等级Error/Warning。所有违反Error级规则的结果会被直接标记为“高置信度失败”流入后续的第四层防御人工复核或重试。违反Warning级的则记录日志供后续分析优化模型。实操心得这一层防御的实现成本低但效果立竿见影。它帮我们拦截了大约15%的明显错误输出。更重要的是它让我们对LLM输出的质量有了一个可量化的、基于规则的初步判断。我们把这些规则写成可配置的YAML文件方便非技术同事如财务人员根据实际业务需求增删改查。例如他们可以轻松地添加一条新规则“销售方名称中如果包含‘医院’二字则‘货物或应税劳务名称’字段必须与医疗相关”。这种灵活性是纯LLM方案难以提供的。6. 第四层防御外部知识库与上下文校验——引入“领域专家顾问”核心问题LLM缺乏私有、实时、精确的领域知识发票上的很多信息需要结合外部知识才能判断其正确性。例如销售方名称LLM可能提取了一个简称或略有错误的名称。我们需要知道它是否与我们合作供应商名录中的某个官方全称匹配。商品信息提取的货物名称是否在我们的产品编码库中有对应单价是否在历史合同价的可接受波动范围内逻辑关联这张出差地的出租车票日期是否在员工的出差申请时间段内防御策略知识库查询与关联验证这一层防御我们将LLM提取的初步结果与我们的内部数据库、业务系统进行关联校验。这相当于为LLM配备了一个实时更新的“领域知识大脑”。实操要点与系统集成构建知识库供应商库包含供应商官方全称、简称、纳税人识别号、历史合作记录。商品/服务库包含标准产品名称、编码、分类、历史价格。员工/项目库包含员工信息、项目编号、预算科目、出差记录等。设计校验流程模糊匹配对于“销售方名称”使用模糊字符串匹配算法如fuzzywuzzy或rapidfuzz在供应商库中查找最相似的条目。如果匹配度超过阈值如95%则用知识库中的官方名称覆盖LLM的提取结果。同时用知识库中的税号与提取的税号进行交叉验证。编码映射对于“货物名称”尝试在商品库中映射到标准编码和分类。映射成功则补充这些字段映射失败则标记为“未知商品”需要人工确认。业务规则校验将发票日期、金额、类型等信息与发起报销的员工、所属项目、预算余额等进行关联校验。这部分需要与公司的ERP或财务系统进行API对接。实操心得这一层是提升数据可用性而不仅仅是准确性的关键。LLM可能提取了一个“正确”的名称“北京XX科技公司”但我们的知识库知道其官方全称是“北京XX科技有限公司”并且其纳税人识别号应该是“91110108MAABCDEFG”。通过知识库校验我们不仅修正了错误还将一张发票的孤立数据链接到了整个公司的业务上下文中为后续的自动审核、记账打下了基础。实施这一层时最大的挑战在于知识库的维护和更新频率。我们建立了与采购部门、财务部门的定期同步机制确保知识库的时效性。7. 第五层防御多模型投票与置信度评估——组建“评审委员会”核心问题单一模型的局限与不确定性依赖单一LLM提供商或单一模型存在风险模型本身可能存在的系统性偏差、API服务的临时波动、以及对某些特定类型发票如极其模糊的手写体、特殊行业票据识别能力不足。我们需要一种机制来评估每次提取结果的置信度并对低置信度结果进行仲裁。防御策略集成学习与共识机制我们不再只调用一个LLM而是组建一个“模型委员会”。对于同一张预处理后的发票我们并行调用多个LLM例如GPT-4V, Claude-3 Opus 以及一个开源的、针对中文票据微调过的多模态模型让它们根据相同的提示词独立进行提取。实操要点与仲裁策略模型选型选择2-3个主流、性能领先的多模态LLM作为委员会成员。考虑到成本可以采用“一主多辅”策略即一个高成本高精度模型主审配合一两个低成本或开源模型辅审。结果对齐由于不同模型的输出格式可能微调需要先将所有输出解析并映射到统一的schema上。共识判断完全一致如果所有模型对某个字段的提取结果完全相同则该字段置信度为“高”直接采纳。多数一致如果多数模型如2/3结果一致则采纳多数派结果置信度为“中”。记录少数派的不同意见供分析。完全不一致如果所有模型结果都不同则置信度为“低”。这张发票将自动进入“高难度案例”处理队列。置信度量化除了基于投票的定性置信度我们还可以设计简单的定量指标。例如对于金额、日期等字段可以计算不同模型输出之间的方差。方差越小置信度越高。实操心得多模型投票极大地提升了系统的鲁棒性。我们发现不同模型在不同类型的发票上各有优劣。GPT-4V可能对印刷体表格识别更准而Claude-3对不规则版式的理解更强。通过投票我们实际上获得了“集成优势”。虽然成本增加了约2-3倍但对于那些高价值、高风险的票据如大额合同发票这笔开销是值得的。同时所有“低置信度”的案例都成为了我们优化系统、补充训练数据的宝贵素材。我们建立了一个标注平台专门用于处理这些疑难杂症并将人工复核后的正确结果反馈回去用于优化我们的提示词和后续流程。8. 第六层防御人工复核闭环与持续迭代——保留“最终裁决权”核心问题自动化无法覆盖所有边缘情况无论前面的五层防御多么完善总会存在一些“刺头”案例是当前自动化系统无法完美处理的。例如严重损毁无法识别的票据、极其潦草的手写体、从未见过的新型票据模板、或者经过前面几层防御后置信度依然很低的结果。我们必须承认100%全自动化的不现实性并为这些边缘情况设计优雅的降级处理方案。防御策略人机协同与主动学习这是最后一道也是最关键的一道防线。它不是简单的“遇到错误就抛给人”而是一个设计好的、高效的人机协同流程。实操要点与流程设计建立复核队列系统自动将以下票据送入人工复核队列经过规则引擎校验为“Error”且无法自动修正的。多模型投票后置信度为“低”的。与外部知识库匹配失败或产生冲突的。随机抽样的一部分高置信度结果用于质量监控。设计高效复核界面复核界面不是简单地展示图片和LLM的原始输出。而是将预处理后的图片、LLM的提取结果可能来自多个模型、规则校验的告警、知识库匹配的建议并排展示。复核人员可以一目了然地看到矛盾点并在一个结构化的表单中进行快速修正。修正时可以直接选择知识库中的条目或输入正确值。闭环反馈与迭代所有人工复核的结果都会被系统记录并结构化存储。这些数据有两大用途即时自愈对于因知识库缺失导致的错误复核人员补充信息后系统可以立即更新知识库后续遇到相同供应商或商品时即可自动通过。长期迭代定期如每周将人工复核纠正的案例特别是那些多模型都出错的“硬骨头”整理成新的提示词优化样本、规则引擎补充规则或者用于微调我们自有的OCR或信息提取模型。这使得整个系统具备了“主动学习”的能力越用越聪明。实操心得这一层防御在心理上和技术上都至关重要。从心理上它让业务方财务部门感到安心他们拥有最终控制权。从技术上它确保了系统输出的最终质量是100%可靠的因为经过了人工确认同时这个人机接口又成为了系统持续进化的“养料”。我们设计的目标是随着系统运行需要人工复核的比例不断下降。在项目后期这个比例从初期的超过30%降到了5%以下而且复核人员的平均处理时间也因为系统提供了丰富的辅助信息而大幅缩短。9. 常见问题与排查技巧实录在实际部署和运行这套六层防御系统的过程中我们遇到了各种各样的问题。下面是一些典型的“坑”和我们的解决思路希望能帮你提前避雷。问题1预处理后图像质量反而变差导致LLM识别率下降。排查检查预处理流水线每个环节的输出图像。常见原因是二值化阈值设置不当导致文字断裂或背景噪声被保留或者纠偏算法误判了倾斜角度。技巧不要对所有图片使用同一套参数。可以设计一个简单的分类器根据图像的亮度、对比度、色彩通道方差等特征将图片分为“清晰”、“模糊”、“低对比度”、“有底色”等类别然后应用不同的预处理参数组合。我们写了一个小脚本用OpenCV计算一些图像统计指标来动态选择预处理策略。问题2LLM的API调用不稳定时而超时时而返回非JSON内容。排查首先确认是否是网络问题或服务商问题。然后检查提示词是否足够强硬地要求返回JSON。有时模型会在JSON外加一层Markdown代码块标记。技巧重试与退避实现带指数退避的自动重试机制。第一次失败后等待1秒重试第二次失败后等待2秒以此类推。输出清洗在解析JSON前先用正则表达式尝试从返回文本中提取第一个完整的JSON对象。例如匹配\{[\s\S]*\}这能有效去除模型额外添加的说明文字。设置超时与备用为API调用设置合理的超时时间如30秒。如果主模型超时或连续失败立即切换到备用模型如另一个服务商的API或本地部署的轻量模型。问题3规则引擎的规则越来越多难以维护且可能互相冲突。排查当新增一条规则后发现之前能正确处理的一些案例突然出错了。这通常是规则冲突或顺序问题。技巧规则优先级为规则定义优先级P0, P1, P2。高优先级规则如金额逻辑校验先执行低优先级规则如某些字段的格式建议后执行。冲突时以高优先级为准。规则测试集建立一个涵盖各种边缘案例的测试发票集。每次添加或修改规则后跑一遍整个测试集确保没有破坏原有功能回归测试。规则可视化与管理将规则用更易读的方式如决策表管理并开发一个简单的界面让业务人员能看到规则触发的日志理解为什么某张发票被标记。问题4多模型投票成本太高如何平衡成本与收益技巧分级调用不是所有发票都走“全委员会”评审。可以设计一个“快速通道”先用一个最快/最便宜的模型或甚至传统OCR规则做初筛。对于初筛置信度高、且金额小、风险低的发票如小额出租车票直接采纳。只有初筛不通过或金额较大的发票才启动多模型投票。缓存结果对于同一张发票通过哈希值判断短时间内多次处理请求如重试、复核再次触发可以直接返回缓存的多模型投票结果避免重复调用API。使用开源模型积极评估和引入优秀的开源多模态LLM如Qwen-VL, InternVL虽然可能需自行部署但长期来看能大幅降低调用成本。问题5人工复核环节成为瓶颈人员抱怨工作枯燥。技巧智能排序复核队列不是简单的先进先出。系统可以根据置信度分数、发票金额、业务紧急程度等因素对队列进行排序让复核人员优先处理最可疑或最重要的票据。批量操作对于来自同一供应商、同一日期段的大量类似发票如果系统判断模式高度一致可以提示复核人员“这些50张发票的销售方信息疑似相同是否批量审核通过”极大提升效率。游戏化与反馈让复核人员能看到他们的修正如何帮助系统学习例如“您上周纠正的‘XX公司’简称问题本周已自动修正了20张类似发票”提升成就感。这场用LLM处理一万五千张发票的实战给我的最大体会是现阶段LLM不是传统自动化任务的“替代者”而是一个需要被精心“管理”和“赋能”的“超级员工”。它的能力惊人但也不可预测。我们不能指望用一个魔法咒语提示词就解决所有问题而必须为它搭建一个稳健的工作环境预处理、提供明确的操作手册提示工程、设立质量检查岗规则校验、配备领域专家支持知识库、引入同事复核多模型投票并保留经理的最终决策权人工闭环。这套六层防御体系每一层都在弥补LLM的某种不足同时也都在利用LLM的独特优势。它看起来比直接调用API复杂得多但正是这种复杂性换来了生产环境所需的可靠性、可维护性和可进化性。当你面对的不是几张演示图片而是成千上万张真实的、混乱的、关乎真金白银的业务单据时这种“系统工程”的思维远比追求某个单一模型的“刷榜”分数更重要。