Есть два способа дать модели знания, которых нет в её обучении: положить всё в контекст целиком или построить поиск, который достаёт только нужный кусок. Оба работают. Экономика и риски у них разные.
Два способа устроены по-разному
Длинный контекст это просто промпт побольше. Берёте документы, склеиваете, отправляете модели целиком вместе с вопросом. Модель сама решает, что из этого релевантно.
RAG (retrieval-augmented generation) работает иначе. Тексты заранее нарезаны на куски и превращены в embeddings, векторные представления смысла. На вопрос пользователя ищутся ближайшие по смыслу куски, и в промпт попадает только выборка, а не весь корпус.
Разница на бумаге небольшая, а на счёте и на качестве ответов, серьёзная.
Что происходит со счётом
С длинным контекстом каждый вызов оплачивает весь корпус как входные токены, даже если вопрос касается одного абзаца из тысячи страниц. Растёт корпус, растёт цена каждого запроса, линейно и без потолка.
Кеширование промпта смягчает боль, если один и тот же большой контекст используется повторно в течение окна кеша: платите полную цену один раз, а дальше вход дешевле. Но если вопросы разные, а корпус меняется, кеш не спасает.
С RAG цена запроса не зависит от размера корпуса, она зависит от размера выборки, которую вы решили передать модели. База может расти хоть до миллиона документов, в промпт всё равно попадёт условная горстка кусков. Плата за это, отдельная инфраструктура: векторная база, эмбеддинги, иногда ещё один вызов модели на переранжирование кандидатов.
Что происходит с точностью
У длинного контекста есть известная слабость: модель хуже удерживает детали из середины большого текста, чем из начала и конца. Чем длиннее контекст, тем выше риск, что нужный факт потеряется среди шума.
У RAG слабость другая. Точность ответа упирается в качество поиска. Если нарезка кусков сделана грубо, релевантный фрагмент может просто не попасть в выборку, и модель ответит уверенно и неправильно, потому что не увидела нужные данные вообще. Это тихая ошибка: лога нет, извинений нет, просто неверный ответ.
Что ломается на поддержке
Длинный контекст просто устроен: нет отдельного пайплайна, нечему ломаться ночью. Плата за простоту в том, что вы сами следите за бюджетом токенов и рано или поздно упрётесь в предел окна модели, если корпус растёт.
RAG это отдельная система. Нужно выбрать стратегию нарезки текста, выбрать и зафиксировать версию модели эмбеддингов, пересобирать индекс при каждом обновлении контента, следить, что поиск вообще находит релевантное. Каждый из этих узлов может тихо деградировать, и заметите вы это не сразу, а по жалобам пользователей на странные ответы.
Гибрид, который используют чаще всего
На практике редко выбирают что-то одно. Небольшой стабильный корпус, документация одного проекта, база знаний команды, чаще просто кладут в контекст целиком, особенно если кеширование доступно.
Растущий или разнородный корпус чаще уходит в RAG, но с поправкой: поиск находит не короткие обрывки, а целые релевантные документы, которые потом целиком идут в контекст. Так получают точность поиска и способность модели рассуждать над полным текстом, а не над вырванной фразой.
Пример из практики: бот поддержки на пяти статьях помощи прекрасно живёт на длинном контексте, все пять статей помещаются в промпт с запасом. Тот же бот на трёхстах страницах документации API, где раздел про аутентификацию обновляется каждую неделю, обычно переезжает на поиск, потому что весь корпус в контекст уже не влезает так, чтобы модель не путалась в деталях.
Как решить для своей задачи
Три вопроса дают ответ в большинстве случаев. Насколько большой корпус и как быстро он растёт? Если весь корпус помещается в контекст с запасом и почти не меняется, поиск не нужен. Как часто меняются данные? Если контент обновляется каждый день, придётся пересобирать индекс так же часто, а это расход денег и времени команды. Нужен точный факт или синтез по многим источникам? Точный факт лучше найти поиском и процитировать, синтез по большому объёму материала часто удобнее делать на полном контексте.
Посчитать разницу в деньгах проще, чем кажется: на калькуляторе Claudexia можно прикинуть цену запроса для разного объёма контекста и сравнить с ценой пары вызовов, которые нужны для RAG, включая переранжирование.
Коротко
Длинный контекст проще и точнее на среднем объёме, но счёт растёт вместе с корпусом. RAG держит счёт под контролем на любом объёме данных, но добавляет инфраструктуру и риск не найти нужный кусок. Небольшой стабильный корпус: контекст. Растущий и разнородный: поиск, который отдаёт модели целые документы, а не обрывки.