Промпт — самая часто меняющаяся часть системы с моделью. Его правят при каждой жалобе на качество, при смене модели, при появлении нового класса случаев.
И это же часть, которую чаще всего не версионируют: строка в коде или, хуже, поле в базе, которое кто-то поправил через админку.
Последствия предсказуемы. Через полгода никто не помнит, почему промпт выглядит именно так, что будет, если убрать абзац, и когда именно система стала работать хуже.
Что хранить вместе с промптом
Сам текст — не всё. Полезно хранить:
| Что | Зачем |
|---|---|
| Версия | на что ссылаться при разборе |
| Дата и автор | кто и когда менял |
| Что изменено и зачем | через полгода это единственный источник |
| Модель, под которую отлажен | промпты не переносятся между моделями свободно |
| Результат на проверочном наборе | было и стало |
| Схема ответа | меняется вместе с промптом |
| Статус | черновик, боевой, отключён |
Строка про результат на наборе — самая ценная. Она превращает историю правок из хроники в данные: видно, какое изменение что дало.
Где хранить
В репозитории вместе с кодом — простой и надёжный вариант. Отдельные файлы, история изменений, сравнение версий, откат — всё это уже есть в системе контроля версий, ничего изобретать не нужно.
Минус: правка требует выкатки. Для большинства проектов это не проблема.
В базе с версионированием — когда промпты меняют не разработчики. Нужны: неизменяемые версии, явное переключение боевой версии, история, права доступа.
Опасность: правка «на живую» без прогона набора. Если такая возможность есть, ею воспользуются.
Через шлюз моделей — если он у вас есть, промпты естественно живут там же — «Шлюз моделей».
Чего делать не стоит: держать промпт строкой в коде вперемешку с логикой и править его правкой кода без отметки о причине.
Порядок изменения
Шаг 1. Понять, что чиним. Не «стало хуже», а конкретный класс случаев с примерами из журнала.
Шаг 2. Зафиксировать исходное состояние — прогон набора на текущей версии.
Шаг 3. Одно изменение за раз. Иначе непонятно, что сработало.
Шаг 4. Прогнать набор. По классам случаев отдельно, а не в среднем — «Тестирование модели на своей задаче».
Шаг 5. Сравнить по всем классам. Ключевой шаг: улучшение целевого класса не должно ухудшать остальные.
Шаг 6. Выкатить с возможностью вернуться.
Шаг 7. Наблюдать. Проверочный набор не покрывает всего; часть эффектов видна только на потоке.
Разбор: поломка, которую искали неделю
Задача. Конвейер обработки документов, работал стабильно несколько месяцев.
Симптом. Выросла доля документов, уходящих на ручную проверку. Не резко — постепенно, примерно за две недели.
Что проверяли сначала. Модель — не обновлялась. Поток документов — не изменился по составу. Среда запуска — та же.
Что мешало разбираться. Промпт хранился в базе и правился через административный интерфейс. Истории изменений не было — только текущее значение. На вопрос «менялся ли промпт» ответить было нечем.
Что нашли. Опросили причастных. Выяснилось: за две недели промпт правили трижды разные люди. Каждая правка решала свою частную задачу — попросили лучше обрабатывать один тип документов, потом другой.
Ни одна правка не прогонялась на проверочном наборе. Каждая улучшала свой класс и незаметно ухудшала соседние.
Суммарный эффект: целевые классы стали лучше, основной поток — хуже. Поскольку основной поток составлял большую часть, итог оказался отрицательным.
Что сделали.
Перенесли промпты в репозиторий: правка стала проходить через выкатку с историей.
Ввели обязательный прогон набора перед выкаткой, автоматически.
Добавили сравнение по классам случаев, а не по общей доле верных ответов.
Восстановили работающую версию — собирали по памяти участников, потому что истории не было.
Сколько стоило. Неделя на поиск причины. С историей изменений это было бы полчаса: сравнить версии и прогнать набор на каждой.
Что стоит забрать. Отсутствие истории промптов не выглядит проблемой, пока всё работает. Оно становится проблемой ровно в тот момент, когда нужно понять, что изменилось, — и тогда стоит недели.
Отдельно про правку через админку
Возможность менять промпт без разработчика удобна и опасна одновременно.
Что она даёт: быстрое исправление, независимость от цикла выкатки, вовлечение людей, знающих предметную область.
Что ломает: правки без проверки, отсутствие истории, несколько человек правят независимо, никто не видит общей картины.
Как совместить, если такая возможность нужна:
- версии неизменяемы, новая правка создаёт новую версию;
- прогон проверочного набора обязателен перед переключением боевой версии, а не по желанию;
- переключение — отдельное действие, отличное от редактирования;
- в интерфейсе видна история: кто, когда, что изменил и с каким результатом на наборе;
- возврат к предыдущей версии — в один шаг.
Без этих условий правка через админку рано или поздно приводит к описанному выше.
Что версионировать помимо промптов
Всё, что влияет на поведение системы и меняется:
- схемы ответа — вместе с промптами, они связаны;
- параметры генерации;
- версия и настройки модели;
- правила маршрутизации между моделями;
- проверочный набор — он тоже растёт, и результаты сравнимы только внутри одной его версии.
Последнее упускают: если набор изменился, сравнивать результаты «до» и «после» нельзя.
Частые вопросы
Зачем версионировать промпты?
Потому что это самая часто меняющаяся часть системы, а каждое изменение может незаметно ухудшить работу на классах случаев, о которых при правке не думали. Без истории вопрос «когда и почему стало хуже» превращается в расследование на недели вместо получаса.
Где лучше хранить промпты?
В репозитории вместе с кодом, если правят разработчики: история, сравнение версий и откат уже есть в системе контроля версий. В базе с версионированием — если правят люди без доступа к коду, но тогда обязательны неизменяемые версии, отдельное действие переключения боевой версии и принудительный прогон проверочного набора.
Можно ли давать правку промптов не разработчикам?
Можно, если правка не равна выкатке: новая версия создаётся, но становится боевой только после прогона проверочного набора. Без такого условия несколько человек будут независимо править под свои задачи, каждый улучшая свой класс случаев и ухудшая остальные.
Что хранить вместе с текстом промпта?
Версию, дату, автора, описание изменения, модель, под которую он отлажен, и результат на проверочном наборе. Последнее превращает историю правок в данные: видно, какое изменение что дало, и не приходится вспоминать.
Как понять, что промпт сломали?
Прогоном проверочного набора по классам случаев до и после изменения. Общая доля верных ответов может почти не измениться, а конкретный класс просесть заметно — и именно он окажется основным потоком.
Нужно ли версионировать проверочный набор?
Да. Набор растёт и меняется, а результаты сравнимы только внутри одной его версии. Сравнение результата на старом наборе с результатом на новом ничего не показывает, хотя выглядит убедительно.
Что дальше
Что менять в промпте и что действительно влияет — «Промпт-инжиниринг в продукте». Как построить набор для проверки — «Тестирование модели на своей задаче». Где промпты естественно живут — «Шлюз моделей». Как переносить промпты при смене модели — «Миграция между моделями».
Организация сопровождения систем с моделями — часть работы по разработке и внедрению ИИ и сопровождению решений.