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

Вокруг LLM очень много мистификации. Мол, только особенные люди после специального образования, где их учили мудрые наставники, могут освоить таинство работы с LLM. Я уверен, что это не так. У меня была мечта написать небольшой гайд, с помощью которого любой сильный духом сможет разобраться, как эти LLM нужно использовать в своем продукте. Эта статья – воплощения моей мечты.

В одном исследовании утверждается, что 80% всех ИИ проектов проваливаются. Сам не считал, но думаю, что порядок примерно такой. Давайте вместе попробуем это исправить. 

В этой статье мы не будем разбирать:

• Как с нуля обучить LLM

• Самые свежие научные статьи про LLM

• Как Сэм Альтман поднимает очередной раунд инвестиций в погоне за AGI.

Что мы будем разбирать: как с помощью LLM нанести непоправимую пользу вашему продукту.

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

Кто я такой? Я — Сева, сейчас руковожу внедрением разных LLM в Поиске Яндекса, а вообще 8 лет занимаюсь внедрением моделей в разные продукты. Хочу поделиться этим опытом с вами. 

Статья довольно объемная и состоит из 3 больших частей.

1. Куда и зачем внедрять LLM?

2. Стратегия

3. Тактика

В конце будет список литературы для домашней работы. Поехали!

Куда и зачем внедрять LLM?

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

• Поиск

• Рекомендации товаров в маркетплейсах

• Рекомендации друзей в социальных сетях

• Таргетированная реклама

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

Что у нас с деньгами? Я очень люблю вечерами смотреть отчеты McKinsey, потому что они всегда безумно красивые. В отчете 2023 года приведена диаграмма, сколько денег в мировую экономику может привнести генеративный ИИ дополнительно к классическому. Классический пока сильно больше.

Но голубой столбик год к году будет прибавлять в весе, это я вам обещаю. 

А чем LLM отличается от обычных ИИ моделей? Напишем основные отличия:

1. Взаимодействие с моделью через текст 

   LLM обучается через задачу предсказания следующего слова (более подробно посмотрите лекцию тут). Благодаря этому с LLM можно поговорить: можно ввести текст на вход (далее мы будем называть этот текст “промптом” от англ. “подсказка”), LLM предскажет продолжение, то есть ответит вам тоже текстом. 

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

2. Обобщаемость

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

   Самое важное, что LLM прекрасно справляется с задачами, которые она даже никогда в глаза не видела. В статье, где сравнивали ChatGPT с другими моделями по 140 различным задачам, она часто идет вровень с моделями, которые всю жизнь учились только одной специализированной задаче.

   За счет чего LLM это удается? Здесь 2 фактора успеха. LLM обучается в парадигме Self Supervised Learning. В этой парадигме модель учится на широкую задачу, после чего ей проще дается сразу набор более узких (про это у меня есть один анекдот пост). Во-вторых, используют огромные вычислительные мощности, которые заставляют работать законы масштабирования. Про масштабирование LLM я подробно писал в прошлой статье. Почитайте, она правда классная. 

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

3. LLM дороже.

   LLM дороже любого ИИ, который был раньше. Все из-за буквы “L – Large” в аббревиатуре Large Language Models. Их дороже обучать, они больше едят GPU в работе. 

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

И еще немного про стоимость LLM.

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

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

Это все приводит к тому, что в США идет всем ходом внедрение LLM в малый бизнес. Harvard Business Review пишет, что с выходом ChatGPT заказы на написание текста упали уже более чем на 30%. Более подробно я писал в этом посте. 

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

• Любой R&D

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

• Работа с клиентом

  В моем широком смысле это волшебная тройка: маркетинг, продажи, поддержка. LLM рассылает email, потом общается с лидом и в итоге отвечает на его вопросы, когда он стал клиентом. Подробнее про это статья. Здесь можно и нужно делать по-настоящему персональный LLM-сервис, который подстраивается под каждого клиента. 

• Автоматизация внутренних бизнес процессов

  Это главная тема любителей раундов инвестиций. Здесь ценности от ИИ сразу две:

  • Экономим деньги и (возможно) увеличиваем качество решения задачи

  • Делаем более масштабируемый бизнес

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

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

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

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

Стратегия

Команда внедрения LLM?

Самое важное, что вам нужно понять: с каждым днем ИИ делать все проще и проще.

