ML vs LLM: 4 сценария, когда агенты на основе ML эффективнее больших моделей

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

ML vs LLM: 4 сценария, когда агенты на основе ML эффективнее больших моделей

В 2023 году чат-боты на базе больших языковых моделей писали средние тексты, объясняли сложные темы простым языком и помогали с переводами. Это были LLM почти в чистом виде – они работали с одношаговыми задачами и никак не взаимодействовали с окружающим миром.

За три года чат-боты научились планировать шаги, использовать внешние инструменты и данные, помнить контекст, рассуждать и перепроверять себя. Сейчас это полноценные агенты с большими языковыми моделями в «мозгах».

Что тогда лежит в основе запроса на «корпоративный LLM», разбираемся в статье.

Пробежимся по терминам

Large Language Model – механизм предсказания следующего токена в последовательности, обученный на огромных массивах текстов.

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

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

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

Чтобы LLM хоть что-то могла сама, вокруг модели нужно построить инфраструктуру из четырех компонентов:

1. RAG (Retrieval-Augmented Generation) – система поиска по корпоративным документам.

2. Multi Step Reasoning – размышление, при котором модель бьет задачу на множество маленьких логических шагов.

3. Function Calling – механизм «вызова» внешних инструментов.

4. Агентский цикл (ReAct) – архитектура «наблюдение → размышление → действие».

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

Основных типов агентов в корпоративном сегменте всего три:

1. Полуавтономные агенты. Самостоятельно выполняют комплексные задачи, обращаются к внешним сервисам. Human-in-the-loop: переходят к критичным этапам после подтверждения человека.

2. Автономные агенты. Работают без участия человека от постановки задачи до результата.

3. Мультиагентные системы. Координирующиеся агенты, параллельно работающие над комплексными задачами. Оркестрацией занимается агент-тимлид: он учитывает инструкции и корректирует взаимодействие внутри группы агентов.

Полной автономности не будет – человек так или иначе контролирует действия агента. В январе ИИ-ассистент без разрешения потратил с карты пользователя 7 тысяч долларов. В бизнесе риски подобных инцидентов кратно выше.

ML vs LLM: 4 сценария, когда агенты на основе ML эффективнее больших моделей

Зачем делать с нуля, если можно взять готовое

Логичный вопрос: почему бы не взять уже готовые продукты от OpenAI, Google или Anthropic, которые умеют все, что нужно. Нельзя – по нескольким причинам.

Первая – утечки. В апреле 2023 года инженеры Samsung за 20 дней трижды слили конфиденциальные данные в ChatGPT: исходный код системы измерения оборудования, код для идентификации дефектных чипов и расшифровку конфиденциального совещания. В итоге Samsung ввел полный запрет на использование ChatGPT и локально развернул собственное решение.

Недавно стало известно, что Copilot Chat обрабатывал и делал саммари конфиденциальных писем из папок «Отправленные» и «Черновики». Специальную метку и политики DLP, которые должны были не пустить ИИ к чувствительным данным, ассистент успешно проигнорировал. Microsoft признала ошибку и уже все пофиксила, но тема ущерба от таких инцидентов все еще не раскрыта.

Вторая – требования регулятора. Использовать зарубежные чат-боты рискованно, а на объектах КИИ вообще запрещено.

Третья – требования безопасности. Интегрировать внешний, тем более иностранный, сервис с инструментами внутри корпоративной инфраструктуры не разрешит ни одна служба ИБ. Не говоря уже об уязвимостях к промпт-инъекциям, которые неоднократно признавали в том же OpenAI (хотя проблемы честно пытаются решить).

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

А выгодно ли запускать такой проект?

Да, если агент нужен, чтобы помочь разработчикам, автоматизировать процессы бэк-офиса или разгрузить первую линию клиентской поддержки. Для работы с текстовыми данными – отличное решение. Во многих остальных случаях внедрение универсального «умного» чат-бота не окупается по нескольким причинам.

Это долго

