Как общаются агенты и что такое MCP

Microsoft на своем мероприятии объявила, что они уже видят "open agentic web". Идея не нова — агенты общаются друг с другом, решают задачки, люди отдыхают, о дивный новый мир.

Чтобы этот дивный мир состоялся, нужна фундаментальная вещь —протокол. Давайте вместе разберёмся, что это.
И не забудьте, что в конце, как обычно, список обязательной литературы.

Издалека, зато по порядку

Интернет стал интернетом, потому что компьютеры научились разговаривать друг с другом. Правила этого общения называются протоколами, например, HTTP (для сетевого общения, кстати, нужно много протоколов). Благодаря протоколам есть все, что мы с вами так любим. В конце концов, этот телеграм канал.

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

Есть MCP от Anthropic, A2A от Google и, наверное, куча еще других. Дальше поговорим про MCP, потому что я другого не знаю он самый популярный.

MCP

Сделано в Anthropic.
15 к звездочек на Гитхабе, его уже приняла во все свои продукты Microsoft, и даже окнул Сэм из OpenAI, что как бы намекает на его лидерство.

Основан на клиент-серверной архитектуре. Сервер предоставляет клиенту набор различных tools (базы данных, методы или других агентов, неважно), клиент их с умом использует. Конкретнее:

1) Вы запускаете клиент MCP, отправляете запрос нужному вам MCP-серверу (по HTTP) — "друг, дай список своих tools"

2) Сервер отвечает: «умею вот такое, вызывай их так»

3) LLM на клиенте читает про инструменты, понимает, что вызывать и с какими аргументами. Отправляет свой запрос на сервер.

4) Сервер выполняет, отправляет результат клиенту. Клиент уже делает, что хочет с результатом.

Очень понятный-свободный протокол, примерно так все всегда и делали LLM-приложения. Поэтому он такой популярный. Уже есть 4700 MCP серверов (список).

Более известные люди ругаются на MCP за его простоту, но я до конца претензию не осознал. Если поняли — дайте знать в комментариях.

Смерть SAAS

Агенты с протоколами реальная угрозу классическому Software as a service. Гендиректор Microsoft тоже любит так говорить.

Зачем платить за подписку на простой soft, когда хочется платить за результат? Хочется не просто иметь CRM в облаке, а чтобы CRM-агент, к которому ты подключаешься, сразу нашел тебе перспективных клиентов. MCP значительно ускорит этот переход.

Я не настоящий стартапер, но посмотрите мнение ребят из YC и почитайте мнение ребят из Andreessen Horowitz. Outcome-based pricing мне видится реальной перспективой.

Что обязательно читать

- Почему MCP победил

- Оригинальный пост Anthropic про MCP

- MCP против API В чем разница проектирования

- Пример создания MCP приложения

И еще обязательно задавать вопросы в комментариях.

Если нужна консультация под ваш вопрос — пишите уже в личные сообщения.

Продолжаем серию публикаций по LLM System Design. Сегодня говорим про важность внешних инструментов.

Паттерн 3. Дайте LLM правильные инструменты

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

Очень важно: любую детермированную логику выполнять кодом, а не LLM. Если нужно понять, можно ли дать этому клиенту скидку, пускай это решит детерминированный алгоритм, а LLM его правильно вызовет. Если нужно отсортировать документы по релевантности, пускай LLM выдаст релевантность, а отсортируете вы результат кодом. Более подробно про это читайте тут.

В дизайне системы очень удобно считать tool-ом любой другой элемент: внешний код, база данных (RAG), другие LLM и т.д. Вызов инструментов требует правильного заполнения всех аргументов, поэтому крайне удачно, что мы прошли Structured Output в Втором паттерне. Не забывайте его использовать.

Код — ваш лучший инструмент

Код это самый мощный tool, который вы только можете дать LLM (но риски кратно возрастают). LLM может персонально под задачу генерировать программу.

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

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

На этой идеи построена библиотека smalagents от HuggingFace. Технические подробности в статье CodeAct.

Как научить LLM использовать инструменты

От самого простого к самому сложному:

