12 правил разработки проектов с LLM

Давно не писал в канал. Не потому что забросил, а потому что писал свод правил по внедрению LLM. Попутно создал сайт, где я буду публиковать дальше статьи. Пока обошелся без AI, собрал на Тильде. Но AI консультировал по Тильде :)

В статье суммаризовал все правила внедрения LLM: про прототипирование, оценку качества, RAG, дообучение, оптимизации, агентов и про все все все, что вам может понадобиться. Читайте, делитесь с друзьями, делитесь мнением о прочитанном.

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

Еще очень важных новостей.

Мне сегодня стукнуло 30. Я уже совсем взрослый дата саентист. Если вы хотите меня поздравить, разберите статью из прошлого поста. Мне будет приятно.

И раз я теперь такой взрослый, пора становиться Всеволодом и менять название канала. «AI разбор» отличное название, именно этим я тут и планирую заниматься. А шутка про ИИнженера мне даже в начале не казалась особенно смешной.

И всем огромное спасибо за теплые слова и поздравления!

Aгент-аналитик для всех и каждого. Кейс компании Ramp.

Чтобы принять решение, нам нужна аналитика. Узнать, что покупали, куда кликали, что читали за прошлый день/месяц/год. Вопросы эти срочные. Отлично, если вы сами умеете в SQL. Хорошо, когда у вас свой аналитик. Ожидаемо, когда вы сделали задачу на аналитику, но не дождались ответа и все решили сами. Вот чтобы такого не было, финтех компания Ramp сделала агента дата-аналитика. Разбираем этот кейс.

Архитектура решения

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

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

2) По этой документации запускаем RAG. Находим релевантные базы данных. В контекст агента отправляем полное описание всех полей в базе. Про это читайте мое 5-е правило.

3) Агент пишет SQL-запросы. Запросы выполняются, результаты работы и ошибки отправляются на вход агенту.

4) Агент рефлексирует: все ли, что спрашивал пользователь он нашел? Если нет, можно еще поискать другие БД в пунте 2 или еще пописать SQL в пункте 3.

5) Если все нашли, формируем финальный ответ, показываем пользователю, ждем нагоняй конструктивную обратную связь.

Вот, кстати, неплохой туториал от Google по Text2SQL системам. Очень похожие идеи.

Бизнес эффект

Вы не оптимизируете работу аналитиков. Нет. Вы упрощаете сотрудникам доступ к информации для принятия решения.

В Ramp этому агенту задают 1500 запросов в месяц, а людям-аналитикам задают 66 запросов. Разница больше, чем в 20 раз. Это все те вопросы, которые люди боялись спрашивать или откладывали в длинный бэклог. Не трогай, это вопрос на новый год!

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

Основная проблема этого кейса

Ненадежность. Если по компании пойдет молва, что агент сгаллюцинировал, и из-за этого приняли неверное решение, это будет последний день этого агента. Нужна мощная система защиты от галлюцинаций (читайте правило 8). Мои варианты защиты от менее надежного к более:

1) Дежурный аналитик. Заметьте, что вопросы задаются в канале, а не в личных сообщениях. Если бы босс был я, в канале обязательно был бы дежурный аналитик, у которого обязанность проверять, что в ответах не полная ерунда.

2) Явная проверка. Вы делаете через бота предварительную разведку. Если хотите результаты анализа написать на слайде, делаете задачу на отдел аналитики. Они перепроверяют.

3) Copilot для аналитика. Не даем инструмент всем, а только ускоряем работу аналитиков. Они проверяют, что агент отработал адекватно.

Резюме

Из этого кейса нам нужно вынести 2 урока:

- ИИ это не только про автоматизацию. Это про демократизацию и более широкий доступ. Который в долгую может быть намного важнее.

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

Что думаете про этот кейс? Жду ваши мысли и вопросы в комментариях. И пишите в личные сообщения, если хотите разобрать другой AI-проект.

#ai_cases

Как AI делает деньги.
Классический зарабатывает больше генеративного?

В 2024 компании инвестировали 250 млрд. долларов. Пошли внедрять GenAI на эти деньги, куда только можно, но 80% компаний не получили финансового эффекта. Зато внедрили, отчитались.

Почему все вкладывают деньги, но не получают выхлопа? И можно ли его вообще получить? Обсудим в серии постов «Как AI делает деньги».

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

Как на самом деле работает любой AI

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