Раньше модели могли делать только математики. Никакой кодовой базы не было, все обучение писали сами. С полного нуля. Как производную насчитал, так модель и обучил. Вход в индустрию был довольно высок. Сейчас все стало сильно веселее. Огромное число умников побежало делать ИИ. И корпорации, и опенсорс. У нас есть куча API к моделям , куча моделей в опенсорсе, огромное множество библиотек обучения, куда нужно только вставить ваш датасет. 10 лет назад у нас был только ранний tensorflow и scikit-learn. 

В таком многообразии уже не так важно, как вы берете производные. Гораздо важнее 2 других навыка.

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

2. Умение писать хороший код. Любой ИИ это в первую очередь разработка. Это код для собирания и валидации данных, регулярного обучения модели, код сервиса, который использует модель и еще код и еще код…

На стыке ИИ-практики и разработки возникает профессия AI-engineer (ИИ-инженер, если по-нашему). Который и в моделях современных неплохо ориентируется и без особых багов их внедрит.  

Стать таким человеком можно 2 разными путями. 

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

2. Стать неплохим разработчиком, а затем осваивать этот самый ИИ, постепенно работая все с более сложными моделями.

Оба варианта рабочие. Проверено на практике.

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

Частая проблема ИИ-проектов – оторванность команды от продукта. 

Допустим, мы делаем LLM для автоматизации колл-центра. Хотим собрать данные, где на фразы пользователей есть правильный ответ, чтобы на этом обучить LLM. А какой, кстати, ответ правильный? Что надо ответить, когда клиент жалуется на плохую услугу? Можно тут дать скидку? А если клиент угрожает уйти к конкуренту? А если, а если, а если… 

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

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

Что они должны делать технически:

1. Отвечать за постановку бизнес задачи: зачем мы это делаем?

2. Делать продуктовое описание, какой выход ожидается от системы для разных входов и как это связано с первым пунктом

3. Следить, что разметка данных не противоречит второму пункту

4. Следить за качеством продукта

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

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

Быстрые итерации

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

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

Мы наняли пачку ИИ-инженеров. Прикинули, что нашей фичей будет пользоваться минимум 10к пользователей, купили железо. Данных у нас, конечно, нет, будем 3 месяца их размечать. Спустя полгода начали учить модель, улучшать архитектуру и тд. В процессе работы поняли, что наша первоначальная гипотеза ошибочна: продукт на бизнес метрику слабо влияет. В итоге через год у нас офигенный продукт, который правда  никому нафиг не нужен, но все вынуждены притворяться, потому что жалко признаться себе.

Это плохой расклад, и частая причина провалов. Надо делать строго не так. Благодаря LLM нам доступны быстрые итерации. Я это называю prompt driven development:

1. Придумали идею, которая должна приносить профит

2. Проверили на промптах к самых дорогих/крутых моделях. Без ML-только промпты. 

3. Проверили оценку/cusdev решения. Если не качает – идем в пункт один

4. Иначе начинаем пилить модельку, нанимать инженеров и т.д.

Еще раз. Никаких инвестиций в разработку, пока не доказали ценность.

Вам очень важно, чтобы в написании промптов были затянуты те самые бизнес-эксперты/продакт менеджеры. Не переживайте, что они не справятся. Подбирать промпт это примерно тоже самое, что объяснять, что нужно делать человеку, который вас не очень понимает. Этим менеджеры занимаются всю карьеру. Нужно прочитать ровно 1 туториал по промптингу. Например, этот (тут даже больше, чем нужно).

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

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

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

• Дистилляция

• Квантизация

• Кэширование промпта

• Спекулятивный декодинг

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

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

Главное правило: если вы понимаете, что хотите сделать, вам нужен всего один человек, который знает как. Если вы не понимаете, что вы хотите, вам не поможет никто. 

Гибкость против кастомизации

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

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

Нагляднее всего от этого страдают стартапы. Стартап выбрал какую-то нишу, которую пока не может решить базовая модель из коробки. Например, что GPT-9 плохо пишет на Python. Поднял раунд, начал пилить PythonGPT. Пока пилил, OpenAI зарелизил новую GPT-10, которая уже прекрасно пишет на Python. Все расстроились и закрыли стартап. Про возможное решение этой проблемы я писал тут. 

Как раз для стартапов Сэм Альтман давал такой проверочный вопрос:

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

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

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

Не пытайтесь обогнать лучшие лаборатории мира. Стойте на их плечах.

Тактика

Существует целый класс задач, в которых очень просто сделать демо, но невероятно сложно сделать настоящий продукт.  (Андрей Карпатый)

