Data Science | Machinelearning [ru]

Как находить вредные обучающие примеры перед 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-срезам: новые пользователи, редкие классы, проблемные регионы, свежий drift, сегменты с высокой бизнес-ценой или высоким SLA. 3. Data pruning перед fine-tune Рабочий пайплайн: 1. Зафиксировать production-like validation set без leakage. 2. Обучить baseline / fine-tune и сохранить несколько чекпоинтов. 3. Посчитать influence или TracIn для train→val. 4. Проверить top harmful samples: - label noise; - outdated distribution; - конфликтующие дубликаты; - corrupted inputs; - неправильная task/schema version. 5. Удалить, downweight или отправить на relabeling. 6. Повторить fine-tune и проверить не только общий metric, но и regression по сегментам. Production-пример: перед дообучением рекомендательной модели на свежих логах можно найти старые взаимодействия с изменившейся таксономией товаров, конфликтующие labels после миграции схемы или ботовый трафик, который ухудшает ranking loss на свежем holdout. 4. Предупреждение Не стоит слепо удалять все «вредные» примеры. Иногда они ухудшают текущий validation, но нужны для long-tail robustness, fairness или устойчивости к редким сценариям. Безопаснее начинать с top-K, делать human-in-the-loop аудит, сравнивать варианты remove / downweight / relabel и смотреть trade-off между quality, latency пересчета, стоимостью разметки, воспроизводимостью и надежностью мониторинга. Вывод: Influence Functions и TracIn полезны не как магическая чистка данных, а как инженерный способ сделать fine-tuning менее токсичным к шуму, устаревшим данным и конфликтующей разметке.

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_features
WHERE rn = 1;

Если нет available_at, вы часто не можете доказать, что leakage отсутствует. 2. Backfill’ы - скрытый источник утечки Backfill опасен тем, что создает иллюзию исторической полноты. Например, сегодня вы пересчитали фичу за прошлый год: - исправили старые события; - добавили данные из нового источника; - поменяли business logic; - подтянули late-arriving events; - использовали справочник, которого тогда еще не было. В результате train получает историю, которой на самом деле не существовало в момент прогноза. Корректный backfill должен отвечать на вопрос:

Какую фичу модель увидела бы тогда, если бы пайплайн работал с теми же задержками, источниками и правилами доступности?

Если ответ неизвестен, это не historical truth, а reconstructed truth. Для обучения моделей это разные вещи. 3. Проверка каузальности фичей Перед обучением каждую фичу стоит прогнать через causality review. Минимальный чеклист: 1. Фича доступна до prediction_time? Не событие произошло, а именно значение фичи было доступно. 2. Нет ли в фиче label proxy? Например, days_since_last_payment_failed для задачи дефолта может быть почти прямым следствием будущего таргета. 3. Окно агрегации строго в прошлом? last_7d должно означать [t-7d, t), а не календарную неделю, которая включает будущее относительно t. 4. Нет ли future-aware справочников? Сегменты, статусы, лимиты, antifraud-флаги и CRM-атрибуты часто обновляются задним числом. 5. Учитывается ли latency источника? Если данные приезжают через 6 часов, то для прогноза в 10:00 нельзя использовать событие в 09:55, даже если event_time подходит. Вывод: В production ML фича считается валидной не тогда, когда она исторически верна, а тогда, когда доказуемо доступна модели в момент принятия решения.

Конформные интервалы в 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 np

def 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.1

scores = 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 - tau
high = q_high_prod + tau

