Глава 2 — Интеллектуальный парсинг документов

Второй пост поглавного разбора LLM Primer III: Enhancing Enterprise AI with RAG. Поисковая система наследует качество своих входов — а слой входа тихо хранит самую частую причину разочаровывающего качества RAG.

Почему существует эта глава

Первая версия RAG-пайплайна почти всегда использует ту утилиту PDF-to-text, что лежала под рукой. Похожий на правду текст выходит, индекс наполняется, модель выдаёт правдоподобные ответы. Через несколько месяцев команда обнаруживает, что таблицы тихо сплющены в прозу, многоколоночные статьи переплетены построчно, сноски вшиты в абзацы, а подписи к рисункам исчезли вовсе. Потолок качества поиска был задан этими решениями ещё до настройки поиска. Глава о том, чтобы отнестись к слою входа всерьёз — потому что ничего ниже по потоку не восстановит того, что выбросил парсер.

Если коротко: PDF — это спецификация позиционирования, а не текстовый файл, и парсер, не понимающий макет, даёт транскрипт файла, а не транскрипт документа.

2.1 Почему «расплющивание» PDF теряет самое важное

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

С таблицами хуже. Смысл числа 1 427 в строке 3, колонке 4 — пересечение 3 кв. 2024 и Северо-Восточного региона. Для наивного экстрактора это число без связи с обеими строками, потому что строки были нарисованы в другом месте страницы. Таблица растворяется в список чисел через пробел, и запрос про «выручку Северо-Востока в 3 квартале» не находит ничего — чанк с числом 1 427 не содержит «Северо-Восток» достаточно близко, чтобы эмбеддинг их связал. У форм аналогичный режим отказа: подписи и значения выходят как несвязанные строки, и в индексе теперь значения без названий полей. OCR по сканам добавляет посимвольные ошибки именно на технических терминах и собственных именах — там, где поиск чувствительнее всего к написанию.

2.2 Парсинг с учётом макета: возвращая сигналы

Ответ — класс инструментов, которые рассматривают документ как двумерный артефакт, а не как поток глифов. Страница отрисовывается в изображение, модель детекции макета сегментирует её на области (абзацы, таблицы, рисунки, заголовки), порядок чтения восстанавливается эвристиками макета, а таблицы пропускаются через специализированные модели, восстанавливающие структуру строк и колонок в HTML, Markdown или JSON. Выход — не плоская строка, а структурное представление, сохраняющее иерархию, связывающее подписи с рисунками и выставляющее метаданные, по которым может работать следующий за ним чанкер.

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

2.3 Текущий ландшафт инструментов

Пространство уплотнилось вокруг полудюжины инструментов, которые стоит знать. LlamaParse — хостинговый парсер от LlamaIndex; силён на таблицах и формах, правильный дефолт, если вы уже внутри экосистемы LlamaIndex и managed-сервисы приемлемы. Docling — open-source парсер с учётом макета от IBM, с моделью TableFormer для сложных таблиц, естественный выбор для on-premises развёртываний, где данные не должны покидать инфраструктуру. Unstructured оптимизирован под широту — много входных форматов, типизированная модель разметки элементов, единый интерфейс на выходе — самый безопасный первый выбор для разнородных корпоративных корпусов. Marker-PDF делает одно очень хорошо: PDF в чистый Markdown с особым вниманием к заголовкам, спискам и блокам кода. Firecrawl решает веб-сторону задачи входа — URL на входе, чистый Markdown на выходе, шаблонная вёрстка убрана. DeepSeek-OCR, выпущенный в конце 2025 года, кодирует страницы в очень малое число vision-токенов с существенно меньшими расходами памяти и вычислений и оказывается серьёзным кандидатом, когда главный бюджет — пропускная способность.

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

2.4 Мультимодальная альтернатива

Параллельный трек отвергает саму рамку. Если визуально-языковая модель способна прочитать страницу достаточно, чтобы отвечать о ней, зачем вообще конвертировать в текст? Мультимодальные ретриверы с поздним взаимодействием — ColPali, ColQwen2 — переносят идею ColBERT на изображения: один эмбеддинг на patch страницы, оценка против токенов запроса через max-similarity. Ретривер достаёт страницы, которые по тексту бы не совпали, потому что нужная информация была в таблице, рисунке или вёрстке, которую извлечение текста бы исказило. Визуально-языковая модель читает страницу напрямую.

Цена существенна и заслуживает конкретики. Обычный текстовый чанк даёт один эмбеддинг размерности ~1024 — несколько килобайт. Страница, закодированная ColPali, даёт около тысячи patch-эмбеддингов размерности ~128 — полмегабайта на страницу. Размер индекса для миллиона страниц растёт с гигабайтов до сотен гигабайт, оценка дороже, генерация требует визуально-языковой модели. Для корпусов, плотных таблицами и рисунками, апгрейд реальный. Для корпусов из прозы на скромном бюджете хорошо распарсенный текстовый поиск всё ещё разумный дефолт. Гибридные конфигурации — ColPali для поиска, текст для генерации, или наоборот — это то, где осядет большинство production multimodal RAG в ближайший год.

Стоит запомнить: самая частая причина разочаровывающего качества RAG — это не ретривер, не reranker и не промпт. Это парсер. Команды видят «модель галлюцинирует» и крутят промпты, тогда как настоящая проблема — документы, испорченные тремя стадиями выше. Сначала чините парсинг; ничего ниже по потоку не вернёт того, что было потеряно выше.

Что подготавливает глава 2

Чистый парсинг с учётом макета необходим для качественного RAG и не достаточен ни для чего. Распарсенный документ остаётся документом — его надо разбить на куски, достаточно маленькие, чтобы эмбеддить, и достаточно большие, чтобы что-то значить. Чанкер, игнорирующий структурные подсказки парсера, выбрасывает ровно то, что парсер старался сохранить. Эти два слоя надо проектировать вместе, и Глава 3 проходит по спектру чанкинга и приёмам фронтира, которые его переписали.

Дальше — Глава 3: Продвинутые фреймворки чанкинга. Спектр чанкинга от фиксированного размера до учёта структуры, миф об overlap, обрыв контекста и техники contextual retrieval и late chunking, изменившие расчёты.

Хочется всю картину? Книга проходит по каждому инструменту с конкретными рекомендациями по соответствию корпусу, содержит плейбук версионирования парсера, удерживающий индекс согласованным между апгрейдами, и разбирает вопросы резидентности и контроля доступа, которые возникают в реальных мультимодальных развёртываниях. LLM Primer III на Amazon →