Как внедрять GenAI в операционную работу

Артём начинал инженером в Parallels, делавшей виртуальные машины, а придя в банк на позицию Head of NLP, обнаружил, что за три года занимался чем угодно, кроме обучения моделей: процессами, product discovery, погружением в бизнес. Александр ставит вопрос выпуска: почему первой автоматизировалась самая интеллектуальная профессия, а работа оператора со скриптом устояла. Артём отвечает, что парадокса нет. Десять-пятнадцать лет назад инженеры разбирались с пейджингом и регистрами и десятилетиями работали над тем, чтобы больше к этому не прикасаться: рантаймы, динамическое управление памятью, интерпретируемые языки. Сам он теперь пишет только на Python, над которым посмеивался, когда учился. Модель учится на сигнале, а вокруг кода собрана целая машина сигналов: компилятор бьёт за синтаксис, линтеры — за уровень выше, тесты — за ошибки логики. Александр вспоминает выступление Дженсена Хуанга: после революции свёрточных сетей стало ясно, что получен идеальный аппроксиматор любой функции, и остаётся понять, какую функцию приближать и где взять данные.

Контрпример — работа продажника: человек набирает номер, включается аппарат чтения эмоций и подстройки под собеседника, но юнит-теста для звонка не существует. База прозвонов конечна, записи застыли во времени, вернуться и сказать фразу иначе нельзя; Александр добавляет, что реализовалась ровно одна трасса, а контрфактических данных нет. Артём соглашается: потратишь базу на один проход градиента — звонить будет уже некому, номера заблокируют. Симуляция выручает разве что отчасти в беспилотных автомобилях, поэтому остаётся дробить работу на атомарные шаги с предсказуемым входом и выходом — Александр вспоминает булавки Адама Смита. Награду тоже раскладывают на прокси: что такое хорошая продажа, никто не знает, но в хороших продажах здороваются и не посылают друг друга матом. Там, где среда с автоматической наградой строится, всё работает: Александр приводит AlphaEvolve, который эволюционным перебором переписывает код под задачи оптимизации вроде планирования ресурсов, и напоминает, что внутри Google до сих пор живёт оркестратор Borg.

Поддержкой Артём занялся сразу после выхода ChatGPT: положил в промт регламент выдуманного ресторана, долго обстреливал его вопросами и понял, что промтом и руками делается то, ради чего раньше рисовали деревья диалогов и обучали модель на сотнях примеров. Он думал закрыть задачу за год — «никогда так сильно я ещё в жизни не ошибался». Отрезвил эксперимент: опытных сотрудников небольшого участка поддержки попросили описать, как они обслуживают людей, а затем по реальному потоку обращений просили модель показать пункт регламента, на который опирался оператор. Нашлось около 20% случаев, и писали регламент сильные люди. Иногда дистиллировать нечего вовсе: есть не процесс, а суждение — как вытащить из CTO, что такое хорошая архитектура, если сигнал приходит годами. Александр добавляет, что любую метрику качества легко загеймить, и вспоминает пример Влада Хононова, где компонент-звезду делят надвое: картинка улучшилась, а связь пропускает прежний объём.

Дальше начинается контроль качества. У людей он держится на страхе: выборку разбирает отдельная вертикаль, и человек, зная, что его диалог туда попадёт, сам следит за изменениями продуктов и регламентов. Модель так не умеет — её учили никогда не отказываться от задачи: попадание даёт плюс, промах минус, промежуточного варианта нет, и, как на экзамене с вариантами ответа, выгоднее ляпнуть наугад. Там, где человек осторожничает, модель прёт вперёд. Чтобы её проверять, нужен эталон обслуживания под конкретный случай, а его нигде нет: типовые процедуры больших поддержек пишут для удобства в рантайме, они неглубокие. Экономику Артём называет вопросом третьей очереди, хотя инженеры любят начинать с неё. Труднее всего организации: тысячи людей должны работать иначе, и даже в Т-Банке готовы были не все, причём боятся не операционщики, а те, кто строил прежнюю систему. Отсюда его совет: встроить модель в существующий процесс нельзя — берите ответственность за вертикальный срез вплоть до клиентского результата.

Бухгалтерия нравится Артёму как микс классической инженерии и генеративной: доходы минус расходы и ставка спокойно описываются кодом, включая тонкости с ФОТ, НДС и зависимостью ставки от числа сотрудников. Вся интеллектуальная часть сидит в другом — понять по каждой транзакции, что это было и к какому договору она относится, когда выписки приходят из двух банков, где-то в PDF, где-то в XML, а часть оплат прошла наличными мимо кассы. Значит, нужен не агент, а аккуратно спроектированный workflow. Спорной остаётся интерпретация: на двух бухгалтеров три мнения, какими документами подтверждать проводку, а в налоговом кодексе хватает серых зон. Александр возражает против единого внутреннего решения для такой зоны: что позволено Юпитеру, не позволено быку, и стандартная практика может подставить клиента. Артём отвечает риск-анализом: сначала приходит предупреждение, иногда дешевле заплатить штраф, а обычные бухгалтеры ошибаются тоже.

В маркетинге узким местом оказались не тексты, а пинг-понг согласований: продакт пишет позиционирование и слоганы и днями ждёт контентных редакторов — их и запроксировали моделью, чтобы правила приходили сразу к автору. Часть эффекта пришла вовсе без генеративок, как у ребят из Яндекса, отключивших дорогую разметку, которую давно никто не смотрел. Последний кейс Артём услышал в бане от товарища, чья компания строит промышленные объекты: «мы внедрили GenAI, и он проектирует у нас здания». Секрет оказался в постановке цели — не сгенерировать здание, а найти точки экономии: модель набрасывает варианты куска, а проектировщик, десять лет делавший одинаково, берёт их как референс. Александр добавляет, что прочность здания всё равно считают классическими методами, и внешняя верификация возвращает задачу в инженерную рамку. Итоговая рамка отбора: понять цель проекта, прикинуть сквозной эффект при идеальном исходе, спросить, как качество измеряют сегодня, и не станет ли проверка дороже экономии.