本地票据整理神器：Gemma + Ollama 打造隐私优先的开源工具

自由职业者最头疼的事之一，就是整理散落在邮箱、相册和截图里的发票。报税季到来时，手动录入每一张收据成为不可避免的负担。更棘手的是，这些票据往往包含客户名称、费率和付款细节——把它们上传到第三方服务，许多人并不放心。是否有办法既享受自动化便利，又不牺牲隐私？开发者 DhanushGowdaDev 给出了一个答案：Local Receipt Sorter。

该项目完全运行在用户自己的电脑上，借助 Gemma 视觉模型与 Ollama 本地推理框架，实现票据自动识别、字段提取、异常检测和导出。它可以处理 PDF、照片和截图，提取供应商名称、日期、发票号码、币种、小计、税额和总额，还能为每份文档建议规范的文件名，例如 2026-03-04_acme-cloud_1180.00.pdf。

核心设计：本地推理与结构化输出

Local Receipt Sorter 的技术栈并不复杂，但每个选择都围绕隐私和实用性展开。模型采用 Gemma 3 视觉模型（4B 参数）通过 Ollama 在本地提供服务，文档全程不出机器。开发者刻意没有依赖云端 API，因此没有按量计费的账单，也意味着可以预测成本。

整个流程完全由 Python 驱动：PyMuPDF 负责解析 PDF，Streamlit 提供交互界面，pandas 处理导出。安装步骤也很简单，只需三条命令：拉取 gemma3:4b 模型、安装依赖、启动应用。若需要更高精度，还可通过环境变量切换到 12B 版本。

为了让识别结果可程序化处理，模型输出被强制约束为 JSON schema。无论输入何种票据，返回的字段结构始终一致。这一点对后续的校验和导出至关重要，否则非结构化的文本将难以自动化利用。

Ollama 是一个开源的大语言模型本地运行框架，它把模型权重、推理引擎和 REST API 封装成单一可执行程序，用户只需 ollama pull <model> 即可拉取并运行模型。其核心价值在于屏蔽了 GPU/CPU 后端配置、量化格式和显存管理的复杂度，让非专业用户也能在个人电脑上跑起 4B 到 70B 级别的模型。Ollama 默认在 localhost:11434 暴露兼容 OpenAI 风格的接口，因此 Python 应用可以通过标准 HTTP 调用本地模型，无需任何云端凭证。对于 Local Receipt Sorter 这类隐私敏感工具，Ollama 提供的“数据不出机器”特性是关键：推理过程中的提示词、图像张量和输出 token 全部留在本机内存与磁盘，不会经过任何第三方服务器。

JSON schema 约束输出 是指通过提示词工程或推理框架的解码器约束，强制模型生成的 token 序列符合预定义的 JSON 结构。在 Local Receipt Sorter 中，这意味着无论票据是 PDF、照片还是截图，模型返回的字段名、类型和嵌套层级都保持一致，例如 {vendor: string, date: string, total: number, ...}。这种做法绕开了传统 LLM 输出“看似 JSON 但实际缺括号、多逗号”的解析难题。实现方式通常有两种：一是把 schema 写入系统提示词并配合 few-shot 示例；二是使用支持 grammar-based decoding 的推理后端（如 llama.cpp 的 GBNF 语法或 Ollama 的 format: json 参数），在采样阶段直接屏蔽非法 token。对下游的 pandas 导出和规则校验而言，稳定的 schema 是自动化流水线的前提。

不用模型自评，用规则校验

一个值得关注的工程决策是：开发者没有让模型报告自己的置信度。原因在于小模型（即便是视觉模型）对自身准确性的判断并不可靠。相反，系统内置了一套规则检查器，自动标记缺失字段、错误或未来日期、非正数总额，以及小计与税额之和不等于总额的行。

