Экспресс-курс · No. 30

Большинство курсов про двигатель. Этот — про опыт, построенный поверх него, и про жёсткий факт в его центре: модель уверена, гладка и иногда неправа. Хороший дизайн ИИ-продукта не про то, чтобы это спрятать; он про то, чтобы под это спроектировать — задать честные ожидания, показать работу, держать человека в контроле и мягко сбоить. Доверие зарабатывает дизайн, а не модель.

Только суть · Один образ на идею · Доверие через дизайн

§ 01

Вся дисциплина начинается с принятия того, что модель есть: блестящая, полезная и ненадёжная определённым образом. Дизайн, что притворяется иначе, подставляет пользователей под ожог.

Модель уверена, даже когда неправа

Харизматичный эксперт, что даёт каждый ответ тем же самоуверенным тоном, — верные и выдуманные звучат ровно одинаково.

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

Доверие строит дизайн, а не модель

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

Пользователи не доверятся ИИ-фиче, потому что она мощна; они доверятся, потому что опыт вокруг неё даёт им чувствовать себя в безопасности — они могут её проверить, поправить, отменить и знать, чего ждать. Модель поставляет способность; дизайн поставляет доверие. Блестящая модель в небрежном интерфейсе ощущается недоверенной; скромная модель в продуманном ощущается надёжной. Доверие — это свойство продукта, что ты строишь, а не модели, что ты использовал.

Подбери дизайн под ставки

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

Сколько свободы ты даёшь ИИ, должно отслеживать, насколько дорого обошлась бы ошибка. Низкоставочный, легко обратимый вывод (предложенный тег, черновая фраза) может быть автоматичнее; высокоставочное, необратимое действие (отправить деньги, удалить данные, опубликовать) требует ревью и подтверждения. Самое важное решение дизайна — калибровать автономию под ставки, и взять это неверно, в любую сторону, — вот что делает ИИ-фичу либо безрассудной, либо бесполезно робкой.

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

§ 02

Огромная доля разочарования в ИИ — это на деле несовпавшие ожидания. Честно сказать пользователям, с чем они имеют дело, до того как обожгутся, — самое дешёвое доверие, что можно купить.

Скажи пользователям, что это ИИ и он может ошибаться

Прогноз погоды говорит «70% шанс дождя», а не «будет дождь», — назвать неопределённость заранее вот что заставляет людей доверять ему, даже когда он промахивается.

Будь прям, что фича на ИИ и её вывод может быть несовершенным. Это не извинение и не слабость — это калибровка. Пользователь, что знает, что получает ИИ-предложение, читает его уместно: полезное, стоит проверить, не евангелие. Прятать, что вывод сгенерирован ИИ, или намекать, что он авторитетен, подставляет людей переоценить его и потом почувствовать себя преданными, когда он неправ. Честное обрамление превращает неверный ответ из предательства в ожидаемое, управляемое событие.

Обрамляй выводы как черновики и предложения

Рукописный штамп «черновик» на документе меняет то, как ты его читаешь, — ты относишься к нему как к отправной точке для улучшения, а не как к финальному слову, что надо слушаться.

Слова и обрамление вокруг вывода формируют, насколько пользователи ему доверяют. Подавать ИИ-результаты как черновики, предложения или отправные точки — а не готовые, авторитетные ответы — приглашает пользователя вовлечься критически и редактировать, что ровно верная поза к ошибающемуся инструменту. «Вот черновик, что ты можешь отредактировать» производит лучшие исходы и меньше катастроф, чем «вот ответ». Обрамление делает тихую, постоянную работу, держа пользователя в правильном отношении с моделью.

Не перепродавай то, что она может

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

Соблазнительно продавать ИИ-фичу как магию, но перепродажа гарантирует разочарование — зазор между обещанием и реальностью становится опытом пользователя. Задай ожидания чуть ниже того, что модель может, а не выше, и дай ей приятно удивить. Быть честным о её пределах, даже заметно, строит куда более долговечное доверие, чем хайп, что первый же сбой разбивает. Недообещай и дай модели перевыполнить, а не наоборот.

