专用小语言模型如何通过SFT与DPO优化，实现低成本、高稳定OCR

1. 项目概述：当OCR遇上专用小语言模型

在文档数字化和信息提取的日常工作中，光学字符识别（OCR）技术扮演着“翻译官”的角色，负责将图片、扫描件这些机器“看不懂”的视觉信息，转换成结构化的、可被程序处理的文本。这个活儿听起来简单，但实际干起来，坑可不少。传统的OCR引擎，像是Tesseract或者一些商业闭源方案，在处理排版规整的印刷体文档时表现尚可，但一旦遇到手写体、复杂的表格、混合了图片的版面，或者是一些特定领域（比如法律文书、历史档案）的文档，准确率就会大打折扣。它们更像是在“认字”，而不是“理解文档”。

近年来，随着多模态大语言模型（如GPT-4V、Gemini等）的崛起，大家发现，让模型“看懂”图片里的文字并理解其结构，似乎有了新的解法。这些模型凭借强大的视觉-语言联合理解能力，在复杂文档的识别和结构化上确实表现惊艳。但问题也随之而来：这些“巨无霸”模型推理成本极高，响应延迟大，对于需要处理海量文档的企业级应用来说，每页几美分甚至更高的成本是难以承受的。更关键的是，它们是“通才”，并非为OCR任务量身定制，在一些专业领域文档上，其“常识”可能反而成为干扰。

于是，一个更务实的思路出现了：专用小语言模型。它的核心思想是“好钢用在刀刃上”。与其用一个万亿参数的庞然大物去干OCR这一件“小事”，不如训练一个参数量小一到两个数量级（比如3B到7B）的模型，但让它所有的“注意力”都集中在理解文档图像、识别文字、并按照预设结构（如JSON）输出上。这样做的直接好处是，模型推理速度快、成本低，且因为高度专业化，在目标任务上的性能甚至可以超越那些“通才”大模型。

然而，小模型也有自己的“阿喀琉斯之踵”：文本退化。这不是指识别错误，而是模型在生成文本时，可能会陷入一种“鬼打墙”的循环，不断重复某个词或句子，直到达到生成长度上限才被迫停止。想象一下，你让模型识别一页合同，它却不停地输出“甲方甲方甲方甲方……”，这不仅让输出结果完全报废，更糟糕的是，它会占满GPU内存、阻塞推理队列，严重拖垮整个系统的吞吐量和响应时间。文本退化不是一个简单的质量瑕疵，而是一个会引发系统性性能雪崩的工程灾难。

今天要深入探讨的DharmaOCR项目，正是针对上述痛点的一次精准打击。它基于开源的小语言模型（如Qwen2.5-VL、Nanonets-OCR2），通过一套组合拳——监督微调来教会模型严格遵守我们设定的JSON输出格式，再通过直接偏好优化来“惩罚”模型产生退化文本的行为——最终炼成了DharmaOCR Full和Lite两个模型。它们不仅在自建的巴西葡萄牙语文档基准测试中，在提取质量上超越了所有开源和商业基线模型，更重要的是，将文本退化率压制到了极低的水平（最低0.20%），同时通过量化技术进一步压缩了推理成本。这为在实际生产环境中部署高效、稳定、低成本的OCR服务，提供了一个经过验证的、可复现的工程范本。

2. 核心思路拆解：从通用到专用，从识别到“规训”

要理解DharmaOCR的价值，我们需要先拆解其解决核心问题的逻辑链条。这个项目的目标非常明确：在保证高精度结构化文本提取的前提下，实现低延迟、低成本和高稳定性（即低退化率）。其方法论可以概括为“一个基础，两次优化”。

2.1 基石：为什么选择专用小语言模型？

首先，为什么是“小”模型？在AI领域，通常存在一个误区：模型越大，能力越强。这在一定范围内成立，但对于高度特定的任务，大模型的冗余参数和广泛的知识分布可能并非最优。SSLMs的思路是反其道而行之：

