Чек-лист готовности к производственному использованию ИИ-агентов, разделенный на этапы.

Переход от рабочего прототипа ИИ-агента к его реальному внедрению происходит по предсказуемой схеме, причем на каждом этапе существуют свои проверки, а также способы возникновения ошибок при их пропуске. В данном обзоре рассматриваются все этапы по порядку.

Прототип выполняет одну задачу — демонстрировать работоспособность идеи: одна машина, состояние в памяти, отсутствие реальных пользователей. В производственных условиях требуется гораздо больше: система должна выдерживать перезагрузки, обслуживать несколько пользователей одновременно, восстанавливаться после сбоев на любом этапе и сохранять записи, которые позволяют отследить проблемы.

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

Этап 1: разработка и локальный прототип

Цель здесь намеренно узка: доказать, что основная идея вообще работает. Пока не создавайте версию, предназначенную для производства. Слишком раннее применение такой версии обычно означает создание неподходящей инфраструктуры для ещё не сформировавшейся концепции.

Сначала заставьте работать основной рабочий процесс в максимально упрощённом виде. Добейтесь одного чистого прохождения данных от входных данных до правильного вывода до того, как в дело вступят очереди, базы данных или процесс развертывания.

Почему: Ранние выборы инфраструктуры обычно бывают неверными, поскольку истинная природа проблемы неизвестна: время выполнения, размер состояния и способы сбоев — всё это пока лишь предположения. Версия производственного уровня, созданная сразу, обычно всё равно приходится пересоздавать.

Пример: Агент, отвечающий за сортировку заявок на поддержку, начинает свою работу с простого скрипта: он читает одну заявку, запрашивает у модели категорию и выводит ответ. Сервера и базы данных нет, и скрипт запускается вручную из терминала.

Сделайте поведение системы настраиваемым, а не жестко заданным в коде. Когда системе необходимо действовать по-разному в зависимости от входных данных — таких как сегменты клиентов, типы документов, языки или тон общения — регулируйте это с помощью настроек, а не добавляйте новые ветки кода.

Почему: Количество вариантов быстро растет по мере появления пользователей («Работает ли система с заявками на французском?», «Могут ли корпоративные аккаунты иметь более строгий тон?»). Если для каждого варианта требуется изменение кода и выпуск обновления, новые случаи накапливаются в очереди у инженеров, тогда как с использованием настроек их можно быстро скорректировать.

Пример: Вместо условий if/else в зависимости от уровня клиента инструкции агента формируются из небольших текстовых шаблонов — одного базового и по одному на каждый уровень. Для добавления нового уровня необходимо добавить соответствующий файл.

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

Почему: Недостаток, который никто не зафиксировал, позже приводит к неожиданностям, обычно обнаруживаемым во время инцидента, а не во время планирования. Зафиксированный недостаток становится чек-листом для следующего этапа.

Пример: Краткая таблица с такими строками, как «состояние хранится в словаре Python, поэтому требуется надежное хранилище», «одновременно может выполняться только одна задача, поэтому необходима поддержка одновременных запусков» и «отсутствуют записи о произошедшем, поэтому нужен журнал аудита». На этом этапе ничего не фиксируется — элементы просто получают названия.

Этап 2: тестовая среда и стадия подготовки

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

Выберите среду выполнения, соответствующую реальной нагрузке. Прежде чем решить, где будет располагаться агент, ознакомьтесь с конкретными цифрами: максимальное время работы, стоимость простоя и возможность возобновления работы прерванного процесса.

Причина: Нагрузка на агентов редко соответствует обычным веб-запросам. Один запуск может длиться несколько минут и требует передачи большого объема контекста на протяжении множества этапов. Среда выполнения, предназначенная для краткосрочных запросов, выдаст таймаут в процессе работы, а среда, рассчитанная на постоянный трафик, будет слишком дорогой для процессов, выполняющихся всего несколько раз в день.

Пример: Агент для проверки юридических документов обрабатывает их разделы по одному за один запуск, чтобы сохранить полный контекст; обработка длинного документа может занять от 10 до 15 минут. Это исключает использование безсерверных функций с жестким лимитом времени. Также исключается использование непрерывно работающих контейнеров, поскольку агент запускается лишь несколько раз в день, и простаивающая мощность будет бездействовать. Длительные, периодические запуски указывают на среду выполнения, которая взимает плату только за время активной обработки и не имеет таймаута.

