Рекомендации для работы в продакшене

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

Надёжность

• Повторяйте запросы при подходящих кодах ответа. 429, 500, 502, 503, 529 с экспоненциальным увеличением задержки и случайным разбросом. Никогда не повторяйте вслепую 400, 401, 402 или 403.
• Задавайте тайм-ауты. Длительная генерация вполне может занимать несколько минут; зависшее соединение не должно блокировать рабочий процесс. Для вызовов без потоковой передачи разумный верхний предел — 120 секунд.
• Ограничивайте число одновременных запросов с помощью семафора, вместо того чтобы отправлять всё сразу и повторять отклонённые запросы.
• Предусмотрите резервную модель. Если основная модель перегружена, переход на менее мощную модель лучше, чем возврат ошибки.

Стоимость

• Задайте max_tokens при каждом вызове. Это ограничение расходов, а не рекомендация.
• Выбирайте модель в зависимости от задачи — см. Контроль затрат.
• Включите кэширование промптов для стабильных префиксов.
• Записывайте в журнал usage для каждого запроса с меткой задачи, чтобы впоследствии можно было определить, на что ушли средства.

Безопасность

• Храните ключи в переменных окружения или менеджере секретов — никогда в репозитории или клиентской сборке.
• Используйте отдельный ключ для каждого сервиса, чтобы можно было точечно отзывать доступ.
• Никогда не составляйте промпты, объединяя недоверенный пользовательский ввод с инструкциями через конкатенацию строк; храните пользовательский контент в сообщении user а инструкции — в system.
• Считайте вывод модели недоверенным. Не eval его и не выполняйте сгенерированный SQL с ролью, имеющей права записи.

Наблюдаемость

• Для каждого вызова записывайте в журнал модель, задержку, usage, stop_reason и собственный тип задачи.
• Настройте оповещения о доле stop_reason: max_tokens — её рост означает, что ответы обрезаются.
• Отслеживайте расходы по типам задач, а не только общую сумму. Общие показатели скрывают, для какой нагрузки расходы выросли.