Промпт, RAG или fine-tuning: как выбрать

Короткий ответ: начинайте с промпта, факты добавляйте через RAG или инструменты, а дообучение берите, когда нужно изменить поведение модели и вы можете это измерить. Длинный ответ — дальше, потому что у каждого варианта есть случаи, где он выглядит правильным и оказывается дорогой ошибкой.

Вариантов на самом деле не три, а пять: промпт, RAG, длинный контекст, инструменты и дообучение. Их часто смешивают, потому что все пять «делают модель умнее в нашей задаче». Но делают они это разными способами.

Сначала вопрос: чего не хватает модели — знаний или поведения?

Это разделение — основа всего решения.

Знания — это факты: цены, регламенты, остатки на складе, содержание договоров, вчерашние изменения в документации. Они меняются, их нужно уметь проверить, у них есть источник.

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

Ошибка в первом же вопросе тянет за собой всё остальное. Самая частая — пытаться научить модель фактам через дообучение.

модель ошибается
├─ не хватает фактов?
│   ├─ фактов мало, они помещаются в контекст → длинный контекст
│   ├─ факты в документах                      → RAG
│   └─ факты в живой системе (CRM, склад, API) → инструменты
└─ факты есть, но поведение не то?
    ├─ сначала                                 → промпт: инструкции, примеры, формат
    └─ промпт не держит, а eval это показывает → дообучение (обычно LoRA)

Промпт — всегда первый

Промпт дёшев, обратим и меняется за минуты. Инструкции, несколько примеров нужного ответа, явная схема вывода, разбиение задачи на шаги — этого часто хватает там, где кажется, что «модель не умеет».

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

Предел у промпта тоже есть. Если формат нужен жёстко и на большом потоке, если инструкции раздуваются до страниц и модель всё равно сбивается, если вы платите за длинный промпт в каждом из множества запросов — пора считать другие варианты.

RAG, длинный контекст или инструменты — откуда брать факты

Все три доставляют факты в контекст, различается источник.

Длинный контекст — положить всё нужное прямо в промпт. Работает, когда документов немного и они стабильны. Минусы — стоимость каждого запроса растёт вместе с объёмом, а модели хуже находят нужное в середине длинного текста. В программе это разбирается отдельно, как context engineering.

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

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

Когда дообучение оправдано

Дообучение меняет саму модель, поэтому подходит для того, что должно стать её устойчивым свойством:

• стиль и формат, которые промпт держит ненадёжно или слишком дорогой ценой;
• узкий навык в вашем домене — например, разметка обращений по внутренней классификации;
• удешевление: малая дообученная модель вместо большой на массовой задаче.

Последний пункт — едва ли не самый практичный. Итоговая задача специализации LLM Engineer в нашей программе так и звучит: заменить большую модель дообученной малой и снизить стоимость задачи без потери качества по eval.

Почти всегда дообучают параметр-эффективно — LoRA или QLoRA обучают небольшую добавку к весам, а не всю модель. Это дешевле полного дообучения и в большинстве прикладных случаев его достаточно.

Где проваливается дообучение

Факты через fine-tuning. Модель после такого обучения может начать отвечать увереннее, но не правдивее: источник ответа не покажешь, а новый факт требует нового цикла обучения. В программе фраза «fine-tuning, чтобы добавить знания» без обоснования входит в список критических ошибок, которые закрывают гейт уровня L4.

Нет eval-набора. Без эталонных примеров и метрики «до» и «после» нельзя доказать, что дообучение помогло, и нельзя заметить, что модель разучилась тому, что умела. Сначала набор и замер на базовой модели, потом обучение.

Полное дообучение там, где хватило бы LoRA. Дороже по железу и по времени, сложнее откатить.

Как зафиксировать решение

Выбор механизма — архитектурное решение, и оно живёт дольше, чем кажется. Через полгода никто не вспомнит, почему выбрали RAG, а не длинный контекст, если это нигде не записано.

Минимальный формат — ADR на страницу: какая задача, какие варианты рассматривали (все пять, а не два любимых), чем измеряли, почему выбрали этот и при каких условиях решение стоит пересмотреть. Например: «RAG, пока корпус больше, чем помещается в контекст; пересмотреть, если корпус сократится или подешевеют длинные контексты».

Частые вопросы

Можно ли сочетать RAG и дообучение? Да, и это нормальная схема: дообучение отвечает за формат и манеру работы с найденными документами, RAG — за сами факты.

Сколько примеров нужно для LoRA? Зависит от задачи и того, насколько нужное поведение далеко от базовой модели. Честный ответ даёт только замер: собрали набор, обучили, сравнили на eval с промптом.

Что делать, если промпт стал огромным? Разобраться, что в нём лежит. Факты — вынести в RAG или инструменты. Правила поведения, которые модель всё равно нарушает, — кандидат на дообучение, но после того, как появится набор для проверки.

Где это в программе

Дерево решений «промпт, RAG, длинный контекст, дообучение, инструменты» — модуль L4.9, итог модуля — ADR для собственного проекта. На L6 к этому добавляется практика: как обучаются LLM, лаборатория LoRA на малой модели под нужный стиль с замером до и после. Глубоко, вплоть до preference optimization и дистилляции, дообучение изучается в специализации LLM Engineer.