Вы когда-нибудь задумывались, почему вообще возможно исправить ошибки и опечатки в текстовых данных, например, в адресах и именах? Почему мы думаем, что «Терская» — это, скорее всего, Тверская улица, а не какая-нибудь фантастическая улица Василиятёрского? А вдруг это Комсомольский проспект, в котором сделано двадцать опечаток? Например, «8 Марта 1 12» — это «1-я улица 8 Марта, дом 12» или «улица 8 Марта, дом 1, квартира 12»? Оба адреса существуют и правильные, но какой из них соответствует исходному? Для спам-рассылки обычно достаточно, чтобы больше спама достигло своих адресатов, при этом не отправлять письма на совсем уж очевидные «черные дыры». То есть важно, чтобы база после обработки стала лучше, чем была. Или хотя бы не стала хуже. Это, пожалуй, единственный случай, когда процент распознанных данных имеет самостоятельную ценность. В остальных случаях требуется быстро получить подмножество «зеленых» данных, где совершенно точно нет ошибок, и сразу запустить их в работу: выдавать кредиты, слать товары, использовать для скоринга и выписывать страховые полисы. Получили 50% зелёных данных? Плоховато, но уже ценно для бизнеса. 80%? Супер, количество ручной работы сократилось в 5 раз! 95%? А с остальными «серенькими» можно разобраться потом. Параноидально доводить всю базу до 100% обычно не имеет особого смысла с точки зрения бизнеса, поэтому ценных и актуальных клиентов исправляют форсировано (обычно с привлечением ручного труда сотрудников или подъемом первичной документации). А остальные так и остаются в «серой зоне», пока клиент сам не свяжется с компанией. Но это все имеет смысл только когда наши «зеленые» — действительно зеленые. Такие, что мы им верим, как самим себе и даже больше. Когда их не нужно проверять. Предположим, что у нас есть корзина с двумя десятками яблок. Мы знаем, что среди них есть отравленные. Откусишь — умрешь. Но сколько их — неизвестно. Может все отравлены, а может и ни одного. Потребительская ценность такой корзины близка к нулю. Разумный человек решится взять хоть одно яблочко, только если альтернативой будет голодная смерть. Теперь допустим, что в 5 яблок из 20 воткнута табличка «это яблоко точно не отравлено». Яблоки те же, только есть еще и таблички. Теперь другое дело. Да, 5 яблок из 20 — это немного, но их можно съесть. А если их будет не 5, а 15? Ценности в три раза больше! А если их будет 19, но на табличке будет не «точно не отравлено», а «95%, что не отравлено»? Рискнете? Очевидно, что потребительская ценность такой корзины резко падает. Эти таблички в разборе слабоструктурированных данных называются кодами качества. По сути это те же таблички: «точно не отравлено», «нельзя при беременности и лактации», «цианистый калий, 100 мг». Десять лет назад у нас в «Дадате» уже были отличные алгоритмы, которые исправляли даже очень сложные адреса: с опечатками, нарушенным порядком, с переименованиями и переподчинениями. Каждое преобразование хорошо объяснялось в логике программы, но с точки зрения человека было много изуверских случаев, когда результирующий очищенный адрес был совершенно не похож на исходный. В самом деле, любая абракадабра, даже фзвща8г2з98оаз9, может быть адресом с большим количеством опечаток. Но это по логике программы, а не человека со здравым смыслом. Поэтому мы добавили процесс валидации разобранных данных. Валидация специально портит хорошие данные и делает из них плохие. Для валидации используются совершенно другие алгоритмы, чем для разбора — они пробуют разобранные данные искорежить таким образом, чтобы снова получился исходный адрес. Таким образом проверяется сразу несколько вещей: Валидированные таким образом данные — очень зеленые. Для валидированных данных мы добились точности 99,99%, или не более 1 ошибки на 10000 записей. Такая точность гарантирована ежедневно актуализируемыми тестами из десятков миллионов примеров. Это сверхчеловеческий уровень качества. Блестящая победа человеческого разума над самим собой! Главное здесь — «ежедневно актуализируемые тесты из десятков миллионов примеров». Создание тестов — это не одноразовая задача, а постоянный процесс, поскольку меняются справочники, и жизнь приносит новые случаи. Без тестов невозможно гарантировать, что «зеленые» данные — действительно «зеленые», а без этого для большинства реальных применений все теряет смысл. Достижение и постоянное обслуживание каждой гарантированной «девятки» стоит дороже, чем все предыдущие «девятки» вместе взятые. Это не только значительно более сложные алгоритмы, но и значительно более объемные тесты, которые должны репрезентативно отражать разные случаи в реальных данных и разные ветвления этих более сложных алгоритмов. Если 90% можно гарантировать репрезентативным тестом из 10 тысяч тестовых пар (исходный адрес и ожидаемый очищенный), то для 99% понадобится уже около 100 тысяч, а для 99,99% — не менее 10 миллионов тестов. Не случайных записей, а именно тестов, представительность каждого случая в которых отражает встречаемость проблемы в реальных данных. Поскольку на таких объемах добиться распределения встречаемости крайне трудно, то приходится использовать еще большие объемы, чтобы уж точно все встретилось. В итоге минимальный корпус тестов для русских адресов — это примерно 50 миллионов тестовых пар, которые актуализируются специалистами на несколько процентов в год. Это значит, что ежемесячно вручную проверяются десятки и сотни тысяч адресов. Постепенно процессы отлаживаются и обслуживание такого корпуса снижается, но вряд ли на это стоит рассчитывать в первые годы. Разработка парсеров вполне по силам талантливым энтузиастам и небольшим командам, но высокие и гарантированные показатели качества на произвольных данных практически недостижимы. По этим же причинам перенос технологии из одной страны и языка на другие практически эквивалентен разработке с нуля, поскольку львиная доля времени и расходов — это качественные тесты, а не алгоритмы. Описанные явления характерны не только для адресов, но и для любых применяемых в реальном бизнесе результатов работы со слабоструктурированными данными. Для глубокого машинного обучения, больших данных, для текста, голоса, картинок и видео — везде будут эти закономерности: Редактор