Функция искусственного интеллекта может быть полезной и при этом слишком медленной или дорогой для конкретной операции. Риск возникает, когда к каждому вызову относятся так, будто у них одинаковые требования: суммаризация текста в фоновом режиме не оказывает такого же влияния, как ответ на вопрос во время оплаты. Чтобы контролировать стоимость и задержку ИИ в PHP, стоит определить операционный бюджет для каждого сценария использования и заранее решить, что произойдет при его исчерпании.
Такой бюджет — не обещание качества и не гарантия того, что провайдер ответит в установленный срок. Это набор ограничений и продуктовых решений, позволяющий сдерживать влияние, информировать пользователя и контролировать поведение приложения.
Отдельный бюджет для каждой операции
Операционный бюджет объединяет ресурсы, которые может потреблять функция, и время, в течение которого имеет смысл ждать. Он может включать максимальную длительность, лимит расчетных расходов, количество попыток, объем обработанного текста или сочетание этих ограничений. Бюджет должен быть связан с узнаваемой операцией в продукте, а не представлять собой абстрактную конфигурацию, общую для всех вызовов.
Например, необязательная подсказка на панели может не отображаться, если система обрабатывает ее слишком долго. Но если функция входит в важный процесс, возможно, понадобится предложить альтернативу, позволяющую завершить сценарий без ИИ. Задача пакетной классификации может выполняться в очереди со статусом ожидания, тогда как для интерактивного ответа необходим более строгий лимит ожидания.
Чтобы выбрать ограничения, сначала уточните, какой результат нужен пользователю, обязателен ли он именно сейчас и что произойдет, если он будет недоступен. Также отделяйте бюджет от оценки качества: быстрый и дешевый ответ может быть неверным, а правильный ответ может прийти слишком поздно, чтобы быть полезным. Для этих аспектов нужны отдельные метрики и критерии.
Измеряйте, прежде чем устанавливать пороговые значения
Без базовых показателей ограничения будут лишь предположениями. Регистрируйте метрики по типам операций и наблюдайте, как они меняются в зависимости от объема, размера входных данных и условий использования. Как минимум стоит измерять общую длительность, время до первого полезного результата, если оно применимо, частоту использования и расчетную стоимость. Для асинхронных операций также регистрируйте время в очереди и время обработки.
Связывайте каждое измерение с идентификатором операции, результатом и нечувствительными контекстными данными, например приблизительным размером запроса или режимом выполнения. Не сохраняйте пользовательский текст, секреты, персональные данные или полные ответы, если они не нужны для диагностики. Если требуется расследовать конкретный случай, применяйте надлежащие меры контроля доступа, хранения и минимизации данных.
Расчетная стоимость должна основываться на информации, доступной для используемого сервиса, и учитывать его ограничения. Не путайте ее с подтвержденным списанием: цены, учитываемые единицы и оплачиваемые компоненты могут различаться. Если приложение не может надежно рассчитать стоимость до вызова, используйте альтернативные меры — например, ограничения частоты запросов и максимального размера, квоты на пользователя или мониторинг совокупных расходов.
Преобразуйте бюджет в проверяемые ограничения
Определите, где применяется каждое ограничение. Лимит на запрос не дает отдельному выполнению длиться слишком долго или потреблять слишком много ресурсов. Квота на пользователя или учетную запись ограничивает повторное использование. Лимит на процесс защищает задачу, объединяющую несколько операций. Для контроля общих расходов также отслеживайте совокупное потребление: индивидуальное ограничение не помешает множеству одновременных запросов превысить бюджет системы.
Также определите поведение повторных попыток. Автоматический повтор запроса может удвоить расходы или увеличить задержку, особенно если неизвестно, успел ли сервис обработать запрос. Установите допустимое число попыток, ошибки, при которых они выполняются, и интервал ожидания. Используйте ключи идемпотентности, если они поддерживаются и уместны, чтобы избежать повторного применения эффектов в операциях, изменяющих данные.
При достижении порога можно остановить запрос, сократить его объем, отложить выполнение в очереди или передать задачу на проверку человеком. Выбор зависит от сценария использования. Частичный ответ приемлем только в том случае, если интерфейс явно обозначает его как частичный, а результат остается безопасным и полезным. Если задача чувствительна или не допускает неполных результатов, лучше не показывать сгенерированный ответ.
Реализуйте контроль в интеграционном слое PHP
Сосредоточьте внешние вызовы в интеграционном слое, который получает операцию и ее бюджет, применяет соответствующие ограничения и возвращает явный результат. Тогда бизнес-логика не будет напрямую зависеть от провайдера и по-разному обрабатывать тайм-ауты и ошибки в разных частях приложения.
Для следующего фрагмента требуется PHP 8.0 или более поздняя версия, поскольку в нем используются свойства, объявленные в конструкторе, и именованные аргументы. Это частичный пример: он проверяет размер входных данных и передает клиенту тайм-аут, но не реализует квоты, лимиты расходов или очередь. Эти ограничения нужно добавлять отдельно в соответствии с потребностями приложения.
final class AiOutcome
{
public function __construct(
public string $status,
public ?string $content = null,
public ?string $reason = null,
) {}
}
function runAiOperation(
AiClient $client,
string $input,
int $timeoutSeconds
): AiOutcome {
if (strlen($input) > 12000) {
return new AiOutcome('rejected', reason: 'input_limit');
}
try {
$response = $client->generate($input, $timeoutSeconds);
return new AiOutcome('completed', $response->text);
} catch (TimeoutException $e) {
return new AiOutcome('timed_out', reason: 'timeout');
} catch (ProviderException $e) {
return new AiOutcome('unavailable', reason: 'provider_error');
}
}Используемый клиент и исключения зависят от выбранной интеграции. В production настройте ограничение времени также на уровне HTTP-клиента и проверяйте размер данных до отправки. Статус timed_out означает, что время ожидания запроса истекло; он не означает, что задача поставлена в очередь или будет продолжена. Возвращайте статус deferred только в том случае, если приложение сохранило задачу в очереди и располагает процессом, который сможет возобновить ее выполнение и сообщить о результате.
Чтобы завершить настройку слоя контроля, применяйте ограничения частоты запросов или квоты с помощью счетчика, согласованного между процессами, и отслеживайте совокупные расходы. Если необходимо установить лимит стоимости до каждого вызова, рассчитывайте предполагаемые расходы на запрос и сравнивайте их с доступным бюджетом; если надежно оценить стоимость невозможно, используйте альтернативные ограничения и оповещения о расходах. Общие квоты не должны зависеть только от памяти одного PHP-запроса.
Возвращайте разные статусы, например «завершено», «отклонено из-за ограничения», «истекло время ожидания» или «недоступно». Это позволит бизнес-слою решить, что показать пользователю, и не смешивать медленный ответ с ответом низкого качества, а операционное ограничение — со сбоем провайдера.
Спроектируйте понятный и полезный режим деградации
Деградация не означает, что нужно скрывать ошибку или выдавать альтернативный результат за равноценный. Она позволяет сохранить понятный пользовательский опыт, когда функция не может выполнить свою задачу. Для необязательного действия может быть достаточно сообщить, что подсказка недоступна, и позволить пользователю продолжить. Для длительной задачи покажите, что она ожидает выполнения, и предоставьте возможность проверить статус — но только если приложение способно надежно его поддерживать.
Если можно сократить объем задачи, объясните, что было исключено. При передаче на проверку не создавайте впечатление, будто результат уже проверен. Если используется детерминированная альтернатива, например существующее бизнес-правило, объясните ее роль, когда различие влияет на решение пользователя. Не обещайте доставить результат позже, если нет очереди и процесса, способных выполнить это обещание.
Fallback при сбоях отличается от контроля бюджета: он применяется в ситуациях вроде недоступности сервиса, сетевых ошибок или некорректных ответов. Бюджет может быть исчерпан, даже если сервис работает нормально. Эти механизмы нужно определять и тестировать отдельно, используя статусы и сообщения, соответствующие каждой причине.
Тестируйте, настраивайте оповещения и корректируйте на основе данных
Проверяйте пороговые значения на репрезентативных нагрузках и в неблагоприятных сценариях: больших входных данных, повторных запросах, медленных ответах, высокой параллельности, ошибках провайдера и исчерпании квот. Убедитесь, что видит пользователь и что регистрируется в системе. Включите сценарии отмены и проверьте, что остановленный запрос не продолжает без необходимости расходовать ресурсы в фоновом режиме.
Настройте оповещения об операционных аномалиях: росте задержки, увеличении числа отклоненных запросов, росте расчетных расходов или накоплении ожидающих задач. Оповещение должно указывать на условие, которое требует расследования, а не заменять анализ. Разделяйте данные по операциям, чтобы проблемный поток не терялся в общем среднем показателе.
Пересматривайте ограничения при изменении объема, пользовательского опыта продукта, размера входных данных или технической интеграции. Не смягчайте их только ради исчезновения оповещения: сначала выясните, вызвана ли проблема неверно заданными ожиданиями, неожиданной нагрузкой, сетевым сбоем или операцией, которую необходимо перепроектировать.
Контрольный список для production
- Назначение: у операции есть сценарий использования, пользователь и альтернатива на случай, если ИИ не ответит.
- Измерения: регистрируются длительность, частота, результат и расчетная стоимость без ненужного сбора чувствительных данных.
- Ограничения: установлены подходящие лимиты на запрос и, когда это необходимо, на пользователя, процесс и систему.
- Поведение: определены повторные попытки, отмена, работа очереди и реакция на достижение каждого порога.
- Пользовательский опыт: статусы и сообщения различают ожидание, отклонение из-за ограничения и сбой сервиса.
- Эксплуатация: есть тесты и оповещения, а также ответственный человек или команда, которые пересматривают ограничения.
Контролировать стоимость и задержку ИИ в PHP — не значит выбрать единственный тайм-аут для всего приложения. Это значит связать каждое ограничение с конкретной потребностью, измерять его влияние и заранее определить альтернативу, которая позволит продукту оставаться понятным и безопасным, если функция не сможет завершить работу.
