Вопросы на собеседовании: Инженер по безопасности ИИ

Я бы стратифицировал пары предпочтений по harm-классу, неоднозначности и легитимному применению, а не отбирал только очевидные нарушения.

• Для каждого вредоносного запроса я бы добавил близкие benign-, transformative- и boundary-кейсы, чтобы предпочтительный ответ различал отказ и безопасную помощь.
• Редкие тяжёлые классы я бы пересэмплировал, а затем применил importance weights, чтобы training-распределение не выдавало их за основную долю реального трафика.
• До добавления данных в обучение held-out срез по источнику и аннотатору измерял бы safe-completion rate, refusal recall и benign false-positive rate.
• Я бы ограничил повторяющиеся шаблоны и кластеризовал семантические дубликаты, чтобы одно семейство jailbreak не доминировало в градиенте.

Я бы сделал политику ориентированной на решения, с размеченными примерами, правилами эскалации и явным способом фиксировать неоднозначность.

• Для каждого harm-класса нужны примеры включения, исключения и пограничных случаев, а также ожидаемый режим ответа: выполнить, безопасно помочь, отказать или эскалировать.
• Аннотаторы отдельно размечают policy outcome и уверенность, чтобы большинство с низкой уверенностью не принималось за однозначный gold label.
• Я бы делал двойную разметку калибровочной выборки, считал Krippendorff's alpha по классам и отправлял разногласия на adjudication, а не принуждал к консенсусу в чате.
• Решения adjudication становятся версионированными примерами следующего релиза политики, а исходные labels сохраняются для аудита и повторного анализа.

Я бы оценивал reward model как safety-классификатор и ранжировщик на held-out, adversarial и distribution-shifted парах предпочтений.

• Pairwise accuracy разбивается по harm-классу, severity, языку и границе между выполнением и отказом, а не сводится к одному агрегату.
• Я бы проверил перестановку ответов, парафразы, контроль длины и поверхностные изменения стиля, чтобы найти shortcuts по позиции, многословию и формулировкам отказа.
• Calibration curves сопоставляют reward margins с согласием людей, потому что большой разрыв score должен соответствовать действительно однозначному предпочтению.
• Release-проверка также измеряет downstream policy behavior, поскольку небольшой ranking bias может усилиться при оптимизации.

Я бы рассматривал KL-контроль как safety-ограничение на отклонение от известной политики, а не как константу только для настройки reward.

• Слишком слабое KL-давление позволяет policy эксплуатировать пробелы reward model и терять исходные сигналы неопределённости; слишком сильное сохраняет небезопасное или бесполезное поведение reference model.
• Я бы использовал замороженную версионированную reference model, близкую к стартовой policy, и строил графики safety-метрик относительно reward и измеренного KL по checkpoints.
• Per-class eval должны включать over-refusal и dangerous compliance, потому что одинаковый средний KL может скрывать концентрированное изменение одного harm-класса.
• Я бы выбрал checkpoint на границе Парето и отклонил любую точку, пересекающую жёсткий severe-harm gate, даже если preference reward вырос.

Я бы искал поведение, которое повышает оптимизируемый reward, не выполняя исходную safety-рубрику.

• Нужно сравнивать scores reward model со слепой человеческой разметкой на high-reward примерах, особенно на повторяющихся отказах, дисклеймерах, многословии и имитации policy-терминов.
• Я бы обучал пробные policies против замороженных reward snapshots и разбирал случаи с максимальным расхождением reward, а не случайные ответы.
• Где возможно, я бы использовал независимые process checks, rule-based факты и второго judge, чтобы detector не разделял тот же shortcut с reward model.
• Reward, severe-harm rate, safe-completion rate и разнообразие ответов нужно отслеживать вместе; рост reward при плоских внешних safety-метриках является stop-сигналом.

Нестабильность PPO может резко сдвинуть ранее безопасную policy к reward exploits или широким отказам, даже когда средний reward выглядит нормально.

• Я бы отслеживал policy KL, clip fraction, entropy, value loss и safety-метрики по классам на каждом checkpoint, а не только в конце epoch.
• Консервативный learning rate, меньшая update strength, reward normalization, gradient clipping и adaptive KL target снижают риск разрушительных скачков policy.
• Фиксированные canary prompts для severe harm и benign dual-use запросов запускаются во время обучения и останавливают job при регрессии жёсткой границы.
• После rollback весов к безопасному checkpoint я бы сбросил или осознанно скорректировал optimizer moments и снизил learning rate или update strength; восстановление momentum, вызвавшего нестабильный шаг, может повторить его.

DPO упрощает оптимизацию, но его safety-качество всё равно ограничено покрытием preference pairs и выбранной reference policy.

