⁣Замечен челлендж с реальными данными и большим призовым фондом.

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

Глядя на эти три задачи, кто из вас прямо сейчас уверен, что вытащит такую сортировку в продакшен за два месяца?

⁣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-поведения, уверенность ретривера и изменения корпуса, чтобы поймать деградацию раньше пользователей.

Совет на ближайшие годы — изучайте ВАЙБ-КОДИНГ

ИИ уже пишет код, чинит баги, генерирует тесты, документацию и помогает запускать продукты быстрее, чем это делали классические команды разработки. И это уже не "будущее когда-нибудь", а реальность, которая меняет рынок уже сегодня

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

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

Подписывайтесь, нас уже 45 тысяч: @vibecoding_tg

Конформные интервалы в 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-объектов и контролировать надежность этой калибровки.

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 фича считается валидной не тогда, когда она исторически верна, а тогда, когда доказуемо доступна модели в момент принятия решения.