Блеск и нищета ML‑автоматизации

Рынок ML‑автоматизации в России переживает второе рождение. Первое было классическим ML: деревья решений, CatBoost, XGBoost, скоринговые модели. В эту эпоху «ML для бизнеса» означало аккуратный пайплайн на табличных данных с дата‑сайентистом, неделями настраивающим гиперпараметры. Второе рождение произошло благодаря LLM в агентном режиме, и эти роды получаются не легче первых.

Дело в том, что мы отстаем от мира в среднем на 1–1.5 года, и это отставание неравномерное: в одних нишах разрыв меньше, в других больше. Неравномерность отставания и создает ту странную картину, которую сейчас видит на рынке почти каждый интегратор: индустрия предлагает клиенту вчерашнюю архитектуру, а клиент, начитавшись свежих обзоров, уже просит завтрашнюю.

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

Клиент приходит с запросом в духе: «хотим платформу для ИИ‑автоматизации, соберите нам ее, а дальше мы сами будем запускать модели, менять их на более новые и так далее». По сути, клиент просит ML‑автоматизацию малой кровью, без постоянной зависимости от подрядчика.

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

У этих двух вариантов на первый взгляд разная архитектура, но на самом деле одна и та же логическая ошибка ^[1]: и в том, и в другом случае бизнесу пытаются продать один универсальный «мозг», который должен одинаково хорошо закрывать вообще все задачи компании, от звонков в контакт‑центре до анализа юридических договоров.

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

Сейчас представитель клиента открывает чат‑бота и сам за пять минут выясняет, чем RAG отличается от fine‑tuning и почему модель нужно дообучать строго под свои данные и процессы. Асимметрия исчезла. В итоге на встрече звучит фраза, которая ломает бизнес‑модель интегратора:

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

А отдельная задача, дообученная под данные конкретной компании, это по определению не то, что можно тиражировать в следующем проекте без переделки.

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

Low‑code частично снимает кадровый голод при сборке сценариев, но бессилен там, где упирается в качество самих моделей ^[2].

Здесь важно разделить два разных явления, которые вносят путаницу:

• Оркестрационный слой (интеграции, вебхуки, HTTP‑тулы, маршрутизация вызовов между системами) растет и никуда не денется, потому что решает задачу интеграции систем, а не задачу качества модели.

• Идея одной большой модели‑монолита как источника интеллекта ^[3] для всех задач умирает, потому что клиент теперь точно знает: без специализации под конкретную задачу и конкретные данные результат будет посредственным везде понемногу.

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

Во‑первых, локализация (ч. 5 ст. 18): с 1 июля 2025 года, после поправок 23-ФЗ, первичный сбор и запись персональных данных россиян через зарубежные базы прямо запрещены.

Во‑вторых, основание обработки и договор поручения (ст. 6): если данные по вашему заданию обрабатывает облако, SaaS или модель, с обработчиком должен быть оформлен договор поручения, и без него сама передача данных обработчику уже будет нарушением, еще до всякой утечки.

В‑третьих, отдельное и часто забываемое требование заключается в уведомлении РКН о трансграничной передаче персональных данных до ее начала (ст. 12), если обработчик физически находится за пределами РФ. Эта процедура не закрывается ни локализацией, ни договором поручения.

Западные облачные сервисы в большинстве случаев не дают закрыть ни второе, ни третье требование в принципе (здесь и далее популярное изложение логики закона, а не юридическая консультация).

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

Open‑source модели, поднятые в российском облаке с должным образом оформленными отношениями с провайдером, закрывают требование закона, а прямой вызов зарубежного облачного API для реальных ПДн без локального периметра является стабильным источником юридического риска ^[4].

Даже если персональных данных у вас нет, постоянное использование облачных моделей ведет к утечке коммерческой информации ^[5]. Через небольшой промежуток, необходимый для дообучения, фронтир‑модель будет успешно рекомендовать ваши подходы конкуренту, который будет задавать вопросы в чате. И это не пустая угроза ^[6].

