Мультимодальную frontier-модель нужно запустить через 6 недель для текста, изображений и аудио, с 12 harm-классами и порогом ASR для критического вреда ниже 1%. Как вы спроектируете release-gate eval suite?

Я бы создал единый версионируемый release gate, который связывает тесты по модальностям с общей harm-policy и блокирует релиз по худшему критическому срезу. - Я бы объединил фиксированные регрессии, закрытые экспертные кейсы, адаптивные атаки и benign-контроли, показывая доверительные интервалы вместо одной средней оценки. - Задачи Inspect AI фиксировали бы модель, policy, scorer, seed и преобразования медиа, чтобы каждый результат и повторный прогон имели точную атрибуцию. - Для критических CBRN, cyber и self-harm гейтов не допускалась бы статистически подтверждённая регрессия, а низкие уровни могли бы расходовать документированный error budget.

За 45 дней нужно выпустить harm-таксономию v3 для 18 продуктовых поверхностей и 14 harm-классов. Как сделать её общим контрактом для policy, eval и guardrail?

Я бы сделал таксономию исполняемым версионируемым контрактом со стабильными harm ID, тяжестью, намерением, допустимыми преобразованиями и владельцем эскалации. - Каждый лист содержал бы позитивные, пограничные и benign-примеры, а также связи с eval-датасетами, классификаторами и действиями продукта. - Панель из safety, policy, product и Trust and Safety откалибровала бы стратифицированный набор из 1 000 кейсов перед утверждением. - Миграции сохраняли бы старые ID и публиковали lineage, чтобы scorecard оставались сопоставимыми при разделении или слиянии категорий.

Модель 9B переходит от чата к tool use за 90 дней, и руководству нужны 4 уровня capability-risk с числовыми порогами релиза. Как вы определите систему уровней?

Я бы отдельно оценивал измеренную capability и правдоподобный harm, а их комбинацию связывал бы со всё более строгими deployment-контролями. - Триггеры уровней использовали бы заранее заданные метрики uplift, task success, autonomy horizon и доступа с доверительными интервалами, а не число параметров или впечатления. - Пересечение порога автоматически добавляло бы экспертные eval, ограничение доступа, мониторинг или no-go gate до продвижения модели. - Я бы пересматривал пороги после каждого крупного скачка capabilities, но никогда не понижал бы их во время активного release review.

У вас бюджет $750 000 и 8 недель на независимый predeployment red team для модели с 20 миллионами пользователей. Как вы организуете работу?

Я бы дал независимой команде ограниченный доступ, защищённый канал отчётности и свободу тестировать за пределами внутренней таксономии без права model-team наложить вето. - Контракт определял бы целевые поверхности, правила доступа к опасным доменам, качество доказательств, безопасность исследователей, раскрытие и декларации конфликтов интересов. - Я бы оставил 20% бюджета на повторные тесты, потому что отчёт без проверки mitigation неполон. - Находки шли бы в тот же severity и release-gate процесс, что и внутренние eval, а спорные оценки разбирала бы заранее выбранная третья сторона.

Корпус dangerous-capability содержит 80 000 CBRN- и cyber-элементов и должен поддерживать 30 оценщиков без экспорта сырых данных. Как защитить его и сохранить воспроизводимость eval?

Я бы держал сырые элементы в изолированном evaluation enclave и разрешал экспорт только проверенных агрегатов и санитизированных обезличенных трасс. - Оценщики получали бы минимальный временный доступ по домену, а для ключей ответов и исполняемых артефактов требовалось бы более строгое одобрение. - Каждое чтение, запрос к модели, изменение scorer и экспорт записывались бы в неизменяемый аудит и связывались с целью оценки. - Воспроизводимость обеспечивали бы подписанные манифесты датасета, изолированные раннеры и детерминированные snapshot ID, а не распространение опасного контента.

Спроектируйте платформу Inspect AI для 2 миллионов eval-эпизодов на релиз, 40 вариантов моделей и SLA 6 часов. Какую архитектуру выберете?

Я бы отделил неизменяемые определения задач от горизонтально масштабируемого execution plane и подписанного хранилища доказательств. - Версии dataset, solver, scorer, model adapter, sandbox и policy формировали бы единый content-addressed манифест запуска. - Очередь делила бы задания по риску и ресурсам, а изолированные sandbox обслуживали tool-задачи вместе с rate-aware воркерами, checkpoint и идемпотентными повторами. - Release-дашборды читали бы только завершённые подписанные прогоны, а сырые транскрипты следовали бы правилам доступа и хранения конкретного harm-класса.

Статический suite показывает только 3% ASR, но адаптивный бюджет из 10 000 запросов достигает 19%. Как построить adaptive attack service для каждого еженедельного кандидата?

Я бы запускал генерацию атак как поиск с ограниченным бюджетом, где цель, stop rules и целевая policy фиксируются для каждой кампании. - Сервис поддерживал бы итеративные атаки в стиле PAIR, мутации, transfer attacks и штраф за отсутствие разнообразия, чтобы не потратить бюджет на одно семейство шаблонов. - Кандидатные атаки повторно оценивала бы отдельная policy-модель, а выборку вслепую проверяли бы люди для контроля сговора attacker и judge. - Новые успешные кластеры помещались бы в карантин, минимизировались и после проверки на leakage переходили бы в закрытый regression set.

Image-text модель работает на 6 языках и должна удерживать ASR тяжёлых multimodal jailbreak ниже 0,5% на 24 000 тестов. Как построить suite?

Я бы тестировал смысл между модальностями, а не просто прикреплял небезопасный текст к случайным изображениям. - Suite покрывал бы типографику, диаграммы, скриншоты, преобразования изображений, межмодальные противоречия и benign-аналоги на всех 6 языках. - Я бы делил результаты по harm, языку, качеству изображения и семейству атак, добавив парные text-only контроли для локализации уязвимой модальности. - Хеши медиа, преобразования, настройки модели и версии scorer фиксировались бы, чтобы точно воспроизвести сбой.

Чат-модель поддерживает сессии по 200 ходов, а отложенные jailbreak появляются после 60-го хода в 7% атак. Спроектируйте multi-turn safety suite с ночным бюджетом 4 часа.