У вас есть процесс, который вы хотите наделить этим самым интеллектом. У процесса есть входные данные (текст, картинка, видео, etc) и метрика, где мы понимаем, что выход процесса нам нравится. Дальше вы оптимизируете модель делать этот процесс под эту метрику. Все.

Чем более изолированный процесс, тем проще его оптимизировать. У него намного проще померить успех. Например, процесс «классификация искового заявления» сильно проще оптимизировать, чем «составление искового заявления». Во втором куча разных подзадач и нюансов, от которых зависит успешность результата.

Какой AI зарабатывает больше

По оценкам McKinsey 70% потенциала влияния ИИ на мировую экономику, это классический ИИ и только 30% — генеративный. Это именно потенциал. Если даже все внедрить правильно, генеративный ИИ будет приносить денег меньше. Если вы постоянный подписчик, то понимаете, что внедряют чаще всего неправильно :)

Самые денежные процессы сейчас оптимизируются по старинке, без всяких LLM. Это, например:

- Рекомендательные системы

- Кредитный скоринг

- Видео аналитика на производстве

Это массовые изолированные процессы с моментальной обратной связью. Пользователь купил? Клиент вернул кредит? Оборудование исправно? Сама Вселенная хочет, чтобы мы поставили здесь модельку и научили ее делать это действие оптимальным образом.

А что с LLM?

В генеративном ИИ такие удобные процессы тоже есть. И они, очевидно, будут внедрены в первую очередь. Это, например:

- поддержка клиентов. Бот решил проблему?

- маркетинг. На письмо ответили?

- продажи. Встречу согласовали?

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

Значит, зарабатывать нужно по-другому. Не как с классическим AI. Каким образом? Об этом расскажу в следующих постах. Там и вылезут наши любимые AI-агенты.

LLM уже решает реальные рабочие задачи, как человек? Бенчмарк от OpenAI

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

Как OpenAI проводили этот замер, пора ли хантить AI-сотрудников, поговорим в этом посте. Поехали.

Как замеряли модели

Взяли 44 цифровых профессии, на которые приходится больше всего денежных выплат в США. Эти профессии зарабатывают 3 триллиона $ в год.

Дальше рекрутировали экспертов в каждой профессии. Эксперт предлагал реальную задачу из своей практики. Задача это не только текст, но и картинка/видео/excel-файл и тд.

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

Результаты

- На 1-м месте Claude Opus 4.1 с винрейтом 47.6 % против человека.

- На втором GPT-5, которая побеждает человека в 38.8 % случаев.

- Дальше ризонинг-модели от OpenAI с чудовищным неймингом, и на 5-м месте Gemini 2.5 Pro. Маск даже не в пятерке :(

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

У вас могла возникнуть идея…

Пора переходить на AI-сотрудников?

Не пора. В эту ловушку попадал сам Джеффри Хинтон в 2016 году, когда сказал, что рентгенологи не нужны, ведь AI находит на снимках болезни лучше. С тех пор спрос на рентгенологов только растет. Почему?

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

Но работа рентгенолога целиком это огроменная композиция этих задач и постоянное переключение между ними в зависимости от текущей ситуации. Кстати, именно по этой причине мне нравится copilot режим — рутинные задачи отдаются в AI, но проверяет их решение и склеивает все воедино эксперт.

Резюме

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

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

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

Сева-новости

Понял, что безумно приятно в нашем уютном канале делиться личными новостями. Готовьтесь :)

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

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

Карпатый обещал нам еще 10 лет до AGI. Так что нас с вами ждет много увлекательной работы.

4 шаблона разработки AI-агентов

Карпатый недавно высказал непопулярное мнение, (а я давно это говорил!) что неправильно рассуждать, про “год ИИ-агентов”, а надо говорить про "десятилетие ИИ-агентов". У агентов столько проблем, что мы 10 лет будем их решать. Маск, конечно, возвразил, что Грок завтра всех победит, но мы то с вами все понимаем.

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

Базовая архитектура AI-агента

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

context = [{{"role": "user", "content": first_prompt}}]

while True:
    response = llm(context)
    context.append({"role": "agent", "content": response.text})
    if response.tool_calls:
        tool_result = execute_tool_calls(response.tool_calls)
        context.append(tool_result)
    else:
        return response.text

В чем основная проблема?

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

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

Новые шаблоны архитектуры

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