Так calibration distribution становится ближе к production distribution без грубого раздувания всех интервалов. Как не получить слишком широкие интервалы Один глобальный tau часто переоценивает неопределенность, если ошибка модели сильно зависит от x. Практически помогают: - CQR вместо point prediction: Conformalized Quantile Regression уже моделирует heteroscedastic uncertainty, поэтому conformal correction обычно меньше. - Нормализованный score: например s_i = |y_i - y_hat_i| / sigma_hat(x_i), а интервал строится как y_hat(x) +- tau * sigma_hat(x). - Локальная калибровка: отдельный tau по geo, device, channel, price bucket или risk bucket. Это близко к Mondrian conformal, но требует достаточного числа calibration examples в каждом сегменте. - Rolling calibration buffer: для рекомендаций, скоринга и forecasting старый calibration set быстро перестает описывать текущий traffic mix. Главный риск - плохие веса Density ratio model может быть шумной. Несколько объектов с огромными весами фактически “заменят” весь calibration set. Контролируйте: ESS = (sum w)^2 / sum(w^2) Если ESS низкий, weighted quantile нестабилен, а интервалы начинают прыгать от релиза к релизу. Практичные меры: - clip weights и мониторить долю clipped weights; - сглаживать density ratio; - объединять редкие сегменты; - не калибровать сегмент, где мало свежих labels; - запускать перекалибровку при падении ESS или drift по X. Production-чеклист - отдельный calibration set, не смешанный с training; - drift detection по feature distribution; - density ratio model между prod traffic и calibration traffic; - weighted conformal calibration; - мониторинг coverage, average width, coverage по slices, ESS и latency; - алерты на рост ширины интервалов без роста ошибки; - A/B validation, если интервалы влияют на routing, fallback или human review. Важно не путать marginal и conditional coverage. Conformal может держать 90% coverage на потоке в среднем, но проваливаться в отдельных микросегментах. В production это надо проверять явно. Вывод: При covariate shift цель не в том, чтобы слепо расширить интервалы, а в том, чтобы калибровать их под текущую смесь production-объектов и контролировать надежность этой калибровки.

Совет на ближайшие годы — изучайте ВАЙБ-КОДИНГ ИИ уже пишет код, чинит баги, генерирует тесты, документацию и помогает запускать продукты быстрее, чем это делали классические команды разработки. И это уже не "будущее когда-нибудь", а реальность, которая меняет рынок уже сегодня И те, кто научится вайбкодить сейчас, будут увереннее конкурировать на рынке и зарабатывать больше тех, кто по-прежнему делает всё вручную. Стартовать с нуля поможет канал Вайб-кодинг. Там ребята круглосуточно мониторят более 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 резко упал: retriever стал приносить другой контекст; - top-1 score системно падает: запросы хуже матчятся с корпусом; - score distribution сильно сдвинулась: старые thresholds и confidence logic могли сломаться. Практический совет: считайте эти метрики не только глобально, но и по сегментам - источникам, языкам, типам документов, продуктовым доменам. Глобальный average легко скрывает деградацию в критичном сегменте. 4. Retrieval confidence без ground truth Даже без разметки можно смотреть на «уверенность» ретривера: - высокий top-1 score; - большой gap между top-1 и top-2; - согласованность dense retrieval и BM25; - стабильность top-k при query rewriting; - низкая доля дубликатов в top-k; - покрытие нужных источников. Если dense и lexical retrieval внезапно начали расходиться, не стоит списывать это на шум. Часто это значит, что корпус или запросы изменились так, что одна из стратегий больше не работает как раньше. Production minimum для RAG: - хранить snapshot retrieval-результатов для anchor queries; - считать overlap, score drift и rank churn после каждого обновления корпуса; - отдельно мониторить дубликаты, новые чанки и распределения источников; - заводить alerts не на один query, а на агрегаты по сегментам. Corpus drift неприятен тем, что не выглядит как авария. Система отвечает, ошибок нет, latency нормальная. Просто контекст стал чуть менее релевантным. Потом ещё чуть менее. И качество RAG медленно проседает. Вывод: Без labels нельзя честно измерить relevance, но можно мониторить стабильность retrieval-поведения, уверенность ретривера и изменения корпуса, чтобы поймать деградацию раньше пользователей.