Большинство разочарования в ИИ — несовпавшие ожидания. Скажи, что это ИИ и он может ошибаться, обрамляй выводы как черновики, а не вердикты, и недообещай — честное обрамление это самое дешёвое доверие.

§ 03

Ответ, что нельзя проверить, — это ответ, которому нельзя доверять. Дать пользователям увидеть, откуда взялся вывод, превращает заявление чёрного ящика в то, что они могут проверить, — а проверяемость это фундамент доверия.

Цитируй источники за ответом

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

Когда модель отвечает из извлечённой информации, показывай источники — линкуй документы, цитируй пассаж, указывай, откуда взялось утверждение. Цитаты дают пользователям проверить ответ вместо того, чтобы брать на веру, и они превращают модель из оракула, которому надо верить, в научного ассистента, что можно проверить. Это дизайн-отдача заземления: недостаточно, чтобы ответ был подкреплён источником внутри, пользователь должен мочь увидеть и пройти по источнику.

Сделай ответ проверяемым, а не просто правдоподобным

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

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

Показывай уверенность и рассуждение, где это помогает

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

Где можешь, выноси сигналы того, насколько надёжен вывод, — уровень уверенности, шаги рассуждения, флаг, когда модель не уверена или работает из тонких улик. Это помогает пользователям калибровать, насколько опираться на каждый ответ, вместо того чтобы относиться ко всем как к одинаково твёрдым. Идеально не будет, но даже грубая подсказка «эта шаткая» драматически улучшает то, насколько безопасно люди используют фичу. Дать пользователю сигнал надёжности, что тон модели прячет, — это один из самых ценных дизайнов, что можно сделать.

Ответ, что нельзя проверить, — это тот, которому нельзя доверять. Цитируй источники, делай выводы проверяемыми и выноси уверенность — проверяемость превращает неизбежные неверные ответы из скрытых рисков в ловимые.

§ 04

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

Предлагай и помогай, не действуй без спроса

Хороший ассистент пишет черновик письма и оставляет тебе его отправить — он не жмёт «отправить» сам и не говорит тебе после.

Для всего значимого проектируй ИИ предлагать, а не действовать: предложи правку, набросай сообщение, порекомендуй выбор — и дай человеку решить, принимать ли. Это держит человека в контуре на решениях, что важны, так что ошибка модели становится отвергнутым предложением, а не выполненной ошибкой. Чем больше действие важно или необратимо, тем твёрже модель должна предлагать, а человек располагать. Помощь, что пользователь командует, безопаснее автономии, что пользователь лишь надзирает.

Дай пользователям редактировать, а не только принять или отвергнуть

Хороший шаблон даёт тебе менять части, что не подходят, вместо того чтобы навязывать выбор «всё или ничего» между идеальным и бесполезным.

Лучшие ИИ-взаимодействия дают пользователю формировать вывод, а не просто взять или оставить. Делай ИИ-результаты лёгкими редактировать, дорабатывать и частично оставлять — потому что модель часто доводит тебя на 80%, и ценность в том, чтобы дать человеку доделать последние 20%, а не выбросить всё из-за одного изъяна. Относиться к выводу как к редактируемой глине, а не готовому вердикту, совпадает с тем, как модель на деле работает: сильный черновик, что человек улучшает. Редактируемость превращает «почти верно» из сбоя в фору.

Подтверждай перед всем необратимым

Банк требует второго подтверждения для крупного перевода — намеренная пауза перед тем, что нельзя забрать назад.

Ставь ясный шаг подтверждения перед любым действием, что пользователь не может отменить, — отправить, заплатить, удалить, опубликовать, что угодно необратимое. Это то же мышление о радиусе взрыва, что в безопасности, выраженное в UX: ошибка модели должна максимум произвести предложение, что пользователь отклоняет, никогда необратимое действие, совершённое самой. И сочетай это с отменой, где можешь, чтобы даже принятые действия оставались восстановимыми. Возможность шагнуть назад вот что даёт пользователям действовать на ИИ уверенно, а не боязливо.

