Чем отличаются RAG, дообучение и длинный контекст?
Длинный контекст кладёт исходный материал прямо в промпт. RAG (retrieval-augmented generation, генерация с поиском) в момент запроса ищет по индексу и отдаёт модели только те фрагменты, которые подходят к вопросу. Дообучение (fine-tuning) меняет веса модели на примерах: оно хорошо меняет манеру ответа и плохо подходит для того, чтобы рассказать модели, что правда. Материал, который можно слать целиком каждый раз, подходит длинному контексту. Материал слишком большой, слишком свежий или слишком закрытый для этого требует поиска. Факты верные, а поведение не то — это задача для дообучения.
В этом году вопрос усложнился. Окна в 1 млн токенов стали обычным делом для топовых моделей (в майском бенчмарке 2026 года проверили пять, и у всех заявлено 1 млн), а все крупные API дают скидку на повторяющийся префикс промпта. «Просто положим всё в промпт» перестало быть шуткой.
Но бесплатным это не стало, и точным не всегда бывает.
Как мы выбираем для проекта клиента?
Мы задаём четыре вопроса в фиксированном порядке. Часто ли меняются знания и должен ли каждый ответ ссылаться на источник? Помещается ли весь корпус в окно с запасом? Проблема в поведении (формат, тон, метки), а не в нехватке фактов? Различается ли доступ по пользователям или арендаторам? Затем собираем самый простой вариант и прогоняем его по 50–100 реальным вопросам клиента, прежде чем добавлять хоть один компонент.
- Знания меняются еженедельно или нужны ссылки на источники: RAG. Длинный промпт тоже умеет цитировать, но каждая правка корпуса сбрасывает закешированный префикс.
- Корпус занимает заметно меньше половины окна и редко меняется: длинный контекст с кешированием промпта. Ни индекса, ни конвейера загрузки.
- Ответы фактически верные, но имеют не ту форму: сначала промпты и few-shot примеры, дообучение только если они не справились на объёме.
- Разные пользователи видят разные документы: RAG с фильтрами по правам, каким бы ни был размер корпуса. Это перекрывает вопрос 2: у промпта нет контроля доступа.
«Меньше половины окна» — наше практическое правило, а не цифра вендора. Мы выбрали его, увидев, что точность падает задолго до заявленного предела, и сдвигаем границу, как только этого требует оценочный набор клиента.
Когда хватает длинного контекста и RAG не нужен?
Длинного контекста достаточно, когда корпус с запасом помещается в окно, редко меняется, а один и тот же префикс используется во множестве запросов, так что кеширование промпта окупается. Типичные примеры: справочник по продукту или договоры по одной сделке. Отправляем целиком, кешируем и обходимся без эмбеддингов, нарезки на чанки и векторного хранилища. Заодно уходит классический сбой RAG, когда ретривер пропускает нужный фрагмент. Цена вопроса: точность плывёт по мере роста промпта, поэтому без проверки на документах самого клиента мы этому варианту не доверяем.
Экономику изменило именно кеширование. В API Anthropic чтение из кеша стоит 0,1x от базовой цены входа (0,05x или 0,025x у нескольких новейших моделей), запись в 5-минутный кеш — 1,25x, запись в часовой — 2x. OpenAI кеширует автоматически и описывает кешированный вход как «скидку до 95%»; на новейших моделях чтение стоит 0,1x, запись 1,25x, а запись живёт 30 минут после последнего обращения. Google тарифицирует кешированный вход Gemini 2.5 Pro по $0,125 за миллион токенов против $1,25 без кеша (для промптов до 200K токенов) плюс хранение по $4,50 за миллион токенов в час. Плата за хранение кусается: большой кеш, который всю ночь держат живым без трафика, всё равно стоит денег.
resp = client.messages.create(
model=MODEL,
max_tokens=1024,
system=[
{"type": "text",
"text": "Answer only from the handbook. Quote the section number."},
{"type": "text", "text": handbook,
"cache_control": {"type": "ephemeral", "ttl": "1h"}},
],
messages=[{"role": "user", "content": question}],
)
print(resp.usage.cache_read_input_tokens) # 0 means full price
Это последнее значение стоит логировать в продакшене. Один изменившийся байт в префиксе (обычный виновник — таймстемп в системном промпте) незаметно превращает каждый запрос в запись в кеш по полной цене, и никто этого не видит до счёта.
Менее приятная часть — точность. Отчёт Chroma «Context Rot» за июль 2025 года проверил 18 моделей, и все они работали хуже по мере роста входа. На вопросах LongMemEval модели заметно лучше отвечали на сфокусированном промпте примерно в 300 токенов, чем на полном примерно в 113K. Майское исследование 2026 года по пяти моделям с окном 1 млн токенов показало, что поиск одного факта решён (100% у трёх сильнейших), а трёхшаговые рассуждения расходятся: Gemini и Claude держались выше 80% до 512K токенов, GPT-5.5 и Qwen3.6-plus резко просели между 512K и 1 млн, а DeepSeek V4 Pro деградировал на всём диапазоне.
Когда RAG выигрывает у дообучения и длинного контекста?
RAG выигрывает, когда знания меняются, когда корпус намного больше любого окна, когда у пользователей разные права доступа или когда каждый ответ должен указывать на фрагмент-источник. Переиндексация одного изменённого документа занимает секунды, переобучение модели или пересборка закешированного промпта — нет. Поиск ещё и держит промпты короткими, а значит, модель остаётся в диапазоне, где, по исследованию context rot, она точнее всего. Стоимость переезжает в инженерию: загрузка данных, нарезка, метаданные, фильтры доступа и оценка качества поиска, которую вы поддерживаете как обычный набор тестов.
Права доступа решают больше проектов, чем размер корпуса. Всё, что лежит в промпте, модель может повторить тому, кто спрашивает. При поиске фильтр срабатывает до того, как модель что-либо увидит, поэтому документ, который пользователь открыть не может, до неё не доходит.
Как построить это хорошо — отдельная тема. В нашем чек-листе запуска RAG разобраны оценка и эксплуатация, материал о гибридном поиске объясняет, зачем мы совмещаем поиск по ключевым словам с эмбеддингами, а статья про pgvector — где могут жить векторы.
Когда дообучение — правильный выбор?
Дообучайте, когда модель знает достаточно, но ведёт себя не так. Под нагрузкой она уходит от вашей JSON-схемы, непоследовательно размечает тикеты, игнорирует фирменный стиль, который не удерживает даже длинный промпт, или вам нужна маленькая дешёвая модель для одной узкой задачи на большом объёме. Фактам дообучением учить не надо. Дообученная модель хранит знания без указателя, откуда они взялись, устаревает в день изменения документа и может выдавать текст, похожий на цитату, за которым нет подтверждения.
Свежие исследования говорят о том же. Статья Kaplan, Gekhman и соавторов на CoLM 2026 (впервые опубликована в апреле 2026 года) называет новые факты, вносимые через supervised fine-tuning, одним из ключевых источников галлюцинаций: модель их усваивает и забывает пересекающиеся факты, которые знала раньше, причём забывание растёт вместе с пересечением. Предложенные авторами способы (самодистилляция, заморозка групп параметров) — исследовательская работа, а не галочка в интерфейсе вендора.
Сдвинулась и сторона вендоров. 7 мая 2026 года OpenAI закрыла self-serve fine-tuning для организаций, которые раньше им не пользовались, а действующие клиенты с 6 января 2027 года больше не смогут создавать новые задания; дообученные модели продолжают работать, пока не будет выведена из обращения их базовая модель. Поэтому план дообучения теперь начинается с письменного ответа на вопрос: «Что будет, когда базовую модель отключат?»
Пять вариантов в сравнении
Сначала читайте последний столбец. Это условие, при котором вариант становится нашей отправной точкой, и ни одна строка не годится отправной точкой для всего.
| Подход | Лучше всего для | Слабое место | Свежесть знаний | Цитаты | Главная статья расходов | Наш выбор по умолчанию, когда |
|---|---|---|---|---|---|---|
| Длинный контекст (+ кеширование промпта) | Небольшой стабильный корпус; вопросы по документам целиком | Точность падает с ростом промпта; задержка на больших промптах | Свежесть последней пересборки промпта; каждая правка сбрасывает кеш | Возможны через цитирование; контроля доступа нет | Токены на запрос, доля попаданий в кеш, хранение кеша в Gemini | Корпус заметно меньше половины окна, редко меняется, один уровень доступа |
| RAG | Большие или меняющиеся корпуса, доступ по пользователям | Промах поиска даёт уверенный неверный ответ | Актуален сразу после переиндексации документа | Встроены: каждый ответ указывает на фрагменты | Загрузка данных, поддержка индекса, оценка качества поиска | Данные часто меняются либо нужны цитаты или права доступа |
| Дообучение | Формат, тон, метки; маленькая модель на большом объёме | Замороженные знания, забывание, текст в форме цитаты без подтверждения | Заморожена на момент обучения | Ненадёжны | Размеченные примеры, запуски обучения и оценки, переобучение при изменениях | Промпты и примеры не справляются с поведением на объёме |
| RAG + длинный контекст | Ответы, которым нужен текст вокруг фрагмента | Больше настройки; промпты больше, чем в обычном RAG | Как у RAG | Встроены | Поиск плюс более крупные промпты | RAG находит нужный документ, но ответ упускает его контекст |
| RAG + дообучение | Актуальные факты при жёстких требованиях к формату ответа | Два конвейера, которые надо поддерживать и заново оценивать | Как у RAG | Встроены, если модель обучена цитировать фрагменты | Всё из двух предыдущих | Рабочий RAG всё ещё даёт разрыв в поведении, который промптами не закрыть |
Из чего складывается стоимость каждого подхода?
Для длинного контекста счёт — это размер промпта на число запросов, уменьшенный долей попаданий в кеш. Для RAG — конвейер: загрузка данных, эмбеддинги, хостинг индекса, переиндексация при изменениях и оценочный набор, который кто-то поддерживает в актуальном виде. Дообучение стоит запусков обучения и оценки, которые повторяются при каждой смене требований или базовой модели. Чаще всего в смете не хватает пункта, общего для всех трёх: инженерного времени на оценку, которая показывает, работает ли всё это вообще.
- Длинный контекст: размер промпта на трафик и доля попаданий. Запросы с интервалом больше 5 минут промахиваются мимо кеша Anthropic по умолчанию, если не платить 2x за часовые записи. В Gemini добавляются часы, в течение которых кеш держат живым.
- RAG: объём документов и частота изменений, число подключаемых систем-источников, нужно ли зеркалировать права доступа.
- Дообучение: сколько размеченных примеров уже есть (писать их обычно дороже всего), как часто меняются требования и миграция, когда базовую модель снимают.
Небольшой внутренний инструмент по руководству на 200 страниц дешевле всего обходится как закешированный промпт. Поставьте то же руководство за нагруженный публичный ассистент с отдельным набором документов на каждого клиента, и оно становится RAG-системой.
Как каждый из них ломается в продакшене?
У каждого подхода есть свой сбой, который обычно проявляется только после запуска. Длинный контекст тихо деградирует, когда в промпт дописывают документы и он растёт, а вместе с ним растёт задержка. RAG ломается при промахе поиска: модель бегло отвечает по не тому фрагменту, и пользователи верят, потому что ответ на что-то ссылается. Дообучение ломается медленно: знания замерзают в день обучения, а новые факты, протолкнутые обучением, вытесняют те, что модель уже знала.
Лекарство во всех трёх случаях одно, и оно скучное. Держите набор реальных вопросов с известными верными ответами и прогоняйте его при каждом изменении промпта, модели, индекса или набора документов. Для RAG оценивайте поиск отдельно от финального ответа, чтобы понимать, какая половина сломалась.
Утечки — отдельная категория. Общий длинный промпт и набор дообученных весов хранят всё, что им дали, для любого, кто может к ним обратиться. Поиск с фильтрами — единственный из трёх вариантов, где правило «этому пользователю нельзя видеть этот документ» можно обеспечить кодом. Смотрите наш разбор OWASP Top 10 для LLM-приложений и статью о том, как работают ИИ-агенты, — о том, что меняется, когда модель начинает вызывать инструменты.
Можно ли их комбинировать и когда стоит?
Можно. Стоит знать два гибрида: RAG плюс длинный контекст и RAG плюс дообучение. В первом поиск сужает большой корпус до набора кандидатов — целых документов или длинных разделов (не чанков по 300 токенов), а большое окно позволяет модели прочитать их вместе с окружением. Во втором поиск поставляет актуальные данные, а дообученная модель отвечает за строгое поведение: схему, метки, тон. Новый слой мы добавляем только тогда, когда оценочный набор показывает разрыв, который более простой вариант закрыть не может.
Порядок важнее выбора гибрида. Начинайте с промпта. Кеширование добавляйте, когда префикс повторяется, поиск — когда этого требуют корпус, частота его изменений или права доступа, а дообучение — в последнюю очередь и только ради поведения. Если сначала дообучить, а потом выяснить, что факты меняются раз в неделю, вы заплатите за запуски обучения, которые обесценит следующее обновление документов.
Не уверены, что подойдёт вашим данным?
Пришлите сценарий, выборку документов и двадцать вопросов, которые ваши пользователи действительно задают. Мы скажем, с какого из вариантов выше начали бы и какая оценка подтвердит или похоронит эту идею. Подробности — на странице «ИИ и машинное обучение», либо напишите нам через форму обратной связи.