Data Science | Machinelearning [ru]

⁣Feature-wise Gradient Noise Injection против концептуального дрейфаКонцептуальный дрейф — это когда модель резко теряет качество, потому что данные поменялись. В online-пайплайнах это проблема номер один. Модель банально переобучается под текущее распределение, а при сдвиге — всё, метрики летят в тартарары. Ретрейнинг? Запаздывает. Детекция дрейфа? Тоже не сразу, да и переразметка нужна. Есть штука поизящнее — Feature-wise Gradient Noise Injection.Суть методаКоротко: добавляем шум к градиентам, но не абы как, а для каждого признака отдельно, с учётом его дисперсии в батче. Это мешает модели выучивать хрупкие паттерны, которые типичны для дрейфа. Признаки с высокой дисперсией — те, что чаще всего и дрейфуют — получают больше шума, их влияние на обновление весов снижается. Модель учится обобщать, а не запоминать случайные корреляции.Почему это работаетШум адаптируется под текущее распределение — если дисперсия меняется при дрейфе, шум автоматически подкручивается. И никакой отдельный детектор не нужен, регуляризация уже вшита в обучение. На мини-батче считаем дисперсию каждого признака σ²_j. Потом к градиенту по этому признаку добавляем шум N(0, λ·σ²_j). λ — гиперпараметр.Пример на PyTorchimport torchdef add_feature_wise_noise(grad, features, lambda_noise=0.01): var = features.var(dim=0, unbiased=True) noise = torch.randn_like(grad) * (lambda_noise * var.sqrt()) return grad + noisefor x_batch, y_batch in dataloader: pred = model(x_batch) loss = criterion(pred, y_batch) loss.backward() for param in model.parameters(): if param.grad is not None: param.grad = add_feature_wise_noise(param.grad, x_batch) optimizer.step() optimizer.zero_grad()Практические советы и предупреждения- λ — ключевой параметр. Слишком маленький — эффекта ноль. Слишком большой — модель перестанет сходиться. Я обычно начинаю с 10⁻³ и подбираю по валидации на исторических дрейфах. Это типичная ошибка — не настраивать λ под конкретные данные.- FGNI не отмен

⁣Batch-level caching для эмбеддингов: как не пересчитывать одно и то же в real-timeВ production рекомендательных системах и NLP-сервисах узкое место часто — генерация эмбеддингов. Когда на один user request нужно проинференсить десятки кандидатов, каждый запрос требует векторного представления каждого объекта. Латенси растет, и специалисты часто упускают простой оптимизационный трюк: кэширование в рамках батча, а не глобальное.Почему batch-level caching?Запросы к инференс-сервису приходят батчами. Если вычислять эмбеддинги для каждого кандидата заново, число вызовов модели растет линейно с числом запросов и объектов в каждом. Однако многие объекты повторяются между запросами: топ-рекомендуемые товары, популярные тексты, частые сущности. Batch-level caching решает это дедупликацией ID внутри одного батча, минимизируя повторные вычисления.Как это работаетСобираете все ID объектов из всех запросов батча, дедуплицируете их, вычисляете эмбеддинги только для уникальных ID, затем раздаете результаты через маппинг. Пример на Python:def process_batch(batch_requests): all_unique_ids = {} for req in batch_requests: for item_id in req['item_ids']: all_unique_ids[item_id] = True unique_ids_list = list(all_unique_ids.keys()) embeddings_map = compute_embeddings(unique_ids_list) results = [] for req in batch_requests: req_embeddings = [embeddings_map[i] for i in req['item_ids']] results.append(compute_scores(req['user_vec'], req_embeddings)) return resultsПроизводственный примерДопустим, у вас сервис для скоринга объявлений в real-time: 100 запросов в батче, каждый с 50 item'ами, но уникальных — всего 200. Без кэширования — 5000 вызовов модели эмбеддингов, с batch-level — 200. Сокращение в 25 раз. Для критичного по latency пайплайна это разница между SLA violation и стабильной работой.Практический совет и trade-offsДобавьте LRU-кэш второго уровня для hot items с TTL в 1 минуту. Batch-level — первый фильтр, отсекающий дубликаты вн

