Почему знание математики не гарантирует работу

Неприятная правда для начинающих в Data Science:

Хорошая математика ≠ готовность к реальной работе.

Можно понимать:

👉 линейную алгебру
👉 статистику
👉 градиентный спуск
👉 вероятности

И всё равно провалиться на практике.

Почему так происходит

Потому что работа Data Scientist — это не только формулы.

Это ещё:

👉 грязные данные
👉 непонятные требования
👉 слабые baseline’ы
👉 странные бизнес-ограничения
👉 коммуникация с людьми

В реальности задача редко выглядит как в учебнике.

Математика помогает, но не заменяет практику

Математика даёт понимание:

👉 почему модель работает
👉 где она может сломаться
👉 как читать метрики
👉 как не верить магии

Но она не научит:

👉 чистить данные
👉 строить pipeline
👉 писать production-код
👉 делать нормальный train/test split
👉 объяснять результат бизнесу

Главная ошибка новичков

Они думают:

«Сначала выучу всю математику, потом начну проекты».

Проблема в том,
что «вся математика» не заканчивается никогда.

Работу дают не за знание формул,
а за способность решать задачи.

Что реально смотрят на собеседованиях

Обычно хотят понять:

👉 можешь ли ты работать с данными
👉 понимаешь ли метрики
👉 умеешь ли делать baseline
👉 видишь ли leakage
👉 можешь ли объяснить решение
👉 есть ли у тебя проекты

Математика важна.
Но сама по себе она не продаёт тебя как специалиста.

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

Лучший путь:

👉 учить математику по мере необходимости
👉 параллельно делать проекты
👉 разбирать ошибки моделей
👉 писать код руками
👉 учиться объяснять выводы простыми словами

Теория должна усиливать практику,
а не заменять её.

Главный инсайт

Математика — это фундамент.
Но дом строится не фундаментом одним.

В одном предложении

Чтобы получить работу в DS/ML, мало знать формулы —
нужно уметь превращать данные в работающие решения.

Кошмар вайбкодера

xCode Journal

Data Fest в гостях у ВТБ

24 мая ВТБ открывает двери Loft Hall на Автозаводской — будет день докладов, нетворкинга и не душных разговоров про Data Science и карьеру в индустрии.

В программе:
• Data Fusion — кейсы от DS-команды ВТБ
• Mathematics & ML
• ML в рекламе и маркетинге
• Open Career — честно про карьеру в DS

Программу и спикеров можно посмотреть тут, регистрацию лучше не откладывать — места на площадке ограничены.

📍 24 мая, Loft Hall (зал Ratusha)
⏰ С 11:00 до вечера
📌 Вход бесплатный, при регистрации указывайте ФИО и опыт в DS/ML

Feature Engineering важнее выбора модели

Самый непопулярный факт в ML:
модель — это не главное.

Можно часами выбирать между:
XGBoost
LightGBM
CatBoost
…и получить +1% к качеству.

А можно поменять фичи — и получить +20%.

Разберёмся, почему так 👇

Модель учится только на том, что ты ей дал

Garbage in → garbage out

Если признаки:
- шумные
- нерелевантные
- плохо отражают задачу

👉 никакая модель не спасёт

Даже самая большая.

Пример из жизни

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

Фичи:
- возраст
- город
- тариф

Модель: ок, но слабый результат

Добавили:
- время с последнего действия
- частоту использования
- изменение активности

👉 резкий рост качества

Почему?
Потому что фичи начали отражать реальное поведение

Feature Engineering = внедрение знаний о задаче

Модель не знает:
- бизнес
- контекст
- причинно-следственные связи

Зато ты знаешь.
И когда ты создаёшь фичи —
ты “вшиваешь” это знание в данные.

Модель vs Фичи

Что меняем → эффект

Модель → +1–5%
Гиперпараметры → +1–3%
Feature Engineering → +10–50%

Где FE особенно решает

- Табличные данные
- Маленькие датасеты
- Бизнес-задачи

👉 там, где нет миллионов примеров, фичи — это всё

Когда модель важнее
- CV (изображения)
- NLP (тексты)
- Speech

👉 там фичи учатся автоматически

Почему все игнорируют FE

Потому что:
- это сложно
- это долго
- нет “магической кнопки”
- требует понимания данных

