Не всё надо решать LLM. Где в продакшене побеждают бустинги, эмбеддинги и правила

Привет! На связи Катерина Лапаева, руководитель агентства в сфере AI – GIGASCHOOL. В мае наша команда проектировала AI-трек на одной из самых масштабных конференций для разработчиков на Урале – UWDC 2026, где мы запустили дискуссию. Обсудили, когда нужны большие языковые модели, а когда задачу проще, дешевле и надёжнее решить другими технологиями.

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

В дискуссии приняли участие:

Камиль Шакиров

AI-инженер в компании ДАР

Камиль занимается агентскими сервисами и AI-системами в комбинации CV, классического ML и LLM; уверен, что проблемы решаются не только одной LLM;

Никита Овчинников

ML-инженер RUTUBE

Никита разрабатывает RAG-системы, агентов и NLP-решения, имеет опыт ^[1] в CV и считает, что в этой области много где ещё можно применить классический ML, не переходя на LLM.

Ян Анисимов

Tech Lead DS/DS+, Yandex Practicum,
Head of SDD, Insit Telecom, ментор AI Talent Hub

Ян сторонник классической разработки и интеграции решений в телекоме.

В этой статье основные выводы и интересные мысли из дискуссии.

Где проходит граница между классической разработкой, ML и LLM?

Сейчас можно сказать, что если данные не про текст – добро пожаловать в мир машинного обучения ^[2]. Но всё-таки появляется третье измерение, которое говорит нам, что в бизнесе есть классическая разработка, ML и LLM как отдельная история, которая встаёт между ними. 

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

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

«Мы используем классический ML как опору для ответа LLM, потому что отдавать без анализа цифры и категории – это риск не подтвердить, почему та или иная LLM-ка так решила. Плюс, сервис начинает зависеть от того, что сегодня эта модель так работает, а завтра вышла другая, и приходится заново всё пересобирать, – Камиль Шакиров.

Почему бизнес по-прежнему выбирает классический ML

Значительную часть обсуждения посвятили базовым моделям и универсальным архитектурам.

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

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

«Если у вас есть ограничения на время и ресурсы, зачем тянуть трансформер, если лог-рег или линейная регрессия будут работать с удовлетворяющим вас качеством? Ради любви к искусству? Ну, может быть», – Ян Анисимов.

Почему выигрывают гибридные архитектуры?

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

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

«В гибридных системах и больших пайплайнах ошибка ^[3] не просто суммируется – она мультиплицируется и накапливается. Чем серьёзнее ошибка на первом этапе, тем страшнее она будет на втором и т. д. Нужно строить пайплайны так, чтобы самые точные алгоритмы были как можно выше.», – Никита Овчинников.

В итоге получаем такое распределение уверенности: 

1. Правила, эвристики (бизнес-логика) и регулярные выражения – это базовый слой, где результат заранее известен. Он служит надежной опорой и позволяет реализовать fallback-сценарии.

2. Классический ML – следующий уровень: модель обучена на итеративно собранных данных, её поведение ^[4] предсказуемо, ей можно больше доверять;

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

Что тяжелее поддерживать в продакшене: ML или LLM?

Если коротко: ML сложнее на входе, но легче потом, а LLM – наоборот.

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

С LLM так не выйдет, потому что крупные модели выходят раз в 3 месяца и ведут себя по-разному. Получить демо-результат можно буквально за 2 минуты, но затем нужно постоянно контролировать качество ответов, тестировать новые версии и валидировать результаты.

«Если хотите причинить боль ^[5] любому, кто разрабатывает и использует LLM в продукте, просто спросите, как он валидирует результаты модели. В этом плане классический ML более статичен и детерминирован, то есть результаты обучения таких моделей гораздо проще валидировать. У классических ML‑моделей (например, SVM) есть устоявшиеся метрики, которые хорошо интерпретируются и понятны бизнесу, даже могут быть объяснены через деньги.

А чтобы понять, не ошиблась ли LLM, нужно делать достаточно большую обвязку и провести много монотонной ручной работы с данными», – Никита Овчинников.

Дрейф данных и деградация моделей

Спикеры отметили, что деградировать могут не только LLM. Классические ML-модели тоже ломаются, когда статистически меняется распределение данных. В качестве яркого примера вспомнили февраль–март 2020 года и пандемию COVID-19. Тогда многие модели столкнулись с тем поведением ^[6] пользователей, которого раньше никогда не было, весь мир круглые сутки сидел дома. 

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

Что в итоге?

В ходе дискуссии стало понятно, что противопоставлять ML и LLM, пожалуй, не совсем корректно. Наши спикеры не выступали ни за один из лагерей на 100% – все говорили про компромиссы, фишки и ограничения каждого подхода. 

А какой опыт был у вас? Приходилось ли вам в своих проектах использовать LLM вместо ML или, наоборот, отказываться от LLM в пользу более простых решений? Где, на ваш взгляд, лучше всего работают правила, где побеждают бустинги и классические модели, а где уже не обойтись без LLM?

Давайте продолжим это обсуждение в комментариях? Делитесь своими кейсами, будет интересно узнать случаи из вашей практики.