Как проектировать интерфейсы для ИИ-фич: разбор вероятностного вывода

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

В чём сдвиг

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

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

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

Пять свойств и пять следствий

Каждое свойство заставляет принять конкретное решение. Если рекомендацию нельзя проследить до одного из этих пяти, это скорее вкусовщина.

Разрыв проверки

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

время_генерации + время_проверки < время_самостоятельной_работы

И отдельно — риск:

вероятность_ошибки × стоимость_незамеченной_ошибки < ценность_сэкономленного_времени

Оба неравенства должны выполняться. Первое объясняет, почему фича, которая выдаёт правдоподобный текст на 800 слов, может быть чистым убытком: внимательно прочитать и довериться дольше, чем написать 300 слов самому. Второе — почему та же модель, что триумф в редакторе кода, где компилятор и тесты проверяют бесплатно, становится обузой, когда генерирует сумму возврата клиенту: тут проверка — человек, читающий число, которое выглядит правильным.

Дизайн в основном атакует время_проверки. Цитаты-якоря, диффы вместо переписанного документа, структурированный вывод, который рендерится как форма, а не абзац, раскрытие уверенности — всё это существует, чтобы проверять было дешевле, а не чтобы модель стала лучше.

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

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

Обратимость — главная переменная дизайна

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

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

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

Четыре вопроса к уже зарелизенной фиче

Большинство команд приходят к этой теме, когда фича уже живая. Четыре вопроса по порядку, у каждого — конкретный фикс:

1. Куда попадает результат? Если он попадает не туда, где его можно отредактировать до того, как он начнёт действовать, это и есть баг. Переведите его в черновик.
2. Что пользователь делает для проверки? Если ответ — «читает и надеется», ваши затраты на проверку безграничны, и фича минимум для части пользователей стоит не на той стороне неравенства.
3. Что будет на p95 задержки? Не медиане. Откройте фичу, представьте сорок секунд тишины и посмотрите, что на экране.
4. Сколько стоит вторая попытка? В деньгах и в усилиях. Если перегенерировать — один клик, а повторно вводить контекст — двадцать, пользователи выберут дорогой вариант, потому что он у них перед глазами.

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