Автоматизация бизнеса с помощью ИИ: нейросети для заявок, документов и рутинных операций

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

1. Можно ли записать решение в виде «если — то» на одной странице? Если да, пишем обычный код или настраиваем RPA. Это дешевле, быстрее и предсказуемее.
2. Одинаково ли выглядит вход? Если счета приходят от трёх поставщиков в трёх форматах, шаблонное чтение справится. Если форматов несколько десятков и появляются новые, нужна модель.
3. Что стоит ошибка и кто её заметит? Если ошибку видно сразу и исправляется за минуту, можно автоматизировать смелее. Если её найдут через месяц на сверке с контрагентом, нужен человек в контуре.

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

• Подсказка. Система показывает результат, сотрудник сам вводит его в учёт. Начинаем с неё, когда нет эталонных данных: сотрудник одновременно проверяет и модель, и свои привычки.
• Черновик с подтверждением. Система заполняет поля, составляет письмо или готовит запись, сотрудник просматривает и подтверждает одним действием. Это основной режим для денег, документов и обращений к клиентам.
• Самостоятельное действие. Система сама записывает данные или отправляет ответ. Допустимо там, где ошибка видна сразу, откатывается и не касается денег и клиентских обещаний, например при присвоении категории или маршруту внутренней заявки.

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

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

1. сколько раз операция выполняется;
2. сколько минут занимает одно выполнение и сколько людей это делают;
3. какую долю результатов человек сейчас исправляет после себя или после коллеги;
4. сколько стоит одна ошибка, если она дошла до клиента, до бухгалтерии или до контрагента;
5. как меняется объём в пиковые периоды.

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

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

Для данных, которые нельзя передавать наружу, мы разворачиваем модель на серверах заказчика или у выбранного им хостера и подключаем её к процессу. Для таких данных внешние облачные модели чаще всего не подходят по требованиям заказчика к безопасности. Если данные открыты (описание каталога, публичные обращения), внешний программный интерфейс допустим, и пилот на нём проще и быстрее. Подробнее о развилке — в статье «Своя LLM или ChatGPT API» и на странице частных моделей в закрытом контуре.

Если задача сводится к ответам по документам, лучше начать со страницы ИИ-ассистента по документам.