1) Подключиться к MCP-серверу, если такой есть, и взять оттуда этот tool.

2) Самим сделать tool на базе каких-то API (не забываем про разницу MCP и API), напихать все в промпт

3) Самим сделать tool, зафайнтюнить LLM правильно этот tool использовать. Про это есть классическая статья.


Обязательная литература

- Объяснение, почему важно разделять LLM и tools

- Аналогичное правило, но для ИИ агентов

- Пост, чем дизайн tool для LLM отличается от просто API

- Статья, как важно Structured Output для tools

Любые вопросы обязательно пишите в комментарии.

Если нужно обсудить конкретно ваш случай - пишите вопрос в личные сообщения.

#llm_system_design

Блин, когда начинал эту серию, думал, что паттернов будет 10.

За месяц захотелось добавить еще 2 паттерна, теперь у меня их 12.

Интересно, допишу ли я когда-нибудь их все…

Нашел потрясный курс по RAG.

Здесь 22 урока по имплементации различных RAG-техник: от самого базового на эмбеддингах, до RAG-а на графе и добучения с помощью Reinforcement Learning.

Что самое приятное: все пишется с нуля на Python.

Обычно все клепают RAG-и так: берем готовый фреймворк (LangChain и тд), смотрим туториал "how implement rag", берем готовые модули оттуда. Для быстрых прототипов это ок вариант, но так нормально не разобраться, как что работает.

Только разобравшись, как это все пишется с нуля, сможете потом делать надежные LLM-системы. И на любом фреймворке.

Вы как знаете, а я пошел повторять.

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

Паттерн 4. Зашивайте все ваши знания в промпт

Базовой LLM нужно много чего знать о вашей задаче, чтобы ее решить. Факты о вашем продукте, какие есть тулы, как зовут пользователя, с которым LLM говорит и тд и тп. Все это надо отправить в промпт. Часто его называют контекстное окно.

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

Несмотря на то, что модели умеют все лучше и лучше работать с длинными последовательностями, вам нужно думать о размере контекстного окна. Чем длиннее окно, тем сложнее модели понять, что происходит, поэтому важно контекст эффективно записывать. Даже Google с своим Gemini вынужден делать хаки с контекстом, чтобы их агент смог играть в Покемон-Го. Подробнее про эти хаки читайте тут и берите на вооружение.

Часто мы даже точно не знаем, какую именно информацию нужно засунуть в окно, чтобы задача решилась. Тогда возникает архитектура RAG.

RAG

Название пришло из статьи 2020 года, в которой авторы присоединили retrieval систему к seq2seq-генератору. Дада, я использую слова из 2020 года, без всяких LLM. Фишка статьи, что они обучали обе эти модели вместе. Сейчас под RAG-ом подразумевают все, когда к LLM присобачивают какой-то поиск.

А присобачивать поиск оказалось довольно удобно. Человечество до эры LLM много лет занималось поиском. Вдруг оказалось, что поверх всех этих знаний можно вставить LLM, и оно просто заработает.

Fine-tuning

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

1) Вы скорее всего сломаете базовый алайнмент модели. Это как вскрыть айфон — гарантия производителя перестает действовать. Веса модели меняются, уже никто не гарантирует, что модель не сломается на каком-то out of domain запросе. Такое же мнение написано тут.

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

3) Не факт, что побьете RAG по качеству на вашем тесте. Почитайте просто форум. Посмотрите статью, где бенчили RAG против дообучения. Хорошо дообучать это сложно.

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

Я вам строго рекомендую RAG, чтобы дать LLM внешнюю инфу, а файнтюнинг оставить для другого. Об этом, кстати, говорят и OpenAI в своем курсе (ссылка ниже).


Литература для обязательного изучения

- Статья, как важно контролировать контекстное окно

- Доходчиво, почему fine-tuning для внедрения информации, это трата времени

- Видос про это же

- Часовой урок по fine-tuning от OpenAI (очень наглядно, когда надо дообучать)

- Объяснение, почему все состояние надо записывать в контекст

Как всегда, все вопросы пишите в комментарии или в личные сообщения.

#llm_system_design

