Коузианская сингулярность

Сейчас в интернетах широко обсуждают академическую статью (оригинал в комментах) "Коузианская сингулярность? Спрос, предложение и дизайн рынков с AI-агентами"

Рональд Коуз, в честь которого названа сингулярность, в своей знаменитой работе 1937 года “Природа фирмы” объяснил, почему фирмы существуют как организационная форма. Его ключевая идея заключалась в том, что структура нашей экономики определяется транзакционными издержками — затратами на использование рыночных механизмов для координации экономической активности. Когда транзакционные издержки высоки, экономически выгоднее организовать производство внутри фирмы (“делать”), а когда низки — покупать на рынке (“покупать”)

Авторы предполагают, что AI-агенты могут привести к радикальному снижению транзакционных издержек до уровней, близких к нулю, что станет точкой перегиба в экономической организации — своего рода “сингулярностью”. Это потенциально может фундаментально переписать границы между фирмами и рынками, которые существовали веками.

Транзакционные издержки как издержки человеческого труда

Можно утверждать, что многое в том, как мы структурируем нашу экономику и фирмы, может быть объяснено транзакционными издержками, часто издержками человеческого труда.

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

Сдвиг границ “делать или покупать”

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

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

- Углубление на конкретной специфике — если координация через рынок становится практически бесплатной, фирмы могут сосредоточиться на узких компетенциях.

- Вертикальная интеграция — зачем владеть всей цепочкой поставок, если агенты могут эффективно координировать множество поставщиков?

- Новые рыночные структуры — ранее невыполнимые из-за координационных издержек формы организации.

Выводы

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

Делитесь с коллегами и подписывайтесь на Machine Head

А это очень интересно 🧐

Попросил Perplexity проанализировать логи и собственное окружение.

Что примечательно:

Perplexity может сгенерировать python код, выполнить его и отрефлексировать свое окружение 😁

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

В потрохах: FastAPI, Jupyter, рассыпуха python и npm пакетов, буду исследовать дальше, Perplexity весьма откровенен )

Посмотреть и вдохновиться можно здесь

Update: Sandbox это не просто docker контейнер-песочница, а E2BSandbox - инструменты для запуска ресерч агентов. О дивный новый мир, я каждый день узнаю о новой ИИ тулзе. 🤪

Анатомия ИИ-агентов. Вступление

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

Я испробовал почти всё популярное: LangChain/LangGraph для python и typescript, CrewAI, ADK, даже Koog для Kotlin и yaml-ориентированный Composio. Каждый фреймоворк предлагает свои особенности и уровень простоты. Чем проще инструмент, тем меньше остается контроля над происходящим. Наш путь - заглянуть под капот, разобраться в нюансах и сделать для себя правильный выбор.

План такой:

1️⃣ Сначала разберемся, а из чего же состоит AI-агент и что, собственно, его делает агентом.
2️⃣ Исследуем, какие подходы предлагают фреймворки для смешивания детерминированной бизнес-логики c тем бардаком, что генерируют LLM
3️⃣ Столкнемся главным вызовом разработчика агентской системы - как заставить группу агентов работать совместно, защититься от галлюцинаций, таск-дрифта и других побочных эффектов работы систем с нечеткой логикой
4️⃣ В конце, обсудим плюсы и минусы, сделаем наметки на будущие шаги, возможно даже построим свой агентский фреймворк, обсуждая его дизайн в прямом эфире.

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

Это отличная задача для ИИ, но со звездочкой. Я для себя разделил целевое использование ИИ-агентов на 2 части:

- Исследовательское - компиляция данных, с LLM-верификацией источника. Мы не знаем заранее куда пойдет Агент и мы не можем полагаться на достоверность источника.
- Функциональное - компиляция данных из заранее верифицированного источника. Агент ходит в базы данных или в документы и предоставляет результат, которому мы, в целом, можем доверять.

