Комментарии 22
К сожалению до любого ближайшего заведения 640 километров :)
адаптивный поиск для школоты?
Спасибо, интересная статья.
Можете уточнить:
1. какие фонетические группы у Вас получились для кириллицы?
2. Не совсем понятно как у вас расширяется (а еще интереснее как изначально создавался) словарь (places и places-index)
Можете уточнить:
1. какие фонетические группы у Вас получились для кириллицы?
2. Не совсем понятно как у вас расширяется (а еще интереснее как изначально создавался) словарь (places и places-index)
Базовый словарь places и places-index формируется на основании описаний заведений которые забиваются руками.
places хранит данные которые мы возвращаем в качестве результатов, по сути мы по нему не ищем.
places-index формируется на основании кириллическоего и/или английского названия заведения + набора синонимов.
Каждую фразу (вариант названия) перед загрузкой в индекс мы пытаемся расширить так:
1. Если фраза содержит '-' (например му-му), то создадим два варианта — без '-' и с заменой на пробел.
2. Если фраза содержала русские символы то дополнительно создадим тринслитерированный вариант
например для му-му получим:
му-му => { муму, му му, mumu, mu mu }
Для кириллицы мы объединили только (а, о, у) и (е, и)
places хранит данные которые мы возвращаем в качестве результатов, по сути мы по нему не ищем.
places-index формируется на основании кириллическоего и/или английского названия заведения + набора синонимов.
Каждую фразу (вариант названия) перед загрузкой в индекс мы пытаемся расширить так:
1. Если фраза содержит '-' (например му-му), то создадим два варианта — без '-' и с заменой на пробел.
2. Если фраза содержала русские символы то дополнительно создадим тринслитерированный вариант
например для му-му получим:
му-му => { муму, му му, mumu, mu mu }
Для кириллицы мы объединили только (а, о, у) и (е, и)
Сапожник без сапог?
Сапожник без сапог?
— мк.дональдс
— ничего не нашли :(
Собственно тупую транслитерацию он не понял
— ничего не нашли :(
Собственно тупую транслитерацию он не понял
Как-то не очень ясно, зачем было расписывать вещи вроде i << 1, которые любой компилятор сделает сам, если не замечена важнейшая особенность расстояния Левенштейна — достаточно хранить всего две, в данном случае, строки матрицы. Это даст выигрыш и по скорости и по памяти. Плюс код не потокобезопасен.
Да и если вы используете soundex, то какой смысл вообще в редакционном расстоянии?
Даже если есть реальная необходимость его использования, то сначала достаточно поискать точное вхождение soundex кода хеш-поиском, например, а потом если не повезет — уже подбирать варианты.
Это я все к чему. 8 миллисекунд на запрос к базе из 2.5к слов — это пугающий результат. Масштабируемость у вас линейная и всего 312к слов дадут секунду на запрос. К слову, за десятки миллисекунд мы отыскивали нечетким поиском подходящую ДНК секвенцию в базе на десятки гигабайт.
Да и если вы используете soundex, то какой смысл вообще в редакционном расстоянии?
Даже если есть реальная необходимость его использования, то сначала достаточно поискать точное вхождение soundex кода хеш-поиском, например, а потом если не повезет — уже подбирать варианты.
Это я все к чему. 8 миллисекунд на запрос к базе из 2.5к слов — это пугающий результат. Масштабируемость у вас линейная и всего 312к слов дадут секунду на запрос. К слову, за десятки миллисекунд мы отыскивали нечетким поиском подходящую ДНК секвенцию в базе на десятки гигабайт.
Да, конечно, соглашусь «i << 1» это перебор, это скорее привычка так писать.
И про две строки матрицы — тоже хороша идея, мы не делали токого рада оптимизаций, потому что пока производительность нас устраивает.
> Плюс код не потокобезопасен.
Зачем использовать этот объект в нескольких потоках? Вы сэкономите совсем немного памяти и получите расходы на синхронизацию.
> Да и если вы используете soundex, то…
Мы совсем его не используем.
> 8 миллисекунд на запрос к базе из 2.5к слов — это пугающий результат. Масштабируемость у вас линейная и всего 312к слов дадут секунду на запрос.
Да, вы правы, но в нашем случае словарь не будет линейно расти с ростом числа заведений в базе и врядли достигнет такого размера.
Если уж словарь большой сперва можно воспользоваться n-граммным индексом.
Ну и конечно в коде много мест которые можно пооптимизировать, наподобии двух строк матрицы про которые вы написали )
А каким индексом вы пользовались при поиске по базе ДНК? У вас все влезало в память или кешировали часть данных?
И про две строки матрицы — тоже хороша идея, мы не делали токого рада оптимизаций, потому что пока производительность нас устраивает.
> Плюс код не потокобезопасен.
Зачем использовать этот объект в нескольких потоках? Вы сэкономите совсем немного памяти и получите расходы на синхронизацию.
> Да и если вы используете soundex, то…
Мы совсем его не используем.
> 8 миллисекунд на запрос к базе из 2.5к слов — это пугающий результат. Масштабируемость у вас линейная и всего 312к слов дадут секунду на запрос.
Да, вы правы, но в нашем случае словарь не будет линейно расти с ростом числа заведений в базе и врядли достигнет такого размера.
Если уж словарь большой сперва можно воспользоваться n-граммным индексом.
Ну и конечно в коде много мест которые можно пооптимизировать, наподобии двух строк матрицы про которые вы написали )
А каким индексом вы пользовались при поиске по базе ДНК? У вас все влезало в память или кешировали часть данных?
Погуглите еще на тему daitch-mokotoff кода. Он применим и для русского языка.
По сути предлагаемого подхода сказать нечего. А вот по поводу самого сайта — интересная, красивая реализация. Мы нечто подобное делали тут (тогда еще не было геолокации на уровне браузера, поэтому мы определяли местоположение с помощью стартапа Wi2Geo). Только вот в проекте InTheCity была целая редколегия которая обзванивала все заведения и составляла их TTX в итоге получалось нечто вроде: inthecity.ru/#/places/restaurants/YAkitoriya_Arbatskaya
У Вас я обнаружил вместо TTX краткое описание (пример: edatuda.ru/#!chain/yakitoriya):
Демократичный и непретенциозный суши-бар
Якитория — один из ветеранов среди многочисленных московских суши-баров. Уже более десяти лет она не теряет своей популярности. И неудивительно, ведь соотношение цена-качество в Якитории порадует всех.
Честно говоря зная Якиторию я с таким описанием не могу согласиться. Демократичным (по крайней мере по ценам) его не назовешь средний чек не ниже чем в том же Тануки или Нияме. Но и «непретенциозным» тоже никак назвать нельзя потому что внутреннее обстановка там одна из самых удачных среди суши баров (чего только аквариумы с рыбой которую периодически вылавливают и уносят на кухню) стоят и очки которые выдают для просмотра 3D меню.
Может стоит дать пользователям предлагать свои описания заведениям? А так же было бы не плохо дать возможность задавать пользовательские: теги, рейтинги и отзывы не фейсбуке, а в ваш движок что бы потом можно было выводить как на афишах/меню.ру.
У Вас я обнаружил вместо TTX краткое описание (пример: edatuda.ru/#!chain/yakitoriya):
Демократичный и непретенциозный суши-бар
Якитория — один из ветеранов среди многочисленных московских суши-баров. Уже более десяти лет она не теряет своей популярности. И неудивительно, ведь соотношение цена-качество в Якитории порадует всех.
Честно говоря зная Якиторию я с таким описанием не могу согласиться. Демократичным (по крайней мере по ценам) его не назовешь средний чек не ниже чем в том же Тануки или Нияме. Но и «непретенциозным» тоже никак назвать нельзя потому что внутреннее обстановка там одна из самых удачных среди суши баров (чего только аквариумы с рыбой которую периодически вылавливают и уносят на кухню) стоят и очки которые выдают для просмотра 3D меню.
Может стоит дать пользователям предлагать свои описания заведениям? А так же было бы не плохо дать возможность задавать пользовательские: теги, рейтинги и отзывы не фейсбуке, а в ваш движок что бы потом можно было выводить как на афишах/меню.ру.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реализация нечеткого поиска