Почему в AI много демок и мало внедрений

Существует целый класс задач, в которых очень просто сделать демо, но невероятно сложно сделать настоящий продукт. (Андрей Карпатый)

Я думаю, весь AI это ровно про это.

Как вы думаете, когда начали ездить первые self driving cars? В 90-х годах двадцатого века. Они ездили по настоящей дороге, могли поворачивать. Бибикали. Иногда даже успешно.
Можете посмотреть на список прогнозов Илона Маска, когда уже появится автономный транспорт. Пока мы ждем.

Почему так

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

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

Как демку превратить в продукт

Серия шагов:

1) Научиться замерять качество.

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

2) Оценить риски.

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

3) Если не принял риск - подключай человека.

В автономном транспорте есть 6 уровней автоматизации. При чем реально автономны только последние 2 уровня.

Для AI-приложений можно делать также. Отлично работает паттерн “human in the loop”, о котором мы говорим в постах по LLM System Design.

Обязательная литература

- Обзорная статья, как бороться с ненадежностью LLM

- Пост про правильный UI для повышения надежности агентов

Любые вопросы обязательно пишите в комментарии.

Если нужно обсудить конкретно ваш случай - пишите вопрос в личные сообщения.

10 рабочих ИИ решений за июнь 2025

Меня жутко бесят все AI-каналы, где собирают самые бесполезные в мире новости. Как у Сэма Альтмана перекупают разработчиков, когда британские ученые предсказывают AGI и тд. Хочу собрать реально полезный ИИ-дайджест.

И собрал. Дайджест из 10 рабочих решений, которые вышли/прославились в июне 2025.

Здесь опенсорс библиотеки, модели, гайды, прикладные статьи. Например:
- релизы опенсорс моделей Gemma и Qwen

- обзор архитектур защиты от промпт инъекций

- библиотека для RAG на графе знаний

- насколько успешны vLLM в классическом CV

и куча еще всего.

Делитесь, комментируйте. Если зайдет — сделаю регулярным

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

Раньше я не понимал, что делать, когда «оно такое медленное». Сейчас понимаю, куда копать. Больше всего мне помогла статья, очень ее рекомендую.

Почему про это надо думать?

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

Это создает кучу проблем.
Из-за этого вам приходится постоянно в GPU гонять информацию (слои/активации и тд) туда сюда для каждого токена по очереди. Это значит, что чаще всего ваши вычисления ограничены скоростью передачи данных, а не вычислительной мощностью. Вы не используете GPU на полную катушку.

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

Читайте статью, задавайте вопросы в комментарии или в личку.
Буду выкладывать больше материалов по локальной работе с LLM.

4 методики работы с контекстом LLM

В Паттерне 4 мы поняли, насколько важно использовать контекст в LLM-системе.
Сейчас давайте разберемся, как это можно делать. Все эти правила прекрасно изложены в статье.

1) Запись во внешнюю память

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

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

2) Выбор нужного из внешней памяти

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

- Если память маленькая, можно прочитать ее всю

- Можно размечать тегами разные участки памяти, например "error" для ошибок, и дальше искать по тегам

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

3) Суммаризация

Часто информации настолько много, что ее проще хранить/использовать в сжатом виде. Обычно делают так: если токенов > X, тогда отдельный LLM-call суммаризует последнюю историю. Это позволяет свежую информацию хранить полностью, а старую уже менее детально.

Так делает Google со своим Gemini, когда агент играет в Покемонов (я кстати в жизни ни разу не играл, расскажите, как оно?).

4) Разделение контекста

В мультиагентских системах разумно иметь изолированные контексты разных LLM. У них могут быть свои задачи/тулы/история.

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

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

Нудное послесловие

Разработка крутых LLM-систем это всегда про эксперименты и креатив. Я запрещаю зацикливаться на простых решениях, типа, пихаем в контекст все. Или фиганем эмбеддинги, FAISS потом разберется. Позаботьтесь о себе и о вашей LLM.

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

Оказывается, я случайно попал в тренд июля 2025! Промпт-инженеры уже не круто. Им на смену пришли контекст-инженеры.

