Как обработать PDF через API нейросети

Модель не читает PDF — она читает текст. Между файлом и запросом всегда стоит шаг извлечения, и именно он определяет качество ответа сильнее, чем выбор модели: из документа с двумя колонками наивный разбор даёт перемешанные строки, из таблицы — набор чисел без привязки к столбцам, из скана — ничего. Дальше встаёт второй вопрос: документ на двести страниц не помещается в один запрос и не должен туда помещаться, даже когда влезает. Разбираем весь путь — извлечение, разбиение, таблицы, сканы, — и считаем, во что это обходится по токенам.

Почему PDF — это не текст

Причина в устройстве формата, и она объясняет все дальнейшие сложности.

PDF описывает, где на странице нарисовать какой символ. Не «абзац», не «заголовок», не «ячейка таблицы» — координаты и глифы. Структуру документа человек достраивает глазами, а извлекающая программа вынуждена угадывать.

Отсюда типовые поломки, которые видит каждый:

Колонки склеиваются. Текст в две колонки читается построчно через всю страницу, и предложения перемешиваются.

Колонтитулы попадают в середину. Номера страниц и названия разделов оказываются посреди абзацев.

Таблицы рассыпаются. Числа извлекаются, связь со столбцами теряется. Модель видит поток цифр и уверенно относит их не туда.

Переносы разрывают слова. Слово, перенесённое по слогам, становится двумя.

Практический вывод: посмотрите глазами на извлечённый текст, прежде чем винить модель. В половине случаев проблема видна сразу и лечится другим извлекателем, а не другим запросом.

Сканы — отдельная история

Здесь важно понимать, что задача другая по сути.

Скан — это картинка страницы. Текста в файле нет вообще, извлекать нечего. Нужен отдельный шаг распознавания, и он вносит собственные ошибки: спутанные цифры, потерянные строки, неверно прочитанные подписи.

Главная опасность в том, что ошибки распознавания дальше идут в модель как факты. Модель не знает, что «1 250» на самом деле было «1 260», — она просто ответит на основе того, что получила, и ответ будет уверенным.

Отсюда правило для документов с числами: сверяйте ключевые значения с оригиналом, а не полагайтесь на цепочку «скан → распознавание → модель». Для сумм, дат и идентификаторов это обязательный шаг, а не перестраховка.

Рынок специализированных моделей под документы растёт — мы писали про компактную модель распознавания документов. Но принцип не меняется: распознавание остаётся отдельным шагом со своей точностью, и её надо измерять на своих документах.

Разбиение на части

Второй большой вопрос: что делать с объёмом.

Даже когда документ помещается в контекст целиком, подавать его целиком — обычно плохая идея. Причин две: вы платите за весь объём при каждом обращении, и качество ответа на длинном контексте не растёт линейно с его размером — сколько контекста реально нужно.

Разумная схема зависит от задачи.

Задача про весь документ (пересказ, общий вывод): разбить на части, обработать каждую отдельно, затем свести промежуточные результаты. Дороже одного запроса по числу вызовов, дешевле по объёму.

Задача про фрагмент (найти условие, проверить пункт): не подавать документ вовсе. Найти релевантные куски и отправить только их — это поиск по своим документам, и качество поиска здесь решает всё.

Задача про сравнение (что изменилось между версиями): сравнивать программно, а модели отдавать только различия.

Про границы частей стоит сказать отдельно: режьте по смыслу, а не по числу символов. Разрыв посреди пункта договора или посреди таблицы делает обе половины бесполезными. Заголовки, абзацы и разделители — естественные места разреза.

Сколько это стоит

Считаем, потому что документы — самый быстрый способ незаметно увеличить счёт.

Страница плотного текста — ориентировочно от нескольких сотен до полутора тысяч токенов. Точнее сказать нельзя: зависит от плотности и языка, причём кириллица расходует больше токенов, чем латиница, — как считать токены.

Из этого следуют две вещи, которые обычно выясняются постфактум.

Документ на двести страниц — это крупный запрос. Один такой вызов может стоить дороже, чем весь остальной день работы сервиса.