⁣Feature-wise quantization-aware training для production inference: как сохранить метрики при внедрении 4-битных моделей на GPU с ограниченной памятьюКвантование до INT4 в продакшене режет память, но часто убивает метрики на чувствительных признаках. Обычный QAT усредняет scale на весь тензор, и редкие, но критичные фичи затираются. Feature-wise QAT решает это на уровне отдельных признаков.Почему обычный QAT ломает метрикиСтандартное квантование обучает единый scale для всего тензора. В production-моделях, особенно в рекомендательных системах или NLP, некоторые признаки имеют высокую дисперсию или распределены неравномерно. Пример — эмбеддинги редких сущностей или временные ряды с выбросами. Один scale усредняет эти выбросы, и модель теряет важные нюансы, теряя 2-5% на задачах классификации и регрессии.Как работает Feature-wise QATВместо общего scale ты учишь отдельные параметры для каждого признака: scale и zero-point. Во время fine-tuning модель подстраивает каждый канал под искажения при 4-битном представлении. Псевдокод кастомного слоя:class QuantLayer(nn.Module): def __init__(self, num_features, bits=4): super().__init__() self.scales = nn.Parameter(torch.ones(num_features)) self.zero_points = nn.Parameter(torch.zeros(num_features)) self.max_val = 2**(bits-1) - 1 def forward(self, x): x_scaled = x / self.scales x_quant = torch.clamp(torch.round(x_scaled), -self.max_val, self.max_val) return x_quant * self.scalesПрактический совет: используй learnable параметры, инициализированные из предварительной калибровки на репрезентативном датасете. Это ускоряет сходимость и снижает риск переобучения.Production-метрики и trade-offsНа BERT-подобных моделях FWQAT даёт прирост F1 на 2-3% относительно обычного QAT. ResNet-50 теряет всего 0.5% против FP32, тогда как стандартный QAT режет 2-3%. Типичная ошибка — тонкий fine-tuning без репрезентативной выборки. Для стабильности нужно минимум 1% обучающих данных с сох

⁣Positional attention decay в transformer-моделях: как информация вымывается из середины контекста и что с этим делать в productionДаете модели длинный документ, она уверенно отвечает на вопросы по началу и концу, но проваливается, когда ответ зарыт в середине. Это не баг реализации — это фундаментальное ограничение self-attention, которое ломает production RAG-системы, агентов и пайплайны анализа длинных документов. Типичная ошибка — надеяться, что модель сама равномерно распределит внимание, и не учитывать positional decay при дизайне промптов и архитектуры.Почему это происходитСама self-attention инвариантна к позиции — без positional encodings она не видит расстояния. Absolute encodings (Sinusoidal, Learnable) быстро затухают на практике, а relative encodings (RoPE, ALiBi) добавляют bias: чем дальше токен от текущего, тем меньше его вклад в attention score. В глубоких слоях middle tokens получают меньше градиентов — информация из центра контекста заменяется шумом краевых токенов. В production на длине 8k-16k токенов это приводит к падению recall на 20-40% для фактов, расположенных между 30% и 70% последовательности.Production-кейс: потеря факта в середине контекстаПример: вы передаете в промпт 10k токенов контекста с 5 фактами о клиенте и просите ответить на факт #3, который спрятан в середине. Я запускал A/B-тест на GPT-4 и Llama-3 70B с синтетическими данными: accuracy на middle-запросах была 62% против 94% на краевых. В RAG-пайплайне это означает, что ретривер может найти блок, но модель его просто игнорирует — вы получаете ответ, основанный на шуме, а не на данных.Практические приемы для production1. Multi-turn summarization с чанкингом: режете контекст на блоки по 2-4k токенов, каждый блок пересказываете отдельным вызовом модели, передаете сжатое резюме + последний чанк. Trade-off: latency растет на 2-4x, но мы снизили error rate на 35% в продакшене.2. Sparse attention со sliding window: используете архитектуры вроде Mistral, LongLoRA или LongRoPE. Глобальн

