Проверка PDF по страницам или целиком: что выбрать

Почему длинный PDF часто дает ошибки

Длинный PDF редко подчиняется одной логике от первой страницы до последней. В начале может быть аккуратный шаблон договора, дальше - приложение, потом скан, вставленная таблица или письмо в другом формате. Парсер сначала привыкает к одной структуре, а потом получает совсем другую.

Из-за этого одни и те же поля ищутся в разных местах. Реквизиты компании иногда стоят в шапке первой страницы, иногда мелким текстом внизу, а иногда вообще переезжают в приложение с подписями. Если система ждет ИИН, БИН, адрес или номер договора только в одном блоке, она спокойно пропустит их в другом.

Проблема становится заметнее, когда документ собрали из нескольких файлов. Первая часть может быть цифровой и чистой, а последние 20 страниц - скан с серым фоном, печатями и перекосом. OCR на таких страницах путает символы, съедает пробелы и ломает строки. В итоге БИН превращается в набор похожих знаков, а дата читается не так, как в оригинале.

С таблицами ошибок обычно еще больше. На одной странице есть заголовок колонок, на следующей его уже нет. Строка начинается внизу листа и заканчивается после переноса, а сверху и снизу добавляются колонтитулы, номера страниц и служебные пометки. Парсер легко принимает их за часть таблицы, и суммы или наименования съезжают в соседние столбцы.

Со сносками ситуация еще сложнее. Число в таблице выглядит понятным, но важное уточнение лежит мелким шрифтом внизу страницы или в конце приложения. Если читать только основной блок текста, можно забрать цифру без оговорки. Для финансовых документов это частая причина неверных выводов.

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

Типичный пример - договор на 60 страниц. Первые 8 страниц содержат основной текст, потом идет таблица тарифов, затем приложение с банковскими реквизитами, а в конце - скан подписанного листа. Если извлекать все одним проходом, система часто берет реквизиты не из финальной части, теряет продолжение таблицы и не замечает сноску под суммой. Поэтому при работе с многостраничными документами важно проверять не только текст, но и структуру.

Когда разбор по страницам работает лучше

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

Если в документе 80 страниц, но полезны только 12, нет смысла читать весь файл как один длинный текст. Проще сначала пройтись по страницам, понять их тип и убрать пустые листы, разделители, обложки и служебные вставки. Такой фильтр часто экономит и время, и деньги.

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

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

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

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

Представьте PDF, в котором лежат 25 актов и 5 сканов писем. Если читать документ целиком, модель может смешать суммы и даты из соседних актов. Если читать по страницам, она берет реквизиты отдельно с каждого бланка, а письма и пустые листы вы отсекаете в самом начале.

Когда стоит читать документ целиком

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

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

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

Примечания тоже редко живут отдельно. Сноска на странице 18 может уточнять ставку, сумму или срок, указанные на странице 12. Если читать только одну страницу, примечание висит в воздухе. Если читать весь файл, модель находит исходный пункт и связывает его с уточнением, а не додумывает смысл сама.

Разбор целиком полезен и тогда, когда на выходе нужен один итоговый объект по всему документу. Это частый случай для договоров, анкет, тендерных пакетов и отчетов. Там одни и те же поля повторяются, обновляются в приложениях или уточняются в конце, и простая склейка ответов по страницам дает слишком много мелких ошибок.

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

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

Как выбрать подход за пять шагов

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

Выбор лучше делать не по привычке, а по короткому тесту.

1. Сначала зафиксируйте, что именно вы ищете в файле. Не просто данные из документа, а конкретные поля: номер договора, дата, БИН, сумма, валюта, позиции таблицы, примечания под строками. Если поле почти всегда живет на одной странице, постраничный разбор часто дает более чистый результат.

2. Затем проверьте макет. Возьмите несколько документов и посмотрите, повторяется ли структура от страницы к странице. Если шапка, блоки реквизитов и таблицы стоят примерно на одних и тех же местах, постраничная схема обычно проще и дешевле. Если документ собран из разных шаблонов, лучше сразу тестировать чтение целиком.

3. Отдельно посчитайте проблемные страницы. Полезно не гадать, а отметить, на скольких листах таблица рвется переносом, сноска уходит вниз, а продолжение мысли появляется только через страницу. Если таких мест много, модель без общего контекста начнет путать строки, дублировать ячейки или терять примечания.

