Lift Datalab: как вытащить структурированный JSON из PDF и сканов локально

Чтобы превратить PDF или скан в готовый JSON по своей схеме полей, поставь опенсорс-модель Lift от Datalab командой pip install lift-pdf, опиши нужные поля в JSON-схеме и прогони документ: lift_extract input.pdf ./output --schema schema.json. Это вижн-модель на 9B параметров: читает инвойсы, договоры, акты, сканы и отдаёт валидный JSON, который совпадает с твоей схемой за счёт schema-constrained decoding. Главное - она крутится локально, на одной видеокарте, и документы никуда не уходят. Для договоров и персональных данных это и есть решающий аргумент.

Дальше - что это за модель, реальные цифры с бенчмарка Datalab, точные команды установки и как из этого собрать автоматизацию, за которую бизнес платит.

Что такое Lift и чем он отличается от обычного OCR

Lift - это не OCR в привычном смысле. OCR (Tesseract и подобное) выдаёт сырой текст: буквы, цифры, кашу. Дальше ты сам пишешь регулярки, парсишь, ловишь крайние случаи. Lift работает иначе: ты даёшь ему документ и схему полей, которые хочешь получить, а он возвращает заполненный JSON.

Пример. Нужно из инвойса вытащить номер, дату, контрагента, сумму и список позиций. Описываешь это в JSON-схеме, скармливаешь PDF, получаешь:

{
  "invoice_number": "INV-2026-0412",
  "date": "2026-06-15",
  "vendor": "ООО Ромашка",
  "total": 148500.00,
  "items": [
    {"name": "Консультация", "qty": 3, "price": 45000},
    {"name": "Внедрение", "qty": 1, "price": 13500}
  ]
}

Ключевая штука - schema-constrained decoding. Декодер по ходу генерации режет всё, что не совпадает с твоей схемой: типы полей, структура, вложенность держатся на уровне самой генерации, а не проверяются постфактум. Поля, которых в документе реально нет, приходят как null, а не как выдуманные значения. Для разработчика это значит, что не нужно оборачивать вывод в десять try-catch и гадать, что там пришло.

Lift сделали те же ребята, что и Marker - известный опенсорс-инструмент для конвертации PDF в markdown. Контора не с улицы, у них репутация в document intelligence.

Честная оговорка: открытые веса слабее их же платного API. На бенчмарке Datalab хостовый API даёт 95.9% по полям против 90.2% у локальной Lift, плюс citations и проверку по полям. Если тебе нужна максимальная точность и не жалко отправлять документы в облако - есть платный вариант. Но смысл локальной модели как раз в том, что данные остаются у тебя.

Какие цифры показывает Lift на бенчмарке

Datalab прогнали модели на собственном бенчмарке из 225 документов (6-64 страницы каждый, около 11 000 проверяемых полей) с заранее заложенными ловушками: значения, размазанные по нескольким страницам, обязательно пустые поля, почти-совпадающие отвлекающие данные, агрегация из разных источников. Скоринг - детерминированный exact-match по эталону. Вот что вышло.

* На документ, 8 параллельных запросов. Локальные модели гнали через vLLM на одной видеокарте. Сам Datalab пишет: задержка зависит от железа и нагрузки, цифры стоит читать как относительные, не как абсолют.

Читается так: локальная опенсорс-модель на 9 миллиардов параметров отстаёт от облачного Gemini Flash 3.5 на 1.1 процентного пункта по точности полей, но по медиане работает почти втрое быстрее. И не отправляет твои документы в Google.

Не натягиваю сову на глобус: full-document accuracy (весь документ распознан полностью без единой ошибки) у Lift скромнее - 20.9% против 40% у Gemini. На длинных сложных документах он ещё ошибается. Но для большинства бизнес-задач важна точность по полям, а не идеальный разбор 64-страничного договора целиком. Если надо из тысячи инвойсов вытащить пять полей, 90% по полям - это рабочая лошадь.

Почему «локально» - это не гик-флекс, а деньги

Главный аргумент за Lift даже не точность. Он в том, что модель крутится у тебя на машине. Не на сервере Datalab, не в облаке Google, не у OpenAI. У тебя.

