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


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

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


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

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


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

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


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

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


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

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

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

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

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

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

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

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

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

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

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


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

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


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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как не дает? Дает — исправляет ошибки в случае необходимости. n-граммы нужны для этого, а не для поиска в справочниках (хотя у меня и для этого тоже).
Пушкино, Пушкна есть — вот например: 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

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

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

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

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

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

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

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

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

Тут не понял… Если город найден — почему не найден регион?)
Так найден город федерального значения — выше него региона уже нет.
Да, верно, проверил. Комментарий писал не проверив в базе, сорри.
Сопоставить КЛАДР гранулированный корректный адрес, где указаны типы и наименования компонентов (улица, город,..), в основном, не большая проблема. Самое сложное — это разобрать адрес одной строкой до состояния гранулированного корректного.
Only those users with full accounts are able to leave comments. Log in, please.