Почти невозможно найти рабочие примеры архитектур мультиагентных систем. Обычно, пишут что-то вроде: "ну сделайте ИИ-бухгалтера, ИИ-программиста и объедините их в ИИ-семью". Брр.

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

Зачем тут мультиагенты?

Например, задача: "найти 100 конкурентов, выписать их выручку и позиционирование" (McKinsey на этом моменте напряглись, их хлеб). Человек пойдет задавать 200 тысяч запросов, переваривать тонну информацию, а потом долго писать отчет. Очень дорогая задача.

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

Дизайн архитектуры

Мы делаем систему с супер простой координацией агентов:

1) Есть агент-лидер, который бьет задачу на части и раздает подзадачи субагентам.

2) Каждый субагент решает свою задачу. Итеративно ходит поиск, анализирует выдачу, делает новый запрос, пока не докопается до истины.

3) После завершения своих задач, субагенты отправляют результаты лиду. Лид всех ждет. Потом, если он считает, что тема разобрана, готовит финальный отчет. Иначе делает новые подзадачи и по новой.

4) Когда отчет готов, отдельный агент расставляет, из какого источника, что было взято.

Оценка качества

Ровно так, как рассказывал старина Сева.

1) LLM-as-a-judge на различные свойства: достоверность ответа, точность цитат полнота, качество источников.

2) LLM-ки ловили не все кейсы, так что частично оценивали людьми.

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

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

#ai_cases

Как скинуть обработку тысяч документов на LLM. Кейс Uber.

Вот вы работаете с поставщиками. Поставщик выставляет вам счет за товар/услугу. Конечно, в виде PDF-ки на электронную почту. Очень удобно.

Можно все эти PDF-ки разгребать руками, а можно попросить это сделать LLM, как сделали коллеги из Uber. Давайте разберемся с этим кейсом.

Архитектура решения

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

По шагам:

1. Взяли PDF-ку, сделали из нее картинку, чтобы дальше применять CV-модели
2. Накатили на нее OCR-модель. Распознали текст.
3. Взяли текст, извлекли из него все нужные поля LLM-кой
4. В красивом интрфейсе показали сотруднику извлеченные поля. Он ОКает, либо правит (наш любимый human-in-the-loop)

Самой проблемной точкой мне видится связка OCR + LLM. На шаге OCR уже может накопиться большая ошибка. Можно сразу делать VLM. Например, вот дообученный qwen, который по картинке документа текст распознает. Или, например, VLM Gemini сразу умеет работать с PDF .

Какая LLM под капотом?

Пробовали дообучать опенсорс и просто промптить GPT-4. Удивительно, но промптить GPT-4 оказалось сильно лучше.

Вообще, довольно сложно на опенсорсе победить OpenAI на широких задачах, вроде разработки кода. Но в задачах типа выделение именованных сущностей, классификации это обычно довольно просто (вот пруф).

Странно, что у коллег не получилось. Хотя, они использовали довольно слабые опенсорс модели, вроде Flan T5. Надо было на дипсике пробовать 🙂

Результаты

На первый взгляд, все благополучно. Средняя точность около 90%. В 2 раза сократили ручную обработку документов и на 70% сократили среднее время обработки.

Теперь чуть-чуть подумаем. Допустим, у Uber тысячи поставщиков. И есть целый отдел, не знаю, из 15 человек, который только обработкой счетов и занимается.

Такой проект LLM-автоматизации, если делать все с нуля (и сразу хорошо), делать несколько месяцев отдельной командой инженеров. Как думаете, он окупится?

Что нужно изменить

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

AI-команда делает платформу по автоматизации. Там должны быть инструменты: как писать промпты, как оценивать качество, как собирать датасеты, как потом это деплоить и мониторить качество.

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

Хороший, качественно сделанный пример внедрения LLM с понятной пользой. Главное, чтобы это был только первый шаг, а не конечная точка.

#ai_cases

Aгент-аналитик для всех и каждого. Кейс компании Ramp.

Чтобы принять решение, нам нужна аналитика. Узнать, что покупали, куда кликали, что читали за прошлый день/месяц/год. Вопросы эти срочные. Отлично, если вы сами умеете в SQL. Хорошо, когда у вас свой аналитик. Ожидаемо, когда вы сделали задачу на аналитику, но не дождались ответа и все решили сами. Вот чтобы такого не было, финтех компания Ramp сделала агента дата-аналитика. Разбираем этот кейс.

Архитектура решения

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

1) Пишем техническую документацию. Для любой базы данных должно быть очевидно, что там лежит. Можно прям примеры запросов к этой базе написать.

2) По этой документации запускаем RAG. Находим релевантные базы данных. В контекст агента отправляем полное описание всех полей в базе. Про это читайте мое 5-е правило.

3) Агент пишет SQL-запросы. Запросы выполняются, результаты работы и ошибки отправляются на вход агенту.

4) Агент рефлексирует: все ли, что спрашивал пользователь он нашел? Если нет, можно еще поискать другие БД в пунте 2 или еще пописать SQL в пункте 3.

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

Вот, кстати, неплохой туториал от Google по Text2SQL системам. Очень похожие идеи.

Бизнес эффект

Вы не оптимизируете работу аналитиков. Нет. Вы упрощаете сотрудникам доступ к информации для принятия решения.

В Ramp этому агенту задают 1500 запросов в месяц, а людям-аналитикам задают 66 запросов. Разница больше, чем в 20 раз. Это все те вопросы, которые люди боялись спрашивать или откладывали в длинный бэклог. Не трогай, это вопрос на новый год!

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

Основная проблема этого кейса

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

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

2) Явная проверка. Вы делаете через бота предварительную разведку. Если хотите результаты анализа написать на слайде, делаете задачу на отдел аналитики. Они перепроверяют.

3) Copilot для аналитика. Не даем инструмент всем, а только ускоряем работу аналитиков. Они проверяют, что агент отработал адекватно.

Резюме

Из этого кейса нам нужно вынести 2 урока:

- ИИ это не только про автоматизацию. Это про демократизацию и более широкий доступ. Который в долгую может быть намного важнее.

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

Что думаете про этот кейс? Жду ваши мысли и вопросы в комментариях. И пишите в личные сообщения, если хотите разобрать другой AI-проект.

#ai_cases