Поиск по PDF: как сохранить смысл таблиц и диаграмм

В PDF нашлась нужная фраза, но ответ на вопрос всё равно неверный. Например, система выбрала страницу со словами «объём производства», хотя количество изделий указано в таблице на следующей странице. Или извлекла подписи диаграммы, потеряв связь между цветом линии и легендой. Для бизнеса важен не сам поиск по документам, а возможность проверить, откуда взялось решение.

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

Что меняется при визуальном поиске

В материале Weaviate от 1 сентября 2026 года описан подход, при котором индексируется изображение страницы, а не только извлечённый текст. Модель сохраняет несколько векторов для разных участков изображения; при поиске сопоставляет элементы вопроса с участками страницы. В приведённой демонстрации используются квартальные презентации NVIDIA, страницы с графиками и финансовыми таблицами.

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

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

Выбирать по вопросам, а не по формату файла

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

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

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

Ссылка должна помогать проверке

В обзоре качества retrieval Weaviate автор связывает ошибки своих экспериментальных RAG-процессов с нерелевантным, обрезанным и устаревшим контекстом. Это вывод автора о его исследовании; практическая рекомендация для PDF — проверять материал, попавший в ответ, отдельно от качества формулировки.

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

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

Проверка на производственном сценарии

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

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

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

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

Когда усложнение оправдано

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

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

Источники

• Weaviate: How to extract meaning from charts and tables in PDFs, 1 сентября 2026 года.
• Weaviate: Your LLM Is Only as Good as What It Retrieves, 6 мая 2026 года.