Стратегии чанкинга в RAG: разбивайте документы для улучшения поиска

Большинство сбоев RAG происходят из-за того, как вы разбиваете свои документы.

Если качество поиска (retrieval) низкое, не спешите первым делом менять промпт или LLM. Посмотрите на свои чанки. Если правильная информация есть в вашей базе данных, но система не может её найти, скорее всего, проблема в стратегии чанкинга.

Плохой чанкинг приводит к трем основным проблемам:

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

Используйте эти четыре стратегии, чтобы исправить свой пайплайн:

  1. Чанкинг фиксированного размера Лучше всего подходит для длинной непрерывной прозы, такой как отчеты или статьи. • Используйте от 256 до 512 токенов. • Установите перекрытие (overlap) в 10–15%, чтобы избежать разрыва предложений.

  2. Семантический чанкинг Лучше всего подходит для плотного текста, такого как FAQ или документация поддержки. • Он разбивает текст на основе смены тем, а не количества токенов. • Это позволяет сохранять законченные идеи вместе.

  3. Структурный чанкинг Лучше всего подходит для технической документации, Markdown или HTML. • Он разбивает текст на основе заголовков (H1, H2, H3). • Это добавляет метаданные, позволяя фильтровать результаты поиска по разделам.

  4. Иерархический (Parent-Child) чанкинг Лучше всего подходит для продакшн-систем, которым важны и точность, и контекст. • Создавайте маленькие дочерние чанки (64–128 токенов) для точного векторного поиска. • Связывайте их с большими родительскими чанками (512–1024 токена), которые будет читать LLM. • Это дает лучшее из обоих миров.

Как выбрать размер:

• 128–256 токенов: подходит для поиска фактов и технической документации. • 256–512 токенов: хорошая отправная точка для общего использования. • 512–1024 токена: используйте для развернутых аналитических вопросов.

Золотое правило: всегда тестируйте свою стратегию перед внедрением.

Сформируйте набор из 30–50 реальных запросов. Разметьте правильные ответы. Измерьте ваш recall@3. Не меняйте модель эмбеддингов, пока ваш recall не станет выше 80%.

Source: https://dev.to/dishant_sethi/rag-pipeline-chunking-strategies-split-documents-for-better-retrieval-aoe

Optional learning community: https://t.me/GyaanSetuAi