Вот даже сам Карпатый про это написал.

Ниша пока пустая, может пора нам делать курсы «как стать контекст инженером»?))

Кажется, материал будет даже более осмысленный…

В опенсорс вышла T5 Gemma

Ну вышла и вышла, что бухтеть то?

Самое интересное - Gemma T5 это не decoder model, как GPT, R1 и прочие. Это EncoderDecoder модель.
Сначала весь входной текст пропускается через encoder, затем поверх этого представления запускается авторегрессия на декодере. В энкодере стоит двусторонний аттеншион, как в обычном Берте.

Почему это важно?

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

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

Выложили сразу несколько моделей с разной размерностью Encoder и Decoder. Можно использовать нужный размер под вашу задачу.

Так что по метрикам?

На MMLU работает не хуже. На бенчах с сложным входом работает даже чуть лучше, например, на математике типа GSM8K.
Что еще важно: модель очень хорошо файнтюнится. При одинаковых размерах с DecoderOnly качество файнтюна значимо выше.

Что мы имеем в итоге

Более гибкая архитектура. На отдельном классе задач работает лучше и быстрее. Файнтюнится проще.
Очень рекомендую попробовать.

Блогпост
Модели на HF

Мы тут иногда архитектуру LLM-систем изучаем. Продолжаем этот опус.

Паттерн 5. Архитектура надежных RAG-систем

В Паттерне 4 мы поняли, как удобно, когда вся информация, нужная для ответа, находится у LLM в контексте.
Часто эта информация зависит от текущего состояния системы. Тогда возникает RAG.

RAG это синтез двух очень больших и очень разных миров: Поиска и Генерации. Разберем каждый.

Поиск

Основная сложность в Поиске — огромное число кандидатов, с которых можно написать ответ.

Если у вас их десятки, сотни тысяч документов, то уже проблема. Нужно придумывать инженерные трюки, которые позволят быстро находить перспективных кандидатов. Благо за десятки лет их придумали много штук. Перечислим некоторые:

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

- Текстовый матчинг. Точное совпадение кусков текста. Можно считать по буквам, словам, n-граммам. Работают формулы TF-IDF, BM25 и тд. Не способны ловить семантику

- Графы знаний. Задают структуру ваших данных. Например, что эти документы из одной категории. Или, что тот документ идет после вот этого. Можно делать с помощью LLM, рассказывал про cocoindex в дайджесте.

Можно и нужно генерировать кандидатов разными методами, а затем их ранжировать более тяжелыми формулами. Бертами, LLM или даже ансамблем деревьев решений. Про выбор модели читайте тут.

Генерация

Основная сложность в Генерации - опираться только на найденные Поиском документы. Ничего не выдумывать, не галлюцинировать.

Для решения есть такие опции, от простого к сложному:

- Промптинг.
Попросить, дорогой генератор, ответь только по тому, что у тебя в контексте. Не выдумывать. Для простого RAG, где небольшой контекст и простые вопросы — метод рабочий, можно использовать.

- SFT-дообучение.
Когда промптинга мало, модель все равно галлюцинирует. Собираем датасет троек (запрос, контекст, правильный ответ). Учим на этом генератор. Не забывайте в "правильный ответ" записать "Не могу ответить, ничего не нашла", когда по контексту невозможно ответить. Работает для средней сложности задач.

- RLHF.
Когда даже SFT не справляется. Делаем reward модель, которая оценивает качества ответа. Дальше делаем итерацию PPO/DPO/GRPO, обновляем reward, делаем новую итерацию, потворять до готовности.

Агентность в RAG

В RAG идеально вписываются элементы архитектуры агентов. От простого к сложному:

1) Отдельная модель, которая генерирует удобные запросы.
Позволяет формулировать правильные запросы, снимать омонимию.

2) Итеративные походы в Поиск.
Если в первый раз не нашли, давайте сходим снова. Понять, что не нашли, можно эвристиками или рассуждениями.

3) Настоящий DeepResearch.
Объединение первых двух. Агент рассуждает, ходит итеративно в Поиск с правильными запросами.

