Вопросы на собеседовании: AI Product Manager

AI PM отвечает за те же пользовательские и бизнес-результаты, что и любой PM, но дополнительно управляет вероятностным качеством, данными и экономикой инференса.

• Обычный PM часто может задать одно ожидаемое поведение, а AI PM определяет допустимые диапазоны качества и поведение при сбоях.
• AI PM поддерживает доказательную базу оценки при изменениях модели, промпта и данных, а не считает запуск финишем.
• Качество, задержка, стоимость и доверие пользователей входят в каждое решение о релизе вместе с использованием и удержанием.

AI PM решает, какой пользовательский результат должна дать система и какие компромиссы допустимы, а ML-инженер строит и улучшает техническую систему.

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

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

• Если проверку проходят 92% оцененных случаев, остальные 8% все равно завершаются ошибкой; детерминированное правило, напротив, дает фиксированный результат для одного и того же корректного ввода.
• Среднего качества недостаточно, потому что редкие опасные ошибки могут быть важнее частых мелких промахов.
• Поэтому критерии приемки включают диапазоны оценки, рискованные срезы, отказ от ответа и fallback-сценарий, а не один успешный путь.

Проблема подходит для AI, если в примерах есть полезные закономерности, некоторая неопределенность допустима, а результат улучшает реальное решение или задачу пользователя.

• Хорошие кандидаты включают классификацию разнообразных обращений в поддержку, ранжирование вариантов или подготовку текста для проверки пользователем.
• Я проверяю наличие репрезентативных данных или контекста и возможность оценить успех по меткам, рубрике или пользовательскому результату.
• Ожидаемая экономия времени или улучшение решения должны перевешивать стоимость модели, усилия на проверку и риск ошибок.

Правила или ручная работа лучше, когда решение стабильно, должно быть точным, встречается редко или ошибка слишком дорого обходится.

• Фиксированный расчет налога или возрастное ограничение должны использовать явную логику, потому что одинаковые входы требуют одинакового проверяемого результата.
• Редкий процесс, занимающий десять минут в неделю, может не оправдать сбор данных, стоимость модели и мониторинг.
• Неоднозначные случаи с высоким риском могут оставаться у квалифицированного специалиста, пока AI не достигнет подтвержденной планки качества и надежного процесса эскалации.

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

• Для сотрудника поддержки задача может звучать так: быстро подготовить точный ответ и сохранить контроль над тем, что уйдет клиенту.
• Я включаю ситуацию, желаемый результат и текущую помеху, например поиск по пяти страницам правил перед ответом.
• Такая формулировка оставляет выбор между поиском, предложенным черновиком или решением на правилах, вместо того чтобы заранее считать чат правильным ответом.

Я расспрашиваю о недавнем процессе и боли пользователя до упоминания любого AI-решения.

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

Текущий процесс и человеческий baseline показывают, где AI создаст ценность и какой уровень ему нужно превзойти.

• Я фиксирую время задачи, долю завершения, частоту исправлений, передачи задачи между людьми и этапы, где требуется профессиональное суждение.
• Человеческий baseline, например точность 85% относительно эталонных меток при четырех минутах на случай, не дает поставить нереалистичную цель в 100% для модели.
• Карта также показывает, не решат ли узкое место поиск, улучшенная форма или удаление лишнего этапа без AI.

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

• Например, предложенные ответы поддержки сократят медианное время подготовки на 30% для новых сотрудников.
• Гипотеза называет механизм, например сокращение поиска политики и работы над первым черновиком, а не просто рост использования AI.
• Она также задает защитную метрику, например отсутствие роста исправленных утверждений о правилах или жалоб клиентов.

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

• Качество может требовать не менее 90% прохождения рубрики в целом и отдельный минимум для рискованных вопросов о политиках.
• Операционные ограничения могут задавать p95 ответа ниже четырех секунд и среднюю стоимость ниже двух центов за завершенную задачу.
• Критерии сбоя описывают момент отказа от ответа, запасной экран, возможность править черновик и случаи обязательной проверки человеком.
• PRD фиксирует набор оценки и версии модели, промпта, источника поиска и схемы, на которых проверялись пороги.

Возможность модели описывает выполнение отдельной задачи, а результат продукта показывает, получают ли пользователи ценность во всем процессе.

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

Precision показывает, как часто положительный сигнал оказывается верным, а recall показывает, сколько реальных положительных случаев нашла система.

• При precision 80% в очереди мошенничества две из десяти отмеченных транзакций, отправленных на проверку, будут нормальными.
• При recall 70% система находит семь из десяти мошеннических транзакций и пропускает три.
• Я выбираю акцент по стоимости процесса, потому что проверяющим важно качество сигналов, а команде риска также важны пропущенные случаи.

Эти два типа ошибок обычно по-разному вредят пользователям и бизнесу, поэтому их стоимость определяет продуктовую политику.

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

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

• Снижение порога мошенничества может найти больше нарушений, но отправить больше нормальных платежей на проверку.
• Я выбираю порог на валидационных данных под требование вроде recall не ниже 90% при очереди до 1000 случаев в день.
• Выбранный порог, владелец, доказательства и условие пересмотра нужно документировать, потому что распределение оценок может измениться.

Матрица ошибок показывает число правильных и неправильных решений по реальному и предсказанному классам.

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

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

• Для списка из трех вакансий precision at 3 показывает, насколько эти три видимые позиции заполнены подходящими вариантами.
• Для поиска NDCG может поощрять размещение очень релевантных результатов выше просто допустимых, а не считать все позиции одинаковыми.
• Я все равно связываю офлайн-метрику с онлайн-результатом, например выбором результата, успешным откликом или сокращением повторных запросов.

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

• MAE показывает типичный промах в единицах цели, например среднюю ошибку срока доставки в 1,8 дня.
• RMSE сильнее штрафует редкие крупные промахи и подходит, когда ошибка в десять дней причиняет непропорциональный вред.
• Я также отдельно смотрю завышение и занижение, если у них разная цена, например лишние запасы и отсутствие товара.

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

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

Галлюцинация является неподтвержденным утверждением, groundedness проверяет наличие доказательств, а faithfulness проверяет точность передачи этих доказательств.

• Выдуманное правило возврата является галлюцинацией, потому что его не подтверждает надежный источник.
• Ответ может ссылаться на настоящую политику и оставаться неверным источнику, если в политике указано 14 дней, а в ответе 30.
• Я отдельно оцениваю поддержку утверждений и корректность цитат, потому что уверенная формулировка не является доказательством.

Abstention означает отказ системы отвечать в неуверенных случаях, а coverage является долей подходящих случаев, на которые она отвечает.

• Повышение планки доказательств может улучшить качество ответов, но снизить coverage и передать больше работы людям.
• Я измеряю оба показателя, например 95% прохождения качества при coverage 70%, а не хвалю качество на маленьком простом подмножестве.
• Продукту нужен полезный путь отказа, например запрос недостающего контекста, показ результатов поиска или передача на проверку.