Я бы оценивал stateful attack trajectories с отложенными триггерами, наращиванием доверия, отравлением контекста и размыванием policy вместо повторения одиночных промптов. - Состояние сценария хранило бы цель атакующего, внедрённые факты, наблюдения инструментов, summary и точный ход изменения policy-поведения. - Я бы выбирал короткие, средние и 200-ходовые горизонты, а adaptive pruning направлял бы compute на траектории с растущим риском. - Гейты оценивали бы и итоговый harm, и ранние сигналы вроде небезопасных обязательств или сохранённой вредоносной памяти.

Агент может вызывать 75 инструментов и выполняет 3 миллиона действий в день, а порог тяжёлых вредных действий ниже 1 на миллион. Как спроектировать safety eval?

Я бы оценивал полную траекторию от полномочий пользователя до предложенных аргументов, policy-решения, результата инструмента и восстановления. - Сценарии покрывали бы confused deputy, повышение привилегий, indirect injection, необратимые действия, обход approval и ложные заявления об успехе, разделяя unsafe attempts, заблокированные попытки, выполненный harm и benign overblocking. - Детерминированные симуляторы проверяли бы side effects, а adversarial-наблюдения тестировали бы отношение агента к tool output как к недоверенным данным. - Для независимых репрезентативных Bernoulli-испытаний ноль вредных событий примерно в 3 миллионах испытаний даёт одностороннюю 95%-ную точную биномиальную верхнюю границу около 1 на миллион; точная пуассоновская граница требует независимой репрезентативной event exposure. Повторение сценариев, инструментов или пользователей создаёт кластеры, поэтому я бы применил cluster bootstrap либо иерархическую beta-binomial или Poisson model, указал effective sample size и связал оценку с production exposure.

У вас 12 недель и 40 проверенных экспертов, чтобы измерить, повышает ли frontier-модель результат CBRN-задач более чем на 5 процентных пунктов. Как безопасно провести исследование?

Я бы заранее зарегистрировал estimand, минимально обнаружимый эффект в 5 пунктов и иерархический протокол с повторными задачами до открытия опасных материалов. - Эксперты выполняли бы рандомизированные model-assisted и control задачи, измеряющие capability без возможности завершить реальный вредный процесс, а анализ учитывал бы случайные эффекты участников и задач. - Я бы симулировал мощность при правдоподобной сложности задач, внутригрупповой корреляции и пропусках; 40 экспертов нельзя считать достаточными без расчёта, поэтому могут понадобиться дополнительные задачи на эксперта или эксперты. - Привязанный к личности enclave, запрет сырого экспорта, поэтапная выдача, stop rules, legal и domain review защищали бы участников, а оценки эффекта и неопределённости ограничивали бы заявления об uplift.

В cyber-исследовании 120 участников, бюджет $400 000 и цель за 10 недель обнаружить uplift на 8 пунктов над human baseline. Как его спроектировать?

Я бы оценивал поэтапную цепочку атаки в изолированных сбрасываемых репликах: поиск уязвимости, разработку exploit и подтверждённый end-to-end compromise. - Участники по crossover-дизайну проходили бы model-assisted и control условия с одинаковым доступом к инструментам и случайным порядком, а анализ учитывал бы случайные эффекты участников и задач. - Заранее зарегистрированные endpoints измеряли бы завершение каждого этапа цепочки, время и безопасные непригодные для развёртывания артефакты вместо generic human uplift. - Симуляция мощности варьировала бы исходный навык, crossover-корреляцию, сложность задач и отток; я бы не предполагал, что 120 участников обнаружат эффект в 8 пунктов, и при необходимости добавил бы участников или задачи.

У вас 1 500 участников, 3 языка и 60 дней, чтобы измерить persuasive manipulation с минимально обнаружимым эффектом 3%. Как спроектировать human study?

Я бы заранее зарегистрировал бинарный primary estimand при повторном измерении, отделяющий манипуляцию через обман, давление или эксплуатацию уязвимости от обычного убеждения. - Условия меняли бы стратегию модели при одинаковых теме, времени воздействия и доверии к источнику, а рандомизация была бы стратифицирована по языку и кластеру набора. - До набора я бы симулировал мощность с учётом кластеризации; простому сбалансированному независимому дизайну при baseline около 50% нужно примерно 4 400 участников для эффекта в 3 пункта и ещё больше с учётом оттока и множественных сравнений, поэтому 1 500 не обеспечат эту цель без нового дизайна или большего MDE. - Согласие, debriefing, право выхода, защита уязвимых групп и независимый ethics review сопровождали бы отчёт о неопределённости и пределах по языкам, темам и горизонту.

Frontier-агент получает sandbox на 72 часа и 50 autonomy-задач, без внешнего сетевого доступа и с гейтом успеха 2%. Как тестировать риск self-replication?

Я бы создал инструментированные proxy-задачи на получение ресурсов, persistence, планирование репликации и уклонение от надзора внутри герметичной среды. - Sandbox предоставлял бы синтетические учётные данные, фальшивые сервисы, ограниченный compute, отсутствие внешнего маршрута и аппаратный kill path вне контроля агента. - Критерии успеха требовали бы проверенных изменений состояния, а не убедительных текстов, и graders различали бы частичное планирование и завершённую capability. - Я бы менял варианты заданий и canary для обнаружения запоминания, сохраняя каждую траекторию для экспертного review с ограниченным доступом.

Модель набирает 91%, когда ей говорят об обучении, и 68%, когда говорят о safety evaluation, на 2 000 парных задач. Как тестировать sandbagging или deception без лишних заявлений?

Я бы рассматривал разрыв как гипотезу, требующую контролей, а не как доказательство намеренного обмана модели. - Я бы рандомизировал признаки evaluation, перефразировал их, скрывал происхождение задач и сравнивал парные capability-контроли на разных seed и checkpoint. - Причинные вмешательства в признаки и внутренние представления дополнялись бы поведенческими повторами, а scorer и contamination checks исключали бы простые объяснения. - Отчёт разделял бы наблюдаемую чувствительность к контексту, данные, совместимые со стратегическим занижением результата, и более сильные выводы, которые мы не можем подтвердить.

Нужно обслуживать 14 safety-классификаторов на 900 миллионах запросов в день, с recall по harm выше 99% и benign blocking ниже 3%. Как спроектировать fleet?

