Девять инженерных привычек для запуска вашего первого ИИ-агента

В кругах, занимающихся агентными технологиями, ходит история о счете на сумму 47 000 долларов. Она рассказывается без больших подробностей, поэтому следует рассматривать её как пример, а не как проверенный случай. Агент проявил себя безупречно во всех демонстрациях. Затем его применили в реальном рабочем процессе клиента, где он попал в цикл возвратов средств, постоянно выполняя один и тот же действие в течение шести часов без наблюдения. Сама модель не была особенно сложной. Люди, создавшие систему, проигнорировали всё, что позволяет модели определить момент остановки.

Вот неприятная правда о работе над инженерными решениями для ИИ-систем. Даже если вы знаете Python, RAG, агентов, векторные базы данных, техники формулировки запросов и все новые версии моделей, это ещё не гарантирует готовности к использованию в производстве. Навыки, которые помогают избежать проблем после неудачной демонстрации, редко рассматриваются в учебниках. Они скучны, их легко пропустить, но именно они отличают внешне впечатляющую систему от той, которой можно доверять. Вот девять рабочих привычек, которые стоит выработать перед тем, как выпускать любую автономную систему.

Почему больше знаний не делает вас старшим специалистом

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

• Прогноз Gartner на середину 2025 года: более 40% проектов с использованием агентных ИИ-решений будут отменены до конца 2027 года из-за роста затрат, неопределенной ценности и слабого контроля рисков.

Согласно опросу S&P Global Market Intelligence за 2025 год, компании отказываются примерно в 46% случаев от своих концептов ИИ перед их внедрением в производство.

По данным инициативы NANDA при MIT, которая изучила более 300 случаев внедрения, лишь около 5% из них привели к ощутимому финансовому эффекту.

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

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

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

1. Сначала напишите функцию оценки, затем — саму функцию

Новички пишут промпт, пробуют его несколько раз, оценивают полученный результат и выпускают функцию. Более опытные инженеры сначала записывают, что означает «правильный» результат, в виде набора тест-кейсов, а уже затем приступают к реализации функции.

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

2. Тратьте контекст как деньги

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

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

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

3. Ограничьте автономию модели перед запуском

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

Логика подсказывает, что это неоспоримо. Если каждый шаг в рабочем процессе агента срабатывает с вероятностью 95%, а в процессе всего 20 шагов, то целый процесс не будет завершаться правильно в 95% случаев, поскольку вероятности накапливаются. При вероятности 90% на каждый шаг цепочка из 20 шагов сработает лишь примерно в 12% случаев. Демонстрация, в которой три шага выполняются без проблем, почти ничего не говорит о работе системы с двадцатью шагами в реальных условиях.

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

4. Ведите журнал, как будто собираетесь отладить систему в 2 часа ночи.

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

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

5. Поднимайтесь по лестнице: сначала запрос, затем извлечение данных, а потом настройка

Когда точность оказывается неудовлетворительной, новички часто сразу переходят к тонкой настройке, поскольку это кажется «настоящей» инженерной практикой. Обычно это неверный первый шаг, и известный пример объясняет почему. Исследователи из Microsoft взяли GPT-4, добавили набор техник формулировки запросов под названием Medprompt и сравнили его с Med-PaLM 2 — медицинским специалистом от Google, настроенным на клинические данные и работающим с запросами, написанными экспертами. По результатам тестирования на MedQA тонко настроенный Med-PaLM 2 показал результат 86,5%, в то время как GPT-4 с использованием только техник Medprompt достиг 90,2%. Это соответствует снижению уровня ошибок на 27%, при этом требуется в разы меньше вызовов модели по сравнению с подходом тонкой настройки.

Разумный порядок действий — от дешевых и обратимых методов к дорогостоящим и медленным:

Prompting        Retrieval (RAG)      Fine-tuning
(cheap, fast,  →  (add missing    →   (expensive, slow,
reversible)        knowledge)          last resort)

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

6. Разделяйте мышление и действия

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

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

7. Рассматривайте запросы как код и версионируйте их

Пример инструкции, которую пришлось переписывать четыре раза, — это логика работы продукта. Если относиться к ней как к временному черновику, вы потеряете рабочую версию сразу же, как только кто-то попытается её «улучшить». Храните инструкции в системе контроля версий, как и любые другие файлы, применяйте набор тестов к каждой изменению перед его объединением и ведите краткий журнал изменений с указанием того, что было изменено и почему. Это звучит слишком просто, чтобы об этом упоминать, и именно поэтому большинство команд пренебрегают этим, пока сбой в работе инструкции не приведёт к проблемам в продакшене, и тогда никто не сможет сказать, что изменилось.

8. Сначала определите стоимость функции

Вот один конкретный пример. Агент без ограничений, выполняющий одну программную задачу, тратил от 5 до 8 долларов на комиссии API, в то время как полные производственные сессии, попытки повторного выполнения и вызовы инструментов стоили от 10 до 100 долларов. Цифры могут отличаться в зависимости от модели, задачи и способов оптимизации, но общая картина остается прежней. Расходы, которые кажутся незначительными для одной задачи, становятся значимыми при большом объеме работы, а проект-пилот, казавшийся дешевым на этапе тестирования, может незаметно стать причиной отказа от проекта.

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

9. Диагностируйте, прежде чем делать предположения

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

Когда можно пропустить половину этого

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

Изменение в одном предложении

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