Повторные вопросы по одному документу удваивают счёт. Если вы подаёте документ заново при каждом вопросе, вы платите за него каждый раз. У всех текстовых позиций нашего каталога кэш промптов не поддерживается, то есть скидки за повторный контекст здесь нет.

Отсюда практический приём: для сценария «много вопросов по одному документу» правильная схема — один раз разобрать и проиндексировать, дальше подавать только найденные фрагменты. Она же оказывается и точнее.

Порядок, который работает

Шесть шагов, если вы делаете это впервые.

1. Извлеките текст и посмотрите на него глазами. До всякой модели. Половина проблем видна здесь.
2. Уберите мусор. Колонтитулы, номера страниц, повторяющиеся шапки. Они занимают токены и сбивают модель.
3. Решите, нужен ли весь документ. Обычно нет.
4. Разбейте по смыслу. Заголовки и абзацы, а не фиксированная длина.
5. Просите структуру, а не пересказ. Ответ полями надёжнее и проверяемее — как получить строгий формат.
6. Проверяйте числа. Всё, что попало в ответ из документа и важно, сверяйте с исходником программно.

Шестой пункт — граница между демонстрацией и рабочим сервисом. Модель не отличает верное значение от испорченного при распознавании, и эту проверку никто, кроме вашего кода, не сделает.

Про чужие документы

Короткое, но важное предупреждение.

Документ, пришедший извне, — это чужой текст в вашем контексте. Инструкцию в нём можно спрятать так, что человек не заметит, а модель прочитает как команду.

Если разбор документов у вас связан с какими-то действиями — отправкой писем, изменением записей, вызовом функций, — считайте содержимое документа недоверенным вводом. Это тот же принцип, что и с любыми внешними данными, просто здесь его забывают чаще.

Что делать с таблицами

Таблицы заслуживают отдельного разговора: это самая частая причина уверенно неверных ответов по документам.

Проблема в том, что при извлечении теряется связь между числом и его столбцом. Человек видит сетку, программа — последовательность значений. В результате модель получает поток цифр и относит их к заголовкам так, как считает логичным, — а логично не всегда правильно.

Что помогает:

Извлекать таблицы отдельно от текста. Не общим проходом по странице, а инструментом, который понимает границы ячеек и отдаёт структуру.

Переводить таблицу в явный формат. Строки с подписанными полями надёжнее, чем выровненные пробелами столбцы: у модели не остаётся места для интерпретации.

Не отдавать модели арифметику. Если по таблице надо посчитать сумму или долю, считайте это в своём коде. Модель может ошибиться в вычислении, и ошибка будет выглядеть так же уверенно, как правильный ответ.

Проверять итоги. Если в документе есть строка «итого», сравнивайте её со своим расчётом. Расхождение — сигнал, что таблица извлеклась неверно.

Последний пункт полезен и как приёмка качества всего конвейера. Документ, где итоговая строка сошлась, скорее всего извлёкся правильно целиком; документ, где не сошлась, дальше пускать нельзя независимо от того, насколько убедительно выглядит ответ модели.

Чего мы не утверждаем

Не рекомендуем конкретные библиотеки извлечения. Их много, качество зависит от типа документов, и выбирать нужно на своих файлах.

Не даём точных цифр по токенам на страницу. Разброс велик, ориентир выше — грубый.

Не обещаем распознавания сканов через каталог. Это отдельный шаг вне API модели; поддержку конкретных возможностей проверяйте в живой выдаче под свою задачу.

И практическое замечание про приёмку: заведите десяток документов, на которых конвейер точно работает правильно, и прогоняйте их после каждого изменения. Извлечение — самая хрупкая часть цепочки: смена библиотеки или новый тип документа ломает то, что работало, а заметно это становится только по неверным ответам недели спустя.

Что держать в голове

Модель читает текст, а не PDF. Качество извлечения определяет результат сильнее, чем выбор модели, и посмотреть на извлечённый текст глазами — самый дешёвый способ найти проблему.

Второе: подавать документ целиком почти никогда не нужно. Разбиение по смыслу и поиск нужных фрагментов дают ответ и точнее, и дешевле.

Как мы проверяем факты и что храним из запросов — на странице о проекте и в llms.txt. Проверить разбор своих документов по одному ключу: keydealer.ru/login.