- Внешняя память. Не все нужно писать в контекст. Часть информации может быть полезна только в очень редкие моменты. Разумно такую информацию добавлять не в контекст, а записывать во внешние файлы, которые потом можно загрузить через отдельный tool. Ну или через RAG поверх всей памяти. Особо деликатный вариант использует Manus: информация записывается во внешней файл, а агент может пользоваться обычными bash-утилитами, вроде grep, чтобы найти в файле все, что агенту нужно.

- Суммаризация контекста. Часто в контексте куча лишней информации, которую можно почти без потери качества сжать другими моделями. Например, Congnition очень не любит мультиагентов, предпочитают этот вариант. Не сжатый вариант всегда можно сохранить во внешней памяти
(см. пункт 2)

- Актуальный план через файл. Агент всегда должен иметь возможность вернуться к плану, чтобы отрефлексировать, туда ли он сейчас идет. Это позволяет постоянно фокусироваться на решении исходной задачи. Все как у людей. Например, в Claude Code есть файл ToDo List, где агент пишет, что он собирается сделать.


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

Как AI делает деньги. Заставляем LLM приносить пользу

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

Наш с вами классический рецепт успеха: наняли команду из 5 ML-щиков, собрали датасет, обучили модель, работать тут уже не будет. А что будет? Разбираемся в этом посте.

Горизонтальное и вертикальное внедрение

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

На самом деле, так почти все и делают. Именно отсюда берутся отчеты про 99.9% компаний внедрили LLM :) Здесь внедрение AI больше похоже SaaS. Купил, поставил, работает. Ничего перестраивать не надо. Только бизнес-эффект вы тоже никак не замерите. Но для SaaS вы же тоже его никогда не мерили, правда? Попробуйте посчитать на досуге ROI от покупки Microsoft Outlook. Про это отлично написали коллеги из McKinsey, но суть вы уже поняли.

Гораздо эффективнее брать один бизнес-процесс и оптимизировать именно его. Это называется вертикальное внедрение. Тут уже и ROI понятно как считать.

Но есть 2 проблемы:

1) Процесс состоит из кучи связанных задач. Вот поэтому все и носятся вокруг AI-агентов. Нужно, чтобы система умела делать сложную многоэтапную работу. Пока выходит так себе. Но мы работаем над этим. Я верю, что следующий год подарит нам много прорывов в области обучения агентов с помощью Reinforcement learning. Следите за моими публикациями :)

2) Каждая такая задача уникальна. В разных отделах могут быть абсолютно разные процессы, например, работы с клиентами. Наивно думать, что кто-то выпустит коробку, которая начнет пользу приносить, как только вы примете лицензионное соглашение. Здесь AI вообще не SaaS. Модель под каждую задачу нужно будет адаптировать. И нельзя адаптировать как раньше: собрать 5 ML-инженеров и дать им датасет. Не хватит времени и денег. Здесь нам AI внедрение нужно разделять на 2 разных этапа.

Платформа и масштабирование

Платформа создает интеллектуальную мощь системы. На этом этапе работают много ML-инженеров, они пишут много кода, создают AI-системы, от которых требуется обобщаемость. То есть, когда эту платформу будут внедрять в реальные процессы, допиливать напильником придется, но максимально мало. Эту платформу можно разрабатывать внутри компании или купить у вендора.

Масштабирование — это внедрение платформы сразу во многие процессы. На этом этапе должно работать как можно больше бизнес экспертов, которые точно понимают, что им нужно. И как можно меньше ML-инженеров, потому что это дорого. Здесь происходит допиливание напильником и оценка качества. Если все ок — внедряем, если напильника не хватает — делаем заказ в платформу.

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

Сегодня вечером буду душевно общаться про наши любимые LLM с коллегами из R77 AI.

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

Приходите общаться про LLM, агентов, технологии и что с этим всем поменяется в будущем. Постараемся выдать базу, но и немного пофантазировать.

Друзья, выпустил новую статью про экономический эффект от внедрения генеративного AI. Спойлер: часто эффект отсутствует.

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

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

Читайте, делитесь прочитанным с друзьями, пишите вопросы и возражения

Ставим агентов на поток. Кейс компании DoorDash

В своих статьях и постах (один и два) я занудствую про важность платформ. Нет ничего сильнее семьи платформы. Делают ли так на практике, или это просто мнение одного фантазера? Неделю назад вышла статья DoorDash, которая поможет нам разобраться, зачем кому-то понадобилась платформа AI-агентов.

