В RAG-системах документы обычно не отправляют в модель целиком. Их делят на чанки, превращают в векторы и кладут в индекс. Когда пользователь задает вопрос, система ищет несколько наиболее подходящих чанков и добавляет их к запросу. Так модель отвечает не “по памяти”, а с опорой на конкретные фрагменты базы знаний.
Хороший knowledge chunk должен быть достаточно коротким, чтобы помещаться в контекст, и достаточно цельным, чтобы не терять смысл. Если нарезать документ слишком мелко, модель получает обрывки без объяснения. Если слишком крупно — поиск становится шумным, а в контекст попадает лишнее. Поэтому часто используют смысловую нарезку: по заголовкам, разделам, пунктам инструкции, FAQ-блокам или логическим абзацам.
Для AI-агентов качество чанков напрямую влияет на качество ответов. Один и тот же документ может работать хорошо или плохо в зависимости от того, как его разбили, какие метаданные сохранили и умеет ли retriever выбирать нужные фрагменты.
Примеры
- Раздел регламента “Как оформить возврат” сохраняют как отдельный knowledge chunk.
- FAQ-вопрос и ответ хранят одним чанком, чтобы модель не потеряла связь между ними.
- Инструкцию по оплате делят на шаги, но каждый шаг содержит заголовок и контекст раздела.
- Для юридического документа chunk может включать один пункт договора и его номер.
- Если агент отвечает неправильно, проверяют, какие чанки попали в контекст и были ли они релевантны.
Где используется
- Индексация базы знаний компании для RAG
- Подготовка документов для AI-агента поддержки
- Поиск ответов по инструкциям, регламентам и FAQ
- Разбор договоров, ТЗ, отчетов и тендерной документации
- Оптимизация качества retrieval и semantic search
- Снижение галлюцинаций за счет источников в контексте
- Диагностика плохих ответов в AI-поиске по документам
Связанные термины
Частые вопросы
Чем knowledge chunk отличается от документа?
Документ — это полный файл или страница, а knowledge chunk — его небольшой смысловой фрагмент. В RAG чаще ищут и передают модели именно чанки, потому что целый документ может быть слишком большим и шумным.
Какой размер чанка считается хорошим?
Универсального размера нет. Для FAQ подойдут короткие блоки, для регламентов — разделы или пункты с контекстом, для договоров — статьи и подпункты. Важно тестировать качество поиска, а не ориентироваться только на количество токенов.
Почему плохая нарезка ломает ответы AI-агента?
Если chunk слишком маленький, в нем не хватает смысла. Если слишком большой, retriever приносит лишний текст. В обоих случаях модель может ответить неточно, пропустить важное условие или сослаться не на тот источник.
Нужно ли хранить метаданные у чанков?
Да. Полезны название документа, раздел, дата обновления, владелец знания, тип документа, права доступа и ссылка на источник. Метаданные помогают фильтровать поиск и показывать пользователю источник ответа.
