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

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

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

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

Что там есть

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

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

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

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

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

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

Чего там нет

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

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


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

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

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

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

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

Метрики

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

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

Архитектура

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

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

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

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

#llm_cases

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The gen AI paradox

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

#llm_system_design

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

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

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

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

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

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

Почему так?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Продолжаем серию о создании надежных LLM-продуктов. Сегодня наконец говорим про метрики качества.

Тема 7. Оцениваем качество LLM

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

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

Понятно, что вас скорее всего волнуют пользовательские онлайн метрики. Желательно, деньги. Ну или retention пользователей. К сожалению, их долго мерить. Для быстрых итераций нам нужны оффлайн метрики качества, которые как-то аппроксимируют ваш целевой онлайн. Мы верим, что улучшая оффлайн метрики, в итоге наши пользователи будут нам благодарны.

Почему LLM сложно оценивать?

В ИИ есть 3 класса задач. В них по-разному делаются метрики качества.

1) Задачи, в которых есть точный ответ.
Тогда все ваши метрики качества это сравнение ответа модели с эталоном. Например, классификация, где вы сравниваете с правильным классом. Сравнивать можно не обязательно точным совпадением с эталоном. Можно, например, текстовыми метриками (BLEU, WER) или пускай сравнивает отдельная модель, например BERT (bert_score). В этом классе обычно проблем нет.

2) Задачи, в которых ответ можно проверить.
Ну тогда возьмите и проверьте :) Это, в первую очередь, код, который можно прогнать на тестах. Это математика, в которой можно проверить формальное доказательство. В этом классе раньше были проблемы, сейчас современный RL тут всех унижает. Посмотрите сколько компаний выигрывают одну и ту же олимпиаду по математике. Я уже сбился со счета.

3) Задачи, в которых правильный ответ хрен пойми какой.
С этим обычно самые трудности (интересно, блин, почему?)
Делаем RAG-ассистента, человек задает вопрос, мы что-то ответили. Ответить можно миллионом способов, верифицировать нельзя. Здесь обычно делают так:

а) Вырабатывают продуктовые критерии "а что такое хороший ответ"? Наш RAG-ответ должен быть релевантный, достоверный, актуальный.... Записывают эти критерии в виде инструкции.

б) Учат кого-то размечать ответы по этим критерии. Кого можно учить?

Размечаем людьми

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

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

LLM-as-a-judge

У нас нет денег/времени работать с людьми. Делаем LLM, которая оценивает ответы другой LLM. Критиковать чужой труд всегда проще :)

Обычно делается в несколько этапов

1) Собираем датасет правильных оценок. Это когда у разных ответов LLM проставлены метки: релевантный ли там ответ, достоверный ли ответ и тд. Здесь важно получить не очень большой, (можно 100 примеров) но чистый набор данных.

2) Записываем все наши продуктовые критерии в виде промпта. Он может быть очень длинным, нестрашно.

3) Итеративно меняем модель, промпт, метод генерации и тд, чтобы сделать максимальную точность на датасете 1) Обычно используют максимально большие рассуждающие модели.

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

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

- Подробный гайд методи оценки качества в LLM

- Наглядная статья с примерами кода для LLM-as-a-judge

- Туториал, как делать LLM-as-a-judge


Правильные метрики — залог вашей счастливой и активной LLM-разработки. Отнеситесь очень внимательно. А если в чем-то сомневаетесь — пишите в комментарии или в личные сообщения @seva_batareika

#llm_system_design

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

Чувствую себя челом из твиттера, у которого очень много важных умных мыслей.
Надо что ли текстовый блог где-то еще вести?

Сколько ИИ-агентов нужно для счастья?

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

В чем идея?

Обычно, любые сложные процессы это синтез разных действий: сначала что-то почитал, потом понял, что прочитал, потом написал про это пост в тг… (а уже и GPT5 вышла)

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

Почему это почти всегда плохая идея

Тут 2 проблемы:

1) У всех агентов разный контекст. Каждый не в курсе, что делает другой. Есть риск, что агент-тестировщик пошел тестировать код, который агент-кодер уже признал легаси.

2) Так как контекст разный, вам придется делать какую-то синхронизацию. Дейлики для ИИ-агентов. Это и в реальном мире неприятно, ИИ-мир к такому не готов.

Когда это очень полезно

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

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

Нудный вывод

Не нужно пытаться напихать в проект побольше агентов.

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

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

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

Зачем тут мультиагенты?

Например, задача: "найти 100 конкурентов, выписать их выручку и позиционирование" (McKinsey на этом моменте напряглись, их хлеб). Человек пойдет задавать 200 тысяч запросов, переваривать тонну информацию, а потом долго писать отчет. Очень дорогая задача.

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

Дизайн архитектуры