Про что платформа

DoorDash — крупнейшая компания по доставке еды в США. У них накоплена масса полезных знаний о их бизнесе: корпоративная вики, таски в джире, множество SQL-таблиц, регламентов и прочих разных вкусностей корпоративных гигантов.

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

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

Каких агентов можно создавать

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

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

- мультиагент через планировщика. Самый простой и рабочий вариант мультиагентной системы. Главный агент независимые подзадачи раздает субагентам, а потом собирает ответ. Классический пример от Anthropic.

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

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

Техническое устройство

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

- RAG-платформа, через которую вы добавляете информацию

- Поддержка SQL

- Система оценки качества агента

- Валидация ответа и Guardrails

И много чего еще. После небольшого инструктажа обычный человек, используя эти кубики, сможет собрать реально полезного агента. Да, там не будет последних трюков из контекст-инжениринга. Да, LLM там обычные, а не дообученные под эту задачу. Но мы получим 80% результата за 20% сил.

Главный секрет успеха платформы — как надежно и удобно работает система оценки качества. Если получилось — дальше собирать Лего одно удовольствие. Если нет — всегда будут получаться жигули.

Моя вера в будущее

Я верю, что только так мы сможем масштабировать AI. Многие со мной согласны. Компании валом побежали делать платформы для создания агентов. Даже OpenAI, которые ранее верили только в один мега-мозг.

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

#llm_cases

Фреймворк, как привести к успеху любой AI-проект

Самый частый вариант беседы, когда меня просят помочь с проектом:

- Сева, вот смотри, хотим решить проблему X. Понятно?
- Пока да.
- Супер! Короче, мы взяли 15 ИИ-агентов, в них запихали 4 роутера, облили это все графовой базой знаний. И все это на 1.5B квене, который мы специально доучили, но код обучения случайно удалили.
- Уже понятно меньше, но допустим. А что вы от меня хотите?
- Вот оно у нас плохо работает...

Беседа потом идет примерно одинаково. Готовьтесь, дальше не будет никакого роя AI-агентов. Дальше будет нуднота.

Итеративный фреймворк управления проектом

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

Элементом фреймворка является гипотеза. Гипотеза — это идея, что некоторое изменение улучшит качество AI-проекта. Например, что нужно LLM обновить до GPT 5.1. Гипотеза может быть в одном из трех состояний:

- Прототипирование. Нужно как можно скорее понять, а стоит ли инвестировать силы. Подробнее в статье.

- Оценка качества. Замерили и теперь понимаем успешная ли гипотеза. Гайд по замеру качества.

- Внедрение. Уверены, что гипотеза полезная. Разрабатываем и внедряем.

Любой проект начинается с самого простого и легко поддерживаемого решения. Например, чат-бот. Вначале просто API к GPT + простой промпт. Больше ничего. Смотрим недостатки (время/цена/галлюцинации/etc). Делаем гипотезу. Потом еще одну. Идею вы поняли.

Откуда берутся гипотезы

Нет, не из статей с хабра и даже не с arxiv.org. Гипотезы рождаются из анализа проблем. Типовой анализ выглядит примерно так:

- Собрали репрезентативный список задач в систему. Например, запросы в чат-бот за год.

- Оценили качество текущей системы.

- Разбили примеры с проблемами на понятные группы.

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

Резюме

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

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

Ваше путешествие начинается с одного шага. Так написано на моей беговой дорожке. Уверен, эти ребята знают, о чем говорят.

А судьи кто? Гайд по LLM-as-a-judge

Оценка качества — ключ к фрейморку успешного AI-проекта. Если вы не овладете этим навыком, любые ваши AI-успехи, если они и будут, окажутся только случайной удачей. Недавно в моей статье мы бегло просмотрели эту тему.

Сегодня погрузимся в самый популярный метод — оценка качества моделей “LLM-as-a-judge”. В нем вместо оценки ответов людьми мы оцениваем ответы другой "LLM-судьей". Тут обычно все шутят, что критиковать всегда проще, чем творить. Мне шутка уже надоела, но законы жанра. Извините.

Когда использовать LLM-as-a-judge?

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

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

2) Вам нужны очень быстрые итерации.
Гонка, пожар, стартап. Если вам нужно получать оценку качества через часы, а не дни.