⁣Label Leakage: когда валидация врет, а метрики — это иллюзияРадуешься ROC-AUC 0.99 на сложном пайплайне, а в проде модель выдает 0.6? Знакомо. Это label leakage — утечка таргета. Но часто проблема не в банальной ошибке вроде scaler.fit(X_train, y_train). Скрытые пути хитрее, и они любят засады на middle/senior уровнях.1. Агрегаты с прицелом на будущееКлассика в feature engineering. Допустим, считаешь среднее по категории:df['avg_target_by_city'] = df.groupby('city')['target'].transform('mean')Если делаешь это на всем датасете до разбивки на train/val, модель на валидации видит среднее, посчитанное с учетом future-меток. Метрики взлетают, в проде — провал. Решение: агрегаты строго в рамках train-фолда через target_encoding в Pipeline или GroupKFold. И никаких transform до split.2. Time-aware валидация: иллюзия порядкаВременные ряды без строгого разбиения по времени — утечка из-за shuffle. Модель на валидации подсматривает данные из будущего. Простое правило: никакого train_test_split с random_state. Используй TimeSeriesSplit или PurgedGroupTimeSeriesSplit. И проверяй lag-фичи — они любят заглядывать вперед. Типичная ошибка: добавление rolling-агрегатов на всем датасете, а не в рамках временного окна.3. Фичи-строки, которые знают ответБывает, поле user_flag появляется только после события (таргета). Или transaction_id коррелирует с таргетом: новые транзакции — выше риск дефолта. Удали ID-поля, проверь корреляцию с таргетом. Значение >0.95 — явный leakage. Еще один production-пример: в NLP пайплайне, когда токен документа использется как фича, но он присваивается после разметки таргета. Это ломает валидацию в LabelPropagation на stream-данных.Как детектировать скрытые утечки * Lasso-регрессия: если модель оставляет 1-2 фичи с огромными весами — red flag. * Permutation importance: аномально высокое падение метрики при перестановке одной фичи. * Lookahead bias audit: проверь, что признаки вычисляются на момент t-1, а не t. Используй reverse-engineering на отложенной

⁣Стабильность градиентов при длинных последовательностях: как Spherical Gradient защищает от взрывов и затуханий в online-обучении временных рядовВ онлайн-обучении временных рядов градиенты либо взрываются, либо затухают на длинных последовательностях. LSTM и GRU справляются нестабильно: при потоковых данных модель не успевает адаптироваться к новым паттернам из-за экспоненциального роста или схлопывания градиента.Проблема стандартного Gradient ClippingКлассический gradient clipping с фиксированным порогом часто ломается в online-режиме. При коротких последовательностях он обрезает слишком агрессивно, теряя информацию о редких событиях. А при длинных — не защищает от затухания, так как работает только с верхней границей нормы.Spherical Gradient: принцип и реализацияПодход нормирует градиент на каждом шаге, фиксируя его длину при сохранении направления. Это L2-нормировка, которая решает обе проблемы:- Градиент не взрывается, так как норма ограничена (например, 1.0)- Градиент не затухает, так как даже при норме около нуля восстанавливается до фиксированного значенияПример на PyTorch для production-сценария:def spherical_gradient_clip(grad, max_norm=1.0, eps=1e-8): norm = grad.norm() if norm > max_norm: return grad * (max_norm / norm) elif norm < eps: return torch.randn_like(grad) * eps return gradИнженерные trade-offs в production MLКомбинируйте Spherical Gradient с layer normalization и gradient checkpointing при длине последовательности >500 шагов (финансы, IoT, логи). Внимание: нормировка градиента увеличивает latency на ~5-10%, но стабильность сходимости окупается на реальных данных. Типичная ошибка — применять Spherical Gradient к Transformer без нормировки весов, что ломает attention scores при большой разрядности.Практический совет по валидацииДля online-обучения на стрим-данных сравните variance градиентов до и после применения на синтетике с length=500. В production на Transfomer для временных рядов Spherical Gradient показывает сниж

⁣Delayed feedback в CVR-моделях: как не сломать обучение и оценку конверсий из-за запаздывающих лейбловВ CVR пользователь может конвертироваться через минуты, дни или недели после клика, поэтому разметка «как есть» часто превращает будущие positive в ложные negative. Это критично для рекламы, рекомендаций, marketplace-воронок и A/B-тестов, где модель обучается на неполных логах.Проблема: лейбл может быть еще не созрелДля клика в момент click_time = t мы хотим оценить:P(conversion | click, x)Но на дату сборки датасета T мы знаем только одно из двух:* конверсия уже произошла до T* конверсии пока не видноВторой случай не равен converted = 0. Это censored observation: объект наблюдался недостаточно долго.Типичная ошибка:converted = 1, если conversion_time - click_time <= 7dconverted = 0, иначеТак свежие клики получают искусственно заниженный CVR, модель учится на ложных negative, offline-метрики зависят от «зрелости» среза, а production-калибровка плывет: модель предсказывает full-window CVR, а мониторинг видит partial-window CVR.Baseline: обучаться только на mature dataЕсли целевой горизонт - конверсия за 7 дней, а данные доступны до 2025-01-31, то в train стоит брать клики не позже 2025-01-24.Плюсы:* честные лейблы* простая валидация* легко дебажить пайплайн и leakageМинусы:* теряем свежие данные* хуже адаптация к сезонности и изменению трафика* при длинном conversion lag train сильно устареваетПрактический совет: явно храните в feature store или training dataset поля event_time, label_observed_until, horizon и label_age. Без них невозможно воспроизвести разметку и понять, почему CVR изменился после очередного retraining.Более сильный подход: моделировать задержкуМожно разложить задачу на вероятность конверсии и распределение delay:P(y = 1, delay <= H | x)Например:* CVR-модель оценивает вероятность самой конверсии* delay-модель оценивает P(delay <= age | y=1, x)Это ближе к survival analysis: есть событие, time-to-event и censored observations. Такой подход особенно по

