Менеджер по работе с нейросетями: что делает в команде
Менеджер по работе с нейросетями не обязан писать промпты весь день. Разбираю его задачи, первый пилот, контроль качества и границы ответственности команды.
М
Марина
Контент-маркетолог LibraChat
9 мин чтения
Менеджер по работе с нейросетями нужен не для того, чтобы весь день сочинять эффектные запросы. Его полезная работа начинается там, где пять человек по-разному понимают одну задачу, берут разные исходные данные и получают результат, который никто не отвечает проверить. Я разбираю эту роль на примере команды, готовящей ответы клиентам: кто задаёт правила, что можно доверить ИИ и как понять, что пилот вообще помог.
Представь отдел из пяти коллег. У каждого свой образец письма: у одного обещан срок, которого нет в договоре; у другого нет конкретного следующего шага. Руководитель просит «подключить нейросеть», а сотрудники ждут волшебной кнопки. Я в такой ситуации начинаю с вопроса не о модели, а о том, какой ответ клиенту считается приемлемым. Это и есть работа координатора процесса.
Менеджер по работе с нейросетями — отдельная профессия?
Название роли встречается в разных командах, но единого набора обязанностей из него не следует. Где-то человек обучает коллег составлять задания для ИИ. Где-то строит внутренний процесс проверки текстов, разбирает права доступа или собирает обратную связь. В маленькой компании эти функции может вести действующий редактор, аналитик или руководитель проекта. Поэтому я бы сначала читала описание задач, а уже потом название вакансии.
Есть соблазн объявить такого сотрудника «переводчиком между бизнесом и ИИ». Звучит гладко, но почти ничего не объясняет. В нашем примере его рабочий результат выглядит конкретно: согласованный шаблон ответа, понятный список разрешённых данных, ответственный за окончательную отправку письма и журнал типичных ошибок. Если этих вещей нет, опыт команды держится на памяти отдельных людей.
Специалисту не обязательно писать сложный код. Но он должен уметь сформулировать задачу, увидеть неверное допущение, разговаривать с владельцем процесса и признать, что инструмент в какой-то точке пока не подходит. Мне самой полезнее коллега, который заметил ложное обещание клиенту, чем человек с коллекцией из ста красивых промптов.
За что такой менеджер отвечает утром, днём и после пилота?
Утром он выбирает одну повторяемую задачу. Не «автоматизировать общение с клиентами», а «подготовить черновик ответа на вопрос о сроке поставки по утверждённой памятке». Днём вместе с владельцем процесса смотрит, какие данные нужны и кто вправе их передавать в сервис. После пробного периода собирает ошибки и решает, стоит ли продолжать.
Работа · Кто принимает решение · Что остаётся после этапа
Выбор задачи — Руководитель процесса и менеджер — Одна цель и граница пилота
Подготовка материалов — Владелец данных — Разрешённый набор примеров без лишних сведений
Критерии ответа — Сотрудник, который общается с клиентом — Проверяемый чек-лист
Черновик с ИИ — Исполнитель — Вариант текста, ещё не отправленный клиенту
Приёмка — Ответственный сотрудник — Исправленный текст и запись об ошибке
Решение о масштабировании — Руководитель — Причины продолжить, изменить или закрыть пилот
В этой таблице намеренно нет строки «нейросеть приняла решение». Она предлагает материал. Команда отвечает за то, что отправит наружу. Такой раздел ролей согласуется с подходом NIST к управлению рисками ИИ: роли людей и системы, проверка и наблюдение за результатом должны быть явными.
Почему одного удачного ответа мало?
На демонстрации удачный пример находится быстро. Я сама попадалась: выбирала письмо, где все условия уже расписаны, получала стройный черновик и радовалась. А потом приносили вопрос с исключением или старой формулировкой договора. Именно он показывал, что шаблон не выдерживает рабочую нагрузку.
Для первого пилота я взяла бы 20 обезличенных учебных обращений: короткие, длинные, с неясным сроком, с жалобой и с просьбой, на которую компания не может ответить сразу. Это не статистическое доказательство качества сервиса. Это достаточно разнообразная подборка, чтобы увидеть, где ломается собственный процесс. Часто выясняется, что памятка для сотрудников устарела. Модель лишь делает проблему заметнее.
Перед стартом договорись, что фиксировать. Например: сохранён ли смысл вопроса клиента, верно ли указан срок из утверждённой памятки, нет ли нового обещания, понятен ли следующий шаг. Я не стала бы мерить только скорость подготовки черновика. Быстрый текст, который сотрудник переписывает целиком, ничего не выигрывает. Запиши исходное время и число правок на небольшой выборке, затем сравни с пилотом. Не переноси цифру одного отдела на другую команду.
Хороший журнал ошибок короткий: номер учебного примера, тип расхождения, причина, действие. Если одно и то же замечание повторилось трижды, меняют инструкцию или исходную памятку. Если ошибка затрагивает разрешение на данные, пилот приостанавливают и согласуют процесс с ответственным человеком. Я лучше потеряю день на этот разговор, чем буду объяснять клиенту обещание, которого никто не утверждал.
Как выглядит карточка пилота для руководителя?
Когда я приношу руководителю только подборку удачных текстов, он спрашивает о бюджете и сроках, а я не могу объяснить, что именно предлагаю купить или изменить. Поэтому у пилота появляется карточка на одну страницу. Она нужна не для красивой отчётности: по ней коллега, который не присутствовал на первой встрече, поймёт, какое решение ожидается и на каких условиях.
Задача: черновик ответа на один тип обращения, а не весь клиентский сервис.
Материалы: версия утверждённой памятки, дата её проверки и список обезличенных примеров.
Критерий: сохранён смысл вопроса, нет нового обещания, указан следующий шаг.
Ответственный: кто утверждает текст перед отправкой и кто меняет памятку при ошибке.
Остановка: какие ошибки прерывают пилот сразу, без попытки «докрутить» запрос.
С такой карточкой проще увидеть разницу между качеством ответа и качеством организации работы. Если памятка не обновлялась полгода, аккуратно написанный черновик всё равно приведёт к старому сроку. Если сотрудник не знает, кто утверждает исключение, промпт не заменит полномочий. Я проверила бы эти две вещи ещё до первого сравнения текстов.
На обороте карточки я оставила бы дату следующего разбора. Иначе пилот незаметно превращается в постоянную практику, которую никто не пересматривал после смены условий работы.
Карточку стоит обсудить с исполнителями, а не только с руководителем. Они быстрее замечают строку, которую невозможно выполнить: например, «проверить ответ по базе», когда у вечерней смены нет доступа к этой базе. После разговора иногда меняется не инструмент, а порядок работы. Это вполне полезный итог пилота. У команды появляется ясная точка, где проверять факт, и меньше поводов отправлять клиенту ответ наугад.
Менеджер по работе с нейросетями должен сам выбирать сервис?
Он может предложить критерии выбора, но решение обычно затрагивает доступы, условия использования и бюджет. Я начинаю с задач, которые не требуют загрузки чувствительных материалов. Для текстовых черновиков можно описать процесс в LibraChat: сервис ведёт диалог, помогает писать и переписывать тексты; в чате можно уточнять требования, а проект объединяет свои инструкции и материалы для разговоров внутри него. Доступность конкретного режима и ограничения смотри на странице тарифов, не по старой презентации.
У меня есть простая проверка до выбора инструмента:
Можно ли решить задачу на вымышленных или обезличенных примерах, пока согласуются доступы?
Есть ли у команды владелец исходной памятки и человек, который принимает итоговый текст?
Можно ли показать, как проверяется ответ, не опираясь на впечатление «звучит хорошо»?
Что сделаем, если черновик предлагает неверный срок или пропускает исключение?
Где зафиксируем исправление, чтобы следующая смена не повторила ту же ошибку?
Если на первые три вопроса нет ответа, покупка расширенного доступа не решит процессную проблему. Сначала нужно согласовать данные и приёмку. Если ответы есть, пилот можно провести в допустимом рабочем контуре и оценить результат без игры в угадайку.
Что написать в первом запросе для команды?
Я предложила бы не универсальный «суперпромпт», а инструкцию для одной роли. Ниже шаблон для учебного обращения; это предлагаемый текст запроса, не фактически полученный ответ LibraChat:
«Помоги подготовить черновик ответа клиенту. Вопрос: [обезличенный пример]. Утверждённые факты: [три пункта из актуальной памятки]. Тон: спокойный, без обещания срока, если его нет в фактах. Структура: короткий ответ, что мы можем сделать, следующий шаг. Если данных не хватает, перечисли вопросы сотруднику вместо выдуманного ответа. Отдельно пометь фразы, для которых исходных фактов оказалось недостаточно».
В таком запросе полезна последняя просьба: она показывает, где закончились подтверждённые сведения. Это не даёт гарантии, что черновик будет безошибочным, поэтому сотрудник всё равно сверяет его с памяткой. Но команда получает общий способ описывать задачу. В следующем цикле менеджер может смотреть, какие вопросы возникали чаще, и добиваться ясных формулировок от владельца процесса.
Я советую сохранять не только удачный промпт, но и три типовых провала: неправильный факт, потерянная просьба клиента, неуместный тон. На обучении коллегам эти примеры полезнее восторженного скриншота. По ним видно, что нужно проверить перед отправкой. Рабочая инструкция становится короче, когда её пишут по настоящим ошибкам, а не по списку возможностей инструмента.
По чему понять, что роль полезна команде?
Я бы смотрела на повторяемость, а не на объём разговоров с ИИ. Через две недели можно взять новую небольшую выборку обращений и сравнить её с исходной: сколько черновиков прошли проверку без существенной правки, какие ошибки повторились, сколько времени ушло на доработку. При таком сравнении обязательно разделяй простые и сложные обращения. Иначе лёгкая выборка создаст красивую цифру без пользы.
Вторая мера — независимость команды от одного энтузиаста. Коллега, не участвовавший в настройке, должен суметь открыть правила, подготовить учебный запрос и понять критерии приёмки. Если он не может, менеджер сделал личный трюк, а не рабочий процесс. Я однажды составила инструкцию, которую понимала только сама. Пришлось выбросить половину терминов и добавить один разбор ошибки.
Третья мера неприятная, но нужная: что команда сознательно отказалась автоматизировать. Например, окончательное решение по спорному клиентскому обращению или обработку данных без согласованного доступа. Хороший менеджер умеет записать эту границу и объяснить её руководителю. Пилот, который что-то исключил, тоже может быть успешным — он уберёг команду от плохого применения инструмента.
Если хочешь примерить роль на себя, открой LibraChat и попробуй описать одну безопасную задачу своей команды по схеме выше. Для близкой индивидуальной работы почитай материал «Нейросеть для менеджера». Не обещай отделу чудес: принеси на встречу цель, 20 учебных примеров и критерий, по которому согласишься остановить пилот. С этого и начинается управленческая работа.