АЙТИШНИКИ БЕСПЛАТНОЕ ОБУЧЕНИЕ сборник курсов, инструментов и книг Проект «TERMINAL» стал крупнейшей библиотекой бесплатного образования. В одном канале собраны курсы, книги, полезные инструменты и практические тренажёры для всех разработчиков 🎓 Практические курсы и задания 🪽 Книги и статьи известных авторов 😮‍💨 Полезные инструменты и ресурсы 🌟 IT-новости и инсайды Обучение по всем направлениям: SQL, Python, Frontend, PHP, C++, Golang, GIT, Linux, QA, Java, Vibe-coding, Infosec и др. Ценишь знания, подпишись: Terminal_tg

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

Нейросети, IT и AI — в одной папке 💬 С коллегами собрали новые каналы про: 💠 промпты для нейросетей и готовые решения 💠 AI-фотосессии, генерация изображений и контента 💠 новости искусственного интеллекта без лишнего шума 💠 применение AI в работе, бизнесе и повседневной жизни 💠 Python, JavaScript, Data Science и системный анализ 💠 вакансии и возможности для специалистов в IT Посмотреть и подписаться тут 👉 https://t.me/addlist/c_rbhnzprbAwMmFi 💌 Добавить свой канал в папку

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

Хватит гадать — DeepSeek за тебя уже всё решил 🐳 * Сейчас все только про Claude, но я перешёл на DeepSeek и не жалею. Бесплатно, контекст 1 млн токенов — закинул целую книгу, помнит всё. Код пишет отлично, а рассуждения (Reasoning) выдают логику, как у архитектора. Решил протестировать агентский режим на задаче, которую вечно откладывал — собрать чистое инфополе с нуля. Чтобы не перебирать паблики вручную, зашёл через функцию похожих каналов в Telegram. Скормил DeepSeek ссылки на качественных авторов по IT и AI, которых читаю сам, и попросил проанализировать сотни рекомендаций. Агент изучил контент на каналах и оставил только тех, кто делится практическим опытом по: AI-воркфлоу, автоматизации, вайб-кодингу, промт-инжинирингу, RAG-syst. нейрогенерации и др. DeepSeek собрал полезную подборку экспертов в одну папку. Делюсь списком — внутри только полезный контент про IT & AI. 🔗Забирай в один клик: 👉 https://t.me/addlist/FYyQj91I8jJiMzg0

Когда ИИ-агент выходит за пределы экспериментов, одного «умного чата» становится мало. Чтобы агент был полезен в рабочей разработке, ему нужны правила, доступ к инструментам, понятный контекст, проверка действий и безопасная обвязка. Иначе вместо ускорения команда получает непредсказуемость, лишние риски и дорогой хаос в контекстном окне. На открытом уроке 15 июня в 20:00 разберём, как устроены современные ИИ-агенты и их обвязка: правила, модули навыков и MCP — протокол подключения модели к внешним инструментам. Поговорим, чем поведенческий слой агента отличается от слоя подключения, где искать готовые навыки, почему они стали популярны и как их устанавливать. Отдельно обсудим, как с помощью MCP дать агенту нужные инструменты, не перегружая контекст, а также как защищать агентов: схемы проверки, журналы аудита и типовые способы атак. Урок не для тех, кто хочет просто «подключить агента к проекту» без правил, контроля и понимания рисков. И не для тех, кто считает, что рабочая интеграция ИИ — это только написать хороший запрос. Регистрация: https://vk.cc/cYDpol Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

⁣Что такое calibration модели и зачем она нужна Многие смотрят на модель только через: 👉 accuracy 👉 F1 👉 ROC-AUC Но есть проблема.

Даже модель с хорошими метриками может очень плохо оценивать вероятности.

И иногда это критичнее самой классификации. Интуитивный пример Представь две модели. Обе предсказывают одинаково хорошо. Но первая говорит: 👉 «вероятность дефолта 95%» и оказывается права только в половине случаев. А вторая: 👉 «вероятность дефолта 95%» и реально попадает примерно в 95 случаях из 100.

