Привет, Хабр! Меня зовут Дмитрий Браженко. Разработка продуктов и сервисов регулярно сталкивает нас с необходимостью выбрать лучший вариант: какая иконка красивее? Какая кнопка удобнее? Краудсорсинг – отличный способ учесть мнение потенциальных пользователей, проведя несложные UX-тесты.
Делюсь готовым решением – пайплайном для ранжирования данных. Код на гитхабе прилагается! Под катом расскажу, как запустить, на что обратить внимание, покажу несколько примеров использования.
Выбрать метод ранжирования
Существует три основных подхода к обучению и оцениванию моделей ранжирования:
- поточечный (pointwise): на вход для сравнения подаются пары «запрос-документ», каждой из которых соответствует оценка краудсорсеров. Качество модели = точность оценки, полученной для пары «запрос-документ»;
- попарный (pairwise): документы, соответствующие одному запросу, сравниваются между собой парами. Задача ранжирования – уменьшать число инверсий для пар документов, т.е. чтобы то, что было оценено хуже, не оказывалось в топе ранжирования;
- списочный (listwise): асессор составляет список – «идеальную выдачу» – сравнение идёт с ней.
Подробнее про подходы к ранжированию можно прочитать, например, в презентации или в статье. Для пайплайна выбрал самый популярный – попарные сравнения. Всё-таки ответить на вопрос «Что хочется больше: яблоко или апельсин?» респондентам оказывается проще, чем оценить по шкале от 1 до 10, насколько хочется именно яблоко.
Подготовить шаблон к работе с данными
Перед тем как приступить к запуску пайплайна, понадобится:
- Зарегистрироваться в Толоке как заказчик.
- Получить OAuth-токен по ссылке (подробнее – в документации).
- Выбрать способ хранения файлов, задействованных в задании.
На последнем пункте на всякий случай остановлюсь поподробнее:
- Если планируете размечать большой объём данных, удобно использовать произвольное постоянное S3-хранилище файлов. Например, Yandex.Cloud.Object.Storage.
- Подойдёт и любое другое хранилище, которое позволяет получить URL на картинку (графический объект) вида https://sbs.s3.yandex.net/39a307e3f4859c96f37161b3ab00aa5daa99858fbd6df1b70f53fa9a649ea467.png
Полный флоу расчётов с пояснениями – на гитхабе. Весь приведённый код должен воспроизвестись, если указать свой токен заказчика (тем не менее, что-то может устареть и потребовать доработок). В статье я постараюсь сосредоточиться на содержательной стороне вопроса.
Ранжировать объекты
Что бы вы ни сравнивали – поисковые выдачи, интерфейсные решения, иконки, картинки и даже видео – суть метода не меняется: для наглядности покажу, как он работает, на конкретном примере.
Часто встречающаяся задача – выбрать вариант дизайна чего-либо. В таком случае есть хотя бы два варианта: новый и старый. Чтобы выбрать самый удачный, можно провести опрос, какой вариант лучше и почему. Вот так мы выбирали карточку для приложения Яндекса:
Чтобы взаимное расположение картинок не влияло на выбор, половине опрашиваемых покажем их в порядке (A|B), другой – (B|A).
После запуска эксперимента получим результаты в полусыром виде. В моём коде прописано как оформить их в виде таблички:
Группа людей | Число проголосовавших “лево” | Число проголосовавших “право” |
---|---|---|
Слева красная кнопка (A|B) | 18 | 8 |
Слева белая кнопка (B|A) | 7 | 17 |
Выполним несложные математические преобразования, чтобы понять, за какой цвет кнопки именно проголосовало больше людей.
Число выбравших красную кнопку: 18 + 17 = 35
Число выбравших белую кнопку: 7 + 8 = 15
Теперь представим результаты красивой табличкой, заодно подтянем примеры комментариев, которые оставляли наши респонденты (тоже есть в коде):
Красная кнопка | Белая кнопка | |
---|---|---|
Результат (pvalue=0.007) | 70% (35/50) | 30% (15/50) |
Примеры комментариев под каждым из вариантов | На красном фоне белыми буквами более заметно и больше обращает на себя внимание чем красными буквами на белом фоне у объявления. | красный цвет забирает на себя все внимание а белый нет |
На что стоит обратить внимание:
- Для оценки статистической значимости результатов подойдёт классический биномиальный тест. Сравниваем две картинки: если они одинаковые, score каждой из них будет близок к 0.5 (смутило слово «score»? – не переживайте, в следующем разделе покажу, как его считать). Если картинки разные, мы должны с помощью статистического теста проверить, не случайный ли у нас у результат.
- Ещё раз напомню: одной половине респондентов выдаём картинки в виде (A|B), другой – (B|A).
- Не следует использовать такой подход как «серебряную пулю» и принимать решения исходя исключительно из полученных цифр. Причиной выбора может являться не сделанное изменение, а, например, дефект одного из макетов.
- «Garbage in – garbage out»: не стоит сравнивать заведомо плохие варианты, которые вы не стали бы отправлять в продакшн.
Ещё больше о том, как корректно поставить эксперименты Side-By-Side – на видео с Я.Субботника: подводные камни, границы применимости методики.
Теперь пример посложнее: увеличим количество ранжируемых объектов. Допустим, требуется отсортировать несколько картинок и выбрать лучшие из них для галереи фонов.
Вернёмся к идее pairwise подхода: проведём попарное сравнение картинок. Получится 6 ? 5/2 сравнений. Каждой картинке присвоим простую метрику:
где – число раз, когда картинка победила соперника, – проиграла ему. Интерпретировать полученный score можно как "вероятность выигрыша против случайно взятого соперника из набора".
Дальше можно сортировать картинки по этому скору. В моем случае получилась такая сортировка:
Совпало с вашим ожиданием?
На что стоит обратить внимание:
- Если вариантов очень много, то сравнивать каждый с каждым будет дороговато, можно попробовать придумать «опорные точки».
- В качестве сортировки можно использовать более умные скоры, например ELO-score.
Другие задачи, с которыми справится этот пайплайн
Используя Яндекс.Толоку, можно проводить куда более сложные тесты, чем парные сравнения картинок.
Таргетирование
Иногда для качественного ранжирования данных бывает важно учесть какие-то дополнительные факторы, влияющие на предпочтения – возрастные, социальные, территориальные. Попробуем запусить вот такой эксперимент сначала для респондентов из Москвы, а потом – из Санкт-Петербурга. Оформление одинаковое, отличаются только названия продукта:
Готовим два пула, проверяем в интерфейсе, что в настройках не случилось ошибок, запускаем.
Результаты предсказуемы:
- в Москве предпочтительнее «шаурма»: её выбрали 78% респондентов;
- в Санкт-Петербурге, хотя отрыв и меньше, лидирует «шаверма»: 54% против 46%.
Парные сравнения видео
Сравнивать можно не только картинки, но и видео. Например, чтобы понять, что люди думают про ваш рекламный ролик. Или просто собрать фидбек.
Есть два видео об Алисе:
Видео 1 (Алиса-Мечта) | Видео 2 (Алиса-Планка) |
---|---|
Какое видео вам понравилось больше? Почему?
Видео 1 (Алиса-Мечта) |
Видео 2 (Алиса-Планка) |
|
---|---|---|
score | 72% | 28% |
Пример комментария за каждый вариант | Ребёнок вызывает больше приятных эмоций, чем слабак из 2-го варианта, который отжаться не может. В варианте 1 показана возможная практическая польза от алисы для развития ребёнка | Более позитивный, в первом ребенок как мне кажется, не понял шутки |
Более сложные тесты
Как видите, всё ограничивается только вашей фантазией, нужно лишь подправить шаблон в Толоке: опросники по картинке, 5-секундный UX-тест (подробнее – тут), тест на 1-й клик, Card Sorting – продолжить вдохновляться можно здесь.
Для таких тестов часто бывает полезно сделать скринкаст – запись того, как пользователь взаимодействовал со страницей. В этом нам поможет инструмент, входящий в Яндекс.Метрику, а именно Вебвизор. Его можно встроить в шаблон и смотреть, как пользователи работают с заданием. Для наглядности приведу видео:
Чтобы сделать вебвизорную запись, замените в коде с Гитхаба мой счётчик Яндекс.Метрики на ваш.
Вместо заключения
Спасибо, что дочитали до конца! Собрал основные тезисы и ссылки:
- Многие дизайны Яндекса проходят подобное тестирование. У нас существует автоматический пайплайн, который получает картинки, загружает их в Толоку, ждёт оценок и считает метрики.
- Толока – гибкий инструмент для выполнения краудсорсных задач – область применения ограничена только вашей фантазией. Вот тут рассказывали как обучать беспилотники и оценивать качество сервисов. А здесь коллеги из ODS создают датасет для распознавания счётчиков.
- Если у вас есть регулярный процесс с необходимостью «механической», монотонной работы, его несложно автоматизировать через API Толоки.
- Конфигурация и настройка заданий могут вызывать трудности – в тексте постарался подсказать, на что стоит обратить внимание. Для сбора результатов достаточно небольшого упорства и знания азов HTML/CSS/Js.
- Используйте код на Github. Можете контрибьютить – сделаем библиотеку шаблонов для Толоки.
- Есть продукты, которые тестировать в Толоке всё же не стоит: что-то нестандартное, не подразумевающее массового использования – неспециалистам будет очень сложно дать качественный фидбек, например, об утилите для управления космическим кораблём.
kucev
Дмитрий, спасибо вам большое за очень интересную статью!
Прочитал от корки до корки несколько раз)
После прочтения у меня возникло несколько вопросов. Буду рад, если вы их прокомментируете)
1. Почему вы используете биномиальный тест для проверки статистической значимости? Ведь биномиальный тест предполагает использование Z-критерия. А он применим, когда мы точно знаем распределение для генеральной совокупности (нормальное или гауссово). На сколько я понял, распределение генеральной совокупности нам неизвестно.
2. Как перед тестом вы определяете необходимый размер выборки людей, чтобы результаты теста получились статзначимыми?
3. Отбираете ли вы исполнителей для выполнения задания? Если да, то в каком формате они проходят обучение и экзамен? Как вы высчитываете навык исполнителей на проекте?)
4. Какими способами вы контролируете качество в проекте? Ведь в таком типе заданий нет 100% правильно ответа, поэтому контроль “мнением большинства” и многие другие методы контроля качества не работают.
5. Применяете ли вы модель Bradley-Terry для агрегации полученных оценок?
dmitry_brazhenko Автор
Роман, привет!
Спасибо за вопросы, постараюсь ответить на них :)
1. Применяется вот этот тест. У нас биномиальная случайная величина {0 – выбор варианта 0; 1 – выбор варианта 1}. Есть N наблюдений за этой случайной величиной. Далее мы вычисляем среднее полученного ряда. Средняя асимптотически распределена нормально (спасибо ЦПТ). Нас интересует отклонение средней от 0.5 (подбрасывания монетки). Поэтому мы и сравниваем получившееся среднее с 0.5.
2. Размер выборки зависит от задачи. В каком-то смысле, он просто принят. Если есть только пара объектов и нужно сравнить их – можно набрать больше выборку (например, 500 человек). Если задача проранжровать объекты (как у меня пример с фотографиями), то здесь будет накладно брать много людей, да и ни к чему, потому что интересуют не парные сравнение (каждого объекта с каждым), а общее упорядочивание. Цели <получить статзначимый результат> обычно нет. Если такой эксперимент не прокрасился, надо запускать следующий, а не прокрасить его увеличением выборки.
3-4. Задача отбора и контроля качества скорее творческая, чем методологическая. Для примеров, которые упомянуты в моем рассказе, я запускал только с использованием встроенных механизмов Толоки: соотношения скорости/качества и других инструментов. Однако если речь идет о больших больших объемах сбора данных, то, надо придумывать что-то хитрее и держать в секрете :)
5. Для тестов, которые я описал в статье, я пробовал использовать модель Bradley Terry, но явных причин ее использовать, я не увидел.
kucev
Дмитрий, спасибо большое за ответы!)