В RAG-пайплайне chunk обычно проходит путь: документ очищают, делят на chunks, для каждого chunk считают embedding, сохраняют текст и метаданные в vector database или поисковом индексе. Когда пользователь задает вопрос, система ищет похожие chunks и передает их модели как источники.
Хороший chunk должен быть достаточно маленьким, чтобы не перегружать контекст, и достаточно большим, чтобы сохранять смысл. Если chunk слишком короткий, модель теряет объяснение и условия. Если слишком длинный, поиск становится шумным и в ответ попадает лишний текст.
Часто используют overlap - небольшое перекрытие между соседними chunks. Это помогает не разорвать важную мысль на границе. Например, если раздел инструкции начинается в одном фрагменте, а уточнение попало в следующий, overlap снижает риск потерять связь.
Для практического RAG важно хранить метаданные: источник, заголовок, раздел, дата версии, права доступа, номер страницы, ссылка на документ и язык. Тогда агент может дать citation, проверить актуальность и не использовать документ, к которому пользователь не имеет доступа.
Примеры
- PDF-инструкцию на 80 страниц делят на chunks по разделам, чтобы агент находил конкретный ответ, а не загружал весь документ.
- В базе знаний каждый chunk хранит текст, заголовок раздела, номер страницы и ссылку на исходный файл.
- Для FAQ chunk может быть одной парой "вопрос-ответ", а для юридического документа - пунктом договора с соседним контекстом.
- Если chunk разорвал таблицу пополам, агент может дать неверный ответ, поэтому таблицы лучше обрабатывать отдельным правилом.
- Overlap в 100-200 токенов помогает сохранить смысл между соседними фрагментами длинной инструкции.
- При обновлении документа старые chunks удаляют или помечают версией, чтобы агент не отвечал по устаревшему тексту.
Где используется
- подготовка документов для RAG
- индексация базы знаний компании
- поиск по PDF, DOCX, Notion, Confluence и Google Drive
- создание embeddings для фрагментов текста
- ответы ИИ-агента с citations и ссылками на источники
- обработка длинных инструкций и регламентов
- разделение документов по заголовкам и смысловым блокам
- контроль доступа к источникам через метаданные chunk
- обновление индекса после изменения документа
- снижение галлюцинаций за счет точных найденных фрагментов
Связанные термины
Частые вопросы
Какой размер chunk выбрать?
Универсального размера нет. Для FAQ подходят короткие chunks, для инструкций - смысловые разделы, для договоров - пункты. На практике размер подбирают тестами по качеству поиска и ответов.
Что такое overlap в chunking?
Overlap - это перекрытие между соседними chunks. Оно помогает не потерять смысл на границе фрагментов, но слишком большой overlap увеличивает дубли и стоимость индекса.
Почему нельзя просто делить документ каждые 1000 символов?
Так можно разрезать мысль, таблицу, список или условие пополам. Лучше учитывать заголовки, абзацы, пункты, таблицы и структуру документа.
Chunking влияет на качество RAG?
Да, очень сильно. Даже хорошая модель будет отвечать плохо, если поиск возвращает фрагменты без контекста, устаревшие chunks или куски, где потеряна главная мысль.
Какие метаданные хранить вместе с chunk?
Источник, URL или путь к файлу, заголовок, раздел, страницу, дату версии, язык, owner, права доступа и идентификатор документа. Это помогает citations, ACL и обновлению индекса.
Нужно ли пересоздавать chunks при обновлении документа?
Да, если изменился текст. Старые chunks нужно удалить, заменить или пометить как устаревшие, иначе агент может отвечать по старой версии базы знаний.
