Комментарии 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'ах даже близко не дает удовлетворительный результат.
Например, юзер может ввести:
— московская о, пушкино, пушкина 15-3-123
или даже еще проще
— пушкино пушкина 15-4-123
1. Пушкина — это улица или ошибка написания города? Если ошибка, то какая? Человек спутал о и а (пушкино/пушкина) или добавил случайно букву (пушкин/пушкина)?
2. Пушкино — это город? Село? Поселок? В какой области?
Или например,
— пушкино, тургенева 18а
Это именно «город Пушкино, ул. Тургенева, д18а» или «город Пушкино, мкр. Заветы Ильича, ул. Тургенева, д18а». Оба объекта находятся рядом, но имеют разный почтовый индекс и разные почтовые отделения. Местный, проживающий во втором адресе, как ни странно, скорее напишет первый адрес.
В этом кейсе ни приоритет, ни тип не сработают. Надо смотреть, какой номер дома завел клиент, и исходя из этого уже определять какой адрес он ввел. Но и этот способ не позволяет проверить достоверно — что же хочет клиент, если он ввел номер дома, например, д3.
Так что задача не тривиальна, а пример с пушкино выше поиск на n-gramm'ах даже близко не дает удовлетворительный результат.
Отличные примеры — мой алгоритм завалил тест на них))). Беглый осмотр показал проблему в справочниках, например алгоритм не нашел ни один населенный пункт в московской области с названием «пушкино» и улицей «пушкина». Буду разбираться, спасибо.
Улица. Алгоритм распишу отдельным постом на хабре, как только доделаю подобные моменты и прикручу геокодер.
Это выясняется в справочнике на основе остальных данных. Область — либо указанная, либо дефолтная (определяемая по ip, например).
Значит, в большинстве случаев, помочь ему не сможет никто).
По моему опыту — это плохая практика. Нельзя полагаться на номера домов.
Согласен, есть сложные моменты.
Как не дает? Дает — исправляет ошибки в случае необходимости. n-граммы нужны для этого, а не для поиска в справочниках (хотя у меня и для этого тоже).
Пушкина — это улица или ошибка написания города?
Улица. Алгоритм распишу отдельным постом на хабре, как только доделаю подобные моменты и прикручу геокодер.
Пушкино — это город? Село? Поселок? В какой области?
Это выясняется в справочнике на основе остальных данных. Область — либо указанная, либо дефолтная (определяемая по 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
:)
В одном рекламном блоке (по одному дому) идет сразу два адреса:
Продается 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-граммы не должны влиять на ранжирование — их задача поправить возможные ошибки.
Ну тут все просто. Если нет других данных — алгоритм не может определить, что это Саратов, соответственно выбирает максимально подходящий. Если есть доп.параметры, которые позволяют идентифицировать Саратов — это он и есть…
Надо смотреть на реализацию, но по мне — это не правильный алгоритм. Он очень зависим от исходной строки. Например, если будет указано «московская обл.» — все хорошо, а если «московская» — все плохо… Возможно ошибаюсь, конечно-же.
Тут не понял… Если город найден — почему не найден регион?)
По поводу n-gramm — все же не соглашусь. Они не исправляют ошибки эффективно, а при ранжировании результатов поиска могут серьезно ухудшить выборку.
Тут важно уточнить — необходим правильный алгоритм ранжирования. n-граммы не должны влиять на ранжирование — их задача поправить возможные ошибки.
Или другой пример — Саратов. Если ошибиться и написать Сартов — то n-gramm найдет поселок (или село — не помню точно) Сартово — оно более релевантно этой ошибке.
Ну тут все просто. Если нет других данных — алгоритм не может определить, что это Саратов, соответственно выбирает максимально подходящий. Если есть доп.параметры, которые позволяют идентифицировать Саратов — это он и есть…
Вообще, в целом, я более-менее приемлимый результат получил только проводя последовательно несколько проверок:
— точное совпадение начала типа объекта (г, р-н, обл)
— точное совпадение по каждому значащему слову
— совпадение по граничному n-gramm с правом одной ошибки
— совпадение по n-gramm с правом одной ошибки
Надо смотреть на реализацию, но по мне — это не правильный алгоритм. Он очень зависим от исходной строки. Например, если будет указано «московская обл.» — все хорошо, а если «московская» — все плохо… Возможно ошибаюсь, конечно-же.
+ 0.0015 parse_federals Город федерального значения: [спб] -> [санкт-петербург] (исправлена ошибка написания)
+ 0.0015 parse_region Регион не найден
+ 0.0016 parse_area Район не найден
Тут не понял… Если город найден — почему не найден регион?)
А кладр использовать тупо для выбора адресов не вариант?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как выбрать алгоритм для адресного фильтра