Последние два года кажется, что у любой бизнес-задачи появился универсальный ответ: «давайте подключим LLM», «сделаем агента», «пусть ИИ сам решит». Складывается впечатление, будто искусственный интеллект - это следующая обязательная ступень развития любой автоматизации.
Но чем больше я участвую в проектировании реальных систем, тем сильнее убеждаюсь в обратном.
Главная ошибка - не недостаточное использование ИИ, а применение ИИ там, где он вообще не нужен.
Если процесс можно описать правилами, алгоритмом или конечным автоматом, то использование языковой модели чаще ухудшает систему, чем делает её лучше.
Не потому что современные модели плохие.
Потому что они решают совершенно другую задачу.
Автоматизация появилась задолго до LLM
До появления генеративного ИИ компании десятилетиями успешно автоматизировали процессы.
Заказы распределялись между менеджерами.
Письма сортировались по правилам.
Платежи проверялись по регламентам.
CRM автоматически меняла статусы.
ERP рассчитывала остатки.
Workflow-системы запускали согласования.
Все эти процессы работали по одной причине.
Они были детерминированными.
Одинаковые входные данные всегда приводили к одинаковому результату.
Если сегодня клиент сделал заказ на 1500 рублей, завтра система обработает такой же заказ абсолютно так же.
Именно эта воспроизводимость делает бизнес предсказуемым.
Что меняется, когда появляется LLM
Языковая модель работает иначе.
Она не исполняет правила.
Она предсказывает наиболее вероятное продолжение текста.
Именно поэтому LLM великолепно пишет статьи, помогает с кодом, резюмирует документы и отвечает на вопросы.
Но одновременно именно поэтому она плохо подходит для задач, где существует единственно правильный результат.
Каждый вызов модели вероятностный.
Даже если вероятность ошибки составляет всего один процент, бизнес-процесс, который выполняется сто тысяч раз в месяц, получит тысячу потенциальных ошибок.
У обычного алгоритма вероятность подобной ошибки должна стремиться к нулю.
Не каждая автоматизация становится лучше после добавления ИИ
Сегодня можно встретить проекты, где LLM вызывается буквально на каждом шаге.
Агент получает письмо.
Потом определяет его тему.
Потом решает, кому отправить.
Потом формирует ответ.
Потом выбирает шаблон.
Потом меняет статус в CRM.
Со стороны выглядит впечатляюще.
На практике возникает простой вопрос.
Зачем?
Если маршрут письма определяется десятью известными правилами, зачем просить языковую модель угадывать ответ?
Если статус сделки зависит от одного поля CRM, зачем подключать генеративный ИИ?
Если документ имеет фиксированную структуру, почему его нельзя разобрать обычным парсером?
Во многих случаях LLM заменяет несколько строк кода, которые работают быстрее, дешевле и предсказуемее.
Каждый вызов модели - это новая точка вероятного отказа
Любая распределённая система проектируется с одной целью - уменьшить количество компонентов, отказ которых способен остановить весь процесс.
Поэтому инженеры десятилетиями боролись за уменьшение количества зависимостей.
Каждая новая зависимость увеличивает вероятность сбоя.
С LLM происходит то же самое.
Теперь успешное выполнение процесса зависит не только от вашего приложения.
Появляются дополнительные условия:
- доступность API;
- стабильность интернет-соединения;
- отсутствие лимитов;
- скорость ответа модели;
- совместимость новой версии модели;
- стоимость токенов;
- корректность промпта;
- отсутствие галлюцинаций.
Даже если все эти риски невелики сами по себе, вместе они превращаются в новую поверхность отказа.
Причём зачастую совершенно ненужную.
Вероятностная система никогда не будет такой же предсказуемой
Самое ценное качество корпоративного ПО - предсказуемость.
Если бухгалтер запускает расчёт зарплаты сегодня и завтра, он ожидает получить одинаковый результат.
Если логистическая система строит маршрут по известным правилам, маршрут не должен зависеть от настроения модели.
Если банк проверяет транзакцию, итог проверки обязан определяться правилами, а не статистической вероятностью.
Именно поэтому детерминированные алгоритмы остаются стандартом практически во всех критически важных системах.
ИИ может помочь человеку принять решение.
Но принимать решение вместо алгоритма совсем другая история.
Хорошая архитектура начинается не с вопроса «где использовать ИИ»
Правильный вопрос звучит иначе.
Можно ли решить эту задачу без него?
Если ответ да, скорее всего именно так и следует поступить.
ИИ должен становиться последним инструментом в цепочке, а не первым.
Сначала:
- обычный код;
- SQL;
- workflow;
- BPMN;
- правила;
- конечные автоматы;
- классические модели машинного обучения.
И только если все эти инструменты перестают справляться, появляется смысл подключать большую языковую модель.
Это не борьба с ИИ.
Это инженерный подход к проектированию систем.
Где ИИ действительно незаменим
Это вовсе не означает, что LLM бесполезны.
Наоборот.
Есть задачи, где традиционные алгоритмы оказываются бессильны.
Например:
- анализ свободного текста;
- работа с договорами;
- извлечение информации из неструктурированных документов;
- поиск смысла в переписке;
- генерация контента;
- написание кода;
- работа с естественным языком;
- интеллектуальный поиск по базе знаний;
- классификация данных, которые невозможно описать фиксированными правилами.
Именно здесь языковые модели дают результат, который ещё несколько лет назад казался невозможным.
Проблемы начинаются тогда, когда этот успех пытаются распространить вообще на всё.
Агент не всегда более умная система
Сегодня слово «агент» стало почти синонимом современной автоматизации. Кажется, что если добавить автономность, память, инструменты и возможность самостоятельно принимать решения, процесс автоматически станет эффективнее.
На практике всё оказывается сложнее.
Каждый агент - это система, которая постоянно выбирает следующий шаг. Какой инструмент вызвать? Какие данные использовать? Что считать успешным результатом? Нужно ли выполнить действие сейчас или запросить дополнительную информацию?
Все эти решения принимаются не по жестким правилам, а на основе вероятностной модели.
Именно поэтому поведение агента нельзя гарантировать так же, как поведение обычного алгоритма.
Сегодня он выберет один путь, а завтра другой.
Через месяц после обновления модели - третий.
Если задача допускает разные способы решения, это не проблема. Если же бизнес ожидает один конкретный результат, такая изменчивость становится источником риска.
Добавляя ИИ, мы увеличиваем сложность системы
Любая новая технология имеет цену.
Чаще всего эта цена скрыта не в лицензиях и не в стоимости токенов.
Она проявляется в сложности сопровождения.
Допустим, раньше процесс состоял из пяти шагов:
- Получить заявку.
- Проверить обязательные поля.
- Найти клиента.
- Создать заказ.
- Отправить уведомление.
Все пять шагов были детерминированными. Если где-то происходила ошибка, её можно было воспроизвести, локализовать и исправить.
Теперь представим, что между каждым этапом появился вызов LLM.
Система стала значительно сложнее.
Возникают вопросы, которых раньше просто не существовало.
Почему модель приняла именно такое решение?
Какой промпт использовался?
Какая версия модели отвечала?
Изменилось ли её поведение после обновления?
Почему вчера результат был одним, а сегодня другим?
Как воспроизвести ошибку, если модель генерирует разные ответы?
Фактически разработчик начинает сопровождать уже не программу, а вероятностную систему.
Не путайте интеллектуальность и надежность
Это одна из самых распространённых ошибок.
Мы привыкли считать, что более "умная" система автоматически становится лучше.
Но инженерия работает иначе.
Представьте два решения.
Первое использует регулярное выражение, которое за две миллисекунды извлекает номер договора.
Второе отправляет документ в LLM, которая анализирует текст, интерпретирует контекст и через три секунды возвращает тот же номер договора.
Какое решение лучше?
Если документ всегда имеет одинаковую структуру, то первое.
Оно быстрее.
Дешевле.
Проще.
Полностью воспроизводимо.
И практически не требует сопровождения.
Использование ИИ здесь не увеличивает ценность.
Оно лишь увеличивает количество компонентов.
Принцип минимально необходимого интеллекта
В инженерии давно существует идея минимально необходимой сложности.
Система не должна быть сложнее, чем требует задача.
Мне кажется, тот же принцип должен применяться и к ИИ.
Можно назвать его принципом минимально необходимого интеллекта.
Его суть очень проста.
Используйте самый простой инструмент, который способен решить задачу с требуемым качеством.
Если достаточно SQL - используйте SQL.
Если хватает набора бизнес-правил - используйте правила.
Если подходит workflow - стройте workflow.
Если необходим классический ML - используйте ML.
И только когда задача действительно требует понимания языка, работы с неопределённостью или генерации нового содержания, подключайте LLM.
ИИ должен быть последним уровнем архитектуры, а не первым.
Хороший вопрос: "Что произойдет, если отключить модель?"
Есть простой мысленный эксперимент, который помогает оценить необходимость ИИ.
Представьте, что завтра API модели перестало отвечать.
Что произойдёт с вашим процессом?
Если остановится весь бизнес, стоит задуматься, действительно ли модель находилась в правильном месте архитектуры.
Очень часто оказывается, что критически важный процесс зависит от генерации текста, хотя мог работать вообще без неё.
Надёжные системы проектируются так, чтобы интеллектуальные компоненты были изолированы.
Если ИИ недоступен, процесс должен либо продолжать работать в упрощённом режиме, либо безопасно останавливаться до участия человека.
Он не должен превращать всю систему в цепочку домино.
Где агент действительно оправдан
Это не означает, что агентные системы бесполезны.
Есть задачи, которые невозможно описать фиксированными правилами.
Например, исследовательский поиск.
Агент получает задачу:
«Изучи рынок европейских поставщиков, сравни лицензии, найди последние изменения законодательства и подготовь рекомендации.»
Такой процесс невозможно выразить в виде набора условий.
Здесь действительно нужна способность самостоятельно искать информацию, принимать промежуточные решения, выбирать источники и менять план работы.
Именно в подобных сценариях агент раскрывает свои сильные стороны.
Но если задача звучит так:
«Если сумма счета превышает 500 000 рублей, то отправить документ финансовому директору.»
То никакой агент здесь не нужен.
Обычное условие if выполнит работу быстрее, надежнее и без риска неожиданной интерпретации.
Как выбирать технологию
За последние годы мне всё больше нравится одна простая последовательность принятия решений.
Перед тем как использовать ИИ, стоит ответить всего на четыре вопроса.
Первый вопрос. Можно ли решить задачу обычным алгоритмом?
Если да - используйте алгоритм.
Второй вопрос. Можно ли описать решение набором правил или workflow?
Если да - используйте правила.
Третий вопрос. Требуется ли статистическое распознавание или прогнозирование?
Если да, то возможно, достаточно классического машинного обучения.
И только четвёртый вопрос. Нужно ли понимать естественный язык, генерировать новый текст, анализировать неструктурированные документы или принимать решения в условиях высокой неопределённости?
Лишь после этого имеет смысл рассматривать использование LLM или агентной архитектуры.
Такой порядок может показаться консервативным. На самом деле он просто соответствует фундаментальному принципу инженерии: не усложнять систему без необходимости.
Именно поэтому зрелые архитектуры редко строятся вокруг искусственного интеллекта. Обычно ИИ становится одним из компонентов системы, а не её фундаментом. Это не ограничивает возможности модели, а наоборот, позволяет использовать её там, где она действительно создаёт ценность, не превращая каждый бизнес-процесс в эксперимент с вероятностным исходом.
Стоимость ошибки всегда выше стоимости автоматизации
Когда обсуждают внедрение ИИ, обычно говорят о скорости.
«Мы будем обрабатывать заявки быстрее.»
«Мы сократим время подготовки документов.»
«Мы избавимся от рутинной работы.»
Все эти аргументы справедливы.
Но почти всегда упускается другой вопрос.
Сколько стоит ошибка?
Для генерации статьи ошибка может означать лишние пять минут редактора.
Для службы поддержки - недовольного клиента.
Для бухгалтерии - неверный платёж.
Для банка - нарушение требований регулятора.
Для юридического отдела - судебный спор.
Для промышленной системы - остановку производства.
Поэтому стоимость внедрения ИИ нельзя считать только в токенах или лицензиях.
Необходимо учитывать стоимость вероятностной ошибки.
Чем выше цена неверного решения, тем меньше места должно оставаться для вероятностного поведения системы.
ИИ не должен принимать решения, которые можно вычислить
Есть простой принцип, который, на мой взгляд, должен стать инженерным стандартом.
Если решение можно вычислить, его не нужно генерировать.
Например.
Определить ставку НДС.
Проверить наличие обязательного документа.
Выбрать согласующего по организационной структуре.
Рассчитать скидку.
Определить маршрут согласования.
Проверить права доступа.
Все эти действия описываются правилами.
Использование LLM здесь не добавляет интеллекта.
Оно лишь заменяет гарантированный результат вероятностным.
Это примерно то же самое, что использовать нейросеть вместо калькулятора.
Технически возможно.
Практически бессмысленно.
Настоящая ценность ИИ в работе с неопределённостью
Есть область, где языковые модели действительно совершают революцию.
Это задачи, в которых невозможно заранее перечислить все варианты ответа.
Человек пишет письмо свободным языком.
Клиент формулирует проблему своими словами.
Документ составлен без единого шаблона.
На встрече обсуждали десятки тем одновременно.
Именно здесь классические алгоритмы начинают ломаться.
Не потому что они плохие.
Потому что невозможно заранее предусмотреть все возможные формулировки.
LLM умеет работать именно с этой неопределённостью.
Она не заменяет алгоритмы.
Она закрывает задачи, которые раньше вообще невозможно было автоматизировать.
Именно поэтому искусственный интеллект следует рассматривать не как замену традиционной автоматизации, а как следующий уровень, который включается только тогда, когда предыдущие перестают работать.
Самая дорогая ошибка - использование ИИ "потому, что сейчас так делают"
Технологии всегда проходят через период увлечения.
Когда появились микросервисы, ими пытались заменить монолит даже там, где это не имело смысла.
Когда стали популярны Kubernetes, многие разворачивали его для одного приложения на одном сервере.
Сегодня похожая история происходит с LLM.
Любой процесс пытаются превратить в агента.
Любую интеграцию сделать интеллектуальной.
Любой workflow заменить цепочкой промптов.
Но зрелая инженерия редко следует моде.
Она следует принципу достаточности.
Каждый компонент системы должен оправдывать своё существование.
ИИ не исключение.
Если его убрать и ничего не изменится, значит он был не нужен.
Простая модель выбора технологии
За последние годы я пришёл к очень простой последовательности, которую использую практически для любой новой задачи.
Перед внедрением ИИ стоит пройти четыре уровня.
Уровень 1. Детерминированный алгоритм
Если задачу можно решить программным кодом, SQL-запросом, регулярным выражением, BPMN-процессом или набором правил — на этом стоит остановиться.
Это наиболее дешёвое, быстрое и надёжное решение.
Уровень 2. Классическое машинное обучение
Если задача требует прогнозирования, классификации или поиска закономерностей в числовых данных, имеет смысл использовать традиционные модели машинного обучения.
Они значительно более предсказуемы, чем большие языковые модели, и легче контролируются.
Уровень 3. Большая языковая модель
Когда появляется необходимость понимать естественный язык, работать с неструктурированными документами, извлекать смысл или генерировать новый текст, приходит время LLM.
Именно здесь они создают максимальную ценность.
Уровень 4. Агентная система
И только когда задача требует автономного планирования, последовательного использования множества инструментов, изменения стратегии по ходу выполнения и длительной работы без участия человека, появляется смысл строить агентную архитектуру.
Это самый сложный уровень.
И применять его стоит только тогда, когда предыдущие три действительно недостаточны.
Не стройте систему вокруг ИИ
Мне кажется, сегодня происходит интересная подмена понятий.
Многие начинают проектирование с вопроса:
«Как встроить сюда ИИ?»
Но правильный вопрос другой.
«Какую проблему мы решаем и какой самый простой инструмент способен её решить?»
Иногда ответом окажется обычная функция.
Иногда SQL.
Иногда workflow.
Иногда модель машинного обучения.
Иногда LLM.
Иногда агент.
И это нормально.
Хорошая архитектура никогда не начинается с выбора самой модной технологии.
Она начинается с выбора технологии, которая создаёт максимальную ценность при минимальной сложности.
Большие языковые модели - одно из самых значимых достижений современной разработки. Они уже изменили подход к работе с текстом, знаниями, поиском информации и взаимодействию человека с программным обеспечением.
Но из этого не следует, что ими нужно заменять любую автоматизацию.
Детерминированные алгоритмы обладают качествами, которых у вероятностных моделей никогда не будет: воспроизводимостью, проверяемостью, предсказуемостью и гарантированным результатом при одинаковых входных данных.
Поэтому архитектура надёжных систем должна строиться по простому принципу.
Всё, что можно реализовать детерминированно, должно оставаться детерминированным.
Искусственный интеллект стоит подключать только там, где традиционные методы действительно достигают своих пределов.
Такой подход не ограничивает использование ИИ.
Наоборот, он позволяет применять его именно там, где он создаёт максимальную ценность, не превращая каждую бизнес-задачу в ещё одну вероятностную систему с дополнительной стоимостью, дополнительной сложностью и ещё одной точкой отказа.
Команда платформы Botman.one предлагает вам консалтинг и автоматизацию: анализ процессов + автоматизация с помощью платформы и доступных на ней нейросетей.
Мы можем сами сделать автоматизацию под заказ или вы можете самостоятельно атоматизировать процессы на платформе.
Тут можно попробовать: ссылка.
Проходите бесплатный курс по автоматизации: ссылка
Заходите в Телеграм-группу, где мы обсуждаем технологии: ссылка
Смотрите наши обучающие видео: ссылка
Заглядывайте в нашу базу знаний Legaltech: ссылка