База знаний (лекции, документация, статьи) — это фундамент любой RAG-системы. Качество ответов напрямую зависит от того, как вы подготовили данные. Это звучит очевидно, но на практике 80% проблем в RAG — это не выбор LLM и не параметры эмбеддингов, а именно некорректное чанкование (chunking)
Что такое чанк на самом деле?
Формально чанк — это единица поиска, фрагмент текста, который превращается в вектор (embedding). Важно помнить: на этапе поиска семантики в привычном понимании нет — есть только математическое сравнение векторов в многомерном пространстве.
Поэтому чанк — это прежде всего единица сравнения. И подбирать его параметры нужно исходя из того, как формируется embedding и как выполняется retrieval (top-k, фильтры, реранкинг).
Главный вопрос: какой размер выбрать?
Многие допускают интуитивную ошибку: делают чанки большими, считая, что «чем больше информации, тем лучше». Но модель эмбеддингов сжимает текст в вектор фиксированной размерности.
- Oversized Chunks: Если внутри чанка слишком много тем, вектор получается «усредненным», а смысл — размазанным. В итоге он плохо совпадает с конкретным запросом пользователя.
- Small Chunks: «Точечный» вектор хорош для поиска, но теряет контекст. Если мысль разбита на 3 части, LLM получит лишь обрывок и даст неполный ответ.
Практический Pipeline это 4 столпа настройки
Ошибки чанкования нельзя полностью вылечить промпт-инжинирингом или Query Rewriting. Если релевантный кусок не попал в выборку, LLM его просто не увидит.
1. Адаптивный размер под задачу Нет «золотого стандарта» в 512 токенов. Нужно ориентироваться на смысловую плотность текста:
- Legal / Medical: смысл часто размазан по иерархии документов. Лучше использовать большие чанки (1500+ символов) с анализом структуры.
- Technical Docs / Instructions: плотность смысла уже высокая. Чанки по 500–700 символов работают лучше, так как запрос пользователя обычно очень конкретен.
- Академические лекции: Хорошо работает баланс в 1000–1500 символов.
2. Overlap (перекрытие)
Добавляйте в каждый следующий чанк около 30% текста из предыдущего. Это «страховка»: если мысль окажется на границе разреза, она целиком попадет хотя бы в один из соседних чанков, что критично для корректного поиска или реранкинга.
3. Нарезка по логическим границам (Structural Splitting)
Режьте текст используя рекурсивные сплиттеры (RecursiveCharacterTextSplitter), которые приоритизируют естественные разделители:
- Заголовки и переносы строк (\n\n, \n)
- Знаки пунктуации (точки, точки с запятой)
Чанк должен быть максимально близок к законченной мысли.
4. Иногда используют Semantic Chunking
Для наиболее критичных задач используют Semantic Chunking. Вместо подсчета символов мы анализируем косинусное расстояние между соседними предложениями. Если оно резко увеличивается — значит, тема сменилась, и именно там должен быть разрез. Это делает границы чанка наиболее смысловыми.
Какие еще есть подходы к чанкованию текста
- Ручная разметка: Эксперты читают документы и выделяют смысловые блоки в отдельные куски текста. Проблема очевидная: долго, дорого, невозможно масштабировать.
- Разметка через LLM: Подаем в LLM большое окно контекста — просим разбить на смысловые куски не меняя смысла текста. Дорого и не стабильно.
- Семантический поиск: Даже при простой нарезке можно улучшить результат за счёт reranking, расширения запроса, многошагового retrieval.
Чанкование — это этап, который напрямую влияет на геометрию векторного пространства и качество поиска
Наша задача не “сохранить смысл идеально”, а увеличить вероятность того, что релевантный кусок попадёт в retrieval.
Ошибка на этом этапе не компенсируется ни моделью, ни промптами. Ведь в конечном итоге, если LLM не получит релевантный чанки, она не сможет дать релевантный ответ пользователю.