Нейросеть в бизнес‑процессе: как не переделывать все через пару месяцев

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

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

Вы оптимизировали процесс, но через какое‑то время что‑то пошло не так

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

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

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

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

Почему ИИ‑процессы «стареют», и как это происходит

Обычную автоматизацию можно один раз настроить и надолго забыть, но с ИИ дело обстоит совсем иначе.

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

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

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

Четыре вещи, без которых все придется начинать заново

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

Контрольный набор примеров. Для начала стоит собрать 50‑100 реальных примеров с заранее известными правильными ответами: например, какое письмо в какой отдел должно уйти. Тогда в любой момент можно прогнать эти примеры через текущий процесс и убедиться, что модель отвечает как надо, а не полагаться на ощущения. Проверку несложно автоматизировать и запускать раз в несколько дней, чтобы в моменте отследить падение качества.

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

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

Главная ошибка: нейросети отдали лишнее

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

Все расчеты, проверки формата, однозначные правила вроде “заказы дороже 50 тысяч всегда идут на согласование” нейросеть выполняет нестабильно. При этом такие вещи легко запрограммировать (в том числе с помощью того же ИИ), и заодно сэкономить на вычислительных ресурсах. Если все свалено в один огромный промпт, то любое изменение — скажем, поднять порог с 50 до 70 тысяч означает, что придется найти нужный фрагмент в этой простыне текста, переписать его заново и прогнать весь процесс по тестовым примерам, чтобы убедиться, что все работает.

Так что правило тут довольно простое: нейросеть должна отвечать только за то, что требует понимание смысла, — распознать тему письма, вытащить данные из непредсказуемого текста, сформулировать черновик ответа. Все остальное — арифметику, жесткие правила, проверку, что ИНН состоит из 10 или 12 цифр, расчет скидки и так далее — лучше выносить наружу, отдельными инструментами.

Современным моделям не обязательно считать или проверять что‑то самостоятельно, они умеют вызывать готовые инструменты — этот механизм так и называется, вызов инструментов (tool calling). Модель сама решает, какой инструмент нужен под какую задачу — калькулятор, или же проверка по базе, — передает в этот инструмент исходные данные, получает обратно результат и дальше работает уже с ним. Это очень удобно, так как правило живет внутри инструмента, а не внутри промпта: когда нужно поднять порог с 50 до 70 тысяч, можно поменять одно число в коде проверки, а формулировку задачи оставить без изменений.

Напоследок

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

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