Java标准HTTP调用多模态模型的票据抽取前置校验
内容提要
文章介绍在Java中调用多模态模型抽取票据金额前进行本地校验：检查文件类型仅限JPG/PNG、大小不超过5MB，并用BigDecimal比对申报金额与识别金额，容差0.01元。示例基于JDK17+的HttpClient构造REST请求，显式处理密钥、超时和状态码，强调模型输出不可直接作为付款指令，需JSON解析与人工复核。
延伸解读
本地校验：成本与安全的第一道闸
文章强调在调用多模态模型前，先用Java检查文件类型和大小。这不仅能避免将任意文件或超大图片发送给模型，从而控制API成本，还能减少无效请求。代码中check方法拒绝非JPG/PNG和超过5MB的文件，直接抛出异常，让问题在本地暴露，而不是等到模型返回错误。这种前置门禁是报销自动化中防止事故的简单有效手段。
金额比对：为何必须用BigDecimal
文章使用BigDecimal的subtract和abs方法比较申报金额与识别金额，并设置0.01元容差。这是因为double类型在货币计算中会产生精度损失，导致比较结果不可靠。within方法通过compareTo判断差值是否在容差内，避免了直接使用等号。但文章也提醒，0.01容差不能用于含税与不含税不同口径的比对，否则可能掩盖真实差异。
模型输出不可直接作为付款指令
文章反复强调，模型的文字输出不能直接当作付款指令。示例代码只打印HTTP状态，并建议将原始响应交由受控的JSON解析器提取金额。生产中应要求模型按JSON Schema返回currency、amount和confidence字段，再用Jackson等库解析。此外，还需人工复核，因为模型可能出错，且税务规则复杂，自动化流程只能作为辅助核验。
工程化扩展与常见陷阱
文章指出，真实项目需加入病毒扫描、对象存储短期签名URL、JSON响应校验、票据哈希去重、人工复核与保留期限。常见错误包括：图片实际为PNG却硬写JPEG MIME、把带逗号的金额直接转数值、失败后无限重试导致重复上传。这些细节提醒开发者，从示例到生产还有大量工程工作，不能仅依赖模型能力。
Q&A
在Java中调用多模态模型抽取票据金额前，需要做哪些本地校验？
需要做三项本地校验：一是检查文件类型，只接受JPG、JPEG或PNG；二是检查文件大小，不能超过5MB；三是用BigDecimal比对申报金额与模型识别金额，容差为0.01元。
为什么不能用double来比较票据金额？
因为货币金额比较必须精确，double存在浮点精度问题，可能导致比较结果错误。文章强调应使用BigDecimal进行金额比对，容差设为0.01元。
调用多模态模型时，Java代码如何处理超时和API密钥？
代码通过HttpRequest设置连接超时5秒、整体请求超时25秒；API密钥从环境变量GEMINI_API_KEY读取，并通过请求头x-goog-api-key传递。如果密钥缺失或为空，会抛出异常。
模型返回的金额可以直接作为付款指令吗？
不可以。文章明确强调模型输出不可直接作为付款指令，必须交由受控的JSON解析器提取金额，并进行人工复核。生产中应要求模型按JSON Schema返回currency、amount和confidence，再用Jackson等库解析。
如果票据金额与员工申报金额不一致，应该怎么处理？
文章建议将这种情况进入人工复核，而不是自动付款。示例中的within方法用BigDecimal比较，容差0.01元，超出容差则视为不一致，适合作为进入审批前的辅助核验。
这个Java示例程序有哪些常见的错误需要避免？
常见错误包括：图片实际为PNG却硬写JPEG MIME类型；把模型输出中的逗号金额直接转数值；将0.01容差用于不含税/含税不同口径；失败后无限重试造成重复上传。
工程化落地时还需要补充哪些措施？
工程化时需加入病毒扫描、对象存储短期签名URL、JSON响应校验、票据哈希去重、人工复核与保留期限。此外，不应把原始票据长期写入日志。
