Функция ИИ, встроенная в PHP-приложение, может отвечать слишком долго, быть недоступной или возвращать результат, который не подходит для процесса. Проблему не решить, если считать каждый ответ корректным или бесконечно повторять запрос: оба решения могут навредить пользовательскому опыту, данным и бюджету. Fallback для интеграции ИИ в PHP определяет, что будет делать система при сбое зависимости и какие операции не должны выполняться без приемлемого ответа.
Подходящая альтернатива зависит от влияния функции. Подсказку для текста можно временно не показывать; решение, затрагивающее платёж, разрешение или обновление данных, не следует принимать на основе неполной или предположительной информации. Цель — обеспечить предсказуемое поведение, а не скрыть все ошибки.
Определите, что считать сбоем
Прежде чем реализовывать альтернативные сценарии, укажите условия, при которых ответ нельзя использовать. Разделение случаев упрощает выбор политики и оценку её эффективности:
- Таймаут: запрос превышает установленное приложением время ожидания.
- Недоступность или ошибка транспорта: соединение прерывается либо провайдер возвращает ошибку.
- Пустой ответ: вызов завершается, но ожидаемого содержимого нет.
- Некорректный формат: результат невозможно разобрать или он не соответствует требуемой схеме, например в JSON отсутствуют поля.
- Неприемлемый результат: ответ можно прочитать, но он не проходит бизнес-правила, проверки или критерии безопасности.
Не следует приравнивать технически корректный ответ к допустимому решению. Если приложение ожидает категорию из ограниченного набора, нужно проверить, что значение входит в этот набор. Если ожидаются обязательные поля, их необходимо проверить, прежде чем передавать данные другому компоненту. Детерминированные проверки должны выполняться в PHP-коде, а не делегироваться той же модели повторно.
Ограничьте время ожидания и число повторных попыток
Установите таймаут с учётом операции и общего времени, которое пользователь или процесс может ждать. Учитывайте также ограничения веб-сервера, очереди и промежуточных HTTP-клиентов: локальный таймаут, превышающий лимит запроса, не обеспечивает реального контроля. Для фоновой задачи допустимо предусмотреть другое время ожидания, если явно определена политика обработки отложенных заданий.
Число повторных попыток должно быть ограничено; применять их следует только к потенциально временным сбоям. Обрыв сети может оправдывать ещё одну попытку, а ответ, не соответствующий схеме, обычно требует проверки, fallback-сценария или ревью, а не слепого повтора. Ограничьте количество попыток и общее время. Если используется увеличивающаяся задержка, задайте и её максимальное значение.
Помните, что повторный вызов может привести к дополнительным расходам или побочным эффектам. Не допускайте неограниченных автоматических повторов и проверьте, является ли операция идемпотентной. Генерация текста без побочных эффектов — не то же самое, что действие, создающее заказ или отправляющее уведомление. Для чувствительных операций разделите генерацию предложения и его выполнение, а для самого выполнения предусмотрите отдельные проверки.
Выберите альтернативу с учётом последствий
Fallback — это не универсальный ответ на все сбои. Он должен сохранять бизнес-правила и ясно сообщать, что приложение может сделать:
- Перейти в упрощённый режим: если ИИ лишь повышает удобство, разрешите продолжить работу без этой функции. Например, покажите обычную форму, если подсказку сгенерировать не удалось.
- Отложить: если результат можно получить позднее, сохраните задание со статусом ожидания и предусмотрите повторную обработку через очередь с ограничениями и отслеживанием.
- Запросить проверку: если требуется участие человека, покажите предложение как черновик или передайте случай специалисту. Не выдавайте непроверенный результат за окончательное решение.
- Отклонить или остановить: если невозможно проверить необходимое для выполнения условие, заблокируйте действие и объясните, как продолжить или запросить помощь.
Решение должно учитывать риск ошибочного действия, а не только неудобство от прерывания процесса. Поиск с подсказками может продолжить работу с исходным запросом. Но поток, изменяющий данные клиентов, не должен заполнять отсутствующие поля догадками. Если результат ИИ влияет на бизнес-решение, по возможности сохраняйте ручной сценарий или детерминированное правило.
Защитите целостность процессов
Считайте ответ модели внешними данными: разбирайте его структуру, проверяйте каждое значение и ограничивайте операции, которые он может инициировать. Не вставляйте ответ напрямую в SQL-запросы, команды, HTML или инструкции для других систем. Используйте параметризованные запросы, соответствующее контексту экранирование и списки разрешённых значений, а также проверки, специфичные для предметной области.
Разграничьте предложение и выполнение действия. Например, ИИ может предложить классификацию; код проверяет, допустима ли она, а политика продукта определяет, применять ли её автоматически или оставить в ожидании. Если обязательных данных не хватает, безопаснее запросить их, оставить случай незавершённым или остановить процесс, а не выдумывать значения. Поведение при сбоях также должно соответствовать обычным требованиям к разрешениям, проверкам и авторизации.
Регистрируйте сбои, не сохраняя лишнюю информацию
Логи должны помогать диагностике, не превращаясь в копию переписок. Сохраняйте технические события: операцию, тип сбоя, длительность, число попыток, результат проверки и идентификатор корреляции. Включайте достаточно данных, чтобы отличить, например, таймаут от некорректного JSON, но по умолчанию не записывайте полные промпты, ответы, учётные данные или персональные данные.
Если для ревью или аудита необходимо сохранять содержимое, заранее определите цель, права доступа, срок хранения и меры защиты. В метриках отслеживайте частоту таймаутов, некорректных ответов, срабатываний fallback и отложенных заданий, а также задержку и повторы. Рост этих показателей может указывать на операционную проблему или изменение поведения ответов. Метрики помогают выявлять тенденции, но не заменяют проверку конкретного случая и сами по себе не доказывают корректность ответа.
Проверьте сценарии и согласуйте критерии
Тестируйте интеграцию с контролируемыми ответами и проверяйте как результат, видимый пользователю, так и эффекты в системе. Учтите высокую задержку, обрыв соединения, пустой ответ, некорректный формат, значение, не соответствующее правилам, и восстановление после сбоя. Убедитесь, что действия не выполняются повторно, повторы соблюдают ограничения, а логи не раскрывают чувствительное содержимое. Также проверьте, что происходит, если задание остаётся отложенным или требует вмешательства.
Прежде чем выводить функцию в production, согласуйте с командами продукта и разработки следующие решения:
- Обязательна ли эта функция для завершения операции или она лишь улучшает пользовательский опыт?
- Какое общее время ожидания допустимо для каждого канала?
- При каких сбоях разрешены повторы и сколько их допускается?
- Какова безопасная альтернатива: продолжить без ИИ, отложить, запросить проверку человеком или остановить процесс?
- Какие проверки должен пройти ответ, прежде чем его можно будет использовать?
- Какие данные записываются, кто может получить к ним доступ и как долго они хранятся?
- Как команда получает оповещения и кто обрабатывает отложенные случаи?
Полезная политика позволяет переводить второстепенные функции в упрощённый режим и останавливать операции, зависящие от непроверенных данных. Если нельзя точно объяснить, что произойдёт при задержанном, некорректном или отсутствующем ответе, у интеграции ещё нет рабочего fallback-сценария. Документируйте эти правила вместе с описанием потока и повторно тестируйте их при изменении продукта, проверок или способа использования сервиса.