Обновили encoder - сломали ANN? Как мигрировать эмбеддинги без болиВ embedding-based системах encoder - это часть контракта данных. Его нельзя обновлять как обычную ML-модель: в ANN-индексе уже лежат вектора из старого пространства, и частая ошибка - считать совместимость гарантированной из-за той же размерности и метрики.Почему совместимость ломаетсяДаже если размерность та же, cosine тот же, а offline-бенчмарк лучше, новый encoder не обязан быть совместим со старым индексом.После обновления меняются:- геометрия пространства;- распределение норм;- локальные окрестности;- ranking ближайших соседей;- калибровка score’ов;- поведение ANN-структуры: HNSW/IVF/PQ строились под старое распределение.Главный анти-паттерн: писать новые документы новым encoder’ом в старый индекс со старыми embedding’ами.Такой индекс становится смешанным: часть векторов живёт в одном пространстве, часть - в другом. ANN формально работает, но nearest neighbors уже не имеют корректной семантики.Версионируем embedding space как production contractВерсионировать нужно не просто model_name, а полный контракт:embedding_version = encoder + tokenizer + pooling + normalization + dim + metricЕсли поменялось что-то из этого - это новая версия пространства.Практический совет: храните embedding_version рядом с документом, запросом, индексом и retrieval-логами. Иначе при деградации recall или CTR вы не поймёте, какой encoder реально участвовал в выдаче.Поднимаем новый индекс и включаем dual-writeСтарый путь:docs_v1 -> embeddings_v1 -> ann_index_v1Новый путь:docs_v2 -> embeddings_v2 -> ann_index_v2Даже если документы те же, embedding’и должны быть пересчитаны новым encoder’ом. Для ANN это новый corpus.Важно: параметры индекса тоже стоит перетюнить. Например, для HNSW старые M, efConstruction, efSearch могут быть не оптимальны для нового распределения.На время миграции новые и обновлённые документы пишем в обе версии:on_document_upsert(doc): emb_v1 = encoder_v1(doc) emb_v2 = encoder_v2(doc) index_v1.u

Как находить вредные обучающие примеры перед fine-tune: influence functions, TracIn и data pruning в production MLВ production ML «плохие» train-примеры могут стоить дорого: кластер mislabeled, устаревших или аномальных объектов способен стабильно ухудшать fine-tune на свежем срезе данных. Частая ошибка - чистить датасет только по эвристикам и не проверять, какие samples реально увеличивают loss на production-like validation.1. Influence FunctionsИдея: оценить, как изменится loss на validation-примере z_val, если немного увеличить вес train-примера z_train.I(z_train, z_val) ≈ - ∇L_val^T H^-1 ∇L_trainгде H - Hessian по параметрам модели.Если influence большой и положительный, train-пример, вероятно, увеличивает validation loss и вредит качеству.Плюсы:- аккуратная теоретическая постановка;- можно связывать конкретные train-примеры с конкретными ошибками модели.Минусы:- дорогой H^-1;- плохо масштабируется на большие нейросети;- чувствителен к non-convexity, batchnorm/dropout, чекпоинтам и приближению Hessian.В production обычно используют приближения: LiSSA, conjugate gradients, low-rank approximation или считают influence только для последнего слоя / head модели.2. TracInБолее инженерный вариант: train-пример полезен для val-примера, если их градиенты по ходу обучения направлены похоже. Вреден - если направлены противоположно.TracIn(z_train, z_val) = Σ_c η_c · ∇L_train(θ_c) · ∇L_val(θ_c)где θ_c - чекпоинты, η_c - learning rate.Сильно отрицательный score означает: train-пример тянет модель против направления, полезного для validation.Мини-скетч для последнего слоя:for ckpt in checkpoints: model.load_state_dict(load(ckpt)) g_val = mean_grad(model.head, val_loader) for i, batch in enumerate(train_subset): g_train = grad(model.head, batch) scores[i] += lr[ckpt] * dot(g_train, g_val)harmful = argsort(scores)[:K]Практический совет: считайте score не по всему validation, а по важным production-срезам: новые пользователи, редкие классы, проблемные регио

