Почему мы в «Дадате» тратим 2 млн долларов в год на 99,99% точность обработки данных

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


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


    Например, «8 Марта 1 12» — это «1-я улица 8 Марта, дом 12» или «улица 8 Марта, дом 1, квартира 12»? Оба адреса существуют и правильные, но какой из них соответствует исходному?


    Серая зона


    При обработке адресов возникает три группы результатов:

    • Хорошие — ошибок не было или их удалось однозначно исправить.
    • Плохие — ничего нельзя сделать: не хватает данных или равновероятная неоднозначность, как в примере с улицей 8 Марта;
    • Непонятные — ошибки исправили, но сделали при этом какие-то допущения.

    Фронт битвы за качество — это чтобы зеленых адресов было как можно больше, но при этом среди них не попадались красные.

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


    В остальных случаях требуется быстро получить подмножество «зеленых» данных, где совершенно точно нет ошибок, и сразу запустить их в работу: выдавать кредиты, слать товары, использовать для скоринга и выписывать страховые полисы. Получили 50% зелёных данных? Плоховато, но уже ценно для бизнеса. 80%? Супер, количество ручной работы сократилось в 5 раз! 95%?


    А с остальными «серенькими» можно разобраться потом. Параноидально доводить всю базу до 100% обычно не имеет особого смысла с точки зрения бизнеса, поэтому ценных и актуальных клиентов исправляют форсировано (обычно с привлечением ручного труда сотрудников или подъемом первичной документации). А остальные так и остаются в «серой зоне», пока клиент сам не свяжется с компанией.


    Красные в зелёной шкуре


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


    Предположим, что у нас есть корзина с двумя десятками яблок. Мы знаем, что среди них есть отравленные. Откусишь — умрешь. Но сколько их — неизвестно. Может все отравлены, а может и ни одного.


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


    Теперь допустим, что в 5 яблок из 20 воткнута табличка «это яблоко точно не отравлено». Яблоки те же, только есть еще и таблички. Теперь другое дело. Да, 5 яблок из 20 — это немного, но их можно съесть. А если их будет не 5, а 15? Ценности в три раза больше!


    А если их будет 19, но на табличке будет не «точно не отравлено», а «95%, что не отравлено»? Рискнете? Очевидно, что потребительская ценность такой корзины резко падает.



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


    Сломать, чтобы починить


    Десять лет назад у нас в «Дадате» уже были отличные алгоритмы, которые исправляли даже очень сложные адреса: с опечатками, нарушенным порядком, с переименованиями и переподчинениями.


    Каждое преобразование хорошо объяснялось в логике программы, но с точки зрения человека было много изуверских случаев, когда результирующий очищенный адрес был совершенно не похож на исходный. В самом деле, любая абракадабра, даже фзвща8г2з98оаз9, может быть адресом с большим количеством опечаток. Но это по логике программы, а не человека со здравым смыслом.


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


    • Не было ли ошибки в разборе?
    • Действительно ли результирующий адрес соответствует исходному, или алгоритмы что-то нафантазировали?
    • Действительно ли код качества отражает то, что произошло с адресом?

    Валидированные таким образом данные — очень зеленые. Для валидированных данных мы добились точности 99,99%, или не более 1 ошибки на 10000 записей. Такая точность гарантирована ежедневно актуализируемыми тестами из десятков миллионов примеров. Это сверхчеловеческий уровень качества. Блестящая победа человеческого разума над самим собой!


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


    Магия «девяток»


    Разница между качеством 99,99% и 99,98% — в два раза. В первом случае 1 ошибка на 10 000, а во втором — 2 ошибки на 10 000 записей.

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


    Если 90% можно гарантировать репрезентативным тестом из 10 тысяч тестовых пар (исходный адрес и ожидаемый очищенный), то для 99% понадобится уже около 100 тысяч, а для 99,99% — не менее 10 миллионов тестов. Не случайных записей, а именно тестов, представительность каждого случая в которых отражает встречаемость проблемы в реальных данных.



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


    Точность «Дадаты» стоит нам около двух миллионов долларов в год.

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


    Выводы


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


    1. Точные коды качества важнее точности обработки данных.
    2. Коды качества должен присваивать не тот алгоритм, который обрабатывает данные.
    3. Точность недостижима без хороших тестов.
    4. Хорошие тесты долго создавать и дорого поддерживать.

    HFLabs

    44,00

    Качество и интеграция клиентских данных

    Поделиться публикацией

    Похожие публикации

    Комментарии 28
      +3
      «Терская» — это, скорее всего, Тверская улица, а не
      а не производная от Терека без всяких опечаток?
        +2
        Кстати, такая есть в Анапе.
          0
          И ещё в Азове, ЕМНИП, (Ростовская область) есть Терская.
          0
          Тратить то тратите, но так и не поправили информацию по api на этой странице https://dadata.ru/api/clean/ хотя я в своем письме Елене Журавлевой указывал это еще 9.09.16
            0
            Спасибо, посмотрим.
            0
            Классный сервис. По опыту могу сказать, что вам стоит присмотреться продавать его в банки. Абсолютное большинство банков мучаются с отсутствием нормального исправителя адресов по КЛАДРу. Из-за этого, ЦБ штрафует банки на приличные суммы. Из-за этого банки запрягаяют своих операционистов, чтобы они сотнями и тысячами вручную исправляли адреса клиентам. Тысячи человекочасов тратятся на рутинную работу, с которой отлично может справиться ваш сервис. Поэтому отделу продаж надо целить в банки, имхо :)
              0

              Так это, в сбере факторов под завязку закуплено, например :)

              0
              Попытка исправить адрес «саранск кир завод 19» привела к «Брянская обл, Погарский р-н, п Кирпичный завод, д 19»
              Случай вполне реальный, (адрес проверяется гуглом), хотя и надо признать, что непростой.
                0

                Да. И поставила табличку «на ручную проверку», то есть явно указала, что яблоко может быть отравлено :–) Как написано в статье, главное отделить ядовитые яблоки от хороших.

                0
                А как сервис различает ситуации, в которых названия улиц почти похожи с точностью до одного-двух редакторских исправлений? Например, в Москве есть как Дубнинская улица, так и Дубининская.
                  0
                  Задача сервиса — определить такие случаи и отсеять из для ручной проверки. Иначе есть большой шанс исправить неправильно и потравить яблоко.
                    0
                    Адресная строка рассматривается как единый указатель на точку.
                    Если есть неопределенность в улице рассматривается город, в Москве есть и Дубнинская и Дубининская — ок. Смотрим индекс если есть у этих улиц они разные. Смотрим дома (есть случаи когда на одной улице дом 55 есть, а на второй его нет)
                    Таких факторов внутри адресной строки много.
                    И если не можем принять решение о гарантии «зеленого» разбора — да отдаем на ручную проверку, но нужно понимать что любой подготовленный человек на такой работе дает в среднем 1-2% ошибки, а если это потоковый разбор то может отдавать и все 5% с ошибкой.
                    За человеком тоже нужна проверка.
                    «Машина разбирает- человек проверяет. Человек разбирает — машина проверяет»
                    –2
                    2 миллиона $ это конечно хорошо, даже очень, но всё же.
                    Это 124 млн рублей в год, по 10 млн в месяц.
                    Для работы вида
                    Это значит, что ежемесячно вручную проверяются десятки и сотни тысяч адресов. Постепенно процессы отлаживаются и обслуживание такого корпуса снижается, но вряд ли на это стоит рассчитывать в первые годы.

                    и белой зп с налогами в 100 т.р/ месяц получатся 103 обезьянки. (с запасом)
                    HFLabs всего работает около 20-30 человек.
                    Или вы лукавите ли работы делает кто-то другой, а вы пользуетесь их трудом.
                    Если кто то другой — то каков уровень доверия к таким тестам и из наполнению?
                      –2
                      В продолжении 100 тыс адресов при работе по 15 минут на адрес (а бывают куда более сложные случаи и по пол часа и по часу разбираются что случилось) получается трудозатраты 25 тыс часов, или 142 человекомесяца.
                      Тупого достаточно труда. У вас ИТ-фабрика в Китае? =)
                      –1
                      По этим же причинам перенос технологии из одной страны и языка на другие практически эквивалентен разработке с нуля, поскольку львиная доля времени и расходов — это качественные тесты, а не алгоритмы.


                      Зависит от подхода. Если лупить просто по хэш таблицам которые наполняются за 2 млн $ /год -да.
                      А если учитывать семантику (европейские языки похожи, а иероглифические тоже можно) и верифицировать с эталонами, то можно и Украину разбирать и Казахстан с Германией.

                      ФИАС имеет в среднем 2-3% ошибок о каких 4-х девятках мы говорим с таким уровнем эталона? Свой эталон? — Отлично, но ошибки суммируются, а не компенсируются зачастую.

                      Четыре девятки это показатель относительно чего?
                        0
                        Где вы были 10 лет назад )
                        Приходилось писать скрипт для такой обработки своими силами (на основе КЛАДР):

                        image
                          0

                          только у КЛАДР индексы не всегда совпадали с данными почты России, по крайней мере 3 года назад

                            0
                            Совпадает не всегда и сейчас, а вот если добавить Росреестр и БТИ по всей стране, получается множественная версия правды в зависимости от применения.
                            Хочешь посылки доставлять — бери почтовую базу,
                            Хочешь налоги считать / сдавать — бери ФИАС
                            Хочешь в Агенство по страхованию вкладов отчетность сдать — бери КЛАДР
                            Ну БТИ — отдельные ребята, хотя пространство — время у нас с ними общее живут параллельно не пересекаясь с остальными.

                              0

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

                                0
                                Думаете там будет разбор адресов из строчки да еще и по почтовой БД?

                                  0

                                  Обещано


                                  Подсказки при вводе, очистка и валидация данных
                                  Автоматическое определение индекса места доставки

                                  работа с JSON
                                  спецификация уже выложена, есть примеры на python

                                    0
                                    А какие то показатели надежности определены?
                                    Прямая и обратная ошибки? Полнота и актуальность базы?
                                    Подсказки при массовом вводе — это зло, ускоряют ввод, но приводят к необратимым ошибкам (те самые отравленные яблоки). Часто оператор выбирает первый примерно подходящий suggest и если это улица — товар улетает не туда.
                                    На больших городах часто потери такого вида идут.
                                    Определение индекса доставки по строчке — отличная функций, очень полезная. Посмотрим как будет работать.
                                    Можно ссылку на обещание почты?
                                      0

                                      1.В ответе типа все есть


                                      Внимание!
                                      Анализируйте Код качества (quality-code) и Код проверки (validation-code) в ответах.
                                      Код качества должен быть: GOOD, POSTAL_BOX, ON_DEMAND или UNDEF_05.
                                      Код проверки должен быть: CONFIRMED_MANUALLY или VALIDATED.
                                      Иначе нормализуемый адрес может быть неприемлем для доставки!

                                      1. Да, конечно.
                                        https://otpravka.pochta.ru/specification#/nogroup-normalization_adress
                                        0
                                        Не совсем.
                                        Коды качества определяют качество конкретного результата, а показатели прямой и обратной ошибки определяются обычно на выборе в 10 или 100 тыс записей.

                                        Пресловутые 99,99% из статьи, значат, что прямая ошибка (не нашли) всего 0.01%. Обратная ошибка (отравленные яблоки) не обозначаются.

                                        Полнота базы — дом есть, его нет в базе=> база не полная.
                                        Актуальность базы — дом снесли, а в базе он нормальный и можно доставлять => база не актуальная.
                                        Полнота и актуальность так же определяется % от общего количества объектов.

                                        За ссылку спасибо.
                                        Коды качества знакомые. =) похожи на те что отдает владелец блога.
                                        https://dadata.ru/api/clean/
                                        https://otpravka.pochta.ru/specification#/enums-clean-address-quality
                                        Похоже, но нет.
                                        Не будет отдавать почта такие коды =)
                                          0

                                          Да я ни в коей мере и не хотел сравнивать конкретно сабжевый проект и решение почты России.
                                          Обычно в проекте проще использовать в плане поддержки одно решение, чем два.
                                          Поэтому мы и ждем решение от почты, потому что оно в себя включает автоматизацию обработки входных данных, регистрации, отправки и отслеживания посылок.
                                          Это решение всяко лучше чем текущее локальное решение "Партионная почта", в котором только хардкор: ручное занесение данных, ручной экспорт в xls, отправка xls в почтовое отделение, печать списков, а потом еще на почте до 12 часов работы
                                          Конечно, если нам не будет хватить возможностей для корректировки адреса получателя, мы рассмотрим все же оба решения.

                                            0
                                            Внутри этого API тот же «Фактор», что используется в Дадате :-) Почта России — наш давний любимый клиент.
                                            0
                                            Да, вы все правильно поняли — это тот же «Фактор», что и Дадатой используется.
                              0
                              10 лет назад мы чистили адреса первому клиенту и про нас ещё никто не знал :-) Про скрипт очень знакомо, сами с этого начинали :-))

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

                            Самое читаемое