Вторая модель calibrated. Первая — нет.

Что вообще означает calibration Calibration отвечает на простой вопрос:

«Можно ли доверять вероятностям модели?»

Если модель говорит: 👉 0.8 probability то примерно в 80% таких случаев событие действительно должно происходить. Почему это важно Особенно там, где решение зависит именно от вероятности. Например: 👉 кредитный скоринг 👉 медицина 👉 fraud detection 👉 ranking 👉 ad systems

Бизнес часто работает не с классом, а с risk score.

Какие модели calibrated хуже Некоторые модели по природе оценивают вероятности хуже других. Например: 👉 Logistic Regression обычно калибрована неплохо 👉 Gradient Boosting часто слишком overconfident 👉 deep learning любит завышенную уверенность Почему ROC-AUC тут не спасает Очень частая история: 👉 ROC-AUC отличный 👉 а вероятности мусорные Почему?

ROC-AUC оценивает ranking, а не качество probability estimates.

Модель может: 👉 идеально ранжировать объекты 👉 и ужасно оценивать сами вероятности одновременно. Как проверяют calibration Обычно используют: 👉 calibration curve 👉 reliability diagram 👉 Brier score Если calibration плохой, применяют: 👉 Platt Scaling 👉 Isotonic Regression 👉 temperature scaling для нейросетей Почему это недооценивают На Kaggle calibration почти никого не волнует.

Там главное — leaderboard.

Но в реальном проде вероятность: 👉 0.97 👉 0.12 👉 0.83 часто становится бизнес-решением. Например: 👉 выдать кредит 👉 заблокировать транзакцию 👉 отправить на ручную проверку Главная мысль

В какой-то момент оказывается, что качество вероятностей важнее красивого ROC-AUC.

Стажировки и вакансии для DevOps - Вакансии которых нет на джоб-агрегаторах - Только прямые контакты HR в Telegram 👉 @jobs_devops 🤖 ML & DS 👩‍💻 DevOps 👨‍✈️ ИБ & OSINT 👣 Go 👩‍💻 Mobile 👩‍💻 C# 👩‍💻 Node.js 👩‍💻 Python 🔎 QA 👩‍💻 Java 👩‍💻 UX/UI 👩‍💻 Frontend 🖼️ PHP 📋 Analyst 💼 1C 🖥 SQL 👩‍💻 IT HR Пока другие листают джоб-сайты — ты уже пишешь HR в Telegram.

⁣Почему многие DS не понимают бизнес-задачу Одна из самых частых проблем в Data Science вообще не связана с моделями. Многие DS отлично знают: 👉 метрики 👉 архитектуры 👉 feature engineering 👉 Python 👉 математику

Но при этом плохо понимают, зачем бизнесу нужна модель.

И это потом очень заметно в работе. Когда ML уходит в вакуум Например, человек может месяцами улучшать ROC-AUC: 👉 с 0.91 до 0.93

Хотя для бизнеса разницы почти нет.

Или строить сложную систему там, где хватило бы пары SQL-правил. И наоборот: 👉 модель с «неидеальными» метриками 👉 может приносить много денег потому что хорошо встроена в процесс. Откуда начинается проблема Большинство курсов учат: 👉 обучать модели 👉 подбирать гиперпараметры 👉 улучшать benchmark Но почти не учат задавать вопросы: 👉 что именно пытается оптимизировать бизнес? 👉 сколько стоит ошибка? 👉 как модель будут использовать? 👉 кто принимает решения на основе предсказаний?

Хотя это важнее половины ML-стека.

Метрика ≠ цель бизнеса Многие воспринимают задачу как:

«Получить максимальную метрику».

Хотя в реальности задача обычно звучит иначе: 👉 уменьшить churn 👉 снизить потери 👉 ускорить процесс 👉 сократить ручную работу