Мне кажется, почти все задачи в ИИ попадают в этот класс задач. Прототип автономных машин создавали еще в 90-х годах. Они ездили по настоящей дороге, могли иногда поворачивать. Наверное, иногда бибикали. Прошло 30 лет с тех пор, а автономные машины все еще массово не выехали на трассы. 

Как оценивать качество

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

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

Всего есть 3 варианта измерения качества LLM: тесты, оффлайн метрики и AB эксперимент. 

Тесты

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

Например, так можно проверять формат ответа модели. Если вы в промпте договорились с моделью, что она выдает json вот с такими полями, вы должны проконтролировать, что ваш контракт модель не нарушила. 

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

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

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

Но нам этого мало. 

Метрики качества

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

В LLM есть 2 вида задач. Задачи, в которых можно написать примерно правильный ответ и в которых нельзя. 

К первому классу относятся, например, задача классификации текста. Здесь вы можете получить предсказание класса от LLM и сравнить его с правильным классом, затем рассчитать точность/полноту и тд. Легче легкого. 

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

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

Для таких задач существует 2 варианта построить метрику:

1. Разметка людьми.

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

2. Разметка моделью.

   Вы вместо людей используете модель. Чаще всего LLM, поэтому этот подход часто пафосно называется LLM-as-a-judge. Суть проста: мы подаем ответ тестируемой модели на вход в новую LLM и просим оценить ее, хороший ответ или плохой. Почему это работает? Как правило, понять хороший ответ или нет, сильно проще, чем написать этот ответ. Основная проблема этого метода: LLM, которая оценивает, тоже нужно как-то оценивать, что она все делает правильно. Внезапно! Это можно сделать только людьми. Опять нашими бизнес экспертами. Основные правила, как это делать, отлично написаны тут

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

AB эксперимент

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

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

Как улучшать качество

Мы научились мерить качество. Вот теперь мы готовы его улучшать.
Есть всего 3 рабочих инструмента.

1. Подбор промпта – когда хотим базово объяснить модели, что от нее хотим 

2. RAG – когда хотим вложить в модель новые знания

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

Ну и их любая комбинация. Сейчас про каждый инструмент поподробнее. 

Промптинг

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

Что такое промпт? Это интерфейс к языковой модели. Этот интерфейс принимает на вход человеческий язык. В промпте вы должны по полочкам изложить, что вы хотите, чтобы модель сделала. 

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

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

Вам часто дают советы, либо которые работали случайно у одного человека, либо  которые работали в каких-то отдельных версиях моделей OpenAI. Например, когда-то был популярен “лайфхак” писать в промпте, что дашь модели 100 баксов за правильный ответ.  Если вы до конца не поняли, что это бесполезно в долгосроке, перечитайте раздел “Гибкость против кастомизации”.

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

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

Важно. Подбирая промпт, смотрите на метрику качества, как написано в разделе “Как оценивать качество”. Без контроля качества подбирать промпт не имеет смысла. 

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

2. Будьте конкретны в формулировках и оценках. Не пишите “сделай короткое сообщение”, пишите “сделай сообщение не длиннее 100 слов”.

3. Дайте модели порассуждать. Рассуждение часто приводит к более хорошим результатам. Просите порассуждать в промпте (это называется Chain-of-Thought) или используйте рассуждающие модели, как o1.

4. Показывайте модели примеры с правильными ответами (это называется Few-Shot промптинг). Можно снабдить примеры цепочкой ваших рассуждений, чтобы модель поняла, как именной ей стоит рассуждать.  

5. Заставьте модель отвечать структурированно. Явно пропишите поля, (например, в json-формате) которые модель должна вернуть. Это поможет модели лучше понять, что от нее хотят, и еще вам будем проще парсить ее ответ. Все в выигрыше. Кстати, современные API умеют контролировать формат ответа, заставляя модель выдавать нужный вам json. Очень удобно, рекомендую. 

6. Не плодите монстр-промпт. Здесь все тоже самое, что в программировании. Если у вас сложная задача, в которой нужно много чего сделать, то не нужно делать 1 промпт, который делает сразу все. Разбейте задачу на подзадачи, каждую подзадачу выполните отдельным промптом, а затем результат сагрегируйте финальным промптом. Разделяй и властвуй.  

RAG

RAG (Retrieval Augmented Generation) – это подключение LLM к внешней базе знаний. Это основной способ внести в LLM знания, которая она не получила во время своего обучения, но которые очень нужны для решения вашей задачи. 

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

Тут то мы и понимали, что ваша задача распадается на две: поиск релевантной информации и генерация ответа по найденной информации. 

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