1. 计算效率：参数量小（3B-7B），意味着单次推理所需的浮点运算和内存带宽大幅减少。这直接转化为更快的响应速度（通常为秒级甚至亚秒级）和更低的硬件成本（可以用消费级GPU甚至高端CPU部署）。
2. 任务专注：通用LLM的训练目标涵盖聊天、推理、编程等上百种技能。而SSLM在微调阶段，其所有参数更新都围绕着“从文档图像生成结构化JSON”这一个目标进行。这使得模型有限的“脑容量”被最有效地利用，避免了知识稀释。
3. 可控性与可解释性：模型越小，其行为相对越容易分析和调试。在出现问题时，工程师可以更聚焦地分析是数据问题、提示词问题还是模型本身的缺陷。

在DharmaOCR中，团队没有从零开始训练一个模型，而是选择了两个已有良好OCR基础的“苗子”：olmOCR-2-7B和Nanonets-OCR2-3B。这是一个非常聪明的策略。前者是基于Qwen2.5-VL-7B-Instruct在书籍、论文等多样式文档上微调而来的，后者则是专为输出Markdown格式设计的3B模型。以它们为起点进行二次优化，相当于站在了“OCR专家”的肩膀上，比从通用的多模态模型开始微调，收敛更快，效果也更有保障。

2.2 第一次优化：用SFT塑造“输出纪律”

监督微调是让模型适应新任务的标准方法。在DharmaOCR的上下文中，SFT的目标不仅仅是让模型“认得更准”，更重要的是让它“输出得对”。

核心在于结构化输出。项目为训练数据设计了一个严格的JSON Schema：

这个结构看似简单，却意义重大：

• 强制分离：它强制模型理解文档的版面布局，区分不同功能区的内容。这对于后续的信息抽取（如只从text字段提取正文）至关重要。
• 信息完整性：与一些只提取主体文本的方案不同，此结构保留了所有文本区域，将“是否使用页眉/页脚信息”的决定权交给了下游应用，提供了更大的灵活性。
• 易于验证：JSON格式便于程序化校验，可以快速检查输出是否完整、字段是否缺失，为自动化流水线提供了便利。

在SFT阶段，模型通过最小化预测输出与人工标注的JSON之间的交叉熵损失来学习。这个过程就像老师手把手地教学生：“看到这种版式的图片，你应该输出这样结构的文本。” 经过SFT后，模型已经能够较好地完成从图像到结构化文本的转换。

2.3 第二次优化：用DPO根治“文本退化”顽疾

SFT解决了“怎么做对”的问题，但未必能解决“怎么不犯错”的问题，尤其是文本退化这种“低级错误”。文本退化的根源在于自回归语言模型的内在缺陷：模型在生成下一个词时，如果某个词的概率异常高，且被选中，那么下一个时间步看到这个词的历史后，生成它的概率可能会更高，从而陷入自我强化的循环。

传统的解决思路多在推理阶段下功夫，比如调整采样温度、使用核采样、重复惩罚等。但这些方法属于“事后补救”，且可能影响正常文本的生成质量。DharmaOCR创新性地将直接偏好优化应用到了OCR任务中，在训练阶段就对退化行为进行“根治”。

DPO的工作原理：它不需要训练一个复杂的奖励模型，而是直接利用“好答案”和“坏答案”的对比来调整模型。其损失函数的核心思想是，最大化模型认为“好答案”优于“坏答案”的几率。

在DharmaOCR中，DPO的“妙用”在于：

1. 构建偏好对：从SFT后的模型在评估集上的生成结果中，利用一个强大的LLM（如Qwen3-VL-235B）作为“裁判”，根据完整性、准确性、格式和JSON遵循度四个标准，对同一个文档的多个候选输出进行评分和排序。
2. 刻意保留“坏样本”：关键的一步是，那些发生了文本退化的生成结果，被刻意地标记为“被拒绝的答案”。这样，DPO训练过程就会接收到一个明确的信号：“生成这种循环重复的垃圾文本，是非常糟糕的行为。”
3. 优化目标：DPO损失函数会拉高“好答案”（高评分、无退化）的相对概率，同时压低“坏答案”（低评分、或包含退化）的相对概率。经过这个过程的模型，其内部概率分布被重塑，从根源上降低了陷入退化循环的可能性。