• DPO исключает отдельно эксплуатируемую reward model и нестабильный online PPO loop, что уменьшает один класс reward hacking.
• Label noise и односторонние пары с отказами могут напрямую научить blanket refusal, потому что в DPO нет независимой reward model для проверки.
• Параметр beta управляет отклонением от reference, поэтому я бы перебрал его относительно severe-harm recall, safe-completion rate и стилевых артефактов.
• Я бы сравнил DPO и RLHF на одном held-out adversarial set и выбирал по safety-границе Парето, а не только по простоте обучения.

Я бы отдельно проверял конституцию, judge и обученную policy, поскольку ошибка любого из них может стать целью alignment.

• Для пунктов конституции нужны конкретные правила разрешения конфликтов и примеры, иначе два разумных принципа могут по-разному ранжировать один ответ.
• AI judge калибруется относительно слепого human adjudication по harm-классам, языкам и неоднозначности, с тестами на position bias и self-preference.
• На части выборки я бы менял judge model и формулировку конституции, чтобы измерить зависимость labels от одной evaluator-конфигурации.
• Финальные policy eval используют независимых judges и людей, потому что оценка результата тем же judge, который создал preferences, даёт циклическое доказательство.

Я бы сохранял исходный ответ, выбранный принцип, структурированную критику, исправление и provenance как отдельные артефакты.

• Сначала principle selector выбирает применимые пункты и фиксирует конфликты, вместо передачи всей конституции в каждый пример.
• Critic должен указать нарушенный фрагмент и principle ID, а reviser получает только критику, исходный ответ и разрешённые принципы.
• Validators проверяют, что исправление устраняет нарушение, не выдумывает факты, не теряет полезное содержание и не превращает каждый boundary case в отказ.
• Human review фокусируется на high-severity, low-confidence и critic-reviser disagreement случаях, что даёт лучшее покрытие, чем равномерное ревью.

Я бы использовал process supervision, когда небезопасны промежуточные действия, даже если финальный ответ выглядит безвредно.

• Tool-use planning, биопротоколы и cyber workflows требуют step labels, потому что агент может совершить необратимое опасное действие до проверки финального ответа.
• Outcome supervision дешевле и подходит, когда успех и harm надёжно наблюдаются в конце, например для ограниченного classifier-решения.
• Process labels дороже и могут навязывать предпочтительный стиль рассуждения, поэтому я бы размечал проверяемые действия и переходы состояния, а не приватную reasoning-прозу.
• Eval сравнивает финальный harm и промежуточные policy violations, чтобы подтвердить, что process supervision добавляет сигнал, а не просто меняет подачу.

Я бы разложил задачу на проверяемые утверждения и действия, а затем совместил специализированные инструменты, помощь моделей и выборочный экспертный review.

• Evidence retrieval, executable tests и provenance checks обрабатывают проверяемые подзадачи до того, как model judge оценивает оставшиеся спорные решения.
• Несколько независимых critics проверяют разные failure modes, например factuality, policy compliance и tool authorization, вместо обсуждения одного расплывчатого score.
• Эксперты adjudicate high-impact разногласия и случайную low-risk выборку, чтобы оценить ошибки, пропущенные confidence routing.
• Я бы сначала проверил метод oversight на задачах с известными ответами и только потом доверял ему задачи вне прямых человеческих возможностей.

Weak supervision расширяет покрытие, но коррелированные ошибки разметки могут превратиться в уверенный ложный консенсус.

• Heuristics, policy keywords, model judges и source metadata нужно моделировать как отдельные шумные labeling functions с измеренным пересечением и конфликтами.
• Небольшой экспертно размеченный gold set оценивает class-specific accuracy каждого источника вместо равного голосования.
• Общее происхождение моделей и скопированные правила создают коррелированные ошибки, поэтому три похожих judge не дают три независимых сигнала.
• Severe и novel harm случаи я бы оставил для expert review и явно показывал abstention weak labels, а не принудительно добивался полного покрытия.

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

• Нужны вопросы с ложной предпосылкой, политические и личные мнения, а также случаи, где пользователь давит на модель после верного ответа.
• Оценка измеряет factual consistency, уместную неопределённость, уважительное несогласие и изменение уверенности без новых доказательств.
• Порядок ответов и identity cues пользователя нужно контрбалансировать, чтобы eval не путал вежливость или демографический стиль с sycophancy.
• Multi-turn варианты проверяют, приводит ли повторное давление к постепенной уступке, которую не заметит one-turn benchmark.

Я бы обучал на семействах атак и поведенческих инвариантах, а не на списке запомненных suffix.