4. Дальше нужен небольшой прогон на реальных данных. Возьмите 20-30 документов и пропустите их двумя способами: по страницам и целиком. Если вы сравниваете несколько моделей, удобнее делать это через один совместимый слой. Например, в AI Router можно менять маршрут и base_url на api.airouter.kz, не переписывая SDK, код и промпты под каждого провайдера.

5. В конце сравните не только точность. Смотрите сразу на три вещи: сколько полей система пропустила, сколько стоит обработка одного документа и как долго идет ответ. Иногда чтение целиком дает на 2-3% лучшее извлечение, но задержка вырастает вдвое. Для поточного ввода это уже плохой обмен.

На практике решение часто бывает смешанным. Реквизиты и короткие блоки берут по страницам, а длинные таблицы и примечания проверяют целиком или на связке соседних страниц. Для договоров с приложениями это обычно самый спокойный вариант.

Как доставать реквизиты без лишних пропусков

Больше всего пропусков бывает не в середине документа, а в тихих местах: в шапке, в блоке подписей и в приложениях. В договоре номер и дата часто стоят на первой странице, БИН и банковские данные - в конце, а полное название юрлица или сумма по этапам - в приложении. Если искать реквизиты только в одном месте, часть полей почти наверняка потеряется.

Рабочее правило простое: для каждого поля задайте несколько зон поиска. Для даты это может быть шапка и подпись. Для суммы - предмет договора, таблица приложения и акт. Для реквизитов компании - раздел "Стороны", подписи и отдельное приложение с банковскими данными.

После извлечения сразу приводите значения к одному виду. Иначе система считает, что перед ней разные данные, хотя смысл один и тот же. Дату в формате "12.03.2025" и "2025-03-12" лучше свести к одному шаблону. БИН и ИИН стоит хранить как строки из 12 цифр, без пробелов и лишних символов. Суммы полезно очищать от пробелов в разрядах, а валюту приводить к одному обозначению, например KZT или USD.

Нормализация особенно важна, если документ разбирается по страницам. На одной странице модель может вернуть "12 500 000 тг", на другой - "12500000 KZT". Без приведения к одному виду вы не поймете, что это одна и та же сумма.

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

Ручная проверка нужна чаще, чем кажется. В теле договора может стоять одна сумма, а в приложении после правок - другая. Или БИН в подписи записан верно, а в шапке осталась старая версия из шаблона. В таких случаях не стоит угадывать правильный ответ. Лучше пометить значение как спорное и показать оператору оба варианта.

Если команда прогоняет многостраничные документы через LLM-конвейер, полезно сохранять confidence score и page reference для каждого реквизита. Это сильно упрощает разбор ошибок: видно не только итог, но и источник каждого поля.

Что делать с таблицами и примечаниями

Таблицы и сноски ломают разбор PDF чаще, чем обычный текст. Особенно это заметно в договорах, актах и приложениях на 30-50 страниц, где одна таблица тянется через несколько листов, а пояснение к сумме или сроку уходит вниз страницы мелким шрифтом.

Если таблица переходит на новую страницу, не считайте первую строку на следующем листе новой записью автоматически. Сначала проверьте, не обрезалась ли строка на предыдущей странице. Обычно это видно по пустой первой колонке, повтору рамок, одинаковому номеру позиции или по тому, что текст в ячейке начинается с середины фразы. В таких случаях строки лучше склеивать до поиска реквизитов.

Колонтитулы мешают почти всегда. Фразы вроде "Страница 12 из 48", название документа, дата печати и пометки вроде "Продолжение таблицы" легко принять за отдельную колонку или часть ячейки. Поэтому их лучше убирать до анализа структуры. Иначе парсер начинает видеть лишние столбцы, а суммы и даты сдвигаются.

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

Со сносками лучше работать отдельно от основного текста таблицы. Если в ячейке стоит "*", "1" или маленький верхний индекс, сохраните эту метку и найдите ее расшифровку внизу страницы или после таблицы. Потом свяжите пояснение с конкретной ячейкой. Иначе примечание "цена без НДС" может случайно приклеиться ко всей таблице, хотя относится только к одной строке.