Перенесите состояние из памяти в надежное, общедоступное хранилище. Все то, что должно сохраняться после перезагрузки или быть видимым для нескольких серверов — такое как статус выполнения, история разговоров и результаты текущих операций — должно храниться в реальном хранилище данных, а не в переменных внутри работающего процесса. Выберите одну систему в качестве источника истины.

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

Пример: В этом случае агент для редактирования документов хранит информацию о состоянии обработки, историю чатов и предлагаемые изменения в хранилище объектов, не сохраняя ничего в процессе обработки запросов. Хранилище объектов является единственным источником истины, а база данных используется только для одной узкой задачи — блокировки операции, чтобы предотвратить одновременную обработку одной и той же операции двумя процессами. Общее состояние не делится между ними, и нет правил, определяющих, который из них победит.

Предположим, что «эта операция выполнялась дважды» и «эти операции выполнялись одновременно». Большинство реальных систем мессенджеров могут отправлять один сигнал несколько раз. Простая проверка статуса («начать, если ещё не начато») не сработает, поскольку оба процесса могут прочитать значение «не начато» до того, как кто-либо из них занесёт запись «начато». Необходим механизм, позволяющий именно одному из процессов победить.

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

Пример: Ранняя система блокировок для заявок на выполнение работала в нормальных условиях, но не могла освободить заявку, если процесс, её державший, завершился или застрял. В производственной среде это приводило к тому, что множество заявок оставались в статусе «обработка» на несколько дней, и не было способа их восстановить. Для устранения проблемы были добавлены механизм истечения срока аренды, токен, предотвращающий путаницу между восстановленным процессом и первоначальным владельцем блокировки, а также периодический сканирование для возврата заявок, срок аренды которых истёк без завершения работы. Это намного надёжнее, чем простое правило «заявить о блокировке один раз».

Внедряйте функции отслеживания и логирования до того, как к ним возникнет необходимость из-за инцидента. Когда задействовано более одного сервиса — такого как веб-слой, очередь, рабочий процесс и среда выполнения ИИ — одно действие пользователя проходит через каждый из них. Сразу же найдите способ отслеживания этого пути между сервисами, чтобы не пытаться восстановить его уже во время сбоя.

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

Пример: В системе с ИИ в режиме выполнения с самого начала существовала подробная трассировка, но сервис, доступный через веб, не имел такой функции; поэтому трассировка показывала всё, что делал агент, но не запрос, который его запустил, поскольку между ними не было никакой связи. Решением стало создание уникального идентификатора запуска в момент поступления запроса и передача его в логи каждого сервиса, чтобы один поиск позволял получить полный путь конкретного запуска, даже если две системы трассировки оставались раздельными.

Попробуйте настоящий клиент заранее. Когда пользователи подключаются к системе через определённый браузер, приложение или устройство, как можно скорее проведите тесты именно на этом инструменте, не ограничиваясь обычным API-клиентом или его упрощённой версией.

Причина: У реальных клиентов бывают особенности, такие как ограничения по длине, скрытое обрезание данных и нестандартная кодировка, которые не обнаружат универсальные инструменты. Эти проблемы обычно проявляются только у реальных пользователей, к тому времени уже превращаясь в инцидент в производственной среде, а не в проблему, обнаруженную на этапе тестирования.

Пример: Функция открытия документов в десктопном приложении проходила все автоматизированные тесты, но у пользователей одной операционной системы работала с периодическими сбоями. Приложение скрыто обрезало ссылки на загрузку при превышении определённой длины, а временные учетные данные, используемые для подписи ссылок, приводили к тому, что длина подписи значительно превышала допустимый лимит. Решением стало использование отдельной идентичности для подписи ссылок, которая генерирует гораздо более короткую подпись, вместо временных учетных данных, используемых остальной частью системы.

Соотнесите сетевой путь входных дверей с способом подключения клиентов. Если пользователи могут подключиться к системе только через частную сеть, такую как VPN, прокси с моделью нулевого доверия или сеть, доступная только внутри организации, убедитесь, что адрес, который они используют, действительно ведет к ресурсам на том же частном пути от начала до конца. Домен, выглядящий как внутренний, но на самом деле перенаправляющий трафик на публичный балансировщик нагрузки или CDN, может работать для некоторых пользователей, но периодически отказывать у других.

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

Пример: Внутренний инструмент предназначался к использованию исключительно через корпоративную сеть посредством прокси с политикой нулевого доверия, который направлял трафик через различные соединители в зависимости от выбора каждого ноутбука. Домен этого инструмента казался внутренним, однако на самом деле указывал на публичную сеть доставки контента. Некоторые соединители могли обращаться к этому публичному адресу, в то время как другие могли доступаться только к частным адресам, поэтому сбои появлялись и исчезали в зависимости от используемого соединителя. Решением стало размещение входного порта на балансировщике нагрузки внутри частной сети, к которому можно было обращаться по тому же маршруту, что и реальные пользователи, плюс отдельный зашифрованный путь для одного десктопного приложения, которое вообще не могло использовать прокси.

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

