Математика или программирование? Какие знания нужны ML‑специалисту

Александр Сербул

Руководитель больших данных, высоконагруженных систем и машинного обучения Битрикс24

Для Tproger поговорили с Александром Сербулом, руководителем ML‑направления в Битрикс24. Он рассказал, как не застрять на старте и почему в ML инженерная культура важнее модных нейросетей. Внутри — о том, когда градиентный бустинг лучше LLM, почему код нужно покрывать тестами, как работать с нехваткой данных и на что смотреть при выборе команды.

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

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

Кем должен быть ML‑специалист — математиком или программистом

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

Сколько математики нужно в ML

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

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

Как развиваться в ML и не застрять на старте

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

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

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

Что с большими языковыми моделями

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

Но инженеру важно понимать, что промт не заменяет модель, это просто способ задать контекст, как преднастройка перед задачей. За ней всё тот же набор весов и вероятностных расчётов. Ошибка — считать промты заменой инженерной работы.

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

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

Какие методы сейчас реально работают

По данным Александра, для бизнес‑задач нет универсального решения, но есть набор проверенных инструментов. Если данные категориальные — лучше использовать градиентный бустинг, например CatBoost или XGBoost. Эти методы часто точнее нейросетей и требуют меньше подгонки.

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

Если данных мало или вычислительных мощностей не хватает, помогает байесовский подход. Он хорошо ведёт себя на шумных и несбалансированных выборках, где другие методы не подходят или не работают. Отдельное направление — оптимизация моделей. Уменьшение моделей через compression позволяет запускать их на обычных серверах без потери точности — актуально для компаний без GPU‑кластеров.

Когда ML действительно нужен

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

Если данных мало, лучше брать байесовские методы или простые классификаторы — они устойчивее и не требуют много ресурсов. То же самое касается бизнес‑кейсов, где результат критичен, а точность нужно проверять.

Решение в пользу ML — это не вопрос нового стека, а вопрос наличия данных и понимания задачи. Если подход классических алгоритмов решает проблему быстрее и дешевле, значит, выбираем его.

Что делать, если данных мало

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

Полезно искать и дополнительные источники сигналов. Если пользователь бросил корзину в интернет‑магазине, это может быть прокси‑признак будущей покупки. Такие косвенные данные часто помогают вытащить модель на нужный уровень точности.

Где ML приносит реальную пользу бизнесу

Александр приводит примеры из практики Bitrix24. Один из самых ощутимых по эффекту — скоринг лидов и сделок. Там используется логистическая регрессия и градиентный бустинг. Метод простой, но позволяет заметно повысить точность прогнозов и напрямую влияет на выручку.

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

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

Пример: текст "машина" при длине шингла 3 даёт набор шинглов: "маш", "аши", "шин", "ина". 

Дальше можно сравнивать эти множества и вычислять похожесть, например через коэффициент Жаккара. 

В Bitrix24 метод шинглов помогает системе одинаково понимать обращения пользователей на разных языках или с разными формулировками.

Как проверить, что модель действительно работает

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

Дальше важно понимать метрики: precision, recall, F1 и другие. Они показывают, на сколько точно модель попадает в нужные ответы и сколько ложных срабатываний допускает. Не стоит воспринимать метрики как формальности — от них зависит, будет ли решение полезно для бизнеса.

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

Если ML‑модель не выигрывает по скорости или точности, её не стоит внедрять. Тестировать нужно на реальных данных и регулярно пересматривать результаты, особенно если бизнес‑процессы меняются.

Какие инструменты и ресурсы использовать

Основная экосистема машинного обучения сегодня крутится вокруг Python, и начинать логично с него. Хороший старт — realpython.com, где подробно объясняются основы языка и приёмы написания читаемого кода.

Но нужно развивать инженерные привычки. Александр рекомендует читать книги вроде Effective Java Джошуа Блоха, чтобы прокачивать культуру разработки и понимать многопоточность. Даже если вы работаете с Python, знания из других языков помогают писать лучше и думать о производительности.

Из библиотек стоит освоить PyTorch или TensorFlow для нейросетей и scikit‑learn для классического ML. При росте нагрузки полезно переписывать критичные части на Java или Rust — это уменьшает задержки и делает систему устойчивее.

Как набраться практики и выбрать правильную команду

Лучший способ вырасти в ML — попасть туда, где есть реальные данные и сильная инженерная культура.

Идите в крупные компании вроде Яндекса, ВК, Сбера или X5 — там есть инфраструктура, процессы и опытные коллеги. Просто читать статьи и собирать pet‑проекты недостаточно, если не сталкиваешься с настоящими продуктами и их ограничениями.

Главный признак хорошей команды — наличие тестов, QA и понятного кода. Если в отделе этого нет, нужно уходить, иначе быстро потеряешь профессиональный уровень. ML уже давно не чудо‑технология, а инструмент. И успех зависит не от того, кто первым применил нейросеть, а от того, чья команда умеет держать систему в рабочем состоянии и проверять результаты каждый день.

В конце хочется спросить: как вы сами учились или учитесь ML — через курсы, проекты или книги? Делитесь своим опытом и мыслями в комментариях — обсудим, какие подходы к обучению и работе в ML работают сегодня.