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


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


Например, «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. Хорошие тесты долго создавать и дорого поддерживать.
Поделиться с друзьями
-->

Комментарии (15)


  1. Zolg
    18.10.2016 18:53
    +3

    «Терская» — это, скорее всего, Тверская улица, а не
    а не производная от Терека без всяких опечаток?


    1. sergeykorol
      18.10.2016 18:54
      +2

      Кстати, такая есть в Анапе.


    1. svboobnov
      19.10.2016 18:16

      И ещё в Азове, ЕМНИП, (Ростовская область) есть Терская.


  1. wertex15
    18.10.2016 20:03

    Тратить то тратите, но так и не поправили информацию по api на этой странице https://dadata.ru/api/clean/ хотя я в своем письме Елене Журавлевой указывал это еще 9.09.16


    1. sergeykorol
      18.10.2016 20:03

      Спасибо, посмотрим.


  1. TimsTims
    18.10.2016 23:18

    Классный сервис. По опыту могу сказать, что вам стоит присмотреться продавать его в банки. Абсолютное большинство банков мучаются с отсутствием нормального исправителя адресов по КЛАДРу. Из-за этого, ЦБ штрафует банки на приличные суммы. Из-за этого банки запрягаяют своих операционистов, чтобы они сотнями и тысячами вручную исправляли адреса клиентам. Тысячи человекочасов тратятся на рутинную работу, с которой отлично может справиться ваш сервис. Поэтому отделу продаж надо целить в банки, имхо :)


    1. asm0dey
      19.10.2016 07:38

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


  1. nsdfxela
    18.10.2016 23:49

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


    1. algenon
      19.10.2016 11:07

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


  1. yanykin
    19.10.2016 10:29

    А как сервис различает ситуации, в которых названия улиц почти похожи с точностью до одного-двух редакторских исправлений? Например, в Москве есть как Дубнинская улица, так и Дубининская.


    1. sergeykorol
      19.10.2016 10:30

      Задача сервиса — определить такие случаи и отсеять из для ручной проверки. Иначе есть большой шанс исправить неправильно и потравить яблоко.


    1. ALIron
      19.10.2016 11:41

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


  1. ALIron
    19.10.2016 10:39
    -2

    2 миллиона $ это конечно хорошо, даже очень, но всё же.
    Это 124 млн рублей в год, по 10 млн в месяц.
    Для работы вида

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

    и белой зп с налогами в 100 т.р/ месяц получатся 103 обезьянки. (с запасом)
    HFLabs всего работает около 20-30 человек.
    Или вы лукавите ли работы делает кто-то другой, а вы пользуетесь их трудом.
    Если кто то другой — то каков уровень доверия к таким тестам и из наполнению?


    1. ALIron
      19.10.2016 10:43
      -2

      В продолжении 100 тыс адресов при работе по 15 минут на адрес (а бывают куда более сложные случаи и по пол часа и по часу разбираются что случилось) получается трудозатраты 25 тыс часов, или 142 человекомесяца.
      Тупого достаточно труда. У вас ИТ-фабрика в Китае? =)


  1. ALIron
    19.10.2016 10:56
    -1

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


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

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

    Четыре девятки это показатель относительно чего?