Качество и интеграция клиентских данных
106,11
рейтинг
16 октября 2014 в 15:36

Разработка → Как выбрать алгоритм для адресного фильтра


Довольно часто на Хабре появляются статьи с новыми алгоритмами автоматического разбора адресов, записанных одной строкой. Кроме этого, услуги по обработке адресов предоставляют различные it-компании. В статье мы расскажем как использовать свою адресную базу для выбора алгоритма автоматического разбора адресов, и на что стоит обратить внимание при тестировании и разработке алгоритмов адресных фильтров.

Эта статья для всех, кто хранит данные клиентов и хочет решить одну из следующих задач:
  1. убедиться, что адрес существует, чтобы не отправить посылку или письмо в никуда;
  2. разбить адрес на компоненты, чтобы понять, где идут лучше продажи;
  3. дополнить адрес недостающей информацией, чтобы оптимизировать план работы курьеров;
  4. стандартизовать адреса, чтобы найти дублирующие записи одного и того же клиента;
  5. актуализировать и привести адреса к формату справочника, чтобы пройти проверки регуляторов.

Задача автоматического разбора почтовых адресов кажется довольно простой на первый взгляд — бери да сопоставляй адресному справочнику (например, ФИАСу) слова из входной строки. Но все, кто за неё берутся, утопают в большом количестве особенностей адресов…

Что мы знаем об адресах


Для начала представимся. Мы занимаемся задачей автоматизированного разбора адресов более 9 лет. За это время мы работали как с крупными компаниями, так и с небольшими фирмами. Мы накопили большую выборку адресов, описывающую формат данных заказчиков, чтобы хорошо понимать, как наши идеи влияют на качество обработки адресов в реальных системах.

В течение последнего года мы разрабатывали новую версию алгоритма (мы его называем адресным фильтром) с целью поставить точку в алгоритме разбора адресов.

Определяем задачу


Мы знаем три способа, как получить актуальные корректные адреса:
  1. получить хороший адрес от клиента сразу (например, при помощи подсказок по адресам);
  2. нанять операторов для ручного разбора адресов;
  3. автоматически разобрать данные.

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

Мы рекомендуем использовать синтезированный вариант из 2-го и 3-го пунктов:
  1. разобрать адреса автоматически с указанием показателя качества разбора адреса;
  2. адреса с хорошим показателем качества — отправить в бизнес-процессы, а с плохим — отдать на разбор операторам.

Так вы получите большой процент разобранных адресов за приемлемую сумму.

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

Готовим адреса


Для выбора алгоритма надо проанализировать результаты обработки некоторого объёма адресов разными алгоритмами. Кажется логичным взять часть адресов из реальных данных и дополнить их адресами с косметическими исправлениями, чтобы проверить, какой процент адресов с ошибками и опечатками будет распознан правильно.

Заблуждение первое: автоматически исправлять любые опечатки — хорошо


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

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

Наши исследования показывают, что в исходных адресах корпоративных систем редко встречается более 2% адресов с опечатками — среди всех наших клиентов процент таких систем меньше 5%. При этом большинство опечаток (около 95% от всех опечаток) носят системный характер, то есть это либо часто встречающаяся опечатка, например, Масква, либо исправление вида ул. 3ая Мытищинская >>> ул. 3-я Мытищинская или ул. Толстой >>> ул. Толстого. Эти опечатки можно описать конечным набором правил, который позволит их исправить.

Чем плохо исправление опечаток в общем случае? Производя исправление всех опечаток по n-граммам, расстоянию Левенштейна и т.п., алгоритм пытается притянуть адрес к справочнику с большим шансом получить совсем не то, что подразумевалось в исходном адресе. Кроме того, в исходном адресе может содержаться дополнительная информация, отсутствующая в адресном справочнике: название компании, бизнес-центра, как пройти от метро и т.д. В алгоритме с исправлением опечаток эти дополнения с большой долей вероятности будут восприняты как нормальный компонент адреса.

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

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

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

Заблуждение второе: процент хорошо разобранных адресов — основной критерий выбора фильтра (кроме стоимости, конечно)


Любой алгоритм автоматического разбора адресов на вход принимает адрес, а на выходе — выдаёт его же в стандартизированном виде. Обычно он умеет возвращать признак, показывающий, уверен алгоритм в разборе адреса или нет. Такой признак обычно называют кодом качества.