Это все можно промтировать, SFT-шить, или через RL. Последнее можно глянуть в статье.


Литература для обязательного изучения

- Глава 1 отсюда. Понятно про архитектуру RAG.

- Видос по основам RAG. Во многом дублируется с постом

- Туториал по оценку RAG-а через LLM-as-a-judge (важная тема, не влезла в пост)

- Статья большой обзор кучи подходов к RAG. Все читать не обязательно, просто посмотрите, что вообще есть



Как всегда, все вопросы пишите в комментарии или в личные сообщения.

#llm_system_design

Кстати, 19 июля расскажу про архитектуру RAG на Turbo ML Conf в секции NLP.

Раскрою вот этот пост и чуть подробнее расскажу, как готовить RLHF для RAG.

Приходите слушать, нетворкаться и дружиться.

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

Что там есть

- Как работает инференс LLM (Prefill стадия, декодинг стадия)

- Как посчитать, сколько нужно VRAM у GPU

- Какие есть надежные фреймворки

- Метрики для инференса

- Методы ускорения LLM

и много всего еще

Чего там нет

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

Тогда вам поможет зубодробительная статья тут и немного менее тут.


Теперь вы знаете, что делать вечером в воскресенье, не благодарите :)

Обсуждать абстрактно "как правильно делать LLM" очень тупо. Поэтому мы будем разбирать архитектуру на реальных примерах.

Раз мы недавно обсуждали RAG, начнем с примера поисковой архитектуры.

Архитектура Поиска по контенту LinkedIn

В соцсети много контента, надо по нему искать. Для RAGа, да и просто для души.

Метрики

Time Spent просмотра постов
Если пользователь листает выдачу поиска и ничего не читает, то скорее всего мы нашли фигню.

Релевантность
Часто просто крутить Time Spent плохая идея, сигнал шумный. Хорошая идея мешать его с чем-то более легко измеримым, например, релевантностью поста. Мерят с помощью GPT.

Архитектура

Индекс из миллиардов постов. Два метода генерации кандидатов:

1) Текстовое совпадение по словам
Вечная классика — обратный индекс, нашли посты со словами из запроса, никакой семантики.

2) Эмбеддинги и быстрый поиск ближайших соседей
Для эмбеддеров используется хорошая мультиязычная моделька.

Дальше тысячи кандидатов отправляются в ранкер.

Ранкер из 2-х этапов. Сначала тысячи ранжируются одной моделькой. Дальше сотни ранжируются моделькой побольше. Архитектура моделей одинаковая.

Модель ранкера это две FC сети. Первая предсказывает релевантность. У нее есть только эмбеддинги запроса и документа. Вторая предсказывает Time Spent. Туда помимо эмбеддингов подаются и обычные фичи (популярность поста, дружит ли пользователь с автором и тд).

Учатся модели на взвешенную сумму Time Spent + Релевантность.

Учатся на кучи исторических сессиях поиска.

Что тут важно почерпнуть

- Несколько таргетов. Часто хорошая идея. Особенно связка онлайн + оффлайн

- Классическая архитектура поиска. Несколько генераций кандидатов + несколько ранкеров.

- Разметка с помощью GPT. Если не очень сложная задача, работает быстро и хорошо

Что я бы поменял

Очень странный выбор ранкера. Две FC-сети, при чем с готовыми эмбеддингами на входе и еще в лаваше с обычными фичами. Такое делать можно, ну только если у вас совсем нет железа.
Мне нравится что-то из:

1) Трансформеры-кроссэнкодеры на текстах, которые вы файнтюните

2) Бустинг над деревьями с обычными фичами

А лучше когда выход 1) пихаете в 2)

Если исторических данных много, то можно учить очень крутые и сложные ранкеры.

Итог

Базовая статья, как обычно делают поиск, но со странным выбором моделей. Можете на нее опираться, когда у вас в базе RAG что-то больше, чем 1000 документов.

Что думаете по этой архитектуре поиска? Слабовато или наоборот перекрутили?

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

#llm_cases

Нам точно нужны эти большие-больше LLM, когда мы делаем продукт? Может стоит брать компактные модели, обученные под одну задачу, а дальше объединять их как мультиагентную систему?

