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

Чат часто оказывается наиболее привычным способом взаимодействия пользователя с ИИ-системой. Пользователь вводит запрос, нажимает Enter, ждет ответа и затем интерпретирует его. Такой подход отлично подходит для задач с открытым концом, так как диалог дает пользователю возможность уточнять запрос по мере появления новой информации.

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

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

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

В этой статье мы рассмотрим встроенный ИИ и контекстную помощь, а также то, как ИИ может автоматизировать части рабочего процесса. Мы также затронем адаптивные интерфейсы и сценарии, в которых ИИ остается преимущественно вне поля зрения.

Где уместен чат

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

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

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

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

Интеграция ИИ в рабочий процесс

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

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

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

Компоненты Progress Telerik и Kendo UI AI отражают этот широкий спектр возможных вариантов интерфейса. Например, такой компонент, как React Inline AI Prompt, может разместить подсказку прямо рядом с содержимым, которое редактирует пользователь, а кнопка React SmartPaste способна превратить неструктурированный текст из буфера обмена в поля существующей формы. Ни один из этих сценариев не требует отдельного диалога для достижения пользы.

От ответов к прогрессу в работе

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

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

Адаптивные интерфейсы

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

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

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

Когда ИИ может оставаться в тени

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

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

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

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

Создание решений за пределами панели чата

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

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

В упрощенном TypeScript бэкенд может рассматривать ответ модели как предлагаемое изменение, а не как состояние приложения:

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

Автоматизация рабочего процесса добавляет еще один уровень, поскольку бэкенд должен отвечать за выполнение и восстановление. Модель может порекомендовать операцию или выбрать из разрешенных инструментов, но код приложения по-прежнему проверяет разрешения и валидирует запрос. Он также записывает результат и определяет, когда требуется одобрение человека. Упрощенная граница выполнения может выглядеть примерно так:

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

Совместное проектирование интерфейса и бэкенда предотвращает превращение ИИ в изолированную функцию. Это позволяет использовать контекст приложения, сохраняя при этом элементы управления, которые уже регулируют рабочий процесс.

Выбор подходящей поверхности для ИИ

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

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

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

Заключение

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

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

Например, библиотека Progress KendoReact предоставляет несколько способов создания таких интерфейсов без перехода по умолчанию к панели чата. Inline AI Prompt и SmartPasteButton привносят помощь в рабочие процессы с контентом и формами. Семантический поиск Data Grid и подсветка на базе ИИ распространяют ту же идею на интерфейсы с интенсивным использованием данных.

Дополнительные сведения о создании приложений и интерфейсов на базе ИИ с помощью Progress см. в следующих ресурсах: