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

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

Кто такой сильный LLM-инженер?

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

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

По-хорошему, LLM-инженер должен подключаться уже на этапе бизнес-анализа. Я не имею в виду, что инженер должен делать бизнес-анализ, но он должен консультировать бизнес аналитика как написать TO BE процесса.

Дело в том, что в LLM-продуктах часть требований, которые выглядят как обычная бизнес-логика, на практике оказываются техническими: маршрутизацией, fallback-сценариями, ограничениями модели, уровнем уверенности, edge cases.

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

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

Нужны ли промпт-инженеры?

Чтобы ответить на этот вопрос, давайте разберёмся, в чём заключается работа промпт-инженера.

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

Все эти сказки о том, что LLM пишет промпты лучше человека, работают ровно до тех пор, пока контекст проекта помещается на пяти страницах А4.

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

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

Окей, промпт-инженеры нужны. Но какими навыками они должны обладать?

Однозначного ответа нет, подходы у компаний разные. В Сбере на такую позицию требуют базовое понимание системного анализа, в Точка Банке основы Python, а в Альфе, насколько понимаю, роль промпт-инженера рассматривают ближе к бизнес-аналитику, и в этом тоже есть логика.

Звучит заманчиво, чтобы промпт-инженер мог сам описывать интеграции или прописывать тесты промптов. Но нам понятно, что системные аналитики или разработчики, даже уровня junior, не будут переходить в промпт-инженеры: для них это будет восприниматься как шаг вниз по карьерной лестнице. Поэтому на такие роли приходят не технари, а те, кто подготовились под собеседования и освоили нужный минимум. Так что СА/тесты на хорошем уровне всё равно не будет сделаны.

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

Какую архитектуру выбрать?

Агенты, агенты, агенты…Сейчас все говорят про агентов. Но для начала стоит договориться, что мы вообще называем ИИ-агентом.

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

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

Некоторые заказчики хотят, чтобы LLM-решение внедрялось именно в виде агента. Но это не всегда нужно — иногда лучше работает детерминированный flow. У многих сотрудников есть чёткий алгоритм действий и они не думают: «А как лучше сделать эту задачу?», они должны сделать её так, как это записано в регламенте. И если мы оптимизируем работу такого сотрудника (а большинство LLM-проектов именно этим и занимаются), то, конечно, мы должны делать это через детерминированную цепочку.

Объясню на упрощенном примере с роботом, который моет посуду. 

Он должен:

1 — взять посуду из зоны A.
2 — помыть.
3 — положить посуду в зону B.

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

Но у детерминированного flow есть своя цена — хрупкость. 

Например, наш робот должен был мыть только тарелки, но бизнес изменил требования и теперь ему также приносят стаканы. Робот берет их в работу, но моет как тарелки — только снаружи. Мы делаем фикс, теперь робот моет стаканы изнутри, но иногда пытается помыть изнутри и тарелку и т.д. и т.п. Поддерживать и развивать такие системы изнурительно.

Также если детерминированный flow не сработал, его невозможно НИКАК переиспользовать в других проектах. Поэтому перед началом реализации такого flow важно убедиться в двух вещах: у задачи есть оптимальная траектория решения, и вы можете разложить её на понятные шаги.

Что оптимизировать в последнюю очередь?

Стоимость и скорость агента вторичны.

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

Ведь если качества нет, вы просто выдаёте плохой результат. Какой смысл в том, что вы делаете это быстро и дёшево?

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

Со скоростью сложнее, но её можно компенсировать продуктово: заранее запускать агента, менять UX, например, не показывать в очереди задачу, пока не придёт ответ от агента.

Какое качество реально достижимо?

Правило 90%

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

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

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

Пример для автоматических ответов в контакт-центре:

Клиент пишет: «Войти в кабинет»

Система работает по цепочке:

1. Переписывание вопроса пользователя — 95%. Преобразуем вопрос пользователя в более точный поисковый запрос для базы знаний: «Не могу войти в личный кабинет»

2. RAG / поиск по базе знаний — 80%. Ищем релевантную инструкцию в базе знаний.

3. Финальный ответ пользователю — 99%. Формируем понятный ответ на основе найденной информации.

Общее качество всей цепочки считается как произведение качества каждого шага:

0,95 × 0,80 × 0,99 = 0,7524