Так думают авторы статьи Small Language Models are the Future of Agentic AI. Давайте разбираться

В чем преимущества

1) Маленькое дешевле. Их можно запускать на сильно более простых видеокартах.

2) Маленькое проще менять. Относительно легко/дешево дообучить под новую задачу.

Сейчас идет большой бум RL для обучения агентов. И наших маленьких агентиков мы тоже можем так дообучать. Вот 100 строчек кода, которые через RL 1b модельку учат математику решать. И реально работает, качество растет.

3) Маленькое можно использовать локально. Чтобы хостить современные модели масштаба R1, вам даже одной GPUшки не хватит, вам нужно кластер арендовать (много ест по памяти в GPU, как считать читайте тут)

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

Вроде все логично, но...

Есть один нюанс

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

Очень дорого и долго делать кастомные модели под каждую фичу. Нужна отдельная команда, которая умеет обучать модели, высокие требования по данным. В итоге пока фича делается, уже может технология 2 раза поменяться.

Мощь больших моделей, что вы ее один раз захостили, а дальше куча разных команд поверх нее строят новый продуктовый слой: системы контроля качества, RAG-платформы и тд. А потом поверх этого еще крутецкие продукты. А модель при этом переучивать не надо. Она стоит одна и ей хорошо.

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

ИИ-агенты рецепт от всех проблем?

Часто слышу: "Раньше у нас было легаси, LLM там всякий, а вот сейчас бахнем ИИ-агентов и заживем!"
Не заживете.

Примерно тоже самое я прочитал вчера в отчете McKinsey. Ну от кого от кого, а от них не ожидал...
Давайте сначала кратко разберем отчет.

The gen AI paradox

Сначала все адекватно. Рассказывается парадокс, что все компании говорят, что у них давно все на ИИ. Прям как в анекдоте: "ну так и вы говорите..."

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

Потом предлагается решение — ИИ-агенты. Мол раньше мы делали беспонтовые раги и чатботы, а теперь мы умеем делать агентов (давать моделям API-шки), и вот сейчас агенты перевернут весь бизнес. Все автоматизируем. Ну и дальше классическое "Перестраивайте скорее ваши бизнес процессы под агентов, звоните по номеру +7 ...".

Но есть один нюанс

Вообще, нюансов строго больше одного:

0) Основная проблема автоматизации не в том, что мы не догадывались раньше до агентов. Операционный процесс надо сначала оцифровать. McKinsey продают цифровизацию с тех пор, как появилось слово "цифра". Нужно работать дальше.

1) Агенты очень очень плохи в долгих многоэтапных задачах. У них копится вероятность ошибки. Посмотрите мой пост. И еще можно статью про качество ИИ-бухгалтера.
Обычный многоэтапный бизнес процесс агент под ключ пока не сделает.

2) Заводятся агенты пока только на больших моделях. Еще и с ризонингом. Это довольно дорого.

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

4) Чтобы агенты могли нормально интегрироваться в систему, нужно написать кучу кода. Обычного человеческого кода. Код всех апишех (тулов) ко всем вашим системам. Это не только код вызова ошибок, но и вывода ответов/ошибок этих апишек.

Что я рекомендую

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

1) Copilot-режим. Его также рекомендует Андрей Карпатый, а это чего-то стоит.
Под капотом Copilot могут быть агенты или просто LLM с ифаками. Ключевое: пользователь остается в привычном интерфейса, но получает мощнейшего партнера для ускорения.

2) Режим автоматизации, но частичной. Его также советует Andrew Ng.
Разбейте бизнес процесс на задачи. Найдите самые узкие места, которые понятно как сделать. Например, создание отчета о состоянии рынка. Или драфт коммерческого предложение. На сложных местах оставляйте человека.

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

Если нужно помочь с каким-то вариантом, пишите в личку @seva_batareika. Обсудим ваш проект.

Продолжаем грызть науку LLM-строения.
В прошлых 5 публикациях мы поняли, из каких кубиков состоит LLM-система. Сейчас пришло время из них что-то собирать.
А как собирать?