Когда ты гоняешь договоры, медкарты, паспортные данные, бухгалтерию клиентов через облачный API, ты эти данные кому-то отправляешь. Для многих компаний это просто запрещено: 152-ФЗ, NDA с клиентами, банковская тайна, врачебная тайна. Юрист или безопасник такую интеграцию завернёт на входе. А Lift ставится на свой сервер или даже на сервер клиента - air-gapped, без интернета вообще. Документы не покидают периметр.

Вот за это бизнес и платит. Не за «нейросеть», а за «разбор входящих документов без утечки на сторону». Локальная обработка снимает целый класс возражений, на которых разваливаются сделки с облачными решениями.

Как поставить и запустить Lift: реальные команды

Базовая установка (под бэкенд vLLM) - одной строкой:

pip install lift-pdf

Дальше два режима работы.

Через vLLM (рекомендованный самим Datalab, легче ставится - сначала поднимаешь сервер, потом гоняешь файлы):

lift_vllm                 # поднять сервер, по умолчанию настройки под H100
lift_vllm --gpu a100-80   # или подстроить под свою видеокарту

lift_extract input.pdf ./output --schema schema.json

lift_vllm поднимает Docker-контейнер и сам масштабирует размер батча под VRAM карты. В списке поддержки: h100, a100-80, a100, l40s, a10, l4, 4090, 3090, t4. То есть стартануть можно на домашней RTX, не арендуя кластер.

Локально через HuggingFace (всё на одной машине, но нужен torch - ставится отдельным экстра):

pip install lift-pdf[hf]
lift_extract input.pdf ./output --schema schema.json --method hf

Целая папка документов разом:

lift_extract ./documents ./output --schema schema.json --method hf

Полезные флаги: --page-range "0-5,7,9-12" чтобы взять конкретные страницы PDF, и --max-output-tokens чтобы ограничить длину ответа. На каждый файл lift_extract пишет в выходную папку <имя>.json с результатом и <имя>_metadata.json с числом страниц, токенов и инфой об ошибках.

Отдельно - Schema Studio, приложение на Streamlit, где можно собирать и тестировать схему прямо на своих документах, не лазая в JSON руками. Ставится своим экстра:

pip install lift-pdf[app]
lift_app

Лицензия двойная: код под Apache-2.0, веса модели под модифицированной OpenRAIL-M - бесплатно для исследований, личного использования и стартапов с выручкой или финансированием меньше $5M (и нельзя конкурировать с их API). Крупной конторе - читать условия на их странице с ценами, для них отдельная история.

Как написать схему полей для Lift

Схема - это обычный JSON Schema. Чем проще, тем надёжнее. Поддерживаются: строка, число, целое, булево, массивы из них, массивы объектов и вложенные объекты. Пример рабочей схемы под инвойс:

{
  "type": "object",
  "properties": {
    "invoice_number": {"type": "string", "description": "Номер счёта"},
    "date": {"type": "string", "description": "Дата в формате ГГГГ-ММ-ДД"},
    "vendor": {"type": "string", "description": "Название поставщика"},
    "total": {"type": "number", "description": "Итоговая сумма"},
    "items": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "name": {"type": "string"},
          "qty": {"type": "integer"},
          "price": {"type": "number"}
        }
      }
    }
  },
  "required": ["invoice_number", "total"]
}

Два правила из документации, которые экономят нервы:

1. Пиши description для любого поля, чьё имя неочевидно. Модель ориентируется на описание, как будто это инструкция человеку.
2. Помечай поле required только если оно обязано быть в документе. Поля, которых реально нет, вернутся null, и это нормально.

Чего избегать: enum, anyOf/oneOf, $ref, additionalProperties. Декодер их не компилирует и просто пропустит такую часть схемы, ослабив гарантию валидности.

Связка с Claude Code: автоматизация разбора входящих документов

Сам по себе Lift - это движок. Деньги начинаются, когда ты оборачиваешь его в пайплайн. Тут заходит Claude Code.