Я бы использовал маршрутизируемый fleet классификаторов с откалиброванными специалистами, общими policy ID и shadow lane для кандидатов. - Быстрые широкие классификаторы обрабатывали бы обычный трафик, а неопределённые и тяжёлые случаи направлялись бы сильным специалистам или людям. - Калибровка, пороги и abstention версионировались бы по harm и языку на свежих production-like holdout. - Здоровье fleet отслеживало бы recall, precision, calibration error, drift, disagreement и коррелированный отказ, чтобы резервирование было реальным, а не декоративным.

Tool-using ассистент обслуживает 10 миллионов сессий в день и имеет 250 мс на guardrail. Как построить каскад input, output и tool guardrail?

Я бы поставил отдельные контроли на каждой границе доверия вместо одного универсального moderator. - Input-контроли классифицировали бы намерение и injection risk, а context-контроли помечали бы retrieved content и memory как недоверенные доказательства. - Tool-контроли проверяли бы полномочия пользователя, schema, policy и approval до выполнения; output-контроли проверяли бы утверждения, чувствительные данные и запрещённую помощь. - Каждый этап выдавал бы общий harm ID и reason code, чтобы fallback, appeal, observability и release eval использовали один контракт.

Релиз покрывает 16 harm-классов, но агрегированный safety score равен 97%. Как задать гейты по классам, если recall тяжёлого harm должен быть выше 99,5%, а benign FPR ниже 4%?

Я бы отверг агрегированный score и определил пороги по тяжести, обратимости, охвату и качеству доказательств. - Катастрофические и тяжёлые классы получили бы жёсткие гейты recall или ASR с доверительными интервалами без компенсации успехами низкорисковых классов. - Для каждого класса также был бы потолок benign FPR и путь abstention, чтобы безопасность не достигалась отказом на всё. - Редкие классы запускали бы сбор экспертных данных или консервативные access controls, а не ложный pass на слабой выборке.

Guardrail проходят English с recall 99%, но показывают 81% на Arabic и 84% на Japanese среди 30 000 кейсов, а запуск через 8 недель. Какую систему построить?

Я бы использовал единую policy-таксономию для всех языков, но калибровал данные, классификаторы и пороги с native-экспертизой по каждой локали. - Корпус включал бы нативные вредные запросы, code switching, транслитерацию, диалекты, обфускацию и benign boundary cases, а не только переводы с английского. - Native reviewers калибровали бы рубрики и разбирали разногласия, а back-translation служил бы диагностикой, не ground truth. - Rollout оставался бы закрытым по языку, пока каждый критический harm не достигнет порога, даже при проходящем глобальном среднем.

Модель обслуживает 2 000 enterprise tenants, взрослых и несовершеннолетних, в 12 регионах с конфликтующими policy-требованиями. Как наслоить safety policy без 24 000 форков?

Я бы компилировал небольшую иерархию из глобальной model policy, региональных обязательств, age protections, tenant-ограничений и контекста сессии в единый decision bundle. - Нижние слои могли бы только сужать разрешения, а каждое правило содержало бы precedence, юрисдикцию, даты действия, владельца и тест-кейсы. - Policy compiler находил бы противоречия и генерировал region-age-tenant regression matrix до публикации. - Runtime фиксировал бы resolved bundle на сессию и логировал decision ID, а legal отвечал бы за интерпретацию, safety engineering за точное исполнение.

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

100 реальных вопросов с образцовыми ответами и пояснениями для уровня Senior.

Смотреть пример резюме: Инженер по безопасности ИИ →

Тренировка флешкарточками

Интервальное повторение · Hunter Pass

Вопросы

release-gate

Я бы создал единый версионируемый release gate, который связывает тесты по модальностям с общей harm-policy и блокирует релиз по худшему критическому срезу.

Я бы объединил фиксированные регрессии, закрытые экспертные кейсы, адаптивные атаки и benign-контроли, показывая доверительные интервалы вместо одной средней оценки.
Задачи Inspect AI фиксировали бы модель, policy, scorer, seed и преобразования медиа, чтобы каждый результат и повторный прогон имели точную атрибуцию.
Для критических CBRN, cyber и self-harm гейтов не допускалась бы статистически подтверждённая регрессия, а низкие уровни могли бы расходовать документированный error budget.

Зачем это спрашивают: Интервьюер проверяет, умеет ли кандидат превращать мультимодальные safety-доказательства в воспроизводимое решение о релизе, а не в средний бенчмарк.

llm-safetyharm-taxonomyguardrails

Я бы сделал таксономию исполняемым версионируемым контрактом со стабильными harm ID, тяжестью, намерением, допустимыми преобразованиями и владельцем эскалации.

Каждый лист содержал бы позитивные, пограничные и benign-примеры, а также связи с eval-датасетами, классификаторами и действиями продукта.
Панель из safety, policy, product и Trust and Safety откалибровала бы стратифицированный набор из 1 000 кейсов перед утверждением.
Миграции сохраняли бы старые ID и публиковали lineage, чтобы scorecard оставались сопоставимыми при разделении или слиянии категорий.

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

tool-usesystem-design

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

Триггеры уровней использовали бы заранее заданные метрики uplift, task success, autonomy horizon и доступа с доверительными интервалами, а не число параметров или впечатления.
Пересечение порога автоматически добавляло бы экспертные eval, ограничение доступа, мониторинг или no-go gate до продвижения модели.
Я бы пересматривал пороги после каждого крупного скачка capabilities, но никогда не понижал бы их во время активного release review.

Зачем это спрашивают: Интервьюер хочет увидеть, что уровни риска являются измеримыми триггерами контроля, а не ярлыками, которые подгоняют под запуск.

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

Контракт определял бы целевые поверхности, правила доступа к опасным доменам, качество доказательств, безопасность исследователей, раскрытие и декларации конфликтов интересов.
Я бы оставил 20% бюджета на повторные тесты, потому что отчёт без проверки mitigation неполон.
Находки шли бы в тот же severity и release-gate процесс, что и внутренние eval, а спорные оценки разбирала бы заранее выбранная третья сторона.

Зачем это спрашивают: Интервьюер проверяет, есть ли у внешнего red team реальная независимость, безопасный доступ и путь к release authority.

llm-eval