Тема 6. Этапы LLM-проекта

Я делю разработку на 4 этапа:

1) Бизнес постановка

2) Создание прототипа

3) Упрощение протототипа

4) Деплой системы и мониторинг качества

Бизнес постановка

Нам нужны частотные и дорогие задачи. Важно, чтобы была толерантность к ошибкам — близкое к 100% качество у LLM бывает разве что в простой классификации. Классические примеры:

- Бот поддержки клиентов — большой объем, средняя толерантность, средняя стоимость операции

- Copilot для разработчика — средний объем, высокая толерантность (copilot же), высокая стоимость операции

- Автоматизация документооборота— средний объем, средняя толерантность, средняя стоимость операции

Создание прототипа

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

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

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

Упрощение протототипа

Здесь сильные технические люди крутят-вертят LLM. Чтобы прототип не стоил, как запуск ракеты Илона Маска.
Большое разнообразие различных вариантов:

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

2) Дообучение. Можно не дистиллировать, а просто взять модель поменьше. Но тогда придется их покрутить, так как они справляться будут хуже. Здесь приходит на помощь дообучение (особенно Reinforcement Learning). Вот тут много примеров по дообучению разных LLM разными методами.

3) Работа с контекстом окном. Убирание лишнего из контекста, суммаризация (я пока не устал шутить про контекст-инженера)

4) Оптимизации. Тут отдельный мир: размер батча/квантизация/спекулятивный декодинг. Про это есть отдельная методичка в этом посте.

И еще куча-куча всего. Тут живет мощная LLM-инженерия.

Деплой и мониторинг качества

Здесь происходит классическая разработка. Пишется сервис, в котором работает наша эффективная система. Самое важное: нам нужно контролировать качество этого сервиса. При чем не разово, а постоянно. Зачем?

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

Литература для обязательного изучения

- Довольно понятная (мне) моя статья. Часть материала пересекается с постом.

- Гайд, как быстро улучшать AI-продукты

- Очень крутая статья про мониторинг и distribution shift


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

#llm_system_design

Как ИИ может снижать продуктивность разработчиков

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

Даже моделью, которая сдает ЕГЭ по математике на 100 балов без калькулятора, можно легко испортить ваш продукт. Как? Об этом расскажет статья, в которой изучали влияние ИИ инструментов на продуктивность опенсорс-разработчиков. И эта продуктивность упала. Давайте разбираться.

Суть исследования

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

В итоге, когда разработчику давали ИИ, он делал задачи на 19% дольше, чем без ИИ. Забавно, что даже после того, как они прошли испытание, они все равно верили, что ИИ их ускоряет на 20%. Вот что значит технооптимизм!

Почему так?

На самом деле, хрен поймешь. Надо проводить глубинные интервью с пользователями (помните, кто очень важен для ИИ-продукта). Давайте вместе набрасывать варианты:

- Тупой ИИ. Сэм Альтман не согласен, все бенчи на кодфорсесе говорят об обратном

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

- Разрабы крутые разрабы, но не умеют пользоваться ИИ

- Разрабы хотели показать ИИ, что он хуже них, и специально без него писали код быстрее.

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

и еще тонна вариантов, которые вы легко напишите сами в комментах.

Что я рекомендую делать

Не думайте в контексте "есть задача, ИИ решает 20% задачи, значит люди будут на 20% эффективнее". Не будут. Думайте про то, как люди интегрированы в процесс, который вы оптимизируете.

А в интеграции людей есть огромное число вопросов, помимо обычного качества:

1) Насколько люди доверяют решению? Может они будут больше времени тратить на перепроверку?

2) Будут ли люди саботировать ваше решение? Может они из вредности будут работать дольше?

3) Насколько удобно ваше решение? Не тратят ли люди кучу времени, чтобы разобраться в вашем интерфейсе, которое они раньше тратили на работу?

4) Насколько люди умеют пользоваться решением? Они точно понимают, как эффективно применять?

ИИ это не только про МЕГА-модели. Это всегда еще про доверие, удобство и обучение людей. Не забывайте про это.