Логика простая. Lift достаёт данные из документа. Claude Code пишет вокруг него всю обвязку: следит за папкой входящих, дёргает Lift на каждом новом файле, валидирует JSON, кладёт строки в базу или Google Sheets, шлёт уведомление в Telegram, складывает разобранные документы в архив. Ты не пишешь этот код руками - описываешь задачу словами, а Claude Code собирает скрипт.

Типичный сценарий, который я бы собрал под клиента:

1. Бухгалтер кидает PDF-инвойсы в папку (или они падают на почту).
2. Скрипт ловит новый файл, прогоняет через Lift со схемой инвойса.
3. Готовый JSON улетает строкой в таблицу учёта.
4. Если сумма выше порога - уведомление ответственному.

Раньше это делал человек руками, по 2-3 минуты на документ. После автоматизации - секунды и ноль ручного ввода. Так же, как в гайде про свою CRM за час вместо amoCRM, где Claude Code собирает рабочий продукт под конкретный процесс, здесь он собирает конвейер разбора документов. За автоматизацию входящего документооборота бизнес платит порядка 15-60к рублей в месяц (это оценочная рыночная вилка, не прайс конкретной сделки) - потому что она снимает живого человека с тупой механической работы и не роняет данные в облако.

Если хочешь системно научиться ставить задачи Claude Code, чтобы он писал такие пайплайны без ошибок, начни с гайда про чёткий системный промпт - принцип тот же.

Частые вопросы

Lift реально бесплатный и опенсорсный?

Код - да, под лицензией Apache-2.0, лежит на GitHub (~317 звёзд на момент написания). Веса модели - под модифицированной OpenRAIL-M: бесплатно для исследований, личного использования и стартапов с выручкой или финансированием меньше $5M, и нельзя использовать конкурентно с их API. Модель доступна на Hugging Face. Крупным компаниям нужно смотреть условия отдельно на странице Datalab.

Какое железо нужно, чтобы запустить Lift локально?

Одна видеокарта. Модель на 9B параметров серверится через vLLM, и в списке поддерживаемых GPU есть как датацентровые H100/A100/L40S, так и потребительские RTX 4090, 3090 и даже T4. Точные требования по VRAM в README не указаны, но запуститься можно на домашней игровой карте, а не только на аренде в облаке.

Чем Lift лучше, чем просто отправить PDF в ChatGPT или Gemini?

Двумя вещами. Первое - данные не уходят на чужой сервер, документ обрабатывается локально, что критично для договоров и персональных данных. Второе - schema-constrained decoding держит JSON валидным по твоей схеме, тогда как обычная LLM может вернуть текст, сломанный JSON или выдуманные поля. По точности на полях Lift (90.2%) почти догоняет Gemini Flash 3.5 (91.3%) и при этом быстрее по медиане. Минус - на полностью безошибочном разборе длинных документов Lift пока уступает.

Lift распознаёт сканы и фотографии документов, или только цифровые PDF?

В README прямо сказано, что модель работает с PDF и изображениями документов - то есть со сканами тоже, не только с текстовыми PDF. Явного списка форматов картинок (PNG/JPG) в документации я не нашёл, так что под конкретный формат скана лучше проверить на своём файле.

За сколько Lift обрабатывает один документ?

По бенчмарку Datalab медианная задержка - 9.5 секунды на документ (на их сетапе: серьёзная видеокарта, 8 параллельных запросов). Это почти втрое быстрее, чем у облачного Gemini Flash 3.5 (28.1 с). Datalab отдельно отмечает, что задержка зависит от железа и нагрузки. На потребительском железе будет медленнее, но порядок тот же - секунды, а не минуты.

Вывод

Lift закрывает конкретную боль: превратить ворох PDF и сканов в чистые структурированные данные, не отправляя ни байта на сторону. Ставится одной строкой, работает на одной видеокарте, отдаёт валидный JSON по твоей схеме и по точности полей почти не уступает облачным моделям (уступая им на полном безошибочном разборе длинных документов). А если обернуть его в Claude Code, получается готовый конвейер разбора входящих документов - ровно то, за что бизнес платит ежемесячно.