Блеск и нищета ML-автоматизации: от гигантских LLM-монолитов к микросервисной архитектуре

Сфера автоматизации процессов с помощью машинного обучения проходит очередной этап трансформации. Первый этап строился на классических алгоритмах: дереве решений, градиентном бустинге вроде CatBoost или XGBoost и скоринговых системах. В тот период внедрение машинного обучения в корпоративные процессы требовало тщательной работы дата-сайентистов над табличными данными и многонедельного подбора гиперпараметров.

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

Типичный запрос против типичного предложения

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

В ответ интеграторы обычно выдвигают одно из двух стандартных предложений:

• Готовая коробочная подписка на внешнюю облачную модель (обычно обернутая в сервис вроде Claude или аналогичные API);
• Установка мощного локального сервера с одной гигантской языковой моделью для всех задач компании.

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

Раньше заказчик получал всю информацию о нейросетях исключительно от самого продавца. Это позволяло легко продавать один и тот же монолитный программный продукт разным клиентам, меняя лишь визуальный интерфейс и брендинг. Сегодня асимметрия информации исчезла. Представитель заказчика может за считаные минуты выяснить разницу между RAG-архитектурой и дообучением (fine-tuning) и осознать, почему нейросеть необходимо адаптировать под специфику конкретного бизнеса.

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

При этом спрос на решения в области искусственного интеллекта продолжает расти. По данным исследований Gartner, доля корпоративных продуктов со встроенными ИИ-агентами должна увеличиться с менее чем 5% до 40% к концу 2026 года. Значительная часть этого роста приходится на low-code и no-code платформы, так как квалифицированных инженеров для создания агентных систем с нуля катастрофически не хватает. Инструменты low-code позволяют ускорить сборку логики и сценариев, но они не способны исправить проблемы, вызванные низким качеством самих моделей.

Здесь важно четко разграничивать два компонента систем:

1. Оркестрационный слой: интеграции, вебхуки, вызовы HTTP-инструментов и маршрутизация между сервисами. Этот слой активно развивиается и решает задачи связывания систем, а не качества генерации нейросетей.
2. Слой моделей: концепция единой облачной или локальной модели-монолита постепенно отмирает, поскольку без глубокой специализации под конкретный контекст качество работы нейросети останется посредственным во всех сферах.

Если архитектура базируется на вызове внешней облачной LLM через API, бизнес в России неизбежно сталкивается с жесткими законодательными ограничениями по 152-ФЗ:

• Требование к локализации (ч. 5 ст. 18): нормы 23-ФЗ с 1 июля 2025 года прямо запрещают первоначальный сбор и запись персональных данных граждан РФ с использованием иностранных баз данных.
• Оформление поручения на обработку (ст. 6): передача персональных данных в стороннее облако или SaaS-сервис требует обязательного наличия официально оформленного договора поручения. Без такого документа сам факт передачи данных является правонарушением.
• Уведомление Роскомнадзора (ст. 12): при трансграничной передаче информации обязательна процедура предварительного уведомления регулятора. Никакие локальные договоры или договоры поручения не отменяют необходимость выполнения этой нормы, если сервер обработки физически находится за пределами страны.

Западные облачные сервисы практически никогда не обеспечивают соблюдение этих требований. По этой причине при наличии необезличенных персональных данных работа возможна исключительно в российском контуре: либо на базе проверенных отечественных облаков (Yandex Cloud, Sber AI, VK Cloud) с оформлением договора поручения, либо на собственном серверном оборудовании в РФ. Прямые вызовы зарубежных API без изолированного периметра несут в себе высокие юридические риски.

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

Второй вариант — развертывание собственного GPU-сервера для запуска локальной модели размером 200–400B параметров без дообучения — также имеет существенные изъяны. Модели общего назначения проектируются так, чтобы быть приемлемыми во всем понемногу, тогда как бизнесу требуется максимальная точность в конкретных операциях.

Анализ затрат на развертывание открытых LLM показывает, что содержание крупной open-weight модели уровня Qwen3-235B требует инфраструктурного кластера стоимостью более $200 000. Хотя по качеству такие нейросети приближаются к топовым закрытым аналогам, их эксплуатация сопровождается высокой операционной сложностью. Внедрение открытых моделей в компании обычно проходит путь от базового промпт-инжиниринга к RAG-системам, затем к эффективному дообучению параметров (PEFT) и далее к полному дообучению под предметную область. Поэтому запуск модели «как есть» — это лишь начальный этап работы.

Обзоры практического использования агентных систем показывают: в 70% из 20 изученных кейсов, где команды обходились без fine-tuning, применялись топовые зарубежные облачные API, а не локально подгруженные гиганты на 200–400B параметров. Сценарий работы без дообучения оказывается эффективным в чужом облаке, но не оправдывает себя при создании дорогостоящего собственного кластера ради одной универсальной модели.

От монолита к микросервисам

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

Сегодня с машинным обучением происходит аналогичный процесс. Вместо одной громоздкой модели бизнес переходит к ансамблю специализированных агентов и компактных нейросетей (размером от 1B до 80B параметров). Каждый такой компонент оптимизируется под конкретную задачу, собственный массив данных и правила доступа, после чего объединяется с остальными через API под управлением оркестратора.

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

RAG (Retrieval-Augmented Generation)

Внутренняя база знаний компании и RAG-система для юридического отдела принципиально отличаются по архитектуре и правилам доступа. Корпоративная вики (HR-регламенты, инструкции) ориентирована на широкий охват пользователей и не требует критической точности до каждого знака. Юридический же RAG (договоры, судебная практика) ограничен в доступе из-за конфиденциальности и требует максимальной точности на уровне конкретных пунктов и оговорок.