Держи человека главным: модель предлагает, человек решает; выводы редактируемы, а не «бери или оставь»; и всё необратимое требует подтверждения и, в идеале, отмены.

§ 05

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

Дай ей сказать «я не знаю»

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

Проектируй опыт так, чтобы позволять — и предпочитать — честное «я не знаю» или «я не уверен» над выдуманным ответом. Самый опасный сбой ИИ — уверенно изобрести ответ, когда у него нет основания, и продукт, что делает отказ валидным, мягким исходом, куда безопаснее того, что давит на модель всегда что-то произвести. Выносить неопределённость вместо того, чтобы её замазать, — не сбой фичи, а фича, работающая честно. Модель, что знает свои пределы, и дизайн, что их уважает, зарабатывают больше доверия, чем та, что всегда отвечает.

Обрабатывай случай низкой уверенности иначе

Спам-фильтр, что уверен, маршрутизирует сообщение автоматически, но тот, что не уверен, помечает его тебе на проверку, — неуверенный случай обрабатывается, а не прячется.

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

Деградируй, не рушься

Когда GPS теряет сигнал, он показывает твою последнюю известную позицию и говорит «ищу», вместо того чтобы погаснуть или отправить тебя с обрыва, — он сбоит мягко.

Когда ИИ не может выполнить — ошибка, простой, запрос вне области, — опыт должен деградировать мягко, а не ломаться или, хуже, производить мусор. Откатись к более простому варианту, ясному сообщению, ручному пути, кэшированному результату. Фича, что сбоит в разумное, честное состояние, держит доверие пользователя; та, что сбоит в уверенный неверный ответ или сломанный экран, его разрушает. Планируй режимы сбоя так же намеренно, как путь успеха, потому что с ошибающимся компонентом сбой — часть нормальной работы.

Сбой — не краевой случай для ошибающейся модели, а норма. Дай ей сказать «я не знаю», обрабатывай случаи низкой уверенности иначе и деградируй в честный откат вместо уверенного мусора.

§ 06

Хороший ИИ-продукт не просто выдаёт выводы — он учится из того, как пользователи на них реагируют. Поймать этот сигнал превращает каждое взаимодействие в шанс улучшиться и даёт пользователям способ быть услышанными.

Дай пользователям лёгкий способ среагировать

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

Сделай беструдным для пользователей сигналить, был вывод хорош или плох, — палец вверх/вниз, быстрая оценка, флаг. Это делает две вещи разом: даёт пользователю чувство агентности и того, что услышан, и даёт тебе непрерывный поток реального сигнала о том, где фича работает и сбоит. Фича, что нельзя оценить, — это фича, по которой ты летишь вслепую; простой контрол реакции — самая дешёвая, богатая обратная связь, что ты получишь. Лови реакцию, что пользователи дали бы так и так.

Дай правкам учить систему

Когда ты исправляешь адрес, что предложила клавиатура телефона, она учится — правка не только на этот раз, она улучшает следующий.

Богатейшая обратная связь — пользователь, чинящий вывод. Когда кто-то редактирует ИИ-предложение, эта правка — точный сигнал того, как выглядело «верно», — лови его. Правки и отказы — золото: они говорят тебе ровно, где модель не дотянула, на реальных случаях. Скармливай их назад в свои эвалы (курс об эвалах), чтобы фича измеримо улучшалась, и продукт становится лучше по контурам того, где реальные пользователи на деле спотыкаются. Правка — это и починка на сейчас, и урок на потом.

Продовая обратная связь — твой лучший эвал-набор

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

Реакции и правки, текущие из реального использования, — самый ценный источник эвал-случаев, что у тебя есть: это то, что твои пользователи на деле делают, включая сбои, что ты бы и не выдумал. Майнить эту обратную связь, чтобы найти, где фича ломается, и вплетать те случаи в эвал-набор замыкает петлю: прод учит тебя, что чинить, ты чинишь, и следующий релиз лучше. Продукт с этой работающей петлёй улучшается непрерывно; без неё — гадает. Петля обратной связи вот что заставляет ИИ-фичу становиться лучше, а не просто существовать.

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

