法国公司LightOn发布LightOnOCR-3系列小模型（0.8B、1B、4B），尝试将OCR、版面理解、图像描述与图表数据提取整合到一次调用并以Apache 2.0开源。模型支持默认文本转录和带坐标的grounding模式，输出区域标签与边界框，便于企业文档检索与RAG工作流接入，但性能与稳定性仍需独立评测验证。
法国人工智能公司LightOn于2026年10月8日发布LightOnOCR-3模型系列，试图把传统OCR、文档版面分析、图像描述和图表数据提取整合到一个较小的视觉语言模型中。该系列提供0.8B、1B和4B三个尺寸，模型以Apache 2.0许可证开放，面向研究和商业使用。
LightOn在官方介绍中将这次升级定位为从“文字转录”走向“文档理解”。模型不仅输出页面文字，还可以识别标题、段落、表格、图片、图表等区域，并为这些区域返回标签和边界框。使用名为grounding的提示词时，模型还会对图片进行简短描述，并把图表中的数据整理为HTML表格。
LightOn官方产品与研究页面和Hugging Face官方发布文章是此次发布的主要来源。
从文字识别到带空间信息的文档输出
传统OCR流水线通常先识别文字，再交给其他组件判断标题、表格或图片的位置。若应用还需要理解图表，往往要另外接入版面分析、视觉问答或表格识别模块。LightOnOCR-3的核心变化，是尝试由同一个模型直接产生这些信息。
在默认的转录模式下，模型沿用此前LightOnOCR的使用方式：输入页面图像和空提示词，输出页面文字及Markdown格式内容。对于已经部署LightOnOCR-2的用户，LightOn表示，1B版本保留上一代架构，因而可以作为相对直接的升级路径。
另一种是grounding模式。模型会在输出内容前加入类型和坐标标记，坐标被归一化到0至1000。例如，一段标题可以带有title标签和对应边界框；图片区域会附上简短描述；图表区域则可输出包含数据点的HTML表格。支持的区域类型还包括列表、页眉、页脚、页码、脚注、公式、代码和题注等。
这种输出形式对企业文档搜索和检索增强生成（RAG）有实际意义。文档处理系统不仅能保存“页面上写了什么”，还可以记录内容位于什么位置、属于哪一类区域，并把检索结果链接回原始页面。对于报告、发票、表单、收据、多栏排版和技术论文等材料，这类空间信息有助于减少纯文本切分造成的上下文丢失。
但这并不意味着模型已经替代了所有文档处理组件。边界框和标签仍需要被下游系统解析，表格恢复也需要根据业务要求转换为适合数据库、搜索索引或知识库的格式。模型输出是否能在不同扫描质量、语言和复杂版面下保持稳定，也仍需要更多独立测试。
三个尺寸对应不同部署取舍
LightOnOCR-3包括三个模型：0.8B、1B和4B。官方模型卡显示，1B版本沿用LightOnOCR-2-1B的架构；0.8B和4B版本则采用Qwen3.5视觉语言模型架构。LightOn把4B版本列为面向多数OCR任务的推荐模型，把0.8B版本定位为速度和效率优先的选择，而1B版本主要面向希望保持上一代架构和接入方式的部署。
模型卡还给出了不同的预处理建议。4B版本建议将PDF页面以400 DPI渲染，并把最长边调整到2048像素；1B版本建议使用约200 DPI和最长边1540像素的图像。这样的差异反映出模型尺寸、输入分辨率和显存需求之间的权衡：更高的图像分辨率有利于处理小字体和复杂页面，但也会增加推理成本。
LightOn同时提供了Transformers和vLLM使用方式，以及用于转换输出和可视化的LightOnOCR开源代码库。这使开发者可以选择直接获得Markdown转录，也可以把带坐标的结果接入自己的文档解析、检索或知识库导入流程。
厂商基准显示小模型具有竞争力，但不等于独立结论
根据LightOn在Hugging Face文章中披露的比较结果，LightOnOCR-3-4B在olmOCR-Bench上的总体分数为86.3，0.8B版本为85.5，1B版本为84.5。在ParseBench中，4B和0.8B版本的五类总体分数分别为75.1和74.6，1B版本为71.4。
LightOn还把三个基准的总体结果做了等权汇总：4B版本为78.5，0.8B版本为76.9，1B版本为75.2。按这一汇总方式，4B和0.8B均处于较小模型与较高分数的前沿位置。4B版本在olmOCR-Bench的ArXiv类别得分91.1，0.8B版本在长小字类别得分94.1，1B版本在多栏页面类别得分85.9。
这些数字需要放在限定条件下理解。首先，汇总分数是LightOn按照三个基准和特定评测规则计算出的派生指标，不是一个独立机构发布的统一排行榜。其次，olmOCR-Bench的部分结果使用了后处理，而ParseBench和fr-bench-pdf2md的输出按提交结果评估；不同模型的报告方式也不完全相同。LightOn自己也将这些结果描述为在选定开源或开放权重模型中的比较，而不是覆盖所有OCR系统的普遍结论。
更具体地说，LightOnOCR-3-4B在olmOCR-Bench总体分数上低于参数规模为35.1B的Infinity Parser Pro，但在同为4B规模的比较中高于Chandra 2。0.8B版本的结果则说明，在特定文档类别中，较小模型未必会因为参数更少而明显落后。不过，这类结果只能说明它在这些数据集和评测设置下具有竞争力，不能直接推导出所有企业文档场景中的准确率、成本或稳定性优势。
这类边界同样适用于速度和成本。LightOn表示LightOnOCR-3相较上一代在速度和转录质量方面有所改进，但实际吞吐量和单页成本仍会随硬件、图像分辨率、批处理方式和部署框架变化。没有统一硬件和公开第三方测试时，厂商披露的速度描述不应被当作普遍适用的性能承诺。
OCR竞争正在从识字转向文档工作流
LightOnOCR-3的发布，反映出OCR产品竞争正在发生变化。过去，OCR的主要问题是把扫描图片转换为文字；现在，企业更关心的是如何把复杂文件直接送入搜索、RAG、知识库和智能体工作流。模型是否能保留标题层级、表格关系、图片含义和页面位置，往往比单纯提高字符识别率更接近实际部署需求。
AIFlux此前对DharmaOCR的报道显示，专门化的小模型可以在明确的语言和文档任务中，通过任务对齐和偏好优化取得具有竞争力的结果。LightOnOCR-3的方向与此相似，但它把重点从特定语言的转录质量进一步扩展到版面和视觉内容的联合理解。
另一方面，PP-OCRv6的轻量多语OCR家族代表了另一条路线：通过更小的模型和多种推理后端，适配边缘设备、移动端和服务端部署。两者并不是简单的“谁的模型更强”的关系，而是对应不同的工程约束。LightOnOCR-3更强调单模型覆盖转录、版面、图像和图表；轻量OCR家族则更强调参数规模、延迟、多语言和运行时适配。
在实际企业环境中，模型的选择可能取决于文档类型、语言覆盖、隐私要求、硬件预算和下游系统能否处理结构化输出。对于纸质档案和扫描件，图像质量与版面复杂度可能比模型参数规模更重要；对于知识库导入，表格和图片是否能被稳定地转换为可检索结构，可能比单一基准分数更关键。
Cloudflare推出的AI Search也说明，扫描PDF的OCR已经被纳入托管式搜索和智能体检索基础设施。LightOnOCR-3提供的是更靠近模型和部署层的开放组件，而托管服务则负责把文件摄取、OCR、嵌入和检索串起来。两条路线最终都在回答同一个问题：如何让企业文档不只是“被读出来”，而是能进入后续的搜索、问答和自动化流程。
下一步仍要看独立评测和真实部署
LightOnOCR-3的开放许可证、三种模型尺寸和可直接接入Transformers或vLLM的方式，降低了开发者试用和自托管的门槛。对需要处理敏感文件的企业而言，本地部署也可能比把文档发送到外部API更容易满足数据边界要求。
但开放权重和较好的厂商基准成绩，并不自动等于生产环境已经成熟。后续仍需要观察几个问题：模型在更多语言和非标准扫描件上的表现如何；图表数据提取是否足够可靠；边界框与文档阅读顺序在复杂版面中是否稳定；不同硬件上的实际吞吐和成本怎样；以及模型能否在大规模批处理和长文档场景下保持一致的输出质量。
因此，LightOnOCR-3更准确的定位，是一个把OCR与文档视觉理解进一步合并的开放模型系列，而不是已经解决所有文档智能问题的通用答案。它所展示的方向很明确：未来的文档处理模型，竞争重点将不再只是“能否识别文字”，而是能否以较小的部署成本，把文字、空间关系、图像和图表转换为可供企业系统继续使用的结构化信息。
来源：