И иногда лучший ML-проект — это вообще не ML.

Прод быстро возвращает в реальность Бизнесу всё равно: 👉 какой у тебя encoder 👉 сколько слоёв 👉 какой learning rate Его интересует: 👉 работает ли система 👉 экономит ли деньги 👉 не ломается ли каждую неделю Частая ошибка Люди начинают: 👉 с модели 👉 обсуждают архитектуру 👉 спорят про CatBoost vs XGBoost

Ещё до того, как нормально поняли саму задачу.

Хотя хороший DS обычно сначала пытается понять: 👉 откуда берутся данные 👉 как принимаются решения 👉 где появляется ценность И только потом думает про модель. Главная мысль Сильные специалисты часто отличаются не тем, что знают больше алгоритмов.

А тем, что умеют связывать: 👉 данные 👉 продукт 👉 ограничения 👉 деньги 👉 реальный процесс

Без этого ML очень быстро превращается в дорогую игрушку.

⁣Reinforce.fi Challenge: Market-Action Arena Хакатон по reinforcement learning в трейдинге с призами до $2,500 от Reinforce.fi (ex-Overnight.fi) Задача: построить модель, которая на каждом шаге выбирает оптимальное действие (A1–A10) и максимизирует суммарный PnL. Что внутри: — анонимизированные market-like признаки — последовательности по 1000 шагов — частично наблюдаемая среда — скоринг = суммарный PnL Почему это интересно с engineering стороны: — задача на policy optimization, а не классический supervised ML — длинные эпизоды (1000 steps) — важно устойчивое поведение модели, а не single-step accuracy — приближено к реальному execution / trading loop Призы: 1 место — $2,500 2 место — $1,500 3 место — $1,000 Старт: конец июня Длительность: ~1.5–2 месяца Регистрация: https://forms.gle/UB71QuyUvp8mSBRo9 Чат хакатона: https://t.me/+R6lMJ10VXP5hOTI0

🤣 Не баг, а фича ✖️ xCode Journal

Как измерить рост производительности команды от внедрения ИИ. Бесплатный урок курса «Руководитель команд в ИТ» ИИ внедряют почти все, но далеко не все понимают, стал ли от этого процесс лучше. Команда может активнее пользоваться новыми инструментами, а расходы на лицензии могут расти, но главный вопрос остаётся открытым: действительно ли выросла производительность, сократилось ли время работы и появился ли экономический эффект. На открытом уроке 3 июня в 20:00 разберём, как руководителю команды подходить к внедрению ИИ не на уровне ощущений, а через измеримые показатели. Поговорим об условиях успешного внедрения, способах оценки производительности команды, поиске эффекта именно от ИИ, а не от случайных факторов, и расчёте экономической эффективности. Отдельно обсудим, какие требования стоит выполнить до внедрения, чтобы потом не гадать, помог ИИ или просто добавил ещё один слой инструментов. Урок не для тех, кто внедряет ИИ «потому что все так делают», не готов считать эффект и хочет заменить управленческие решения покупкой новых лицензий. 👉 Записаться: https://vk.cc/cYor0a Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, erid: 2VtzqvsDf7E

Российские ученые представили более быстрый и дешевый метод дообучения VLM Команда исследователей из Т-Банка проверила, можно ли прокачивать визуально-языковые модели не в настоящих интерфейсах и средах, а в синтетических симуляторах — и переносить эти навыки на реальные задачи. И оказалось, что да: ученые представили метод VL-DAC, который учит модели совершать последовательность действий