所有识别结果在导出前都会呈现在可编辑表格中，用户可以逐条修正。这种人机协作的方式，在自动化与准确性之间找到了平衡点。模型负责繁重的初步提取，规则负责捕捉明显错误，人类负责最终把关。

在测试中，作者遇到了一个有趣案例。最初他用订单页面（可以生成发票但本身不是发票）测试，模型返回了空日期列。他一度认为是模型失败，甚至放宽了提示词。后来才意识到模型是对的——文档中根本没有日期。于是他调整提示词，明确要求“绝不虚构日期、供应商或金额”。这个小插曲也反映出：本地模型在适当约束下，能够忠实反映输入，而非强行编造。

模型自评置信度 指的是让 LLM 在输出答案的同时附带一个“我有多确定”的分数或标签。对小参数量模型而言，这种自评往往不可靠：模型可能对完全错误的提取给出高置信度，也可能对正确结果给出低分。原因在于置信度校准需要模型对自身知识边界有准确元认知，而 4B 级别的视觉模型通常不具备这种能力。Local Receipt Sorter 选择用确定性规则替代自评，例如检查日期是否在未来、总额是否为正数、小计加税额是否等于总额。这类规则只依赖字段间的数学与逻辑关系，不依赖模型的主观判断，因此更稳定、可测试、可审计。工程上，这相当于把“不确定性检测”从模型内部转移到外部代码，是本地小模型应用中常见的可靠性补偿策略。

实测 25 份文档：可行性验证

创作者在 25 份文档上进行了测试，包括 15 份 PDF、10 张照片和 15 张截图。需要说明的是，这个样本量只能证明“它能工作”，不能说明“它有多可靠”。作者本人也坦承了这个局限：“我仅测试了 25 份文档，这些结果展示的是它可行，而非成功率有多高。”

一个关键验证是：关闭 Wi-Fi 后应用仍然正常工作，这证实了推理过程确实在本地完成。对于关心数据隐私的自由职业者，这一点比单纯的准确率指标更有说服力。

作者没有将本地模型与闭源商业模型进行对比，因此他没有声称“更好”。他的主张更克制：一个小型开源模型，在本地运行，能够完成这项工作中相当有用的一部分。 这种审慎的态度在 AI 项目中并不多见。

Gemma 3 视觉模型（4B） 是 Google 发布的轻量级多模态模型，支持文本与图像输入，4B 参数版本经过 4-bit 量化后显存占用约 3-4GB，可在消费级笔记本 GPU 或 Apple Silicon 上流畅运行。视觉能力使其能直接“看”发票照片和截图，而不依赖 OCR 预处理。不过 4B 规模在复杂版式、手写体或低光照照片上的字段提取精度会明显低于 12B 或云端大模型。Local Receipt Sorter 允许通过环境变量切换到 gemma3:12b，这提供了精度与资源消耗之间的可调档位。对自由职业者而言，若票据以电子 PDF 为主，4B 通常够用；若大量为手机拍摄的收据，升级到 12B 或增加图像预处理（如裁边、增强对比度）会更稳妥。

开源与商业化的双重可能

作为 Hacktoberfest 挑战赛第二周“副业”主题的参赛作品，Local Receipt Sorter 也提出了商业化设想：可以一次性授权出售给自由职业者，或按月收费，甚至提供按批次处理的代客服务。

隐私本身就是产品差异点。对于处理敏感财务信息的用户，本地运行的优势无可替代：没有数据外泄风险，没有按张计费的顾虑，且用户可以自由更换更大的模型、收紧提示词，甚至针对特定类型（如 GST 发票）进行微调。代码已在 GitHub 开源，项目下一步计划包括增加测试文档、尝试更大模型、针对细分场景微调，以及吸引第一位付费用户。

这个项目的价值在于展示了一种路径：开源小模型无需追求通用性，只要在垂直场景中稳定完成明确任务，就能构建出具有实用价值和商业潜力的工具。隐私不是噱头，而是被代码结构所保障的事实。