Python接入Gemini 3.8 Flash实现票据视觉抽取与规则校验
内容提要
本教程介绍用 Python 调用 Gemini 3.8 Flash 抽取票据字段，并通过 Pydantic Schema 与本地 Decimal 规则双重校验。金额以字符串传输以避免浮点误差；差额超过 0.01、币种未知或图像不清时转人工处理。模型仅负责识别，本地代码负责判断，结果进入待审批队列而非自动打款，同时需防范重复报销与隐私泄露。
延伸解读
为什么金额要用字符串传输
文章强调金额字段在Schema中定义为字符串，而非浮点数。这是因为二进制浮点可能产生0.1+0.2这类精度误差，导致合计校验失败。进入本地业务代码后再用Decimal转换并统一保留两位小数，能避免因精度问题误判票据。这一设计把模型输出与财务计算解耦，让模型只负责识别，本地代码负责精确判断。
转人工条件的设计逻辑
文章设定了三个明确的转人工条件：图像质量非clear、币种为UNKNOWN、小计加税额与总额差额超过0.01。这些条件不依赖模型自报置信度，而是用可验证的本地规则判断。作者指出，未经校准的置信度百分比容易制造虚假确定性，因此用显式状态和数学复算替代，让高风险错误在付款前被拦截。
图片预处理与多票据处理要点
预处理的目标是让可见证据更稳定，而非把票据修得更像真的。文章建议做四角检测、旋转纠正和补光提示，但避免过度锐化或涂抹，以免改变小数点和数字边缘。原图与处理后图片应使用不同哈希并建立关联。若一张图含多张票据，应先分割并为每个区域生成独立ID，再分别抽取和复算，防止总额被错误合并。
适用边界与工程化改进方向
文章明确该流程适合低风险报销预审、收据归档和人工审核辅助，不适合单凭图片自动打款或判断票据真伪。生产环境应保存图片哈希、建立多场景评测集，并分别统计字段准确率、金额完全匹配率和人工转交率。其中“应该转人工却自动通过”的漏拦率最关键，因为系统价值在于把高风险错误挡在付款之前。
Q&A
用Python调用Gemini 3.8 Flash做票据识别，为什么不能直接自动打款？
因为模型只负责识别，本地代码负责判断，结果进入待审批队列而非自动打款。即使金额数学上吻合，也可能存在重复票据、伪造图片、超预算或不合规品类，所以不能单凭图片自动打款。
票据金额为什么用字符串传输而不是浮点数？
因为二进制浮点会产生0.1 + 0.2一类精度问题，金额故意用字符串而非浮点数，进入业务代码后再转成Decimal并统一两位小数。
哪些情况下票据识别结果需要转人工处理？
差额超过0.01、币种未知或图像不清晰时一律转人工。此外，日期晚于今天或票号为空等本地规则也可触发转人工。
Gemini 3.8 Flash处理票据图片时，输入层有哪些限制？
小图片可以以内联Base64数据提交，整个请求小于20MB时最方便；示例把图片大小控制在15MB以内，给提示词和编码留余量。大文件或重复使用的图片应走Files API。
如何用Pydantic Schema约束模型输出？
定义Receipt模型，包含merchant、currency、subtotal、tax、total、image_quality、notes七个字段。金额用字符串，image_quality是三选一枚举，让“看不清”成为显式状态。模型返回后先用Pydantic验证结构，本地代码再计算subtotal + tax - total。
票据图片预处理时要注意什么？
预处理目标是让可见证据更稳定，不要过度锐化或涂抹，以免改变小数点和数字边缘。原图与处理后图片应使用不同哈希并建立关联。分辨率不是越高越好，应用自己的票据集合做分档实验，观察关键字段完全匹配率。
这个方案适合哪些场景，不适合哪些场景？
适合低风险报销预审、收据归档、商品标签抽取和人工审核辅助。不适合单凭图片自动打款、判断票据真伪或处理高额异常交易。视觉模型能读内容，却不能替代发票查验平台、重复报销检测和财务授权。
生产环境如何做工程化改进和评测？
应保存图片哈希而非随意复制原图，建立不同拍摄角度、低光、折痕和多语言票据的评测集；分别统计字段准确率、金额完全匹配率和人工转交率。按字段赋予不同风险权重，记录字符准确率、字段完全匹配率、金额差错率与漏拦率。模型或SDK升级时先做影子流量对比，再调整自动通过阈值。
