как масштабировать мультиагентную систему на людей?

например, оператор должен держать в коридоре всего один показатель: стоимость производства единицы фичи.

есть риск сползания в экспоненциальную историю.

если этот показатель начинает штормить, останавливать реактор и инициировать рефакторинг.

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

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

Изыди, бесноватый…

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

Так есть уже. Майкрософт сделал облачного агента copilot (не путать с обычным копайлот) который может закрывать issue в github и делать PR, и ревьювить PR, и по идее вообще можно сказать ему сделать что угодно в комменте. Но пока прям все таски он не осилит. Если ты про то, чтобы посадить одну модель писать код а другую типа ее проверять, типа чтобы не было так, что модель делает себе поблажки, то в этом особо нет смысла, так как модели stateless, то есть каждый новый промт/запрос/вызов инструметов запускает новый процесс в облачном кластере, и нет состояния, туда заново подается вся переписка, прочитаные файлы и т.д. И это новый инстанс модели. Образно говоря, это как колл-центр с десятком индусов, и каждый твой звонок попадает новому, ты его спрашиваешь, почему ты реализовал это так, но это реализовал предыдущий индус, и он, не моргнув глазом отвечает тебе почему так, ибо у него такие служебные инструкции. Лично для меня это крипово.

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

На комментарии дурачков не обращайте внимание. Пока они дурачатся, Майкрософт увольняет тысячи кодеров низкого звена примерно с 2018 кода. Там по закону сразу много нельзя.

Stateless только бесплатные модели. Все нормальные модели знают и держат контекст.

Все нормальные модели знают и держат контекст.

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

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

Подробнее о том, как создавать контекст и что с ним можно делать ищите информацию по “composition and maintaining context in AI models”.

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

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

Гм, а что произойдет если поискать информацию по «are llm stateless?»

Я же сказал, этот контекст является частью модели. В зависимости от типа модели, он может существовать только на время сессии или сохраняться между сессиями, храниться как на стороне клиента, так и на стороне модели.

1) Берёшь задачу, ставишь её агенту, он выдаёт какое-то решение. Затем берёшь решение и подаёшь на вход другому агенту, но уже с задачей «найди ошибки». Результат работы второго агента подаёшь на вход первого агента. Он должен либо исправить ошибки, либо выдать аргументацию, почему это false positive. Затем результат исправления снова подаётся на вход второго агента. Цикл повторяется либо пока агенты не сойдутся во мнении, что ошибок нет, либо до исчерпания бюджета времени на задачу (исходим из допущения, что самые критичные ошибки будут исправлены в первую очередь, а оставшееся будет лишь косметическими улучшениями).

2) Берёшь нескольких агентов и даёшь им одну и ту же задачу. Затем все результаты подаёшь на вход другого агента и его задача - выбрать лучшее решение.

3) Совместить 1 и 2 - на стадии выбора решения агента два. Один выбирает решение и приводит аргументы. Другой должен либо согласится, либо высказать контраргументы. Агенты зациклены, пока не придут к согласию или пока не наступит дедлайн (тогда можно в качестве tie-breaker подключить третьего агента, который должен сказать кто из спорщиков прав и выбрать одно решение).

4) N агентов генерируют решения, затем M агентов голосуют за решения, выбирается решение набравшее большинство голосов (N и M так подобраны, чтобы не могло быть ничьей, либо добавляется опять этап дискуссии, когда один агент должен переубедить другого агента, либо можно устроить второй тур выборов из финалистов первого голосования)

Неплохие результаты получаются, если спорящие агенты построены на разных ИИ моделях (например, Claude Opus + ChatGPT Codex), потому что из-за чуть разных обучающих выборок у моделей разные bias и они находят разные классы ошибок, в итоге хорошо дополняют друг-друга. Но модели должны быть +- одного уровня. Если поставить ревьюить Opus какой-нибудь DeepSeek, то результат будет хуже, чем от чистого Opus.

Всё это позаимствовано из мира людей и вполне себе применяется. Людям как и агентам для нормальной работы такой системы нужны некоторые правила (дедлайны на принятие решения, защиты от ничьих и т. д.). Система повышает шанс удачного решения, но не даёт 100% гарантий (но их вообще ничто не даёт).

Я же сказал, этот контекст является частью модели.

Ну это вопрос философский, является ли контекст частью. Но сама модель stateless, данные (контекст) подаются на вход черного ящика, а не находятся в нем.

Хорошо, с этим я согласен. Сама модель не хранит состояние, но хранит контекст, который изменяет поведение модели за счёт изменившегося предубеждения (bias) по токенам контекста.

граждане, я неплохо понимаю как пользоваться langgraph, вы чет не поняли ))

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

надо ли шкалить новую модель разработки на человеков, чтобы их — человеков — было N и они не толкались, а дополнялись?

и если да, то как?

это всё понятно. и дирижер — человек — тут один. что как будто неправильно.

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

Соответственно, если задач много, то сотрудников тоже может быть несколько.

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

Этот генератор уже очень прочно вошёл в нашу жизнь

Весьма популярное мнение, среди тех, кому банально не хватает квалификации оценить его непригодность для реальных задач)

Когда он в теле, гной тоже вроде свой да не совсем

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

Этот генератор уже очень прочно вошёл в нашу жизнь

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

Мне несколько раз пришлось ревьювить вывод генераторов, и каждый раз всё было плохо. Причём это была плохая разновидность «плохо», когда что-то вроде имеет смысл, что-то нет, и в совокупности это шлак. Если бы всё было равномерно плохо, было бы проще. В итоге ревью требует больших затрат сил. Приходится объяснять, что конкретно плохо. И у меня есть подозрения, что с другой стороны мои объяснения просто запихнут обратно в LLM-помощник, который весело и с песней выплеснет новый набор патчей. Разработчику это не стоит практически ничего, он на это время не тратит. А меня этот шлак выматывает.

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

пришлось ревьювить вывод генераторов

так чем тебя не устраивает цикл «сделай — проверь — переделай»? сама модель, или несколько, проводят ревью друг другу, рано или поздно они успокоятся. опус 4.6 весьма неплохо умеет это делать.

и чем тут оперировать? качеством кода или производимым продуктом?

если продукт есть, устраивает потребилетя и у тебя есть деньги по результату, не очень понятно что именно «не так». разве что за державу немного обидно.