Тесты показывают, что при поиске правовых рисков точность базовых моделей существенно снижается на нестандартных и длинных формулировках статей, требуя точечного fine-tuning. Хотя топовые облачные решения справляются с правовыми вопросами неплохо, при потоковой обработке документов их задержка, высокая стоимость вызовов и риски утечки данных делают применение узкоспециализированной компактной модели, обученной структурированному извлечению, более выгодным.

Кроме того, дообучение отлично дополняет RAG-механику: если RAG выполняет роль внешней базы фактов, то fine-tuning задает верный формат, специфический стиль и структуру ответа. В результате каждый RAG-контур (юридический, бухгалтерский или технический) становится отдельным микросервисом со своими источниками и настройками.

IDP (Интеллектуальная обработка документов)

Распознавание документов в бухгалтерии и юридическом отделе требует разных подходов. В бухгалтерском учете основной поток состоит из актов, счетов и УПД с четкой табличной структурой, где необходимо извлекать позиции, цены и НДС. В юридическом отделе обрабатываются многостраничные договоры свободной формы, где критична сохранность формулировок и оговорок на любых страницах. Дообучение нейросети на юридических текстах значительно снижает уровень галлюцинаций при извлечении специфических сущностей (суммы компенсаций, форс-мажорные условия, реквизиты сторон).

Входящие звонки и голосовые агенты

Разница между базовой версией нейросети и специализированной моделью наиболее ощутима в обработке речи. Исследования по адаптации нейросети распознавания речи NVIDIA Canary для контакт-центров показали: при fine-tuning на реальных аудиозаписях доля ошибок в символах (CER) на шумных телефонных линиях снизилась с 23,31% до 9,04%. Ошибки в распознавании имён, адресов и ключевых параметров уменьшились с 16,98% до 3,78%. Адаптация стиля общения нейросети на датасете всего из 100 целевых диалогов показала лучшую естественность речи, чем попытки скорректировать тон через обычный системный промпт.

Роутинг заявок и классификация обращений

В исследовании LoRA Land при тестировании 310 дообученных моделей на 31 классификационной задаче компактные специализированные нейросети опередили GPT-4 в 25 случаях, показав прирост точности в среднем на 10 процентных пунктов. Сравнение zero-shot работы флагманских моделей (GPT-4, Claude Opus) с небольшими fine-tuned моделями подтвердило: на специфических данных приложения дообученная компактная модель стабильно выигрывает. В задачах маршрутизации заявок в Service Desk (где может быть от 40 до 200 узких категорий) базовая модель путается, и один только промпт-инжиниринг не решает проблему.

Совещания и протоколы

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

Распознавание документов

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

Почему одна модель не может закрыть все эти задачи?

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

Каждая из этих задач требует противоположных векторов оптимизации. Универсальные фронтирные модели идеальны на этапе прототипирования (MVP) или для решения сложных логических задач, но при оптимизации Unit-экономики и качества специализированные микросервисы становятся единственным рабочим решением.

Куда все движется?

Рынок ML-автоматизации неизбежно переходит на двухуровневую архитектуру:

1. Слой оркестрации: инструменты класса low-code (например, n8n) отлично подходят для вызова HTTP-методов, обработки вебхуков и связи систем между собой.
2. Слой специализированных ML-микросервисов: распознавание речи для телефонии, классификатор тикетов, изолированный юридический RAG, экстрактор данных из первичных документов и сервис суммаризации совещаний. Каждый модуль обучается под специфику конкретной компании и обменивается данными по API.

Главный минус такого подхода — необходимость уплаты так называемого «MLOps-налога». Интеграторы больше не могут продавать одно коробочное решение сотням клиентов. Каждое внедрение превращается в сервисный инжиниринг с подготовкой датасетов, разметкой и дообучением. В свою очередь, заказчик вместо простой системы получает инфраструктуру из нескольких нейросетевых сервисов, требующих квалифицированного обслуживания.

В результате бизнес сталкивается с выбором:

• Попытка сделать всё на Low-Code своими силами: снижает расходы на инженеров, но упирается в ограничение качества коробочных нейросетей.
• Архитектура ML-микросервисов: гарантирует необходимую точность, безопасность и соответствие закону, но требует постоянных затрат на MLOps.

Заключение

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

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

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

Как запустить Qwen3.8-Flash-Next 125B на 6 ГБ VRAM

Интересным примером оптимизации нейросетевых архитектур стал запуск открытой модели Qwen3.8-Flash-Next с 125 млрд параметров, построенной на архитектурных решениях будущей серии Qwen4. Согласно бенчмаркам, модель демонстрирует результаты, сопоставимые с топовыми закрытыми фронтирными решениями в задачах написания кода, работы с агентами и сценариях computer use.

Нам удалось развернуть полный чекпоинт Qwen/Qwen3.8-Flash-Next на одной потребительской видеокарте NVIDIA RTX 4090. При этом пиковое потребление видеопамяти (VRAM) составило всего 5,95 ГБ. Запуск производился без применения 4-битной квантизации или дистилляции — использовался оригинальный чекпоинт в формате bf16, генерирующий стандартный поток токенов. По данным тестов Qwen, модель показывает высокие результаты в сравнении с решениями уровня Opus 4.6 Max, открывая новые возможности для локального использования мощных нейросетей на доступном аппаратном обеспечении.

Источник: habr.com