这种“SFT打基础，DPO修细节”的两阶段策略，是DharmaOCR在保持高精度的同时，将文本退化率降低多达87.6%的关键。它不仅仅是在教模型“做什么”，更是在教它“不做什么”。

3. 实操要点：数据、训练与评估的魔鬼细节

纸上谈兵终觉浅，绝知此事要躬行。DharmaOCR的成功，离不开在数据构建、训练工程和评估设计上的一系列扎实操作。这些细节往往是决定一个研究项目能否转化为稳定生产系统的关键。

3.1 数据准备：质量与多样性的平衡

模型的天花板由数据决定。DharmaOCR的训练数据集合了约4万页文档，核心语言为巴西葡萄牙语。其构建策略体现了实用主义：

• 来源混合：结合了公开数据集（如arXiv）和内部专有数据。公开数据提供多样性，内部数据确保对目标领域（如法律、行政文档）的覆盖。
• 预处理与匿名化：在纳入训练集前，所有文档都经过了敏感信息移除和匿名化处理。这是合规性要求，也是保护隐私的必要步骤，对于处理真实企业文档至关重要。
• 标注流水线：采用“大模型标注+人工校验”的模式。使用Claude、Llama、Gemini等多个大模型进行初步文本提取和结构化，然后进行人工抽样验证和质量控制。这种方法在保证标注规模的同时，有效控制了成本和质量。
• 严格的训练/评估分离：用于最终模型评估的DharmaOCR-Benchmark数据集，与训练集和用于DPO偏好对构建的数据集是完全独立的。这确保了评估结果的公正性，防止模型过拟合到测试集。

注意：对于希望复现或借鉴此工作的团队，数据构建是第一个门槛。如果缺乏特定领域的标注数据，可以优先考虑使用现有开源OCR模型（如PaddleOCR、EasyOCR）进行粗标注，再辅以人工精校。关键在于保证标注格式（如上述JSON Schema）的一致性。

3.2 训练工程：超参数与资源管理

训练过程的稳定性直接影响最终模型的性能。报告中提到的一些关键选择值得关注：

1. 全参数微调 vs. LoRA：实验对比了全参数微调和LoRA两种方式。结果显示，对于OCR这种需要模型深刻理解视觉-语言对齐的任务，全参数微调（FFT）通常能带来更好的性能。LoRA虽然节省显存，但在一些模型上（如Gemma）性能损失较大。这表明，当计算资源允许时，对小型模型进行全参数微调可能是性价比更高的选择。
2. 学习率与调度：采用了余弦退火学习率调度，初始学习率在1e-5（FFT）到1e-4（LoRA）量级，并设置最低点为初始学习率的10%。这是一个比较稳健的设置，避免了训练后期的震荡。
3. DPO数据筛选：并非所有生成的候选对都用于DPO训练。团队采用了类似Selective-DPO的策略，进行了多阶段过滤，包括统计分析去除离群值、人工审查随机样本等，最终只保留了约21%的高质量偏好对。这确保了DPO训练信号的清晰和有效，避免了噪声数据干扰优化过程。
4. 硬件配置：SFT训练在单张H200 GPU上进行，而DPO训练和推理标注则用到了多张H200。这提示我们，DPO阶段由于需要多次生成和评估，计算开销更大。在实际操作中，可以根据资源情况调整批次大小或使用参数更小的“裁判”模型来降低成本。

3.3 评估体系：超越精度的综合考量

DharmaOCR-Benchmark的设计体现了工程化的评估思维。它不仅仅看“认得多准”，还看“跑得多稳”、“花多少钱”。

1. 综合质量分数：基准分数 = (Levenshtein比率 + BLEU) / 2。
   • Levenshtein比率：基于编辑距离，擅长捕捉字符级别的错误，如拼写错误、漏字、错别字。这对OCR至关重要。
   • BLEU：基于n-gram重叠，擅长评估句子级别的流畅度和顺序保持能力。 两者结合，兼顾了“字对不对”和“句顺不顺”。
