Model card на собеседовании Data Scientist

Что такое model card

Model card («карточка модели») — это короткий документ, который сопровождает обученную ML-модель и описывает, что это за модель, для чего она, на каких данных обучена и как ведёт себя на разных группах пользователей. Аналогия — readme для датасета, только про саму модель: любой, кто берёт её в работу, должен из карточки понять, где модель применима, а где сломается.

Концепцию ввели в работе «Model Cards for Model Reporting» (Mitchell и др., 2019, Google). С тех пор она стала стандартом де-факто: карточки моделей — это те самые README с YAML-метаданными на Hugging Face Hub, отдельный Model Card Toolkit у Google, обязательная часть model governance в крупных командах. На собесе DS тему поднимают в блоке про ML в продакшене и responsible AI: интервьюер проверяет, думаете ли вы дальше метрики — про документацию, воспроизводимость и коммуникацию со стейкхолдерами.

Структура model card

Канонический набор разделов из статьи 2019 года выглядит так — это удобный шаблон, который стоит держать в голове:

# Model Card: model_name

## Model Details
- Архитектура, версия, авторы, дата, лицензия.

## Intended Use
- Основные сценарии применения.
- Сценарии, для которых модель НЕ предназначена (out-of-scope).

## Training Data
- Источник, размер, состав, известные перекосы выборки.

## Evaluation
- Метрики и бенчмарки.
- Разбивка качества по подгруппам (не только среднее).

## Ethical Considerations
- Возможные смещения (bias) и их источники.
- Риски и способы их снижения (mitigations).

## Caveats and Recommendations
- Ограничения модели.
- Рекомендации по использованию.

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

Intended use: где можно и где нельзя

Самый недооценённый раздел — назначение модели. Здесь важно явно зафиксировать не только то, для чего модель создана, но и то, для чего её использовать нельзя.

• Основной сценарий (primary use). Например: «классификатор спама для B2C-рассылок на русском языке». Конкретно: какой вход, какой выход, какой контекст.
• Вне области применения (out-of-scope). Например: «не использовать для юридической или медицинской классификации». Это защищает от переноса модели в задачу, для которой её никто не валидировал.

Такая явная граница экономит всем нервы: пользователь модели сразу понимает, подходит ли она под его кейс, и не тащит спам-классификатор в скоринг заявок. На собесе это хороший сигнал зрелости — вы думаете не только про качество, но и про риски неправильного применения.

Метрики по подгруппам

Ключевая идея карточки в части оценки — не ограничиваться средним качеством. Одна агрегированная цифра accuracy легко маскирует провал на конкретном сегменте. Поэтому метрики приводят с разбивкой (disaggregated):

• По языку или локали.
• По демографическим группам.
• По источнику данных или каналу.

| Группа       | Accuracy |
| Русскоязычные | 92%      |
| Остальные     | 87%      |

Разбивка вскрывает смещения и показывает, где модель нужно дорабатывать. Классический пример из статьи 2019 года — модель с высоким средним качеством, но заметно худшим результатом на одной из подгрупп; по среднему это незаметно, по разбивке — сразу видно. Именно поэтому интервьюер часто просит показать не «точность модели», а «точность по срезам».

Этические соображения

Раздел про этику — это не философия, а инженерный чек-лист рисков.

• Источники смещения (bias). Перекос в демографии обучающей выборки, систематические ошибки в разметке, исторические предубеждения в данных.
• Приватность. Есть ли в обучающих данных персональные данные (PII)? Может ли модель «протечь» ими в выводах (training data leakage)?
• Потенциал злоупотребления. Можно ли применить модель для дискриминации или манипуляции? Что мешает этому?
• Меры снижения рисков (mitigations). Что конкретно сделано: сбалансированная выборка, тестирование на bias, фильтры контента, ограничения по применению.

В регулируемых отраслях — финансы, медицина — документация модели давно перестала быть опцией и становится обязательным артефактом (тот же вектор задаёт и EU AI Act). Поэтому умение аккуратно описать риски модели — это уже часть работы DS, а не «бонус».

Как это спрашивают на собесе

Тему редко спрашивают в лоб «что такое model card» — чаще она всплывает в кейсах про production и ответственный ML.

«Модель готова к деплою. Что положишь в документацию?» Сильный ответ разворачивается в структуру карточки: назначение и out-of-scope, данные обучения, метрики с разбивкой по подгруппам, известные ограничения и риски.

«Accuracy 95%, но в проде жалобы. Как ловить такие вещи заранее?» Здесь ждут разбивку качества по сегментам: среднее скрывает провал на подгруппе, карточка требует показывать метрики по срезам именно ради этого.

«Чем model card отличается от datasheet for datasets?» Карточка описывает модель (назначение, качество, риски), datasheet — датасет (как собран, из чего состоит, какие ограничения). Это два разных документа под ответственный ML, часто идут в паре.

«Кому вообще нужна эта карточка?» Не только автору: тем, кто берёт модель в другой продукт, ревьюерам, комплаенсу в регулируемой отрасли. Карточка — способ коммуникации между командами, а не отчёт «для галочки».

Частые ошибки

• Считать карточку формальностью. Карточка нужна, чтобы другой человек безопасно применил модель. Формальный документ «для галочки» этой задачи не решает.
• Приводить только среднее качество. Одна цифра accuracy маскирует провалы на подгруппах. Без разбивки по срезам вы не увидите bias, пока он не выстрелит в проде.
• Пропускать out-of-scope. Если не написать, где модель применять нельзя, её обязательно применят не там — и виноватой окажется модель, а не тот, кто её не туда воткнул.
• Молчать про данные обучения. Без описания источника и состава выборки нельзя оценить, где модель будет ошибаться и насколько ей можно доверять на новом сегменте.
• Не обновлять карточку. Модель дообучили или сменили данные — а карточка описывает старую версию. Устаревшая документация хуже, чем её отсутствие, потому что ей доверяют.

Связанные темы

• Bias и fairness для DS
• MLflow и DVC для DS
• Hallucinations и LLM evals для DS
• SHAP и interpretability для DS
• Подготовка к собесу Data Scientist

FAQ

Зачем вообще нужна model card, если есть метрики в отчёте?

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

Что обязательно включать в model card?

Минимум — назначение и сценарии вне области применения (intended / out-of-scope use), описание обучающих данных, метрики с разбивкой по подгруппам, а также ограничения и этические риски модели. Остальное (архитектура, версия, лицензия) полезно, но именно эти четыре блока делают карточку рабочей.

Чем model card отличается от datasheet for datasets?

Model card описывает модель: для чего она, как измерялось качество, какие риски. Datasheet for datasets (Gebru и др.) описывает датасет: как он собран, из чего состоит, какие у него ограничения и допустимые применения. В зрелых командах их ведут вместе — карточку модели и карточку данных.

Почему в карточке требуют метрики по подгруппам?

Потому что агрегированная цифра легко скрывает смещение: модель может показывать высокое среднее качество и при этом заметно хуже работать на конкретном сегменте. Разбивка по срезам (язык, демография, источник данных) вскрывает такие провалы до того, как они проявятся в проде.

Это официальная информация?

Материал основан на работе Mitchell и др. «Model Cards for Model Reporting» (2019) и практике использования карточек моделей (Hugging Face Hub, Google Model Card Toolkit). Конкретный набор разделов и требований зависит от компании, домена и уровня регулирования.

Тренируйте Data Science — откройте тренажёр с 1500+ вопросами для собесов.