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

AI это мир парадоксов. Мир миллиардов инвестиций и самых быстрорастущих стартапов. При всем этом блеске больше 80% компаний ничего не зарабатывают от внедрения AI и более 80% AI-проектов проваливаются, не дойдя до внедрения. Хотя, мне кажется, что это число сильно ближе к 100%.

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

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

Любой LLM-проект должен последовательно пройти 4 этапа:

1) Бизнес постановка.
Здесь мы формируем целеполагание, какую фичу хотим сделать. На какие ключевые метрики хотим повлиять. Главное: не стоит заранее думать про техническое решение, которое больше всего сейчас на хайпе. Фиксируем бизнес-ожидания от проекта, но технику делаем уже дальше.

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

3) Разработка.
Здесь мы ускоряем прототип, делаем его более дешевым, опираясь на прототип из пункта 2. На этом этапе технические специалисты улучшают LLM: уменьшают в размерах, включают нужные оптимизации, дообучают модель и тд. В итоге этого этапа у нас получается LLM, которая проходит все наши требования, и мы готовы ее использовать.

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

Бизнес постановку сделали. С чего начинать делать прототип? С метрик качества.

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

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

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

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

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

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

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

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

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

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

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

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

1) Изменение промпта
С этого всегда надо начинать. Удивительно, но часто делать больше ничего не надо. Но не стоит здесь сходить с ума и обещать LLM100 долларов за правильный ответ. Есть несколько базовых правил:

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

Все эти техники можно прочитать в учебнике.

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

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

3) Дообучение
Вы собираете данные под вашу задачу. Меняете параметры LLM, чтобы она как можно лучше подстроилась под эти данные.

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

Дообучение сильно дороже, чем 2 предыдущих варианта. Вам нужны GPU, а главное люди, которые умеют обучать LLM, не сломав модель. Часто все проблемы можно решить промтом и RAG. Дообучать модель придется максимум в 10% случаев.

4) Инструменты
Странно просить LLM в уме умножить два трехзначных числа. Логичнее научить ее пользоваться калькулятом, и пускай она умножает. Как ее научить?

Нужно в промпте написать, что если ей нужно воспользоваться калькулятором поставь какой-нибудь специальный символ. Например CALC(2224 * 654). Дальше, если модель выдала такой символ, мы вызываем настоящий калькулятор, считаем выражение и в следующей реплике нашего диалога передаем результат калькулятора.

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

5) Агентность
Ранее мы жестко определяли, как должна действовать LLM. Мы могли разбить задачу на подзадачи (LLM-workflow), написать для каждой промпт, но мы точно определяли последовательность всего процесса. LLM делала сначала одно действие, затем другое и делала ровно так, как мы попросили. Многие бизнес-задачи так и устроены, что для них такую последовательность можно задать. Но для некоторых нельзя.

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

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

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

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

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

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

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

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

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

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

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

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

4) Итерации на этой выборке, которые максимизируют качество.

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

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

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

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

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

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

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

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

Технически RAG выглядит всегда примерно так:

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

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

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

Кстати, код это самый мощный инструмент, который вы только можете дать LLM (но риски с безопасностью кратно возрастают). LLM может под задачу генерировать правильную программу.

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

Вызов инструментов требует точного заполнения всех аргументов. Нельзя ничего пропустить. Для этого есть механизм Structured Ouput.

Вы выдаете желаемую схему ответа, а LLM не может при ответе ее нарушить. Работает примерно так:

• Ваша схема конвертируется в грамматику
• Генерация каждого следующего токена жестко ограничена этой грамматикой. Считайте, что работает регулярное выражение на выходе модели, которое отсекает все неправомерные токены.

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

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

Есть 2 варианта.

1. Добавить в промпт описание этого инструмента: как его вызывать, какие входные аргументы, что он возвращает
2. Дообучить LLM правильно инструмент использовать. Делать только, если 1-й пункт не сработал. Обычно это нужно, когда инструментов очень много и модель уже плохо понимает из промпта. Про это есть классическая статья.

Есть 2 разных архитектуры LLM-систем, которые отличаются тем, насколько много свободы вы даете системе. Эти архитектуры называются LLM-workflow и автономные агенты.

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

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

Плюсы системы LLM-workflow:

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

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

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

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

Плюсы автономных агентов относительно LLM-workflow:

• Возможность решать задачи, которые сложно описать алгоритмом. Например, помощник разработчика невозможно сделать на LLM-workflow
• Скорость разработки. Здесь мы только пишем инструменты и промпт. Всю остальную работу по решению задачи делает сама LLM.

Минусы:

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

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

1. Агент для разработки кода. Результат работы проверяется системой тестирования.
2. Агент для поиска информации. Агент исследует интернет, составляет отчет. Человек потом перепроверяет.
3. Персональный агент-ассистент. Все рискованные операции, вроде покупки, будут подтверждаться у человека

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

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