2. 文本退化率：被提升为一级评估指标。判定标准结合了输出达到令牌上限和检测到重复文本片段。这直接量化了模型的不稳定程度。
3. 单页成本：为了公平比较本地模型和商业API，项目提出了“每百万页成本”的估算方式。
   • 本地模型：成本 = (单页平均处理时间 * 每小时基础设施成本)。这需要精确测量推理延迟和硬件租赁费用。
   • 商业API：根据其定价模式（按令牌、按页、按次）进行换算。 这个指标将性能拉回到了商业可行的层面，回答了“好，但用得起吗？”这个问题。
4. 推理环境标准化：所有模型都在统一的AWS g6e.2xlarge实例（NVIDIA L40S GPU）上，使用vLLM进行推理，并设置相同的上下文长度（8192令牌）。这消除了因软硬件环境差异导致的性能波动，确保了比较的公平性。

4. 结果分析与模型选择：在性能、成本与稳定性的三角中寻找最优解

看懂了方法，我们再来看看DharmaOCR交出的成绩单。表1中的数据非常丰富，我们可以从中提炼出几个核心结论和选型建议。

4.1 性能提升：SFT与DPO的贡献分解

对比“原始模型”、“仅SFT”、“SFT+DPO”三列数据，可以清晰看到每一步的收益：

• SFT的基石作用：以olmOCR-2-7B为例，原始模型基准得分为0.823，退化率1.41%。经过SFT后，得分跃升至0.928，退化率略降至1.01%。SFT带来了巨大的质量提升（+0.105），主要贡献是让模型学会了结构化输出。
• DPO的稳定器作用：在SFT基础上加入DPO后，得分轻微下降至0.927（变化可忽略），但退化率从1.01%大幅降低至0.40%，降幅超过60%。这完美印证了DPO的核心价值：在基本保持提取质量的前提下，显著提升模型的生成稳定性。对于Nanonets-OCR2-3B，DPO将退化率从1.61%压到了惊人的0.20%。
• 量化的小代价：对最佳模型进行AWQ量化后（W4A16或W8A8配置），性能损失微乎其微（得分下降约0.002-0.006），但带来了显著的成本降低（推理时间减少约20-30%）。这几乎是“免费的午餐”，是生产部署的必选项。

4.2 模型选型：Full vs. Lite

基于结果，团队最终选定了两个模型发布：

• DharmaOCR Full (7B)：基于DPO优化并量化后的olmOCR-2-7B。它在所有模型中取得了最高的基准得分（0.925），同时保持了极低的退化率（0.40%）和具有竞争力的成本（相对于原始模型成本降低约50%）。它是性能的标杆，适合对识别准确率要求极高、且有一定算力预算的场景。
• DharmaOCR Lite (3B)：基于DPO优化并量化后的Nanonets-OCR2-3B。它的得分（0.911）略低于Full版，但退化率更低（0.20%），且成本优势极其明显（相对成本最低，仅约34%）。它是性价比之王，在资源受限的边缘设备或需要极高吞吐量的批量处理场景中优势巨大。

4.3 与竞品的横向对比

与开源和商业基线模型相比，DharmaOCR的优势是全方位的：

• vs. 开源模型：无论是Qwen3-VL系列、GLM-OCR还是DeepSeek-OCR，DharmaOCR Full和Lite在得分上全面领先，同时退化率远低于这些通用或半专用的模型。
• vs. 商业API：在得分上，DharmaOCR Full（0.925）显著优于Claude Opus（0.833）、GPT-4o（0.635）等商业巨头。更重要的是，商业API按使用量计费，长期累积成本不可控，且存在数据隐私和网络延迟问题。DharmaOCR作为可私有化部署的模型，在成本可控性、数据安全和延迟方面具有天然优势。

一个关键的洞见是：从已在OCR任务上表现良好的模型（如olmOCR-2）出发进行二次优化，其效果远好于从通用的多模态模型（如原始Qwen2.5-VL）开始微调。这证明了领域自适应（Domain Adaptation）的累积效应。

5. 生产部署考量与避坑指南

将这样一个模型真正用起来，还会遇到一系列工程挑战。以下是一些基于经验的实操建议和常见问题排查思路。

5.1 部署架构建议

对于生产环境，建议采用以下架构：