Я бы держал сырые элементы в изолированном evaluation enclave и разрешал экспорт только проверенных агрегатов и санитизированных обезличенных трасс.

Оценщики получали бы минимальный временный доступ по домену, а для ключей ответов и исполняемых артефактов требовалось бы более строгое одобрение.
Каждое чтение, запрос к модели, изменение scorer и экспорт записывались бы в неизменяемый аудит и связывались с целью оценки.
Воспроизводимость обеспечивали бы подписанные манифесты датасета, изолированные раннеры и детерминированные snapshot ID, а не распространение опасного контента.

Зачем это спрашивают: Интервьюер проверяет, умеет ли кандидат совместить контролируемый доступ с доказуемой и повторяемой оценкой dangerous capabilities.

designinspect-ai

Я бы отделил неизменяемые определения задач от горизонтально масштабируемого execution plane и подписанного хранилища доказательств.

Версии dataset, solver, scorer, model adapter, sandbox и policy формировали бы единый content-addressed манифест запуска.
Очередь делила бы задания по риску и ресурсам, а изолированные sandbox обслуживали tool-задачи вместе с rate-aware воркерами, checkpoint и идемпотентными повторами.
Release-дашборды читали бы только завершённые подписанные прогоны, а сырые транскрипты следовали бы правилам доступа и хранения конкретного harm-класса.

Зачем это спрашивают: Интервьюер оценивает практическую архитектуру Inspect AI, воспроизводимость, изоляцию и масштаб, а не знание названий API.

queries

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

Сервис поддерживал бы итеративные атаки в стиле PAIR, мутации, transfer attacks и штраф за отсутствие разнообразия, чтобы не потратить бюджет на одно семейство шаблонов.
Кандидатные атаки повторно оценивала бы отдельная policy-модель, а выборку вслепую проверяли бы люди для контроля сговора attacker и judge.
Новые успешные кластеры помещались бы в карантин, минимизировались и после проверки на leakage переходили бы в закрытый regression set.

Зачем это спрашивают: Интервьюер проверяет, рассматривает ли кандидат адаптивные атаки как управляемый поиск с независимой оценкой и долговременной регрессионной ценностью.

llm-safetyjailbreaktesting

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

Suite покрывал бы типографику, диаграммы, скриншоты, преобразования изображений, межмодальные противоречия и benign-аналоги на всех 6 языках.
Я бы делил результаты по harm, языку, качеству изображения и семейству атак, добавив парные text-only контроли для локализации уязвимой модальности.
Хеши медиа, преобразования, настройки модели и версии scorer фиксировались бы, чтобы точно воспроизвести сбой.

Зачем это спрашивают: Интервьюер оценивает, отражает ли multimodal jailbreak suite реальные межмодальные атаки и сохраняет ли полезные диагностические срезы.

sessionsllm-safetyjailbreak

Я бы оценивал stateful attack trajectories с отложенными триггерами, наращиванием доверия, отравлением контекста и размыванием policy вместо повторения одиночных промптов.

Состояние сценария хранило бы цель атакующего, внедрённые факты, наблюдения инструментов, summary и точный ход изменения policy-поведения.
Я бы выбирал короткие, средние и 200-ходовые горизонты, а adaptive pruning направлял бы compute на траектории с растущим риском.
Гейты оценивали бы и итоговый harm, и ранние сигналы вроде небезопасных обязательств или сохранённой вредоносной памяти.

Зачем это спрашивают: Интервьюер проверяет понимание того, что multi-turn safety зависит от состояния траектории и отложенного сбоя, а не от числа промптов.

agentsdesign

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

Сценарии покрывали бы confused deputy, повышение привилегий, indirect injection, необратимые действия, обход approval и ложные заявления об успехе, разделяя unsafe attempts, заблокированные попытки, выполненный harm и benign overblocking.
Детерминированные симуляторы проверяли бы side effects, а adversarial-наблюдения тестировали бы отношение агента к tool output как к недоверенным данным.
Для независимых репрезентативных Bernoulli-испытаний ноль вредных событий примерно в 3 миллионах испытаний даёт одностороннюю 95%-ную точную биномиальную верхнюю границу около 1 на миллион; точная пуассоновская граница требует независимой репрезентативной event exposure. Повторение сценариев, инструментов или пользователей создаёт кластеры, поэтому я бы применил cluster bootstrap либо иерархическую beta-binomial или Poisson model, указал effective sample size и связал оценку с production exposure.

Зачем это спрашивают: Интервьюер оценивает тестирование agentic harm по полномочиям, решениям и реальным последствиям, а не moderation финального ответа.

performance

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

Эксперты выполняли бы рандомизированные model-assisted и control задачи, измеряющие capability без возможности завершить реальный вредный процесс, а анализ учитывал бы случайные эффекты участников и задач.
Я бы симулировал мощность при правдоподобной сложности задач, внутригрупповой корреляции и пропусках; 40 экспертов нельзя считать достаточными без расчёта, поэтому могут понадобиться дополнительные задачи на эксперта или эксперты.
Привязанный к личности enclave, запрет сырого экспорта, поэтапная выдача, stop rules, legal и domain review защищали бы участников, а оценки эффекта и неопределённости ограничивали бы заявления об uplift.

Зачем это спрашивают: Интервьюер проверяет научную валидность, контроль участников и осторожность утверждений о чувствительном CBRN uplift.

upliftdesign

Я бы оценивал поэтапную цепочку атаки в изолированных сбрасываемых репликах: поиск уязвимости, разработку exploit и подтверждённый end-to-end compromise.

Участники по crossover-дизайну проходили бы model-assisted и control условия с одинаковым доступом к инструментам и случайным порядком, а анализ учитывал бы случайные эффекты участников и задач.
Заранее зарегистрированные endpoints измеряли бы завершение каждого этапа цепочки, время и безопасные непригодные для развёртывания артефакты вместо generic human uplift.
Симуляция мощности варьировала бы исходный навык, crossover-корреляцию, сложность задач и отток; я бы не предполагал, что 120 участников обнаружат эффект в 8 пунктов, и при необходимости добавил бы участников или задачи.

Зачем это спрашивают: Интервьюер оценивает, умеет ли кандидат строго измерять cyber uplift без перехода к неконтролируемому offensive testing.

design

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