2) Через оценку качества
Мы уже строили модель LLM-as-a-judge, которая оценивает качества ответа, в разделе про метрики качества. Мы с помощью этой модели можем оценить качество ответа. Если оно сильно ниже среднего, то ответ стоит исправить.

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

Допустим, критик нашел проблему. Как нам ее исправить?

1) Human-in-the-loop
Мы переводим запрос на человека. Это самый распространенный метод внедрения AI: самые сложные задачи обрабатывают люди, а самые рутинные мы отдаем в LLM. Важно, что примеры, которые переводятся на человека, затем могут быть использованы для улучшения LLM.

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

Если есть возможность, я всегда рекомендую использовать human-in-the-loop даже в небольшом объеме. Так сразу всем будет спать спокойнее.

Можно выделить 3 качества моделей, которые раскрываются с увеличением числа параметров.

1) Знания об мире
По сути модель становится энциклопедией. В своих весах она "запоминает" таблицу Менделеева, законы электродинамики и сколько вышло альбомов Rolling Stones. Чем больше параметров, тем больше информации она может заполнить.

2) Рассуждения
Способность модели генерировать рассуждения и делать на основании них выводы. Этому модели учат специальным этапом обучения. Так, например, делали авторы DeepSeek R1. Маленькую модель сильно сложнее обучить рассуждать.

3) Следование промпту
Насколько модель быстро схватывает, что от нее хотят. Маленькие модели сильнее тупят, приходится больше тратить времени на написание подходящего промпта, чтобы LLM поняла, что от нее хотят.

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

Для многих важных для бизнеса задач, таких как чат-боты поддержки клиентов, написание персонализированных сообщений, выделение главного из отзывов, не нужны гигантские LLM. Можно взять небольшую LLM (1-10 миллиардов параметров) и побороться с проблемой 3. Об этом подробнее в следующем правиле про дообучение.

Дообучать модель стоит тогда, когда модель не слушается вашего промпта. Например, галлюцинирует в задаче RAG. Вы черным по белому написали в промпте: "отвечай только по той информации, что пришла из поиска, ничего не выдумывай", а LLM все равно выдумывает. Чем меньше модель, тем хуже она вас понимает, так что обычно эта проблема возникает не на этапе прототипирования, а уже на 3-м этапе разработки. Эту проблему можно починить дообучением.

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

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

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

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

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

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

• vLLM
• SGLang
• TensorRT-LLM
• llama.cpp
• TGI

Вам нужно только знать о существовании методов оптимизации LLM и не забыть использовать.
Опишем самые важные из них:

1. Батчевание. Группирует запросы в LLM в один пакет (батч) и делает параллельно предсказание сразу для них всех. Важно. Чем больше размер батча, тем более эффективно вы используете GPU, то есть тем больше запросов параллельно может LLM обрабатывать. Но чем больше размер батча, тем медленнее LLM будет отвечать. Выбирайте размер батча, исходя из компромисса пропускная способность/скорость ответа.
2. Квантизация. Представление параметров модели в более компактной форме. Например, параметр 32.4647 мы запишем, как 32.5. Довольно экономно.
3. Кеширование Запоминаем ответ LLM на какой-то промпт. Если нам зададут этот промпт снова, мы возьмем ответ из кеша. Еще есть KV-кеширование, когда мы сохраняем не ответ LLM, а только часть ее слоев (key и value).
4. Спекулятивный декодинг. Используем другую маленькую модель, которая предсказывает несколько токенов, а оригинальная модель верифицирует это предсказание. Оригинальная LLM может поменять его, если не согласна.
5. Более эффективные вычисления. Вычисления внутри LLM можно выполнить огромным числом способов с разной эффективностью. Чаще всего оптимизируют механизм "внимания" (attention). Появляются более эффективные варианты его вычисления: Flash Attention, Paged Attention и тд.

Это последнее 12-е правило, которое рассказывает, как применять все остальные.

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

В AI очень сложно спрогнозировать финальную архитектуру проекта. Любые модели, приемы работают или не работают в зависимости от задачи. Самый рациональный вариант — начинать с MVP, а затем последовательно его усложнять. Как понимать, как именно усложнять? Через метрики качества и анализ проблем.

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

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

2) Смотрим качество ответов на корзинке
Используем разметку асессорами или LLM-as-a-judge, подробнее в разделе про метрики качества.

3) Кластеризуем проблемы
Смотрим на примеры плохих ответов и пытаемся разложить их на кучки. Раскладывать можно по 2 осям: по тематикам (например, вопросы по погоду) и по причинам поломки (например, поиск в RAG ничего не нашел)

Далее решаем каждую проблему по шаблону:

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

Важно. Не пытайтесь тестировать сразу много гипотез, проверяем одну за одной.

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