Четыре ИИ-агента по 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 процента - это оптимистичная оценка сверху, а не пессимистичная снизу.
Как посчитать свою цепочку
Пять минут и салфетка.
- Выписать звенья по порядку. Именно все, включая добавленные «на всякий случай».
- Против каждого поставить долю: сколько прогонов из десяти Вы принимаете без правок. Не «работает нормально», а число.
- Перемножить доли. Это реальная точность на выходе, а не точность лучшего звена.
- Сравнить с ожиданием бизнеса. Если процесс требует 95 процентов, а вышло 60, дальше считать нечего.
- Решить: сокращать цепочку или ставить ручное подтверждение. Оба решения рабочие, третьего нет.
Про сокращение. Соберите два соседних звена в одно или выкиньте лишнее. Каждое убранное звено работает в плюс, потому что вылетает целый множитель.
Про ручное подтверждение. Я держу его в трёх точках:
- перед отправкой клиенту,
- перед тратой денег,
- перед необратимым действием, которое не откатить одной кнопкой.
Не по всей цепочке, а именно там, где цена ошибки такая, что экономия минуты на подтверждении не окупается никогда.
Это не недоделанная автоматизация и не признак слабой системы. Это граница: агент готовит, человек решает.
Ловушка, в которую тянет после подсчёта
Первое желание после того, как Вы перемножили доли и увидели результат, - добавить в цепочку ещё одно звено, которое будет проверять предыдущие.
Вспомните арифметику. Проверяющее звено тоже не стопроцентное и умножается вместе со всеми. Вы добавили множитель меньше единицы к системе, где проблема именно в количестве множителей.
Надёжнее всего работает проверка вне цепочки: фиксированный набор кейсов с заранее известным правильным ответом, прогон после каждого изменения, сравнение с эталоном. Это не агент, это тест.
Но честно скажу и про исключения, они есть. Проверка внутри цепочки бывает рабочей: один и тот же вопрос задают двум моделям разных семейств и зовут человека только там, где ответы разошлись, или ставят оценку качества прямо в поток и отсекают плохие ответы до того, как их увидит клиент. Оба приёма меняют арифметику в лучшую сторону, и оба стоят денег и времени на двойной прогон. Бесплатной проверки внутри цепочки не бывает.
Спорное
Большинство мультиагентных схем в малом и среднем бизнесе собраны не потому, что задача требует нескольких агентов, а потому что схема из десяти квадратиков выглядит серьёзнее, чем один хорошо написанный запрос с двумя инструментами.
Оговорюсь и здесь, потому что мой же второй спикер утверждает обратное по деньгам: грамотно собранная система из нескольких небольших моделей может выходить дешевле одной большой. Спорить с этим не буду, счёт зависит от того, какие модели стоят в звеньях. Но точностью и скоростью за лишние звенья платит владелец всегда, и вот это от выбора моделей не зависит.
Вопрос к Вам, ради которого написан текст. Посчитайте свою самую длинную цепочку по шагам выше и напишите в комментариях два числа: сколько звеньев и что получилось после перемножения. Интересно, у кого выйдет выше 80 процентов и за счёт чего.
И спорьте, если считаете, что дело в качестве запросов, а не в количестве звеньев.