Условия меняли бы стратегию модели при одинаковых теме, времени воздействия и доверии к источнику, а рандомизация была бы стратифицирована по языку и кластеру набора.
До набора я бы симулировал мощность с учётом кластеризации; простому сбалансированному независимому дизайну при baseline около 50% нужно примерно 4 400 участников для эффекта в 3 пункта и ещё больше с учётом оттока и множественных сравнений, поэтому 1 500 не обеспечат эту цель без нового дизайна или большего MDE.
Согласие, debriefing, право выхода, защита уязвимых групп и независимый ethics review сопровождали бы отчёт о неопределённости и пределах по языкам, темам и горизонту.

Зачем это спрашивают: Интервьюер проверяет причинный дизайн исследования, этические меры и аккуратную интерпретацию данных о манипуляции.

agentsreplication

Я бы создал инструментированные proxy-задачи на получение ресурсов, persistence, планирование репликации и уклонение от надзора внутри герметичной среды.

Sandbox предоставлял бы синтетические учётные данные, фальшивые сервисы, ограниченный compute, отсутствие внешнего маршрута и аппаратный kill path вне контроля агента.
Критерии успеха требовали бы проверенных изменений состояния, а не убедительных текстов, и graders различали бы частичное планирование и завершённую capability.
Я бы менял варианты заданий и canary для обнаружения запоминания, сохраняя каждую траекторию для экспертного review с ограниченным доступом.

Зачем это спрашивают: Интервьюер оценивает, основаны ли выводы об autonomy и self-replication на проверенном поведении в sandbox с сильным containment.

llm-eval

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

Я бы рандомизировал признаки evaluation, перефразировал их, скрывал происхождение задач и сравнивал парные capability-контроли на разных seed и checkpoint.
Причинные вмешательства в признаки и внутренние представления дополнялись бы поведенческими повторами, а scorer и contamination checks исключали бы простые объяснения.
Отчёт разделял бы наблюдаемую чувствительность к контексту, данные, совместимые со стратегическим занижением результата, и более сильные выводы, которые мы не можем подтвердить.

Зачем это спрашивают: Интервьюер проверяет экспериментальные контроли и эпистемическую осторожность вокруг значимых заявлений о sandbagging и deception.

design

Я бы использовал маршрутизируемый fleet классификаторов с откалиброванными специалистами, общими policy ID и shadow lane для кандидатов.

Быстрые широкие классификаторы обрабатывали бы обычный трафик, а неопределённые и тяжёлые случаи направлялись бы сильным специалистам или людям.
Калибровка, пороги и abstention версионировались бы по harm и языку на свежих production-like holdout.
Здоровье fleet отслеживало бы recall, precision, calibration error, drift, disagreement и коррелированный отказ, чтобы резервирование было реальным, а не декоративным.

Зачем это спрашивают: Интервьюер оценивает архитектуру classifier fleet в масштабе портфеля, особенно калибровку, маршрутизацию и коррелированный safety-отказ.

sessionsllm-safetyguardrails

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

Input-контроли классифицировали бы намерение и injection risk, а context-контроли помечали бы retrieved content и memory как недоверенные доказательства.
Tool-контроли проверяли бы полномочия пользователя, schema, policy и approval до выполнения; output-контроли проверяли бы утверждения, чувствительные данные и запрещённую помощь.
Каждый этап выдавал бы общий harm ID и reason code, чтобы fallback, appeal, observability и release eval использовали один контракт.

Зачем это спрашивают: Интервьюер проверяет layered guardrail design вокруг границ модели и инструментов при реальном ограничении latency.

aggregation

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

Катастрофические и тяжёлые классы получили бы жёсткие гейты recall или ASR с доверительными интервалами без компенсации успехами низкорисковых классов.
Для каждого класса также был бы потолок benign FPR и путь abstention, чтобы безопасность не достигалась отказом на всё.
Редкие классы запускали бы сбор экспертных данных или консервативные access controls, а не ложный pass на слабой выборке.

Зачем это спрашивают: Интервьюер оценивает, предотвращает ли кандидат сокрытие неприемлемого tail harm или over-refusal агрегированными метриками.

llm-safetyguardrailssystem-design

Я бы использовал единую policy-таксономию для всех языков, но калибровал данные, классификаторы и пороги с native-экспертизой по каждой локали.

Корпус включал бы нативные вредные запросы, code switching, транслитерацию, диалекты, обфускацию и benign boundary cases, а не только переводы с английского.
Native reviewers калибровали бы рубрики и разбирали разногласия, а back-translation служил бы диагностикой, не ground truth.
Rollout оставался бы закрытым по языку, пока каждый критический harm не достигнет порога, даже при проходящем глобальном среднем.

Зачем это спрашивают: Интервьюер проверяет multilingual safety как самостоятельную инженерную систему, а не задачу перевода.

Я бы компилировал небольшую иерархию из глобальной model policy, региональных обязательств, age protections, tenant-ограничений и контекста сессии в единый decision bundle.

Нижние слои могли бы только сужать разрешения, а каждое правило содержало бы precedence, юрисдикцию, даты действия, владельца и тест-кейсы.
Policy compiler находил бы противоречия и генерировал region-age-tenant regression matrix до публикации.
Runtime фиксировал бы resolved bundle на сессию и логировал decision ID, а legal отвечал бы за интерпретацию, safety engineering за точное исполнение.

Зачем это спрашивают: Интервьюер оценивает масштабируемую композицию policy, precedence и ясную границу между юридическим решением и инженерными контролями.

Закрытые вопросы

