Где вам нужно внедрять LLM

В предыдущем посте мы поняли, где нужно применять ИИ. Теперь разберем конкретно LLM.

Чем LLM отличается от других моделей?

1) Взаимодействие через текст.
C LLM можно решать все задачи, которые сводимы к тексту. А таких задач довольно много. Например, вы можете использовать LLM как “мозги” для робота: показываете LLM состояние комнаты, спрашиваете, какой манипулятор робота куда повернуть, чтобы достать эту чашку кофе? Пример такого робота можно посмотреть тут. Такие штуки иногда даже меня немного пугают.

2) Обобщаемость
LLM прекрасно справляется с новыми задачами, которые она даже никогда в глаза не видела. В статье, где сравнивали ChatGPT с другими моделями по 140 различным задачам, она часто идет вровень с моделями, которые всю жизнь учились только одной специализированной вещи. За счет чего LLM это удается? Два секрета: Self Supervised Learning + Законы масштабирования

Как следствие обобщаемости возникает такой феномен, который часто называют “креативность”. LLM может не потеряться от новых условий, увидеть паттерны, которые она уже встречала и разложить неизведанное по полочкам.

3) LLM дороже, если вы все делаете сами.
Их дороже обучать, они больше едят GPU, они дольше отвечают.

Но LLM может быть дешевле классического ИИ, если вы берете готовое решение. В классическом ИИ вам нужно было собирать отдельную выборку, обучать отдельную модель, писать под нее отдельный код. LLM из-за особенностей 1) 2) сильно гибче. Вы описали в промпте, что от нее хотите, и оно неплохо работает. Вы сэкономили на сборе данных, обучении модели, зарплате датасаентистов (на мне, то есть 😩 ). Из-за этого идет повальное применение LLM в малом бизнесе.

Явное следствие пункта 2) и 3) - не имеет никакого смысла делать свою LLM в узкой задаче. Вам не нужно платить за обобщаемость, когда у вас очень мало исходов. Например, классифицировать новости про бренд на негативные/позитивные. С этим прекрасно справятся обычный Bert, вам не нужен там o3.

Некоторые области применения LLM

1) Любой R&D.
Неважно, это разработка нового приложения, разработка нового лекарства или супер гаджета. Здесь нам очень поможет обобщаемость, то есть способность LLM решать новые задачи. В 2024 CEO Google заявил, что 25% нового кода в компании пишут с помощью ИИ. Вы представляете, сколько это денег? Ладно, если вы все еще не верите в креативность LLM, прочитайте интервью лауреата премии Филдса Теренса Тао. Он в нем наглядно рассказывает, почему AI станет помощником любого математика.

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

3) Автоматизация бизнес процессов.
Такое RPA-на-максималках. Огромное число беловоротничковой работы: получил отчет, выделил важное, завел таску, отправил письмо коллеге. То, что обычный rpa-кликер делать не мог из-за своей низкой интеллектуализации. Это уже пошли активно делать, посмотрите интервью фаундера крупнейшей RPA платформы UIPath.

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

Сколько это денег?

Если вам кажется, что это мало и высосано из пальца, то нет. Первый пункт это IT, фарма, технологичное производство. Мировой рынок только поддержки клиентов, это 500 миллиардов долларов. Третий пункт это проценты автоматизации почти любого бизнеса во всем мире. Короче, это триллионы долларов и огромное влияние на мировую экономику.

Разве это не тот приз, за который хочется побороться?

Почему продакт менеджеры самые важные люди на проекте

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

Почему проваливаются ИИ-проекты

По статистике проваливается 80%. У меня счет немного получше, но я точно знаю, почему столько проваливается.
Потому что делают непонятно что.

Разберем понятный кейс. Вы начали делать ассистента для интернет магазина. Благое дело!
Написали инструкцию для разметчиков данных. Потратили кучу денег, подождали пару месяцев, обучили модель. Потом запустили эксперимент и оказалось, что ваши ответы никому не нравятся. Ответы подробные, но в них нет никакой ценности. Они не подсвечивают размер дисплея у телевизоров, крутость видеокарты у игрового ноутбука, БЖУ у фруктового салата. Они хорошие, но бесполезные для пользователя. А данные уже собраны.

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

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

Как это происходит на практике

Описание продукта родиться в вакууме не может. Было бы неплохо, конечно, запереть продакта на неделю в комнате, дать ему бумажку и сказать - пиши. Но так не работает. Нужно смотреть на реальное поведение системы. Тут нам поможет наш старый друг Prompt Driven Development.

Вы собираете прототип. Не думаете про скорость, стоимость. С самыми крутыми моделями, живете на широкую ногу. Я разрешаю использовать даже 10 моделей. Дальше этот прототип конфигурируете промптами и в процессе понимаете, какое поведение вам нравится. В итоге у вас появляется образец продукта и промпт, который этот продукт описывает.

Вам кажется кощунством, что продакт менеджер подбирает промпт?! Для этого же есть целая экспертная профессия Промпт-инженер! Забудьте. Подбирать промпт это примерно тоже самое, что объяснять, что нужно делать человеку, который вас не очень понимает. Этим менеджеры занимаются всю карьеру.

Вместо резюме

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

Сейчас в эпоху LLM и промптов правило еще проще, которому я уже научу вас.
Если вы описали вашу задачу в одном исчерпывающем тексте - вы ее уже решили. Дальше уже дело техники.

Но описать ее будет не просто. Для этого вам потребуются верные друзья.

Как дешевеет ИИ, и к чему это приведет

Мы очень неплохо научились удешевлять модели. Есть целый набор инженерных трюков:

- Дистилляция - переливание знаний в маленькую модель
- Квантизация - использование простых форматов данных в моделеях
- Кэширование промптов - запоминание одинаковых промптов
- Спекулятивный декодинг - комбинация маленькой и большой модели

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

Из-за этих инженерных трюков и закона Мура стоимость будет постоянно снижаться. По аналитике коллег из Andreessen Horowitz, стоимость инференса моделей дешевеет в 10 раз каждый год. Сейчас модель-ризонера, сравнимого с Deepseek, можно запустить на не самом дорогом ноуте и кайфовать от интеллекта.

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

Вот это падение стоимости интеллекта сформирует совершенно новую индустрию. В которой стоимость интеллектуального труда не будет таким сдерживающим фактором для создания дополнительной ценности. Мне очень нравится аналогия профессора Карима Лахмани:

- Когда стоимость доступа к информации упала до нуля (веб браузер), родились компании, как Google.

- Когда стоимость дистрибуции приложений упала до нуля (App Store), родились компании, как TikTok

- Когда стоимость интеллектуальной работы упала до нуля (?), родились компании, как ...

Здесь огромные возможности для всех. Может, кто-то из вас и создаст компанию нового типа.
Я очень надеюсь вам в этом помочь.

Опасная любовь к black box

Внимание, черный ящик!

Собрал данные, запихнул в модель, и этот черный ящик сам разберётся, что надо сделать. Так обычно представляют работу с ИИ большинство людей, даже продвинутых специалистов, которые могут нейронки хоть на Java Script писать.

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

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

Делаем ящик прозрачным

LLM, особенно рассуждающие модели, все переворачивют.

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

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

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

Скоро построение ИИ систем мало чем будет отличаться от построения бизнес процессов в компании.

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

Тогда заживем.

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

Поговорили про 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