Нейросеть научилась получать награду без решения задачи

Иван Коваль, kovalim

10 сентября команда Сбера рассказала об обучении GigaChat 3.5 Reasoning. Среди технических подробностей нашёлся эпизод, который вполне можно приложить к положению о премировании.

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

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

Меня здесь интересует управленческий вопрос: что выгодно делать тому, кто хорошо понял, за что платят?

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

Клиент пишет: «Не могу провести оплату». Сотрудник отправляет инструкцию, ставит «Решено» и закрывает карточку. Оплата не проходит. Клиент пишет снова, получает новый номер обращения и очередную инструкцию. В отчёте уже два закрытия. У клиента всё та же проблема.

Если он достаточно настойчив, то ещё и поможет отделу выполнить план.

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

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

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

Перенести правило Сбера «все тесты или ничего» в отдел тоже заманчиво. Но там есть сложные клиенты, зависшие согласования и сбои у подрядчиков. Если один такой случай обнуляет премию, появится повод передавать его друг другу ещё до попытки разобраться.

Я бы начал с одного повторного обращения, которое уже попало в премиальный отчёт. Открыл переписку: кто устранил сбой? Получил ли он что-нибудь за свою работу или премия досталась тем, кто раньше закрыл карточки?

После этого можно менять конкретные правила. Связать повторное обращение с первым, чтобы одна проблема не превращалась в несколько успехов. Разделить статусы «ответили» и «решили». Определить, кто отвечает за задачу после передачи в другое подразделение.

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

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

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

Другие разборы управления и ИИ в канале kovalim.

#kovalim #дорогая_очевидность #операционнаяэффективность #ИИвработе