• Смесь включает human red-team cases, PAIR-style семантические атаки, преобразования кодировок, role-play, мультиязычные варианты и benign near-neighbors.
• Разделение идёт по attack generator, template cluster и времени, чтобы holdout содержал неизвестные стратегии, а не парафразы training examples.
• Hard examples нужно обновлять против текущих checkpoints, потому что успешные атаки устаревают вместе с изменением модели.
• Unseen-family ASR и benign safe-completion rate измеряются вместе, чтобы обнаружить и хрупкую защиту, и широкие отказы.

Я бы смешал целевые safety-примеры с репрезентативными capability и benign dual-use данными и проверял каждый checkpoint по safety и utility.

• Safety data покрывают severe harms и boundary cases, а replay data сохраняют instruction following, предметные способности и безопасную помощь.
• Низкий learning rate, ограниченное число epochs и PEFT вроде LoRA могут сдержать parameter drift, но не заменяют capability evaluation.
• После каждого epoch я бы сравнивал class-level ASR, over-refusal, основные task scores и calibration со стартовой моделью.
• При регрессии одной способности я бы изменил смесь или остановился на более раннем checkpoint, а не латал loss дублированными примерами.

Я бы находил benign-запросы, достаточно похожие на harmful-контент, чтобы срабатывать у текущего classifier, а перед переобучением проверял их вручную.

• Источниками кандидатов служат цитируемый анализ, профилактика, художественные тексты, medical triage, обсуждение policy и преобразованный контент из live false positives.
• Кандидаты ранжируются по близости к decision boundary или disagreement ансамбля, затем дедуплицируются по семантическим кластерам до разметки.
• Аннотаторы размечают harm class и allowed intent, чтобы модель учила различие, а не просто снижала вес keywords.
• Замороженный hard-negative holdout сохраняется, а severe-harm recall отслеживается, поскольку агрессивное снижение false positives может открыть реальные обходы.

Я бы явно сопоставил продуктовую policy с labels Llama Guard 2, добавил пограничные кейсы продукта и после fine-tuning оценил стандартное дискретное decision rule.

• Training examples балансируют violating, allowed и ambiguous диалоги для сообщений пользователя и ассистента, сохраняя provenance и policy-version fields.
• Multi-turn и multilingual примеры отражают deployed surface, а near-duplicate templates остаются только в одном data split.
• Evaluation сравнивает выданные решения safe или unsafe и category labels с исходной моделью, показывая confusion по категориям на benign dual-use и редких severe harms.
• Стандартный контракт не предоставляет калиброванный continuous score. Только если интеграция намеренно открывает token logits и явно определяет continuous score, я применю temperature scaling или class thresholds на held-out calibration set, затем зафиксирую и провалидирую этот wrapper.

Я бы отделил широкие семейства harm от прикладных leaf labels и разрешил одному примеру иметь несколько labels.

• Parent nodes вроде violence или cyber поддерживают стабильную отчётность, а leaves вроде credential theft или malware deployment запускают разные controls.
• Labels кодируют content, intent и target только там, где каждое измерение меняет enforcement; смешивание всех трёх в одном flat label создаёт разреженные комбинации.
• Правила разметки описывают co-occurrence, primary и secondary harm, а также случай, когда допустим только parent label из-за недостатка данных для leaf.
• Evaluation включает hierarchical precision-recall, чтобы верный parent при неверном leaf не считался полностью посторонним классом.

Я бы относился к изменениям таксономии как к schema migrations со стабильными идентификаторами, mappings и явным окном совместимости.

• При переименовании сохраняется immutable ID, а splits и merges публикуют many-to-many mappings и примеры новой границы.
• Classifiers вместе выводят версии taxonomy и model, а dashboards переводят старые labels только там, где mapping семантически корректен.
• Во время dual-run старая и новая таксономии оценивают один трафик, чтобы владельцы gates измерили разрыв метрик.
• Исторические данные остаются под исходными labels; backfill создаёт новый derived dataset, а не переписывает audit evidence.

Я бы сначала показывал rates по классам, а severity weighting использовал только как прозрачную вторичную метрику решения.

• Каждый harm class получает документированные impact и exposure weights с диапазонами или sensitivity analysis там, где значения неопределённы.
• Expected risk может объединять вероятность нарушения, severity и deployment exposure, но для catastrophic classes всё равно сохраняются жёсткие максимальные пороги.
• Weighted average не должен позволять множеству low-severity улучшений отменить одну severe-регрессию, поэтому scorecard показывает компоненты и худшие результаты по классам.
• Веса версионируются и утверждаются с policy owners, потому что их изменение может поменять release-решение без изменения модели.