А мы внедрили GenAI!

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

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

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

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

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

Хочу отметить момент: до сих пор вообще ни слова про ЛЛМ (И часть из проблем мы действительно решили без ллм вообще). Инженерные решения начали появляться уже на следующем шаге - где на каждый блок проблем собралась команда инженеров продактов аналитиков и операционных ребят (это кстати было must), которые продолжили углубляться в уже отдельные проблемы и тестировать решения. Там работало много команд в параллель, и успеха достигали те, кто:
- инвестировал в быстрый фидбек луп (качественные офлайн метрики/удоьные быстрые а/б)
- упаривался в работу с данными больше чем в работу с алгоритмами
- стараются не сломать сильные стороны текущего решения, но улучить слабые стороны.

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

Рассказывать, что конкретно принесло больше денег контекстуальный классификатор, тулы для операционки, раг, n8n-like workflows или агенты с тулами особенно смысла нет. Просто потому что в вашей системе все может дать совсем по другому.

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