Мы делаем систему с супер простой координацией агентов:

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

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

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

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

Оценка качества

Ровно так, как рассказывал старина Сева.

1) LLM-as-a-judge на различные свойства: достоверность ответа, точность цитат полнота, качество источников.

2) LLM-ки ловили не все кейсы, так что частично оценивали людьми.

Коллеги выложили промпты всех 3-х агентов лид, субагент, цитирование.
Очень наглядная статья, просто бери и делай по аналогии.

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

#ai_cases

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

Правило 8. Сначала делайте прототип

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

Почему нельзя сразу в бой

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

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

Что такое прототип

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

Прототип обычно создается на какой-то удобной платформе, типа n8n. Там мы используем самые мощные модели, чтобы получить как можно быстрее ожидаемое качество.

Когда мы сделали прототип, мы переходим на следующий этап. Техническая команда, сохраняя его качество, снимает все другие ограничения. Например, ускоряет модели.

Как создать прототип по шагам

1) Выделенная команда. В ней точно должен быть продакт-менеджер, который понимает, что хочет, бекенд разработчик и специалист, который уже собирал ИИ-системы.

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

3) Метрики качества на тестовой выборке. Подробнее в прошлом правиле.

4) Итерации на этой выборке, которые максимизируют качество. Итерации вида:
- Взяли самые большие и дорогие модели.
- Провели анализ проблем по выборке. Записали их в эксельку
- Подумали, как это чинить. Покрутить промпт, разбить на подзадачи, добавить RAG и тд.

По этой методике реально собрать рабочий прототип за несколько недель.

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

- Статья известнейшего специалиста (моя), в ней про это раздел.

- Гайд по быстрым итерациями. Это все нужно использовать на прототипе.

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


#llm_system_design

Урок по внедрению AI на полмиллиарда долларов

Меня один пример провала учит в 100 раз лучше, чем 100 историй успеха. Разберем классический кейс 2021 года: как IT-гигант Zillow потерял полмиллиарда долларов на AI-алгоритме.

Спойлер: проблема была вовсе не в алгоритме.

Контекст

Zillow — это медиа-платформа о недвижимости с оборотом $2.4 млрд. Это синоним поиска дома в США. Одна из ключевых фишек — "Zestimate": модель ИИ, которая предсказывает стоимость недвижимости.

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

Что же может пойти не так? :)

Модель систематически переоценивала стоимость приобретаемых домов, в то время как компания агрессивно наращивала закупки. В итоге Zillow была вынуждена продавать дома с огромным дисконтом, получить $500 млн прямого убытка, закрыть программу и уволить 25% штата.

Реальная причина провала

Обычно этот кейс приводят как пример технических проблем модели: не учли сезонность, экономический тренд, забыли положить нужные сигналы в модель. Я с этим на 100% не согласен.

Главная ошибка: Zillow использовали ИИ не чтобы улучшить свой бизнес, а чтобы сделать другой бизнес.

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

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

Сейчас я доделываю "12 правил внедрения LLM", но я совсем забыл правило 0: Встраивайте ИИ только в те процессы, которые вы досконально понимаете без него.

Сначала — понимание бизнеса и его точек роста. Затем — усиление узких мест с помощью AI. Никогда наоборот.

Пишите свои мысли в комментариях. Если есть вопросы, всегда можно задать в личке @seva_batareika

Купить интеллект из коробки

Очень хочется купить подписку на интеллект. Такую коробку, которую ты поставил рядом с бизнесом, и она сразу цену коробки стала отбивать.

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

Отчет MIT о причинах провалов в AI

MIT выпустил отчет о состоянии внедрения генеративного AI в бизнес. Ничего хорошего, естественно, там нет: энтерпрайз массово закупает продукты, но всего 5 % из них достигают значимого экономического эффекта, профит от 95 % закопан где-то на слайдах. Почему так происходит?

По результатам исследования, 90 % сотрудников не доверяют свои объемные рабочие задачи ИИ. Топ-1 барьер: система не учится от нашего фидбека.

Цитата одного юриста из исследования, дословный перевод:

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

Лучше и не скажешь.

Правда, в конце отчета они тоже говорят, что вот ИИ-агенты, вот это топ тема… Спишем это на текущую конъюнктуру.

Интеллект = Адаптация

Я за 8 лет работы с ИИ ни разу не видел рабочего и на 100 % коробочного решения. Всегда нужно что-то учесть под конкретный продукт.

Делаем поиск: «а что по этому запросу хочет наш пользователь найти? Ему здесь важнее цена товара, популярность, новизна?

Делаем суммаризацию отзывов: «а что в этом отзыве для нас самое главное? Что пользователь безумно рад товару или что доставка опоздала на 30 минут?

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

Как внедрять AI