Даже при наличии готовой команды и дорожной карты проекта, путь до прода может занять от 6 месяцев до года. А в enterprise-реальности с учетом согласований, тестирования на безопасность и доработок под legacy-системы проект легко растягивается на 12-18 месяцев.

Это дорого

Привести в порядок хранилище данных, развернуть и дообучить модель, настроить интеграции – все это в моменте требует инвестиций в команду и инфраструктуру. Чтобы решение корректно работало 24/7, придется постоянно вкладывать в мониторинг модели и работу с Data Quality. В большинстве проектов вложения будут существенно выше экономической выгоды от автоматизации процессов.

Это не всегда эффективно и выгодно

В core-процессах, где требуется точность, чат-боты на базе LLM пока не дают результат, сравнимый с классическими ML-решениями.

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

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

Сценарии, когда LLM не нужны (ну почти)

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

Сценарий 1. Урегулирование страховых выплат

Клиент подает заявление, прикладывает документы в разных форматах и качестве. Специалист вручную анализирует информацию, проверяет соответствие полиса, рассчитывает покрытие и принимает решение о выплате.

Средний цикл урегулирования для стандартных случаев составляет 1-2 недели, для сложных – от месяца.

Решение: полуавтономный агент (ML + OCR + RAG)

Агент извлекает данные из заявлений и фото/видео с помощью технологии распознавания символов. Затем классифицирует инцидент, проверяет полис по базе договоров и готовит расчет выплаты. Простые случаи закрываются полностью автоматически за 24–48 часов, сложные — передаются специалисту с отчетом и предварительным расчетом.

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

Сценарий 2. Обнаружение мошеннических действий в реальном времени

Rule-based системы (заранее заданные формальные правила для определения подозрительных операций) и ML-решения эффективны в типовых случаях. Более сложные инциденты требуют ручного рассмотрения. Команды загружены расследованиями инцидентов и не успевают выявлять комплексные схемы мошенничества.

Тип решения: мультиагентная система (ML & Deep Research)

Мультиагентная система анализирует все транзакции в режиме реального времени. Агент-аналитик выявляет подозрительные паттерны, агент-исследователь проверяет историю клиента через Deep Research, третий формирует отчет и рекомендации. Система может самостоятельно блокировать транзакции в заранее определенных сценариях, оставляя человеку роль контроля.

Результаты: типовые случаи разрешаются автоматически. Точность выявления мошенничества растет на 65%, а ресурсы команды высвобождаются на расследование комплексных схем.

Сценарий 3. Восстановление и сверка конструкторского состава изделия

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

Тип решения: полуавтономный агент (ML + OCR + RAG)

Агент извлекает информацию из файлов и сканов конструкторской документации (чертежи, спецификации, ведомости) с помощью OCR и layout-aware parsing, сравнивает её с актуальными данными в PDM и показывает все расхождения.

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

Результаты: качество данных в системах растет, снижается вероятность ошибок. Ускоряется подготовка к производству.

Сценарий 4. Видео-аудит безопасности и SOP

Промышленное предприятие или склад контролирует соблюдение техники безопасности и стандартных операционных процедур (SOP). Сотрудники вручную просматривают записи с камер или проводят выборочные проверки. Часть опасных ситуаций остаются без внимания.

Тип решения: автономный агент (Computer Vision)

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

Результаты: непрерывный контроль безопасности и профилактика инцидентов. Аудиторы тратят на 40-50% меньше времени на проверки.

Что в итоге

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

Для задач с высокой вариативностью текста (юридические консультации, генерация кода, работа с документацией) такие вложения могут быть оправданы. Но для core-процессов, где критичны точность, скорость отклика и предсказуемость, универсальный LLM-агент — избыточное и рискованное решение.

Более выгодная и эффективная стратегия — гибридный подход: использовать LLM как «клей» между системами (генерация отчетов, извлечение смысла из неструктурированных запросов), но оставить тяжелую обработку данных (компьютерное зрение, анализ временных рядов, точные расчеты) специализированным ML-моделям и классическим алгоритмам.

1
1
1 комментарий