Comments 28
«Терская» — это, скорее всего, Тверская улица, а неа не производная от Терека без всяких опечаток?
Тратить то тратите, но так и не поправили информацию по api на этой странице https://dadata.ru/api/clean/ хотя я в своем письме Елене Журавлевой указывал это еще 9.09.16
Классный сервис. По опыту могу сказать, что вам стоит присмотреться продавать его в банки. Абсолютное большинство банков мучаются с отсутствием нормального исправителя адресов по КЛАДРу. Из-за этого, ЦБ штрафует банки на приличные суммы. Из-за этого банки запрягаяют своих операционистов, чтобы они сотнями и тысячами вручную исправляли адреса клиентам. Тысячи человекочасов тратятся на рутинную работу, с которой отлично может справиться ваш сервис. Поэтому отделу продаж надо целить в банки, имхо :)
Попытка исправить адрес «саранск кир завод 19» привела к «Брянская обл, Погарский р-н, п Кирпичный завод, д 19»
Случай вполне реальный, (адрес проверяется гуглом), хотя и надо признать, что непростой.
Случай вполне реальный, (адрес проверяется гуглом), хотя и надо признать, что непростой.
А как сервис различает ситуации, в которых названия улиц почти похожи с точностью до одного-двух редакторских исправлений? Например, в Москве есть как Дубнинская улица, так и Дубининская.
Задача сервиса — определить такие случаи и отсеять из для ручной проверки. Иначе есть большой шанс исправить неправильно и потравить яблоко.
Адресная строка рассматривается как единый указатель на точку.
Если есть неопределенность в улице рассматривается город, в Москве есть и Дубнинская и Дубининская — ок. Смотрим индекс если есть у этих улиц они разные. Смотрим дома (есть случаи когда на одной улице дом 55 есть, а на второй его нет)
Таких факторов внутри адресной строки много.
И если не можем принять решение о гарантии «зеленого» разбора — да отдаем на ручную проверку, но нужно понимать что любой подготовленный человек на такой работе дает в среднем 1-2% ошибки, а если это потоковый разбор то может отдавать и все 5% с ошибкой.
За человеком тоже нужна проверка.
«Машина разбирает- человек проверяет. Человек разбирает — машина проверяет»
Если есть неопределенность в улице рассматривается город, в Москве есть и Дубнинская и Дубининская — ок. Смотрим индекс если есть у этих улиц они разные. Смотрим дома (есть случаи когда на одной улице дом 55 есть, а на второй его нет)
Таких факторов внутри адресной строки много.
И если не можем принять решение о гарантии «зеленого» разбора — да отдаем на ручную проверку, но нужно понимать что любой подготовленный человек на такой работе дает в среднем 1-2% ошибки, а если это потоковый разбор то может отдавать и все 5% с ошибкой.
За человеком тоже нужна проверка.
«Машина разбирает- человек проверяет. Человек разбирает — машина проверяет»
2 миллиона $ это конечно хорошо, даже очень, но всё же.
Это 124 млн рублей в год, по 10 млн в месяц.
Для работы вида
и белой зп с налогами в 100 т.р/ месяц получатся 103 обезьянки. (с запасом)
HFLabs всего работает около 20-30 человек.
Или вы лукавите ли работы делает кто-то другой, а вы пользуетесь их трудом.
Если кто то другой — то каков уровень доверия к таким тестам и из наполнению?
Это 124 млн рублей в год, по 10 млн в месяц.
Для работы вида
Это значит, что ежемесячно вручную проверяются десятки и сотни тысяч адресов. Постепенно процессы отлаживаются и обслуживание такого корпуса снижается, но вряд ли на это стоит рассчитывать в первые годы.
и белой зп с налогами в 100 т.р/ месяц получатся 103 обезьянки. (с запасом)
HFLabs всего работает около 20-30 человек.
Или вы лукавите ли работы делает кто-то другой, а вы пользуетесь их трудом.
Если кто то другой — то каков уровень доверия к таким тестам и из наполнению?
По этим же причинам перенос технологии из одной страны и языка на другие практически эквивалентен разработке с нуля, поскольку львиная доля времени и расходов — это качественные тесты, а не алгоритмы.
Зависит от подхода. Если лупить просто по хэш таблицам которые наполняются за 2 млн $ /год -да.
А если учитывать семантику (европейские языки похожи, а иероглифические тоже можно) и верифицировать с эталонами, то можно и Украину разбирать и Казахстан с Германией.
ФИАС имеет в среднем 2-3% ошибок о каких 4-х девятках мы говорим с таким уровнем эталона? Свой эталон? — Отлично, но ошибки суммируются, а не компенсируются зачастую.
Четыре девятки это показатель относительно чего?
Где вы были 10 лет назад )
Приходилось писать скрипт для такой обработки своими силами (на основе КЛАДР):
Приходилось писать скрипт для такой обработки своими силами (на основе КЛАДР):
только у КЛАДР индексы не всегда совпадали с данными почты России, по крайней мере 3 года назад
Совпадает не всегда и сейчас, а вот если добавить Росреестр и БТИ по всей стране, получается множественная версия правды в зависимости от применения.
Хочешь посылки доставлять — бери почтовую базу,
Хочешь налоги считать / сдавать — бери ФИАС
Хочешь в Агенство по страхованию вкладов отчетность сдать — бери КЛАДР
Ну БТИ — отдельные ребята, хотя пространство — время у нас с ними общее живут параллельно не пересекаясь с остальными.
Хочешь посылки доставлять — бери почтовую базу,
Хочешь налоги считать / сдавать — бери ФИАС
Хочешь в Агенство по страхованию вкладов отчетность сдать — бери КЛАДР
Ну БТИ — отдельные ребята, хотя пространство — время у нас с ними общее живут параллельно не пересекаясь с остальными.
поэтому ждем не дождемся, когда почта откроет доступ к апи личного кабинета по работе с отправлениями. Пока что он доступен только для клиентов из Москвы
Думаете там будет разбор адресов из строчки да еще и по почтовой БД?
Обещано
Подсказки при вводе, очистка и валидация данных
Автоматическое определение индекса места доставки
работа с JSON
спецификация уже выложена, есть примеры на python
А какие то показатели надежности определены?
Прямая и обратная ошибки? Полнота и актуальность базы?
Подсказки при массовом вводе — это зло, ускоряют ввод, но приводят к необратимым ошибкам (те самые отравленные яблоки). Часто оператор выбирает первый примерно подходящий suggest и если это улица — товар улетает не туда.
На больших городах часто потери такого вида идут.
Определение индекса доставки по строчке — отличная функций, очень полезная. Посмотрим как будет работать.
Можно ссылку на обещание почты?
Прямая и обратная ошибки? Полнота и актуальность базы?
Подсказки при массовом вводе — это зло, ускоряют ввод, но приводят к необратимым ошибкам (те самые отравленные яблоки). Часто оператор выбирает первый примерно подходящий suggest и если это улица — товар улетает не туда.
На больших городах часто потери такого вида идут.
Определение индекса доставки по строчке — отличная функций, очень полезная. Посмотрим как будет работать.
Можно ссылку на обещание почты?
1.В ответе типа все есть
Внимание!
Анализируйте Код качества (quality-code) и Код проверки (validation-code) в ответах.
Код качества должен быть: GOOD, POSTAL_BOX, ON_DEMAND или UNDEF_05.
Код проверки должен быть: CONFIRMED_MANUALLY или VALIDATED.
Иначе нормализуемый адрес может быть неприемлем для доставки!
Не совсем.
Коды качества определяют качество конкретного результата, а показатели прямой и обратной ошибки определяются обычно на выборе в 10 или 100 тыс записей.
Пресловутые 99,99% из статьи, значат, что прямая ошибка (не нашли) всего 0.01%. Обратная ошибка (отравленные яблоки) не обозначаются.
Полнота базы — дом есть, его нет в базе=> база не полная.
Актуальность базы — дом снесли, а в базе он нормальный и можно доставлять => база не актуальная.
Полнота и актуальность так же определяется % от общего количества объектов.
За ссылку спасибо.
Коды качества знакомые. =) похожи на те что отдает владелец блога.
https://dadata.ru/api/clean/
https://otpravka.pochta.ru/specification#/enums-clean-address-quality
Похоже, но нет.
Не будет отдавать почта такие коды =)
Коды качества определяют качество конкретного результата, а показатели прямой и обратной ошибки определяются обычно на выборе в 10 или 100 тыс записей.
Пресловутые 99,99% из статьи, значат, что прямая ошибка (не нашли) всего 0.01%. Обратная ошибка (отравленные яблоки) не обозначаются.
Полнота базы — дом есть, его нет в базе=> база не полная.
Актуальность базы — дом снесли, а в базе он нормальный и можно доставлять => база не актуальная.
Полнота и актуальность так же определяется % от общего количества объектов.
За ссылку спасибо.
Коды качества знакомые. =) похожи на те что отдает владелец блога.
https://dadata.ru/api/clean/
https://otpravka.pochta.ru/specification#/enums-clean-address-quality
Похоже, но нет.
Не будет отдавать почта такие коды =)
Да я ни в коей мере и не хотел сравнивать конкретно сабжевый проект и решение почты России.
Обычно в проекте проще использовать в плане поддержки одно решение, чем два.
Поэтому мы и ждем решение от почты, потому что оно в себя включает автоматизацию обработки входных данных, регистрации, отправки и отслеживания посылок.
Это решение всяко лучше чем текущее локальное решение "Партионная почта", в котором только хардкор: ручное занесение данных, ручной экспорт в xls, отправка xls в почтовое отделение, печать списков, а потом еще на почте до 12 часов работы
Конечно, если нам не будет хватить возможностей для корректировки адреса получателя, мы рассмотрим все же оба решения.
Да, вы все правильно поняли — это тот же «Фактор», что и Дадатой используется.
10 лет назад мы чистили адреса первому клиенту и про нас ещё никто не знал :-) Про скрипт очень знакомо, сами с этого начинали :-))
Sign up to leave a comment.
Почему мы в «Дадате» тратим 2 млн долларов в год на 99,99% точность обработки данных