Почему длинные PDF ломают мозг вашему RAG
Вы загружаете техдокумент на 200 страниц в вашу RAG-систему. Задаете вопрос про детали из 156-й страницы. Ответ? Общие фразы, отсылки к началу документа, а иногда и вовсе галлюцинации. Знакомая картина? Проблема не в модели. Проблема в том, как вы кормите ей данные.
Длинные PDF (130+ страниц) — это не просто много текста. Это сложная структура: оглавление, таблицы, сноски, колонтитулы, графики. Стандартный чанкинг «по 1000 токенов» превращает связный документ в кашу, где конец главы может оказаться в одном чанке с началом следующей, а важный контекст теряется на стыке. Итог — качество поиска падает до нуля.
Если вы режете PDF бездумно, вы создаете проблему Lost in the Middle своими руками. Модель просто не увидит ключевую информацию.
Docling: не волшебная палочка, а скальпель
Docling — библиотека для извлечения структуры из документов. Она не делает чанкинг за вас. Она дает вам инструменты, чтобы сделать его осмысленным. Ваша задача — правильно их использовать. Здесь нет одной кнопки «сделать хорошо». Есть стратегии, которые нужно подбирать под тип документа.
1 Подготовка: что проверить до запуска
Не бросайте сырой PDF в конвейер. Сначала убедитесь, что Docling его правильно «увидит».
- Текст vs. Картинка: Если ваш PDF — это сканы страниц (изображения), Docling сама их не распознает. Вам нужен OCR-слой. Используйте связку с Tesseract или облачным сервисом.
- Разметка: PDF с кривой разметкой (где заголовки не помечены как заголовки) — головная боль. Docling попытается восстановить структуру, но иногда проще предварительно спарсить его в JSON с помощью LLM для очистки.
- Размер: 500-страничный PDF может весить гигабайт. Проверьте, хватит ли памяти. Иногда полезно разбить документ на логические части (например, по главам) еще до обработки.
2 Выбор стратегии чанкинга: три подхода
Здесь все решает тип документа. Технический мануал, юридический договор и научная статья режутся по-разному.
| Стратегия | Когда использовать | Параметры Docling | Риски |
|---|---|---|---|
| Семантический (по разделам) | Документы с четкой структурой (главы, подглавы). Техническая документация, книги. | Использовать HierarchicalChunker с настройкой уровня заголовков (например, до h3). |
Если структура плохо распознана, чанки будут кривыми. Требует проверки. |
| Рекурсивный (по параграфам) | Однородные тексты без ярких заголовков. Отчеты, некоторые научные статьи. | Использовать RecursiveChunker с размером чанка ~500-800 токенов и перекрытием 10%. |
Может разорвать смысловую единицу (например, список). Размер критически важен. |
| Гибридный (страница + семантика) | Документы со сложной версткой (таблицы на всю страницу, сноски). Юридические документы. | Сначала чанкинг по страницам, затем объединение мелких чанков по смыслу. | Самый сложный в настройке. Легко получить слишком большие или слишком мелкие чанки. |
Совет: Начните с семантического чанкинга. Он чаще всего дает лучший результат для длинных документов. Если Docling не находит заголовки — падайте на рекурсивный, но тщательно подбирайте размер.
# Пример настройки HierarchicalChunker в Docling
from docling.chunker import HierarchicalChunker
from docling.document import PdfDocument
# Загружаем документ
doc = PdfDocument("long_manual.pdf")
doc.parse()
# Создаем чанкер, который будет резать по заголовкам уровней 1 и 2 (h1, h2)
chunker = HierarchicalChunker(
max_chunk_size=1000, # максимальный размер в токенах
include_headers=["h1", "h2"], # уровни заголовков для разбиения
respect_sentence_boundary=True # не резать посередине предложения
)
chunks = chunker.chunk(doc)
print(f"Получено {len(chunks)} семантических чанков.")3 Оптимизация: скорость против качества
Обработка 300-страничного PDF может занять вечность. Вот где нужно балансировать.
- Параллельная обработка: Если вы режете по страницам или независимым разделам — распараллеливайте. Но учтите, что извлечение структуры всего документа может быть последовательной операцией.
- Кэширование промежуточных результатов: После парсинга документа в промежуточный формат (например, внутреннее представление Docling) — сохраните его. При повторных экспериментах с чанкингом не придется парсить заново.
- Аппаратное ускорение: Сам Docling не сильно нагружает GPU, но если у вас пайплайн включает этап с LLM (например, для переиндексации или суммаризации), подумайте о железе. Для CPU-инференса Epyc 9175F показывает себя неплохо.
Не гонитесь за скоростью в ущерб качеству. Лучше потратить час на обработку один раз и получить хорошие чанки, чем потом месяцами мучиться с плохими ответами RAG.
Ошибки, которые совершают все (и как их не делать)
Я видел десятки развернутых RAG-систем, которые спотыкались об одно и то же.
- Игнорирование метаданных: Каждый чанк должен нести информацию о своем происхождении: номер страницы, название главы, исходный файл. Без этого при поиске вы получите ответ, но не поймете, откуда он. Docling позволяет добавлять метаданные в чанки — используйте это.
- Слепое доверие автоматике: Запустили чанкер, получили 200 чанков, загрузили в векторную БД. Стоп. Выборочно проверьте 10-15 чанков. Убедитесь, что они целостные, что заголовки не «отлипли» от текста. Одна ошибка в структуре может испортить все.
- Одинаковый размер для всего: Таблицы, код, формулы — их нужно обрабатывать иначе, чем сплошной текст. Иногда их стоит выносить в отдельные чанки или хотя бы маркировать особым тегом.
- Забыть про перекрытие (overlap): Без перекрытия контекст на стыке чанков теряется. Но слишком большое перекрытие (30% и больше) дублирует данные и увеличивает шум. Золотая середина — 5-15%.
Что делать, если Docling не справляется?
Бывает. Документы бывают настолько кривыми, что никакая библиотека не вытянет. Выхода два.
Первый: Предварительная обработка более мощным инструментом. Например, Kreuzberg v4 на Rust иногда выжимает из PDF то, что не под силу Python-библиотекам. Конвертируйте документ в чистый HTML или Markdown, а потом кормите Docling.
Второй: Ручная разметка. Да, это звучит как кошмар. Но если документ сверхважный (например, основной договор вашей компании), иногда стоит один раз вложить человеческие часы, чтобы потом годами получать точные ответы. Используйте инструменты вроде LLM для парсинга в JSON — они могут значительно ускорить ручную работу.
И последний совет, который сэкономит вам недели: не зацикливайтесь на идеальном чанкинге. Сначала сделайте рабочую версию, загрузите в RAG, протестируйте на реальных вопросах. Часто оказывается, что 80% качества достигается простой стратегией, а погоня за оставшимися 20% требует непропорциональных усилий. Начните с малого, итерируйтесь и решайте проблемы по мере их поступления.