3) У вас нет ресурсов.
Не только денег. Обучение разметчиков это обычное преподавание. Это материалы, ответы на вопросы, тесты, экзамены. Регулярные проверки, что они все не забыли и не жульничают. Это требует много сил и отдельного штата специалистов.

Как сделать LLM-судью? Пошаговый план

1) Берем бизнес-эксперта. Человека, который понимает, когда система работает правильно. Вместе с ним прорабатываем критерии, по которым оцениваем. Например, релевантность ответа, безопасность, достоверность и тд.

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

3) Переразмечаем, спорим, пока мы с экспертом согласованно не разметим корзинку. Так мы поверяем, что мы сами поняли критерии. В итоге у нас получается «голден корзинка» таких эталонных примеров хороших и плохих ответов.

4) На части этой корзинки тюним LLM-судью. Тестируем итоговое качество на другой части. Тюнить можно по-разному: писать промпты, разбивать задачу на подзадачи (на каждый критерий можно отдельного судью), добавлять агентность. Можно даже файнтюнить LLM. Важно делать это итеративно, как и во всем AI-проекте.

Резюме

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

Если ваша разметка явно не противоречит 3-м пунктам из этого поста, начните с LLM-as-a-judge, а не с разметки людьми. Если не получится, вы всегда сможете часть простых задач разметить LLM, а все сложные отправить людям. Или сможете давать людям LLM-подсказки, чтобы они могли быстрее размечать.

Пробуйте, пишите промпты, замеряйте качество, задавайте мне вопросы. Если оваладете оценкой качества, тогда никакой AI вам не будет страшен.

Экологичный метод дообучения LLM

Я не люблю учить модели. Точнее, я не люблю, когда учат на каждый чих, хотя можно было обойтись методами попроще. Почему?

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

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

Чем LoRA экологичнее?

LoRA (low-rank adaptation) не трогает исходную модель. Метод обучает новые параметры, так называемый адаптер, который просто складывается с оригинальными весами модели. Из этого сразу вытекают два важных преимущества:

1) Размер данных для обучения.
Если для честного дообучения нам нужно были десятки тысяч примеров, то LoRA заводится даже с несколько сотен. Зависит от размера адаптера, который можно регулировать.

2) Удобство предсказания.
Вам не нужно держать 20 клонов модели для 20 разных внедрений. Вы можете только один раз запустить модель на дорогих сердцу GPU-серверах, а 20 раз использовать разные адаптеры, которые намного меньше. На этапе предсказания веса модели будут на лету складываться с параметрами адаптера и выдавать предсказания для 20 разных задач. Ну оооочень экологично, правда. Такой функционал реализован во многих библиотеках, например, в vLLM.

На второй пункт обычно все забивают. И часто в компании возникает зоопарк из 30 версий модели, у каждой по 1 H100 с 3% утилизации железа. Зла не хватает.

Когда и как применять LoRA?

Метод отлично подходит, когда у вас немного качественных данных. На моей практике, когда примеров сотни/несколько тысяч, LoRA показывает паритет с честным обучением и даже иногда его превосходит (но нужно правильно подобрать размер адаптера). Когда примеров уже десятки тысяч, дообучение начинает обгонять по качеству.

Отличное исследование по LoRA, сделали коллеги из Thinking Machines. Некоторые выводы:

- Нужно применять адаптер ко всем слоям модели, а не только к слою внимания.

- Чем больше размер адаптера, тем больше он может заполнить, тем дольше надо учить.

- Шаг обучения ставить примерно в 10 раз выше, чем при полном обучении.

Резюме

Я не хочу, чтобы мы с вами делали разовую AI-активность. Я мечтаю, чтобы мы создавали методы массовой трансформации. LoRA намного больше подходит под эту мечту, чем классическое полное дообучение.

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

Друзья, опубликовал подробный фреймворк оценки качества LLM.

Он состоит из 7-ми шагов, по которым вы сделаете метрику под вашу LLM-задачу. Там много примеров, наглядных схем, основанных на моей 3-летней практике.

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

Друзья, привет! Нас уже более 3-х тысяч, спасибо вам за это. Для тех, кто недавно со мной знаком, расскажу про себя и канал.

Я Сева, и уже 9 лет занимаюсь внедрением AI. Работал в VK, Яндексе, сейчас в Т-Банке. Начинал стажером, стал разработчиком, сейчас руководитель команд.

