Самые разрушительные сбои редко заявляют о себе заранее.

В течение последних нескольких месяцев мы создавали витрины и коммерческие агенты на платформе commercetools, используя инструменты агентного кодирования и навыки commercetools for Builders. Эти сборки были либо ориентированы на промпты, либо основаны на спецификациях. Мы анализировали данные каждого запуска, чтобы понять, что работает, а что нет, а затем превратили эти выводы в защитные механизмы (guardrails), которые вы можете использовать для любой разработки с применением ИИ.

Почти ничего не ломалось, но мы столкнулись с реальными проблемами, которые стоили нам времени и денег, например:

Стоимость растет вместе с продолжительностью сессии. У модели нет памяти между итерациями, поэтому каждая итерация повторно отправляет весь контекст беседы.

Тихие сбои доходят до покупателей. Неправильно настроенный поисковый фильтр возвращает нулевой результат без ошибки, что покупатель воспринимает как «этого товара у нас нет».

Завершенная работа скрывает сломанные релизы. Развертывание отчитывается об успехе, хотя ничего не работает, а агент помечает задачу как выполненную.

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

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

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

Лучшая практика №1: Дайте агенту меньше доступа, а не больше инструкций.

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

Там, где нужны письменные правила, помещайте их в системные правила верхнего уровня, чтобы они применялись универсально, а не полагайтесь на то, что одна часть системы их запомнит. Если какая-то возможность никогда не должна использоваться, не предоставляйте ее вовсе. Например, наш API-клиент с правами на запись был настроен без областей доступа (scopes) для ресурсов, которые никогда не должны меняться, таких как товары и цены в общих средах commercetools. В результате эти операции записи отклоняются платформой независимо от того, читает ли модель правила.

Области доступа (scopes) API-клиента commercetools неизменяемы после создания, поэтому стоит определить их заранее.

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

Лучшая практика №2: Планируйте в одной сессии, создавайте во многих.

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

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

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

Лучшая практика №3: Определите, какой навык за что отвечает, до начала разработки.

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

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

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

Вывод: Сосредоточьтесь на своих целях и сопоставьте их с навыками, которые помогут их достичь.

Лучшая практика №4: Проверяйте результат, а не подтверждение.

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

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

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

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

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

Лучшая практика №5: Регистрируйте то, что узнали, каждый раз.

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

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

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

Установите защитные механизмы до первой сессии.

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

Перед следующей сборкой потратьте полдня на четыре вещи:

Предоставьте агенту только те разрешения, которые вы сможете защитить при аудите.

Напишите план перед открытием сессии реализации.

Определите, какой навык отвечает за какую работу.

Храните данные сессий там, где вы можете их запрашивать.

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

Изучите, что вы можете создать с помощью commercetools for Builders в нашей документации — или свяжитесь с нашей командой для получения дополнительной информации.