Работа с ИИ без хаоса: Как ставить задачи нейросети и получать полезный результат

Илья предложил поручить модели первичную сортировку: выбрать категорию «задержка доставки», отметить требование об отмене и составить короткую сводку. Здесь модели не нужно решать, имеет ли клиент право на возврат. Достаточно точно выделить содержание письма.

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

Плохая сводка выглядела бы так: «Заказ задержан, клиенту положен возврат». В ней появились выводы, которые еще никто не проверял.

Модель может предложить категорию, но человек проверяет, не пропущена ли важная часть обращения. Особенно внимательно нужно разбирать письма с необычными просьбами, упоминаниями неисправности или угрозы безопасности, финансовыми спорами и требованиями, которые обрабатываются по отдельным правилам. Результат этого этапа — правильно направленное обращение с кратким описанием, а не готовое решение.

Второй шаг. Отделить сказанное от известного

Теперь нужно понять, какие сведения есть в письме, а каких не хватает. Из текста можно извлечь, что Анна считает обещанной датой вчерашний день, но нельзя заключить, что именно эта дата указана в системе компании. Можно увидеть просьбу об отмене, но нельзя считать, что отмена уже оформлена.

Модели можно поручить разделить содержание письма на три части:

Клиент утверждает: доставка не состоялась в ожидаемый день.

Клиент просит: доставить заказ сегодня, а если это невозможно — отменить его и вернуть деньги.

Нужно проверить: обещанную дату, текущий статус отправления, возможность отмены и порядок возврата.

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

Для этого этапа Илья предложил запрос: «Используй только текст обращения. Раздели сведения на утверждения клиента, его просьбы и вопросы, требующие проверки. Не делай выводов о статусе заказа, праве на возврат и действиях компании. Если данных недостаточно, укажи, каких именно».

Запрос задает модели конкретную операцию и ограничения. Человек проверяет, что сводка не исказила письмо и не превратила неизвестное в факт.

Третий шаг. Сверить сведения

Чтобы ответить Анне, нужно открыть внутреннюю систему учета заказов и посмотреть статус доставки. В нашем примере там указано, что отправление передали перевозчику, но новых отметок о движении несколько дней не было. Точная дата доставки не подтверждена. Сотрудник также проверяет, не создали ли уже обращение в службу логистики и не менялся ли статус после предыдущего контакта.

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

Мария предложила поручить модели просмотреть все данные и решить, что сообщить клиенту. Ольга уточнила:

— Из какой именно системы она возьмет статус? Что будет, если запись обновится после того, как модель ее прочитает? И кто проверит, что в черновик попали сведения по нужному заказу?

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

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

Четвертый шаг. Выбрать действие

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

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

Ольга обозначила главный риск:

— Кто подтвердит обещание клиенту? Если мы называем дату, компания должна быть уверена, что выполнит обещанное. Модель не отвечает за очередь в логистике и не знает, создал ли сотрудник запрос.

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

Результат этапа — принятое решение и выполненное действие. Например: запрос логистике создан, за него отвечает Мария, а клиенту нужно сообщить о результате не позднее следующего рабочего дня. Теперь есть основа для письма.

Пятый шаг. Составить ответ и проверить его

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

Мария попросила использовать только проверенные сведения, сообщить, что запрос перевозчику уже создан, не обещать дату доставки, назвать срок следующего обновления и не утверждать, что заказ отменен. Она также задала тон: обратиться к Анне спокойно и понятно, без внутреннего жаргона и без изменения смысла.

Черновик получился таким:

«Здравствуйте, Анна. Проверила статус заказа: он передан перевозчику, но новых отметок о движении пока нет. Мы направили запрос, чтобы уточнить ситуацию. До завтра включительно сообщу вам результат проверки. Заказ пока не отменен: возможность отмены нужно подтвердить с учетом текущего статуса отправления. Извините, что заказ не пришел в ожидаемый вами день».

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

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

В одной из первых версий Мария заметила фразу: «Мы гарантируем, что вопрос будет решен завтра». Модель добавила ее, стараясь сделать ответ убедительнее. Команда заменила обещание решить вопрос обещанием связаться: «Завтра сообщу вам результат проверки, даже если перевозчик еще не даст окончательного ответа». Сотрудник может контролировать, когда напишет клиенту, но не скорость ответа перевозчика.

Шестой шаг. Отправить письмо и закрыть цикл

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

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

Карта маршрута

Завершив разбор, Мария свела его в краткую карту. Она показывает, что поступает на каждом этапе, где может помочь модель и кто отвечает за результат.

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

Разбор содержания. Вход — текст клиента. Операция — выделить утверждения, просьбы и неизвестные сведения. Выход — структурированная сводка. Модель готовит ее, человек сверяет с исходным письмом.

