company_banner

Как мы с помощью математической статистики измеряем качество данных в Яндекс.Городе

    Летят в самолете Петька и
    Василий Иванович, Василий Иванович кричит:
    — Петька, приборы!
    Петька отвечает:
    — Двести!
    Василий Иванович:
    — А что «двести»?
    Петька:
    — А что «приборы»?

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

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

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


    У сервиса поиска мест на Яндексе многолетняя история, и к его созданию приложили руку несколько команд. Растёт он из проекта adresa.yandex.ru. Потом Яндекс интегрировал в него бизнес «Жёлтых страниц» — так появился Справочник. Около года назад очень сильно обновилась команда сервиса. И он начал превращаться в Яндекс.Город. Я в этой команде руковожу службой производства данных и сегодня расскажу вам о том, какие у нас метрики и как они помогают нам делать лучшую базу организаций в России.


    Как мы выбирали метрики


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

    Одним из наших базовых показателей стало количество известных сервису организаций (POI). Но при ближайшем рассмотрении эта метрика оказалась довольно бессмысленной. Она безусловно удобна и полезна для оперативного управления, потому что её легко считать и она всем понятна. Но мы делаем продукт для пользователей, а их счастье в ней никак не отражалось.

    Посудите сами, стало ли пользователю лучше от того, что мы знали 50К организаций, а стали знать 60К организаций? Возможно. А если мы все равно не знаем ближайшей к его дому круглосуточной аптеки или ближайшего банкомата нужного банка?

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



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

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

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

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

    • Упомянутое выше количество организаций – как абсолютное, так и в сравнении с основными конкурентами (в том числе по отдельным категориям).
    • Число/доля нерелевантных ответов, которые были вызваны из-за того, что организации не было в базе данных. Удобная метрика, но сложная для измерения, особенно в масштабе нашей страны.
    • Точность – доля организаций с правильными данными среди всех доступных в системе организаций.
    • Полнота – доля известных Яндексу организаций среди всех организаций в реальном мире.

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

    Как мы считали метрики


    Вроде бы жизнь наладилась: мы определили метрики, регулярно измеряли их, продумывали мероприятия по их улучшению. Живи и радуйся. Внутри компании крайне охотно стали обсуждать метрики в терминах «точность должна быть не ниже Х» или «полнота должна быть не ниже Y». Всем казалось понятным, что такое точность – и она, конечно, должна быть как можно выше. Не очень интересно, что же мы считаем организацией, что мы считаем ошибкой, влияющей на точность, и так далее.

    Но когда мы проанализировали, как на самом деле мы измеряем точность, то оказалось, что разные стороны часто понимают под этим немного разное. И удалось бы сэкономить многие часы, потраченные на оживленные совещания, если бы сразу стало понятно – мы говорим на разных языках и потому не можем договориться. Наши данные используются разными сервисами Яндекса, и каждый сервис предъявляет свои требования к точности. Но удивительная история: при этом они просто требуют «данные с точностью не ниже X». Большим сюрпризом для всех оказалось то, что точность все понимают сильно по-разному.

    В результате мы описали несколько метрик точности, последовательно усиливающих одна другую.



    Благодаря этому мы увидели, что если по базовой метрике, использовавшейся с самого начала, наша точность действительно высока (выше 90%), то по остальным она может достигать 50-60%. И именно вложенность метрик друг в друга позволяет последовательно работать над качеством базы, переходя от одной метрики к другой.

    Естественно, все подобные измерения происходят на случайных выборках организаций, и это влечет за собой еще одну коварную ошибку. Часто люди забывают, что у любой косвенной метрики есть погрешность. То есть, если полгода назад точность по замерам была 62%, а сейчас после выполнения какого-то проекта стала 63%, то это еще ни о чем не говорит, рано бить в барабаны. Подобное цитирование статистических данных вообще непрофессионально, если одновременно не указывается погрешность.

    Вторая ошибка при работе с подобными метриками – использование каких-то балльных метрик. Например, в зависимости от значимости ошибки ставить «оценку» от 1 до 5. Получить приемлемую погрешность оценки при вменяемых затратах на измерение можно только в случае бинарной метрики – то есть данные о конкретной организации либо точные, либо нет.

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

    Предположим, что у нас в базе N=40 000 организаций. Нас интересует размер выборки n, которую необходимо разметить, чтобы на ее основе сделать достоверное заключение о точности всей базы. Отметим, что на основе выборочной разметки можно будет сделать лишь вывод следующего вида:

    «Реальная точность базы отклоняется от некоторого числа p не более чем на δ с вероятностью не менее P».

    Итак, у нас есть три величины: n – размер выборки, δ – погрешность оценки, P – вероятность данной оценки. Само собой, мы хотим минимизировать наши затраты на разметку n организаций, минимизировать погрешность оценки δ и максимизировать вероятность P, с которой мы сможем утверждать, что результаты, полученные на основе выборки, применимы и ко всей базе в целом. Но, как в известной шутке «Быстро, качественно, недорого — выбирайте любые два пункта», нам необходимо чем-то пожертвовать. Вероятностью P мы сильно жертвовать не будем, иначе полученная оценка будет лишь с малой вероятностью отражать реальное состояние дел, а зачем же тогда проводился замер? Договоримся на вероятности P=95% и допустимой погрешности δ=5%. А размер минимальной выборки теперь не составит труда вычислить. И что не может не радовать, можно заведомо утверждать, что достаточно будет разметить выборку всего лишь из 384 организаций!

    Предположим, что мы оценили выборку размера n=384 организаций, и из них m=290 организаций оказались верными. Тогда имеем следующую оценку: . А погрешность оценки есть δ%. Итого, мы можем сказать, что наша точность составляет 75.5 ± 4.3%. Если же у нас вдруг появятся требования по снижению погрешности, нам достаточно будет дополнительно разметить еще некоторое случайное число организаций, количество которых вычисляется на основе предъявленных требований к погрешности.



    Как уже отмечалось, получив при следующем измерении, например, 72.2 ± 4.5%, мы не сможем сказать ничего определенного о том, выросла или упала наша точность.

    Теперь перейдем к другой определяющей метрике каждого справочника – метрике полноты. Полнотой называется доля организаций реального мира, представленных в справочнике. Так, если в городе Х расположено 10000 интересующих вас организаций, а вам известно только 6000 из них, то ваша полнота равняется 60%.

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

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



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

    Выводы


    Помимо технических вещей, хочется выделить те менеджерские уроки, которые я вынес за время работы в Яндекс.Городе.

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

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

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

    Comments 36

      –10
      Поздравляю с изобретением Foursquare!
        +5
        На самом деле, весь пост — про то, почему это не Foursquare, чем отличается, и почему модель 4sq применима не ко всему (например, там мало шансов найти что-то про непопулярное место в провинции, не говоря уж о его времени работы).
          +4
          Но по факту все ровно наоборот — в моем городе в 4sq вполне релевантная база мест, а в Я.Город пара кабаков всего.
            +1
            Удваиваю это, по Киеву закономерность соблюдается.
              0
              В Киеве, как и в Украине в целом мы пока еще не запустились, полнота и качество данных там пока что не готовы к полноценному запуску и использованию. Поэтому Город пока что недоступен в украинских сторах, не хочется преждевременно сложить у украинских пользователей превратное ощущение от сервиса.
          +22
          Скорее 2GIS. С его «Где поесть» и т.д.
            +5
            Сегодня в 2GIS, наверное, был аврал. :)
          +5
          Жаль, что опять тотальное игнорирования Android дизайна. Дизайн с iOS опять натянули на другую платформу, наплевав, что пользоваться не привычны и банально не удобно.
            +1
            Вы правы, что по идее дизайн должен быть нативным для каждой платформы. Хотя по нашим тестам простые пользователи не испытывают дискомфорта и от не нативного. Но мы все равно постепенно сделаем андроидную версию более андроидной. Начнём уже с ближайших релизов.
              0
              А вот этот момент очень интересен. Может после редизайна напишете статью с цифрами, влияет ли «нативный» дизайн на комфорт пользователей. Сколько пользователей проводят времени в приложении и т.д. в iOSном дизайне и в андроидном.
              Мне кажется, было бы очень интересно такое сравнение.
                0
                Спасибо за идею! Поговорим с дизайнерами. Может, напишем.
              +2
              А что, в Андроиде есть дизайн? Не замечал.
              habrahabr.ru/post/178713/
                0
                Хорошо, скажем по-другому. В андроиде есть гайды с описанием типовых элементов и их поведением. Есть описанные правила навигации и размещения некоторых стандартных элементов на экране. Если говорить про графическую часть дизайна, то она мне очень нравится, но использование контроллов из ios мне доставляет неудобство, причем не только эстетическое.
              +5
              Плохо, что работает только по Москве. Сижу в Вологде, а любой запрос выдаёт места исключительно Московские.
                0
                Сейчас в ряде регионов действительно есть такая неприятность, воспроизводится только при первом запуске приложения. При перезапуске поиск будет происходить с привязкой уже к вашему родному региону. Сегодня раскатим фикс, который починит эту проблему окончательно.
                +1
                Яндекс, все же, действительно аналог Гугла. Причем я сейчас без намеков на Google Now. Я про дизайн.

                Что у Гугла отличная программная начинка, но отвратительнейший дизайн, который только продолжает портиться, что у вас. В последнем Я.Диске черт ногу сломит. Теперь тут. Где кнопка, а где просто текст с пиктограммой — не понятно.

                Хотя в мобильных приложениях все более-менее нормально. Не удивляюсь, если за мобильный дизайн отвечает другая группа дизайнеров. Более адекватная.
                  +5
                  Три раза на первом скриншоте прочитал «бабы, пабы». Пора в отпуск...
                    0
                    У меня все выходит наоборот «бары, бабы». Видимо, различия в геолокации сказываются. Но в отпуск пора!
                    0
                    Похоже, что когда-то был алиас city.yandex.ru — кое-где остался этот url на страницах gorod.yandex.ru
                    Хе, зашёл поискать свою организацию — увидел, что у нас три адреса, один из них уже неактуальный — пошёл делать заявку в справочник, чтобы почистили. Тоже повод.
                      0
                      Спасибо большое. Фидбек, особенно по закрытым дублям, очень важен для нас. А подскажете, пожалуйста, вы просто оформили заявку на изменение или подтвердили права? Если в Справочнике подтвердить права на организацию все манипуляции с ее карточкой становятся чуть более удобными.
                        0
                        Хм, вы так задали вопрос, что на него придётся ответить развёрнуто, иначе будет непонятно.

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

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

                        Так вот по вашему вопросу насчёт заявки… Все организации подтверждены и промодерированы, да. НО!!! Я читал справку и видел на скриншотах галку «удалить организацию» — и искал её ОЧЕНЬ долго, хотел даже уже через техподдержку запросить удаление. В чём дело? Я создавал организации из яндекс: вебмастера — а там галки на удаление нет, пока я сообразил, что удалять нужно именно через справочник организаций… В общем, фичереквест номер два: поясните в справке, что в панели вебмастера не удалишь, нужно идти в справочник, ещё лучше — продублируйте галку удаления в панель вебмастера. Это просто может быть и очевидно, если занимаешься сайтом постоянно (или у тебя их десятки), а когда время от времени приглядываешь по просьбе знакомых — долго соображаешь.

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

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

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

                          P.S. Бундок клевое место, не знала, что там играют в мафию)
                      0
                      Из-под немецкого впн на начальном экране определяет: «Ваш город Москва» (видимо из кукисов), а дальше все на немецком и на карте окрестности Берлина.

                      upd: пришлось войти в свой аккаунт на яндексе, залезть в настройки и поменять там настройки.
                        0
                        Инокна надеюсь поменяется, вырвиглаз(тм)
                          0
                          Не знаю как у вас нынче с качеством (пока оценить особо не на чем), а вот дизайн android-приложения требует доработки. А возможно и функционал. Установил приложение на работе, так и не понял как на нём найти что-то около дома, где поменять расстояние для поиска и уточнить условия. В фильтрах, например, есть некий «Учитывать». Там 3 варианта: «Расстояние, Рейтинг, Всё». Что их выбор меняет? Есть закладки для выбранных мест, но места то я запомню, мне бы наоборот закладку на запрос «чо пожрать» с какими-нибудь параметрами, но его сохранить походу негде. 40 МБ кэша после 1 запроса — это что, откуда? У меня в яндекс навигаторе тонна карт, в яндекс картах ещё тонна в кэше, ещё тут свой будет? Вы не думали совместить это дело? Мне пространства не сильно жалко на планшете, но если бы он был не 32-гиговым, я бы задумался.
                            0
                            Вкратце о чем фича «учитывать расстояние/рейтинг/все»:

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

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

                            В интерфейсе этот случай: «учитывать расстояние»

                            — второй паттерн: найти самое классное место в относительной близости. Иногда не так критично прокатиться 2-3 километра или дойти до соседней станции метро, к примеру, если выбираешь место, где поужинать с друзьями. В этом случае важен именно рейтинг заведение, наличие у него фото, отзывов и другая комплиментарная информация о заведении. Это кейс «учитывать рейтинг»

                            — есть еще третий паттерн, когда важно и расстояние, и рейтинг. Это то самое «учитывать все»

                            — мы сделали небольшое a/b тестирование, раскатив разные варианты интерфейса для пользователей. Вы увидели первый. Второй выглядит похоже, но предлагает показать «Популярное (паттерн 2) или ближайшее (паттерн 1)»
                            — похоже, что на текущий момент побеждает альтернативный вариант: «показать ближайшее/популярное»

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

                            Сохранение поисковых запросов в закладки в планах.
                            +1
                            А где Windows Phone приложение?
                              +1
                              Поддерживаю… WP приложение просто не обходимо…
                                +1
                                Приятно видеть Windows Phone пользователей, требущих версию Города. О WP приложении обязательно начнем думать, но ближе к концу этого года.
                              0
                              Бинго!
                              Image and video hosting by TinyPic
                                0
                                А кнопочка фидбэк «не нашел, что искал» у вас есть? (А то так и будете) измерять сферического коня в вакууме…
                                Блэкберри Мэпс так и не научились распознавать Schillerstr. в Германии, только Schiller Strasse понимают, и то не всегда. А как им об этом намекнуть, болезным, так и не нашел.
                                  0
                                  В мобильной версии пока есть только 2 возможных варианта фидбека:
                                  — добавить организацию – показываем, если по поисковому запросу ничего не нашлось и предлагаем пользователю заполнить базовую форму добавления организации.

                                  — в профиле, в разделе «о программе» есть раздел «написать разработчикам». В Android вместе с вашим письмом к нему прикрепится поисковой лог с 10 последними запросами, чтобы мы могли подробно разобрать вашу проблему формата «не нашлось нужное».

                                  В iOS скоро выкатим такую штуку, пока лог пользователя не прикрепляем.
                                  +2
                                  Плохо что нет возможности в приложении на iOS изменить язык интерфейса, а то получается часть информации на английском, часть на русском.
                                  Например в англоязычном интерфейсе кнопка «Report an issue» ведет на полностью рускоязычную страницу. Голосовой поиск тоже не работает с русским языком — очевидно. А вот примеры запросов отображемые слайдами на главной странице при клике конвертируются в русскоязычные запросы — тоже непонятно зачем.

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

                                    1. Страница «Report an issue» – не нативная штука, а компонент в верстке, для которого раньше не была предусмотрена локализация. Ребята в верстке в конце июня добавят в компонент возможность локализации

                                    2. Данные об организациях (в частности названия) начнут приходить на языке региона (то есть по всей России – преимущественно на русском, за исключением названий типа Harat's Pub) вне зависимости от локали приложения

                                    3. Язык голосового поиска можно будет выбрать в Настройках

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

                                    Поэтому поиск чего-то вроде «restaurant with a children's room» отдает результаты по качеству сильно уступающие результатам аналогичного русского запроса. Учитывая, что более 90% пользователей с en локалью у нас из РКУБ ( Россия, Украина, Беларусь, Казахстан), такое решение кажется лучше, чем показывать им не супер качественные результаты по англоязычным запросам.

                                    Но в остальных моментах то, что язык интерфейса задается настройками системы, нам кажется правильным.
                                    0
                                    42 раза встречается слово «метрика»…
                                      0
                                      41 вроде

                                    Only users with full accounts can post comments. Log in, please.