У вас есть тысяча страниц документов — регламенты, инструкции, законы, база поддержки — и хочется, чтобы по ним отвечал ИИ. Причём по существу, а не «в целом по теме». Кажется, что решение очевидно: взять модель, отдать ей все документы и радоваться. На практике на этом шаге всё и ломается.
Между «у меня есть документы» и «ИИ по ним отвечает» лежит технология, о которой редко рассказывают простым языком. Она называется чанки. Разберём, что это, как чанки «питаются» документами и почему без них умный поиск по большой базе не взлетит — с кодом и цифрами.
Почему нельзя просто «скормить» ИИ весь документ
У любой языковой модели есть лимит контекста — сколько текста она способна прочитать за один запрос. Даже у самых больших моделей это порядка миллиона токенов (токен — единица, которой «мыслит» модель, примерно два-три символа русского текста). Звучит много, но большая база документов легко весит в разы больше. Не поместилась — модель просто не увидит нужный фрагмент.
Допустим, база всё же влезла. Тогда возникает вторая проблема — деньги. За вход модель берёт плату по объёму. Прокачивать через неё всю базу на каждый вопрос — это единицы, а то и десятки долларов за ответ. Сотня вопросов в день превращается в тысячи долларов в месяц на пустом месте.
И даже если бы деньги не смущали, есть третья беда — качество. Когда модели дают гигантскую «простыню», она хуже находит в ней нужное и легче ошибается. Ей проще работать с несколькими точными абзацами, чем с десятитомником.
Вывод простой: подавать модели всю базу целиком нельзя. Нужно на каждый вопрос доставать только те несколько абзацев, которые реально относятся к делу. Вот здесь и появляются чанки.
Что такое чанк
Чанк (chunk) — это небольшой самодостаточный кусок документа. Условно — один пункт инструкции, один абзац, одна норма. Вместо того чтобы держать документ единой «простынёй» на сотни страниц, мы режем его на сотни маленьких кусочков, каждый из которых понятен сам по себе.
Отсюда метафора из заголовка. Большие документы — это «еда». Чтобы ИИ мог её «переварить», её нужно порезать на порции. Целую книгу проглотить нельзя, а по кусочку — вполне. Режут не механически по длине, а по смыслу: по разделам, статьям и пунктам, чтобы законченная мысль не разрывалась посередине.
// Режем документ на смысловые фрагменты (чанки)
function chunkDocument(text) {
const parts = splitBySections(text); // сначала по разделам и пунктам
const chunks = [];
for (const part of parts) {
if (tokens(part) <= 800) {
chunks.push(part); // мысль влезает — берём целиком
} else {
// слишком длинная — режем скользящим окном с перекрытием,
// чтобы мысль не обрывалась на границе
chunks.push(...slidingWindow(part, 800, /* overlap */ 100));
}
}
return chunks;
}Например, для одного из наших проектов
Чтобы не осталось абстракцией — конкретный случай. Например, для одного из наших проектов мы сделали ИИ-консультанта для сайта: чат, который отвечает посетителям на вопросы по ЖКХ строго по действующему законодательству и со ссылками на конкретные нормы.
Чтобы он это умел, в него нужно было загрузить весь корпус документов. Вот реальный объём:
Тот самый случай, когда «просто загрузить всё» невозможно в принципе: корпус в десять раз больше окна контекста. А если бы влез — один вопрос обошёлся бы примерно в тридцать долларов только за прочтение базы. При живом потоке обращений это несерьёзно.
Поэтому весь корпус нарезали на чанки — получилось 6 735 фрагментов, в среднем по 800–1500 токенов каждый. Теперь на любой вопрос доставать нужно не десять миллионов токенов, а десяток релевантных кусочков. Как именно — дальше.
Как чанки «питаются» документами: технология RAG
Сам по себе набор кусочков ничего не решает — нужно уметь по вопросу мгновенно находить нужные среди тысяч. Это делает RAG (retrieval-augmented generation — «генерация с подтягиванием данных»): модель отвечает не «из головы», а по подтянутым из базы фрагментам. Работает в четыре шага.
Шаг 1. Каждый чанк превращаем в вектор (эмбеддинг)
Каждый кусочек прогоняют через модель, которая переводит смысл текста в набор из 1536 чисел — вектор. Похожие по смыслу тексты получают похожие векторы. Это как «координаты смысла»: «смена управляющей компании» и «расторжение договора управления» окажутся рядом, хотя слова разные.
// Модель эмбеддингов превращает текст в вектор смысла
const res = await openai.embeddings.create({
model: 'text-embedding-3-small',
input: chunks
});
// Сохраняем вектор рядом с текстом чанка (расширение pgvector в PostgreSQL)
await db.query(
'INSERT INTO chunks (content, embedding) VALUES ($1, $2::vector)',
[chunkText, '[' + vector.join(',') + ']']
);Шаг 2. Вопрос тоже превращаем в вектор и ищем близкие чанки
Пришёл вопрос — считаем его вектор той же моделью и ищем в базе кусочки, чьи векторы ближе всего по смыслу. Параллельно идёт полнотекстовый поиск по словам — гибрид двух подходов точнее, чем каждый по отдельности.
-- Ищем 15 ближайших по смыслу чанков (оператор <=> — косинусное расстояние)
SELECT content, 1 - (embedding <=> $1) AS similarity
FROM chunks
ORDER BY embedding <=> $1
LIMIT 15;Шаг 3. Отдаём модели только эти фрагменты
Вместо всей базы в модель уходит десяток-полтора релевантных чанков — тысячи, а не миллионы токенов. Модель отвечает строго по ним и ставит сноски [1], [2] на конкретные документы.
const answer = await claude.messages.create({
model: 'claude-sonnet-4-6',
system: 'Отвечай ТОЛЬКО по этим источникам и ставь ссылки [N]:\n' + relevantChunks,
messages: [{ role: 'user', content: question }]
});Шаг 4. Ответ со ссылками на источники
Человек получает конкретный ответ, а под ним — список источников со ссылками на нужные документы. Каждое утверждение можно проверить. Именно это отличает консультанта от «болталки»: он не выдумывает, а отвечает по найденным фрагментам.
Две модели: одна ищет, другая отвечает
Важная деталь, которую часто упускают: в такой схеме работают две разные модели, и каждая занята своим.
- Модель эмбеддингов (
text-embedding-3-small) переводит текст в векторы. Её задача — не отвечать, а «понимать смысл» для поиска. Дешёвая и быстрая; именно она разложила все 6 735 чанков по «координатам смысла». - Разговорная модель (Claude Sonnet 4.6) читает найденные фрагменты, формулирует понятный ответ человеческим языком и расставляет ссылки на источники.
Разделение труда: дешёвая модель ищет, сильная — отвечает. Так и качество высокое, и стоимость минимальная — дорогая модель обрабатывает не всю базу, а только горсть релевантных кусочков.
С чанками против «без чанков»: сравнение
Соберём разницу в одну таблицу — на цифрах того же корпуса из 115 документов.
| Параметр | Без чанков (вся база в запрос) | С чанками (RAG) |
|---|---|---|
| Объём на один вопрос | ~10,4 млн токенов | ~15 фрагментов, тысячи токенов |
| Помещается в модель | Нет (лимит ~1 млн) | Да, с запасом |
| Стоимость вопроса | ≈ $30 (если бы влезло) | Центы |
| Скорость | Очень медленно / никак | Секунды |
| Качество | Модель «тонет» в объёме | Точный ответ по релевантным нормам |
| Ссылки на источник | Размываются | Чёткая сноска на конкретный документ |
Разница в стоимости — в сотни раз, а по самой возможности запуститься — принципиальная. Без чанков такой ассистент просто не существовал бы: он не поместился бы в модель ни за какие деньги.
Итог
Чтобы ИИ мог опираться на большие документы, их мало «загрузить» — их нужно правильно нарезать на чанки, перевести в векторы и на каждый вопрос подтягивать только релевантные кусочки. Это и есть RAG.
Технология не привязана к юридическим текстам. Так же можно «скормить» ассистенту документацию продукта, регламенты компании, каталог товаров или базу поддержки — и получить помощника, который знает ваши материалы, отвечает за секунды и не выдумывает. Вся магия — в том, как порезать «еду» на правильные порции.