За 9 лет я много раз делал не так. Пришлось структурировать свой опыт в методику «как внедрять AI хорошо», чтобы избежать дальнейших ошибок. Год назад я понял — в этой методике нет ничего сложного, и я могу ей обучить. Не только инженера, но и аналитика, продуктового менеджера, маркетолога. И создал этот канал.

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

Далее перечислю материалы, которыми я горжусь больше всего.

Статьи про методику внедрения AI:

- 12 правил внедрения LLM

- Почему генеративный AI не приносит прибыли

- Методика оценки качества LLM

Основные посты про методику:

- Главный пост про итеративный фреймворк работы с AI-проектом

- Платформа — ключ к массовому внедрению AI

- Почему нельзя купить AI из коробки

- Как неправильное внедрение стоило компании полмиллиарда долларов

- Почему чаще всего не стоит делать своего code-ассистента. Кейс Uber

- 3 кита улучшения любой LLM

- Как можно сделать модель лучше, чем OpenAI и всего за 8 долларов

Кейсы:

- Ставим разработку AI-агентов на поток

- Как создали AI-агента аналитика

- Агент, который исследует информацию в интернете

- Массовая обработка документов на LLM

Уверен, в следующем году в этом посте будет минимум в 2 раза больше полезных материалов.

Если у вас есть мысли, идеи или вопросы по внедрению AI, всегда можно написать мне @seva_batareika

Как посчитать профит от LLM. Если, конечно, он у вас есть.

Знаете, в чем феномен рекомендательных систем? Легко посчитать эффект. Обучили новую модель, потратили X денег на команду/железо. Провели АБ эксперимент, получили рост продаж на Y. Сравниваете X и Y. Для бизнеса все супер прозрачно.

В генеративном AI не так, 80 % компаний не видят финансового эффекта. Но не потому что LLM бесполезны. Обычно, LLM в компании делает что-то базово разумное (хотя бывает всякое). Но никто не может эффект от этой разумности посчитать. Почему это сложно, и что нам теперь делать, об этом сейчас поговорим.

В чем основная проблема

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

В LLM все намного сложнее. Допустим, мы делаем копайлот для сотрудника. Нам нужно:

1) АБ-инфраструктура. Уникальный айди, по которому мы можем сотрудников сплитовать, и система, которая оценивает его перфоманс. Перфоманс, кстати, не у всех профессий можно легко замерить.

2) Много сотрудников, чтобы мы могли что-то прокрасить в АБ.

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

Что делать?

Большинство внедрений LLM не подходят под условие выше. Что нам, теперь не вдрять Copilot для 10 программистов? Внедрять. Варианты:

1) Самое смелое — принять риски.
Посчитать через полгода интегральные метрики. Например, сколько вы сделали релизов, как часто пропускали критичные баги и тд.

2) Самое наивное — проводить массовые опросы.
По шкале от 1 до 10 оцени, насколько Copilot делает тебя продуктивным. Это, конечно, шляпа. Никто не скажет, что я не разобрался даже с главным меню и пользовался им 2 раза. Конечно, мой босс купил очень хороший Copilot!

3) Самое сложное — подумать.
Если вы не можете померить эффект, вам нужно создать прокси. Вы не можете оценить перфоманс менеджера, который пишет вам отчеты через LLM-копайлот. Но вы можете проверить, что менеджер хотя бы им нормально пользуется. Логировать все вопросы, проверять качество отчета (он же этот отчет потом нам покажет!) и оценить, сколько времени требовало бы написать этот отчет (через другие LLM, например). И дальше по пункту 1, но уже более осознанно.

Это затраты на отдельную инфраструктуру, но ее можно использовать во всех AI-проектах внутри компании. Знаю, это гениально, жаль я не придумал это первым :) Уже давно есть стартапы, которые делают такую инфраструктуру.

Резюме

Внедрение LLM тормозится не из-за мифической инертности компаний. Никто не будет долго думать, если ты кладешь в коробку рубль, а она выплевывает два. Дайте мне тысячи таких коробок! Проблема, что ты кладешь рубль, а коробка выплевывает AI. И что с этим AI теперь делать?

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

Друзья, с наступающим! Пусть в следующем году профит от ваших проектов будет такой гигантский, что этот пост вам не пригодится. Спасибо, что читали весь этот год. Обещаю, что в 2026-м читать этот канал будет еще интереснее.