Второй вариант предлагаемой системы выглядит так: купить мощный GPU‑сервер и поднять локально одну модель уровня 200–400B параметров как есть, без дообучения, в расчете на то, что она одинаково хорошо закроет любую задачу компании. Проблема в том, что модели общего назначения оптимизированы быть достаточно хорошими во всем, а не отличными в чем‑то одном, а бизнесу почти всегда нужно второе.

Академический cost‑benefit анализ разворачивания LLM на своем железе ^[7] показывает: крупные open‑weight модели вроде Qwen3-235B требуют кластера ценой свыше $200 тысяч, и хотя технически такие модели приближаются по качеству к топовым закрытым аналогам, это идет рука об руку с существенно возросшей операционной сложностью, а не с готовым результатом «из коробки».

Эксплуатация открытых моделей в корпоративной среде описывает типичную эволюционную кривую: путь идет от промпт‑инжиниринга через RAG к parameter‑efficient fine‑tuning и далее к полному continued pre‑training под домен, то есть развертывание модели «как есть» это начальная, а не конечная точка.

Более широкий обзор реальных производственных агентных систем ^[8] показывает, что там, где команды все же обходятся без дообучения (70% из 20 задокументированных кейсов), это почти всегда облачные API топовых зарубежных моделей, а не самостоятельно поднятые локально гиганты 200–400B, то есть массовый успешный сценарий «без дообучения» это чужая облачная инфраструктура, а не свой дорогой кластер ради того же самого недообученного универсала.

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

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

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

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

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

RAG

RAG для юротдела и внутрикорпоративный RAG это две разные системы по устройству, содержанию и доступу.

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

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

Исследования подтверждают, что для юридических задач именно точность на уровне отдельного пункта договора становится узким местом: бенчмарк по оценке LLM на выявление юридических рисков на уровне статей договора ^[9] показывает, что открытым моделям требуется прицельное дообучение именно потому, что точность заметно проседает на длинных или редко встречающихся формулировках пунктов, то есть то, что в общей корпоративной базе знаний просто не является проблемой, поскольку там нет такой концентрации юридически значимых деталей на пункт текста.

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

Помимо разницы между юридическим и корпоративным RAG, разобранной выше, есть и общая для всех разновидностей RAG картина. Работа по сравнению fine‑tuning и retrieval для внедрения знаний показывает, что дообучение эффективно дополняет RAG, привносня почти столько же точности, сколько и RAG сам по себе.

Получается, что RAG это «справочник» для точного поиска фактов, а дообучение это «усвоенные знания» для воспроизведения формата, стиля и специфической структуры ответа.

Каждый конкретный RAG‑контур (юридический, бухгалтерский, HR, техническая поддержка) это отдельный микросервис с собственным набором источников, политикой доступа и собственной степенью дообучения поверх retrieval, а не один общий индекс на всю компанию.

IDP

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

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

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

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

Здесь разрыв между «из коробки» и «дообучено» едва ли не самый измеримый. В свежей работе по адаптации моделей распознавания речи NVIDIA Canary под задачи контакт‑центра ^[10] дообучение на реальных телефонных записях снизило долю ошибок распознавания символов с 23,31% до 9,04% на шумной телефонной аудиозаписи, а на бизнес‑критичных сущностях, именах и адресах: с 16,98% до 3,78%. Для голосового бота это разница между «понял адрес доставки с первого раза» и «не понял и переспросил в третий раз, клиент положил трубку».

Похожая история со стилем общения агента: дообучение модели на симулированных диалогах на выборке всего в 100 примеров стабильно превосходило по естественности тона попытки добиться того же через системный промпт. Промпт‑инжиниринг в общем интерфейсе просто не дает того же контроля над стилем, что тюнинг весов конкретного речевого микросервиса.

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

В исследовании LoRA Land ^[11] протестировали 310 дообученных моделей на 31 задаче и получили превосходство над GPT-4 в 25 из 31 случая, в среднем на 10 пунктов точности. Независимое исследование сравнило GPT-3.5/GPT-4 и Claude Opus в zero‑shot режиме с дообученными моделями меньшего размера на классификации тональности, одобрения/неодобрения, эмоций ^[12] и политических позиций, и дообучение с данными конкретного приложения выигрывало во всех случаях.

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

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

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

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

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

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

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

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

