Эта статья написана по результату проектирования информационной системы на базе ИИ для медицинских работников. Я не буду описывать интерфейсы системы, но хочу остановиться на отдельном ее элементе, который нередко оказывается за рамками внимания дизайнеров и начинающих разработчиков, потому что основная часть всего описываемого процесса находится вне интерфейса, и только некоторые небольшие фрагменты системы торчат на уровне пользователя.
Простой подход
При базовом подходе кажется, что выполнение запроса к системе выполняется в один шаг: пользователь пишет запрос, система его обрабатывает и отправляет ответ приемлемого качества. Это идеальная картина, которая иногда выполнима, но, когда мы проектируем системы профессионального уровня, нам нужно ориентироваться на более сложные пути.
Основная ошибка, связанная с простым подходом, в том, что мы идеализируем и пользователя, и систему, предполагая, что пользователь пишет вменяемые вопросы, а система всегда выдает вменяемые ответы, лишенные галлюцинаций. Такого рода допущения опасны, если мы хотим сделать систему, которая должна быть источником достоверной информации с высоким уровнем доверия. И как возможный выход из этой ситуации, пока у нас не появились суперумные ИИ, это усложнение пути, который проходит запрос, создавая при этом точки уточнений и проверок.
Цепочка уточнений
С каждым месяцем наши знания об ИИ меняются вместе со сменой моделей, но пока сохраняется уверенность в том, что от качества запроса зависит и качество ответа модели. Причем эта аксиома базируется на самом понимании того, как устроены современные ИИ-модели, и пока не произойдет фундаментальной смены алгоритмов, эта аксиома останется незыблемой.
Поэтому первым шагом в цепочке уточнений стоит добавить валидацию качества пользовательского запроса. Это важно для систем, которые сосредоточены вокруг определенной профессиональной темы, потому что область анализа меньше, и нюансы в постановке запроса могут быть более важными, чем при запросах на общие темы.
В принципе, с процессом проверки и уточнения запроса мы с вами сталкиваемся регулярно, может быть, только не обращаем на это внимание. Но если в поисковик вбить запрос с грамматической ошибкой, то он будет системой изменен. Это простой вариант корректировки запроса. В ситуации же с профессиональными системами нам нужно не просто корректировать запрос с грамматической точки зрения, но и давать возможность пользователю уточнить запрос с точки зрения содержания.
Контроль когнитивной нагрузки
Когда я проектирую интерфейсы, я все время себе напоминаю, что современные пользователи живут в очень перегруженном информацией мире и стараются избегать сложных вещей, которые будут их грузить еще сильнее. Поэтому, если у нас есть возможность облегчить немного жизнь пользователя, то нужно это делать. Снижая когнитивную нагрузку, мы не просто делаем систему более дружественной, но и повышаем качество процессов мышления и рассуждения, потому что у пользователя остается чуть больше ресурсов для принятия чуть более качественных решений. Для больших систем это «чуть» в итоге может складываться в часы, дни, недели высвобожденного в течение года рабочего времени пользователя.
Для информационной системы одним из факторов, который нагружает пользователя, является сам ответ ИИ. В профессиональной системе ответы могут быть длинными, и это нормально. Но не всякий ответ полезен, потому что, например, может уйти в смежную область. Поэтому для ответа ИИ мы вводим саммаризацию ответа, т.е. возможность вначале прочитать короткий ответ перед тем, как вчитываться в длинный.
Дополнительно, что тратит ресурс пользователя, — это время ожидания ответа. Можно, конечно, фантазировать, что в вашей системе ответ будет появляться моментально, но реальность другая. Чаще всего мы сталкиваемся с тем, что до получения ответа проходит заметное для пользователя время. И в течение этого времени хорошо бы пользователю показывать статус системы, чтобы он понимал, что работа идет, и демонстрировать артефакты прогресса. Обычно такими артефактами становятся короткие текстовые фразы, которые показывают, что система сейчас делает. И эти фразы-маркеры попросту успокаивают пользователя, и он перестает волноваться о процессе. Фактически этим мы следуем одной из UX-эвристик Якоба Нильсона — делаем статус системы очевидным.
По большому счету, с точки зрения интерфейса мы должны позаботиться о том, чтобы он все время сообщал, что происходит процесс, а сменой статуса показывал, что процесс не топчется на одном месте.
В упрощенном варианте разработчики добавляют простую анимацию загрузки, которая должна показывать, что что-то происходит. Но когда ваш RAG готовит ответ 43 секунды и потом еще происходит вторичная обработка ответа, то наблюдение простого лоадера может начинать беспокоить. У пользователей будут закрадываться подозрения, что что-то идет не так и все зависло. Несложная проработка интерфейса может нивелировать эту проблему.
Получить ответ недостаточно
В современных системах недостаточно получить ответ, хотя кажется, что на этом все должно заканчиваться. Но задача системы не только в том, чтобы дать ответ, но и помочь пользователю в процессе рассуждений и принятия решения. Поэтому для полного пути процесса получения ответа мы интегрировали два важных шага. Первое — это оценка качества ответа. А второе — это создание вопросов и уточнений для продолжения рассуждения.
Для оценки качества ответа у нас есть два инструмента: оценка качества со стороны пользователя и оценка уверенности системы в качестве ответа.
Оценка пользователя нам дает возможность исследовать большое разнообразие пользовательских кейсов. Это важно, потому что у нас никогда нет возможности придумать такое количество тестовых примеров, которые покроют все возможные варианты ответов системы. Собирая и анализируя обратную связь от пользователей, мы можем постепенно улучшать качество системы.
Оценка уверенности системы в своих ответах позволяет нам добавить уверенности для пользователя в том, что ответы, которые он получает, являются достоверными.
С оценкой уверенности есть тонкий момент, потому что ИИ иногда может нести полную чушь. При этом его слова всегда будут хорошо аргументированы и выстроены в виде убедительного ответа. Все эти факторы в дополнение к тому, что мы имеем дело с профессиональной информационной системой, создают очень высокие предпосылки того, что, если ИИ сгенерирует неверный ответ, то этот ответ будет принят за правду.
В такой ситуации нам самим надо сформулировать критерии оценки качества ответа и обеспечить возможность для этой оценки. Например, у меня одним из критериев является тот факт, что цитаты, которые использует ИИ в ответах, присутствуют в исходных документах и не были выдуманы в процессе ответа. Может показаться, что это мелочь, но именно за счет таких проверок можно обеспечить уверенность в качестве ответа.
Продолжение ветки запроса
Дав ответ пользователю, мы можем предоставить ему варианты продолжения обсуждения. Это могут быть варианты уточняющих вопросов или вариант переформулирования первоначального запроса на более узкую или более широкую область. А в ситуации, когда ответ получается очень широким или неоднозначным, может быть серия вопросов, подталкивающих к тому, чтобы дать уточняющую информацию для более фокусированного ответа.
Стратегия продолжения обсуждения многогранна, могут быть разные подходы, но моя идея заключается в том, что формулировки для продолжения обсуждения — это тоже часть качественного ответа. И пока в системе нет стратегии формулирования фраз или вопросов для продолжения обсуждения, до тех пор она неполная.
Взгляд на процесс обработки запроса
Я начал с того, что простой путь прохождения запроса, хоть и соблазнителен, но не подходит в ситуации, когда вы хотите создать хороший продукт.
Я не настаиваю, что все шаги, которые я описал, являются обязательными или достаточными. Особенности каждой системы могут требовать своего пути. Моей задачей было обратить ваше внимание на детали проектирования, связанные не с технической стороной реализации, а с логикой, потому что если есть продуманная логика, то все остальное — дело техники. А моя задача как UX-дизайнера как раз в том, чтобы предложить такой подход, который будет способствовать нахождению лучшего решения для разрабатываемой системы.
Здесь я почти ничего не говорил об интерфейсах, сосредоточился на процессах. Но и это является важной частью работы, которая ведет к созданию хороших продуктов. В конечном счете мы можем визуализировать только логику того, что понимаем. Надеюсь, эта короткая статья и описание подхода, который я использовал, помогут вам делать лучшие продукты.
Спасибо за внимание и подписывайтесь на мой телеграм-канал UX Point https://t.me/uxpoint