Почему: Процессы, управляемые агентами, редко состоят из одного запроса и одного ответа. Они включают несколько этапов, вызовы инструментов и постепенное получение обновлений, что затрудняет тщательную проверку вручную. Тесты на единицы и интеграцию обычно проверяют отдельные компоненты, а не полную реалистичную сессию. С помощью виртуального клиента вопрос о том, прошла ли корректно полная многоэтапная конверсация, становится проверкой, которую можно выполнить в любой момент.

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

Выберите момент, когда человек может просмотреть результаты работы агента перед тем, как они вступят в силу. Необходимо предусмотреть возможность для человека увидеть, что собирается сделать агент, и иметь возможность одобрить, изменить или отклонить это действие, вместо того чтобы позволять результатам сработать автоматически с первого дня.

Причина: Ошибки агента отличаются от обычных багов. Они кажутся правдоподобными, но ошибочными, и не похожи на явные сбои. Проверка человеком позволяет обнаружить те ошибки, которые проходят все автоматические тесты, и формирует базу данных, необходимую для последующего определения того, где агент может безопасно действовать без проверки.

Пример: Агент для редактирования документов никогда не записывает изменения в окончательный документ. Он предлагает предложения, которые рецензент может принять, отклонить или изменить по отдельности, поэтому ничто из того, что он создает, не считается окончательным до тех пор, пока человек не примет решение.

Этап 3: предпроизводство

Это последняя среда перед реальными пользователями. Вопрос смещается с «работает ли функция?» на «продолжает ли весь процесс работать при неидеальных условиях?» Это включает в себя многократные развертывания, частичные сбои и изменения при замене модели или вводных данных.

Необходимо разработать надлежащую систему оценки, поскольку одних показателей «успех/неудача» недостаточно. Нужно определить, что означает «хорошо» для результата работы агента, что обычно включает несколько критериев (правильные действия на входных данных, существенная корректность, последовательность результатов при повторных запусках), а также определить, кто или что будет проверять каждый из этих критериев: фиксированное правило, человек-рецензент или отдельная модель, выступающая в роли судьи.

Почему: Результаты работы агента редко бывают просто правильными или неправильными, как в утверждениях единичных тестов. Одиночный сигнал «успех/неудача» не позволяет понять, в чем именно произошло ухудшение, а метод оценки, который никто тщательно не анализировал, особенно автоматизированный судья, может постепенно отклоняться от того, что действительно важно для пользователей этих результатов.

Пример: Оценка агента-суммаризатора осуществляется по трём критериям: охват ключевых фактов, наличие выдуманного контента, отсутствующего в исходном материале, и степень изменчивости его результата при двух последовательных обработках одного и того же входного данных. Человек проверяет примеры на наличие «выдуманного контента», поскольку именно эта ошибка стоит дороже всего.

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

Почему: В отличие от обычного кода поведение агента может незаметно меняться после небольших изменений в запросе или обновления модели, при этом ни один тест не выдаст ошибку. Зафиксированный набор примеров часто является единственным способом заметить ситуацию, когда «агент работает нормально, но качество результатов постепенно снижается».

Пример: Агент для редактирования документов проверяется на фиксированном наборе примеров тремя способами: определяется, выбрал ли он правильные разделы для редактирования (по сравнению с ответами, проверенными человеком), верны ли предложенные им изменения (оцениваются отдельной моделью судьи), и насколько сильно меняется его результат при повторных запусках с одинаковым входным данным. Анализ всех трех показателей в разных версиях, а не просто одного результата «успех/неудача», показал, что одно изменение улучшило один показатель, но при этом незаметно ухудшило другой.

Пусть неудачная проверка останавливает выпуск. Набор тестов, при неудаче которого всё равно разрешается развертывание, является лишь формальностью. Необходимо связать результаты с процессом развертывания так, чтобы неудача приводила к его остановке, и чтобы обход этого правила не становился стандартной практикой.

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

Пример: Пайплайн настроен таким образом, что при сбое любого теста шаг развертывания никогда не выполняется. Кнопки вроде «развернуть всё равно» не существует, и чтобы обойти это ограничение, необходимо сознательно изменить конфигурацию пайплайна, а не просто нажать кнопку в предупреждении.

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

