Модуль 4. Промптинг, RAG или дообучение: лестница решений
Цель модуля: по симптому «базовая модель отвечает не так» выбрать правильную ступень — промптинг, RAG или fine-tuning — и защитить выбор ценой: время, деньги, риск. После модуля вы не лечите нехватку фактов дообучением и не пишете гигантский промпт там, где нужны две эпохи на своём датасете.
Перед началом: модули 1–3: токены и лимит контекста (модуль 1), chat template и few-shot (модуль 3), почему модель «не знает» ваших фактов (модуль 3). Инструменты: песочница сайта, текстовый редактор; LLM-чат — по желанию. Трудоёмкость: ~1.5 ч (теория 50 мин · практика 30 мин · квиз 10 мин).
🔥 «Нужно, чтобы модель отвечала в стиле нашей базы знаний»
Пятница, планёрка. Задача сформулирована: «модель должна отвечать в стиле нашей базы знаний поддержки». Все кивают. Дальше команды расходятся — и через месяц приносят три разных решения: одна прикрутила инструкцию к промпту, вторая положила базу знаний в контекст через поиск, третья дообучила модель на тикетах. Задача была одна, а потраченное время отличается на два порядка.
Никто не выбрал «неправильно» — выбрали не осознанно. Фраза «в стиле базы знаний» склеивает три разные потребности: знать наши факты, говорить нашим тоном и устойчиво вести сценарий диалога. У каждой — своя ступень решения и своя цена. В этом модуле учимся разнимать эту склейку до того, как потрачены недели.
📖 4.1. Лестница: контекст против весов
В модулях 1–3 мы выяснили: у модели ровно два места, куда можно «положить» новое, — контекст запроса и веса. Из этого вырастает лестница решений.
Диаграмма — дерево решений. Сверху один вопрос: «Что не так с ответами базовой модели?» — и три ветви. Ветвь «не знает НАШИ факты: база знаний, регламенты, свежая документация» ведёт к RAG — найти релевантные документы и положить их в контекст запроса. Ветвь «говорит не так: тон, формат, жаргон, структура ответа» ведёт к промптингу — инструкция и few-shot примеры прямо в контексте. Ветвь «путается в сценарии: классификация, разметка, устойчивые шаблоны диалога» — к fine-tuning. С узла промптинга есть боковая стрелка «не помогло? формат „не лезет“ в контекст» — вниз, к fine-tuning: инструкция работает, но съедает половину окна и её нужно тащить в каждом запросе — значит, поведение пора переносить в веса.
Отдельно посмотрите на пунктирные стрелки цен. Промптинг — «часы работы, ₽0, правится мгновенно». RAG — «дни: индексация, эмбеддинги, поиск + реранкинг». Fine-tuning — «недели: датасет, обучение, evals, эксплуатация версий». Направление лестницы обязательно: начинаем с самой дешёвой ступени и поднимаемся, только когда она объективно не справляется, — не «потому что дообучение солиднее».
📖 4.2. Что умеет каждая ступень (и чего не умеет никакая)
Промптинг меняет поведение в рамках одного запроса: инструкция в system prompt, few-shot пары «запрос → эталонный ответ» (модуль 3). Идеален для формата и структуры: «отвечай тремя абзацами, в конце — список шагов». Ограничен окном контекста и мягкостью управления: модель может проигнорировать инструкцию, особенно под давлением пользователя.
RAG решает ровно одну проблему — факты. Поиск по вашей базе кладёт в контекст актуальный фрагмент, и модель отвечает по нему, а не выдумывает. База обновляется без переобучения: изменились цены — изменился поиск. Слабое место: качество ответа равно качеству поиска; промахнулись релевантностью — получили уверенно неправильный ответ.
Fine-tuning переносит в веса то, что не выражается словами инструкции: тон компании, устойчивый формат, доменный жаргон, устойчивость к попыткам «переубедить» модель в диалоге. Каждая пара датасета — голос «так правильно», и после сотен повторений модель отвечает так по умолчанию, без инструкции в каждом запросе.
Есть границы, которые не переступает ни одна ступень. Fine-tuning не даст модели свежие факты (веса устаревают в момент сохранения чекпойнта), не научит надёжной арифметике (модель предсказывает токены, а не считает, м2) и не «выучит базу знаний»: попытка зашить тысячи документов в веса кончается галлюцинациями. Требование точности факта — это всегда RAG.
📖 4.3. Таблица «симптом → ступень»
| Симптом | Ступень | Почему |
|---|---|---|
| «Не знает регламент / цены / внутренние документы» | RAG | факты меняются, им место в поиске, не в весах |
| «Ответ не в том формате: нужен JSON / шаблон» | Промптинг | формат описывается словами и few-shot |
| «Тон не тот, хотя инструкция уже написана» | Fine-tuning | стиль передаётся примерами, а не словами |
| «Говорит "забудь инструкцию" — и модель ломается» | Fine-tuning | устойчивость тренируется на примерах давления |
| «Классификация тикетов с фиксированными метками» | Fine-tuning (классификатор) | задача — разметка, а не генерация (модуль 5) |
| «Модель не понимает доменный жаргон» | Промптинг → FT | сначала глоссарий в контекст; не лезет — в веса |
| «Данные обновляются каждый день» | RAG | дообучение не успевает за фактами |
Читайте таблицу справа налево: если «почему» звучит как «факты» — это RAG; если «поведение по умолчанию» — fine-tuning; всё остальное сначала пробуем промптом. Симптомы из одной колонки можно сочетать: «тон + факты» — это гибрид из 4.4, а не «самая верхняя ступень на всё».
📖 4.4. Гибриды и цена итерации
Часто лучший ответ — не ступень, а сочетание: fine-tuning учит модель, КАК говорить (тон, формат, устойчивость), а RAG подкладывает, ЧТО говорить (факты из базы). На диаграмме это узел «Гибрид», к которому сходятся ветви FT и RAG. Типовая связка для поддержки: дообученный тон + поиск по базе знаний в каждом запросе.
Прежде чем подниматься по лестнице, посмотрите вниз — на нулевую ступень. Значительная доля трафика LLM-фичи — повторные или почти повторные вызовы: один и тот же классификатор, одинаковые вопросы, ретраи. Их не нужно ни промптить, ни дообучать — их нужно кэшировать. В рабочем сервисе связка «exact-кэш ответов» (ключ — нормализованный запрос к конкретной модели, у каждого класса запросов свой TTL) плюс учёт префикс-кэша провайдера показала ~98% попаданий на повторном префиксе: попадание возвращает готовый ответ мгновенно и записывает в журнал сэкономленные деньги, не трогая бюджет. Порядок инженера: сначала измерьте долю повторов, поставьте кэш — и только потом оценивайте, осталась ли задача для ступеней лестницы.
Считайте не только цену входа, но и цену каждой итерации. Промпт правится за минуты и откатывается мгновенно. RAG-итерация — переиндексация и настройка поиска, дни. Fine-tuning-итерация — новый датасет, обучение, оценка, версионирование (модуль 12): недели. Полный цикл «логи и фидбек → датасет → гигиена → тюнинг → оценка → A/B → прод → снова логи» показан диаграммой в модуле 12; здесь достаточно запомнить: чем выше ступень, тем дороже каждый следующий шаг по ней.
| Ступень | Время до результата | Деньги | Риск и откат |
|---|---|---|---|
| Промптинг | часы | только токены | минимальный; откат — вернуть текст |
| RAG | дни | индексация, хранение, поиск | средний; качество = качество поиска |
| Fine-tuning | недели | GPU-время, разметка, люди | высокий; нужны eval и версии (модули 8, 12) |
📖 4.5. Компромиссы
- Промпт vs RAG: промпт дешевле и мгновенен, но факты в нём устаревают и съедают контекст; RAG свеж и масштабируется на тысячи документов, но добавляет инфраструктуру и новую точку отказа — поиск.
- RAG vs fine-tuning: RAG отвечает за факты, fine-tuning — за поведение; попытка решить чужую задачу (факты через FT, тон через RAG) даёт галлюцинации и «мёртвый» стиль соответственно.
- Fine-tuning vs гибрид: чистый FT проще в эксплуатации (одна модель, без поиска), но врёт фактами; гибрид точнее, но у него два источника ошибок — модель и поиск.
- Быстрый эксперимент vs инвестиция: промпт-прототип за час покажет потолок задачи почти бесплатно; на fine-tuning идите, когда прототип упёрся в ограничение подхода, а не в качество промпта.
💻 Практика
- (10 мин) Разберите кейс из крючка. Выпишите из фразы «в стиле базы знаний» три потребности: факты, тон, сценарий. Для каждой — ступень по диаграмме и цена по таблице 4.4. Результат — три строки решения.
- (10 мин) Свой домен. Возьмите свою рабочую область (поддержка, docs, продажи). Сформулируйте пять реальных симптомов и поставьте каждому ступень по дереву решений. Для одного обоснуйте, почему ступень выше не нужна.
- (10 мин) Промпт-прототип. Для кейса «тон базы знаний» напишите system prompt с инструкцией и тремя few-shot парами «запрос → эталон». Прикиньте объём промпта в токенах по правилу из модуля 1 и решите: сколько таких инструкций выдержит окно контекста и когда путь один — в FT.
🧩 Quiz "Проверь себя"
✅ Итоги модуля
- Разложить жалобу «модель отвечает не так» на факты / тон / сценарий.
- Назвать по диаграмме, какая ветвь ведёт к RAG, какая к промптингу, какая к fine-tuning.
- Объяснить, почему свежие факты и арифметика — не задача fine-tuning.
- Составить таблицу «симптом → ступень» для своего домена.
- Объяснить устройство гибрида «FT для стиля + RAG для фактов».
- Сравнить цену входа и цену итерации трёх ступеней.
🔗 Мостик к Модулю 5
Допустим, лестница привела вас на верхнюю ступень: поведение модели должно проживать в весах, а не в промпте. Тогда главное слагаемое успеха — уже не модель и не гиперпараметры, а данные: что именно вы покажете модели как «правильно». Следующий модуль — «Датасет — 80% результата»: форматы JSONL, источники пар, гигиена данных и ответ на вопрос «сколько нужно примеров».