BC-OCR

api doc（IMPORTANT）

Run & build

dev under go 1.24.6

# RUN
# clone & cd
go mod tidy
go run ./cmd

# BUILD
CGO_ENABLED=0 go build -o ./bin/bc-ocr ./cmd
chmod +x ./bin/bc-ocr
./bin/bc-ocr

thoughts

basic

三种状态：

• 图
• 文字
• 结构化的文字

OCR模型只负责图转字，LLM负责文字转结构化文字（使用 grammar）

待调研：语义化OCR直接生成结构化文字？

能力协商

模型方应该提供自己能够处理的内容，如

• OCR：
  • 提供“可处理格式”接口
  • 另：OCR api 接口无统一标准
    • 自建OCR后端
    • 配置中提供type？
• LLM：
  • 提供“是否可格式化输出/json输出”接口

或在配置中规定哪些模型的能力？

流程

对图→结构化文字任务：逐步进行

PDF等分区处理，在双端实现均可

• 未指定OCR或LLM模型时如何处理？

  选择能够拥有处理能力的模型

是否需要流量分配？

TODO

• ocr api
• config
  • OCR models (list)
    • address
    • model name
    • key
  • max file size
• Warn user if no models set in config

---

9.11

需实现图像的预处理，自写cv脚本 / 使用模型

需使用一个能够输出文本对应位置坐标的OCR模型

正在考虑使用PaddleOCR

LLM总结的方案需要模型参数量足够，否则经常发疯。我更倾向优先使用位置判断+文本关键字比对，LLM保底。

---

9.15 - 9.17

正则基本OK，接下来的两个方向：

1. 提高OCR文本分块检测的精度，更准确的分块方便正则提取
2. 研究KIE专业模型：作为LLM的替代
   • SER 语义标注模型
   • RE 关系抽取模型

如何处理印刷不齐的执照？

• KIE（困难）
• 更加细化的 基于位置的 字符串构建（困难）

---

9.19

权限问题：目前只有无权限 / 完全权限，是否有必要分开无权限/使用权/管理权

使用者是否有权看err