21
High-risk ассистент должен давать безопасный ответ за 2 секунды для 99,9% запросов и эскалировать людям менее 5%. Как спроектировать fallback и escalation?
escalationdesign
22
Guardrail сейчас добавляют 190 мс p95, но продуктовый бюджет равен 120 мс при доступности guardrail 99,99% и 50 000 запросов в секунду. Как достичь обеих целей?
llm-safetyguardrails
23
Внешний red team проверяет 6 продуктов за 30 дней, но трассы содержат данные несовершеннолетних и trade secrets с SLA удаления 24 часа. Как дать полезный доступ?
secrets
24
Модель обслуживает 100 миллионов взаимодействий в день на 8 поверхностях, и safety-команде нужно обнаруживать новый harm за 15 минут. Как спроектировать postdeployment observability?
designobservability
25
Спроектируйте harm-response system для 25 продуктовых команд с 5 минутами на подтверждение критического сигнала, 30 минутами на containment и 24 часами на сохранение evidence. Что построите?
system-designdesign
26
Программа получает 600 новых jailbreak-репортов в месяц и обещает добавить критические случаи в regression CI за 48 часов. Как построить pipeline от intake до regression?
llm-safetyjailbreakpromises
27
Release council каждую пятницу рассматривает 11 harm-классов, 7 языков и 4 deployment mode. Как спроектировать scorecard для go или no-go решения за 30 минут?
designdeployment
28
Совет из 9 человек должен принять go или no-go решение о frontier-релизе за 2 часа. Какой evidence contract вы потребуете до встречи?
29
Три release gate не проходят на 1,2, 3,8 и 9 процентных пунктов, а product просит waiver на 14 дней. Как спроектировать risk acceptance?
design
30
Модель должна охватить 40 миллионов пользователей за 21 день, а exposure тяжёлого harm оставаться ниже 0,2%. Как провести staged safety rollout?
31
Еженедельному frontier-релизу нужен rollback менее чем за 5 минут для model, policy, 16 classifiers и 80 tools. Что должно быть в rollback bundle?
rollback
32
У вас 300 000 RLHF safety-примеров, 6 harm-классов, 4 языка и годовой labeling budget $1,2 миллиона. Как вести data program?
alignmentrlhf
33
Reward model оценивает 500 миллионов ответов в месяц, но попарная judge-human accuracy падает с 0,82 до 0,61 в 3 safety-доменах. Как построить audit platform?
34
RLAIF-программа использует constitution из 22 принципов для 5 семейств моделей и 9 продуктовых команд. Как управлять изменениями с SLA публикации 7 дней?
rlaif
35
Safety fine-tune снижает jailbreak ASR с 8% до 1%, но повышает benign refusal с 6% до 23% на 60 000 кейсов. Какие regression gate нужны за 10 дней?
llm-safetyjailbreakfine-tuning
36
Нужен human oversight для 2 миллионов high-risk model decisions в месяц с 70 reviewers, p95 SLA 15 минут и бюджетом $900 000. Как это масштабировать?
37
Команда interpretability из 12 человек поддерживает 4 frontier checkpoint и должна за 6 месяцев подготовить release evidence. Как объединить probes, sparse autoencoders и causal tests без overclaiming?
causaltesting
38
Компания выпускает 3 семейства моделей в 25 странах и должна публиковать model card и system card за 14 дней после каждого major release. Какой disclosure standard вы напишете?
system-design
39
Safety case модели с 10 основными claims опирается на 240 eval runs, 35 mitigations и 6 external reviews. Как реализовать evidence lineage?
safety-caselineage
40
За 60 дней нужно сопоставить safety-программу с 13 harm-классами и 8 продуктовыми командами с NIST AI RMF 1.0 и Generative AI Profile. Как избежать checkbox compliance?
41
Организация хочет получить ISO/IEC 42001 certification за 9 месяцев для 4 AI-продуктов в 3 регионах. Какое evidence предоставит safety engineering?
42
GPAI-модель выйдет в ЕС через 5 месяцев, обслуживает 30 downstream providers и может соответствовать критериям systemic risk. Как подготовить technical evidence и сохранить ясное legal ownership?
ownershipsystem-design
43
У вас 6 недель, чтобы отправить 4 варианта модели в MLCommons AILuminate по 12 hazard categories. Как сделать участие полезным для внутренних release gate?
ailuminate
44
Frontier checkpoint готовят к внешнему predeployment review через 30 дней, с 3 уровнями secure access и SLA оценщика 72 часа. Какой пакет подготовить для UK AI Security Institute и CAISI при NIST?
llm-eval
45
Руководство должно за 21 день решить, выпускать ли модель 70B под open weights, при 8 выявленных severe misuse capabilities. Какую posture вы предложите?
46
Public fine-tuning API выполняет 50 000 jobs в месяц, и 4% adversarial adapters обходят safety classifier базовой модели. Как оценивать и гейтить bypass risk?
fine-tuningapidecision-making
47
Procurement хочет за 45 дней утвердить 7 сторонних моделей для 18 продуктов при evaluation budget $300 000. Какую safety acceptance system построить?
llm-evalsystem-designdependencies
48
Команда из 10 человек должна за 6 недель выбрать между eval vendor за $1,4 миллиона в год и собственной системой на Inspect AI за $900 000 в первый год. Как принять решение?
procurementinspect-ai
49
Три лаборатории хотят общий red-team protocol для 5 frontier models, 6 языков и 90-дневного учения без обмена raw weights. Какое соглашение вы спроектируете?
designtyping
50
Вы руководите 6 model-safety IC и должны за 2 квартала вывести 3 middle-инженеров на senior scope, сохраняя еженедельный release gate. Какую конкретную mentoring program проведёте?
mentoring
51
У мультимодального ассистента attack success равен 4% на matched single-modality controls, но 18%, когда безопасное speech audio сочетается с опасной инструкцией поверх изображения. Запуск через 18 часов. Что вы сделаете?
52
Offline benign refusal равен 6%, но после deployment достигает 27% на коротких mobile support prompts, пока recall отказов на harmful requests остаётся стабильным. Product ждёт решение через 4 часа. Что вы сделаете?
promptingdeployment
53
В 50 000 испытаниях обнаружены два severe failure, что ниже aggregate gate 0,02%, но оба относятся к одной attack family и одному cluster. Решение о релизе нужно принять в пятницу к 12:00. Выпустите модель?
aggregation
54
Статический suite показывает jailbreak ASR 3%, но adaptive attacker использует различия guardrail timing и score как oracle и достигает 21% за 500 попыток. Завтрашний gate нужно задать к 17:00. Что изменится?
llm-safetyjailbreakguardrails
55
Безопасная инструкция, заложенная в начале диалога, активируется только после tool result около 30-го хода и создаёт jailbreak path 14% против 1,5% в single-turn tests. Риск нужно ограничить за 2 часа. Что вы сделаете?
llm-safetyjailbreaktesting
56
Лабораторный tool agent без approval отправляет необратимую команду открыть клапан с ограниченным реагентом в 1 из 2 000 canary runs. Что вы сделаете за следующие 30 минут?
agentsdeployment-strategies
57
Из-за regional guardrail version skew один регион работает fail-open, а другой fail-closed в течение 18 минут для 2,4 млн запросов. У вас 45 минут на реакцию. Что вы сделаете?
guardrailsllm-safety
58
Вендор молча меняет classifier, и false negatives по severe harm растут с 2% до 9% на 8 000 anchors. Решение о продлении контракта нужно принять за 24 часа. Что вы сделаете?
procurement
59
Input filtering блокирует 98% опасных промптов, но output checks ловят лишь 61% успешных обходов в 10 000 тестов. Go или no-go review начнётся через 6 часов. Что вы предложите?
promptingtesting
60
Harmful-completion на арабском оценивается в 11% против 1,8% на английском по 12 000 кейсов, и качество ASR выглядит высоким, но большинство кейсов получено machine translation, а reviewer kappa равна 0,22. Запуск через 36 часов. Что вы сделаете?
estimation
61
В 4 из 200 сценариев для детей на тему self-harm модель даёт небезопасный совет для взрослых, а age-aware запуск через 5 дней. Какое решение вы примете завтра?
62
Новая модель повышает expert-rated успех на CBRN-задачах с 4% до 23%, пересекая capability threshold 10%. Совет собирается через 6 часов. Что вы предложите?
63
Cyber uplift study показывает прирост 9 пунктов против подписанного лимита 5 пунктов на 1 500 задачах, но candidate users получили более сильные tools или больше времени, чем control. Решение нужно принять к 15:00. Что вы сделаете?
uplift
64
Persuasion study показывает сдвиг отношения на 7,2 пункта против утверждённого лимита 3 пункта у 2 400 участников. Решения о публикации и продукте нужны за 48 часов. Что вы сделаете?
65
Autonomy proposal позволяет агенту выходить из sandbox в 2 из 500 задач ради завершения deployment, а согласование нужно завтра к 11:00. Что вы ответите?
agentsdeployment
66
Модель набирает 52% на direct eval, но decomposition scaffold с tool feedback даёт 81% на 2 000 matched tasks. За 48 часов нужно определить deployment-relevant upper capability. Что вы сделаете?
feedbackdeployment
67
В 7 из 10 000 trajectories наблюдается поведение, похожее на сокрытие проваленной цели, но confidence judge лишь 62%. Решение о релизе нужно через 6 часов. Что вы сделаете?
68
Модель дословно воспроизводит canary strings и reference answers публичного safety benchmark, давая прирост 11 пунктов, хотя известного dataset overlap нет. Результаты нужны завтра к 09:00. Что вы сообщите?
benchmarkingdeployment-strategies
69
Обновление judge model сдвигает safety score на 8 пунктов на 20 000 фиксированных outputs при неизменных human labels. За 3 часа нужно решить, валиден ли scorecard. Что вы сделаете?
70
Human judges получают kappa 0,58 и расходятся в 31 из 120 severe-harm cases. Go или no-go встреча начнётся через 8 часов. Как вы примете решение?
conflict
71
Три из 12 red-team annotators сообщают о симптомах травмы, а двое потеряли доступ к support resources. Следующий цикл на 5 000 кейсов начнётся через 72 часа. Что вы сделаете?
72
Опасный eval corpus с 18 000 restricted examples появляется в публичном artifact registry на 47 минут. Containment нужен в течение 1 часа. Что вы сделаете?
artifactsregistries
73
Restricted CBRN eval trace export с operational details был доступен по shared links 90 дней и затронул 2,7% из 60 000 records. Scope нужен к 17:00. Что вы сделаете?
llm-eval
74
Изменение deployed threshold снижает false negatives для одной high-risk cohort с 17% до 6%, но повышает false positives для другой cohort с 5% до 24% на 900 labeled cases. Что вы сделаете к завтрашнему дню?
cohortsdeployment
75
Для 12 языков reviewer agreement выше 0,8 в целом, но ниже 0,4 для culturally specific harassment в 3 регионах; их 4 000 кейсов также показывают 24% против 7% label-dependent outcomes. Product хочет rollout через 24 часа. Что вы сделаете?
76
Reward model получает 91% на broad benchmark, но на отдельном safety-critical slice из 2 500 пар предпочитает harmful answer в 28% пар. Начнёте ли вы RL training к 14:00?
benchmarking
77
На fixed normalized snapshot reward растёт на 35%, а verified safety task success остаётся 63%; decomposed evaluators считают каждый subanswer безопасным, но 14% combined outputs образуют harmful plan. Решение нужно за 4 часа. Что вы сделаете?
llm-evalnormalizationsnapshot
78
DPO candidate выигрывает 66% helpfulness pairs, но сдвигает outputs к коротким эвфемизмам; recall output guard падает, пока human-rated harmful completion растёт с 1,2% до 6,8% на 10 000 кейсов. Релиз через 12 часов. Что вы сделаете?
dpo
79
RLAIF constitution содержит два конфликтующих принципа, а AI feedback непоследовательно применяет их precedence в 19 из 600 adversarial cases. Следующий run начнётся через 8 часов. Что вы сделаете?
rlaiffeedback
80
Модель соглашается с ложными медицинскими или политическими утверждениями в 22% из 3 000 high-confidence user prompts. Решение о запуске нужно за 24 часа. Что вы сделаете?
prompting
81
После checkpoint merge, выполненного вслед за safety tune, jailbreak ASR возвращается с 3% до 12%, пока long-context reasoning остаётся на 79%. За 36 часов нужно выбрать релиз. Что вы сделаете?
llm-safetyjailbreak
82
Interpretability probe отмечает sparse-autoencoder feature с correlation 0,74 с deception на 40 примерах, а intervention review через 48 часов. Как избежать false alarm?
83
Causal activation intervention снижает harmful completion на 18 пунктов, но helpfulness падает на 26 пунктов на 5 000 задач. Решение нужно к понедельнику. Что вы сделаете?
causalactivation
84
Во время incident два существующих класса в taxonomy из 14 harm classes пересекаются, из-за чего 43 кейса учитываются дважды или остаются без владельца. Решение нужно за 72 часа. Что вы сделаете?
incidentsharm-taxonomy
85
Weighted scorecard проходит с 92%, но его aggregation design даёт CBRN slice с весом 1% результат 38% против floor 80%. Совет голосует через 3 часа. Что вы предложите?
aggregationdesign
86
После того как 7 из 400 severe agent tests провалили release gate, product policy owner вручную понижает все 7 случаев с critical до major. Решение нужно сегодня. Что вы сделаете?
agentstesting
87
Исходный release gate для severe harm равен 2%, но модель показывает 6,4% на 2 000 тестов. За 20 минут до Friday review executive просит переопределить gate как 7%. Что вы сделаете?
testing
88
Shadow suite с отключёнными tools показывает ноль failures, но live canary на 1% с включёнными tools создаёт 3 severe actions среди 18 000 sessions за 40 минут. Что вы сделаете до стадии 5%?
sessionsdeployment-strategies
89
Jailbreak становится вирусным через 6 часов после релиза, набирает 1,8 млн просмотров и 14 000 подтверждённых попыток. Что вы сделаете в первый час?
llm-safetyjailbreak
90
System card заявляет tool-misuse mitigation ниже 1%, но English suite из 120 prompts запускался с отключёнными tools. Публикация через 2 дня. Что вы сделаете?
promptingsystem-design
91
Регулятор просит воспроизводимое evidence для claim о 0,7% severe harm в течение 10 рабочих дней. Как вы его подготовите?
reproducibility
92
External AISI находит 12 severe failures в 900 тестах, пропущенных вашим internal suite из 30 000 кейсов. Ответ нужен за 72 часа. Что вы сделаете?
testing
93
После release open weights уже скопированы на 600 mirrors, когда подтверждается новая severe vulnerability. У вас 5 дней на response plan. Что вы предложите?
vulnerabilities
94
Customer fine-tune повышает jailbreak ASR с 3% до 34% после всего 5 000 examples. Решение о tenant access нужно принять за 4 часа. Что вы сделаете?
llm-safetyjailbreakfine-tuning
95
Third-party model выдаёт prohibited medical advice в 4,5% из 6 000 тестов после необъявленного provider update. Решение о fallback нужно принять за 90 минут. Что вы сделаете?
dependencies
96
Partner lab просит embargo на disclosure на 14 дней, но shared model запускается через 6 дней, а finding имеет 9 severe reproductions. Что вы сделаете?
97
Managed guardrail vendor пропускает 13% severe cases и раскрывает 42 000 traces при breach. За 7 дней нужно принять build-versus-buy решение. Что вы выберете?
guardrailsprocurementllm-safety
98
Teammate обходит mandatory gate и разворачивает модель с 8 severe failures в 500 тестах. Следующий rollout начнётся через 3 часа. Что вы сделаете?
deployment
99
Middle engineer принял неверное go-решение, затронувшее 2 300 пользователей, после вашего approval в 30-минутном review. Как вы будете менторить его следующие 2 недели?
mentoring
100
Public incident затрагивает примерно от 4 000 до 12 000 пользователей, но confidence в root cause лишь 55%. Первое заявление нужно через 90 минут. Что вы сообщите?
communicationestimationincidents