Temporal leakage в feature store: как point-in-time joins, backfill’ы и проверка каузальности фичей спасают модель от красивой offline-метрики и провала в продеTemporal leakage в feature store - один из самых дорогих способов получить отличную offline-метрику и бесполезную модель в production. Проблема не в том, что фича плохая, а в том, что на train она знает больше, чем модель знала бы в момент принятия решения.Предсказываем churn на дату t, а в фичах используем transactions_last_30d, посчитанный после backfill’а из таблицы, куда транзакции доехали с задержкой или были пересчитаны с учетом будущих исправлений.Offline все красиво. Online - просадка.1. Point-in-time join - базовая защитаДля каждой строки обучения есть prediction_time. Фичи должны быть взяты в том состоянии, в котором они были доступны на этот момент.Важно различать:- event_time - когда событие реально произошло;- ingestion_time / created_at - когда оно попало в систему;- available_at - когда фича стала доступна модели;- prediction_time - момент прогноза.Правильный join должен учитывать не только event_time <= prediction_time, но и available_at <= prediction_time:WITH ranked_features AS ( SELECT l.entity_id, l.prediction_time, f.feature_value, ROW_NUMBER() OVER ( PARTITION BY l.entity_id, l.prediction_time ORDER BY f.event_time DESC ) AS rn FROM labels l JOIN features f ON f.entity_id = l.entity_id AND f.event_time <= l.prediction_time AND f.available_at <= l.prediction_time)SELECT *FROM ranked_featuresWHERE rn = 1;Если нет available_at, вы часто не можете доказать, что leakage отсутствует.2. Backfill’ы - скрытый источник утечкиBackfill опасен тем, что создает иллюзию исторической полноты.Например, сегодня вы пересчитали фичу за прошлый год:- исправили старые события;- добавили данные из нового источника;- поменяли business logic;- подтянули late-arriving events;- использовали справочник, которого тогда еще не было.В резул

Конформные интервалы в production ML при covariate shift: как держать coverage без бесполезно широких предсказанийSplit conformal хорошо работает при exchangeability: train, calibration и test приходят из одного распределения. В production это часто ломается из-за гео, девайсов, каналов, сезонности или смены acquisition mix, а типичная ошибка - просто расширить интервалы “с запасом”.Что именно ломаетсяПри covariate shift имеем:p_prod(x) != p_cal(x)но предполагаем, что p(y|x) примерно сохраняется. Если считать обычный conformal quantile на старом calibration set, coverage на текущем трафике может просесть.Наивное решение - увеличить correction глобально. Coverage частично вернется, но price prediction interval, ETA interval или forecast band станут настолько широкими, что downstream-система перестанет им доверять.Базовый production-рецепт1. Учим quantile-модель:q_low(x), q_high(x)2. На calibration set считаем nonconformity scores:s_i = max(q_low(x_i)-y_i, y_i-q_high(x_i), 0)3. Оцениваем importance weights:w_i ~= p_prod(x_i) / p_cal(x_i)4. Берем не обычный, а weighted quantile score'ов.5. Для нового объекта строим:C(x) = [q_low(x)-tau, q_high(x)+tau]Минимальный скелет:import numpy as npdef weighted_quantile(values, weights, q): order = np.argsort(values) v = np.asarray(values)[order] w = np.asarray(weights)[order] cw = np.cumsum(w) return v[np.searchsorted(cw, q * cw[-1])]alpha = 0.1scores = np.maximum(q_low_cal - y_cal, y_cal - q_high_cal, 0)weights = ratio_model.predict_weight(X_cal)tau = weighted_quantile(scores, weights, 1 - alpha)low = q_low_prod - tauhigh = q_high_prod + tauТак calibration distribution становится ближе к production distribution без грубого раздувания всех интервалов.Как не получить слишком широкие интервалыОдин глобальный tau часто переоценивает неопределенность, если ошибка модели сильно зависит от x.Практически помогают:- CQR вместо point prediction: Conformalized Quantile Regression уже мод

