Ставим агентов на поток. Кейс компании DoorDash
В своих статьях и постах (один и два) я занудствую про важность платформ. Нет ничего сильнеесемьи платформы. Делают ли так на практике, или это просто мнение одного фантазера? Неделю назад вышла статья DoorDash, которая поможет нам разобраться, зачем кому-то понадобилась платформа AI-агентов.
Про что платформа
DoorDash — крупнейшая компания по доставке еды в США. У них накоплена масса полезных знаний о их бизнесе: корпоративная вики, таски в джире, множество SQL-таблиц, регламентов и прочих разных вкусностей корпоративных гигантов.
Вот бы кто-то прочитал и умел отвечать по этому… Одному, правда, будет невмоготу. У каждого департамента свои форматы данных и совершенно разные правила поиска по ним.
Решение: каждый департамент может собрать своего агента-помощника. Подключить необходимые базы и объяснить, как по ним искать (с людьми не получилось, пробуем агентов).
Каких агентов можно создавать
- LLM-workflow. Агент работает по строгому протоколу. Используется, когда нужна высокая надежность и есть этот самый протокол.
- автономный агент. Агент сам решает, в каком порядке и как решать задачу. Используется для более сложных задач и более толерантных к ошибкам
- мультиагент через планировщика. Самый простой и рабочий вариант мультиагентной системы. Главный агент независимые подзадачи раздает субагентам, а потом собирает ответ. Классический пример от Anthropic.
- рой агентов. Не спрашивайте, что это такое. В тексте описана плохо работающая концепция, где агенты асинхронно друг с другом общаются, решая общую задачу. Коллеги сами признаются, что это задел на светлое будущее. Верим, ждём.
Такое разнообразие позволяет брать нужную архитектуру под ваши ограничения. Подробнее про это посмотрите в статье.
Техническое устройство
Разработка агента для пользователя должна быть похожа на сборку любимого лего. Полезных деталек здесь и вправду достаточно:
- RAG-платформа, через которую вы добавляете информацию
- Поддержка SQL
- Система оценки качества агента
- Валидация ответа и Guardrails
И много чего еще. После небольшого инструктажа обычный человек, используя эти кубики, сможет собрать реально полезного агента. Да, там не будет последних трюков из контекст-инжениринга. Да, LLM там обычные, а не дообученные под эту задачу. Но мы получим 80% результата за 20% сил.
Главный секрет успеха платформы — как надежно и удобно работает система оценки качества. Если получилось — дальше собирать Лего одно удовольствие. Если нет — всегда будут получаться жигули.
Моя вера в будущее
Я верю, что только так мы сможем масштабировать AI. Многие со мной согласны. Компании валом побежали делать платформы для создания агентов. Даже OpenAI, которые ранее верили только в один мега-мозг.
Никто не сделает AI для вашей задачи лучше, чем сделаете вы. Только вы знаете, как сделать удобнее всего. Платформы позволят любому создавать AI-решения, не делегируя никому их разработку. Не стоит делегировать интеллект.
#llm_cases
В своих статьях и постах (один и два) я занудствую про важность платформ. Нет ничего сильнее
Про что платформа
DoorDash — крупнейшая компания по доставке еды в США. У них накоплена масса полезных знаний о их бизнесе: корпоративная вики, таски в джире, множество SQL-таблиц, регламентов и прочих разных вкусностей корпоративных гигантов.
Вот бы кто-то прочитал и умел отвечать по этому… Одному, правда, будет невмоготу. У каждого департамента свои форматы данных и совершенно разные правила поиска по ним.
Решение: каждый департамент может собрать своего агента-помощника. Подключить необходимые базы и объяснить, как по ним искать (с людьми не получилось, пробуем агентов).
Каких агентов можно создавать
- LLM-workflow. Агент работает по строгому протоколу. Используется, когда нужна высокая надежность и есть этот самый протокол.
- автономный агент. Агент сам решает, в каком порядке и как решать задачу. Используется для более сложных задач и более толерантных к ошибкам
- мультиагент через планировщика. Самый простой и рабочий вариант мультиагентной системы. Главный агент независимые подзадачи раздает субагентам, а потом собирает ответ. Классический пример от Anthropic.
- рой агентов. Не спрашивайте, что это такое. В тексте описана плохо работающая концепция, где агенты асинхронно друг с другом общаются, решая общую задачу. Коллеги сами признаются, что это задел на светлое будущее. Верим, ждём.
Такое разнообразие позволяет брать нужную архитектуру под ваши ограничения. Подробнее про это посмотрите в статье.
Техническое устройство
Разработка агента для пользователя должна быть похожа на сборку любимого лего. Полезных деталек здесь и вправду достаточно:
- RAG-платформа, через которую вы добавляете информацию
- Поддержка SQL
- Система оценки качества агента
- Валидация ответа и Guardrails
И много чего еще. После небольшого инструктажа обычный человек, используя эти кубики, сможет собрать реально полезного агента. Да, там не будет последних трюков из контекст-инжениринга. Да, LLM там обычные, а не дообученные под эту задачу. Но мы получим 80% результата за 20% сил.
Главный секрет успеха платформы — как надежно и удобно работает система оценки качества. Если получилось — дальше собирать Лего одно удовольствие. Если нет — всегда будут получаться жигули.
Моя вера в будущее
Я верю, что только так мы сможем масштабировать AI. Многие со мной согласны. Компании валом побежали делать платформы для создания агентов. Даже OpenAI, которые ранее верили только в один мега-мозг.
Никто не сделает AI для вашей задачи лучше, чем сделаете вы. Только вы знаете, как сделать удобнее всего. Платформы позволят любому создавать AI-решения, не делегируя никому их разработку. Не стоит делегировать интеллект.
#llm_cases
❤20👍10🔥4🐳2🏆2❤🔥1👏1🤩1
Фреймворк, как привести к успеху любой AI-проект
Самый частый вариант беседы, когда меня просят помочь с проектом:
Беседа потом идет примерно одинаково. Готовьтесь, дальше не будет никакого роя AI-агентов. Дальше будет нуднота.
Итеративный фреймворк управления проектом
AI — это работа с высокой неопределенностью. Нельзя все спланировать и пустить по канбану. Мы должны быть готовы, что что-то не взлетит. И это нормально. Нужно просто это как можно быстрее понять.
Элементом фреймворка является гипотеза. Гипотеза — это идея, что некоторое изменение улучшит качество AI-проекта. Например, что нужно LLM обновить до GPT 5.1. Гипотеза может быть в одном из трех состояний:
- Прототипирование. Нужно как можно скорее понять, а стоит ли инвестировать силы. Подробнее в статье.
- Оценка качества. Замерили и теперь понимаем успешная ли гипотеза. Гайд по замеру качества.
- Внедрение. Уверены, что гипотеза полезная. Разрабатываем и внедряем.
Любой проект начинается с самого простого и легко поддерживаемого решения. Например, чат-бот. Вначале просто API к GPT + простой промпт. Больше ничего. Смотрим недостатки (время/цена/галлюцинации/etc). Делаем гипотезу. Потом еще одну. Идею вы поняли.
Откуда берутся гипотезы
Нет, не из статей с хабра и даже не с arxiv.org. Гипотезы рождаются из анализа проблем. Типовой анализ выглядит примерно так:
- Собрали репрезентативный список задач в систему. Например, запросы в чат-бот за год.
- Оценили качество текущей системы.
- Разбили примеры с проблемами на понятные группы.
Дальше для групп проблем придумываем гипотезу, которая их должна починить.
Резюме
Только итеративный подход, где мы понимаем смысл каждого шага. Анализ проблем, прототипирование гипотезы, оценка качества, внедрение.
Если за всю жизнь я смогу донести только одну эту идею, я буду уверен, что все было не зря.
Ваше путешествие начинается с одного шага. Так написано на моей беговой дорожке. Уверен, эти ребята знают, о чем говорят.
Самый частый вариант беседы, когда меня просят помочь с проектом:
- Сева, вот смотри, хотим решить проблему X. Понятно?
- Пока да.
- Супер! Короче, мы взяли 15 ИИ-агентов, в них запихали 4 роутера, облили это все графовой базой знаний. И все это на 1.5B квене, который мы специально доучили, но код обучения случайно удалили.
- Уже понятно меньше, но допустим. А что вы от меня хотите?
- Вот оно у нас плохо работает...
Беседа потом идет примерно одинаково. Готовьтесь, дальше не будет никакого роя AI-агентов. Дальше будет нуднота.
Итеративный фреймворк управления проектом
AI — это работа с высокой неопределенностью. Нельзя все спланировать и пустить по канбану. Мы должны быть готовы, что что-то не взлетит. И это нормально. Нужно просто это как можно быстрее понять.
Элементом фреймворка является гипотеза. Гипотеза — это идея, что некоторое изменение улучшит качество AI-проекта. Например, что нужно LLM обновить до GPT 5.1. Гипотеза может быть в одном из трех состояний:
- Прототипирование. Нужно как можно скорее понять, а стоит ли инвестировать силы. Подробнее в статье.
- Оценка качества. Замерили и теперь понимаем успешная ли гипотеза. Гайд по замеру качества.
- Внедрение. Уверены, что гипотеза полезная. Разрабатываем и внедряем.
Любой проект начинается с самого простого и легко поддерживаемого решения. Например, чат-бот. Вначале просто API к GPT + простой промпт. Больше ничего. Смотрим недостатки (время/цена/галлюцинации/etc). Делаем гипотезу. Потом еще одну. Идею вы поняли.
Откуда берутся гипотезы
Нет, не из статей с хабра и даже не с arxiv.org. Гипотезы рождаются из анализа проблем. Типовой анализ выглядит примерно так:
- Собрали репрезентативный список задач в систему. Например, запросы в чат-бот за год.
- Оценили качество текущей системы.
- Разбили примеры с проблемами на понятные группы.
Дальше для групп проблем придумываем гипотезу, которая их должна починить.
Резюме
Только итеративный подход, где мы понимаем смысл каждого шага. Анализ проблем, прототипирование гипотезы, оценка качества, внедрение.
Если за всю жизнь я смогу донести только одну эту идею, я буду уверен, что все было не зря.
Ваше путешествие начинается с одного шага. Так написано на моей беговой дорожке. Уверен, эти ребята знают, о чем говорят.
❤29👍27🔥10🏆4🥰2😁2🙏1💯1
А судьи кто? Гайд по LLM-as-a-judge
Оценка качества — ключ к фрейморку успешного AI-проекта. Если вы не овладете этим навыком, любые ваши AI-успехи, если они и будут, окажутся только случайной удачей. Недавно в моей статье мы бегло просмотрели эту тему.
Сегодня погрузимся в самый популярный метод — оценка качества моделей “LLM-as-a-judge”. В нем вместо оценки ответов людьми мы оцениваем ответы другой "LLM-судьей". Тут обычно все шутят, что критиковать всегда проще, чем творить. Мне шутка уже надоела, но законы жанра. Извините.
Когда использовать LLM-as-a-judge?
LLM дешевле, быстрее размечает, не жульничает, но хуже следует сложным инструкциям. Из этого вытекают кейсы, когда этот подход нужно применять вместо разметки людьми.
1) Разметка не слишком интеллектуальная. Она не требует ни:
а) фундаментальных экспертных знаний
б) сложных логических рассуждений
Например, оценить, был ли ответ модели в контексте, LLM-судья может. Но проверить, логически следует ли ответ из контекста, ей будет сложно.
2) Вам нужны очень быстрые итерации.
Гонка, пожар, стартап. Если вам нужно получать оценку качества через часы, а не дни.
3) У вас нет ресурсов.
Не только денег. Обучение разметчиков это обычное преподавание. Это материалы, ответы на вопросы, тесты, экзамены. Регулярные проверки, что они все не забыли и не жульничают. Это требует много сил и отдельного штата специалистов.
Как сделать LLM-судью? Пошаговый план
1) Берем бизнес-эксперта. Человека, который понимает, когда система работает правильно. Вместе с ним прорабатываем критерии, по которым оцениваем. Например, релевантность ответа, безопасность, достоверность и тд.
2) Вместе с экспертом размечаем по критериям репрезентативную корзинку ответов модели. Репрезентативная, значит это случайное подмножество реальных запросов в нашу систему.
3) Переразмечаем, спорим, пока мы с экспертом согласованно не разметим корзинку. Так мы поверяем, что мы сами поняли критерии. В итоге у нас получается «голден корзинка» таких эталонных примеров хороших и плохих ответов.
4) На части этой корзинки тюним LLM-судью. Тестируем итоговое качество на другой части. Тюнить можно по-разному: писать промпты, разбивать задачу на подзадачи (на каждый критерий можно отдельного судью), добавлять агентность. Можно даже файнтюнить LLM. Важно делать это итеративно, как и во всем AI-проекте.
Резюме
Это не просто дешевый, быстрый в разработке подход. Он еще очень гибкий. Если вы хотите поменять критерии качества, намного проще поменять промпты в LLM, чем переучивать 50 людей размечать по-новому.
Если ваша разметка явно не противоречит 3-м пунктам из этого поста, начните с LLM-as-a-judge, а не с разметки людьми. Если не получится, вы всегда сможете часть простых задач разметить LLM, а все сложные отправить людям. Или сможете давать людям LLM-подсказки, чтобы они могли быстрее размечать.
Пробуйте, пишите промпты, замеряйте качество, задавайте мне вопросы. Если оваладете оценкой качества, тогда никакой AI вам не будет страшен.
Оценка качества — ключ к фрейморку успешного AI-проекта. Если вы не овладете этим навыком, любые ваши AI-успехи, если они и будут, окажутся только случайной удачей. Недавно в моей статье мы бегло просмотрели эту тему.
Сегодня погрузимся в самый популярный метод — оценка качества моделей “LLM-as-a-judge”. В нем вместо оценки ответов людьми мы оцениваем ответы другой "LLM-судьей". Тут обычно все шутят, что критиковать всегда проще, чем творить. Мне шутка уже надоела, но законы жанра. Извините.
Когда использовать LLM-as-a-judge?
LLM дешевле, быстрее размечает, не жульничает, но хуже следует сложным инструкциям. Из этого вытекают кейсы, когда этот подход нужно применять вместо разметки людьми.
1) Разметка не слишком интеллектуальная. Она не требует ни:
а) фундаментальных экспертных знаний
б) сложных логических рассуждений
Например, оценить, был ли ответ модели в контексте, LLM-судья может. Но проверить, логически следует ли ответ из контекста, ей будет сложно.
2) Вам нужны очень быстрые итерации.
Гонка, пожар, стартап. Если вам нужно получать оценку качества через часы, а не дни.
3) У вас нет ресурсов.
Не только денег. Обучение разметчиков это обычное преподавание. Это материалы, ответы на вопросы, тесты, экзамены. Регулярные проверки, что они все не забыли и не жульничают. Это требует много сил и отдельного штата специалистов.
Как сделать LLM-судью? Пошаговый план
1) Берем бизнес-эксперта. Человека, который понимает, когда система работает правильно. Вместе с ним прорабатываем критерии, по которым оцениваем. Например, релевантность ответа, безопасность, достоверность и тд.
2) Вместе с экспертом размечаем по критериям репрезентативную корзинку ответов модели. Репрезентативная, значит это случайное подмножество реальных запросов в нашу систему.
3) Переразмечаем, спорим, пока мы с экспертом согласованно не разметим корзинку. Так мы поверяем, что мы сами поняли критерии. В итоге у нас получается «голден корзинка» таких эталонных примеров хороших и плохих ответов.
4) На части этой корзинки тюним LLM-судью. Тестируем итоговое качество на другой части. Тюнить можно по-разному: писать промпты, разбивать задачу на подзадачи (на каждый критерий можно отдельного судью), добавлять агентность. Можно даже файнтюнить LLM. Важно делать это итеративно, как и во всем AI-проекте.
Резюме
Это не просто дешевый, быстрый в разработке подход. Он еще очень гибкий. Если вы хотите поменять критерии качества, намного проще поменять промпты в LLM, чем переучивать 50 людей размечать по-новому.
Если ваша разметка явно не противоречит 3-м пунктам из этого поста, начните с LLM-as-a-judge, а не с разметки людьми. Если не получится, вы всегда сможете часть простых задач разметить LLM, а все сложные отправить людям. Или сможете давать людям LLM-подсказки, чтобы они могли быстрее размечать.
Пробуйте, пишите промпты, замеряйте качество, задавайте мне вопросы. Если оваладете оценкой качества, тогда никакой AI вам не будет страшен.
2🔥27❤9👍8🏆6❤🔥1👏1🤔1🤩1
Экологичный метод дообучения LLM
Я не люблю учить модели. Точнее, я не люблю, когда учат на каждый чих, хотя можно было обойтись методами попроще. Почему?
Для работы каждой новой модели нужно строить свой уютный домик: отдельные GPU, мониторинги и разработчики, которые следят, что ничего не сломалась, и GPU хорошо утилизируется. Это очень плохо масштабируется. Но есть один вариант.
LoRA — экологичный метод дообучения, который значительно проще масштабировать. Почему я его так люблю и как правильно его готовить, мы сейчас обсудим.
Чем LoRA экологичнее?
LoRA (low-rank adaptation) не трогает исходную модель. Метод обучает новые параметры, так называемый адаптер, который просто складывается с оригинальными весами модели. Из этого сразу вытекают два важных преимущества:
1) Размер данных для обучения.
Если для честного дообучения нам нужно были десятки тысяч примеров, то LoRA заводится даже с несколько сотен. Зависит от размера адаптера, который можно регулировать.
2) Удобство предсказания.
Вам не нужно держать 20 клонов модели для 20 разных внедрений. Вы можете только один раз запустить модель на дорогих сердцу GPU-серверах, а 20 раз использовать разные адаптеры, которые намного меньше. На этапе предсказания веса модели будут на лету складываться с параметрами адаптера и выдавать предсказания для 20 разных задач. Ну оооочень экологично, правда. Такой функционал реализован во многих библиотеках, например, в vLLM.
На второй пункт обычно все забивают. И часто в компании возникает зоопарк из 30 версий модели, у каждой по 1 H100 с 3% утилизации железа. Зла не хватает.
Когда и как применять LoRA?
Метод отлично подходит, когда у вас немного качественных данных. На моей практике, когда примеров сотни/несколько тысяч, LoRA показывает паритет с честным обучением и даже иногда его превосходит (но нужно правильно подобрать размер адаптера). Когда примеров уже десятки тысяч, дообучение начинает обгонять по качеству.
Отличное исследование по LoRA, сделали коллеги из Thinking Machines. Некоторые выводы:
- Нужно применять адаптер ко всем слоям модели, а не только к слою внимания.
- Чем больше размер адаптера, тем больше он может заполнить, тем дольше надо учить.
- Шаг обучения ставить примерно в 10 раз выше, чем при полном обучении.
Резюме
Я не хочу, чтобы мы с вами делали разовую AI-активность. Я мечтаю, чтобы мы создавали методы массовой трансформации. LoRA намного больше подходит под эту мечту, чем классическое полное дообучение.
Вы сможете под каждый бизнес-процесс легко обучить LLM, которая будет лучше всех понимать его устройство. И очень быстро развернуть это решение в продакшен. Это уже больше похоже на AI-платформу, правда?
Я не люблю учить модели. Точнее, я не люблю, когда учат на каждый чих, хотя можно было обойтись методами попроще. Почему?
Для работы каждой новой модели нужно строить свой уютный домик: отдельные GPU, мониторинги и разработчики, которые следят, что ничего не сломалась, и GPU хорошо утилизируется. Это очень плохо масштабируется. Но есть один вариант.
LoRA — экологичный метод дообучения, который значительно проще масштабировать. Почему я его так люблю и как правильно его готовить, мы сейчас обсудим.
Чем LoRA экологичнее?
LoRA (low-rank adaptation) не трогает исходную модель. Метод обучает новые параметры, так называемый адаптер, который просто складывается с оригинальными весами модели. Из этого сразу вытекают два важных преимущества:
1) Размер данных для обучения.
Если для честного дообучения нам нужно были десятки тысяч примеров, то LoRA заводится даже с несколько сотен. Зависит от размера адаптера, который можно регулировать.
2) Удобство предсказания.
Вам не нужно держать 20 клонов модели для 20 разных внедрений. Вы можете только один раз запустить модель на дорогих сердцу GPU-серверах, а 20 раз использовать разные адаптеры, которые намного меньше. На этапе предсказания веса модели будут на лету складываться с параметрами адаптера и выдавать предсказания для 20 разных задач. Ну оооочень экологично, правда. Такой функционал реализован во многих библиотеках, например, в vLLM.
На второй пункт обычно все забивают. И часто в компании возникает зоопарк из 30 версий модели, у каждой по 1 H100 с 3% утилизации железа. Зла не хватает.
Когда и как применять LoRA?
Метод отлично подходит, когда у вас немного качественных данных. На моей практике, когда примеров сотни/несколько тысяч, LoRA показывает паритет с честным обучением и даже иногда его превосходит (но нужно правильно подобрать размер адаптера). Когда примеров уже десятки тысяч, дообучение начинает обгонять по качеству.
Отличное исследование по LoRA, сделали коллеги из Thinking Machines. Некоторые выводы:
- Нужно применять адаптер ко всем слоям модели, а не только к слою внимания.
- Чем больше размер адаптера, тем больше он может заполнить, тем дольше надо учить.
- Шаг обучения ставить примерно в 10 раз выше, чем при полном обучении.
Резюме
Я не хочу, чтобы мы с вами делали разовую AI-активность. Я мечтаю, чтобы мы создавали методы массовой трансформации. LoRA намного больше подходит под эту мечту, чем классическое полное дообучение.
Вы сможете под каждый бизнес-процесс легко обучить LLM, которая будет лучше всех понимать его устройство. И очень быстро развернуть это решение в продакшен. Это уже больше похоже на AI-платформу, правда?
1🔥30❤14👍10🏆2❤🔥1🙏1🥱1💯1
Друзья, опубликовал подробный фреймворк оценки качества LLM.
Он состоит из 7-ми шагов, по которым вы сделаете метрику под вашу LLM-задачу. Там много примеров, наглядных схем, основанных на моей 3-летней практике.
Если после прочтения остались вопросы, как в вашем случае строить метрики качества, напишите мне в личные сообщения — разберем ваш случай отдельно.
Он состоит из 7-ми шагов, по которым вы сделаете метрику под вашу LLM-задачу. Там много примеров, наглядных схем, основанных на моей 3-летней практике.
Если после прочтения остались вопросы, как в вашем случае строить метрики качества, напишите мне в личные сообщения — разберем ваш случай отдельно.
vikulin.ai
Как оценить качество LLM. Пошаговая методика создания надёжных метрик
Семь шагов от привлечения бизнес-экспертов до итеративного улучшения метрик. Как сделать оценку качества основой проекта, а не его слабым местом.
5🔥40❤12👍7🤝4🏆3😁2🌚2❤🔥1
Друзья, привет!
Меня зовут Всеволод, я 9 лет занимаюсь внедрением AI (Yandex, VK, T-Банк). Прошел путь от инженера до руководителя команд разработки.
За 9 лет в индустрии я видел сотни проектов. И успешных, и провальных. Я вывел закономерность. Секрет успеха — не в гениальной архитектуре нейросети и не в тысячах GPU. Успех — это всегда системный подход.
Провальные проекты начинаются с фразы «давайте попробуем тут AI». В AI проще простого собрать демку за пару дней. Но невероятно сложно превратить её в актив, приносящий прибыль. Так рождается «кладбище пилотов»: проекты умирают через год, съев бюджет, потому что никто не подумал про надежность, безопасность и риски.
Успешные проекты выглядят иначе. Они скучные, предсказуемые и следуют простой логике:
1. Стратегия: AI решает важные бизнес-задачи, вытекающие из целей компании. Не всегда нужен AI.
2. Инфраструктура: Мы вкладываемся в технологическую платформу, которую будем переиспользовать годами, снижая стоимость каждого следующего решения.
3. Дисциплина: Все инициативы проходят конкретные стадии, и мы объективно оцениваем их потенциал.
Этот канал — квинтэссенция моего опыта.
Я объясняю, как строить AI как бизнес-функцию: постоянную фабрику решений, а не разовый аттракцион.
Далее — материалы, которыми я горжусь больше всего:
Статьи про методику внедрения AI:
- 12 правил внедрения LLM
- Почему генеративный AI не приносит прибыли
- Методика оценки качества LLM
Основные посты про методику:
- Главный пост про итеративный фреймворк работы с AI-проектом
- Платформа — ключ к массовому внедрению AI
- Почему нельзя купить AI из коробки
- Как неправильное внедрение стоило компании полмиллиарда долларов
- Почему чаще всего не стоит делать своего code-ассистента. Кейс Uber
- Как можно сделать модель лучше, чем OpenAI и всего за 8 долларов
Кейсы:
- Ставим разработку AI-агентов на поток
- Как создали AI-агента аналитика
- Агент, который исследует информацию в интернете
- Массовая обработка документов на LLM
Уверен, в следующем году в этом посте будет минимум в 2 раза больше полезных материалов.
Если у вас есть мысли, идеи или вопросы по внедрению AI, всегда можно написать мне @seva_batareika
Меня зовут Всеволод, я 9 лет занимаюсь внедрением AI (Yandex, VK, T-Банк). Прошел путь от инженера до руководителя команд разработки.
За 9 лет в индустрии я видел сотни проектов. И успешных, и провальных. Я вывел закономерность. Секрет успеха — не в гениальной архитектуре нейросети и не в тысячах GPU. Успех — это всегда системный подход.
Провальные проекты начинаются с фразы «давайте попробуем тут AI». В AI проще простого собрать демку за пару дней. Но невероятно сложно превратить её в актив, приносящий прибыль. Так рождается «кладбище пилотов»: проекты умирают через год, съев бюджет, потому что никто не подумал про надежность, безопасность и риски.
Успешные проекты выглядят иначе. Они скучные, предсказуемые и следуют простой логике:
1. Стратегия: AI решает важные бизнес-задачи, вытекающие из целей компании. Не всегда нужен AI.
2. Инфраструктура: Мы вкладываемся в технологическую платформу, которую будем переиспользовать годами, снижая стоимость каждого следующего решения.
3. Дисциплина: Все инициативы проходят конкретные стадии, и мы объективно оцениваем их потенциал.
Этот канал — квинтэссенция моего опыта.
Я объясняю, как строить AI как бизнес-функцию: постоянную фабрику решений, а не разовый аттракцион.
Далее — материалы, которыми я горжусь больше всего:
Статьи про методику внедрения AI:
- 12 правил внедрения LLM
- Почему генеративный AI не приносит прибыли
- Методика оценки качества LLM
Основные посты про методику:
- Главный пост про итеративный фреймворк работы с AI-проектом
- Платформа — ключ к массовому внедрению AI
- Почему нельзя купить AI из коробки
- Как неправильное внедрение стоило компании полмиллиарда долларов
- Почему чаще всего не стоит делать своего code-ассистента. Кейс Uber
- Как можно сделать модель лучше, чем OpenAI и всего за 8 долларов
Кейсы:
- Ставим разработку AI-агентов на поток
- Как создали AI-агента аналитика
- Агент, который исследует информацию в интернете
- Массовая обработка документов на LLM
Уверен, в следующем году в этом посте будет минимум в 2 раза больше полезных материалов.
Если у вас есть мысли, идеи или вопросы по внедрению AI, всегда можно написать мне @seva_batareika
vikulin.ai
12 правил разработки проектов с LLM
Методология, которая помогает не оказаться в «кладбище пилотов»: четыре этапа, метрики качества, инструменты, агенты, дообучение и оптимизации.
1🔥72❤29❤🔥15👍7💅6💯2🙏1
Как посчитать профит от LLM. Если, конечно, он у вас есть.
Знаете, в чем феномен рекомендательных систем? Легко посчитать эффект. Обучили новую модель, потратили X денег на команду/железо. Провели АБ эксперимент, получили рост продаж на Y. Сравниваете X и Y. Для бизнеса все супер прозрачно.
В генеративном AI не так, 80 % компаний не видят финансового эффекта. Но не потому что LLM бесполезны. Обычно, LLM в компании делает что-то базово разумное (хотя бывает всякое). Но никто не может эффект от этой разумности посчитать. Почему это сложно, и что нам теперь делать, об этом сейчас поговорим.
В чем основная проблема
Статистика работает, когда данные стремятся к бесконечности. Если у рек. системы сотни тысяч пользователей, вы уже победили. Делаете АБ сплитование, считаете деньги. Команда будет счастливо работать десятки лет.
В LLM все намного сложнее. Допустим, мы делаем копайлот для сотрудника. Нам нужно:
1) АБ-инфраструктура. Уникальный айди, по которому мы можем сотрудников сплитовать, и система, которая оценивает его перфоманс. Перфоманс, кстати, не у всех профессий можно легко замерить.
2) Много сотрудников, чтобы мы могли что-то прокрасить в АБ.
Вывод. Можно надежно посчитать только для распространенных профессий, у которых легко измерить результативность.
Что делать?
Большинство внедрений LLM не подходят под условие выше. Что нам, теперь не вдрять Copilot для 10 программистов? Внедрять. Варианты:
1) Самое смелое — принять риски.
Посчитать через полгода интегральные метрики. Например, сколько вы сделали релизов, как часто пропускали критичные баги и тд.
2) Самое наивное — проводить массовые опросы.
По шкале от 1 до 10 оцени, насколько Copilot делает тебя продуктивным. Это, конечно, шляпа. Никто не скажет, что я не разобрался даже с главным меню и пользовался им 2 раза. Конечно, мой босс купил очень хороший Copilot!
3) Самое сложное — подумать.
Если вы не можете померить эффект, вам нужно создать прокси. Вы не можете оценить перфоманс менеджера, который пишет вам отчеты через LLM-копайлот. Но вы можете проверить, что менеджер хотя бы им нормально пользуется. Логировать все вопросы, проверять качество отчета (он же этот отчет потом нам покажет!) и оценить, сколько времени требовало бы написать этот отчет (через другие LLM, например). И дальше по пункту 1, но уже более осознанно.
Это затраты на отдельную инфраструктуру, но ее можно использовать во всех AI-проектах внутри компании. Знаю, это гениально, жаль я не придумал это первым :) Уже давно есть стартапы, которые делают такую инфраструктуру.
Резюме
Внедрение LLM тормозится не из-за мифической инертности компаний. Никто не будет долго думать, если ты кладешь в коробку рубль, а она выплевывает два. Дайте мне тысячи таких коробок! Проблема, что ты кладешь рубль, а коробка выплевывает AI. И что с этим AI теперь делать?
Мы с вами должны делать более прозрачные, предсказуемые коробки. Тогда наши коробки будут отрывать с руками.
Друзья, с наступающим! Пусть в следующем году профит от ваших проектов будет такой гигантский, что этот пост вам не пригодится. Спасибо, что читали весь этот год. Обещаю, что в 2026-м читать этот канал будет еще интереснее.
Знаете, в чем феномен рекомендательных систем? Легко посчитать эффект. Обучили новую модель, потратили X денег на команду/железо. Провели АБ эксперимент, получили рост продаж на Y. Сравниваете X и Y. Для бизнеса все супер прозрачно.
В генеративном AI не так, 80 % компаний не видят финансового эффекта. Но не потому что LLM бесполезны. Обычно, LLM в компании делает что-то базово разумное (хотя бывает всякое). Но никто не может эффект от этой разумности посчитать. Почему это сложно, и что нам теперь делать, об этом сейчас поговорим.
В чем основная проблема
Статистика работает, когда данные стремятся к бесконечности. Если у рек. системы сотни тысяч пользователей, вы уже победили. Делаете АБ сплитование, считаете деньги. Команда будет счастливо работать десятки лет.
В LLM все намного сложнее. Допустим, мы делаем копайлот для сотрудника. Нам нужно:
1) АБ-инфраструктура. Уникальный айди, по которому мы можем сотрудников сплитовать, и система, которая оценивает его перфоманс. Перфоманс, кстати, не у всех профессий можно легко замерить.
2) Много сотрудников, чтобы мы могли что-то прокрасить в АБ.
Вывод. Можно надежно посчитать только для распространенных профессий, у которых легко измерить результативность.
Что делать?
Большинство внедрений LLM не подходят под условие выше. Что нам, теперь не вдрять Copilot для 10 программистов? Внедрять. Варианты:
1) Самое смелое — принять риски.
Посчитать через полгода интегральные метрики. Например, сколько вы сделали релизов, как часто пропускали критичные баги и тд.
2) Самое наивное — проводить массовые опросы.
По шкале от 1 до 10 оцени, насколько Copilot делает тебя продуктивным. Это, конечно, шляпа. Никто не скажет, что я не разобрался даже с главным меню и пользовался им 2 раза. Конечно, мой босс купил очень хороший Copilot!
3) Самое сложное — подумать.
Если вы не можете померить эффект, вам нужно создать прокси. Вы не можете оценить перфоманс менеджера, который пишет вам отчеты через LLM-копайлот. Но вы можете проверить, что менеджер хотя бы им нормально пользуется. Логировать все вопросы, проверять качество отчета (он же этот отчет потом нам покажет!) и оценить, сколько времени требовало бы написать этот отчет (через другие LLM, например). И дальше по пункту 1, но уже более осознанно.
Это затраты на отдельную инфраструктуру, но ее можно использовать во всех AI-проектах внутри компании. Знаю, это гениально, жаль я не придумал это первым :) Уже давно есть стартапы, которые делают такую инфраструктуру.
Резюме
Внедрение LLM тормозится не из-за мифической инертности компаний. Никто не будет долго думать, если ты кладешь в коробку рубль, а она выплевывает два. Дайте мне тысячи таких коробок! Проблема, что ты кладешь рубль, а коробка выплевывает AI. И что с этим AI теперь делать?
Мы с вами должны делать более прозрачные, предсказуемые коробки. Тогда наши коробки будут отрывать с руками.
Друзья, с наступающим! Пусть в следующем году профит от ваших проектов будет такой гигантский, что этот пост вам не пригодится. Спасибо, что читали весь этот год. Обещаю, что в 2026-м читать этот канал будет еще интереснее.
❤52👍23🎉14💯3❤🔥2🔥2🤩2🎄1
Как рождается магия в AI-проектах.
Я обожаю чувствовать волшебство от работы. Когда качество твоей модели, твоего продукта кажется чем-то невозможным.
Но чудеса возникают совсем не так, как все предполагают. Когда команда гениальных инженеров запирается в комнате, заказывает пиццу и неистово обучает модели. Чаще магия рождается на стыке инженерии и бизнеса. Когда гибкие модели управляются жесткими бизнес-правилами. Ну, а теперь по порядку.
Магия R&D проектов
Это, как раз, про инженеров и пиццу. Когда ваша задача настолько непонятна, индустрия с таким не сталкивалась, про это всего 5 статей.
Лучшие инженеры с колоссальной интуицией ищут прорыв. Читают статьи, их имплементируют, проводят сотни экспертов. Большая часть провалится. Иногда один выстреливает. Тогда рождается магия.
За этим обычно и идут заниматься машинным обучением. Но знаете сколько таких проектов? 1 %.
Магия продуктовых проектов
Это задачи, где понятна технология. Классификация, суммаризация, простой чат-бот. Непонятно только одно. Что на самом деле нам нужно сделать?
Какой ответ для нашего продукта хороший? Как должен отвечать бот? Какие аспекты должны быть в суммаризации? К какому классу отнести эту категорию? Как только вы вместе с бизнес-заказчиком ответите, дальше все предельно понятно.
- Выделяем зоны, где гибкость модели действительно нужна, и она не создает экстремальные риски (не пихайте везде AI, пожалуйста).
- Делаем метрики качества.
- Подстраиваем под них модель (на промптах тоже можно!).
- Делаем итеративно, шаг за шагом, контролируя метрики и психологическое состояние.
И оно заработает. Я вам обещаю. Это самая предсказуемая магия в мире. Когда ты понимаешь, что нужно сделать, у тебя есть нужная технология и голова на плечах, тебя не остановить.
И таких проектов 99 %.
Вместо резюме
Большинство на старте проекта превращают его в R&D. Архитектуры, данные, функции потерь. И сразу теряют шансы на успех.
Надо начинать AI с общения. С диалога с тем, кто будет этот AI использовать. И тогда обязательно случится магия.
Да, и вот тогда, если остались ресурсы, можете идти делать еще R&D. Вот тогда уже можно.
Я обожаю чувствовать волшебство от работы. Когда качество твоей модели, твоего продукта кажется чем-то невозможным.
Но чудеса возникают совсем не так, как все предполагают. Когда команда гениальных инженеров запирается в комнате, заказывает пиццу и неистово обучает модели. Чаще магия рождается на стыке инженерии и бизнеса. Когда гибкие модели управляются жесткими бизнес-правилами. Ну, а теперь по порядку.
Магия R&D проектов
Это, как раз, про инженеров и пиццу. Когда ваша задача настолько непонятна, индустрия с таким не сталкивалась, про это всего 5 статей.
Лучшие инженеры с колоссальной интуицией ищут прорыв. Читают статьи, их имплементируют, проводят сотни экспертов. Большая часть провалится. Иногда один выстреливает. Тогда рождается магия.
За этим обычно и идут заниматься машинным обучением. Но знаете сколько таких проектов? 1 %.
Магия продуктовых проектов
Это задачи, где понятна технология. Классификация, суммаризация, простой чат-бот. Непонятно только одно. Что на самом деле нам нужно сделать?
Какой ответ для нашего продукта хороший? Как должен отвечать бот? Какие аспекты должны быть в суммаризации? К какому классу отнести эту категорию? Как только вы вместе с бизнес-заказчиком ответите, дальше все предельно понятно.
- Выделяем зоны, где гибкость модели действительно нужна, и она не создает экстремальные риски (не пихайте везде AI, пожалуйста).
- Делаем метрики качества.
- Подстраиваем под них модель (на промптах тоже можно!).
- Делаем итеративно, шаг за шагом, контролируя метрики и психологическое состояние.
И оно заработает. Я вам обещаю. Это самая предсказуемая магия в мире. Когда ты понимаешь, что нужно сделать, у тебя есть нужная технология и голова на плечах, тебя не остановить.
И таких проектов 99 %.
Вместо резюме
Большинство на старте проекта превращают его в R&D. Архитектуры, данные, функции потерь. И сразу теряют шансы на успех.
Надо начинать AI с общения. С диалога с тем, кто будет этот AI использовать. И тогда обязательно случится магия.
Да, и вот тогда, если остались ресурсы, можете идти делать еще R&D. Вот тогда уже можно.
🔥44👍19❤🔥7❤4👌4🥱2🥴1😍1
AI-агент рекрутер. Кейс компании LinkedIn
Рекрутер создает описание вакансии, агент уточняет детали, запускает поиск по базе из миллионов кандидатов, показывает только самых подходящих. Это не автоматизация, это другой подход к поиску кандидатов. Кому, как не LinkedIn, пришло в голову воплотить эту идею. Мы разберем устройство этого агента и найдем причины успеха продукта. Может, они не из-за AI-агента? Но давайте по порядку.
Архитектура
Агент построен на классической архитектуре Plan-And-Execute. Это простой, наглядный и итеративный процесс.
1) Главный субагент получает задачу от рекрутера. Смотрит на историю сообщений. Пытается понять, что рекрутер хочет сделать, насколько он явно выразил мысль, достаточно ли информации. Все рассуждения преобразует в план.
2) План превращается в список конкретных задач для будущих исполнителей. На этом этапе важно дать исполнителю ровно ту информацию, которая ему нужна для решения задачи, но не больше. Все как с людьми: важно все объяснить, но не перегрузить лишними деталями. Это называется изоляция контекста — основной паттерн проектирования агентских систем сейчас.
3) Задачи отправляются субагентам-исполнителям. Их великое множество. Ровно столько, сколько есть разных задач в рекрутменте:
— один собирает у рекрутера дополнительную информацию;
— второй формулирует множество запросов в поиск;
— третий оценивает, насколько кандидат подходит.
...
У каждого субагента есть только свой список тулов, которыми он может пользоваться. Это тоже изоляция, не надо давать кому угодно пользоваться чем угодно. Сломает или потеряет.
4) После того как все субагенты отработали, главный проверяет их результаты. Если цель не выполнена, переформулирует план, отправляет новые задачи. Может спросить совета у рекрутера, если есть вопросы (паттерн human-in-the-loop).
Что здесь на самом деле сложно
Вот такую архитектуру мы с вами можем собрать за 3 часа на n8n и ему подобных. HR-тех мы так не перевернем. Главный актив, над которым команда инженеров LinkedIn работала 99,9% времени — структурированные знания, которыми агент может пользоваться.
Это описания кандидатов, вакансий и успешных историй поиска, где нашли и наняли сотрудника. Это огромный массив данных, который где-то хранится, быстро обновляется и по которому могут быстро искать агенты и люди.
Хранить его просто в текстовом индексе крайне неэффективно. Сейчас все важнее становятся графовые базы данных, вроде neo4j, которые позволяют хранить разные зависимости между объектами. Например, в каких компаниях и в каких вузах учились наши лучшие сотрудники.
У самого LinkedIn есть известная база Economic Graph, в которой лежат структурированные данные по рынку труда, и он может ее легко применять в своих агентах.
Резюме
Да, вам нужно выучить паттерны создания надежных AI-продуктов (читая мой канал, конечно же). Иначе все точно развалится. Но правильная архитектура одного агента не сделает чуда.
Вам нужно оцифровать данные на пути, на котором создается ценность для пользователя. Потом сделать инструменты, чтобы агент мог этими данными пользоваться. Тогда агент сможет сам создавать ценность. Автономно, спрашивая вас только тогда, когда что-то непонятно. Тогда агенты действительно будут полезны бизнесу.
Без этого обычно все заканчивается презентацией прототипа. С очень хорошей архитектурой Plan-And-Execute. Но прототипа.
Рекрутер создает описание вакансии, агент уточняет детали, запускает поиск по базе из миллионов кандидатов, показывает только самых подходящих. Это не автоматизация, это другой подход к поиску кандидатов. Кому, как не LinkedIn, пришло в голову воплотить эту идею. Мы разберем устройство этого агента и найдем причины успеха продукта. Может, они не из-за AI-агента? Но давайте по порядку.
Архитектура
Агент построен на классической архитектуре Plan-And-Execute. Это простой, наглядный и итеративный процесс.
1) Главный субагент получает задачу от рекрутера. Смотрит на историю сообщений. Пытается понять, что рекрутер хочет сделать, насколько он явно выразил мысль, достаточно ли информации. Все рассуждения преобразует в план.
2) План превращается в список конкретных задач для будущих исполнителей. На этом этапе важно дать исполнителю ровно ту информацию, которая ему нужна для решения задачи, но не больше. Все как с людьми: важно все объяснить, но не перегрузить лишними деталями. Это называется изоляция контекста — основной паттерн проектирования агентских систем сейчас.
3) Задачи отправляются субагентам-исполнителям. Их великое множество. Ровно столько, сколько есть разных задач в рекрутменте:
— один собирает у рекрутера дополнительную информацию;
— второй формулирует множество запросов в поиск;
— третий оценивает, насколько кандидат подходит.
...
У каждого субагента есть только свой список тулов, которыми он может пользоваться. Это тоже изоляция, не надо давать кому угодно пользоваться чем угодно. Сломает или потеряет.
4) После того как все субагенты отработали, главный проверяет их результаты. Если цель не выполнена, переформулирует план, отправляет новые задачи. Может спросить совета у рекрутера, если есть вопросы (паттерн human-in-the-loop).
Что здесь на самом деле сложно
Вот такую архитектуру мы с вами можем собрать за 3 часа на n8n и ему подобных. HR-тех мы так не перевернем. Главный актив, над которым команда инженеров LinkedIn работала 99,9% времени — структурированные знания, которыми агент может пользоваться.
Это описания кандидатов, вакансий и успешных историй поиска, где нашли и наняли сотрудника. Это огромный массив данных, который где-то хранится, быстро обновляется и по которому могут быстро искать агенты и люди.
Хранить его просто в текстовом индексе крайне неэффективно. Сейчас все важнее становятся графовые базы данных, вроде neo4j, которые позволяют хранить разные зависимости между объектами. Например, в каких компаниях и в каких вузах учились наши лучшие сотрудники.
У самого LinkedIn есть известная база Economic Graph, в которой лежат структурированные данные по рынку труда, и он может ее легко применять в своих агентах.
Резюме
Да, вам нужно выучить паттерны создания надежных AI-продуктов (читая мой канал, конечно же). Иначе все точно развалится. Но правильная архитектура одного агента не сделает чуда.
Вам нужно оцифровать данные на пути, на котором создается ценность для пользователя. Потом сделать инструменты, чтобы агент мог этими данными пользоваться. Тогда агент сможет сам создавать ценность. Автономно, спрашивая вас только тогда, когда что-то непонятно. Тогда агенты действительно будут полезны бизнесу.
Без этого обычно все заканчивается презентацией прототипа. С очень хорошей архитектурой Plan-And-Execute. Но прототипа.
Linkedin
How we engineered LinkedIn’s Hiring Assistant
👍25❤🔥15🔥6❤4🥴4🤔1🙏1😍1
Observability в агентах. Почему прозрачность важнее технологичности.
LLM не славятся надежностью. Галлюцинации — топ-1 барьер для внедрения их в бизнес. Еще мы дали LLM кучу инструментов, разрешили ей планировать, добавили мультиагентность для души. Можно ли этот коктейль спроектировать так, чтобы всё это работало без сбоев? Нет. Обязательно что-то сломается.
Но что мы должны спроектировать — так это механизмы быстрого анализа того, где и что сломалось. Для этого есть инструменты, которые называются observability. Сегодня обсудим, что это и почему без этого невозможно использовать агентов в продакшене.
Что такое observability
В обычной разработке всё прозрачно: код — источник правды. При любой ошибке можно разобраться, что пошло не так.
В AI-разработке код ничего не объяснит. Источник правды — только история: какие были входные данные и какие действия совершила модель. Набор методов для эффективного анализа этой истории и есть observability. Это:
1. Сбор трейсов. Каждый новый запуск агента получает уникальный идентификатор, к которому привязываются все действия агента в рамках этого запуска. В итоге получается цепочка действий, которая называется трейс. Его дальше и анализируют.
2. Логирование. Все инструменты (тулы) должны логировать входные данные, промежуточные состояния, ошибки и финальный ответ. Тогда тулы в трейсе можно отдебажить.
3. Метрики качества (подробнее тут). В рамках одного трейса нужно обязательно оценить финальный ответ агента и, желательно, все его промежуточные действия. Разметить всё это вручную нереально, чаще используется LLM-as-a-judge (гайд по теме)
4. Дашборды. Помимо метрик качества, там должны быть технические метрики: скорость ответа, среднее число токенов и т. д.
Самые известные observability-библиотеки — это Langfuse и Arize Phoenix.
Как это работает вместе
- Вы мониторите состояние агентов на дашборде по техническим метрикам и метрикам качества.
- Если произошло падение метрик, выбираете трейсы, где аномально плохое качество, и дебажите: в какой момент времени и что именно сломалось.
- Во время дебага смотрите на прокси-метрики действий агента (через LLM-as-a-judge), проверяете все тулы. Благо для этого мы заранее настроили логирование.
Без этого пайплайна разбор любой ошибки агента будет занимать вечность. И ваш проект так и останется на слайдах пилоте.
Резюме
Черные технологичные ящики — это прикольно на презентации. Для инвесторов и начальников. Об этом прикольно рассказывать коллегам и друзьям. Но их очень не прикольно масштабировать и держать в продакшене. Любая поломка черного ящика — всю ночь будете разбирать причину. Лучше сделайте эти ящики прозрачными и спите спокойно.
Друзья, если у вас есть вопрос, как сделать AI более прозрачным, пишите мне @seva_batareika. Разберем его отдельно.
LLM не славятся надежностью. Галлюцинации — топ-1 барьер для внедрения их в бизнес. Еще мы дали LLM кучу инструментов, разрешили ей планировать, добавили мультиагентность для души. Можно ли этот коктейль спроектировать так, чтобы всё это работало без сбоев? Нет. Обязательно что-то сломается.
Но что мы должны спроектировать — так это механизмы быстрого анализа того, где и что сломалось. Для этого есть инструменты, которые называются observability. Сегодня обсудим, что это и почему без этого невозможно использовать агентов в продакшене.
Что такое observability
В обычной разработке всё прозрачно: код — источник правды. При любой ошибке можно разобраться, что пошло не так.
В AI-разработке код ничего не объяснит. Источник правды — только история: какие были входные данные и какие действия совершила модель. Набор методов для эффективного анализа этой истории и есть observability. Это:
1. Сбор трейсов. Каждый новый запуск агента получает уникальный идентификатор, к которому привязываются все действия агента в рамках этого запуска. В итоге получается цепочка действий, которая называется трейс. Его дальше и анализируют.
2. Логирование. Все инструменты (тулы) должны логировать входные данные, промежуточные состояния, ошибки и финальный ответ. Тогда тулы в трейсе можно отдебажить.
3. Метрики качества (подробнее тут). В рамках одного трейса нужно обязательно оценить финальный ответ агента и, желательно, все его промежуточные действия. Разметить всё это вручную нереально, чаще используется LLM-as-a-judge (гайд по теме)
4. Дашборды. Помимо метрик качества, там должны быть технические метрики: скорость ответа, среднее число токенов и т. д.
Самые известные observability-библиотеки — это Langfuse и Arize Phoenix.
Как это работает вместе
- Вы мониторите состояние агентов на дашборде по техническим метрикам и метрикам качества.
- Если произошло падение метрик, выбираете трейсы, где аномально плохое качество, и дебажите: в какой момент времени и что именно сломалось.
- Во время дебага смотрите на прокси-метрики действий агента (через LLM-as-a-judge), проверяете все тулы. Благо для этого мы заранее настроили логирование.
Без этого пайплайна разбор любой ошибки агента будет занимать вечность. И ваш проект так и останется на слайдах пилоте.
Резюме
Черные технологичные ящики — это прикольно на презентации. Для инвесторов и начальников. Об этом прикольно рассказывать коллегам и друзьям. Но их очень не прикольно масштабировать и держать в продакшене. Любая поломка черного ящика — всю ночь будете разбирать причину. Лучше сделайте эти ящики прозрачными и спите спокойно.
Друзья, если у вас есть вопрос, как сделать AI более прозрачным, пишите мне @seva_batareika. Разберем его отдельно.
1🔥39❤15👍11❤🔥3😁2🤩1🗿1
Испечь AI-агента и не сжечь продакшн. Разбор ингредиентов
При масштабировании агентов не стоит придумывать с нуля архитектуру для каждой новой задачи. Разработка агентов — новейшая область, у вас огромный риск, что эксперимент провалится. Процесс должен быть похож на выпечку торта по бабушкиному рецепту: мука, яйца, шоколад, а лучше побольше шоколада...
Сегодня мы разберем эти ингредиенты и способы их замеса в шикарный, предсказуемый агентский торт (весь пост удачно проиллюстрирован картинкой).
Из каких компонентов состоят агенты
5 кубиков агентской системы:
1) Оркестратор. Сердце (душа?) агента
Это runtime-движок, который управляет бесконечным циклом работы агента. Оркестратор запускает все компоненты с нужными аргументами, обрабатывает их выходные данные и ошибки, если они случились. Он работает по определенному шаблону, вроде ReAct (подумай, потом сделай), Plan-Execute (составь план и иди строго по нему) и т. д. Физически это Python-код, реализованный, например, на базе LangGraph/LangChain. Но можно написать это и с нуля.
2) LLM. Мозг агента
Оркестратор собирает промпт и отправляет его в LLM, чтобы «мозг» решил, что делать дальше. Можно использовать разные модели под разные задачи: дорогие — для редких и сложных, модели попроще — для массовых операций. Физически это либо API к облачному провайдеру, либо API к LLM на ваших серверах.
3) Инструменты. Руки агента
Любые программы, которые агент может вызывать для решения задачи. Удобно использовать какой-то протокол, например, MCP. Инструментом может быть и другой агент, тогда получится мультиагентная система.
4) Контекстное окно. Память агента
Управление контекстным окном — одна из сложнейших задач. Нужно, чтобы в каждый момент запуска LLM в контексте была ровно та информация, которая необходима для решения текущей проблемы. Чем больше мусора в контексте, тем выше шанс, что «мозг» сломается. Физически это реализуется через различные методы работы с памятью: сжатие, вытеснение старых данных во внешнюю память и т. д.
5) Внешняя информация. Знания агента
Здесь лежат данные, которые не нужны в контексте прямо сейчас, но могут потребоваться позже. Физически это базы знаний или файлы. Доступ к ним происходит через RAG или инструменты поиска (вроде командной строки grep).
Как компоненты взаимодействуют
Всё взаимодействие идет через оркестратор. Но чтобы агент был прозрачным и безопасным, мы делаем это не напрямую, а через специальные прокси-сервисы — Gateways (шлюзы). У них две цели:
- Аналитика. Нужно логировать всё, что запустил оркестратор, чтобы потом собирать метрики и строить дашборды. Подробнее мы обсуждали это в прошлом посте про observability.
- Безопасность. Каждое действие оркестратора должно проходить проверку. Это контроль доступов к файлам, анализ контекста на prompt injection, проверка безопасности инструментов, шифрование персональных данных и т. д.
Заключение
Следуя этому рецепту, вы сможете не просто выпекать более надежных агентов, но и делать это каждый раз все качественнее и быстрее.
Улучшение любого компонента автоматически улучшает всех агентов компании. А каждый новый инструмент может быть переиспользован в будущих проектах.
Это та самая рецептура масштабного внедрения AI в компании, которую я каждому желаю освоить. Не все же нам дошираки заваривать?
При масштабировании агентов не стоит придумывать с нуля архитектуру для каждой новой задачи. Разработка агентов — новейшая область, у вас огромный риск, что эксперимент провалится. Процесс должен быть похож на выпечку торта по бабушкиному рецепту: мука, яйца, шоколад, а лучше побольше шоколада...
Сегодня мы разберем эти ингредиенты и способы их замеса в шикарный, предсказуемый агентский торт (весь пост удачно проиллюстрирован картинкой).
Из каких компонентов состоят агенты
5 кубиков агентской системы:
1) Оркестратор. Сердце (душа?) агента
Это runtime-движок, который управляет бесконечным циклом работы агента. Оркестратор запускает все компоненты с нужными аргументами, обрабатывает их выходные данные и ошибки, если они случились. Он работает по определенному шаблону, вроде ReAct (подумай, потом сделай), Plan-Execute (составь план и иди строго по нему) и т. д. Физически это Python-код, реализованный, например, на базе LangGraph/LangChain. Но можно написать это и с нуля.
2) LLM. Мозг агента
Оркестратор собирает промпт и отправляет его в LLM, чтобы «мозг» решил, что делать дальше. Можно использовать разные модели под разные задачи: дорогие — для редких и сложных, модели попроще — для массовых операций. Физически это либо API к облачному провайдеру, либо API к LLM на ваших серверах.
3) Инструменты. Руки агента
Любые программы, которые агент может вызывать для решения задачи. Удобно использовать какой-то протокол, например, MCP. Инструментом может быть и другой агент, тогда получится мультиагентная система.
4) Контекстное окно. Память агента
Управление контекстным окном — одна из сложнейших задач. Нужно, чтобы в каждый момент запуска LLM в контексте была ровно та информация, которая необходима для решения текущей проблемы. Чем больше мусора в контексте, тем выше шанс, что «мозг» сломается. Физически это реализуется через различные методы работы с памятью: сжатие, вытеснение старых данных во внешнюю память и т. д.
5) Внешняя информация. Знания агента
Здесь лежат данные, которые не нужны в контексте прямо сейчас, но могут потребоваться позже. Физически это базы знаний или файлы. Доступ к ним происходит через RAG или инструменты поиска (вроде командной строки grep).
Как компоненты взаимодействуют
Всё взаимодействие идет через оркестратор. Но чтобы агент был прозрачным и безопасным, мы делаем это не напрямую, а через специальные прокси-сервисы — Gateways (шлюзы). У них две цели:
- Аналитика. Нужно логировать всё, что запустил оркестратор, чтобы потом собирать метрики и строить дашборды. Подробнее мы обсуждали это в прошлом посте про observability.
- Безопасность. Каждое действие оркестратора должно проходить проверку. Это контроль доступов к файлам, анализ контекста на prompt injection, проверка безопасности инструментов, шифрование персональных данных и т. д.
Заключение
Следуя этому рецепту, вы сможете не просто выпекать более надежных агентов, но и делать это каждый раз все качественнее и быстрее.
Улучшение любого компонента автоматически улучшает всех агентов компании. А каждый новый инструмент может быть переиспользован в будущих проектах.
Это та самая рецептура масштабного внедрения AI в компании, которую я каждому желаю освоить. Не все же нам дошираки заваривать?
👍48🔥19❤10🤷♂7❤🔥3🥰2😁2🗿2
Оркестратор AI-агента. 5 типов и инструкция по их применению.
В прошлом посте мы разобрали, из каких ингредиентов состоят агенты. Сегодня поговорим про оркестратор, который управляет процессом решения задачи и связывает все компоненты воедино.
От выбора оркестратора зависит, будет ли агент вашим надежным другом или галлюцинирующим кошмаром. Мы разберем 5 базовых типов (см. 5 картинок), которые нужно применять к разным задачам.
1. LLM-Workflow (Детерминированное исполнение)
Самый надежный и распространенный вариант в продакшене. Порядок действий жестко задан разработчиком в коде. LLM здесь используется как функция внутри жесткого графа: например, суммаризует ответ, извлекает сущности или классифицирует тексты.
Плюсы: надежно, предсказуемо, дешево.
Минусы: нужно этот граф написать руками. Для творческих процессов не подходит совсем.
Когда использовать: для процессов с высокими рисками и понятным регламентом. Например, умный документооборот, ответы на вопросы клиентов.
2. ReAct (Рассуждение и выбор действия)
Базовый вариант автономного агента. Процесс заранее не зафиксирован. Модель работает в цикле: "Подумал → Выбрал инструмент → Получил результат". Здесь уже сама LLM решает, какой инструмент вызвать и когда остановиться.
Плюсы: гибкость. Может выбирать разные действия под ситуацию.
Минусы: часто ломается в долгих задачах (застревает в цикле или забывает цель).
Когда использовать: для простых коротких задач с небольшим числом инструментов (например, «найди курс валюты и отправь в Slack»).
3. Reflexion (Рефлексия)
Умная надстройка над ReAct. В цикл добавляется этап "Рефлексии". Агент получает результат от инструмента, но не бежит дальше, а оценивает: "А то ли я сделал?". Если нет — пересматривает ответ. И так может делать несколько раз для одного действия. Мой любимый паттерн, я тоже мнительный :)
Плюсы: критически поднимает качество в задачах, где результат можно валидировать (код, математика).
Минусы: мнительность ест много токенов и замедляет работу.
Когда использовать: когда фидбек инструмента максимально полезен. Например, программирование, где фидбек — ошибка выполнения программы.
4. Plan-and-Execute (Планирование и исполнение)
Сначала LLM составляет план, затем шаг за шагом другой оркестратор (например, Reflexion) этот план исполняет. Всё работает в едином контекстном окне. Как только план выполнен, LLM проверяет: задача решена или нужно составить новый план?
Плюсы: рабочий вариант решения долгих задач без LLM-Workflow.
Минусы: страдает от "распухания" контекста. В истории накапливается столько мусора, что модель ломается.
Когда использовать: для длинных цепочек действий, где шаги жестко зависят друг от друга (любая последовательная аналитика).
5. Plan-and-Execute + Мультиагентность
План создается как в прошлом пункте, но каждую задачу изолированно решает отдельный оркестратор (субагент). У каждого субагента — своя узкая задача и только необходимая для неё информация, они не делятся контекстом.
Плюсы: мощь планирования + надежность исполнения
Минусы: можно использовать только для узкого класса задач
Когда использовать: всегда, когда задачу можно разбить на независимые блоки. Например, написание большого отчета (мы разбирали DeepResearch).
Резюме
Это 5 базовых паттернов. На практике мы их комбинируем. Ваш «агент мечты» может выглядеть как надежный LLM-Workflow, в узлах которого вызываются более автономные агенты для сложных задач.
Главное правило выбора: берите самую простую архитектуру, способную решить вашу задачу. Если вы можете написать детерминированный Workflow — напишите и забудьте. За каждую каплю автономности вы платите надежностью и рисками.
В прошлом посте мы разобрали, из каких ингредиентов состоят агенты. Сегодня поговорим про оркестратор, который управляет процессом решения задачи и связывает все компоненты воедино.
От выбора оркестратора зависит, будет ли агент вашим надежным другом или галлюцинирующим кошмаром. Мы разберем 5 базовых типов (см. 5 картинок), которые нужно применять к разным задачам.
1. LLM-Workflow (Детерминированное исполнение)
Самый надежный и распространенный вариант в продакшене. Порядок действий жестко задан разработчиком в коде. LLM здесь используется как функция внутри жесткого графа: например, суммаризует ответ, извлекает сущности или классифицирует тексты.
Плюсы: надежно, предсказуемо, дешево.
Минусы: нужно этот граф написать руками. Для творческих процессов не подходит совсем.
Когда использовать: для процессов с высокими рисками и понятным регламентом. Например, умный документооборот, ответы на вопросы клиентов.
2. ReAct (Рассуждение и выбор действия)
Базовый вариант автономного агента. Процесс заранее не зафиксирован. Модель работает в цикле: "Подумал → Выбрал инструмент → Получил результат". Здесь уже сама LLM решает, какой инструмент вызвать и когда остановиться.
Плюсы: гибкость. Может выбирать разные действия под ситуацию.
Минусы: часто ломается в долгих задачах (застревает в цикле или забывает цель).
Когда использовать: для простых коротких задач с небольшим числом инструментов (например, «найди курс валюты и отправь в Slack»).
3. Reflexion (Рефлексия)
Умная надстройка над ReAct. В цикл добавляется этап "Рефлексии". Агент получает результат от инструмента, но не бежит дальше, а оценивает: "А то ли я сделал?". Если нет — пересматривает ответ. И так может делать несколько раз для одного действия. Мой любимый паттерн, я тоже мнительный :)
Плюсы: критически поднимает качество в задачах, где результат можно валидировать (код, математика).
Минусы: мнительность ест много токенов и замедляет работу.
Когда использовать: когда фидбек инструмента максимально полезен. Например, программирование, где фидбек — ошибка выполнения программы.
4. Plan-and-Execute (Планирование и исполнение)
Сначала LLM составляет план, затем шаг за шагом другой оркестратор (например, Reflexion) этот план исполняет. Всё работает в едином контекстном окне. Как только план выполнен, LLM проверяет: задача решена или нужно составить новый план?
Плюсы: рабочий вариант решения долгих задач без LLM-Workflow.
Минусы: страдает от "распухания" контекста. В истории накапливается столько мусора, что модель ломается.
Когда использовать: для длинных цепочек действий, где шаги жестко зависят друг от друга (любая последовательная аналитика).
5. Plan-and-Execute + Мультиагентность
План создается как в прошлом пункте, но каждую задачу изолированно решает отдельный оркестратор (субагент). У каждого субагента — своя узкая задача и только необходимая для неё информация, они не делятся контекстом.
Плюсы: мощь планирования + надежность исполнения
Минусы: можно использовать только для узкого класса задач
Когда использовать: всегда, когда задачу можно разбить на независимые блоки. Например, написание большого отчета (мы разбирали DeepResearch).
Резюме
Это 5 базовых паттернов. На практике мы их комбинируем. Ваш «агент мечты» может выглядеть как надежный LLM-Workflow, в узлах которого вызываются более автономные агенты для сложных задач.
Главное правило выбора: берите самую простую архитектуру, способную решить вашу задачу. Если вы можете написать детерминированный Workflow — напишите и забудьте. За каждую каплю автономности вы платите надежностью и рисками.
2🔥48👍16❤13❤🔥6🙏2💯2🤩1
Вправляем мозги AI-агенту: 3 закона успешного LLM-инференса
Недавно мы разбирали рецептуру приготовления AI-агентов. Сегодня детально поговорим про один из главных ингредиентов — LLM (мозг агента). А точнее, про инференс: как заставить этот мозг работать так, чтобы агент был надежным, безопасным и не стоил вам как крыло самолета?
1. Запрос к LLM должен идти через Gateway (Шлюз)
Нельзя пускать компоненты агента напрямую к моделям. Все запросы — неважно, к внешней API или к вашей внутренней модели — должны проходить через единый прокси-сервис (Gateway). Клиент общается только с ним. Что должно быть «под капотом» у шлюза:
- Аналитика: логируем, какую модель вызвали, сколько токенов съели и как долго она отвечала. Без этого вы не посчитаете ни health-статус системы, ни юнит-экономику, ни качество.
- Безопасность: здесь мы прячем шифрование персональных данных, аутентификацию и проверку входного промпта на prompt injection.
- Кэширование: сохраняем популярные ответы, чтобы не гонять модели вхолостую.
- Контролируемая деградация: GPU неизбежно выходят из строя, а резервировать железо х2 — удел AI-мажоров. Шлюз должен уметь перехватывать ошибки отвалившегося сервера и бесшовно переводить запрос на модель поменьше (или в код, или в модель в облаке ). Пусть агент временно деградирует, но сама система продолжает решать задачу бизнеса (с контролиуремо меньшим качеством).
Кстати, хороший пример такого Gateway можно подсмотреть у коллег из Uber.
2. Стоимость инференса — KPI отдельной команды
Выжимать максимум из своих LLM — это отдельное искусство. Алгоритмы батчинга, квантизации, кэширования непрырвно обновляются в разных фреймворках (в статье, например, коллеги перечислили все 100500 примочек для инференса).
Эти методы не универсальны и сильно зависят от задачи. У вас должна быть выделенная ML-инфра команда, которая будет разбираться во всех нюансов инференса LLM. Их прямой KPI — удешевлять и ускорять генерацию токенов для разных продуктов компании. Чем больше потребение LLM в вашей компании, тем мощнее будет ROI этой команды.
3. Понимайте потребление LLM в вашей компании
В зависимости от того, как ваши продукты потребляют мощности, выбирается архитектура инференса.
- Единый LLM-сервис на всю компанию
Одна команда развернула сервис с LLM. Все продукты ходят в эту одну общую «розетку».
Плюсы: эффективная утилизация железа и проще сделать надежную и стабильную архитектуру (она ведь всего одна).
Минусы: больно кастомизировать инференс под специфические хотелки конкретных бизнес-юнитов. А это важно, потому что смотри пункт 2. И чем больше потребления, тем более важно. Ну и нельзя разворачивать дообученные модели, разве что через LORA, как мы обсуждали.
Вердикт: Всегда начинайте с этого. Идеально для старта и для продуктов с низкой или средней частотой запросов.
- Выделенный LLM-инференс под продукт
Продукт физически забирает сервера с картами и разворачивает инференс сугубо под себя.
Плюсы: можно тонко настроить инференс под конкретного потребителя и выжать максимум скорости.
Минусы: если дать эту свободу всем подряд, вы получите зоопарк из сотни инференсов, где на каждом дорогущем сервере H100 будет обрабатываться по одному запросу в час.
Вердикт: Делать только для гигантских потребителей, и строго после первого варианта. И еще нужно будет создавать AI-полицию, которая ходит и проверяет, что этот большой продукт реально использует все карты. Ну и отнимает их, если что.
Резюме
Инференс LLM — это самый дорогой и капризный ингредиент в вашем AI-торте. Если пустить его в продакшн без присмотра, он сожрет весь бюджет и бесценные нервы (я не люблю просыпаться по ночам, когда инференс сломался). Готовьте агентов системно: продумайте архитектуру, платформизируйте компоненты и не экономьте на команде оптимизации.
Недавно мы разбирали рецептуру приготовления AI-агентов. Сегодня детально поговорим про один из главных ингредиентов — LLM (мозг агента). А точнее, про инференс: как заставить этот мозг работать так, чтобы агент был надежным, безопасным и не стоил вам как крыло самолета?
1. Запрос к LLM должен идти через Gateway (Шлюз)
Нельзя пускать компоненты агента напрямую к моделям. Все запросы — неважно, к внешней API или к вашей внутренней модели — должны проходить через единый прокси-сервис (Gateway). Клиент общается только с ним. Что должно быть «под капотом» у шлюза:
- Аналитика: логируем, какую модель вызвали, сколько токенов съели и как долго она отвечала. Без этого вы не посчитаете ни health-статус системы, ни юнит-экономику, ни качество.
- Безопасность: здесь мы прячем шифрование персональных данных, аутентификацию и проверку входного промпта на prompt injection.
- Кэширование: сохраняем популярные ответы, чтобы не гонять модели вхолостую.
- Контролируемая деградация: GPU неизбежно выходят из строя, а резервировать железо х2 — удел AI-мажоров. Шлюз должен уметь перехватывать ошибки отвалившегося сервера и бесшовно переводить запрос на модель поменьше (или в код, или в модель в облаке ). Пусть агент временно деградирует, но сама система продолжает решать задачу бизнеса (с контролиуремо меньшим качеством).
Кстати, хороший пример такого Gateway можно подсмотреть у коллег из Uber.
2. Стоимость инференса — KPI отдельной команды
Выжимать максимум из своих LLM — это отдельное искусство. Алгоритмы батчинга, квантизации, кэширования непрырвно обновляются в разных фреймворках (в статье, например, коллеги перечислили все 100500 примочек для инференса).
Эти методы не универсальны и сильно зависят от задачи. У вас должна быть выделенная ML-инфра команда, которая будет разбираться во всех нюансов инференса LLM. Их прямой KPI — удешевлять и ускорять генерацию токенов для разных продуктов компании. Чем больше потребение LLM в вашей компании, тем мощнее будет ROI этой команды.
3. Понимайте потребление LLM в вашей компании
В зависимости от того, как ваши продукты потребляют мощности, выбирается архитектура инференса.
- Единый LLM-сервис на всю компанию
Одна команда развернула сервис с LLM. Все продукты ходят в эту одну общую «розетку».
Плюсы: эффективная утилизация железа и проще сделать надежную и стабильную архитектуру (она ведь всего одна).
Минусы: больно кастомизировать инференс под специфические хотелки конкретных бизнес-юнитов. А это важно, потому что смотри пункт 2. И чем больше потребления, тем более важно. Ну и нельзя разворачивать дообученные модели, разве что через LORA, как мы обсуждали.
Вердикт: Всегда начинайте с этого. Идеально для старта и для продуктов с низкой или средней частотой запросов.
- Выделенный LLM-инференс под продукт
Продукт физически забирает сервера с картами и разворачивает инференс сугубо под себя.
Плюсы: можно тонко настроить инференс под конкретного потребителя и выжать максимум скорости.
Минусы: если дать эту свободу всем подряд, вы получите зоопарк из сотни инференсов, где на каждом дорогущем сервере H100 будет обрабатываться по одному запросу в час.
Вердикт: Делать только для гигантских потребителей, и строго после первого варианта. И еще нужно будет создавать AI-полицию, которая ходит и проверяет, что этот большой продукт реально использует все карты. Ну и отнимает их, если что.
Резюме
Инференс LLM — это самый дорогой и капризный ингредиент в вашем AI-торте. Если пустить его в продакшн без присмотра, он сожрет весь бюджет и бесценные нервы (я не люблю просыпаться по ночам, когда инференс сломался). Готовьте агентов системно: продумайте архитектуру, платформизируйте компоненты и не экономьте на команде оптимизации.
1👍35❤13🔥13❤🔥2🤩1🙏1🐳1💯1
Контекст — всему голова. Почему In-Context Learning — единственный способ строить надежные AI-продукты
Я ненавижу галлюцинации. Я хочу их все уничтожить. Но чтобы победить врага, мне нужно научиться его определять.
Сама LLMсгаллюцинировала дала такое определение галлюцинаций: «Феномен, при котором LLM генерирует уверенные, но фактически неверные, вымышленные ответы». Мне это совсем не помогает. Что значит «фактически неверный» в вакууме? Где источник правды, что есть верные факты?
Но мы можем уточнить правила работы с LLM: всегда давать контент и требуем отвечать строго по нему. Тогда враг становится осязаемым: галлюцинация — это любой ответ, который не строится на выданном тексте. А если мы знаем, как искать врага, мы сможем его уничтожить. И сейчас я покажу как.
Что такое In-Context Learning
Мы закладываем все ожидаемое поведение LLM (то есть обучаем) прямо в контекстное окно (промпт). Без классического обучения.
- Нужно, чтобы модель узнала информацию? Закинули RAG в контекст.
- Модель делает ошибку? Написали в промпте корнер-кейс (от души прошу, не делай так»).
- Нужно рассуждение? Просто попросили подумать шаг за шагом.
- Модель тупит? Почистили контекст от мусора.
Это в разы быстрее и дешевле, чем дообучать саму модель. Скорость итераций взлетает. А главное — это легко оценивать и контролировать.
Как теперь мы уничтожаем галлюцинации
Как только мы зафиксировали чудовище, его очень просто победить. Алгоритм прямолинейный:
1. Мы делаем строгую метрику, которая автоматически детектирует: модель взяла ответ из выданного текста или выдумала его из своих «весов»? (вот тут написано как делать)
2. Мы начинаем мочить модель, чтобы она не отвечала из весов. Как обычно, 3-мя способами: промтинг, раг, дообучение (тут особенно круто раскрывается методы Reinforcment Learning)
Минусы подхода очевидны. Придется строить инфраструктуру, чтобы этот контекст собирать. Ходить в нужные системы, доставать информацию и пихать ее в промпт. Контекст будет «пухнуть», а модели на больших объемах данных могут терять фокус. Благо, с каждым днем они справляются с этим всё лучше. Тренд играет за нас.
LLM — движок рассуждений, а не энциклопедия
Эта логика в будущем сможет уменьшить размеры базовых моделей. LLM такие L (большие), потому что тащат в свои веса и нужное и всякий мусор. Посмотрите на бенчмарки: LLM знают кучу энциклопедических знаний, который любой инженер посмотрит в любимом справочнике. Они кодируют все эти знания в веса, чтобы хорошо предсказывать следующее слова.
Для моих кейсов не важно, чтобы LLM знала анатомию горилл. Можно, пожалуйста, не платить за горилл стоимостью инференса?
Я верю, что модели должны стать исключительно процессорами информации. Запомнить базовое — да. Всё остальное делать только логическими операциями на основе доверенных источников (но не стоит брать за источник правды текущие LLM, иначе весь этот схематоз развалится)
Нудное резюме
Хотите делать надежные AI-продукты? Нудно, системно и последовательно собирайте информацию, которая будете скармливать моделям нужный контекст.
Да, вам придется хорошенько подумать, какую именно информацию и когда вставлять. Зато, если не подумаете вы, LLM с радостью «подумает» за вас. И эта галлюцинация вам точно не понравится.
Я ненавижу галлюцинации. Я хочу их все уничтожить. Но чтобы победить врага, мне нужно научиться его определять.
Сама LLM
Но мы можем уточнить правила работы с LLM: всегда давать контент и требуем отвечать строго по нему. Тогда враг становится осязаемым: галлюцинация — это любой ответ, который не строится на выданном тексте. А если мы знаем, как искать врага, мы сможем его уничтожить. И сейчас я покажу как.
Что такое In-Context Learning
Мы закладываем все ожидаемое поведение LLM (то есть обучаем) прямо в контекстное окно (промпт). Без классического обучения.
- Нужно, чтобы модель узнала информацию? Закинули RAG в контекст.
- Модель делает ошибку? Написали в промпте корнер-кейс (от души прошу, не делай так»).
- Нужно рассуждение? Просто попросили подумать шаг за шагом.
- Модель тупит? Почистили контекст от мусора.
Это в разы быстрее и дешевле, чем дообучать саму модель. Скорость итераций взлетает. А главное — это легко оценивать и контролировать.
Как теперь мы уничтожаем галлюцинации
Как только мы зафиксировали чудовище, его очень просто победить. Алгоритм прямолинейный:
1. Мы делаем строгую метрику, которая автоматически детектирует: модель взяла ответ из выданного текста или выдумала его из своих «весов»? (вот тут написано как делать)
2. Мы начинаем мочить модель, чтобы она не отвечала из весов. Как обычно, 3-мя способами: промтинг, раг, дообучение (тут особенно круто раскрывается методы Reinforcment Learning)
Минусы подхода очевидны. Придется строить инфраструктуру, чтобы этот контекст собирать. Ходить в нужные системы, доставать информацию и пихать ее в промпт. Контекст будет «пухнуть», а модели на больших объемах данных могут терять фокус. Благо, с каждым днем они справляются с этим всё лучше. Тренд играет за нас.
LLM — движок рассуждений, а не энциклопедия
Эта логика в будущем сможет уменьшить размеры базовых моделей. LLM такие L (большие), потому что тащат в свои веса и нужное и всякий мусор. Посмотрите на бенчмарки: LLM знают кучу энциклопедических знаний, который любой инженер посмотрит в любимом справочнике. Они кодируют все эти знания в веса, чтобы хорошо предсказывать следующее слова.
Для моих кейсов не важно, чтобы LLM знала анатомию горилл. Можно, пожалуйста, не платить за горилл стоимостью инференса?
Я верю, что модели должны стать исключительно процессорами информации. Запомнить базовое — да. Всё остальное делать только логическими операциями на основе доверенных источников (но не стоит брать за источник правды текущие LLM, иначе весь этот схематоз развалится)
Нудное резюме
Хотите делать надежные AI-продукты? Нудно, системно и последовательно собирайте информацию, которая будете скармливать моделям нужный контекст.
Да, вам придется хорошенько подумать, какую именно информацию и когда вставлять. Зато, если не подумаете вы, LLM с радостью «подумает» за вас. И эта галлюцинация вам точно не понравится.
1🔥39👍18❤7❤🔥5💯2🙏1🐳1
Модель управляемого риска: подбираем AI-агента под свои нервы
В разработке агентов, как и в инвестициях, есть связка риск/профит. За потенциальную выгоду мы платим риском, который берем на себя.
У AI-агентов обе величины сильно зависят от автономности. Система, где LLM в один промпт суммаризует диалог с клиентом — низкая автономность. Это и не очень рискованно, но профит ограничен. Автономный агент с доступом к CRM и возможностью отправить клиентам email — это уже совсем другая история. Потенциальный эффект выше, но и риск резко возрастает. Это удобно визуализировать на графике риск/профит (см. картинку).
Разберем, как разные архитектуры агентов ложатся в эту кривую — и как по этому графику выбрать архитектуру под вашу задачу. Начнем с архитектур.
Контролируемый рост риска (LLM-workflow)
Самый предсказуемый вариант — фиксированная цепочка промптов, то есть оркестрация LLM-workflow (см. пост про орестрации).
Все шаги прописаны заранее, у системы почти нет свободы “уйти не туда”. Каждую ветку можно отдельно отладить и измерить. Такая система прозрачна и контролируема. На этом участке кривой можно довольно предсказуемо наращивать ценность: добавлять новые узлы в граф, расширять логику, улучшать покрытие кейсов. Риск тоже растет, но управляемо.
Взрыв риска (автономный агент)
Но бесконечно растить workflow не получится: в какой-то момент сложность начинает съедать команду разработки. Тогда возникает соблазн перейти к автономному агенту (например, ReAct или Plan-and-Execute) — и дать ему набор ограниченных инструментов.
В этот момент потенциальная ценность и риск одновременно подскакивают.И вместе с этим подскакивает нагрузка на команду, потому что теперь нужно управлять новым классом рисков: контроль доступов к тулам, защита от prompt injection, observability и тд). Иначе разработка быстро превращается в гадание на таро (долбанет, или пронесет?).
Граница текущей технологии (переизбыток тулов)
Дальше наступает момент, когда дополнительная автономность перестает окупаться. Инструментов становится все больше, они сложнее, контекст длиннее, а модель начинает чаще тупить и галлюцинировать. Вы подходите к границе, которую текущие LLM еще могут выдержать. Вселенная как будто говорит: “Остановись”.
Автономность вредит (агент из телеграм-каналов)
Модель настолько тупит, что с ростом автнономности качество уже деградирует. Надо было послушать вселенную в прошлом пункте.
Концепция интересная, делать то что?
Самое важное: архитектуру AI-системы нужно подбирать под риск, который вы способны контролировать, а не под максимальный профит, который она теоретически может дать. Второе: каждая новая капля автономности требует дополнительных усилий на контроль риска.
Отсюда универсальное правило: начинайте с минимальной автономности, которая может решить задачу. Например: один вызов к LLM → затем цепочка промптов → затем агент → затем новые инструменты.
И на каждом шаге задавайте два вопроса:
1) Сильно ли растет качество?
Если нет — значит, вы уже уперлись в предел, и дальше усложнять систему нет смыла. Хорошая новость, что во многих задачах низкорисковой архитектуры вполне достаточно. Не везде нужен мега-агент.
2) Хватает ли у вас ресурсов контролировать этот риск? Оценивать качество, дебажить сбои, безопасно поддерживать продукт в работе. У разных компаний разная терпимость к риску. Если вы дикий стартап, у которого завтра кончатся деньги, вы более толерантны к риску. Тогда вам нужно меньше инфры для контроля.
Я легко могу собрать демку агента с полным доступом к компьютеру, чтобы он мне создавал регулярные напоминалки полить цветы. Но я потом буду плохо спать по ночам.
И тут возникает логичный вопрос: а оно того стоило?
В разработке агентов, как и в инвестициях, есть связка риск/профит. За потенциальную выгоду мы платим риском, который берем на себя.
У AI-агентов обе величины сильно зависят от автономности. Система, где LLM в один промпт суммаризует диалог с клиентом — низкая автономность. Это и не очень рискованно, но профит ограничен. Автономный агент с доступом к CRM и возможностью отправить клиентам email — это уже совсем другая история. Потенциальный эффект выше, но и риск резко возрастает. Это удобно визуализировать на графике риск/профит (см. картинку).
Разберем, как разные архитектуры агентов ложатся в эту кривую — и как по этому графику выбрать архитектуру под вашу задачу. Начнем с архитектур.
Контролируемый рост риска (LLM-workflow)
Самый предсказуемый вариант — фиксированная цепочка промптов, то есть оркестрация LLM-workflow (см. пост про орестрации).
Все шаги прописаны заранее, у системы почти нет свободы “уйти не туда”. Каждую ветку можно отдельно отладить и измерить. Такая система прозрачна и контролируема. На этом участке кривой можно довольно предсказуемо наращивать ценность: добавлять новые узлы в граф, расширять логику, улучшать покрытие кейсов. Риск тоже растет, но управляемо.
Взрыв риска (автономный агент)
Но бесконечно растить workflow не получится: в какой-то момент сложность начинает съедать команду разработки. Тогда возникает соблазн перейти к автономному агенту (например, ReAct или Plan-and-Execute) — и дать ему набор ограниченных инструментов.
В этот момент потенциальная ценность и риск одновременно подскакивают.И вместе с этим подскакивает нагрузка на команду, потому что теперь нужно управлять новым классом рисков: контроль доступов к тулам, защита от prompt injection, observability и тд). Иначе разработка быстро превращается в гадание на таро (долбанет, или пронесет?).
Граница текущей технологии (переизбыток тулов)
Дальше наступает момент, когда дополнительная автономность перестает окупаться. Инструментов становится все больше, они сложнее, контекст длиннее, а модель начинает чаще тупить и галлюцинировать. Вы подходите к границе, которую текущие LLM еще могут выдержать. Вселенная как будто говорит: “Остановись”.
Автономность вредит (агент из телеграм-каналов)
Модель настолько тупит, что с ростом автнономности качество уже деградирует. Надо было послушать вселенную в прошлом пункте.
Концепция интересная, делать то что?
Самое важное: архитектуру AI-системы нужно подбирать под риск, который вы способны контролировать, а не под максимальный профит, который она теоретически может дать. Второе: каждая новая капля автономности требует дополнительных усилий на контроль риска.
Отсюда универсальное правило: начинайте с минимальной автономности, которая может решить задачу. Например: один вызов к LLM → затем цепочка промптов → затем агент → затем новые инструменты.
И на каждом шаге задавайте два вопроса:
1) Сильно ли растет качество?
Если нет — значит, вы уже уперлись в предел, и дальше усложнять систему нет смыла. Хорошая новость, что во многих задачах низкорисковой архитектуры вполне достаточно. Не везде нужен мега-агент.
2) Хватает ли у вас ресурсов контролировать этот риск? Оценивать качество, дебажить сбои, безопасно поддерживать продукт в работе. У разных компаний разная терпимость к риску. Если вы дикий стартап, у которого завтра кончатся деньги, вы более толерантны к риску. Тогда вам нужно меньше инфры для контроля.
Я легко могу собрать демку агента с полным доступом к компьютеру, чтобы он мне создавал регулярные напоминалки полить цветы. Но я потом буду плохо спать по ночам.
И тут возникает логичный вопрос: а оно того стоило?
❤20🔥16👍10❤🔥3🙏2👏1🤩1🐳1
Когда молчание агента — золото. Кейс компании DoorDash.
DoorDash — крупнейшая компания по доставке еды в США, где с заказами часто что-то идет не так: ресторан не выдает еду, суп пролился по дороге, клиент не отвечает. Все эти кейсы летят в поддержку, и отвечать на них нужно быстро. Для этого в DoorDash построили агентскую систему, которая сама отвечает на вопросы курьеров.
И здесь ошибка агента — это уже не ха-ха, смешная галлюцинация. Это реальные операционные и финансовые потери от неправильного действия курьера.
В таких системах важно не только качество ответа, но и умение агента вовремя заткнуться, чтобы не наговорить того, в чем не разбирается. Как развить у агентов такие навыки осознанности, поговорим в этом посте.
Архитектура системы
Архитектура строится на базе LLM-workflow:
1. LLM суммаризирует кейс.
Она берет обращение курьера, метаданные заказа и историю диалога, выделяет суть проблемы и готовит компактное представление кейса.
2. Ищем релевантные инструкции.
Поиск идет по базе прошлых обращений и связанных с ними верифицированных статей. Сами прошлые ответы не являются источником истины — они нужны только для поиска. Ответ строится на основе проверенных инструкций.
3. Проверяем качества поиска.
Новый LLM-вызов оценивает, действительно ли найденные документы подходят под запрос. Если нет — кейс сразу уходит человеку, а затем эксперты дополняют базу новой информацией. Этот LLM-вызов обычно называется LLM-guardrail. Далее мы подробнее это разберем.
4. Только теперь LLM генерирует ответ.
LLM получает найденные инструкции в контекст и формирует ответ на их основе (вот теперь мы уже можем находить галлюцинации).
5. Проверяем сам ответ.
Вторая LLM-guardrail оценивает:
- нет ли галлюцинаций;
- действительно ли он отвечает на вопрос;
- корректен ли язык.
6. Решаем, отвечаем или нет.
Если все ок, ответ уходит курьеру. Дальше уже поверх этого считаются метрики качества через LLM-as-a-judge. Если что-то guardrail не понравилось — отправляем на человека. Не рискуем.
Почему это хорошая архитектура
Во многих бизнес-задачах не нужно автоматизировать 100% обращений. Нужно надежно автоматизировать самые частые и понятные кейсы — и уже этого достаточно, чтобы получить заметный эффект. Закон Парето: 80/20.
Самые частые 80% кейсов хорошо документированы, а вот оставшиеся 20% редкие, плохо формализованные. Именно на этих 20% попытка додавить становится очень дорогой и опасной.
Поэтому зрелая система не героически отвечает в любой ситуации, а умеет вовремя отказаться. Нужно не всегда действовать, а понимать границы, где действие уже перестает быть адекватным по соотношению риск/профит. Себе тоже возьму на заметочку.
Подробнее про guardrails
Guardrail — это как раз механизм, который помогает разделить эти 80% и 20%. Эта LLM по ответу пытается предсказать, все ли хорошо в ответе с качеством. Если есть намек, что качество плохое, — сразу на человека.
Это может быть ровно та же LLM-as-a-judge, которую мы используем для метрик качества. Только считаем мы ее в рантайме, а не постфактум для observability.
Да, тогда теряется возможность стримить ответ сразу: сначала нужно дождаться всех проверок. Но действительно хорошие вещи стоит и подождать.
Резюме
На своих занятиях по внедрению AI я часто сравниваю два мира.
В B2C все любят показывать “вау-агентов”: модные мультиагентные системы (см пост про DeepResearh), которые соревнуются друг с другом по объему сжирания токенов.
В B2B агентские системы часто выглядят гораздо менее эффектно: сделай это, проверь поиск, проверь ответ, если есть сомнение — сразу на человека.
Но это не потому, что B2B отстает. Просто риск ошибки несет уже не пользователь, а компания. Если в B2C AI обманул, ответственность на пользователе: надо было проверить. Если в B2B агент наврал при общении с клиентом, последствия — уже деньги компании и клиентский опыт. Поэтому ценится не максимальная автономия, а контролируемая автономия.
И очень часто тут самый ценный навык агента — не сказать что-то умное, а вовремя заткнуться.
DoorDash — крупнейшая компания по доставке еды в США, где с заказами часто что-то идет не так: ресторан не выдает еду, суп пролился по дороге, клиент не отвечает. Все эти кейсы летят в поддержку, и отвечать на них нужно быстро. Для этого в DoorDash построили агентскую систему, которая сама отвечает на вопросы курьеров.
И здесь ошибка агента — это уже не ха-ха, смешная галлюцинация. Это реальные операционные и финансовые потери от неправильного действия курьера.
В таких системах важно не только качество ответа, но и умение агента вовремя заткнуться, чтобы не наговорить того, в чем не разбирается. Как развить у агентов такие навыки осознанности, поговорим в этом посте.
Архитектура системы
Архитектура строится на базе LLM-workflow:
1. LLM суммаризирует кейс.
Она берет обращение курьера, метаданные заказа и историю диалога, выделяет суть проблемы и готовит компактное представление кейса.
2. Ищем релевантные инструкции.
Поиск идет по базе прошлых обращений и связанных с ними верифицированных статей. Сами прошлые ответы не являются источником истины — они нужны только для поиска. Ответ строится на основе проверенных инструкций.
3. Проверяем качества поиска.
Новый LLM-вызов оценивает, действительно ли найденные документы подходят под запрос. Если нет — кейс сразу уходит человеку, а затем эксперты дополняют базу новой информацией. Этот LLM-вызов обычно называется LLM-guardrail. Далее мы подробнее это разберем.
4. Только теперь LLM генерирует ответ.
LLM получает найденные инструкции в контекст и формирует ответ на их основе (вот теперь мы уже можем находить галлюцинации).
5. Проверяем сам ответ.
Вторая LLM-guardrail оценивает:
- нет ли галлюцинаций;
- действительно ли он отвечает на вопрос;
- корректен ли язык.
6. Решаем, отвечаем или нет.
Если все ок, ответ уходит курьеру. Дальше уже поверх этого считаются метрики качества через LLM-as-a-judge. Если что-то guardrail не понравилось — отправляем на человека. Не рискуем.
Почему это хорошая архитектура
Во многих бизнес-задачах не нужно автоматизировать 100% обращений. Нужно надежно автоматизировать самые частые и понятные кейсы — и уже этого достаточно, чтобы получить заметный эффект. Закон Парето: 80/20.
Самые частые 80% кейсов хорошо документированы, а вот оставшиеся 20% редкие, плохо формализованные. Именно на этих 20% попытка додавить становится очень дорогой и опасной.
Поэтому зрелая система не героически отвечает в любой ситуации, а умеет вовремя отказаться. Нужно не всегда действовать, а понимать границы, где действие уже перестает быть адекватным по соотношению риск/профит. Себе тоже возьму на заметочку.
Подробнее про guardrails
Guardrail — это как раз механизм, который помогает разделить эти 80% и 20%. Эта LLM по ответу пытается предсказать, все ли хорошо в ответе с качеством. Если есть намек, что качество плохое, — сразу на человека.
Это может быть ровно та же LLM-as-a-judge, которую мы используем для метрик качества. Только считаем мы ее в рантайме, а не постфактум для observability.
Да, тогда теряется возможность стримить ответ сразу: сначала нужно дождаться всех проверок. Но действительно хорошие вещи стоит и подождать.
Резюме
На своих занятиях по внедрению AI я часто сравниваю два мира.
В B2C все любят показывать “вау-агентов”: модные мультиагентные системы (см пост про DeepResearh), которые соревнуются друг с другом по объему сжирания токенов.
В B2B агентские системы часто выглядят гораздо менее эффектно: сделай это, проверь поиск, проверь ответ, если есть сомнение — сразу на человека.
Но это не потому, что B2B отстает. Просто риск ошибки несет уже не пользователь, а компания. Если в B2C AI обманул, ответственность на пользователе: надо было проверить. Если в B2B агент наврал при общении с клиентом, последствия — уже деньги компании и клиентский опыт. Поэтому ценится не максимальная автономия, а контролируемая автономия.
И очень часто тут самый ценный навык агента — не сказать что-то умное, а вовремя заткнуться.
❤34🔥17👍11🐳2❤🔥1🤩1🙏1
Друзья, опубликовал подробный гайд по архитектуре AI-агентов. В нем собрал:
- из каких компонентов состоит агент и как они друг с другом взаимодействуют
- какие бывают типы оркестрации у агентов
- как правильно собирать контекстное окно
- какие есть угрозы безопасности и как с ними бороться
- и много чего еще другого
Если останутся вопросы, как вам собирать надежных AI-агентов, напишите в комментариях или в личных сообщениях @seva_batareika
- из каких компонентов состоит агент и как они друг с другом взаимодействуют
- какие бывают типы оркестрации у агентов
- как правильно собирать контекстное окно
- какие есть угрозы безопасности и как с ними бороться
- и много чего еще другого
Если останутся вопросы, как вам собирать надежных AI-агентов, напишите в комментариях или в личных сообщениях @seva_batareika
vikulin.ai
Архитектура надёжных AI-агентов
Из каких блоков состоит надёжный AI-агент: оркестратор, LLM, контекстное окно, безопасность, observability — и как их правильно комбинировать.
13🔥60❤21👍17❤🔥3🤝3🎉1🤩1🐳1