Но это касается самых простых, типовых документов типа счета (инвойса). Как только речь заходит об объемных документах, нетиповых макетах или низком качестве сканов, точность распознавания общих моделей без дообучения падает.

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

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

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

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

Универсальные фронтир модели отлично подходят для этапа MVP и сложных задач на логику ^[13], а также для написания действительно сложного кода (например, драйверов), но в фазе оптимизации Unit‑экономики и качества специализированные микросервисы становятся неизбежностью.

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

Рынок ML‑автоматизации проходит ту же эволюцию ^[14], что веб‑разработка два десятилетия назад, от монолита к микросервисам. Индустрия сейчас совершает ту же ошибку, что совершали ранние веб‑разработчики, пытавшиеся масштабировать монолит вместо того, чтобы разбить его на сервисы: пытается продать клиенту одну модель (облачную или локальную) как универсальное решение, отставая на свои 1–1.5 года от осознания этого факта.

Реальная архитектура, к которой медленно, но верно идет рынок, содержит два слоя:

• Слой оркестрации (интеграции, вебхуки, HTTP‑тулы, маршрутизация вызовов между системами и между самими ML‑микросервисами): здесь low‑code инструменты вроде n8n реально хороши и никуда не денутся, потому что это задача интеграции, а не задача качества модели.

• Слой специализированных ML‑микросервисов (ASR под шумную телефонию, классификатор тикетов, RAG для юротдела отдельно от корпоративного RAG, экстрактор бухгалтерских документов отдельно от анализатора договоров, суммаризатор протоколов с верификацией фактов): каждый компонент дообучен под свою узкую задачу и данные конкретной компании, общается с остальными по API, и не может быть куплен один раз и продан еще сотне клиентов без переделки, потому что данные и требования каждого клиента уникальны.

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

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

Для клиента это тоже вызов: вместо одной удобной кнопки он получает под капотом зоопарк из нескольких ML‑микросервисов со своими требованиями к железу и обслуживанием.

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

• Иллюзия «Low‑Code своими силами»: экономит бюджет на инженерах и позволяет быструю сборку, но упирается в потолок качества универсальных моделей «из коробки».

• Архитектура специализированных ML‑микросервисов: обеспечивает необходимую точность и безопасность, но заставляет платить «MLOps‑налог».

Если у компании нет собственного штата дата‑сайентистов и MLOps‑инженеров, надежда «купить low‑code платформу и отдать ее бизнес‑аналитикам» не сработает в задачах высокой точности.

Low‑code хорошо подходит для слоя оркестрации, но сопровождение качества, валидация датасетов и мониторинг дрифта специализированных моделей неизбежно потребуют перехода на долгосрочный сервисный аутсорсинг со стороны интегратора или обслуживание собственной ML командой.

Заключение

Для бизнес‑модели интеграторов происходящее на рынке означает конец схем «написал ядро один раз и продал его сто раз», но не конец рынка ML‑автоматизации как такового.

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

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

Любая универсальная модель, запущенная «из коробки» без прицельной адаптации под контекст компании (будь то продвинутые Few‑Shot/RAG‑пайплайны, DSPy или fine‑tuning под специфичные данные), на узких задачах неизбежно дает лишь посредственный результат.

В итоге клиенты приходят к разделению архитектуры на два уровня: управление оркестрационным слоем (интеграции, сценарии, вебхуки) переходит во внутреннюю эксплуатацию компании, а разработка и fine‑tuning узкоспециализированных ML‑микросервисов ведутся под конкретные данные и бизнес‑задачи (от юридического RAG и бухгалтерского OCR до классификаторов и речевых агентов).

---

Спасибо, что дочитали. Здесь должна быть ссылка на мой ТГ‑канал… но у меня его нет. Я никуда никого не зазываю, не продаю курсы или консультации и не встраиваю скрытую рекламу.