Почему существующих методов недостаточно? Современные VLM-модели неплохо понимают картинки, но начинают теряться, когда нужно действовать последовательно: открыть нужный раздел, выбрать объект, применить фильтр, построить маршрут или выполнить инструкцию шаг за шагом. И обучение таким сценариям в реальном мире дорогое и времязатратное. Можно тренировать модели в симуляторах, но существующие подходы требуют либо постоянного подбора коэффициентов вручную, либо большего количества памяти для хранения результатов о предыдущих шагах, либо смешивают обучение действию и оценке пользы выполненного действия. 🗒 Так был разработан метод VL-DAC. Модель обучалась сразу в нескольких средах для развития отдельных навыков: •MiniWorld — навигация и маршруты •Gym-Cards — выбор объекта по заданным условиям •ALFWorld — выполнение инструкций и взаимодействие с внешними объектами •WebShop — работа с веб-интерфейсами Что получилось на практике? После обучения модель Qwen2-VL-7B стала более чем на 50% лучше справляться с интерактивными задачами, улучшила пространственную ориентацию и веб-навигацию Самое интересное — модель учится не только совершать действия, но и понимать, были ли они полезны для достижения цели. Это делает перенос навыков из симуляции в реальные задачи намного стабильнее 😐

Такой подход может пригодиться везде, где ИИ должен не просто видеть, а действовать: от банковских интерфейсов и ритейла до робототехники и логистики. Data Science

Стажировки и вакансии для DevOps - Вакансии которых нет на джоб-агрегаторах - Только прямые контакты HR в Telegram 👉 @jobs_devops 🤖 ML & DS 👩‍💻 DevOps 👨‍✈️ ИБ & OSINT 👣 Go 👩‍💻 Mobile 👩‍💻 C# 👩‍💻 Node.js 👩‍💻 Python 🔎 QA 👩‍💻 Java 👩‍💻 UX/UI 👩‍💻 Frontend 🖼️ PHP 📋 Analyst 💼 1C 🖥 SQL 👩‍💻 IT HR Пока другие листают джоб-сайты — ты уже пишешь HR в Telegram.

⁣Почему нормализация данных иногда ухудшает модель Есть совет, который почти все слышат в начале изучения ML:

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

Проблема в том, что это не универсальное правило. Иногда после scaling модель становится не лучше, а хуже.

Особенно это удивляет людей после перехода с учебных задач на реальные данные.

Зачем вообще нужна нормализация Она приводит признаки к одному масштабу. Например: 👉 возраст: 18–60 👉 зарплата: 1000–300000 Для некоторых моделей это действительно критично. В первую очередь: 👉 Logistic Regression 👉 SVM 👉 KNN 👉 нейросети

Они чувствительны к масштабу признаков.

Без scaling: 👉 обучение может быть нестабильным 👉 градиенты становятся странными 👉 одна фича начинает доминировать над другими Но дальше начинается самое интересное Для деревьев scaling обычно почти бесполезен. 👉 Random Forest 👉 XGBoost 👉 LightGBM 👉 CatBoost работают через split’ы:

feature < threshold

Им не особо важно: 👉 0.5 это 👉 5000 👉 или 500000

Структура дерева от этого почти не меняется.

И поэтому люди иногда строят огромный preprocessing pipeline, который вообще ничего не улучшает. Иногда scaling реально портит модель Особенно если: 👉 много выбросов 👉 странные распределения 👉 heavy tails 👉 шумные данные

После StandardScaler часть фич может стать менее информативной.

Автоматический scaling — частая ловушка Многие делают scaling, даже не задавая вопрос:

«А моей модели это вообще нужно?»

Просто потому что: 👉 «так принято» Хотя на практике: 👉 CatBoost отлично работает на сырых данных 👉 табличные бустинги сами справляются с масштабами 👉 лишняя обработка только усложняет pipeline Отдельная классика — leakage через scaling Когда человек: 👉 нормализует весь датасет 👉 потом делает train/test split

И модель уже косвенно «видела» test.

Метрики после такого обычно очень красивые. До первого прода. Главная мысль Одна из главных проблем в ML — привычка применять техники автоматически.

Scaling — это не улучшение данных само по себе. Это инструмент под конкретный алгоритм.