Четыре ИИ-агента по 90 процентов дают на выходе 65,6. Почему цепочки ломаются тихо

Возьмите четырёх ИИ-агентов, каждый работает с точностью 90 процентов, и поставьте их в цепочку. На выходе будет 65,6 процента.

Это не результат исследования и не замер. Это 0,9 в четвёртой степени, при условии что агенты стоят последовательно, ошибки не чинятся по ходу и сбой одного звена не связан со сбоем другого. Школьную арифметику пропускают ровно в тот момент, когда рисуют красивую схему из десяти квадратиков со стрелочками и называют её мультиагентной системой.

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

Откуда цифра и две честные оговорки

Формулировку я взял у Асафа, руководителя AI-направления Monday, из доклада на конференции LangChain Interrupt. Эффект в компании называют compound hallucination, накопительное галлюцинирование. Дословно:

90% Accuracy times 90% accuracy… Even if they're all at 90%, you're now at 70%

Первая оговорка. Асаф округляет в большую сторону. Точный расчёт 0,9 в четвёртой степени даёт 65,6 процента, а не 70. Округление принадлежит спикеру, я считаю по точному числу.

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

Механика от этого не меняется. Меняется только то, какие числа Вы подставите вместо девяноста.

Что показывает практика самой Monday.сom

Дальше в том же докладе есть деталь, которая сильнее любой арифметики.

Асаф рассказывает, из чего собран первый запущенный цифровой сотрудник Monday. Из четырёх агентов:

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

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

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

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

Второй слой проблемы, который арифметика не покрывает

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

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

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

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

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

Три способа, которыми цепочка деградирует

У меня самая длинная рабочая цепочка - семь звеньев. Деградацию от добавления звена ловил. Она приходит в трёх видах, и это важно, потому что искать её будете глазами:

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

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

Перемножение точностей объясняет только первый симптом. Второй и третий оно не покрывает вовсе. Значит 65,6 процента - это оптимистичная оценка сверху, а не пессимистичная снизу.

Как посчитать свою цепочку

Пять минут и салфетка.

  1. Выписать звенья по порядку. Именно все, включая добавленные «на всякий случай».
  2. Против каждого поставить долю: сколько прогонов из десяти Вы принимаете без правок. Не «работает нормально», а число.
  3. Перемножить доли. Это реальная точность на выходе, а не точность лучшего звена.
  4. Сравнить с ожиданием бизнеса. Если процесс требует 95 процентов, а вышло 60, дальше считать нечего.
  5. Решить: сокращать цепочку или ставить ручное подтверждение. Оба решения рабочие, третьего нет.

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

Про ручное подтверждение. Я держу его в трёх точках:

  • перед отправкой клиенту,
  • перед тратой денег,
  • перед необратимым действием, которое не откатить одной кнопкой.

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

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

Ловушка, в которую тянет после подсчёта

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

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

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

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

Спорное

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

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

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

И спорьте, если считаете, что дело в качестве запросов, а не в количестве звеньев.