Адреса наших заказчиков с хорошим кодом качества разбора автоматически уходят в бизнес-процессы, а с плохим кодом качества — отправляются на ручной разбор. Чем больше процент адресов с хорошим кодом качества, тем больше заказчик экономит на процессе ручной обработки адресов.

Таким образом, основным критерием выбора алгоритма становится процент адресов с хорошим кодом качества.

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

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

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

На какие адреса обратить внимание


Сравнивая алгоритмы адресных фильтров, смотрите не только на процент адресов с хорошим кодом качества, но и на процент неправильно разобранных адресов с хорошим кодом качества. Лучше всего подготовить выборку из своих адресов, включающую случаи написания адресов повышенной опасности, а именно:
  • Адреса с опечатками или неправильным указанием компонента адреса (например, 3ая Мытищинская вместо 3-я Мытищинская).
  • Неоднозначные адреса, для которых только по исходным данным нельзя однозначно определить, о чём идёт речь, в том числе при анализе оператором. Например, пропущенные или некорректно указанные компоненты адреса: Москва, Тверская может подразумевать как Тверскую площадь, так и улицу.
  • Ошибку в указании типа адресного компонента. По нашим данным, около 5% адресов заказчиков содержат те или иные ошибки указания типа компонента адреса: вместо «посёлок городского типа» пишут «деревня», вместо «тупик» пишут «переулок» и так далее.
  • Ошибку в указании самого компонента. Чаще всего неправильно указывают:
    • Район, в котором находится населённый пункт, если он находится на границе двух районов. Например, в адресе Московская область, Дмитровский район, пгт Запрудня некорректно указан район, правильно — Талдомский.
    • Регион, в котором находится объект. Особенно часто это встречается с адресами Москвы и Санкт-Петербурга, например:
      • Ленинградская область, Санкт-Петербург, Фонтанка
      • Московская область, Москва, ул. Расторгуева
      • Московская область, Зеленоград, к 3113
  • Ошибку в имени, звании или другое распространённое заблуждение. Например, вместо улицы Алексея Толстого пишут Льва Толстого, или вместо маршала Жукова пишут генерала Жукова. Иногда также дают какое-то устаревшее или локальное, известное только местным жителям, наименование.
  • Дублирование слов в исходной строке. Иногда после многих преобразований и переходов из системы в систему образуются адреса с дублирующими компонентами. Например, у одной конференции был адрес: Москва, Москва, Москва, Москва, Москва, Ленинградский проспект д. 39 стр. 79. Очевидно, что здесь слово Москва написано несколько раз по ошибке и алгоритм может не принимать во внимание дубли из исходного адреса. Но можно ли удалять дубли всегда? Другой пример: Сахалинская, Южно-Сахалинск, Сахалинская подразумевает адрес Сахалинская область, Южно-Сахалинск, Сахалинская улица. Хороший алгоритм должен находить дубли только если они являются действительно дублями и не уводить адрес в неправильный разбор.
  • Мусор или дополнительную информацию в исходных данных. Обычно это либо ФИО, либо дополнительная информация про само здание и про то, как к нему пройти. Например: Иванов Иван, Пирогова 20 к 1 общ 8/1 ком 313, Новосибирск, НСО или Москва, Турчанинов, БЦ Крымский мост, дом 6 стр 2, 2 минуты от метро и хорошая зарплата. В таких случаях все компоненты входной строки, которые не являются адресными компонентами или часто встречаемой дополнительной адресной информацией (например, метро или районы города), должны быть вынесены на анализ оператору, так как могут влиять на качество разбора адреса.
  • Устаревшие адреса. Это адреса, которые теперь другие: бывает, улицы переименовывают, бывает, что они переезжают в другой населённый пункт, объединяются и т.д. Когда есть два адреса: Самара 13 проезд и Самара Георгия Ратнера, то неплохо бы понимать, что это один и тот же адрес. Алгоритм должен уметь актуализировать адрес и ставить ему хороший код качества только в случае актуализации.


Сравниваем алгоритмы


