Pull to refresh

Comments 11

Шардирование и реплики реализуете через ElasticSearch?
Насколько я помню из старых статей у вас был «чистый» Lucene, который этого не умеет.

Так же интересует вопрос, поиска по кластеру. При склеивании фасетной выдачи с разных кластеров появляется проблема точности, описанная здесь: ссылка
Встречались ли с такой проблемой на практике?
Да, мы все так же используем «чистый» Lucene, для репликации используется lucene-replicator. Шардирование сейчас реализовано по сущностям — под каждую сущность свой индекс (резюме, вакансии, работодатели и тд), так же есть шардирование в индексе резюме по user id. И это все разруливается как раз на мета поиске.

По второму вопросу: c такой проблемой не встречались

Aliksbright прекрасная статья, а можете сказать — все эти алгоритмы — на каком языке написаны? Java/C++/Go? (вот конкретно эти, что в статье). Спасибо.
Многое из описанного уже реализовано в поисковых движках, которые написаны на разных языках: Lucene на Java, Sphinx на C++. Так же есть порт Lucene на C# под названием Lucene.Net.

Что касается наших доработок в hh, все пишется на java, тк у нас используется lucene.
Если я ищу в яндекс-маркете «сотовый телефон», то меня автоматически перекидывает в категорию «Мобильные телефоны».
Если я указываю в поиске на хедхантере «Кипр», то ваша система автоматически определяет, что скорее всего интересуют вакансии на Кипре. Происходит очистка поисковой строки и фильтрация по локации Кипр.
Однако, во многих заграничных вакансиях не указывают заграничную локацию, эти вакансии чаще размещают в Москве/Питере, а в названии и/или описании вакансии добавляют «релокация на Кипр». К сожалению недавно такие вакансии стало не найти.
По запросу «Кипр» — 52 вакансии.
По запросу «лимассол or limassol or никоссия or nicosia or ларнака or larnaka» — 81
По запросу «NOT кипр» — 0, потому что парсинг «not/or/and» у вас происходит уже после автоматического изменения региона на «Кипр» и в строке поиска остаётся только «NOT».
Те же самые проблемы с запросом «Германия», только я не знаю там всех городов, чтобы обойти вашу автозамену.

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

Что касается самого кейса с Not — сейчас автозамена применяется до языка запроса, поэтому так работает. Подумаем как сделать лучше, спасибо!
Познакомившись с Lucene на одном проекте, я столкнулся с такой особенностью: score не нормирован. То есть среди вариантов реализации подсчета совпадения нет такой, которая возвращает значение, приводимое к проценту. В документации написано, мол не пытайтесь этого сделать))) Тогда я не уделил этому особого внимания, а сейчас вспомнил. Не подскажите, в чем проблема?
А зачем приводить score к проценту?
Например, если нужно отобразить эту оценку пользователю. Мол, вы ввели фразу «Мама мыла мылом Милу», а вот в источнике есть «Мама мыла раму», процент совпадения — 50%. Трактовать ненормализованное значение сложнее.
Вообще в Lucene формулы ранжирования предназначены именно для задачи ранжирования, и поэтому кажется что эту задачу они не покроют. Но, всегда можно реализовать свою формулу сделав свою реализацию от класса Similarity :)
Sign up to leave a comment.