Опубликовано

Размер чанка зависит от запроса: как AI21 Labs предлагает решить одну из главных проблем RAG-систем

AI21 Labs показала, что единый размер «чанков» (fragments) в RAG-системах – это компромисс, и предложила простой способ адаптировать разбивку текста под тип запроса пользователя.

Разработка
Источник события: AI21 Labs Время чтения: 3 – 5 минут

Когда работаешь с RAG-системами – теми, что ищут нужную информацию в документах и передают её языковой модели для ответа, – рано или поздно встаёшь перед выбором: на какие куски разбивать текст перед индексацией? Это называется «чанкингом» (фрагментацией), и от размера этих кусков зависит, насколько точно система найдёт то, что нужно.

Обычно выбирают один размер и применяют ко всем документам. Проблема в том, что разные запросы требуют разного подхода. AI21 Labs разобрались в этом вопросе и предложили решение, которое не требует переделывать всю систему.

Почему размер имеет значение

Представьте, что у вас есть длинный документ. Если разбить его на маленькие кусочки – по паре предложений, – то каждый кусок будет очень точным и конкретным. Это хорошо для узких, детальных вопросов: «Какая дата указана в пункте 3.2»? Система быстро найдёт нужное предложение.

Но если вопрос широкий – например, «Каковы основные выводы этого отчёта»? – маленькие куски не помогут. Информация окажется размазана по десяткам фрагментов, и система либо упустит контекст, либо вытащит что-то второстепенное.

Большие чанки работают наоборот. Они охватывают больше контекста, лучше подходят для обобщающих вопросов. Но если вопрос конкретный, большой кусок текста может «зашуметь» результат – релевантная информация потеряется среди общих рассуждений.

Проще говоря: универсального размера нет. Есть компромисс.

Что предлагает AI21 Labs

Команда AI21 решила не выбирать один размер, а использовать несколько одновременно. Идея простая: индексировать документы с разными уровнями детализации – скажем, мелкими чанками по 128 токенов, средними по 512 и крупными по 2048. А потом, в момент запроса, определять, какой масштаб лучше подходит.

Для этого они используют классификатор – небольшую модель, которая смотрит на запрос пользователя и решает: этот вопрос требует детального поиска или общего понимания? В зависимости от ответа система обращается к нужному набору чанков.

Классификатор обучен на примерах запросов, размеченных людьми. Он не пытается угадать «правильный» размер в абсолютном смысле – он просто выбирает тот, который с большей вероятностью даст полезный результат для данного типа вопроса.

Как это работает на практике

AI21 протестировали подход на нескольких популярных бенчмарках для RAG-систем. Результаты показали, что адаптивный выбор размера чанков улучшает качество поиска по сравнению с фиксированным размером – причём независимо от того, какой именно фиксированный размер использовался.

Особенно заметен эффект на запросах, которые явно требуют либо очень детального, либо очень общего ответа. В таких случаях система с одним размером чанков часто промахивается. Мультимасштабный подход позволяет покрыть оба сценария без потери качества.

Важный момент: этот метод не требует сложной инфраструктуры. Не нужно переписывать «пайплайн» (последовательность обработки данных) или внедрять какие-то экзотические алгоритмы. Достаточно проиндексировать документы несколько раз с разными настройками и добавить лёгкий классификатор на входе.

Где могут быть подводные камни

Конечно, есть нюансы. Во-первых, хранение. Если вы индексируете документы в трёх разных масштабах, объём данных в векторной базе вырастет примерно втрое. Для больших корпусов это может быть ощутимо.

Во-вторых, классификатор – это ещё один компонент, который нужно обучать и поддерживать. Если ваши запросы сильно отличаются от тех, на которых модель обучалась, точность может упасть. Возможно, потребуется дообучение на собственных данных.

В-третьих, не все запросы чётко делятся на «детальные» и «общие». Есть промежуточные случаи, где выбор масштаба не очевиден. В таких ситуациях система может ошибиться, и результат будет хуже, чем при универсальном среднем размере.