Моя задача исследовательская, однако к результату особые требования. В отличие результатов, которые дают Deep Research режимы популярных вендоров, нам нужна строгая форма отчета + структурированный вывод, соблюдение акцентов на специфике оффера, переносимость workflow между разными LLM, достоверность и верификации найденных данных на уровне процесса, восставливаемость при сбое в точке остановки. И вот какие проблемы вылезли по дороге:

👻 Галлюцинации

OSS модели (а именно такие являются приритетными для российских реалий) легко выдумывают людей, факты, гипотезы ценности. Понижение температуры и требование “НИКОГДА НЕ ВЫДУМЫВАЙ …” в большом контексте не дает ожидаемого результата.

🏎️ Дрифт задачи

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

🥵 Переполнение контекста

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

💾 Сохранение состояния

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

... продолжение ниже

… начало в предыдущем сообщении

🧠 Reasoning

Одна из мощнейших возможностей LLM после включения кратно снизила качество отчета и услила дрифт задачи уже на 3-4 итерации. Вот пример, ищу данные по компании “Ит1-Холдинг”:
Модель на 3 итерации размышляет: “Отлично, я получил последние новости по “ИТ-холдинг Т1”, этих данных мне хватит для понимания приоритетов развития на ближайший год. В тексте также упоминается ****ов Антон, который вероятно занимает пост директора по инновациям, поищу его цитаты и выступления за последний год“. Далее идет в гугл, получает лавину информации скрейпит ее и вместо 3-5 стратегических целей одной компании, выдает факты из высказываний совершенного другого человека из совершенно другой компании. Вывод: пойдем разбираться, как нам сделать Планирование и Размышление предсказуемым (и нет, примеры в промпте, zero-learning не помогут)

Помимо этих проблем: нюансы работы с краткросрочной и долгосрочной памятью, стриминг процесса в UI, sandboxing deep research агента и многое другое.

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

Подписывайтесь на MachineHead и делитесь с друзьями.

#анатомияииагентов

Вопрос года:

- Чем вы занимаетесь?
- ИИ пинаю

Не успел я наиграться с ACP, который позиционируют как протокол для скрещивания редакторов текста и AI, который я вообще-то хотел скрестить с другими интерфейсами, Google берет и выкатывает A2UI - протокол, устремляющийся именно к этим целям, который тут же именуют стандартом.

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

В новой итерации, передовики из гугл спустились на грешную землю и предлагают нам агентскую обертку, которая проследит, чтобы модель генерировала JSON с описанием интерфейсного виджета, который можно будет отрисовать в любой из сред: Web, Flutter, Jetpack Compose, SwiftUI и тд.

Звучит как «мы бы и сами что-то такое сделали с помощью ACP 😁», но у этого протокола нашлась полезная фича: стриминг потока изменений в отрисованный элемент.

На странице с описанием транспортных протоколов для A2UI меня ждало странное - среди привычных REST и Websocket нашелся зверь под названием AG-UI, который сам является протоколом агентско-пользовательского взаимодействия (больше агентских протоколов богу агентских протоколов) но более низкого уровня, если можно так выразиться.

Идти и пробовать находку рано. Там пока есть клиенты только для Flutter и Angular. Да и бекенд на питоне, что в целом такое себе.

Выводы.

На мой взгляд в гонке протоколов корпорации пытаются застолбить место для своих решений, чтобы в будущем силком затянуть нас в свои феодальные облачные вотчины. Я бы не торопился называть такие библиотеки протоколами и уж тем более стандартами. Нет никаких проблем заставить LLM генерить именно тот output, который можно распарсить и отрисовать виджет на манер Backend Driven UI так, как подходит именно вам. Весь UI в приложение тоже отправить не получится, речь идет об отдельных виджетах, например, на лету создавать интерактивные карточки для языковых приложений. Не то, чтобы нам нужен был для этого спец протокол, но начало положено. Эра ИИ-интерфейсов на пороге.