AWS показала, как 100% точности поиска скрывают провал ИИ-агента

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

AWS описала этот случай в материале об Agent Development Lifecycle, или Agent DLC. Это подход к разработке агентов, в котором команда заранее определяет условия приёмки, проверяет каждое изменение и возвращает обнаруженные в эксплуатации проблемы в набор проверок. Для разработчика ценность здесь в конкретном способе понять, какой компонент требует исправления.

Почему 100% в отчёте оказалось недостаточно

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

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

Для проблемного вопроса эта точность составила 100%, доля полезных фактов внутри найденного материала — 9%, а покрытие подвопросов — 0%. Затем авторы проверили исходные документы: отдельной политики по больничным в корпусе действительно не было.

Команда изменила только системный промпт: потребовала строго опираться на источники, игнорировать лишнее и отвечать по существу. На вопросе об оценке сотрудников доля подтверждённых утверждений выросла с 83% до 87%. На вопросе о больничном она упала с 39% до 31%. Инструкция не могла добавить отсутствующие сведения. Следующим действием должно было стать пополнение базы и проверка поиска.

Что проверять перед выпуском

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

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

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

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

Где заканчиваются выводы эксперимента

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

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

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