• 使用vLLM：强烈推荐使用vLLM作为推理后端。它实现了PagedAttention等优化，能极大提高GPU内存利用率和吞吐量，特别是对于可变长度的OCR请求。
• 服务化：将模型封装为RESTful API或gRPC服务，便于集成。服务层应包含请求排队、批处理、预处理（图像缩放、归一化）、后处理（JSON验证、编码转换）和缓存（对相同文档的重复请求）等功能。
• 监控与告警：必须监控关键指标：每秒请求数、平均响应延迟、P95/P99延迟、GPU利用率、文本退化率。一旦退化率异常升高或延迟大幅增加，应立即触发告警。

5.2 常见问题与排查

1. 问题：模型对某些特定字体或模糊图片识别率骤降。

   • 排查：检查问题图片是否超出了训练数据的分布。训练数据可能缺乏极端模糊、强光照、特殊艺术字体的样本。
   • 解决：进行数据增强。在预处理阶段，可以主动为输入图像添加模拟的模糊、噪声、透视变换，提升模型的鲁棒性。更根本的方法是，收集一批问题样本，加入到训练集中进行增量微调。

2. 问题：输出JSON偶尔出现字段错乱，例如将页眉文本放入text字段。

   • 排查：这通常是SFT阶段数据标注不一致或模型对版面理解不足导致的。检查出错的文档是否有非常规的版面布局（如三栏、环绕图片）。
   • 解决：确保训练数据标注的严格一致性。可以尝试在提示词（Prompt）中更明确地描述各字段的定义。对于固定模板的文档（如发票、申请表），可以训练一个额外的版面检测模型先行分割区域，再分别识别。

3. 问题：即使经过DPO，在超长文档或复杂表格上仍偶发退化。

   • 排查：检查输入图像的尺寸和模型设置的上下文长度。超大的图像经过视觉编码后可能产生过多的视觉令牌，挤占了文本生成的令牌预算。
   • 解决：调整预处理策略。对于超长文档，可以采用“分页识别，再合并”的策略。对于复杂表格，可以尝试先调用一个专门的表格识别模型，或者将表格区域裁剪出来单独识别。此外，可以微调DPO训练数据，增加更多长文档和复杂表格的样本及其退化负例。

4. 问题：量化后模型在某些边缘case上精度损失明显。

   • 排查：AWQ量化虽然整体稳健，但对输出层和视觉编码器较为敏感。检查精度损失是否集中在某类特定内容（如数学公式、罕见符号）。
   • 解决：尝试不同的量化配置。论文测试了FP8、W8A8、W4A16。如果W4A16损失大，可以回退到W8A8。更保守的方法是，对敏感层（如输出投影层）保持FP16精度，只量化中间层。

5.3 成本优化实战技巧

• 动态批处理：利用vLLM的连续批处理功能，将多个用户的OCR请求动态组合成一个批次进行推理，能大幅提升GPU利用率和吞吐量，摊薄单次请求的成本。
• 分级服务：根据业务需求，建立快慢两条管道。对实时性要求高的请求，使用DharmaOCR Lite（3B）快速响应；对后台批量处理、精度要求极高的任务，使用DharmaOCR Full（7B）。甚至可以准备一个更小的模型（如1B级别）用于质量要求不高的预览场景。
• 缓存策略：对相同的文档图片进行哈希，将识别结果缓存起来。这在处理大量重复文档（如同一模板的表格）时，能减少90%以上的模型调用。
• Spot实例与弹性伸缩：如果在云上部署，可以使用Spot实例来运行批处理任务，并设置基于队列长度的自动伸缩，在业务低谷期节省成本。

DharmaOCR的工作为我们展示了一条清晰的路径：通过领域专用的数据、针对性的训练策略（SFT+DPO）和严谨的工程化评估，小模型完全可以在特定任务上战胜大模型和通用商业方案。它的价值不仅在于发布了两个优秀的模型，更在于提供了一套可复现的方法论——如何系统地解决OCR任务中的质量、稳定性和成本三角难题。在实际项目中，我们可以借鉴其数据构建、两阶段训练和综合评估的思路，将其适配到自己的文档类型和业务语言上，打造出真正属于自己的、高效可靠的文档智能化引擎。