Когда мы подготовили тестовую выборку, дальше всё просто. Обрабатываем адреса различными алгоритмами и сравниваем их по критериям:
  1. Процент разбора хороших адресов (то есть адреса без мусора, неоднозначностей и опечаток). Алгоритм должен уметь правильно разбирать хорошие адреса с хорошим кодом качества.
  2. Процент разбора плохих адресов. Алгоритм должен уметь максимально хорошо разбирать плохие адреса, то есть, если адрес плохой, но может быть хорошо разобран с хорошим кодом качества, то алгоритм должен уметь это делать.
  3. Процент адресов с обратной ошибкой. Алгоритм должен содержать минимальную обратную ошибку, то есть не проставлять адресам с некорректным разбором хороший код качества. Нам кажется это самым важным пунктом из всех.
  4. Наличие дополнительных свойств стандартизированного адреса. Алгоритм должен предоставлять удобные рычаги для анализа и работы с адресами с плохими кодами качества. При этом работа с инструментами должна быть простой и понятной.


Выводы


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

P.S.: В течение месяца мы установим новую версию адресного фильтра, про которую шла речь в начале статьи, на dadata.ru. Зарегистрируйтесь, чтобы быть в курсе и оказаться в числе первых исследователей нового алгоритма.

Спасибо chipQA за помощь при подготовке статьи.
Автор: @AlexGechis
HumanFactorLabs
рейтинг 106,11
Качество и интеграция клиентских данных

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

  • +2
    Классный сервис. Пользуемся и всем довольны!
  • +2
    Чем плохо исправление опечаток в общем случае? Производя исправление всех опечаток по n-граммам, расстоянию Левенштейна и т.п., алгоритм пытается притянуть адрес к справочнику с большим шансом получить совсем не то, что подразумевалось в исходном адресе.


    А можно примеры? Хотя-бы парочку… По-моему опыту, справочник (кладр или фиас) + n-граммы отлично исправляют опечатки, не изменяя адрес.

    Адреса с опечатками или неправильным указанием компонента адреса (например, 3ая Мытищинская вместо 3-я Мытищинская).


    Это решается элементарно 1-й регуляркой. Сам столкнулся с подобным, мелкая проблема.

    Неоднозначные адреса, для которых только по исходным данным нельзя однозначно определить, о чём идёт речь, в том числе при анализе оператором. Например, пропущенные или некорректно указанные компоненты адреса: Москва, Тверская может подразумевать как Тверскую площадь, так и улицу.


    Так что-же должно быть в данном случае, улица или площадь? )

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


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

    Устаревшие адреса. Это адреса, которые теперь другие: бывает, улицы переименовывают, бывает, что они переезжают в другой населённый пункт, объединяются и т.д.


    Тоже работа справочника, верно? Без справочника (стороннего или своего) подобные случаи решить не получится никак.

    В целом — отличный пост. Не хватает технических деталей, но и так очень хорошо. Спасибо.
    • 0
      А можно примеры? Хотя-бы парочку… По-моему опыту, справочник (кладр или фиас) + n-граммы отлично исправляют опечатки, не изменяя адрес.

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

      Так что-же должно быть в данном случае, улица или площадь? )

      Мы возвращаем два варианта и говорим, что невозможно однозначно определить адрес.

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

      Справочники то справляются, а вот алгоритмы не всегда и притягивают адрес к другому н.п. но с таким же типом.

      Тоже работа справочника, верно? Без справочника (стороннего или своего) подобные случаи решить не получится никак.

      Верно, но некоторые алгоритмы ставят устаревшим адресам слабый приоритет и разбирают адрес не туда.

      В целом — отличный пост. Не хватает технических деталей, но и так очень хорошо. Спасибо.

      :)
      • 0
        Тут у всех свои пути, и, вероятнее всего, для вашей тестовой выборки алгоритм действительно работает. Мы подразумевали не конкретные примеры, а статистику в целом. Под пример можно заточиться, но это не гарантирует, что ошибка не вылезет в другом месте. Мы сравнивали алгоритмы с исправлением опечаток с теми же алгоритмами, но без них, на выборках примерно в 20млн адресов, и всегда получали бОльший процент обратной ошибки в алгоритмах с исправлением опечаток.


        Эмм… Политик? Так много сказал, а по факту не ответил). Если есть такая статистика — дайте пару примеров, интересно-же…

        Мы возвращаем два варианта и говорим, что невозможно однозначно определить адрес.


        А в веб-версии один результат — улица. Почему?)

        Справочники то справляются, а вот алгоритмы не всегда и притягивают адрес к другому н.п. но с таким же типом.


        Честно — звучит не правдоподобно. В любом алгоритме название должно иметь выше приоритет, нежели тип объекта.

        Верно, но некоторые алгоритмы ставят устаревшим адресам слабый приоритет и разбирают адрес не туда.


        Примеры? Чтобы свой алгоритм протестить ;).
        • 0
          А в веб-версии один результат — улица. Почему?)

          В веб версии этот функционал сейчас отсутствует, мы возвращаем наиболее вероятный вариант и ставим признак «Проверьте корректность распознанного значения».

          В любом алгоритме название должно иметь выше приоритет, нежели тип объекта.

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

          Примеры тестов, к сожалению, не имею права публиковать:(
          • 0
            А конкурентов назвать, с кем сравнивали, имеете право?) Я знаю ahunter.ru и addr.rco.ru — оба отвратительны по качеству работы. На простых адресах еще куда ни шло, а чуть сложнее и все, выдают вообще левое (. Какие-то еще существуют?
            • 0
              В конкурентах у нас каждый программист, кто пишет свою реализацию адресного фильтра. Мы уже устали их считать :) Думаем о том, чтобы проводить соревнования по написанию адресных фильтров, аналогично написанию архиваторов.
              • +1
                Я бы поучаствовал). Вообще, не считаю всех конкурентами, скорее сторонниками. Чем больше реализаций и их обсуждений — тем лучше всем, в том числе и коммерческим системам: повышается качество, подбираются сотрудники с нужным опытом и пр.
                • 0
                  Запишем вас :)
        • 0
          С примерами я могу помочь, поскольку тоже этим занимался. :)

          Например, юзер может ввести:
          — московская о, пушкино, пушкина 15-3-123
          или даже еще проще
          — пушкино пушкина 15-4-123

          1. Пушкина — это улица или ошибка написания города? Если ошибка, то какая? Человек спутал о и а (пушкино/пушкина) или добавил случайно букву (пушкин/пушкина)?
          2. Пушкино — это город? Село? Поселок? В какой области?

          Или например,
          — пушкино, тургенева 18а

          Это именно «город Пушкино, ул. Тургенева, д18а» или «город Пушкино, мкр. Заветы Ильича, ул. Тургенева, д18а». Оба объекта находятся рядом, но имеют разный почтовый индекс и разные почтовые отделения. Местный, проживающий во втором адресе, как ни странно, скорее напишет первый адрес.

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

          Так что задача не тривиальна, а пример с пушкино выше поиск на n-gramm'ах даже близко не дает удовлетворительный результат.
          • 0
            Отличные примеры — мой алгоритм завалил тест на них))). Беглый осмотр показал проблему в справочниках, например алгоритм не нашел ни один населенный пункт в московской области с названием «пушкино» и улицей «пушкина». Буду разбираться, спасибо.

            Пушкина — это улица или ошибка написания города?

            Улица. Алгоритм распишу отдельным постом на хабре, как только доделаю подобные моменты и прикручу геокодер.

            Пушкино — это город? Село? Поселок? В какой области?

            Это выясняется в справочнике на основе остальных данных. Область — либо указанная, либо дефолтная (определяемая по ip, например).

            Местный, проживающий во втором адресе, как ни странно, скорее напишет первый адрес.

            Значит, в большинстве случаев, помочь ему не сможет никто).

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

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

            Так что задача не тривиальна

            Согласен, есть сложные моменты.

            а пример с пушкино выше поиск на n-gramm'ах даже близко не дает удовлетворительный результат

            Как не дает? Дает — исправляет ошибки в случае необходимости. n-граммы нужны для этого, а не для поиска в справочниках (хотя у меня и для этого тоже).
            • 0
              Пушкино, Пушкна есть — вот например: pushkino.choister.ru/kupit-kvartiru/ulitza-pushkina Но при этом если обратить внимание на сами объявления, то там вообще все замечательно:

              В одном рекламном блоке (по одному дому) идет сразу два адреса:
              Продается 1 комна…
              Московская область, Пушкино, Пушкина, 8
              1 комната…
              Продаю 1 комнатную квартиру в Пушкинском р-не п. Лесной, Пушкина, д.8

              То есть тоже вот пример — п. Лесной — в черте города, и его просто опускают при вводе.

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

              Или другой пример — Саратов. Если ошибиться и написать Сартов — то n-gramm найдет поселок (или село — не помню точно) Сартово — оно более релевантно этой ошибке.

              Вообще, в целом, я более-менее приемлимый результат получил только проводя последовательно несколько проверок:
              — точное совпадение начала типа объекта (г, р-н, обл)
              — точное совпадение по каждому значащему слову
              — совпадение по граничному n-gramm с правом одной ошибки
              — совпадение по n-gramm с правом одной ошибки

              Вот только при этом получается что-то приемлимое. что-то вроде такого

              — + 0.0000 init_parser Исходная строка: 'Спб, Марш. Жукова, 44 128'
              + 0.0003 clean_addr Очистка строки: 'спб, марш. жукова, 44 128'
              + 0.0003 split_addr Разбиение строки: [«спб», «марш.», «жукова», «44», «128»]
              + 0.0007 detect_sections Найдены секции: маршрут: [«спб», «марш.», «жукова»] дом: [«44», «128»], неизвестно: []
              + 0.0007 normalize_secti Финальные секции: маршрут: [«спб», «марш», «жукова»] дом: [«44», «128»], неизвестно: []
              + 0.0008 normalize_house Параметры house: [«44 (house)», «128 (kvartira)»]
              + 0.0008 replace_synonym Замена синонимов: [«санкт-петербург», «марш», «жукова»]
              + 0.0015 parse_federals Город федерального значения: [спб] -> [санкт-петербург] (исправлена ошибка написания)
              + 0.0015 parse_region Регион не найден
              + 0.0016 parse_area Район не найден
              + 0.0017 detect_route_el [«санкт-петербург (city)», «марш (street)», «жукова (street)»]
              + 0.0175 search_route Найдено 1 возможных варианта(ов)
              + 0.0179 profile_route Найден адрес 'г. Санкт-Петербург / проспект Маршала Жукова' (score=1.0)
              + 0.0180 parse_house Подготовлен запрос: '[«дом 44»]'
              + 0.0180 parse_house Формат квартиры — long: 'дом 44 квартира 128', short: 'д.44 кв.128'
              + 0.0347 validate_house Постройка найдена: 'дом 44 квартира 128'

              198262, Город Санкт-Петербург, Проспект Маршала Жукова, дом 44 квартира 128

              :)
              • 0
                Я знаю, что есть «Пушкино, Пушкина», у меня в справочнике не обнаружился — буду разбираться.

                По поводу n-gramm — все же не соглашусь. Они не исправляют ошибки эффективно, а при ранжировании результатов поиска могут серьезно ухудшить выборку.

                Тут важно уточнить — необходим правильный алгоритм ранжирования. n-граммы не должны влиять на ранжирование — их задача поправить возможные ошибки.

                Или другой пример — Саратов. Если ошибиться и написать Сартов — то n-gramm найдет поселок (или село — не помню точно) Сартово — оно более релевантно этой ошибке.

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

                Вообще, в целом, я более-менее приемлимый результат получил только проводя последовательно несколько проверок:
                — точное совпадение начала типа объекта (г, р-н, обл)
                — точное совпадение по каждому значащему слову
                — совпадение по граничному n-gramm с правом одной ошибки
                — совпадение по n-gramm с правом одной ошибки

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

                + 0.0015 parse_federals Город федерального значения: [спб] -> [санкт-петербург] (исправлена ошибка написания)
                + 0.0015 parse_region Регион не найден
                + 0.0016 parse_area Район не найден

                Тут не понял… Если город найден — почему не найден регион?)
                • 0
                  Так найден город федерального значения — выше него региона уже нет.
                  • 0
                    Да, верно, проверил. Комментарий писал не проверив в базе, сорри.
  • 0
    ошибся веткой...
  • 0
    А кладр использовать тупо для выбора адресов не вариант?
    • +1
      А вы попробуйте)
    • 0
      Сопоставить КЛАДР гранулированный корректный адрес, где указаны типы и наименования компонентов (улица, город,..), в основном, не большая проблема. Самое сложное — это разобрать адрес одной строкой до состояния гранулированного корректного.

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

Самое читаемое Разработка