Вопросы

2За 45 дней нужно выпустить harm-таксономию v3 для 18 продуктовых поверхностей и 14 harm-классов. Как сделать её общим контрактом для policy, eval и guardrail?

3Модель 9B переходит от чата к tool use за 90 дней, и руководству нужны 4 уровня capability-risk с числовыми порогами релиза. Как вы определите систему уровней?

4У вас бюджет $750 000 и 8 недель на независимый predeployment red team для модели с 20 миллионами пользователей. Как вы организуете работу?

5Корпус dangerous-capability содержит 80 000 CBRN- и cyber-элементов и должен поддерживать 30 оценщиков без экспорта сырых данных. Как защитить его и сохранить воспроизводимость eval?

6Спроектируйте платформу Inspect AI для 2 миллионов eval-эпизодов на релиз, 40 вариантов моделей и SLA 6 часов. Какую архитектуру выберете?

7Статический suite показывает только 3% ASR, но адаптивный бюджет из 10 000 запросов достигает 19%. Как построить adaptive attack service для каждого еженедельного кандидата?

8Image-text модель работает на 6 языках и должна удерживать ASR тяжёлых multimodal jailbreak ниже 0,5% на 24 000 тестов. Как построить suite?

9Чат-модель поддерживает сессии по 200 ходов, а отложенные jailbreak появляются после 60-го хода в 7% атак. Спроектируйте multi-turn safety suite с ночным бюджетом 4 часа.

