Контекстное обогащение чанков — что это простыми словами

Зачем это знать

• Понять, почему поиск по базе знаний отдаёт похожие куски вместо нужных
• Оценить разовые расходы на подготовку базы и отличить их от ежемесячного счёта
• Спрашивать подрядчика долю верных попаданий поиска, а не общее качество ответов

Что такое контекстное обогащение чанков простыми словами

Представьте картотеку, из которой вырвали страницы и сложили в общую стопку. На странице написано: «Выручка в этом квартале выросла на 3%. Североамериканский регион показал рост 12%, европейский снизился на 5%». Чей отчёт, за какой квартал, какое подразделение — на странице этого нет.

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

Обогащение — это надпись сверху страницы, сделанная до того, как её кладут в картотеку. Выглядит она так: «Квартальный финансовый отчёт ACME за второй квартал 2024 года, раздел про региональную выручку». Дальше страница ищется по этой надписи наравне с текстом.

В RAG документы режут на куски по несколько абзацев — их называют чанками. Каждый чанк превращают в эмбеддинг и кладут в векторную базу. Обогащение вставляет перед чанком приписку в 50–100 токенов и только потом считает эмбеддинг.

Как это работает

1. Документ читают целиком. Модели дают весь исходный файл и один кусок из него. Задача — описать место куска в документе, а не пересказать его.
2. Приписка получается короткой. 50–100 токенов: название документа, период, раздел, о ком речь. Длиннее делать незачем — приписка начнёт перевешивать сам текст.
3. Платят один раз. Обогащение идёт при загрузке документа, а не при каждом вопросе. Исходный документ кэшируют, чтобы не отправлять его заново для каждого куска той же папки.
4. Индекс строится по обогащённому тексту. И вектор, и поиск по точным словам видят приписку. Дата и название компании из приписки вытаскивают кусок по запросам, где раньше совпадений не было вовсе.
5. Модели отдают исходный кусок. В ответ подают либо обогащённый текст, либо чистый. Приписка нужна для попадания в выдачу, а не для чтения.

Отдельно проверяют размер контекстного окна. Обогащённые куски длиннее исходных, и в тот же бюджет их влезает меньше. Если модель тянет короткий контекст, приходится выбирать: либо меньше кусков в ответе, либо приписку покороче.

Пример из практики

Производственная компания собрала базу знаний из регламентов, приказов и протоколов за пять лет. Вышло около 4 000 документов, после разбиения — порядка 60 000 кусков. Вопросы сотрудников звучали так: «когда меняли норматив по приёмке на втором участке». Ни даты, ни подразделения внутри куска не было.

Расчётный порядок для такой базы: около 50 центов на тысячу кусков. Считано для недорогой модели с кэшированием исходного документа. На весь архив выходит порядка 30 долларов разово. Текущая доплата считается по числу новых документов в месяц и на таком объёме идёт десятками рублей.

Проверяют результат не на ощущениях. Собирают 50–100 реальных вопросов с заранее известным правильным куском. Меряют долю запросов, где нужный кусок попал в первую пятёрку выдачи. Замер делают дважды на одной и той же выборке: до обогащения и после. Разница между двумя числами и есть весь эффект.

Что это даёт бизнесу

• Меньше ответов «не нашёл». Часть вопросов сотрудников содержит дату, название подразделения или номер приказа. Без приписки такие слова не встречаются в куске вовсе, и поиск их не ловит.
• Расход разовый и считается заранее. Порядок в 50 центов на тысячу кусков умножается на размер архива, и сумма известна до начала работ. Месячный счёт за сами ответы это не меняет — прикинуть его можно калькулятором бюджета.
• Улучшение не требует менять систему. Куски, модель, интерфейс остаются прежними — меняется только то, что попадает в индекс. Откатить можно перезаливкой базы.
• Появляется проверяемая метрика. Доля запросов с нужным куском в первой пятёрке измеряется на одной выборке до и после. Разговор с подрядчиком переходит с «стало лучше» на два числа.

Когда без этого можно обойтись

Часть баз знаний устроена так, что куски и без приписки самодостаточны. Карточки товаров с артикулом внутри, статьи регламента с заголовком в тексте, короткие ответы поддержки. Там прирост попаданий обычно теряется в погрешности замера.

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

Не нужно оно и там, где вся база помещается в контекстное окно целиком. Пара сотен страниц отправляется модели без всякого поиска — тогда ни куски, ни приписки к ним не нужны.

Что важно проверить

Первое: приписку пишет модель, и она умеет ошибаться. На выборке в 50 кусков приписки читают глазами — не приписана ли чужая дата или соседний раздел. Ошибка в приписке хуже её отсутствия: кусок начнёт вылезать не на те вопросы.

Второе: обогащение меняет длину куска, а значит и объём, уходящий в модель при каждом ответе. Десять кусков в подсказке плюс 100 токенов на каждый — лишняя тысяча токенов на запрос. Это уже ежемесячный счёт, а не разовый расход, и его считают отдельно.

Третье: у подрядчика запрашивают долю попаданий до и после на одной выборке вопросов. Рядом — размер выборки и дата замера. Замер после обогащения без замера до него не значит ничего.