Совет на ближайшие годы — изучайте ВАЙБ-КОДИНГИИ уже пишет код, чинит баги, генерирует тесты, документацию и помогает запускать продукты быстрее, чем это делали классические команды разработки. И это уже не "будущее когда-нибудь", а реальность, которая меняет рынок уже сегодняИ те, кто научится вайбкодить сейчас, будут увереннее конкурировать на рынке и зарабатывать больше тех, кто по-прежнему делает всё вручную.Стартовать с нуля поможет канал Вайб-кодинг. Там ребята круглосуточно мониторят более 320 российских и зарубежных источников и публикуют только главное: релизы, инструменты, гайды, курсы и практические кейсы.Подписывайтесь, нас уже 45 тысяч: @vibecoding_tg

⁣Corpus drift в RAG-системах: как заметить деградацию retrieval без разметки, labels и явных ошибокВ RAG retrieval часто ломается тихо: модель та же, embedding model тот же, prompt тот же, latency в норме, а ответы стали хуже. Типичная ошибка - сразу крутить prompt или ругать LLM, хотя проблема ниже: изменился корпус.1. Мониторьте drift самого корпусаМы не измеряем качество напрямую, но смотрим, как изменилось пространство, в котором работает retriever:- распределение embedding-ов чанков;- средняя длина чанка, overlap, число чанков на документ;- доля новых, удалённых и изменённых чанков;- дубликаты и near-duplicates;- распределение доменов, типов документов, языков, дат;- плотность embedding-пространства: не стало ли много «слипшихся» чанков.Если корпус заметно сдвинулся, старые retrieval-пороги и ожидания по top-k могут стать мусором. Особенно если confidence logic завязана на score или gap между top-1 и top-2.2. Anchor queries вместо labelsВ production почти никогда нет labels вида «для этого query релевантны вот эти chunks». Но можно взять стабильный набор production-запросов: например, 500-5000 частых или бизнес-критичных query.Это не разметка. Мы не знаем правильный chunk. Но знаем, что retrieval-поведение не должно хаотично меняться после каждого обновления корпуса.Для каждого anchor query сохраняйте baseline:- top-k doc/chunk ids;- retrieval scores;- rank positions;- gap между top-1 и top-2;- diversity top-k;- source distribution.После обновления корпуса сравнивайте новый retrieval с baseline.Полезные proxy-метрики:- Jaccard@k между старым и новым top-k;- rank churn: сколько документов поменяло позиции;- score distribution shift;- падение top-1 score;- уменьшение score gap;- рост доли low-confidence retrieval;- изменение источников в top-k;- рост почти одинаковых чанков в top-k.Минимальный набор, который уже даёт сигнал:- mean_jaccard@10;- p95_top1_score_drop;- score_wasserstein между baseline и current scores.3. Как интерпретировать сигналы- mean_jaccard@10

⁣Замечен челлендж с реальными данными и большим призовым фондом. Ozon Tech запустил хакатон Робозон, который объединяет три инженерных трека на стыке CV и робототехники. Призовой фонд приятный —  15 млн руб. Финалистов компания обещает отвези на E-CODE.Задачи уже выложили, месяц на регистрацию. Участвовать можно хоть в одиночку. Или собрать команду до 7 человек. Глядя на эти три задачи, кто из вас прямо сейчас уверен, что вытащит такую сортировку в продакшен за два месяца?

Turbo ML Conf 2026: конференция в области машинного обучения и ИИ пройдет в Москве в третий раз На мероприятии, которое Т-Технологии проведут 18 июля в ДК “Серп и Молот”, соберутся ML-инженеры, исследователи, продакты и техлиды AI/ML-команд из крупнейших российских компаний. В этом году организаторы делают Turbo ML Conf 2026 более хардовым: меньше воды, больше практической информации и упор на практику в реальных кейсах. Одна из ключевых тем — разработка современных моделей, их архитектурные особенности и интеграция в конечные продукты. Программа разделена на три направления. Первое посвящено архитектуре современных моделей, их интерпретируемости, безопасному поведению, способности к рассуждению и самокоррекции. Второе — внедрению ML в продукты, интеграции классических и GenAI-моделей, влиянию на бизнес-метрики и пользовательский опыт. Третье — пайплайнам данных, методам дообучения, низкоуровневой оптимизации инференса и инфраструктуре. В программе — демозоны от ведущих компаний про продуктовые, платформенные решения с применением ML, а также выступления спикеров, которыми станут более 20 экспертов из Т-Банка, Яндекса, Авито, Сбера и Института AIRI. Участие бесплатное по предварительной регистрации. Количество мест ограничено.Data Science