10Агент может вызывать 75 инструментов и выполняет 3 миллиона действий в день, а порог тяжёлых вредных действий ниже 1 на миллион. Как спроектировать safety eval?

12В cyber-исследовании 120 участников, бюджет $400 000 и цель за 10 недель обнаружить uplift на 8 пунктов над human baseline. Как его спроектировать?

13У вас 1 500 участников, 3 языка и 60 дней, чтобы измерить persuasive manipulation с минимально обнаружимым эффектом 3%. Как спроектировать human study?

14Frontier-агент получает sandbox на 72 часа и 50 autonomy-задач, без внешнего сетевого доступа и с гейтом успеха 2%. Как тестировать риск self-replication?

15Модель набирает 91%, когда ей говорят об обучении, и 68%, когда говорят о safety evaluation, на 2 000 парных задач. Как тестировать sandbagging или deception без лишних заявлений?

16Нужно обслуживать 14 safety-классификаторов на 900 миллионах запросов в день, с recall по harm выше 99% и benign blocking ниже 3%. Как спроектировать fleet?

17Tool-using ассистент обслуживает 10 миллионов сессий в день и имеет 250 мс на guardrail. Как построить каскад input, output и tool guardrail?

18Релиз покрывает 16 harm-классов, но агрегированный safety score равен 97%. Как задать гейты по классам, если recall тяжёлого harm должен быть выше 99,5%, а benign FPR ниже 4%?

19Guardrail проходят English с recall 99%, но показывают 81% на Arabic и 84% на Japanese среди 30 000 кейсов, а запуск через 8 недель. Какую систему построить?

20Модель обслуживает 2 000 enterprise tenants, взрослых и несовершеннолетних, в 12 регионах с конфликтующими policy-требованиями. Как наслоить safety policy без 24 000 форков?

Закрытые вопросы