Возрождение Метрики: Действие! Действие! Действие!

Фон

Видя потрясающий отклик на первые три статьи этой серии, мне пришлось выпустить четвертую часть.

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

• Часть 1. Метрики: проглотите красную таблетку
• Часть 2. Перезагрузка метрик: Oracle
• Часть 3. Революция метрик: масштабирование

В этой статье мы обсудим, как сделать эти показатели более действенными (используя последние достижения LLM), чтобы постоянно улучшать производительность. Цель будет заключаться в том, чтобы обсуждение было упрощенным и на достаточно высоком уровне для всех, кто работает в этой области.

Проблема

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

Операционные показатели регулярно отслеживаются из производственных журналов и могут использоваться для постановки целей в отношении OKR для всей команды.

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

Должен быть способ измерить ожидаемое влияние всех улучшений производительности непосредственно на показатели, сообщаемые пользователем. Это следует рассматривать как воздействие «Полярной звезды». Так в чем проблема?

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

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

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

Решение

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

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

LLM меняют правила игры

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

Важно отметить, что с увеличением количества токенов, которые могут обрабатывать LLM, много информации о конкретном продукте может быть предоставлено как часть самого «подсказки». В результате готовые API-интерфейсы LLM вместе с некоторыми оперативными разработками могут предоставить действенные показатели, сообщаемые пользователем.

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

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

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