Medium: Человекоцентричный ИИ — как применять руководство Google PAIR на практике
Стейкхолдеры требуют добавить генеративный AI в каждый интерфейс продукта, воспринимая алгоритмы как универсальное решение любой бизнес-задачи. Но дизайнер или исследователь — это последний барьер между разрекламированной технологией и раздражённым пользователем. Развернуть ИИ, не понимая контекст, в котором работает человек, — значит отправить войска без карты. Руководство Google’s People + AI Research (PAIR) Guidebook даёт именно те правила взаимодействия, которые здесь необходимы: это практическое руководство по проектированию ИИ, который решает реальные проблемы, а не демонстрирует технологию ради технологии.
Проверка «нужен ли здесь ИИ?»
Самая частая ошибка продуктовых команд — воспринимать ИИ как молоток, которым можно забить любой гвоздь. Руководство PAIR задаёт предельно прямой вопрос в самом начале: «Действительно ли эта функция требует ИИ?»
ИИ обходится дорого как в разработке, так и в поддержке. Он хорошо справляется с персонализацией контента, прогнозированием событий и пониманием естественного языка. Но если задача состоит в том, чтобы автоматизировать то, что пользователи делают охотно сами, или если точность модели недостаточна для данного контекста, — от функции нужно отказаться. Эффект невозвратных затрат не должен вынуждать команду запускать слабый AI-продукт только потому, что инженеры уже построили модель.
Калибровка доверия, а не его насаждение
Команды страдают от «проклятия знания»: понимая, как работает модель машинного обучения, они предполагают, что пользователь сразу же ей доверится, — однако это предположение в большинстве случаев не подтверждается.
По мнению авторов PAIR, цель никогда не состоит в том, чтобы добиться от пользователя слепого доверия к системе. Цель — «калибровать» доверие, давая пользователю возможность понять, когда следует полагаться на ИИ, а когда — на собственное суждение.
В качестве примера в руководстве приводится гипотетическое приложение PlantPal. Если ботаник использует ИИ для определения обычного садового растения, базового объяснения при onboarding вполне достаточно. Но если турист пытается с помощью приложения выяснить, ядовито ли лесное растение, ставки принципиально меняются. В контексте высокого риска приложение должно предоставить объяснение прямо в момент принятия решения — точное описание того, как ИИ определяет токсичность, — чтобы пользователь мог проверить результат и не переоценить систему в потенциально опасной ситуации.
Авторы руководства разработали рабочий лист, который помогает продуктовым командам составить карту сценариев недоверия и сверхдоверия пользователей. На его основе проектируются UI-стратегии объяснений, адаптированные к уровню уверенности модели и возможным последствиям конкретного решения. Результат — готовые шаблоны сообщений и скрипты user research, позволяющие убедиться, что пользователи безопасно калибруют доверие к системе.
Проектирование с учётом сбоев
ИИ неизбежно будет ошибаться. Проблема не в самой ошибке, а в том, каков пользовательский опыт именно в этот момент.
Распространённый подход — скрывать логику ИИ за «магическим» интерфейсом и перекладывать ответственность на пользователя, когда результат оказывается неверным. Альтернатива, которую предлагает PAIR, — воспринимать интерфейс как инструмент совместной работы: проектировать progressive disclosure, при котором ИИ сообщает о своём уровне уверенности, и явно предусматривать fallback-сценарии на тот случай, когда система неизбежно даёт сбой.
«Контекстные ошибки»
Руководство PAIR выделяет тип сбоя, характерный именно для ИИ: «контекстная ошибка» (Context Error). Она возникает, когда система работает технически безупречно, но полностью неверно считывает человеческий контекст.
Пример из руководства — приложение для рекомендации фильмов. Алгоритм сработал идеально на основе демографических данных пользователя и предложил ему фильм. Однако пользователь уже видел этот фильм в кино и остался крайне недоволен. С его точки зрения — это не технический успех, а очевидная ошибка.
Решение — выстроить двунаправленные циклы обратной связи. Пользователю нужна возможность поставить рекомендации отрицательную оценку или скрыть её, что позволяет возвращать в систему «шумные», реальные данные и улучшать модель на живом пользовательском опыте.
Итог
Руководство PAIR предлагает три базовых принципа для команд, работающих с ИИ-продуктами.
Первый — оспаривать предпосылку: не создавать AI-функции только потому, что стейкхолдеры прочитали об этом в прессе, а сначала подтвердить реальную потребность пользователя.
Второй — калибровать доверие, а не насаждать его: встраивать трение в высокоставочные AI-решения и показывать, как работает система, чтобы пользователи могли доверять ей в нужных ситуациях и в правильной мере.
Третий — проектировать fallback: исходить из того, что ИИ даст сбой, и создавать интуитивные циклы обратной связи, позволяющие пользователям корректировать систему, когда она галлюцинирует или неверно интерпретирует контекст.