Вопросы на собеседовании: AI Product Manager
100 реальных вопросов с образцовыми ответами и пояснениями для уровня Middle.
Смотреть пример резюме: AI Product Manager →Тренировка флешкарточками
Интервальное повторение · Hunter Pass
Вопросы
Я бы начал с одного сложного воркфлоу, где мы отвечаем за результат, а не с универсального чата.
- Я бы выбрал этап согласования, который сейчас занимает у операционной команды 45 минут, потому что встраивание в этот процесс создаёт издержки переключения помимо качества модели.
- Я бы получил разрешение учиться на принятых правках и причинах ревьюеров, создавая собственные данные по задаче, которые конкурент не купит у поставщика модели.
- Я бы дополнил воркфлоу дистрибуцией через текущую CRM или help desk клиента и проверил, завершают ли 30% еженедельных пользователей всю работу внутри продукта.
Зачем это спрашивают: Интервьюер проверяет, умеете ли вы превратить преимущества воркфлоу, данных и дистрибуции в защищаемый AI-продукт, а не полагаться на доступ к модели.
Я бы сравнивал AI с лучшим реалистичным процессом на правилах и поиске, а потолок автоматизации ограничил бы кейсами, за которые продукт может безопасно отвечать.
- Я бы измерил время обработки, решение с первого обращения и долю исправлений для шаблонов с улучшенным поиском, прежде чем приписывать выгоду AI.
- Я бы разметил долю обращений, требующих трактовки политики или действий с аккаунтом; если 35% требуют полномочий человека, начальный потолок автоматизации равен 65%.
- Я бы финансировал ассистента, только если он обходит бейзлайн по стоимости решённого обращения и удерживает фактические исправления ниже согласованного лимита 3%.
Зачем это спрашивают: Сильный ответ отделяет реальную ценность AI от обычного улучшения процесса и признаёт, что автоматизировать следует не каждый кейс.
Я бы использовал оценку, чтобы раскрыть предположения, но перед сравнением привёл ценность вариантов к одному временному горизонту.
- Я бы пересчитал обе выгоды за год: восемь сэкономленных часов в месяц при полной стоимости часа $75 дают $7200 на пользователя в год, а ревью контрактов может предотвращать ожидаемые годовые потери $20 000.
- Риск я бы оценил по тяжести и обратимости: пропущенную деталь встречи можно исправить, а пропущенный пункт контракта способен создать юридические потери.
- Реализуемость я бы оценил по eval из 100 кейсов, нужным интеграциям и стоимости ревью, затем сравнил годовую ценность с поправкой на риск и явными диапазонами уверенности.
Зачем это спрашивают: Интервьюер хочет увидеть инструмент решения, основанный на данных, неопределённости и цене ошибки, а не произвольную таблицу весов.
Я бы сформулировал небольшой набор портфельных убеждений, которые можно проверить несколькими связанными ставками.
- Одна гипотеза может звучать так: сокращение времени подготовки аналитика на 50% увеличит число завершённых отчётов в неделю; она охватывает извлечение, черновик и ревью.
- Примерно 70% ресурсов я бы отдал сильнейшему воркфлоу, 20% соседнему тесту и 10% дешёвым проверкам возможностей моделей.
- У каждой ставки был бы общий пользовательский исход, гейт качества модели и дата остановки, чтобы одно эффектное демо не поглотило весь портфель.
Зачем это спрашивают: Это проверяет, умеете ли вы управлять связанными AI-ставками в условиях неопределённости, сохраняя фокус и возможность учиться.
Я бы получал данные через основной воркфлоу, не позволяя поведению нынешних продвинутых пользователей определить всех будущих пользователей.
- Я бы просил ревьюеров подтверждать или исправлять только решения, влияющие на их работу, и сохранял исходный ввод, финальную метку и причину при явном согласии на использование.
- Недопредставленные отрасли я бы добавлял через оплачиваемых дизайн-партнёров и целевую разметку, а не ждал органического объёма.
- Я бы отслеживал распределение меток и ошибки по размеру клиента, языку и воркфлоу, чтобы маховик не закреплял предпочтения самых громких 10% пользователей.
Зачем это спрашивают: Сильный ответ связывает законное получение данных с ценностью продукта и замечает смещение выборки в циклах данных на основе фидбэка.
Я бы использовал многоуровневую модель аннотации с чёткой ответственностью за инструкции, качество и сложные кейсы.
- Обученный подрядчик может размечать обычные интенты и фрагменты-доказательства, а внутренние специалисты поддержки будут разбирать чувствительные к политикам и неоднозначные примеры.
- Я бы запустил пилот на 300 кейсах и уточнял примеры, пока попарное согласие не превысит целевой уровень, например Cohen's kappa 0,75, после чего масштабировал объём.
- Еженедельные аудиты охватывали бы каждого аннотатора и каждый класс, а к меткам прикреплялась бы версия инструкции для прослеживаемости изменений.
Зачем это спрашивают: Интервьюер оценивает, умеете ли вы сделать разметку повторяемой, измеримой и соответствующей риску домена.
Я бы использовал active learning, только если выбор информативных кейсов снижает общую стоимость разметки и не искажает продакшен-распределение.
- Я бы сравнил кривую случайной разметки с выборкой по неуверенности или расхождению, измеряя прирост качества на каждые $1000 экспертной работы.
- Я бы сохранил случайную выборку в 20%, потому что выбор по неуверенности может чрезмерно сфокусироваться на шумных редких кейсах и скрыть регрессии обычных.
- Я бы продолжил, если тот же релизный порог достигается существенно меньшим числом меток, например 4000 вместо 10 000, с учётом расходов на отбор и ревью.
Зачем это спрашивают: Сильный ответ рассматривает active learning как экономический выбор с рисками выборки, а не как автоматическое техническое улучшение.
Я бы использовал синтетические данные для расширения известных сценариев, но не позволил бы им самостоятельно определять релизную истину.
- Синтетические кейсы полезны для редких форматов, adversarial-вариаций и контролируемой сложности, где ожидаемое поведение каждого примера можно проверить.
- Я бы сохранил отдельный набор из реальных воркфлоу, потому что сгенерированные примеры наследуют стиль, слепые зоны и предположения о политиках своей модели.
- В релизном решении реальные и синтетические срезы показывались бы отдельно, а перед широким запуском было бы хотя бы несколько сотен репрезентативных реальных кейсов.
Зачем это спрашивают: Интервьюер хочет услышать и о пользе синтетических данных для покрытия, и об их неспособности самостоятельно представить реальный спрос.
Я бы сегментировал eval по тому, кто использует фичу, какую работу выполняет и к чему приводит ошибка.
- Пользовательские срезы включали бы новых и опытных пользователей, enterprise и self-serve аккаунты, а также каждый поддерживаемый язык со значимым трафиком.
- Срезы по работе разделяли бы короткие переформулировки, черновики из нескольких источников и ответы, чувствительные к политикам, потому что среднее скрывает разную сложность.
- У риск-срезов были бы отдельные гейты, например 95% фактического прохождения для регулируемого текста, даже если low-stakes-брейншторм можно запустить при полезности 85%.
Зачем это спрашивают: Сильный ответ отвергает агрегированный балл, который может скрывать сбои для важных пользователей, задач или уровней риска.
Я бы выразил каждый вариант через ожидаемую ценность успешной задачи, чтобы не складывать проценты, доллары и секунды как одинаковые единицы.
- У качества был бы жёсткий минимум, например запрет моделей ниже 87% успешности задачи, чтобы низкая цена не компенсировала непригодный результат.
- Выше минимума я бы оценил вклад принятых результатов в маржу, затем вычел стоимость инференса и ревью и денежный эффект потери завершений из-за задержки.
- Я бы проверил эти оценки онлайн-тестом и показал диапазоны чувствительности, потому что роутинг не должен зависеть от одной угаданной цены пункта качества.
Зачем это спрашивают: Это проверяет, умеете ли вы объединять модельные и продуктовые ограничения, не сводя решение к одной технической метрике.
Я бы задавал порог каждого класса по цене false positive и false negative, а не использовал 0,5 для всех.
- Пропуск фрода может стоить $800 за кейс, поэтому я принял бы больше ложных алертов, если нагрузка на ревью и трение для клиента остаются в пределах.
- Ложная маршрутизация в отмену может запустить нежелательный retention-воркфлоу, поэтому этому классу нужен более высокий порог precision, чем общим вопросам.
- Я бы посчитал ожидаемые потери на репрезентативной валидации и пересматривал пороги при изменении стоимости кейса, распространённости или цены ревью.
Зачем это спрашивают: Сильный ответ связывает пороги модели с асимметричными бизнес-последствиями и меняющимися операционными условиями.
Я бы выбрал максимальное безопасное покрытие, при котором очередь неопределённых кейсов укладывается в реальную человеческую мощность.
- Я бы построил зависимость precision от покрытия по уровням риска и отдельно задал пороги автопринятия для кейсов с низкой и высокой ценой ошибки.
- При прогнозном объёме доля отказов должна помещаться в 2000 ежедневных ревью с запасом на пики, отпуска и апелляции.
- Если спрос превышает мощность, я бы сузил подходящие кейсы или улучшил приоритизацию, а не молча снизил уверенность и перегрузил ревьюеров.
Зачем это спрашивают: Интервьюер проверяет, образуют ли политика уверенности, покрытие автоматизации и человеческие операции единую работающую систему.
Я бы рассматривал nDCG как сигнал качества поиска и потребовал доказать улучшение исхода маркетплейса без ущерба здоровью предложения.
- Основной онлайн-метрикой могут быть завершённые покупки на поиск, а guardrails включат возвраты, отмены покупателями и время до первой продажи для новых продавцов.
- Я бы сегментировал показы продавцов и концентрацию, потому что рост конверсии может прийти из-за голодания длинного хвоста, а не лучшего мэтчинга.
- Switchback-тест или тест на уровне рынка уменьшит взаимовлияние treatment и control, когда обе группы используют один инвентарь.
Зачем это спрашивают: Сильный ответ связывает метрики ранжирования с исходами обеих сторон маркетплейса и учитывает взаимовлияние в эксперименте.
Я бы построил слепую регулярную программу с доменными рубриками и путём арбитража.
- Ревьюеры оценивали бы фактическую подтверждённость, завершение задачи и вред по шкалам с примерами того, что означают 1, 3 и 5.
- Выборка каждого релиза включала бы пары ответов бейзлайна и кандидата в случайном порядке, сбалансированные по доменам, языкам и сложным продакшен-кейсам.
- Я бы отслеживал согласие, дрейф ревьюеров и стоимость кейса, а разногласия направлял владельцу домена, а не усреднял до исчезновения.
Зачем это спрашивают: Интервьюер хочет увидеть операционную программу оценки, которая даёт стабильные релизные данные вместо редких субъективных ревью.
Я бы использовал LLM-судью для масштаба только после доказательства, где он согласуется с людьми, а где нет.
- Я бы откалибровал его на слепых метках доменных ревьюеров и показал согласие по языку, длине ответа и классу риска, а не одну общую корреляцию.
- За людьми остались бы трактовка политик, ошибки с большим импактом и случайная аудиторская выборка, потому что судьи склонны предпочитать стиль, позицию и знакомые формулировки.
- Изменение оценки судьи блокировало бы релиз только при стабильных промптах, закреплённых версиях, повторных прогонах и человеческой апелляции для пограничных кейсов.
Зачем это спрашивают: Сильный ответ признаёт автоматическую оценку полезной инфраструктурой, но не независимым источником продуктовой истины.
Я бы назначил ответственную пару из продукта и инженерии, распределив конкретные гейты между владельцами доменов.
- Продукт владеет таксономией пользовательских рисков и релизными порогами; инженерия владеет детерминированным запуском, фиксацией версий и блокировкой в CI.
- Applied ML отвечает за регрессии модели и промпта, а legal или Trust and Safety утверждает срезы политик, которые имеет право оценивать.
- RFC назвал бы ответственных за обновление кейсов, право снять проваленный гейт и срок действия каждого исключения, чтобы общая система не осталась без владельца.
Зачем это спрашивают: Интервьюер оценивает, умеете ли вы определить ясную операционную ответственность между техническими и governance-функциями.
Я бы явно сформулировал причинный мост и проверил каждое звено, а не заявлял, что семь офлайн-пунктов равны продуктовой ценности.
- Гипотеза может звучать так: более полное и фактическое выполнение уменьшает число правок, сокращает время до отправки и увеличивает завершённые задачи в неделю.
- Первое звено я бы проверил на записанных или модерируемых сессиях, измеряя размер правок и время завершения на тех же срезах задач, что и eval.
- Затем я бы запустил защищённый онлайн-тест по успешным задачам на активного пользователя, оставив доверие, отказы, стоимость и эскалации guardrails.
Зачем это спрашивают: Сильный ответ показывает, как офлайн-качество становится проверяемым продуктовым механизмом, а не рекламным заявлением.
Я бы рандомизировал пользователей между стабильными продуктовыми политиками и измерял распределение исходов, а не сравнивал по одному ответу каждой модели.
- Вариант закреплялся бы за пользователем или аккаунтом, а модель, промпт, retrieval и настройки сэмплирования логировались бы для каждого показа.
- Тест шёл бы достаточно долго для повторного использования, а размер выборки учитывал бы повышенную дисперсию из-за стохастических ответов.
- Я бы заранее задал guardrails пользовательской ценности и безопасности, затем проверил хвосты и вред когортам, потому что одинаковое среднее может скрывать редкие тяжёлые ответы.
Зачем это спрашивают: Интервьюер хочет дизайн эксперимента, который считает изменчивость AI-ответов частью продукта, а не шумом, который можно игнорировать.
Я бы маршрутизировал по риску задачи и доказанной сложности с измеримым правилом fallback, а не только по длине запроса.
- Малая модель обрабатывала бы low-risk-классификации выше откалиброванного порога уверенности, а регулируемые задачи или вызовы инструментов сразу шли бы в сильную модель.
- Неоднозначные кейсы эскалировались бы по неопределённости или дешёвому верификатору, а пользователь получал бы один цельный ответ, не замечая смены модели.
- Я бы оптимизировал стоимость успешной задачи и ограничил долю большой модели, но бюджет не мог бы отменить минимальный гейт качества для класса риска.
Зачем это спрашивают: Сильный ответ объединяет продуктовую политику, экономику моделей и риск, а не считает роутинг только инфраструктурным решением.
Я бы включил reranking только для запросов, где прирост точности достаточно меняет успех пользователя, чтобы оправдать задержку и цену.
- Я бы сегментировал прирост по запросам с точными терминами, неоднозначным и требующим нескольких документов, потому что общий рост может идти из одного узкого класса.
- Многоступенчатая схема может делать широкий retrieval, запускать reranking только для неуверенных запросов и обходить этап для известных навигационных запросов.
- Метрикой решения были бы подтверждённые успешные ответы на доллар с guardrail по p95 latency, проверенные ограниченным онлайн-тестом.
Зачем это спрашивают: Интервьюер проверяет продуктовое суждение о качестве, задержке и стоимости конкретного архитектурного выбора в RAG.
Закрытые вопросы
- 21
Система на промптах и RAG всё ещё пишет в неправильном отраслевом стиле. Как вы решите, нужен ли fine-tuning, включая стоимость поддержки?
ragpromptingfine-tuning - 22
Политики меняются ежедневно, но перестроение индекса знаний занимает шесть часов. Как вы зададите требования к свежести и SLA продукта?
indexes - 23
AI-ассистент полезен, но иногда выдумывает детали. Какую стратегию по галлюцинациям и доверию вы добавите в roadmap?
hallucinationroadmaproadmapping - 24
Как вы спроектируете AI UX для неопределённости, не показывая пользователю вводящий в заблуждение процент уверенности?
design - 25
Пользователи часто исправляют AI-черновики, но редко нажимают thumbs down. Как вы соберёте данные о правках и фидбэке без сильного трения?
feedback - 26
AI-воркфлоу иногда требует специалиста. Как вы спроектируете человеческую эскалацию как часть продукта, а не исключение?
escalationdesignerror-handling - 27
Поставщик выпускает новую версию модели каждые несколько месяцев. Каким процессом жизненного цикла и приёмки версий вы будете владеть?
procurementreleasesconcurrency - 28
Как вы примените shadow- и canary-этапы для запуска новой модельной политики, не ожидая полной определённости?
launchesdeployment-strategies - 29
Какой продуктовый мониторинг дрейфа вы потребуете для AI-извлечения данных после запуска?
monitoringiaclaunches - 30
В 09:00 доля принятых ответов AI-агента поддержки падает с 72% до 51% после того, как одним релизом изменились модель, промпт, корпус retrieval, политика возвратов и экран проверки. Как вы выстроите наблюдаемость, чтобы Product установил причину регрессии до разбора инцидента в 15:00?
retrievalpromptingagents - 31
Использование может вырасти со 100 000 до двух миллионов AI-задач в месяц. Как вы построите бюджет и прогноз inference?
inference - 32
Команда предлагает semantic caching и speculative decoding для снижения стоимости и задержки AI. Какие продуктовые компромиссы вы оцените?
cachinglatencysemantic-cache - 33
Как вы выберете ценовую метрику и упаковку для AI-воркфлоу исследования с сильно меняющимся использованием?
pricingmonitoring - 34
AI-воркфлоу приносит $40 с аккаунта в месяц, но расходы на inference, ревью и поддержку сильно различаются. Как вы будете управлять gross margin по воркфлоу?
cssinference - 35
Несколько клиентов потребляют в 20 раз больше медианного AI-объёма на безлимитном плане. Как вы спроектируете лимиты или fair-use-политику?
design - 36
Enterprise-покупатель просит SLA 99,9% для AI-фичи черновиков. Что вы включите и исключите из обязательства?
- 37
Какие требования к изоляции данных клиентов вы установите для мультитенантного enterprise RAG-продукта?
ragmulti-tenancy - 38
Как вы определите хранение данных и приватность для промптов, ответов, фидбэка и eval-трейсов?
promptingfeedbackretention - 39
Когда и как вы проведёте Trust and Safety review новой AI-фичи для коучинга?
- 40
Red-team нашла jailbreak, смещённые отказы и небезопасный выбор инструментов. Как вы превратите выводы в задачи roadmap?
llm-safetyred-teamroadmap - 41
Как вы спроектируете риск-ориентированные контроли для одной AI-платформы, которая обслуживает брейншторм, поддержку клиентов и платёжные действия?
risk-managementdesign - 42
Что вы включите в публичную model card или раскрытие информации об AI-фиче для клиентов?
model-card - 43
Какие kill-критерии вы зададите до запуска пилота AI-фичи?
launches - 44
Как вы выстроите roadmap, если нужная способность модели может улучшиться через шесть месяцев, но сегодня ненадёжна?
roadmaproadmapping - 45
Как вы запишете OKR, связывающие модельные и пользовательские исходы для AI-ассистента поддержки?
performance - 46
Applied Research хочет три месяца исследовать новую агентную архитектуру, а продукту нужен обещанный клиентский воркфлоу. Где вы проведёте границу партнёрства?
agentsarchitecture - 47
Что должен содержать кросс-функциональный RFC до разработки enterprise AI-фичи поддержки решений?
cross-functionalcross-teamdecision-making - 48
Как вы подготовите sales к продаже AI-фичи без завышения качества или будущих возможностей?
- 49
Как вы проведёте customer discovery для enterprise AI-воркфлоу, если покупатели, администраторы и ежедневные пользователи хотят разного?
- 50
AI-фича для письма запускается на шести языках и должна работать с ассистивными технологиями. Как вы зададите требования к доступности и качеству локализации?
launchesa11y - 51
Классификатор страховых случаев показывает precision 82%, но после двухнедельного пилота на 400 кейсах только 31% специалистов говорят, что доверяют его рекомендациям. Какое решение вы примете до встречи по раскатке в пятницу?
precisionreleases - 52
Модель медицинского триажа показывает общую accuracy 91%, но пропускает 12% срочных случаев, тогда как текущий ручной процесс пропускает 4%; запуск назначен через 10 дней. Что вы сделаете?
launchesconcurrency - 53
Один порог антифрод-модели ловит 88% злоупотреблений, но блокирует 6% добросовестных новых клиентов и лишь 0,8% постоянных; Finance ждет решение через пять дней. Оставите один порог?
- 54
Новая пишущая модель поднимает accuracy по рубрике с 84% до 90%, но task completion падает с 68% до 59% в семидневном тесте на 8000 сессий. Какую модель вы выпустите в следующий понедельник?
sessions - 55
Sales copilot достиг 64% недельного adoption, но доля галлюцинаций выросла с 1,5% до 4,8% на аудите 600 ответов, а звонки по продлению начинаются через три недели. Продолжите продвижение?
hallucinationdecision-making - 56
Цитаты в исследовательском ассистенте поднимают оценку доверия к ответам с 52% до 73%, но p95 latency растёт с 3,2 до 7,1 секунды, а completion падает на 6 процентных пунктов; решение о запуске нужно принять в четверг. Что вы выберете?
latencycitationslaunches - 57
После ужесточения evidence gate доля неподтвержденных ответов падает с 5% до 1%, но abstention растет с 9% до 38%, а deflection поддержки за неделю падает на 18%. Что вы измените к пятнице?
abstention - 58
В очередь AI-ревью поступает 1200 помеченных кейсов в день, но операционная команда может проверить только 700, и к понедельнику backlog превысит 5000. Какое продуктовое решение вы примете за следующие 48 часов?
backlogdata-structuresagile - 59
Модель-кандидат прибавляет 4 пункта на новых клиентских примерах, но за два дня до релиза теряет 7 пунктов на golden set из 2000 элементов. Engineering считает набор устаревшим. Разрешите регрессию?
releases - 60
Синтетический eval прогнозирует рост качества на 9 пунктов, но human review 300 кейсов находит лишь 1 пункт роста и вдвое больше нарушений тона; запуск через шесть дней. Каким данным вы доверитесь?
launches - 61
LLM judge оценивает суммаризатор в 92%, а три обученных ревьюера дают 74% и расходятся с judge в 23% из 400 кейсов. Завтра нужно решение go или no-go. Что вы сделаете?
llmconflict - 62
Разметка 5000 доменных примеров будет стоить $120 000 и займет шесть недель, а дешевый подрядчик предлагает $35 000 и три недели при inter-annotator agreement 71%. Что вы порекомендуете к вторнику?
annotator-agreementprocurement - 63
Accuracy рекомендаций кредитного ассистента падает с 87% до 79% для заявок после изменения политики 12 дней назад, а на старом трафике остается стабильной. Что вы решите за 24 часа?
- 64
Ранжирующая модель учится на кликах, но через четыре недели показывает одни и те же популярные шаблоны в 62% случаев, а discovery новых шаблонов падает с 28% до 9%. Какое изменение вы одобрите в этом спринте?
agile - 65
RAG reranker поднимает grounded-answer accuracy с 76% до 84%, но добавляет 850 мс к медиане и увеличивает p95 latency с 2,9 до 4,6 секунды; исторически conversion падает после четырёх секунд. Что вы выпустите через восемь дней?
ragrerankinggroundedness - 66
Ассистент по политикам сослался на документ, удаленный 36 часов назад, в 27 клиентских сессиях, а SLA свежести индекса равен четырем часам. Что вы решите до полудня сегодня?
indexessessions - 67
Fine-tuned модель поддержки повышает точность решения с 78% до 86%, но требует $90 000 сразу и около $18 000 ежемесячно на новые метки и переобучение; базовая модель обновляется ежеквартально. Что вы порекомендуете через пять дней?
fine-tuning - 68
После обновления foundation model в 09:00 завершенные бронирования падают на 24%, tool-call errors растут с 2% до 15%, затронуто 18 000 сессий. Какое продуктовое решение вы примете за следующие 30 минут?
sessions - 69
Через 72 часа поставщик переключит используемый продуктом alias на новую модель; eval из 600 кейсов показывает падение качества возвратов на 5 пунктов при общем росте на 3 пункта. Что вы решите сегодня?
procurement - 70
Маршрутизация 70% низкорисковых запросов на малую модель экономит $160 000 в месяц, но accepted-output rate падает с 74% до 68% в тесте на 20 000 сессий. Запустите на следующей неделе?
launchessessions - 71
Прогноз расходов на инференс к концу месяца равен $520 000 при бюджете $400 000, до конца остаётся 12 дней, признаков фрода или сбоя нет. Что вы сократите к завтрашнему дню?
inference - 72
Более сильная модель поднимает принятие ответов на 5 процентных пунктов, но p95 latency растёт с 3,5 до 6,8 секунды, а checkout conversion за 14 дней падает с 11,2% до 9,6%. Что вы выпустите в пятницу?
latency - 73
Semantic caching может экономить $85 000 в месяц, но 6% кешированных ответов по политикам могут оставаться устаревшими до 24 часов; Procurement ждет решение на этой неделе. Что вы одобрите?
cachingsemantic-cacheprocurement - 74
Функция speculative decoding поставщика сокращает p95 latency на 35% и может поднять conversion на 4%, но требует двухлетнего эксклюзивного контракта на serving стоимостью $2,4M. Что вы порекомендуете через 10 дней?
latencyprocurementdecoding - 75
AI-фича поддержки стоит $0,42 за разговор и предположительно предотвращает передачу оператору 40% обращений, но через 30 дней только 58% этой группы считают вопрос решённым. Какую unit-метрику вы возьмёте на следующий квартал?
monitoring - 76
Ваш AI-тариф за $19 в месяц создает в среднем $24 расходов на инференс и поддержку для активных пользователей, которые составляют 18% подписчиков; pricing review через семь дней. Что вы предложите?
pricinginference - 77
Новый месячный лимит в 500 генераций сократит расходы на инференс на $110 000, но 900 power users дали 28% рефералов, и 41% из них говорят, что уйдут; запуск через 14 дней. Что вы измените?
releasesinference - 78
Enterprise-клиент просит месячный SLA доступности 99,9% для AI workflow, но текущая доступность 99,4%, а контракт на $1,8M нужно подписать через три недели. Что вы пообещаете?
promises - 79
Один клиент с годовой регулярной выручкой $900 000 получает accuracy извлечения только 71%, тогда как остальные 24 enterprise-клиента в среднем получают 89%, а продление через 45 дней. Приоритизируете отдельное исправление?
prioritization - 80
AI-аналитик аккаунта должен выйти через восемь дней. Английская локаль показывает 91% качества, $2,4 млн законтрактованной выручки и ежедневное покрытие ревьюерами; французская показывает 87%, $900 000 и покрытие три дня в неделю; японская показывает 82%, обязательство клиента на $1,6 млн и отсутствие квалифицированного ревьюера ещё шесть недель; португальская показывает 86%, $150 000 в воронке и покрытие два дня в неделю. Порог запуска равен 85%. Какие локали вы запустите?
launcheslaunch-gatecoverage - 81
За пять дней до запуска accessibility-тест показывает, что пользователи screen reader не могут проверить или исправить 38% AI-полей формы; это затрагивает около 6000 пользователей в месяц. Запустите фичу?
a11yformstesting - 82
AI-координатора проектов случайно распределили по пользователям среди 24 000 участников в 600 общих рабочих пространствах. Через 21 день участники тестовой группы закрывают на 13% больше задач, но созданные AI назначения и сводки видят их коллеги из контрольной группы, а в 68% пространств есть обе группы. Отчёт совету директоров через 48 часов. Как вы интерпретируете и переделаете тест?
design - 83
Через 12 дней AI-эксперимент с onboarding показывает рост activation на 3 процентных пункта, но набрал только 1800 из 8000 пользователей, нужных для power 80%; launch slot закрывается в пятницу. Что вы решите?
experimentsonboardingactivation - 84
Ежедневное использование нового AI-коуча подскакивает до 44% в первую неделю, но к четвёртой падает до 19%, ниже 23% старой фичи; команда хочет полный запуск на следующей неделе по числу регистраций. Что вы сделаете?
launches - 85
После добавления confidence labels опрос доверия растет с 3,1 до 4,0 из 5, но пользователи проверяют лишь 14% высокорисковых ответов против прежних 26%; решение нужно через четыре дня. Какой сигнал важнее?
risk-management - 86
Обязательный human review снижает тяжелые AI-ошибки с 3,2% до 0,7%, но 46% пользователей уходят при медианном ожидании шесть часов; анализ продлений нужен к следующей среде. Что вы измените?
- 87
Legal выясняет, что 35% из 200 пилотных пользователей не поняли, что их чаты с поддержкой пойдут на обучение модели, а публичный запуск на 50 000 пользователей через девять дней. Что вы выпустите?
launches - 88
Red-team проверка показывает, что 8% из 500 adversarial prompts выдают инструкции по обходу правил безопасности труда; расширение beta с 2000 до 20 000 пользователей назначено через 48 часов. Что вы решите?
promptingred-team - 89
Ассистент поддержки придумал политику возврата в 63 разговорах за 11 часов, что привело к спорным обещаниям на $18 000. Что вы сделаете за следующие два часа и семь дней?
promises - 90
AI-фича итогов встреч имеет 12% недельного adoption через три месяца, стоит $70 000 в месяц и экономит активному пользователю лишь четыре минуты в неделю; Q3 planning начинается в пятницу. Оставите ее?
decision-making - 91
В 10-недельном квартале доступно 18 engineer-weeks: обещанный eval dashboard требует 10, проект по стоимости инференса требует 8 и экономит $300 000 в квартал, а запрошенное Sales agent-демо требует 7 к конференции через шесть недель. Что вы приоритизируете в понедельник?
promisesagentsinference - 92
Applied Research показывает впечатляющий прототип агента после 8 недель, но у него нет eval set и baseline, а productization требует 6 engineer-weeks до клиентского демо через 1 месяц. Что вы решите на этой неделе?
agentsprototypes - 93
Sales пообещала 95% extraction accuracy потенциальному клиенту на $1,2M, который закрывается через 20 дней, но продукт в среднем дает 86%, а выборка клиента из 150 документов получила 81%. Как вы ответите к завтрашнему дню?
promises - 94
Корпоративный клиент на $1,1 млн передаёт доменный eval-набор из 800 кейсов и просит за 10 дней закрепить общую точность 93% как договорное условие приёмки. При этом 46% кейсов составляют простые продления, которые дают лишь 14% продакшена, а два ревьюера клиента расходятся в 19% меток. О чём вы будете договариваться?
conflict - 95
Launch scorecard требует менее 2% галлюцинаций, но последний eval на 1000 кейсах показывает 2,8%; CMO просит waiver, потому что кампания стартует через 36 часов. Что вы решите?
hallucinationlaunches - 96
10% canary релиза модели показывает падение task completion на 8 процентных пунктов, рост p95 latency на 22% и 4500 затронутых сессий за три часа. Engineering хочет ещё день данных. Откатите сейчас?
latencysessionsrollback - 97
Квартальный AI scorecard показывает рост качества на 6 пунктов и снижение стоимости инференса на 18%, но successful task completion упал на 5%, а обращения в поддержку выросли на 12%; business review в пятницу. Как вы оцените результат?
inferenceperformance - 98
В 15:00 CEO просит одностраничный отчет к 17:00 после того, как AI adoption не достиг цели 40% и составил 24%, расходы на инференс превысили план на $210 000, а галлюцинации остались в пределах gate 2%. Что вы отправите?
hallucinationdecision-makinginference - 99
APM предлагает за три недели запустить AI-ответы на 100% пользователей, опираясь на 20 demo prompts и без taxonomy ошибок; завтра у вас 45-минутная коучинг-сессия. Как вы будете менторить?
promptingmentoringsessions - 100
Ваш RFC предлагает направлять на дешевую модель только низкорисковые запросы, а ML lead хочет 80% routing ради квартальной экономии $250 000; architecture review через 48 часов. Как вы разрешите разногласие?
conflictdecision-makingarchitecture