Сходил недавно на теплый ламповый подкаст

Поговорили про RAG, конечно же агентов и немного про сингулярность. Все что мы любим.

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

3 кита улучшения LLM

У вас есть всего 3 способа улучшить LLM на вашей задаче. Многие путают, когда какой использовать. Давайте вместе разберёмся.

Подбор промпта

С этого всегда надо начинать. Удивительно, но часто делать больше ничего не надо.

Но не стоит здесь сходить с ума и обещать модели 100 баксов за правильный ответ. Есть несколько базовых правил:

- пишите подробно и с точными формулировками
- пробуйте Few-Shot
- используете reasoning (o1-подобные модели или просто Chain of thoughts)
- используйте Structured Output
- дробите большой промпт на несколько маленьких.

Все эти техники и даже больше можно почитать тут.

RAG

RAG - это подключение LLM к внешней базе знаний. Это основной способ внести в LLM знания, которая она не получила во время своего обучения.

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

Отдельная боль в RAG - борьба с галлюцинациями. Явно в промпте укажите, что для ответа можно использовать только информацию из промпта. Если не помогает - подключайте вторую модель, которая будет оценивать ответ на галлюцинации. Посмотрите вот эту статью - поможет вдохновиться.

Дообучение

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

Ошибка использовать дообучение, чтобы внести в модель новые знания. Так только галлюцинации поднимете. Используйте RAG.

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

Учитывая мою патологическую жадность и ненависть к черным ящикам, я рекомендую дообучать модель всего в 10% случаев. Остальное можно решить промтом и RAG.

Без чего нельзя улучшать

Перед любым улучшением LLM вам нужно уметь это улучшение замерять. Это быстро и дешево можно делать с помощью другой LLM. Такой подход называется LLM-as-judge. Его разберём в следующих постах.

Друзья, если остались вопросы, как крутить LLM - пишите в комментарии. Разберемся.

Улучшать LLM или улучшать поиск, когда делаем RAG?

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

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

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

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

За кем будущее?

Поиск в RAG - набор инженерных решений. LLM - штука, которая поддается законам масштабирования. Как думаете, что будет быстрее развиваться?

Посмотрите внимательно на график (данные из статьи). На нем показано, как деградирует качество разных LLM, при росте размера контекста. Посмотрите, как сильно деградирует качество GPT-4o mini по сравнению с ее старшим братом GPT-4o. Чем мощнее модель, тем лучше она будет работать с длинным контекстом. И это будет продолжаться, пока мы всю «Войну и мир» не будем в контекст выкладывать.

Недавно вышла Gemini 2.5 pro. На сложном бенчмарке MRCR, в котором нужно отвечать на очень длинном диалоге, модель показывает 95% качества на среднем контексте в 128 тысяч токенов. Это примерно 200 страниц английского текста.


Пока еще не "Война и мир". Да и пока в реальных задачах метрики не такие сказочные. Пока что крутим поиск. Пока что.

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

Там собраны советы по:
- в каких задачах нужно внедрять LLM
- какая команда должна это делать
- как внедрять быстро и дешево
- как оценивать качество
- как LLM улучшать
и многое многое другое

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

Если у вас остались вопросы после прочтения - пишите в комментариях тут или на хабре. Все разберем.

https://habr.com/ru/articles/896598/

Какую модель применять в NLP?

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

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

Друзья, нас уже 1000 человек!

Спасибо, что вы читаете, ставите реакции, задаете вопросы.

За эти 4 месяца я понял, о чем я на самом деле хочу писать. Конечно, об ИИ. Но только о пользе, экономии, смыслах и о том, куда все это идет.

Предлагаю не просто смотреть, как оно идет, а активно пользоваться и тем самым менять мир.
Вместе мы поймём как.

P.S.
Паша Дуров уже показывает вам рекламу, где интересно моя доля?!

Как Uber 6 месяцев внедрял собственный Code assistant

Нашел клевый доклад Uber, как они внедряли ИИ ассистентов в разработку.

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

Какая тут проблема: генерация кода крайне сложная задача, с кучей подводных камней. Ее пытаются решить огромные компании, которые хотят на таких ассистентах деньги заработать. Например, Github Copilot от Microsoft. Uber не хочет на своем решении деньги зарабатывать, то есть он не будет инвестировать туда столько же ресурсов, сколько Microsoft. Какой у Uber шанс при таких вводных?

После 6 месяцев разработки проект закрыли.

Переехали на Github Copilot. Поняли, что за внешними продуктами им не угнаться. И это отличный исход: они нарастили экспертизу в AI, вбухали не так много денег и вовремя закрыли.

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

Зачем тогда вообще делать свои AI решения?

Кажется, что нам вообще можно ничего не делать? Нет.

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

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

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

Кто такие агенты, и когда их применять

Давайте разбираться, что это и зачем оно нужно.

Что такое агент

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

Пример. Вы автоматизируете поддержку клиентов. У вас может быть алгоритм: дорогая LLM, сначала прочитай эту доку, затем проверь исключения тут, если это, то можно можно вызвать оператора и тд. Тогда у вас не агент, а LLM-workflow (так это называют Anthropic, я пока не придумал как перевести)

Агент, это система, которая сама решает, как ей выполнить поставленную задачу. Она не следует заранее приписанной логике. Схематично это показано на картинке.

Пример. Поддержка клиентов. Вы говорите, что твоя цель решить задачу клиента. Вот такие инструменты есть. Вот так ты можешь у клиента что-то спросить. Удачи, ты сможешь!

Когда агентов нужно применять

- Задача плохо поддаются точному регламенту. Невозможно описать, что за чем надо делать.

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

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

Примеры

Как вы, наверное, поняли, пока диапазон применения скуден. Знаю 3 успешных варианта применения:

1) Разработка. Риск нивелируется тестами. Экономический эффект огромный. Идеальный кандидат.

2) Поиск информации. То что называется Deep Research. Работа дорогая, надо тонну текста прочитать и понять. Риски низкие, читающий может проверить

3) Личный помощник. Двигает мышкой за тебя, бронирует рестораны, экономит время. Рисков почти никаких. Экономический эффект больше хайповый.

Что посмотреть про агентов

- Гайд от Anthropic
- Гайд от OpenAI
- Видео с лучшими практиками от Anthropic

Резюме.

Агенты - крайне редкий зверь в применении LLM.
Но зверь с большим потенциалом.

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

Прогресс в ИИ за 6 лет

Коллеги из METR выпустили прекрасный отчет, который позволит нам по-новому взглянуть на прогресс в ИИ.

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

- В 2017 нейросети распознают аудио как человек. Человеку нужно на это пару секунд.

- В 2022 нейросети отвечает на вопросы как человек. Человеку нужно на это десятки секунд.

- В 2024 нейросети делают поиск в интернете как человек. Человеку нужно на это десятки минут.

Здесь мы видим важную экономическую метрику и ее тренд.

1) Прогресс в ИИ стоит оценивать через метрику "сколько времени на эту задачу тратит человек".

2) Эта метрика удваивается каждые 7 месяцев.

Что будет дальше?

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

Но если этот тренд продолжится, ситуация кардинально поменяется. Можно прикинуть, что будет уметь ИИ через пару лет:

- 2026 год. ИИ уже может решать часовые задачи. Например от и до, написать несложную программу.

- 2027 год. ИИ может работать много часов подряд. Здесь уже пахнет автономностью и огромным экономическим эффектом.

Это не хайп и не гадание на хрустальном шаре. Только тренды. Более подробно про метод исследования читайте в оригинальной статье.

Почему не стоит верить 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