Проверка заказа. Вход — номер заказа и внутренние системы. Операция — сверить статус, дату и историю контактов. Выход — подтвержденные факты и список того, что еще нужно выяснить. Сведения проверяют по источнику.

Выбор действия. Вход — подтвержденные факты, внутренние правила и полномочия сотрудника. Операция — решить, что делать и что можно обещать. Выход — действие, ответственный и срок следующего шага. Решение принимает человек.

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

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

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

Не «дать нейросеть», а выбрать участок

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

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

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

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

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

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

Три вопроса для выбора участка

Прежде чем подключать модель к операции, Мария предложила задать три вопроса.

Можно ли точно назвать входные данные? Если для ответа нужны письмо, статус заказа и внутренняя инструкция, их следует перечислить. Если сотрудник обычно «просто понимает по опыту», сначала нужно описать, какие признаки он учитывает.

Можно ли сформулировать операцию как ограниченное действие? «Выдели просьбы клиента» — понятная задача. «Разберись в ситуации и реши, что делать» — слишком широкая, если не заданы источники, правила и полномочия.

Можно ли проверить результат? Сводку можно сравнить с письмом, статус — с системой учета, черновик — с подтвержденными фактами и решением сотрудника. Если проверка занимает столько же времени, сколько работа вручную, или требует редкой экспертизы, выгода может исчезнуть.

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

Как понять, что процесс стал лучше

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

Важно учитывать полные затраты: подготовку данных, проверку результата и исправления, а не только время на набор текста. Сводки нужно сопоставлять с исходными письмами, а ответы — с источниками и принятыми решениями. Если модель экономит минуты на черновике, но увеличивает число уточнений и повторных обращений, процесс лучше не стал.

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

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

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

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

Границы, которые нельзя передавать модели

Команда Марии готовила справочник тем для обращений в службу поддержки. Ей нужны были короткие нейтральные названия категорий и понятные описания, чтобы сотрудники одинаково распределяли сообщения. Илья предложил проверить формулировки с помощью нейросети и для этого загрузить примеры из рабочей системы.

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

— Если убрать имена и телефоны, этого хватит? — спросила Мария.

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

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

В одном файле — разные типы информации

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

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

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

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

Эти категории могут пересекаться. Внутренний комментарий способен содержать персональные данные сотрудника, публичная публикация — сведения о клиенте, а непубличная статистика — позволять восстановить отдельный случай, если записей мало. Поэтому проверка не сводится к вопросу: «Есть ли в документе фамилии?»

Люди рассказывают в обращениях не только о заказе, но и о своей жизни. Клиент может упомянуть диагноз, инвалидность, семейный конфликт, финансовые трудности или другие личные обстоятельства. Сведения о здоровье и некоторые другие категории требуют особой осторожности и могут подпадать под специальные требования российского законодательства о персональных данных. Их нельзя считать безобидным фоном только потому, что клиент сам написал о них в обращении.

Выгрузка Марии показала это не сразу. Илья открыл строку с фамилией, телефоном и номером заказа. Первые два поля он мог удалить за минуту. Но в тексте оставались точный адрес, дата, описание необычной доставки и фраза о состоянии здоровья. В отдельной колонке значилась внутренняя пометка: «В подобных случаях не предлагать возврат до согласования». Для подготовки справочника категорий не требовалось ни одно из этих сведений.

Цель сужает набор данных

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

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

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

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

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

Перед передачей нужно проверить и материал, и инструмент

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

— Давайте проверим не только, что лежит в файле, но и куда мы собираемся его отправить, — сказала Ольга. — Входит ли инструмент в перечень разрешенных? Как он обрабатывает запросы? Кто имеет к ним доступ и как долго они хранятся? Используются ли данные для обучения или улучшения сервиса? Есть ли ограничения по типам информации?

Эти вопросы не заменяют юридического заключения. Они помогают понять, что нужно выяснить у специалиста, который отвечает за информационную безопасность, персональные данные, юридические вопросы или закупку сервисов. В разных организациях эти обязанности распределены по-разному. Главное — не подменять проверку предположениями вроде «сервис известный», «пароль только у меня» или «в запросе нет фамилии».

В российском рабочем контексте нужно учитывать действующие требования, в том числе законодательство о персональных данных и Федеральный закон № 152-ФЗ, а также локальные документы организации. Правомерность обработки зависит от конкретных обстоятельств: цели, состава сведений, основания обработки, роли организации, выбранного инструмента и условий его использования. Нельзя исходить из того, что один и тот же способ подходит для любой задачи. Если остаются сомнения, нужно обратиться к специалисту, который отвечает за соответствующую область.