Про автоматизацию с ИИ говорят так, будто модель может делать всё. На практике она надёжно делает довольно узкий класс вещей, и весь успех проекта зависит от того, попала ли ваша задача в этот класс.
Правило, которое я вывел из проектов и с которого начинаю любое обсуждение:
> Модель должна делать только то, что умеет одна она — понимать неструктурированный вход. Всё остальное делает обычный код.
Звучит скучно. Но именно нарушение этого правила — главная причина, по которой проекты автоматизации не доходят до эксплуатации: модели отдают шаги, которые надёжнее и дешевле выполнить детерминированно, а потом борются с непредсказуемостью там, где её могло не быть вовсе.
Что модель делает хорошо
Один общий признак: на входе текст, написанный человеком, на выходе — что-то определённое.
- Понять, о чём обращение. Письмо, заявка, отзыв → категория, срочность, тема. Разбор — «Классификация обращений».
- Достать поля из текста. Счёт, накладная, анкета → сумма, дата, контрагент, позиции. Разбор — «Извлечение данных из документов».
- Свести длинное к короткому. Переписка, расшифровка звонка → суть, договорённости, следующий шаг.
- Переформулировать. Черновик → письмо в нужном тоне. С проверкой человеком.
- Сопоставить неточно. «ООО Ромашка» и «Ромашка, ООО» — один контрагент. Правилами это ловится плохо, моделью хорошо.
- Оценить содержание. Отзыв → тональность, конкретная претензия, требует ли ответа.
Что модель делает плохо
Другой общий признак: задача требует точности, воспроизводимости или работы с числами.
- Считать. Арифметика — работа кода. Модель может ошибиться в сложении и не сообщит об этом.
- Выполнять точные правила. «Если сумма больше 100 000 и контрагент из списка — на согласование». Это условие в коде, а не задача для модели.
- Гарантировать одинаковый ответ. Модель вероятностна: два одинаковых запроса могут дать разные формулировки. Там, где нужна воспроизводимость, нужны правила.
- Работать с большими таблицами. Сводка по 10 000 строк — задача запроса к базе.
- Принимать необратимые решения. Платёж, удаление, отправка клиенту — только с проверкой или по детерминированному правилу.
- Заменять отсутствующие данные. Если сведений нет, модель их придумает — «Почему нейросеть выдумывает».
Как выглядит правильно устроенный конвейер
Типичный рабочий пример — обработка входящего письма:
| Шаг | Кто делает | Почему так |
|---|---|---|
| Получить письмо | код | это интеграция, не задача для модели |
| Определить тип и срочность | модель | вход неструктурированный |
| Извлечь контакты, номер заказа, суть | модель | то же |
| Проверить формат номера заказа | код | регулярное выражение надёжнее |
| Найти клиента в CRM | код | запрос к базе |
| Проверить, нет ли дубля заявки | код | точное сравнение |
| Решить, куда направить | код | правила по типу и срочности |
| Создать заявку | код | операция с проверками |
| Составить ответ клиенту | модель | нужен человеческий текст |
| Отправить | код, с проверкой | необратимое действие |
Из десяти шагов модель занята в трёх. Остальное — обычная программа, и это не признак примитивности решения, а признак того, что оно доживёт до эксплуатации. Именно так я и собираю автоматизацию процессов: раскладываю процесс по шагам и определяю, где нужна модель, а где надёжнее код.
Что даёт такое разделение. Предсказуемость: семь шагов из десяти всегда отрабатывают одинаково. Дешевизна: обращений к модели меньше. Диагностируемость: при сбое видно, какой шаг сломался. Тестируемость: код проверяется обычными тестами.
Где проходит граница с агентами
Часто спрашивают, чем это отличается от ИИ-агента. Различие одно и оно определяющее:
В автоматизации последовательность шагов задана заранее. Она нарисована, её можно посмотреть, она всегда одна и та же.
Агент выбирает шаги сам по ходу задачи, и заранее неизвестно ни какие они будут, ни сколько их.
Отсюда всё остальное: автоматизация дешевле, предсказуемее, проще тестируется. Агент нужен там, где порядок действий действительно зависит от промежуточных результатов и его нельзя расписать заранее. Разбор — «Агент, ассистент или чат-бот».
Практическое следствие: если вы можете нарисовать блок-схему процесса — вам не нужен агент. Нужна автоматизация с моделью на отдельных шагах.
Разбор: проект, который переделывали дважды
Задача. Обработка заявок от дилеров: письма со спецификациями, нужно завести заказ в учётную систему.
Первая версия. Отдали модели всё: прочитать письмо, понять состав заказа, найти позиции в номенклатуре, посчитать сумму, создать заказ.
Что сломалось. Три вещи, и все предсказуемые.
Суммы. Модель складывала позиции и ошибалась примерно в одном случае из тридцати. Не сильно — на сотни рублей, — но ошибка попадала в заказ и обнаруживалась при сверке. Хуже того, ошибка была молчаливой: система не сообщала о неуверенности.
Номенклатура. Модель «находила» позиции, которых в справочнике не было, придумывая правдоподобные артикулы.
Воспроизводимость. Одно и то же письмо, обработанное дважды, иногда давало разный состав заказа. Для учётной системы это неприемлемо.
Вторая версия. Оставили модели только разбор письма: вернуть список позиций как они названы в тексте, с количествами, в заданном формате — «Структурированный вывод модели».
Дальше всё делал код: поиск по справочнику номенклатуры с нечётким сопоставлением, проверка, что каждая позиция найдена, арифметика, создание заказа.
Что изменилось. Ошибки в суммах исчезли — арифметикой занялся код. Придуманные артикулы исчезли — код искал в реальном справочнике и не находил несуществующее.
Осталась одна проблема: примерно в 15% писем позиция называлась так, что сопоставление было неоднозначным.
Третья версия. Добавили сценарий неуверенности: если позиция не сопоставилась однозначно, заявка уходит человеку с уже разобранным составом и вариантами на выбор. Не «разбирайтесь сами», а «мы поняли вот так, подтвердите позицию №3». Разбор такого устройства — «Человек в контуре проверки».
Итог. Около 85% заявок стали проходить без человека, 15% — с быстрым подтверждением одной позиции вместо ручного ввода всей заявки.
Что стоит забрать. Первая версия выглядела на демонстрации лучше всех: одна модель делает всё, красиво. В эксплуатации она была непригодна. Рабочая версия скучнее и состоит в основном из обычного кода.
Пять признаков переоценённого предложения
По ним видно, что проект не доживёт до эксплуатации:
- Модель считает деньги. Арифметика должна быть в коде, всегда.
- Нет сценария неуверенности. Система, которая всегда выдаёт результат, будет выдавать неверный там, где надо было спросить.
- Нет измерений. «Работает хорошо» без набора тестовых случаев — не утверждение.
- Модель выполняет точные правила. Если правило формулируется однозначно, ему место в коде.
- Демонстрация на подготовленных примерах. Проверять надо на реальном потоке, включая мусорные и нестандартные случаи.
Частые вопросы
Что ИИ действительно умеет автоматизировать?
Задачи, где на входе текст, написанный человеком, а на выходе нужно что-то определённое: понять тему обращения, достать поля из документа, свести переписку к сути, сопоставить неточно написанные названия. Всё, что требует точного счёта, воспроизводимости и выполнения однозначных правил, надёжнее делать обычным кодом.
Чем автоматизация с ИИ отличается от ИИ-агента?
В автоматизации последовательность шагов задана заранее и всегда одна и та же, а модель занята на отдельных шагах. Агент выбирает шаги сам, и заранее неизвестно, какими они будут. Практическое правило: если процесс можно нарисовать блок-схемой, агент не нужен.
Почему нельзя отдать модели весь процесс целиком?
Потому что она будет ошибаться там, где ошибок могло не быть: в арифметике, в поиске по справочникам, в соблюдении точных правил. Плюс теряется воспроизводимость: одинаковый вход может дать разный результат. Рабочие решения устроены так, что модель делает три-четыре шага из десяти, а остальное — обычный код.
Сколько процессов реально удаётся автоматизировать полностью?
Полностью — редко. Обычная картина: основная часть потока проходит без человека, а сложные и неоднозначные случаи уходят на подтверждение. Это не недоработка, а правильное устройство: попытка довести долю до ста процентов обычно означает, что система начнёт уверенно ошибаться на трудных случаях.
С чего начинать?
С разбора процессов и выбора очереди, а не с выбора технологии. Ошибка в выборе процесса стоит дороже любой технической ошибки: хорошо сделанная автоматизация ненужного процесса не приносит ничего. Метод отбора — «Какие процессы автоматизировать первыми».
Может быть, нам хватит обычного скрипта?
Вполне возможно, и это стоит проверить до начала проекта. Если вход структурирован, а правила формулируются однозначно, модель не нужна — скрипт дешевле, быстрее и предсказуемее. Признаки и сравнение — «Когда хватит скрипта вместо ИИ».
Что дальше
Выбор процессов — «Какие процессы автоматизировать первыми». Проверка, нужна ли модель вообще — «Когда хватит скрипта». Конкретные направления: почта, документооборот, рутина в CRM, отчётность, отзывы.