Почему: Кэши, прямые соединения и подобные ускорения — это те элементы, которые с наибольшей вероятностью могут выйти из строя в производственной среде. Без альтернативы небольшой сбой в одном компоненте приводит к полной недоступности всей функции.

Пример: Обновления обычно поступают в течение секунды по каналу push-соединения. При тестировании с выключенным таким соединением система вместо этого запрашивает данные каждые несколько секунд — это более медленный способ, но результаты всё равно отображаются пользователю.

Позвольте инструментам обеспечивать соблюдение порядка, когда одна вещь должна существовать до другой. Если часть A должна быть готова до того, как можно настроить часть B, включите эту последовательность в процесс развертывания, а не в память человека.

Почему: Правило вроде «развернуть X до Y» действует только до тех пор, пока человек, который его знает, отсутствует, или пока кто-то не автоматизирует процесс, не зная об этом правиле. Важные последовательности должны находиться в инструментах.

Пример: Служба оркестрации требует ID среды выполнения ИИ, созданной другой стеком развертывания, и если каждый стек будет ссылаться на другой, это приведёт к циклу. Поэтому стек среды выполнения при создании записывает свой ID в общий хранилище параметров, а стек оркестрации читает его оттуда. Гарантируется, что среда выполнения существует раньше, и стеки никогда не ссылаются друг на друга.

Этап 4: порог производства

Финальный список проверок выполняется перед тем, как система начнёт использоваться реальными пользователями. К этому моменту корректность должна быть подтверждена. Остаётся лишь убедиться, что выпускаемый продукт полностью соответствует тому, что проходило тестирование, и что сбои можно устранить и объяснить.

Выпускайте именно тот продукт, который проходил тестирование. Используйте версию, пройдшую предпроизводственные тесты, и присвойте ей новое название для производства, вместо того чтобы собирать новую копию на последнем этапе.

Почему: Пересборка в последний момент, даже из «того же» источника, может привести к использованию другой версии зависимости, другого временного метки или других параметров среды. Это приводит к тому, что в производственной среде запускается код, который на самом деле никогда не тестировался.

Пример: Пакетное приложение, прошедшее все предпроизводственные проверки, просто получает новое название как версия для производства и отправляется в таком виде, без изменений — это тот же файл, а не новая сборка из того же кода.

Заранее определите, куда будут направляться повторные сбои и как долго они будут храниться. Установите строгий лимит попыток, решите, куда должны попадать задачи, совершившие сбой после этого лимита, и определите срок их хранения.

Почему: При отсутствии лимита сбойная задача может пытаться выполниться бесконечно, тихо расходуя ресурсы или блокируя очередь. При отсутствии места хранения сбойная задача просто исчезает, и никто не может принять меры по поводу сбоя, которого не видит.

Пример: Задание, которое потерпело неудачу три раза, автоматически перемещается в отдельную зону хранения и не пытается выполняться снова бесконечно. Оно сохраняется в течение двух недель, что даёт инженеру время обнаружить его и провести расследование.

Заранее спланируйте логируемую информацию. Если позже потребуется объяснить решения системы пользователю, аудитору или коллеге, заранее определите, что будет записываться и как к этой информации обращаться.

Почему: Фраза «Мы добавим надлежащее логирование позже» почти никогда не сбывается, когда наступают реальные сроки, и к тому моменту, когда потребность становится очевидной, отсутствующую историю уже невозможно восстановить задним числом.

Пример: Каждое автоматическое решение сохраняется в виде отдельной записи с указанием времени. Если кто-то позже спросит, почему система поступила определённым образом в конкретном случае, у вас будет готовый письменный ответ, а не догадки.

Описывайте каждый реальный инцидент, а не только применённый патч. После неожиданной неисправности задокументируйте корневую причину и способ её устранения, чтобы команда могла к ним обратиться позже; это важнее, чем просто закрытие заявки или сохранение чата.

Почему: Недокументированные решения снова приходится находить с нуля кому-то другому, обычно в условиях большего давления. Краткая запись — это часто самый дешёвый способ избежать повторной многочасовой проверки.

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

Паттерн, лежащий в основе чек-листа

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

Агент меняет местоположение риска. Запуски становятся длиннее и включают больше контекста, поэтому вычислительные ресурсы должны соответствовать этим требованиям. Запуск может сорваться или отклониться по способам, которые обычные тесты не обнаружат, поэтому проверки регрессии на известных рабочих примерах имеют ещё большее значение. Рано или поздно кто-то задаст вопрос «Почему это произошло?», на который должен быть возможен ответ в журнале аудита.