1. Это будет очень дорого. LLM очень вычислительно неэффективно обрабатывает длинные контексты (подробнее прочитайте тут)

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

Обычно архитектура RAG выглядит так:

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

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

3. Поиск топ-к релевантных чанков текста. Здесь часто подразумевается использование какого-то “семантического поиска похожих векторов”, хотя это вообще не обязательно. Часто классический текстовый поиск, вроде моделей BM25, дают очень неплохой результат. 

4. Генерация с использованием топ-к текстов. Здесь все очевидно – просим LLM, опираясь на текст, ответить на вопрос. 

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

Плохой поиск

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

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

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

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

2. Обработка запросов. Делайте так, чтобы запрос был максимально понятным

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

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

Про поиск стоит отметить одну вещь. Чем круче LLM, тем длиннее контекст, который она может обрабатывать. Посмотрите на рисунок ниже: GPT-4o сильно медленнее деградирует при росте размера контекста, чем GPT-4o mini. Значит, следующие модели будут еще лучше работать с длинным контекстом. Это позволит засунуть в них еще больше информации, упростив поиск. И так будет продолжаться и дальше и дальше, пока мы целые книги в LLM не будем вгружать. Тогда можно вообще без поиска общаться с LLM про эту книгу. Gemini уже хвастается о 2-миллионном размере контекста. Дальше будет круче.

Галлюцинации

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

1. Явно опишите в промпте, что надо отвечать только по информации, которая есть в промпте

2. Покажите, что если информации нет в контексте, нужно отвечать “Не могу ответить на ваш вопрос”

3. Используйте другую LLM, которая покритикует ответ первой LLM и поищет там галлюцинации.  Посмотрите вот эту статью – поможет вдохновиться. 

4. Понизьте температуру генерации до 0, модель будет сложнее придумать.

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

Дообучение

Здесь вы начинаете менять уже параметры модели. Вы формируете свое обучающее множество из входных данных и ожидаемых LLM ответов. Дальше дообучаете уже обученную кем-то LLM на вашем датасете. 

До прихода LLM это, вообще говоря, был единственный вариант работы с моделями. Никакой промптинг или RAG из коробки не заводился.  

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

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

На узкой задаче вроде классификации на 2 класса так и будет. Маленькая, но обученная на целевых данных модель будет разрывать GPT-4o по всем метрикам классификации. Но чем шире задача, чем более разнообразные проблемы модель должна решать, тем сложнее вам будет подобрать датасет и правильно обучить модель. 

Дообучение позволяет подстроить модель под нужный формат (стиль) ответа, когда этот формат сложно или вообще невозможно задать в промпте. Например, если вы хотите генерировать текст карточки товара, который оптимизирует CTR. Какой там должен быть промпт? Я тоже не знаю. 

Дообучение сильно дороже, чем подбор промпта. Вам нужны доп. GPU. сбор датасета и знающие люди, которые могут это дело обучить. Разломать модель очень просто, я делал так сотни раз.

Проблему со стоимостью частично решают peft-методы дообучения. Это вы обучаете не всю модель, а только небольшое множество параметров. Это сильно экономнее по GPU. Однако, на практике часто работает хуже, чем полное дообучение. 

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

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

Резюме

Что я хочу, чтобы вы усвоили из этой статьи: 

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

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

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

• Будьте помешаны на контроле качества ваших моделей. Это поможет вам прийти в нужную точку. 

• У вас всего 3 ручки улучшения LLM. Запомните, когда какую стоит использовать.  

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

На самом деле, не так уж и сложно было. Если остались вопросы – обязательно пишите в комментариях. Постараюсь на все ответить.

Об авторе

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

Там много полезного про внедрение LLM. 

P.S. Огромное спасибо за редактуру Юлии Булгатовой.

Список дополнительной литературы

1. Лекция Andrew Ng про возможности LLM, которых у нас раньше не было. Один из моих любимых лекторов, всегда очень доступно. 

2. 39 умных мыслей о внедрении ИИ. Под большей частью я готов подписаться. 

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

4  Видео курс по внедрению ИИ в бизнес. Не только про LLM.  

5. Статья, почему важно быстро итерироваться и как это делать.

6. Обзорная статья, почему для LLM так важно уметь оценивать качество. Многое мы уже раскрыли здесь, но не все. 

7  Доклад, про стратегию внедрения LLM. Рассказывается и про команду, и про оценку качества. 

8. Очень подробная статья, как делать LLM-as-a-judge. В том числе рассказывается, как обучать таких оценщиков. 

9. Полезные советы, как улучшать RAG. 

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