Ответы немного задержались в пробке, но доехали 💨
Если обобщить, то во всех кейсах проблема не только в модели, но и в данных, постановке задачи и в том, как именно мы оцениваем качество.
❤️ Кейс 1 (NLP, RAG)
Основная мысль: одного хорошего retrieval’а недостаточно.
Recall@10 говорит лишь о том, что нужный документ где-то попал в десятку - но это вовсе не значит, что:
• он оказался достаточно высоко в выдаче и не потерялся среди других кандидатов,
• в контексте не было лишнего шума, и LLM действительно опиралась именно на нужный фрагмент (может, ТОП-10 вообще слишком много),
• финальный ответ получился фактически корректным - ведь в условии есть только метрики retrieval, но ничего не сказано про качество генерации.
То есть оффлайн метрика поиска и качество ответа - это разные уровни пайплайна.
Как исправить: смотреть не только на retrieval, но и на качество финального ответа, уменьшать шум в контексте и проверять, насколько модель реально опирается на источники. В чувствительных задачах ещё помогают цитирование и факт-чекинг.
❤️ Кейс 2 (NLP, классификация)
Тут тоже проблема не в самом BERT, а в валидации - из-за этого метрики были слишком оптимистичными и не соответствовали реальности.
Если случайно делить форумные тексты на train/test, легко получить утечку по пользователям - их стилю, повторяющимся формулировкам, темам или даже похожим сообщениям. Тем более раз часть авторов очень активная.
В таком случае модель на оффлайне может запоминать не только задачу, но и особенности конкретных людей. А в проде она может столкнуться с более реалистичным распределением, и качество на новых пользователях просядет.
Как исправить: строить сплит так, как модель будет работать в реальности - например, делить по пользователям, тредам или времени. И проверять, нет ли скрытых утечек или пересечений между train и test.
❤️ Кейс 3 (CV, детекция)
Здесь правда могли сыграть роль данные и разметка + команда могла не заметить проблему из-за неподходящей метрики.
Высокий mAP не всегда означает, что модель хорошо решает бизнес-задачу:
• мелкие дефекты часто детектируются хуже и теряются в общей метрике + усреднённая оценка может скрывать провалы на отдельных типах дефектов
• не самая точная локализация всё ещё может считаться "достаточно хорошей" - особенно по mAP@0.5
И вообще в производстве пропуск дефекта часто гораздо критичнее лишнего срабатывания - поэтому пороги и IoU-метрики важно подобрать под бизнес-ограничения.
Как исправить: конечно, перепроверить датасет, отдельно смотреть качество на выборке с мелкими дефектами и проверять, соответствуют ли IoU и метрики реальной задаче. Если нужна более точная локализация, можно вообще попробовать решать как сегментацию.
❤️ Кейс 4 (CV, классификация)
А тут подвох действительно очень классический: если сначала сделать аугментации, а потом случайный split - то в итоге одна и та же исходная картинка (пусть даже в разных версиях) может оказаться и в train, и в test.
Это даёт очень красивые метрики в оффлайне, но по сути модель уже подглядела часть теста во время обучения.
Как исправить: важно сначала разделять данные на train/test, и только потом уже делать аугментации(!) И вообще полезно следить, чтобы разные версии одного и того же исходного изображения не попадали в обе выборки - в таких случаях можно группировать данные по объекту/сцене/источнику.
Легкой рабочей недели! 🌱
#dl@data_easy
#nlp@data_easy
#cv@data_easy
#карьера@data_easy