§ 07

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

Калибруй автономию под ставки, везде

Ты даёшь ассистенту подшить бумаги самому, набросать важное письмо на твоё ревью и никогда не подписать контракт без тебя, — автономия, масштабированная под последствие.

Объединяющее решение, принимаемое снова и снова через продукт, — сколько давать ИИ делать самому против того, сколько маршрутизировать через человека, — и ответ всегда: масштабируй под ставки. Низкорисковые, обратимые вещи могут быть автоматичнее; высокорисковые, необратимые получают ожидания, проверку, контроль и подтверждение слоями. Хорошо спроектированный ИИ-продукт не равномерно автономен и не равномерно осторожен; он откалиброван, кусок за куском, под то, сколько ошибка там стоила бы.

Проектируй под неверный ответ, а не только верный

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

Признак зрелого дизайна ИИ-продукта в том, что он построен вокруг того, что модель неправа, а не только права. Демо показывает верный ответ; продукт переживает неверный. Так что ты проектируешь проверку, контроль, мягкий сбой, петлю обратной связи — машинерию, что делает уверенную ошибку ловимой и восстановимой. Заставь работать счастливый путь, и у тебя демо; спроектируй под несчастный путь, и у тебя продукт, которому люди реально могут доверить настоящую работу.

Прежде чем выкатывать ИИ-фичу
  • Подобрана ли автономия под ставки — автоматичнее, где обратимо, контролируемее, где нет? - Честны ли ожидания — сказано, что это ИИ, выводы обрамлены как черновики, не перепроданы? - Может ли пользователь проверить — источники цитированы, ответы проверяемы, уверенность вынесена, где помогает? - Человек ли в контроле — предлагать, не действовать, редактируемый вывод, подтверждение перед необратимым, отмена? - Сбоит ли мягко — способна сказать «я не знаю», низкая уверенность обработана, деградирует, а не рушится? - Замкнута ли петля обратной связи — легко среагировать, правки пойманы, скормлены назад в эвалы?
Слова, которыми ты теперь владеешь
  • ошибающийся компонент — модель уверена, даже когда неправа; дизайн должен это учесть. - калибровка автономии под ставки — больше свободы, где ошибка дёшева, больше контроля, где дорога. - честные ожидания / черновики, не вердикты — обрамление, что держит пользователей в верном отношении с моделью. - проверяемость / цитаты — дать пользователям проверить ответ вместо слепого доверия. - человек в контуре (human-in-the-loop) — предложить, отредактировать, подтвердить, отменить — человек остаётся главным. - мягкий сбой — признать «я не знаю» и деградировать вместо выдумки. - петля обратной связи — ловить реакции и правки, чтобы улучшать фичу со временем.
Признаки, что ты проектируешь ИИ хорошо
  • Опыт зарабатывает доверие через проверяемость и контроль, а не только мощь модели. - Пользователям сказано честно, что это, а выводы обрамлены как черновики на проверку. - Человек остаётся в контроле — редактируя, подтверждая и способный отменить. - Оно сбоит мягко, признавая неопределённость вместо уверенной выдумки. - Реальная обратная связь течёт назад в эвалы, так что фича улучшается с использованием.

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

Конец экспресс-курса · 7 глав · доверие через дизайн

Дальше — практика: возьми ИИ-фичу и пройди её со стороны пользователя, предположив, что модель неправа в этот раз, — может ли он сказать, что это ИИ, проверить ответ, отредактировать его, отменить и сообщить о промахе? Везде, где ответ «нет», — это разрыв дизайна, а не модели. Чини опыт, а не только промпт. Дисциплина щёлкает в тот миг, как осознаёшь, что доверие идёт от продукта, а не от модели. Но держи одну мысль выше прочих: модель будет уверенно неправа, и твой дизайн решает, приземлится ли это как пойманное, восстановимое предложение или как катастрофа, поданная как факт. Проектируй под неверный ответ, и верные позаботятся о себе сами.