Сначала прогнать от себя мысль, что AI это SaaS. Купил и сразу работает. Покупать можно и нужно. По тому же отчету MIT, компании, которые интегрируют AI вместе с партнером, в 2 раза более успешно его внедряют.

Но AI это скорее платформа. Вы покупаете систему, с которой вам нужно будет пройти последнюю милю. Покупаете у того, с кем вы хотите ее пройти.

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

И, конечно, обучение сотрудников. Как применять, как давать этот фидбек, как оценивать качество.

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

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

Друзья, я тоже рад вашему фидбеку. Обязательно пишите ваши мысли или вопросы в личные сообщения @seva_batareika или в комментариях.

Как скинуть обработку тысяч документов на LLM. Кейс Uber.

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

Можно все эти PDF-ки разгребать руками, а можно попросить это сделать LLM, как сделали коллеги из Uber. Давайте разберемся с этим кейсом.

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

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

По шагам:

1. Взяли PDF-ку, сделали из нее картинку, чтобы дальше применять CV-модели
2. Накатили на нее OCR-модель. Распознали текст.
3. Взяли текст, извлекли из него все нужные поля LLM-кой
4. В красивом интрфейсе показали сотруднику извлеченные поля. Он ОКает, либо правит (наш любимый human-in-the-loop)

Самой проблемной точкой мне видится связка OCR + LLM. На шаге OCR уже может накопиться большая ошибка. Можно сразу делать VLM. Например, вот дообученный qwen, который по картинке документа текст распознает. Или, например, VLM Gemini сразу умеет работать с PDF .

Какая LLM под капотом?

Пробовали дообучать опенсорс и просто промптить GPT-4. Удивительно, но промптить GPT-4 оказалось сильно лучше.

Вообще, довольно сложно на опенсорсе победить OpenAI на широких задачах, вроде разработки кода. Но в задачах типа выделение именованных сущностей, классификации это обычно довольно просто (вот пруф).

Странно, что у коллег не получилось. Хотя, они использовали довольно слабые опенсорс модели, вроде Flan T5. Надо было на дипсике пробовать 🙂

Результаты

На первый взгляд, все благополучно. Средняя точность около 90%. В 2 раза сократили ручную обработку документов и на 70% сократили среднее время обработки.

Теперь чуть-чуть подумаем. Допустим, у Uber тысячи поставщиков. И есть целый отдел, не знаю, из 15 человек, который только обработкой счетов и занимается.

Такой проект LLM-автоматизации, если делать все с нуля (и сразу хорошо), делать несколько месяцев отдельной командой инженеров. Как думаете, он окупится?

Что нужно изменить

Перетаскивать это все на платформу. AI-команда не должна делать один проект по автоматизации только обработки счетов. Вы так деньги никогда не отобьете.

AI-команда делает платформу по автоматизации. Там должны быть инструменты: как писать промпты, как оценивать качество, как собирать датасеты, как потом это деплоить и мониторить качество.

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

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

#ai_cases

Как сделать LLM лучше OpenAI, потратив всего 8 долларов

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

Статья, как дешево и сердито дообучать опенсорс

В статье коллеги взяли 31 NLP задач, в которых есть обучающая и тестовая выборки. Взяли 10 опенсорс LLM. Дообучили эти модели под все задачи, получили 310 новых LLM.

В итоге эти модели оказались в среднем на 10% лучше, чем GPT-4. При этом по числу параметров они в 1000 раз меньше. Обучали модели с помощью LORA, но это неважно, аналогичный эффект получился бы с чем угодно.

Такое дообучение еще и очень дешевое, потому что обновляет не модель целиком, а обучает только адаптер. Одна модель авторам обходилась примерно в 8 долларов.

Как это возможно?

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

Невозможно победить на широких задачах. На задачах, где надо одновременно много всего знать и уметь. Например, чтобы решать бенчмарк MMLU, своеобразный ЕГЭ для LLM, надо знать кучу фактов. Или для генерации кода надо знать синтаксис и уметь им оперировать для кучи различных ситуаций.

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

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

Но вы то не все.

Алгоритм, как правильно дообучать опенсорс

1) Проверьте, точно ли вам не нравится жить на промпте к чужой модели. Например, дорого или не хочется отправлять данные в чужую API.

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

3) Первая итерация — Supervised Fine Tuning (SFT). Модель учится воспроизводить правильный ответ. Возможно, этого хватит и дальше лезть не придется.

4) Вторая итерация — Reinforcement Learning (RL). Модель награждают за хорошие ответы и ругают за плохие.

Дообучать можно адаптеры (LORA и ее друзья) или полным дообучением. В зависимости от количества данных.

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

Будьте рациональны.

Не надо дообучать модель в любом LLM-проекте. Проверьте, чаще всего все прекрасно работает на промпте + RAG. Тогда сильно сэкономите нервы.

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

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