Значительная часть задач, под которые заказывают ИИ, решается обычной программой — дешевле, быстрее и надёжнее. Я говорю это на первой встрече примерно в каждом третьем случае, и это не скромность, а расчёт: автоматизация, сделанная не тем инструментом, дороже в разработке и дороже в эксплуатации.
Признак, по которому проходит граница, один:
> Если правило формулируется однозначно, ему место в коде. Модель нужна там, где вход написан человеком и однозначного правила не существует.
Три вопроса, которые закрывают тему
1. Структурирован ли вход?
Если данные приходят из формы, выгрузки, таблицы или системы с полями — они уже разобраны. Извлекать нечего.
Модель нужна, когда на входе текст, написанный свободно: письмо, отзыв, сообщение, документ произвольной формы.
2. Можно ли записать правило?
Попробуйте сформулировать: «если поле А больше Х и Б входит в список — то В». Получилось без «ну обычно», «зависит», «как правило» — это код.
Если формулировка неизбежно расплывается, потому что случаи не сводятся к перечислимым условиям, — тогда модель.
3. Нужна ли гарантия одинакового результата?
Код на одинаковом входе всегда даёт одинаковый выход. Модель — нет: она вероятностна, и две обработки одного текста могут дать разные формулировки.
Там, где расхождение недопустимо — бухгалтерия, юридически значимые действия, расчёты, — нужны правила.
Сравнение
| Правила и скрипты | Модель | |
|---|---|---|
| Вход | структурированный | любой |
| Воспроизводимость | полная | вероятностная |
| Стоимость выполнения | практически ноль | плата за каждое обращение |
| Скорость | миллисекунды | сотни миллисекунд и выше |
| Понятно, почему такой результат | да | не всегда |
| Тестируется | обычными тестами | наборами случаев |
| Новый случай | добавить правило | обычно ничего |
| Трудоёмкость роста | растёт с числом правил | почти не растёт |
| Ошибается | там, где правило неверно | непредсказуемо |
Две последние строки объясняют, почему граница вообще существует. При малом числе понятных случаев правила выигрывают вчистую. При большом разнообразии правила превращаются в неподдерживаемый список исключений, и модель начинает выигрывать.
Расчёт: где проходит перелом
Числа условные. Задача: разбор входящих обращений, 2 000 в месяц.
Вариант «правила». Обращения приходят через форму с выбором темы (70% потока) и почтой в свободной форме (30%).
| Статья | Значение |
|---|---|
| Разработка правил для формы | 60 000 ₽ |
| Обработка 1 400 обращений с формы | 0 ₽/мес |
| Правила для типовых писем (шаблонные отправители) | 40 000 ₽ |
| Обработка 300 таких писем | 0 ₽/мес |
| Остаток — 300 писем — вручную | 25 часов/мес |
Вариант «модель на всё».
| Статья | Значение |
|---|---|
| Разработка конвейера | 250 000 ₽ |
| Обращения к модели, 2 000 шт. | ~6 000 ₽/мес |
| Сопровождение | 15 000 ₽/мес |
| Остаток на ручную обработку | ~5 часов/мес |
Вариант «правила плюс модель на остаток».
| Статья | Значение |
|---|---|
| Правила для формы и шаблонных писем | 100 000 ₽ |
| Модель для 300 свободных писем | 180 000 ₽ |
| Обращения к модели, 300 шт. | ~900 ₽/мес |
| Сопровождение | 12 000 ₽/мес |
| Остаток на ручную обработку | ~5 часов/мес |
Что видно. Третий вариант дешевле второго и на входе, и в эксплуатации, а результат тот же. Причина проста: 70% потока не требовали модели вообще — тема уже была указана в форме.
Пропускают это регулярно. Когда задача формулируется как «автоматизировать обработку обращений», её отдают модели целиком, не разбирая, какая часть потока уже структурирована.
Отдельно про первый вариант. Он дешевле всех, но оставляет 25 часов ручной работы в месяц. Окупается ли их устранение — вопрос расчёта: «Какие процессы автоматизировать первыми».
Правильная схема: правила первыми, модель на остаток
Работающий порядок в конвейере:
- Формальные признаки — правилами. Отправитель, тема письма с префиксом, поле формы, тип вложения. Быстро, бесплатно, предсказуемо.
- Модель — для того, что не определилось. Свободный текст без формальных признаков.
- Проверки результата модели — правилами. Форматы, контрольные суммы, диапазоны — «Извлечение данных из документов».
- Решения по результату — правилами. Куда направить, какой приоритет, нужно ли согласование.
Модель занята в одном шаге из четырёх. Это не урезание её роли, а правильное распределение: она делает то, чего не может код, а код — всё остальное.
Признаки, что вам продают лишнее
- Модель применяется к структурированным данным. Разбирать выгрузку из базы моделью незачем.
- Модель считает. Арифметика — работа кода, всегда.
- Модель выполняет однозначное правило. «Если сумма больше 100 000, на согласование» — это условие, а не задача понимания.
- Не разобран состав потока. Не выяснено, какая доля уже структурирована.
- Нет сравнения с простым решением. Хороший подрядчик сам скажет, что часть задачи решается без ИИ.
Когда модель нужна точно
Чтобы не создать обратного перекоса:
- вход написан человеком и формулировки непредсказуемы;
- вариантов слишком много, чтобы их перечислить;
- нужно понять смысл, а не найти ключевое слово;
- правила уже есть, и их сотни, а поддерживать их невозможно;
- нужно сопоставить неточное — «ООО Ромашка» и «Ромашка, ООО»;
- нужно свести длинное к короткому или переформулировать.
Пятый пункт стоит отметить: если у вас уже написано двести правил и каждое новое обращение ломает одно из них — это признак, что пора менять подход, даже если каждое правило по отдельности разумно.
Частые вопросы
Как понять, нужен ли ИИ или хватит скрипта?
По трём признакам: структурирован ли вход, формулируется ли правило однозначно и нужна ли гарантия одинакового результата. Если вход уже разобран по полям, правило записывается без оговорок, а результат должен быть воспроизводим — модель не нужна.
Правда ли, что скрипт дешевле?
В эксплуатации — да, практически всегда: выполнение почти ничего не стоит, тогда как каждое обращение к модели оплачивается. В разработке зависит от числа случаев: при малом числе понятных правил скрипт дешевле, при большом разнообразии написание и поддержка правил обходятся дороже модели.
Можно ли совмещать правила и модель?
Не только можно — так и стоит делать. Правила обрабатывают всё, что определяется формально: отправителя, поле формы, тип файла. Модель разбирает остаток. Часто это сокращает поток к модели в разы и соответственно снижает расходы.
У нас уже есть двести правил, и мы в них путаемся. Что делать?
Это как раз признак, что задача переросла подход: каждое новое условие ломает существующие, а сопровождение стало отдельной работой. Разумный ход — оставить правилами то, что стабильно и формально, а разнообразную часть передать модели.
Модель может выполнять точные правила?
Может, но не должна. Она сделает это менее надёжно, дороже и без гарантии одинакового результата. Однозначное условие в коде выполняется всегда одинаково и проверяется обычным тестом.
Как убедиться, что подрядчик не продаёт лишнего?
Спросите, какая доля потока уже структурирована и что из задачи решается без модели. Если ответа нет или он звучит как «всё сделает ИИ», разбор процесса не проводился. Хороший ответ всегда содержит разделение: вот это правилами, вот это моделью, вот почему.
Что дальше
Общая картина применимости — «Автоматизация с ИИ: что реально работает». Как расставить очередь процессов — «Какие процессы автоматизировать первыми». Стратегический взгляд на масштаб изменений — «ИИ-трансформация или автоматизация».
Разбор процесса с честным разделением на то, что решается правилами, и то, где нужна модель, — часть аудита процессов и работы по автоматизации процессов.