Мы видим, что главная проблема — в RAG: часть нерелевантных фрагментов получает высокое векторное сходство и попадает в ответ.

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

Значит ли это, что теперь будет 100% правильных кейсов? Нет. Мы не покрыли все случаи на которых RAG плохо работает, а оркестрация отсекает часть кейсов, но сама тоже ошибается. Мы не получаем идеальную систему, а добавляем ещё один шаг со своим качеством.

С оркестрацией

Оркестрация отсекается часть кейсов, с которыми RAG работает плохо. Поэтому качество RAG на оставшихся обращениях становится выше.

Например, раньше RAG работал на 80%, а после фильтрации оркестрацией RAG работает на выбранных кейсах, например, на 89%. Почему не на 100%? Потому что наш стоп-лист это только срез данных. Также наша оркестрация работает тоже со своим качеством, допустим 95% .

Тогда качество всей системы будет:

95% × 95% × 89% × 99% = 79,52%

Выбор метрики

Я недавно слышал такую защиту проекта:

«С помощью внедрения LLM в этот процесс мы снизим время работы сотрудника, уменьшим количество ошибок и повысим удовлетворённость клиента».

Но эти метрики работают как сообщающиеся сосуды.

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

• Сокращаете время обработки — растёт риск ошибки.

• Хотите повысить удовлетворённость клиента? Время обработки, скорее всего, вырастет.

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

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

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

За какие проекты лучше не браться?

Представим кейс — для продактов внедрили автотранскрибацию созвонов, можно сделать follow-up, написать задачу в Jira. Допустим, нам получилось доказать, что каждый сотрудник с этой фичей экономит 15 минут в день. Как-будто бы мы получили потрясающий результат.

Но давайте посчитаем сколько мы сэкономили для нашей компании. Умножаем стоимость часа работы продакта на 5 часов сэкономленного времени в месяц, перемножаем на количество продактов в компании и получаем «Нисколько».

Продакт — это высокооплачиваемый сотрудник, у него нет чёткого SLA на задачу. Если у него освободилось 15 минут, это не значит, что он их использует. Он выкурит на одну сигарету больше и всё.

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

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

А что насчет тех у кого есть SLA, там хорошо работает внедрение LLM? 

LLM-проекты для сотрудников с SLA

Для работников с SLA внедрение LLM работает отвратительно.

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

Вы можете внедрять copilot или полную автоматизацию. Copilot в переводе с английского «второй пилот», и его смысл в том, что мы даем пользователю текстовый комментарий о том, как можно поступить в данной ситуации, но решение остаётся за человеком.

Когда вы внедряете copilot для сотрудников с жёсткими нормативами, возникает много проблем, главная из них — ОЧЕНЬ сильная пользовательская привычка. Они вообще-то на потоке обрабатывают одни и те же задачи, многие сотрудники просто забывают про эти подсказки.

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

То есть мы в привычный пользовательский путь мы добавляем один шаг и считаем что этим сократим время на обработку задачи?

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

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

За какие же проекты мы возьмемся? 

Хороший LLM-проект — тот, где есть большой и дорогой кусок работы, который можно либо автоматизировать целиком, либо заметно его сократить. При этом процесс должен позволять ошибаться каждую 10 генерацию.

№1. Для сотрудников с жёстким SLA лучше всего искать процессы, которые можно автоматизировать полностью. Очевидный пример — это поддержка. В этом направлении реально приблизиться к качеству ответов около 90%.

Главным ограничением становится CSAT: удовлетворённость клиентов после запуска не должна упасть ниже текущего уровня. Только тогда сокращение нагрузки на операторов можно считать реальным эффектом, а не экономией за счёт ухудшения сервиса.

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

• сначала экспертно определить самые сложные и долгие операции;

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

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

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

№3. Для дорогих сотрудников подходят copilot, но только для отдельных больших задач. Нужно искать задачу, которая занимает минимум несколько часов и имеет понятный результат. Не нужно делать корпоративный Claude — лучше взять конкретный кусок работы, например написание тестов.

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

---

Что ж, на этом всё. Будут вопросы — задавайте в комментариях, я отвечу. А если нужно больше информации, заходите в мой ТГ, у меня там честные заметки про LLM-проекты, агентов и грабли продакшена.