讨论：基于 OCR/VLM 方案的重构

## 基于 text 布局解析的局限
去年在 bill-file-converter 项目创建时，回看那个时间点：
- 当时 GitHub 上对账单的解析基本都是 Hardcode 解析逻辑、仅支持有限的账单类别，这也是 bill-file-converter 的实现思路
- 同时也已经有一些人在基于多模态模型做账单解析，但大多使用云服务或者比较重的本地模型

我们也曾经讨论过对这个项目的预期：
- 专注银行账单格式解析，统一到 CSV 纯文本格式，便于代码解析和处理
- 本地优先，保护账单敏感数据

而在维护了一段时间后，我发现这个方案的问题：
- 无法解析 image based pdf，只能解析 text based pdf
- text based pdf 解析的逻辑很复杂，各种计算文本间距的逻辑，隔段时间后很难看懂
- pdf 文本还有各种奇怪的边界 case，例如 #20

这些问题可能也是 GitHub 上一直没有一套完整统一的解析银行账单的项目/方案的原因。

## 尝试通用 VLM 方案
时间回到今年，前段时间我在测试 Qwen 和 Gemma 的多模态小模型时，惊奇的发现即使在功耗只有几瓦到几十瓦的手机/平板/笔记本上识别效果也已经很不错了，于是我在重新考虑是不是该考虑下基于本地模型来重构这个项目。

这几天我做了几个测试：
- 基于 Qwen 系列的本地模型（qwen-vl-*/etc）
- 发现对于简单且规则的账单文件解析效果比较好，例如招行借记卡和信用卡
- 但对于动态行高+无分割线的复杂账单（例如交行借记卡），基本都扑街了，出现了各种错位、重复、丢失的问题
- 而且优化 prompt、切换 thinking/切换模型/也没有显著的改善，问题跟打地鼠一样
- 基于 Kimi 2.6 等混合、尺寸更大的模型
- 无明显改善

## 文档解析专用模型
就在比较头疼的时候，发现最近已经有一批在专门做文档识别的小尺寸模型，以及有对应的 benchmark https://opendatalab.com/omnidocbench 。
参考榜单，我测试了前几个 SOTA 模型/产品，发现：
- 整体识别效果相比通用 VLM 有明显的提升，固定布局/清晰边界的表格成功率基本在 100%，动态布局且无边界的表格也能做到接近 100%
- 性能也比通用 VLM 更好，我使用 M1 Pro 在跑 Qwen VL 模型时风扇都会狂转，但切换这类小尺寸模型基本不会触发风扇转动
- 其中 MinerU 在工程上做的更完善一些，包括部署、API 设计等，两行命令就能在本地完成一套 API Server 部署，产物的设计也更完备 https://opendatalab.github.io/MinerU/zh/reference/output_files/

因此我建议基于 MinerU API 来进行识别解析。

## 重构顺便解决的问题
- GUI -> CLI：老版本架构基于 PDF.js，做成浏览器中的 GUI 是更自然的事情；但新版的架构强依赖 LM API，没必要再去保留 Web GUI 了
- TypeScript -> Golang：在之前的协作中还发现，deb-sig contributors 对 Golang 明显更熟悉一些，因此我也准备将语言切换回 Golang
- 统一架构：对于银行账单的解析，全部统一到基于视觉的方案，只接受 PDF 和图片，核心逻辑更少、adapter 适配成本更低