Карта: шесть групп понятий

Карта метро: сначала видишь линии целиком, потом едешь по станциям.

Все понятия курса делятся на шесть групп. Первая — про саму природу модели. Остальные пять — это пять ответов дизайна на неё: честные ожидания, показать работу, человек в контроле, мягкий сбой и петля обратной связи. Седьмая глава собирает всё вместе и добавляет итоговый принцип — Design for the Unhappy Path.

Как читать каждое понятие

Паспорт: одинаковые поля у всех, поэтому их легко сравнивать.

У каждого понятия дальше одно и то же: английское название (запомни его — это термин, по которому ищут статьи и гайды), образ из жизни, схема и карточка с полями: проблема, идея, пример, цена, когда брать и связи. Главное правило всего курса: модель будет ошибаться, и дизайн решает, чем это обернётся.

Fallible Component — модель уверена, даже когда неправа

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

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

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

Trust by Design — доверие строит дизайн, а не модель

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

Пользователи доверятся ИИ-фиче не потому, что она мощная. Они доверятся, потому что опыт вокруг неё даёт чувство безопасности: её можно проверить, поправить, отменить и знать, чего ждать. Это и есть доверие через дизайн (trust by design): модель даёт способность, дизайн даёт доверие.

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

Autonomy Calibration — подбери свободу под ставки

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

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

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

AI Disclosure — скажи, что это ИИ и он может ошибаться

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

Раскрытие ИИ (AI disclosure) — прямо сказать, что фича работает на ИИ и её результат может быть неточным. Это не извинение и не слабость, а калибровка. Пользователь, который знает, что видит ИИ-предложение, читает его правильно: полезно, стоит проверить, не истина в последней инстанции.

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

Draft Framing — подавай выводы как черновики

Штамп «черновик» на документе меняет то, как ты его читаешь: это отправная точка для улучшения, а не последнее слово.

Слова вокруг ответа определяют, насколько ему доверяют. Рамка черновика (draft framing) — подавать ИИ-результаты как черновики, предложения или отправные точки, а не готовые авторитетные ответы. Это приглашает пользователя критически читать и править — ровно та поза, что нужна к ошибающемуся инструменту.

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

Under-promise, Over-deliver — не перепродавай

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

Соблазнительно продавать ИИ-фичу как магию. Но перепродажа гарантирует разочарование: разрыв между обещанием и реальностью и становится опытом пользователя. Принцип under-promise, over-deliver — задать ожидания чуть ниже того, что модель умеет, и дать ей приятно удивить.

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

Citations — цитируй источники ответа

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

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

Это дизайн-отдача заземления (grounding): мало, чтобы ответ опирался на источник внутри системы — пользователь должен увидеть этот источник и пройти по нему.

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

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

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

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

Confidence Signals — показывай уверенность и рассуждение

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

Где можешь, выноси сигналы уверенности (confidence signals): уровень уверенности, шаги рассуждения, флаг, когда модель не уверена или опирается на слабые улики. Это помогает пользователю решить, насколько опираться на каждый ответ, вместо того чтобы считать все одинаково твёрдыми.

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

Suggest, Don't Act — предлагай, не действуй без спроса

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

Для всего значимого проектируй ИИ так, чтобы он предлагал, а не действовал (suggest, don't act): предложи правку, набросай сообщение, порекомендуй выбор — и дай человеку решить. Это держит человека в контуре (human-in-the-loop) на важных решениях: ошибка модели становится отвергнутым предложением, а не выполненной ошибкой.

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

Editable Output — дай редактировать, а не только «да/нет»

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

Лучшие ИИ-взаимодействия дают пользователю формировать результат, а не просто взять или выбросить. Это редактируемый вывод (editable output): ИИ-результаты легко править, дорабатывать и оставлять частично. Модель часто доводит тебя до 80%, и ценность — в том, чтобы человек доделал последние 20%, а не выкинул всё из-за одного изъяна.

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

Confirm & Undo — подтверждение перед необратимым

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

Ставь ясный шаг подтверждения (confirmation step) перед любым действием, которое нельзя отменить: отправить, заплатить, удалить, опубликовать. Это то же мышление о радиусе поражения (blast radius), что в безопасности, только в UX: ошибка модели должна максимум дать предложение, которое пользователь отклонит, и никогда — необратимое действие, совершённое самой моделью.

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

Abstention — дай ей сказать «я не знаю»

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

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

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

Low-confidence Routing — шаткий случай по другому пути

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

Не обращайся со всеми выводами одинаково, каким бы шатким ни был результат. Когда модель не уверена или опирается на слабые улики, нужен другой путь — это маршрутизация по уверенности (low-confidence routing): пометить, попросить подтверждения, отдать человеку или задать пользователю уточняющий вопрос.

Неуверенные случаи — ровно то место, где слепая автоматизация вредит больше всего. Они заслуживают своей обработки, а не отправки с той же уверенностью, что и твёрдые. Проектировать под шаткую середину, а не только под счастливый путь (happy path), — вот что делает фичу крепкой.

Graceful Degradation — деградируй, не рушься

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

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

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

Feedback Controls — дай лёгкий способ среагировать

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

Контролы обратной связи (feedback controls) — палец вверх/вниз, быстрая оценка, флаг — делают так, что сказать «хорошо» или «плохо» не стоит никаких усилий. Это даёт две вещи сразу: пользователь чувствует, что его слышат, а ты получаешь непрерывный поток реального сигнала о том, где фича работает и где сбоит.

Фича, которую нельзя оценить, — фича, по которой ты летишь вслепую. Простой контрол реакции — самая дешёвая и богатая обратная связь, что у тебя будет. Лови реакцию, которую пользователи и так готовы дать.

Corrections as Signal — пусть правки учат систему

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

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

Скармливай их в свои эвалы (evals) (см. курс про эвалы), чтобы фича измеримо улучшалась. Продукт становится лучше именно там, где спотыкаются реальные пользователи. Правка — и починка сейчас, и урок на потом.

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

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

Реакции и правки из реального использования — самый ценный источник эвал-кейсов, что у тебя есть. Это то, что пользователи на деле делают, включая сбои, которые ты бы не придумал. Разбирай эту обратную связь, находи, где фича ломается, и вплетай эти случаи в эвал-набор — так замыкается петля обратной связи (feedback loop): прод учит тебя, что чинить, ты чинишь, следующий релиз лучше.

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

Autonomy Calibration везде — слои защиты по ставкам

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

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

Хорошо спроектированный ИИ-продукт не равномерно автономен и не равномерно осторожен. Он откалиброван — кусок за куском — под то, сколько стоила бы ошибка именно там.

Design for the Unhappy Path — проектируй под неверный ответ

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

Признак зрелого дизайна ИИ-продукта — он построен вокруг того, что модель неправа, а не только права. Это принцип проектирования под несчастный путь (unhappy path). Демо показывает верный ответ; продукт переживает неверный. Поэтому ты проектируешь проверку, контроль, мягкий сбой, петлю обратной связи — машинерию, которая делает уверенную ошибку пойманной и исправимой.

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

Как всё связано

Оркестр: у каждой секции своя партия, но звучит одно произведение.

Всё начинается с Fallible Component: модель уверена, даже когда неправа. Пять групп практик — ожидания, показ работы, контроль, мягкий сбой, обратная связь — это пять ответов дизайна. Autonomy Calibration решает, сколько каждого ответа нужно в конкретном месте. Вместе они дают Trust by Design. А петля обратной связи через эвалы возвращается к модели и делает её лучше со временем.