Гораздо проще:
“давай попробуем ещё одну модель”

Главный инсайт

ML — это не соревнование моделей.
Это соревнование представлений данных.

В одном предложении

Лучший способ улучшить модель —
👉 перестать тюнить модель и начать тюнить данные

⁣Почему нормализация данных иногда ухудшает модель

Новички в ML часто слышат:

«Всегда нормализуй данные».

И начинают масштабировать всё подряд.

А потом качество модели… падает.

Почему так происходит?

Потому что нормализация нужна не всегда.

Что вообще делает нормализация

Она приводит признаки к одному масштабу.

Например:

👉 возраст → 18–60
👉 зарплата → 1000–100000

После scaling:

👉 значения становятся сопоставимыми
👉 обучение становится стабильнее

Когда нормализация действительно нужна

Особенно важна для моделей,
чувствительных к масштабу:

👉 Logistic Regression
👉 Linear Regression
👉 SVM
👉 KNN
👉 Neural Networks

Без scaling такие модели могут работать хуже
или обучаться нестабильно.

А теперь главное

Деревьям scaling обычно не нужен.

Это:

👉 Random Forest
👉 XGBoost
👉 LightGBM
👉 CatBoost

Почему?

Потому что деревья делают split’ы:

feature < threshold

Им неважно:

👉 0.5 это или 5000
👉 масштаб почти не играет роли

Как нормализация может ухудшить модель

1. Добавляет шум

Иногда scaling:

👉 размывает распределения
👉 усиливает выбросы
👉 ухудшает separability

Особенно на плохих данных.

2. Ломает интерпретируемость

Было:

👉 доход = 5000

Стало:

👉 доход = -0.73

Бизнесу это уже сложнее объяснять.

3. Неправильный scaling = leakage

Классическая ошибка:

👉 scaling на всём датасете
👉 потом split

Test уже «утёк» в train.

4. CatBoost может стать хуже

CatBoost хорошо работает с:

👉 категориальными фичами
👉 исходными распределениями

Иногда лишний preprocessing только мешает.

Самый важный инсайт

Scaling — это не «улучшение данных».

Это инструмент под конкретную модель.

Что делать на практике

Простое правило:

👉 линейные модели / distance-based → scaling нужен
👉 деревья → обычно не нужен

В одном предложении

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

Как крепкий фундамент в ML работает в любой сфере

Выпускница ШАДа Дарима Мылзенова применяла одно и то же ML-мышление в медицине (анализ КТ-снимков), нефтянке (изучение недр), стартапе по синтезу речи, а теперь — в финтехе. В интервью 8бит она рассказала про изнанку инженерии.

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

⁣Почему open-source модели меняют рынок AI

Ещё пару лет назад казалось,
что AI будет полностью контролироваться
несколькими большими компаниями.

У кого больше GPU и денег —
тот и главный.

Потом появились:

👉 Llama
👉 Mistral
👉 DeepSeek
👉 Qwen
👉 Phi

И стало понятно,
что рынок пойдёт совсем по другому сценарию.

Дело не только в качестве

Самое интересное,
что open-source модели меняют индустрию
не только из-за качества.

Хотя с качеством у них уже всё довольно неплохо.

Проблема в другом:

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

Сегодня API работает.
Завтра:

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

И ты ничего не контролируешь.

Почему open-source меняет правила игры

С open-source всё иначе.

Хочешь:

👉 запускай локально
👉 дообучай
👉 квантизируй
👉 меняй inference stack
👉 оптимизируй latency
👉 держи данные внутри компании

Для бизнеса это огромная разница.

Особенно там, где:

👉 приватные данные
👉 compliance
👉 большие объёмы запросов
👉 дорогой inference

Есть ещё один важный эффект

Open-source очень быстро двигает индустрию вперёд.

Потому что тысячи инженеров:

👉 тестируют модели
👉 находят слабые места
👉 пилят оптимизации
👉 делают inference-движки
👉 выпускают fine-tuning инструменты

Прогресс идёт не сверху вниз,
а сразу со всех сторон.

Что особенно интересно сейчас

Иногда маленькая open-source модель
на хорошем inference pipeline
ощущается полезнее огромной закрытой LLM.