Служебные пометки не стоит смешивать с данными. "Подпись", "М.П.", "конец таблицы", отметки согласования и внутренние коды часто стоят рядом, но к содержимому таблицы не относятся. Их лучше хранить отдельно или сразу отфильтровать по шаблону.

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

Пример на договоре с приложениями

Обычный договор на 40-60 страниц хорошо показывает, почему один и тот же PDF иногда стоит читать разными способами. На первых 3-5 страницах обычно лежат самые важные реквизиты: кто подписывает документ, номер договора, дата, срок действия. Дальше часто идут приложения, где сидят таблицы услуг, объемов и сумм. Внизу страниц или мелким шрифтом прячутся сноски с исключениями.

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

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

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

Представьте договор на обслуживание с приложением на 12 страниц. На второй странице указаны ТОО "Альфа" и ТОО "Бета", номер 17/24 и дата 15 марта. В приложении есть таблица из 18 услуг. Внизу трех страниц стоят примечания: ночные выезды считают отдельно, расходники не входят в цену, скидка действует только при оплате за квартал. Если собрать только таблицу, итог получится аккуратным, но неверным. Если читать только начало договора, вы получите реквизиты без денег.

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

Частые ошибки

Самая частая ошибка проста: длинный PDF отправляют в модель как один ровный кусок текста. На коротком счете это иногда сходит с рук. На договоре на 80 страниц такой подход ломает логику документа: реквизиты смешиваются с приложениями, суммы - со штрафами, а сноски - с основным текстом.

Даже если вы выбрали проверку PDF по страницам, ошибки сами не исчезают. Они просто меняют форму. Модель может хорошо видеть один лист, но потерять связь между соседними страницами, где строка таблицы началась сверху, а закончилась уже после разрыва.

Чаще всего разбор ломается еще до модели - на входных данных. Повернутая страница, бледный скан, плохой OCR или сдвинутые блоки текста портят результат еще до извлечения реквизитов из PDF.

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

Одна из самых дорогих ошибок - вытаскивать число без контекста. Если в документе есть "Сумма договора", "Сумма НДС" и "Общая сумма к оплате", первая найденная цифра почти никогда не дает надежный ответ. Нужны соседний текст, подпись поля и иногда даже раздел документа.

С таблицами та же история. Если строка начинается на одной странице, а на следующей идет ее хвост, обычный постраничный разбор часто делает две строки вместо одной. Потом сумма по таблице не сходится, и документ приходится проверять вручную.

Отдельно стоит смотреть на примечания. В сканах легко спутать авторское примечание документа с внутренним комментарием вроде "уточнить у юристов". Для бизнеса это разные сущности. Первое может влиять на условия, второе вообще не должно попадать в итоговые данные.

Хорошее правило одно: не доверяйте первому совпадению. Сверяйте поле с заголовком раздела, соседними строками и типом страницы. Это занимает немного больше времени, зато заметно снижает число ложных попаданий.

Короткая проверка перед запуском

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

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

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

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

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

Для таблиц смотрите не только на факт извлечения, но и на структуру. Если система нашла 9 строк из 10, это уже не то же самое, что полное совпадение. Для примечаний полезно отдельно отмечать, нашелся ли сам текст и сохранилась ли его привязка к нужной строке или пункту.

Спорные места не нужно автоматизировать любой ценой. Оставьте ручную проверку там, где файл плохого качества, таблица рвется между страницами или сноска меняет смысл суммы. На старте это дешевле, чем потом исправлять ошибки в учете. Если вы гоняете такие тесты через единый шлюз вроде AI Router, сравнивать модели проще: набор файлов не меняется, а результат видно по конкретным полям, а не по общему впечатлению.

Что делать дальше

Не выбирайте подход на глаз. Возьмите одну и ту же выборку из 20-30 длинных PDF и прогоните ее в двух режимах: по страницам и целиком. Сравнивайте не только общий процент успеха, но отдельно реквизиты, таблицы и примечания. Часто схема, которая лучше на первой странице, хуже держит связи между приложением, сноской и основной таблицей.

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

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

Если команда сравнивает несколько LLM, лучше не переписывать интеграции под каждую модель. Проще держать один совместимый API-слой и быстро переключать маршруты. В этом сценарии AI Router выглядит практично: можно заменить base_url на api.airouter.kz и тестировать разные модели через один OpenAI-совместимый эндпоинт, не меняя существующий код.

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

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