Что такое Dharma Field Extractor и зачем он нужен поверх OCR
Dharma-AI выпустила Dharma Field Extractor: модель на 2 млрд параметров, которая принимает изображение документа и отдаёт структурированный JSON с нужными полями. База - DharmaOCR-LITE v1.1, поверх неё добавлен LoRA-адаптер, обученный на 43 384 примерах. Режимы работы и примеры вывода описаны в анонсе Dharma-AI на Hugging Face.
Один чекпоинт обслуживает счета, медицинские направления, удостоверения и формы без дообучения под каждый тип. Разработчики заявляют 0,834 field-level F1 на наборе из 546 документов и 1 638 кейсов. Для сравнения: протестированные frontier-конфигурации показали 0,816 (Claude Opus 5) и 0,741 (GPT-5.6 Luna).
Практическая суть сводится к одному: из пайплайна убирают слой ручного маппинга текста в поля. Дальше разбираем, как это устроено, где границы применимости и что проверить перед пилотом на своих документах.
Почему OCR сам по себе не решает задачу извлечения полей
OCR возвращает всё напечатанное на странице, строка за строкой, и не говорит, какая строка относится к какому полю. Где тип экзамена, где дата, где итоговая сумма, модели неизвестно. Кто-то всё равно пишет код, который сопоставляет значения с ключами.
Возьмите счёт. Строки «Итого 12 400,00» и «НДС 20%» распознаны безупречно, а пайплайну нужны total и vat с числовым типом. Обычные варианты решения: регулярки, шаблоны под каждый формат, универсальная LLM с промптом. Регулярки ломаются от смены вёрстки, шаблоны требуют сопровождения, промпт на большой модели даёт плавающий JSON.
Field Extractor закрывает именно этот слой: возвращает типизированный JSON, поле за полем, с вложенностью там, где вложен документ. Счёт приходит со всеми позициями как упорядоченный список, у каждой позиции своё количество и стоимость, плюс итоги. Удостоверение возвращается полями под именами, которые система заказчика уже использует. Это заявленное поведение из описания релиза.
На какой базе построена модель: DharmaOCR-LITE v1.1 и LoRA-адаптер
DharmaOCR-LITE специализирована на OCR по широкому спектру документов: контракты, судебные материалы, счета, удостоверения, формы. Field Extractor не обучали с нуля: взяли v1.1 и нарастили LoRA-адаптер на 43 384 примерах извлечения полей. Логика прозрачная: сначала качественная транскрипция, затем маппинг в поля на той же компактной базе, без второго поставщика в цепочке.
Само семейство DharmaOCR описано как пара специализированных малых языковых моделей для структурированного OCR, которые вместе улучшают качество транскрипции, стабильность генерации и стоимость инференса (arXiv 2604.14314). Отсюда и ставка на 2 млрд параметров: задача узкая, платить за универсальность модели на 70B незачем.
Два режима работы: open и schema-directed
Режим задаётся запросом. В open схема не передаётся вообще, в schema-directed передаётся точная схема с типами. От выбора зависит стабильность ключей и объём постобработки.
| Параметр | Open | Schema-directed |
|---|---|---|
| Схема на входе | нет | есть, поле за полем |
| Типы значений | определяются моделью | string, number, boolean |
| Имена ключей | не гарантированы между документами | заданы системой заказчика |
| Отсутствующее поле | может не появиться в ответе | возвращается как null |
| Где применять | разведка нового корпуса | продакшн-пайплайн |
Open-режим: когда схема ещё неизвестна
Модель читает страницу, сама решает, какие её части выглядят как структурированные поля, и возвращает найденное в виде key-value пар. Сценарий: пришёл новый тип документа, состав полей неизвестен, нужно быстро увидеть, что в нём вообще есть. Через пару десятков страниц становится понятно, какие ключи повторяются, а какие случайны.
Ограничение важное: набор ключей между документами не гарантированно совпадает. Для автоматической записи в базу результат open-режима приходится нормализовать в собственную схему. Считайте его инструментом разведки корпуса, а не контрактом для продакшна.
Как может выглядеть ответ по счёту (значения иллюстративные, это не данные бенчмарка):
{
"invoice_number": "A-1042",
"invoice_date": "2026-10-14",
"supplier": "ООО Пример",
"total": 12400.00,
"line_items": [
{"description": "Консультация", "quantity": 2, "value": 5000.00}
]
}Schema-directed: точная схема с типами и null для отсутствующих полей
Здесь передаётся схема: имена ключей, которые уже используются в вашей системе, и тип для каждого поля - string, number или boolean. Ответ приходит ровно с этими ключами, с вложенными структурами и с null там, где поля в документе нет.
Три практических эффекта. Лишние ключи не появляются, так что валидация не спотыкается о неожиданные поля. null отличим от пустой строки, поэтому «данных нет» не путается с «данные пустые». Вложенность повторяет структуру документа, и позиции счёта не приходится разбирать из плоского списка строк.
{
"supplier_name": "ООО Пример",
"invoice_number": "A-1042",
"total": 12400.00,
"paid": false,
"due_date": null,
"line_items": [
{"description": "Консультация", "quantity": 2, "value": 5000.00}
]
}Практический совет: имена ключей берите из существующей схемы базы или API, а не придумывайте новые. Каждый синоним вроде total_amount вместо total означает ещё один маппинг, который потом кто-то будет поддерживать.
Бенчмарк: 0,834 field-level F1 и сравнение с frontier-LLM
Заявленные цифры: 546 документов, 1 638 кейсов, метрика field-level F1.
| Конфигурация | Field-level F1 |
|---|---|
| Dharma Field Extractor (2B) | 0,834 |
| Claude Opus 5 | 0,816 |
| GPT-5.6 Luna | 0,741 |
Что показывает field-level F1 и почему документного accuracy недостаточно
Document-level accuracy отвечает на вопрос «документ обработан верно или нет» и скрывает масштаб потерь. Если в счёте из двенадцати полей потеряна одна позиция, документ всё равно считается провальным, но непонятно, насколько именно. Field-level F1 считает precision и recall по отдельным полям: пропущенное поле режет recall, выдуманное лишнее - precision.
Иллюстрация механики, не данные бенчмарка. В эталоне три поля: номер, сумма, дата. Модель вернула номер и сумму, дату потеряла, лишнего не добавила. Precision = 2/2 = 1,0, recall = 2/3 = 0,67, F1 ≈ 0,8. Документ формально провален, но цифра показывает, что провал частичный, и это удобно для приоритизации доработок.
Любые вендорские метрики полезно сверять с тем, как устроены открытые бенчмарки: например, locallm.top собирает результаты локальных моделей с оценкой экспертов по доменам, без LLM-as-judge. Разница между закрытым внутренним набором и открытой методикой видна сразу.
Насколько корректно сравнивать 2B-модель с frontier-API
Скепсис понятен: «малая модель обошла Opus» звучит как рекламный заголовок. На узкой задаче преимущество объяснимо. Формат выхода жёсткий (JSON по схеме), домен ограничен, LoRA-адаптер обучен на 43 384 размеченных примерах именно этого действия. Frontier-модель тратит ёмкость на общий язык, инструкции и рассуждения, которые при извлечении полей не нужны.
Разрыв с Claude Opus 5 небольшой: 0,834 против 0,816, то есть 0,018 в абсолютных единицах. С GPT-5.6 Luna разница заметнее, 0,741. Осторожность здесь уместна: сравнивались протестированные Dharma-AI конфигурации, а не все существующие модели и не все возможные промпты. Настройки и формулировка промпта у frontier-моделей влияют на результат сильнее, чем хотелось бы. Независимой проверки этих цифр нет, полная методика расчёта field-level F1 и состав набора из 546 документов в доступных материалах не раскрыты.
Похожая логика работает и в общих сравнениях открытых и закрытых моделей: точную дату паритета назвать нельзя, зато можно понять, где локальные модели уже практичны. На извлечении полей этот момент наступил: задача достаточно узкая, чтобы 2B-модель конкурировала с API.
Стоимость: в 6-147 раз дешевле на self-hosted L40S
Разработчики заявляют, что на своей GPU NVIDIA L40S инференс обходится в 6-147 раз дешевле протестированных frontier-конфигураций (анонс релиза). Диапазон широкий, и это честный сигнал: разница зависит от объёма потока, выбранной конфигурации и тарифа API, с которым идёт сравнение. Абсолютных долларовых значений в источниках нет, поэтому для своего кейса придётся считать самому.
Что нужно для запуска на своей GPU
Класс 2B означает умеренные требования к видеопамяти на фоне 7B и больше. Конкретных замеров VRAM и пропускной способности для Field Extractor в доступных материалах нет, так что ориентируйтесь на общие требования vision-language моделей этого размера и на квантование. Потребительские GPU в теории подходят, гарантий без реальных замеров давать нельзя - на L40S считали стоимость, не скорость.
Отдельно стоит планировать хранение весов, версионирование чекпоинта и обновление LoRA-адаптера. Это инфраструктурная работа, которая в сравнении «API против своего железа» часто теряется.
Когда self-hosting выгоднее API, а когда нет
Критерии простые и считаются по вашему потоку. Объём документов в месяц, требования к приватности, наличие GPU и людей, которые будут это сопровождать, стабильность форматов на входе. Большой поток однотипных счетов с требованием не выпускать документы за периметр - сценарий, где локальная 2B-модель выглядит разумно. Маленький поток или часто меняющиеся типы документов - универсальный API с промптом может оказаться дешевле в разработке, даже при более высокой цене за токен.
Полезно держать в голове контраргумент: локальный запуск не всегда дешевле облачных API, если считать железо, электричество и время инженеров. Заявленные 6-147 раз относятся к стоимости инференса, а не к полной стоимости владения. Экономия появляется, когда GPU уже загружена другими задачами или когда альтернатива - не подписка, а интеграция с внешним провайдером и согласования по данным.
Кому подходит Field Extractor и какие у него ограничения
Типы документов, на которых модель заявлена
Список из анонса: счета, медицинские направления, удостоверения, формы. Базовая DharmaOCR-LITE дополнительно описана на контрактах и судебных материалах. Расширять этот перечень самостоятельно не стоит: за его пределами качество никем не проверено.
Свойство «один чекпоинт без дообучения под каждый тип» - заявленная характеристика, а не гарантия идеального результата на любом новом документе. Реальная проверка - прогон на вашем корпусе.
Где специализированная модель проигрывает универсальной LLM
Есть классы задач, где узкая модель просто не тот инструмент. Документы с длинными свободными формулировками, где нужно понять смысл условия, а не вытащить значение. Запросы, где требуется объяснить решение или ответить на вопрос по содержанию документа. Форматы, которых не было в обучающем наборе и которые меняются каждые пару месяцев.
В этих случаях frontier-LLM с большим контекстом и общими знаниями уместнее, несмотря на цену за токен. Если нужна универсальность при низкой стоимости, стоит смотреть и на открытые модели общего назначения: DeepSeek V4 Flash при цене $0.09 за миллион токенов закрывает более широкий круг задач, хотя специализированной точности на извлечении полей никто не обещает.
Ещё ограничение: обучение на 43 384 примерах задаёт домен. Если ваши документы заметно отличаются от типовых счетов и направлений, ошибки будут накапливаться на редких полях - как раз на тех, ради которых всё затевалось.
Практика: как встроить Field Extractor в пайплайн
- Соберите 20-50 реальных документов своего типа, включая неполные и плохие сканы.
- Прогоните их в open-режиме и посмотрите, какие поля модель находит сама, а какие сливаются в один ключ.
- Зафиксируйте схему с именами ключей из своей базы и типами string, number, boolean.
- Перейдите в schema-directed и проверьте, как обрабатываются отсутствующие поля и вложенные списки.
- Оцените точность вручную по своей выборке, не полагаясь только на цифры вендора.
Как описать схему, чтобы не переписывать маппинг
Имена ключей - ровно те, что уже используются в системе. Типы - минимально достаточные: number для сумм и количеств, boolean для флагов вроде paid, string для идентификаторов, даже если они выглядят числовыми: ведущие нули в номерах документов иначе пропадут.
Вложенность повторяйте за документом: позиции счёта - список объектов с quantity и value, а не плоское поле items_text. Отсутствующие поля оставляйте как null, чтобы отличать отсутствие данных от пустой строки. И не добавляйте в схему поля, которых в документе не бывает: модель начнёт искать их там, где искать нечего.
На что смотреть при пилоте
Набор метрик для приёмки: доля документов, где извлечены все обязательные поля; доля ошибок по критичным полям (суммы, даты, номера); стабильность ключей между запусками на одном и том же документе; поведение на повреждённых и неполных файлах. Отдельно прогоните документы, которые визуально отличаются от типовых: другой шрифт, скан под углом, рукописные пометки.
Если на своём корпусе точность заметно ниже 0,834, это сигнал, что домен вышел за пределы обучающего распределения. Тогда вариантов два: расширять схему и нормализовать вывод либо брать более универсальную модель с большим контекстом.
Технический фундамент: что стоит за DharmaOCR
В статье про DharmaOCR описаны Full (7B) и Lite (3B): они набирают 0,925 и 0,911 на DharmaOCR-Benchmark при доле дегенераций 0,40% и 0,20% соответственно. Field Extractor построен на DharmaOCR-LITE v1.1 с 2 млрд параметров, поэтому эти цифры описывают OCR-задачу семейства, а не field-level F1 самой Field Extractor. Материал подписали Gabriel Pimenta de Freitas Cardoso, Paulo Henrique de Medeiros Araujo, Bruno Duarte и Francisco de Almeida Rocha Alves (arXiv 2604.14314).
Почему зацикливание OCR критично для JSON-выхода
Если модель на этапе транскрипции зацикливается и повторяет фрагмент, структурированный выход разваливается: JSON становится невалидным или поля дублируются. Для пайплайна это не косметика, а падение обработки.
Авторы DharmaOCR применили Direct Preference Optimization, используя дегенеративные генерации как отклонённые примеры, чтобы штрафовать зацикливание. По их данным, это первое применение DPO для OCR, и оно снижает долю дегенераций до 87,6% относительно. Практический вывод: стабильная транскрипция - предпосылка корректного JSON, и специализированная база даёт её дешевле, чем универсальная модель с промптом «сделай OCR и выведи JSON».
AWQ-квантование и стоимость инференса
В DharmaOCR AWQ-квантование снижало стоимость до 22% на страницу с пренебрежимо малой потерей качества (arXiv 2604.14314). Для Field Extractor таких замеров в доступных материалах нет, поэтому рассматривайте квантование как направление, которое надо проверять на своём корпусе: 4-битные веса могут по-разному влиять на точность извлечения редких полей.
Вывод: стоит ли смотреть на Field Extractor
Аргументы за: узкая задача решена специализированной моделью, JSON приходит под вашу схему с типами и null, один чекпоинт покрывает счета, медицинские направления, удостоверения и формы. 0,834 field-level F1 против 0,816 у Claude Opus 5 и 0,741 у GPT-5.6 Luna, стоимость на L40S ниже в 6-147 раз по заявлению разработчиков.
Аргументы против: бенчмарк внутренний, независимых замеров нет, методика расчёта F1 не раскрыта, домен ограничен обучающим набором. Сравнение идёт с протестированными конфигурациями, а не со всеми моделями на рынке.
Практический вывод простой. Если у вас стабильный поток однотипных документов и требования не выпускать их за периметр, берите 30-50 своих файлов, прогоняйте в open-режиме, фиксируйте схему под ключи своей базы и считайте точность руками. Такая проверка за пару дней даёт больше, чем любая таблица с чужими цифрами. Если же задача разовая или документы сильно нестандартные, универсальная LLM с большим контекстом остаётся разумным выбором.