Почему не стоит верить LLM Arena

Андрей Карпатый как-то сказал:

Я верю только в 2 способа измерения качества LLM: LLM Arena и посты на реддите.

Я бы на его месте верил только постам на реддите, сейчас объясню почему.

Что не так с LLM Arena?

Суть LLM Arena проста: отдаём пользователю на его запрос два ответа от двух разных моделей, он сравнивает, какой ответ ему больше нравится. Модель, которая нравится больше всех, становится первой в рейтинге. Что же может пойти не так? :)

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

В недавней статье авторы по полочкам разложили, что не так с LLM arena. Я примазался добавил немного от себя, вот мой итоговый список.

- Оценки людей очень смещены. Все это поняли после релиза LLAMA 4. Модель стала выдавать больше эмодзей - поднялась выше в арене. Мерит ли это как-то умность модели? Нет.

- Авторы LLM собирают данные с арены, а дальше файнтюнят на этом свои модели. Сева, в чем проблема, на этом же весь ML держится?
Проблема, что популярные модели чаще используются и у них тупо больше данных. Ну и оценки смещены, смотри пред. пункт.

- У LLM Arena есть приватное тестирование. Разработчики могут залить скрыто несколько версий моделей, чтобы люди их проверяли. В итоге выбирают ту модель, которая больше смещена нравится людям. Типичное переобучение.

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

Как тогда нам выбирать LLM?

Не доверяйте полностью никаким открытым рейтингам моделей. Они все так или иначе страдают от проблем, которые я написал выше.

Как я советую выбирать модель:

1) Делаем систему оценки качества. Про это есть раздел в огромной статье. Собираем правильные ответы, дальше сравниваем предсказанное. Если нужно - делаем LLM-as-a-judge.

2) Берем топ-N моделей с какого-то адекватного лидерборда. Можно с той же LLM Arena. Там, кстати, есть фильтр по русскому языку, если нужно. Прогоняем топ через нашу систему оценки, берем лучшую.

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

AI в 2026 году

У меня довольно не плохо с пониманием трендов. Давайте я спрогнозирую, куда придет индустрия через год.

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

1) Мультиагентные системы.

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

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

Про это читать туториал.

2) Reinforcement Learning поверх агентов

Невозможно сделать такую систему без проб и ошибок. Без Reinforcement Learning. Любая мощная агентная система будет настраиваться так.

Именно применение RL сделало возможным создавать первых реально полезных ИИ-агентов, таких как Deep Research.

С релизом DeepSeek-R1 индустрия активно побежала RL-ить свои модели. Смотреть видео. Изучать код RL-дообучения (на 180 строк, вы справитесь).

3) Коммуникация агент -> человек

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

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

Агенты будут писать вам в удобном месте - в телеге, слаке, почте, лишь бы получить от вас фидбек.
Это невозможно научить делать без Reinforcement Learning.

Внимательно читать статью.

Резюме

Настоящее применение технологии начинается спустя пару лет после хайпа про нее. Для построения надежных агентских систем нам осталось положить еще пару кирпичиков.

RL показал свою мощь для обучения рассуждающих моделей. Теперь он должен стать ключом к агентcким системам.

Ждем. По крайней мере я точно.

Сегодня счастлив был выступить на DataFest с докладом про LLM System Design.

Спасибо всем кто пришел и слушал.
Если интересно - выкладываю презентацию.

Архитектура LLM продуктов новая и сложная тема, давайте в ней вместе разбираться. На последнем слайде список полезных статей по LLM System Design - читайте, задавайте вопросы.

Увидимся на следующих конференциях!

10 паттернов разработки надежных LLM приложений.

Начинаю серию публикаций по LLM System Design.
Если осилите все 10 паттернов - сможете разрабатывать надежные LLM-приложения, которые не сломаются от наплыва счастливых пользователей.
Поехали.

Паттерн 1. LLM приложение это просто граф

Считайте, что вы разрабатываете обычный софт. Используете микросервисную архитектуру. Сервис 1 ждет ответа от Сервиса 2, если ответ = X, то идет в Сервис 3 и тд.

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

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

Перечислим часто используемые элементы в этом графе:

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

- Вызов LLM. Они могут соединяться различным образом: идти последовательно, параллельно, при выполнении условия и тд. Строго читать статью

- Внешние инструменты. Например, поисковый движок. Похоже на код, но инструменты не делают бизнес логики. Результат инструментов подается на вход в LLM. Разберем в "Паттерн 3. Все есть инструмент".

- Внешняя база знаний. Так делается RAG. Лучший способ заложить внешние знания в LLM. Подробнее обсудим в "Паттерн 4. Всегда используйте in context learning" и "Паттерн 5. Не переусложняйте RAG".

- Не-LLM модели. Обычно это берты/сверточные сети или бустинги над деревьями. Очень быстры и дешевы. Как правило, обучаются дистилляцией. Поговорим про это в "Паттерн 10. Дистилируйте."

- Guardrails. Модели, которая оценивает качество ответа. Если качество плохое, лучше такое никому не показывать. Обсудим в "Паттерн 8. Human-in-the-loop"

- Человек. У него нужно уточнить, когда непонятно, что делать дальше. У него нужно спросить, когда хотим сделать рискованное действие. Подробнее в "Паттерн 8. Human-in-the-loop"

- Автономные агенты. Редкий зверь, но будет чаще встречаться. Почему редкий. Обсудим в "Паттерн 9. Когда нужны автономные агенты."


Литература для изучения

- Строго mustread пост от Anthropic
- Подробная схема LLM-приложений от Chip Huyen
- Пост, почему надо разделять LLM и бизнес логику
- 500 реальных кейсов LLM-приложений
- Подробный гайд с большим числом деталей
- Принципы проектирования агентов (многое можно почерпнуть и для неагентов)


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

#llm_system_design

Надеюсь, я не отбил у вас желание разбираться с LLM System Design. Если нет, то продолжаем.

Второй паттерн. Structured output

Вы выдаете желаемую JSON-схему ответа, LLM не может ее нарушить. Работает благодаря 2-м вещам:

1) Ваш формат конвертируется в грамматику. Генерация каждого следующего токена жестко ограничена этой грамматикой. Считайте, что работает регулярка на выходе модели.

2) Базовая модель дообучалась, чтобы понимать по схеме, что вообще от нее хотят.

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

from pydantic import BaseModel

class ResearchPaperExtraction(BaseModel):
    noscript: str
    authors: list[str]
    keywords: Optional[list[str]]

response = client.responses.parse(
    model="gpt-4o-2024-08-06",
    input=[...], 
    text_format=ResearchPaperExtraction,
)

Optional объясняет, что keywords может быть не у каждой статьи.

Почему важно

- Убирает боль неверных форматов. При условии, что мы все идем к тулам и агентам (подробнее в 3 паттерне), это супер важно.

- Улучшает прозрачность. Все понятно, что модель нашла , а что найти не смогла (там будет None)

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

Structured Output и Reasoning

Никто не мешает вам совмещать Structured Output (SO) с рассуждающими моделями. Пусть они выводят свои рассуждения в отдельное (первое) поле:

class Step(BaseModel):
    explanation: str
    output: str

Есть статьи, которые говорят, что это ломает рассуждающие способности. Решение: пробуйте 2 раза. Сначала рассуждайте без SO, потом извлейкайте ответ с SO (более простой моделью, конечно)

Литература для изучения

- Документация от OpenAI
- Волшебный доклад про Pydantic
- Подробнее про двойной подход в SO + Reasoning
- Туториал по SO для Langchain

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

#llm_system_design

Как общаются агенты и что такое 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