Особенно в проде.

Потому что в реальности важны не только benchmark’и.

Важны:

👉 цена
👉 контроль
👉 latency
👉 стабильность
👉 возможность встроить модель в систему

Главная мысль

Кажется, рынок AI постепенно уходит от идеи:

«Одна гигантская модель для всего».

К модели:

«Много специализированных моделей
под конкретные задачи».

Устал инициализировать претрейны весами Qwen? Приходи к нам — мы честно учим с нуля! 😉

Ищем Senior/Senior+ AI Engineer и продактов в RnD-команду: как отдельных специалистов, так и целые команды, — которые готовы разрабатывать прорывные AI-решения.

Познакомиться ближе с нашими направлениями и оставить отклик можно на сайте.

А если хотите следить за тем, как команда RnD ML Сбера исследует и разрабатывает AI-технологии, — подписывайтесь на Telegram-канал команды. Там делятся исследованиями, экспериментами и инсайтами из мира AI, а также свежими вакансиями 🚀

Галлюцинации LLM: где модель помогает, а где уверенно врёт

Большие языковые модели выглядят как всезнающие эксперты. Текст гладкий, уверенный, логичный. Ровно до тех пор, пока не выясняется, что все это были галлюцинации. Давай разберёмся, где галлюцинации — это ожидаемое поведение модели, а где они quietly превращаются в серьёзную проблему.

1. Где галлюцинации — это «нормально»

Модель не знает, она продолжает
LLM — это не база фактов, а сверхмощный автодополнитель. Её цель — сгенерировать правдоподобное продолжение, а не истину.

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

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

2. Где начинаются проблемы

Фактические вопросы
Чат-бот уверенно сообщает неверные даты, имена и события. И пользователь принимает это за правду.

Генерация кода
• Функции, которых не существует.
• API, которых никогда не было.
• Код выглядит правильно — пока не запускаешь.

Критические домены
Юриспруденция, медицина, финансы. Здесь «звучит убедительно» = потенциальная катастрофа.

Уверенный тон без знаний
Самое опасное — модель не сомневается. Она не краснеет, не делает пауз, не оговаривается.

3. Что реально снижает галлюцинации

RAG (привязка к данным)
Модель отвечает не «из головы», а по конкретным документам. Есть источник — меньше фантазий.

Дообучение и выравнивание
RLHF, domain fine-tuning, обучение говорить «я не уверен». Модель учат быть осторожной, а не болтливой.

Чёткие инструкции:
— отвечай только по контексту
— если не знаешь — скажи
— обоснуй каждый шаг

Иногда этого уже достаточно.

• Пост-проверки и правила
• Тесты для кода
• Проверка ссылок
• Фильтры на запрещённые паттерны

Попросить модель:
— проверить себя
— оценить уверенность
— пересмотреть ответ

4. Что отличает надёжную систему от «просто LLM»

— Модель не единственный источник истины
— Есть данные, проверки и ограничения
— Ошибка ловится до пользователя
— Уверенность ≠ корректность

Галлюцинации — это не «плохая модель». Это следствие того, что LLM всегда старается ответить. И если не обложить её контекстом, проверками и правилами, она будет стрелять в ногу ровно так же уверенно, как и рассуждать.

Data Science

Agentic Vision: Google превращает зрение модели в рабочий процесс

Google quietly выкатили Agentic Vision для Gemini 3 Flash, и это довольно важный сдвиг в том, как модели работают с изображениями. Вместо привычного «посмотри на картинку и ответь» теперь используется полноценный цикл Think–Act–Observe: модель сначала анализирует изображение и строит план, потом запускает код для обработки — детекцию, расчёты, измерения — и только после этого возвращается к рассуждению уже с новыми данными в контексте. Проще говоря, картинка превращается не в статичный вход, а в рабочее пространство для мышления. Типовой пример — подсчёт пальцев: модель не угадывает число, а реально детектит каждый палец, считает боксы и выводит результат. Лучше всего это заходит на сложных таблицах, схемах и мелких деталях, где обычное «визуальное понимание» раньше сыпалось. По метрикам прирост относительно обычной Gemini 3 Flash — в среднем 5–10%, а попробовать фичу уже можно и через API, и в AI Studio.

Data Science