Зачем это нужно

Чанкинг – одна из тех вещей, которые кажутся технической деталью, пока не столкнёшься с реальной задачей. Когда RAG-система работает на «продакшене» (в реальных условиях эксплуатации), и от неё зависит, найдёт ли пользователь нужную информацию, качество поиска становится критичным.

Подход AI21 не претендует на революцию. Это скорее практичное улучшение, которое можно внедрить без больших переделок. Если у вас уже есть RAG-система, и вы видите, что на одних запросах она работает хорошо, а на других – нет, возможно, дело именно в том, что размер чанков не подходит для всех типов вопросов.

Мультимасштабный подход даёт способ это исправить. Не идеально, но лучше, чем гадать, какой один размер выбрать и надеяться, что он сработает для всех.

Ссылка на публикацию: https://www.ai21.com/blog/query-dependent-chunking/
Оригинальное название: Chunk size is query-dependent: a simple multi-scale approach to RAG retrieval
Дата публикации: 29 янв 2026
AI21 Labswww.ai21.com Израильская компания, создающая большие языковые модели и инструменты для работы с текстом.
Предыдущая статья Theorizer: как ИИ учится формулировать научные законы на основе тысяч статей Следующая статья YouTube разрешил создавать Shorts с помощью AI-аватаров

От источника к разбору

Как создавался этот текст

Этот материал не является прямым пересказом исходной публикации. Сначала была отобрана сама новость – как событие, важное для понимания развития ИИ. Затем мы задали рамку обработки: что в тексте важно прояснить, какой контекст добавить и на чём сделать акцент. Это позволило превратить отдельный анонс или обновление в связный и осмысленный разбор.

Нейросети, участвовавшие в работе

Мы открыто показываем, какие модели использовались на разных этапах обработки. Каждая из них выполняла свою роль – анализ источника, переписывание, проверка и визуальная интерпретация. Такой подход позволяет сохранить прозрачность процесса и ясно показать, как именно технологии участвовали в создании материала.

1.
Claude Sonnet 4.5 Anthropic Анализ исходной публикации и написание текста Нейросеть изучает оригинальный материал и формирует связный текст

1. Анализ исходной публикации и написание текста

Нейросеть изучает оригинальный материал и формирует связный текст

Claude Sonnet 4.5 Anthropic
2.
Gemini 2.5 Flash Google DeepMind Проверка и правка текста Исправление ошибок, неточностей и спорных формулировок

2. Проверка и правка текста

Исправление ошибок, неточностей и спорных формулировок

Gemini 2.5 Flash Google DeepMind
3.
DeepSeek-V3.2 DeepSeek Подготовка описания для иллюстрации Генерация текстового промпта для визуальной модели

3. Подготовка описания для иллюстрации

Генерация текстового промпта для визуальной модели

DeepSeek-V3.2 DeepSeek
4.
FLUX.2 Pro Black Forest Labs Создание иллюстрации Генерация изображения по подготовленному промпту

4. Создание иллюстрации

Генерация изображения по подготовленному промпту

FLUX.2 Pro Black Forest Labs

ИИ: События

Вам может быть интересно

Перейти ко всем событиям

Другие события из мира искусственного интеллекта, которые помогают увидеть общую картину и понять, как меняется направление развития технологий.

BSC и ACAPPS разрабатывают технологии на основе искусственного интеллекта, призванные помочь глухим и слабослышащим людям эффективнее взаимодействовать с цифровыми сервисами.

Компания AMD представила Micro-World – первые модели мира (world models) с открытым исходным кодом. Они способны генерировать видео с учетом действий пользователя в реальном времени и оптимизированы для работы на графических процессорах компании.

Hugging Face запустил Community Evals – платформу, на которой разработчики могут самостоятельно тестировать языковые модели и делиться результатами, не полагаясь на закрытые рейтинги.

Не пропустите ни одного эксперимента!

Подпишитесь на Telegram-канал –
там мы регулярно публикуем анонсы новых книг, статей и интервью.

Подписаться