Суть
Аддитивный метод (упрощённая версия prefix tuning): перед основным промптом ставятся виртуальные токены — непрерывные векторы, не являющиеся реальными словами. Через backpropagation обновляются только их эмбеддинги, направляя замороженную модель к нужному выводу. Аналогия из материала: «вшить сотруднику рефлекс» — модель действует «по-вашему», даже не думая об этом.
Зачем это нужно
Закрывает разрыв в иерархии дообучения: когда промпт-инжиниринга уже мало (нужен стабильный стиль/формат), а полный fine-tuning избыточно дорог. Это альтернатива бинарному выбору «промпт vs дообучение», который раньше встречался в материалах по RAG.
Как работает (иерархия выбора)
| Ситуация | Рекомендация | Почему |
|---|---|---|
| Прототип / MVP | Prompt Engineering | Быстро, ноль затрат, гибко (выбирается в ~90% случаев) |
| Нужны актуальные данные | RAG | Модель не переобучается (RAG) |
| Конкретный стиль/формат | Prompt Tuning | Дешевле fine-tuning (~5-8% случаев, от 200-500 примеров) |
| Узкий домен (медицина, юр.) | Fine-tuning | Точность на специфике (~0.01-1%) |
| Low latency, нет RAG | Fine-tuning | Знание «зашито» в веса |
| Регулируемая отрасль | Fine-tuning / RAG | Полный контроль над моделью |
Условие, без которого таблица врёт: выигрыш prompt tuning зависит от размера модели. На моделях в миллиарды параметров он догоняет полное дообучение, на небольших — уступает ему заметно. То есть строка «дешевле fine-tuning» верна для крупной замороженной модели, а не вообще.
Главное правило: всегда начинать с Prompt Engineering; переходить к Prompt Tuning только когда есть реальные данные о том, где модель ошибается — и эти ошибки нельзя исправить редактированием текста инструкции. Prompt tuning нужен для одной задачи с высоким качеством (для 2-3 задач — разные ветки).
Эволюция промптов (бонус, «писать промпты не модно»): самообучающиеся промпты через HADI-циклы — GEPA (эволюция с Парето-фронтиром), DSPy (программирование вместо текста), APE (LLM сама генерирует/отбирает инструкции), OPRO (оптимизация по истории попыток), STaR / ReST.
Когда окупается и чем настраивать
Порог по данным. Точного числа нет, но есть признак, по которому решают: обучение мягких промптов имеет смысл, когда у вас уже собран размеченный набор, на котором видно систематическую ошибку, и попытки исправить её текстовой инструкцией исчерпаны. Порядок величины — от сотен размеченных примеров; на десятках обучать нечего, и тот же результат достигается few-shot-примерами в промпте (Few Shot Prompting), которые не требуют обучения вовсе.
Практическое правило, экономящее много времени: сначала исчерпать бесплатное. Если ошибка исчезает от переформулировки инструкции или добавления примера — обучать не нужно. Если не исчезает и повторяется систематически на одном классе входа — это и есть случай для мягких промптов.
DSPy против ручной настройки. Разница не в качестве результата, а в том, есть ли у вас метрика. DSPy оптимизирует промпт автоматически, но ему нужна функция оценки и набор примеров — то есть тот же eval-набор (Agent Evals). Если он есть, автоматический подбор экономит время и находит формулировки, до которых руками не доходят. Если метрики нет, инструмент не поможет: оптимизировать нечего, и остаётся ручная работа с прямым чтением ответов.
Отсюда порядок: сначала eval-набор, потом любой автоматический подбор — в обратную сторону не работает.
Связано с
- Prompt Engineering — стартовый уровень, из которого вырастает prompt tuning
- RAG — альтернатива для «актуальных данных» в той же иерархии
- Agent Security — общий источник («Безопасность и оптимизация»), где prompt tuning — часть блока оптимизации