Версии промптов ChatGPT API: как менять инструкции без сюрпризов

Зачем промпту нужен идентификатор версии

Промпт — часть конфигурации продукта. Он определяет роль ассистента, ограничения, формат результата и границы инструментов. Поэтому запись «чуть поправили текст» недостаточна: у каждого выпуска должны быть понятные ID, владелец, дата, назначение и ссылка на тестовый набор. Идентификатор не должен содержать пользовательские данные, секреты или сам ключ API. Достаточно короткого значения вроде support-2026-09-02-r3, которое сервер добавляет к своей телеметрии.

Версия помогает сравнивать только сопоставимые запросы. Если на одной неделе меняются инструкция, модель, маршрут и лимиты, результат нельзя честно приписать одному изменению. Разделяйте конфигурацию модели и инструкцию: model ID, температура, лимит ответа, включённые инструменты и prompt version должны попадать в безопасный журнал отдельными полями. Не пишите туда полный prompt, сообщения клиента, Authorization или ответ модели. Для таких журналов полезны правила из руководства по логированию без утечек.

Соберите тестовый набор до редактирования

Тестовый набор представляет классы реальных задач, но не копирует чужие документы, персональные данные, платежные сведения или секреты. Для поддержки это могут быть нейтральные вопросы, отказ от опасного действия, структурированный ответ и обращение с недостающим контекстом. Для каждого кейса опишите наблюдаемый критерий: JSON проходит серверную схему, ответ не вызывает инструмент без разрешения, тон соответствует продукту, а время и объём укладываются в ваш бюджет.

Не просите модель «оценить саму себя» как единственное доказательство качества. Нужна серверная проверка формата, а сложные ответы — выборочная ручная оценка по заранее записанной рубрике. Отдельно включите отрицательные сценарии: слишком длинный ввод, неверный JSON, отмена, 429 и timeout. Они показывают, что ваше приложение корректно останавливается и не создаёт дубли. Контрактный подход подробно разобран в тестировании совместимого API.

Храните шаблон и параметры раздельно

Не собирайте систему из произвольной строки, которую можно передать в HTTP-параметре. Сервер выбирает только разрешённую версию из реестра, подставляет проверенные переменные и ограничивает размер входа. Это защищает от случайной смены роли, упрощает rollback и даёт повторяемость теста. Если в переменной может быть личная информация, минимизируйте её, задайте доступ и срок хранения согласно своим требованиям.

В OpenAI-совместимом API конкретные поля и возможности могут отличаться. Не выдавайте статью за справочник официального производителя и не предполагаете, что любой model ID поддерживает одинаковую семантику. Перед выпуском посмотрите ваш текущий каталог и документацию RussiaAPI, затем выполните синтетический server-side запрос. Ниже код рассчитан на Node.js 18+ и демонстрирует границу приложения; имена модели и версия промпта задаются вашими переменными окружения.

const promptRegistry = {
  'support-2026-09-02-r3': 'Отвечай кратко. Если данных не хватает, попроси уточнение.'
};

export async function answerSupport(input) {
  if (typeof input.message !== 'string' || input.message.length > 4000) {
    return { status: 400, body: { error: 'invalid_message' } };
  }
  const version = process.env.PROMPT_VERSION;
  const system = promptRegistry[version];
  if (!system) return { status: 503, body: { error: 'prompt_config_unavailable' } };
  const response = await fetch('https://russiaapi.com/v1/chat/completions', {
    method: 'POST',
    headers: { authorization: `Bearer ${process.env.RUSSIAAPI_API_KEY}`, 'content-type': 'application/json' },
    body: JSON.stringify({ model: process.env.RUSSIAAPI_TEXT_MODEL, messages: [{ role: 'system', content: system }, { role: 'user', content: input.message }] }),
    signal: AbortSignal.timeout(12_000)
  });
  if (!response.ok) return { status: 503, body: { error: 'assistant_unavailable' } };
  const data = await response.json();
  return { status: 200, body: { version, text: data.choices?.[0]?.message?.content ?? '' } };
}

Этот обработчик проверяет тип входа, выбирает версию только из allowlist и возвращает пользователю собственную ошибку. В production добавьте аутентификацию пользователя, tenant-права, ограничение частоты и вашу JSON-схему ответа. Не возвращайте наружу сырой текст ошибки поставщика: в нём могут быть диагностические детали, которые не нужны клиенту.

Выпускайте через feature flag

Сначала прогоните новую версию на наборе, затем включите её только внутренним тестовым пользователям или небольшой явно измеряемой группе. Feature flag должен быть серверным и иметь владельца: браузер не вправе присылать название prompt version. Для каждой версии наблюдайте долю валидного ответа, ручные отказы, задержку, стоимость успешной операции и число безопасных fallback. Не обещайте, что новая инструкция обязательно повысит качество или снизит цену: это гипотеза, которую подтверждают только ваши тесты.

Определите условие остановки заранее. Например, если нарушается схема, растёт доля контролируемых ошибок или становится невозможным нужный бизнес-сценарий, выключите флаг и верните последнюю проверенную конфигурацию. Не лечите такую регрессию бесконечными retry: повтор того же плохого запроса лишь увеличит затраты. Для постепенной смены model ID используйте отдельную практику canary rollout и rollback модели.

Что фиксировать после выпуска

Сохраняйте таблицу решений: зачем создана версия, что именно изменилось, кто проверил тестовый набор, какой флаг её включает и как вернуть предыдущую. В метриках оставьте только агрегаты и технические идентификаторы: prompt version, версия конфигурации, HTTP-класс, задержка, расход вашей единицы учёта и внутренний request ID. Если нужно расследовать один случай, сначала получите согласованный внутренний ID и проверьте доступ сотрудника, а не собирайте полные диалоги в общий чат.

Периодически удаляйте неиспользуемые версии и закрывайте флаги после закрепления результата. Это снижает число неожиданных комбинаций и делает тесты понятнее. Изменение прав инструментов или модели рассматривайте как отдельный релиз, даже если текст промпта не менялся. Совместимость endpoint не отменяет проверки формата, ролей и бюджета в вашем приложении.

Чек-лист версии промпта

1. Версия, владелец, назначение и дата проверки записаны в реестре без секретов и пользовательских данных.
2. Сервер выбирает версию из allowlist, а не из параметра браузера или клиента.
3. Есть безопасный тестовый набор, серверная проверка формата и критерии остановки.
4. Feature flag включает малую контролируемую группу и имеет проверенный rollback.
5. Журналы содержат только безопасные метаданные, а не prompt, ключ или полный диалог.

После любого изменения повторите тест с текущим model ID. Если функция недоступна по договору, правилам поставщика или применимым требованиям, отразите это честно в продукте; версия промпта не предназначена для обхода ограничений.

FAQ

Читайте также

• Контрактное тестирование API
• Canary rollout модели
• Логирование без утечек
• Документы RussiaAPI