Новый взгляд на поиск по сайту

[@RoboSloNE]

После опыта с Alfred (Mac) сразу обратил внимание на отсутствие Fuzzy Search.
А вообще выглядит очень круто!

[@Cher]

Спасибо )
Fuzzy можно настроить, учесть синонимы, ошибки. Мы в тестовой выдаче сделали морфологию автоматом, а ошибки в написании решили выводить подсказками снизу поисковой строки. Попробуйте набрать mikael, предложат michael

[@Cher]

у нас вся семантика строится на параметрах которые уже есть в вашей базе, и эти параметры должны быть четко определены. Даже когда мы расширяем это понятие с помощью данных из DbPedia мы должны отталкиваться от чего-то. Например, у вас базе есть аттрибут — город производства товара: Гуанчжоу. Мы можем расширить его до Китай, Южный Китай, Кантон
Задача каталогизации новостей это другая сложная задача )

[@Cher]

я думаю задача про новости ближе к тому что пилит abbyy www.abbyy.ru/science/technologies/business/compreno/
Словари синонимов — да, поддерживаются, но мы его пока не загрузили. Хороший пример с пурпурным диваном.
безбрежный|необозримый|необъятный пурпурный диван ))

[@ha2bj]

если длина > 2000мм

— ok ;)

[@ha2bj]

А можно реальный пример article1: tag1, tag2, tag3 (теги конечно лежат в базе)

[@Cher]

так, а какой пример?

[@ha2bj]

структура такая:

tags: id, name
articles: id, name, body
articles_tags: article_id, tag_id

напишите код агента?

[@Cher]

прошу в личку, все настроим, случай на первый взгляд не сложный )

[@sphinks]

Супер!
Возникли пара вопросов:
1. Использование Freebase. Расскажите это автоматически при необходимости может быть интегрировано в поисковую выдачу по сайту для посетителя? Как я понял Freebase сама по себе просто ссылается на статьи википедии, то есть если я ищу ОС Windows, то в выдачу приедет, ровно то что уже находится в википедии? В чем преимущество Freebase не очень понял — в структурированном представлении полей википедии и в связях между объектами?

2. Получится ли использовать ваш сервис для поиска без сохранения в БД (например, если есть api для получения информации и нет желания осуществлять предварительно сохранение в БД эти данных, сразу получится скормить вашему сервису)?

3. Предположительные тарифы? Сейчас бесплатно, потом будет какая то бесплатная версия или все станет платным?

[@Cher]

1. Freebase пока только в ближайших планах и еще не выпущено в продакшн. Freebase не ссылается на википедию только частично, например смотрите что есть во Freebase по Мадонне:
www.freebase.com/m/01vs_v8
как видно description просто взят из википедии, однако есть и куча других полей типа /music/artist/album: Like a Virgin, True Blue

Если вы знаете что у вас в базе в таблице Artists в поле Titile лежит имя исполнителя, вы можете прописать запрос на получение дополнительных данных, например — дайте мне все альбомы мадонны. Далее можно решить что с этими данными делать, можно их добавить в выдачу, например человек ищет МАДОННА, вы в сниппете покажете альбомы мадонны.

Можно спросить Freebase: дай мне псевдонимы мадонны (/common/topic/alias), и добавить синонимы: Louise Ciccone, Madonna Ciccone Ritchie… и в вас заработает поиск по запросу LOUISE CHICCONE

2. API пока есть только на выдачу, загрузка пока через базу. API на добавление документов в ближайших планах
3. Мы пока думаем как монетизироваться. Но если мы подключили кого-то бесплатно, платным оно не станет

[@Aesma]

Как вы кстати.

Имеется проект, на несколько десятков тысяч нод (на Друпале). Посетители часто пользуются поиском (пока что спасаемся с помощью Solr). Однако люди как раз чаще задают запросы человеческим языком, а не по параметрам забитым в базу.

Хотел глянуть вашу демку для Друпала, а у вас там ажамбех пашамбе эшельбе шайтанама — Apache 2 Test Page powered by CentOS. Печально.

[@Cher]

демки еще не успели настроить все,
наш основной сайт indexisto.com тоже на drupal, и простой поиск по тэгам типа korean pop там работает

[@Moor]

Пытаюсь понять логику системы.

Вводим «DE» — видим DeBarge, Deodato и еще что-то.
Вводим «DEP» — видим только юзеров
И только после «DEPE» появляется Depeche Mode.

Ни в коем случае не наезд, конечно :) Но как оно работает? В смысле какой приоритет релевантности?

[@Cher]

ага вижу, это неправильно, на DEP ерунда.
Сразу не отвечу. Скорее всего дело в обработке запроса и индексированных документов. Отрабатывает морфология и стоп слова (отбрасываются артикли и прочее). Кто-то что-то привел к нормальной форм, потом что-то отбросил. Копаем.

[@merc]

а чем вы лучше swiftype?

[@Cher]

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

[@Abcd_Efgh]

А скажите, JJAMZ из проигрывателя на Myspace у вас специально нет? :-)

[@Cher]

не слышал такого )

[@pav]

Из административного интерфейса есть возможность влиять на бустинг поисковых запросов/полей по которым осуществляется поиск? То есть в конечном итоге влиять на релевантность. Например мне нужно чтобы релевантность зависала от временной актуальности искомой сущности в solr я бы воспользовался стандартным {!boost b=recip(ms(NOW, поле_даты),3.16e-11,1,1)} тем самым более новые сущности имели бы больший score. В общем как обстоят с этим дела у вас.

[@Cher]

У нас под капотом elastic search который имхо даже гибче SOLR в плане бустов.
В простейшем случае можно обернуть основной запрос в custom_score запрос, где можно вставить JS и сделать любой буст:

{
  "query": {
    "custom_score": {
      "query": { ...the main query... },
      "script": "_score * (doc['поле даты'].value)"
    }
  }
}

такой запрос пишется в «виджете», например у нас на сайте блок Artists это отдельный виджет, со своим запросом. А блок Users — другой виджет со своим запросом. В Users логично сделать буст по какому-нибудь параметру типа карма.

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

Кстати здесь еще плюс в том что лишнее не торчит наружу, то есть запрос на результаты поиска выглядит вот так:
gate.indexisto.com/51d587807d3e114babf91418/edit?q=hi&items=hdfkl;JrEXH;
где 51d587807d3e114babf91418 номер индекса, q — введеные символы, items=hdfkl;JrEXH; — id виджетов.
а параметры передаются в запрос написанный в виджете (запрос лежит на сервере) вот так:

{
  "query":{
    "multi_match":{
      "query":"${q}",
      "type" : "phrase_prefix",
      "use_dis_max" : true,
      "fields":[
        "title"
      ]
    }
  },

в SOLR многовато можно в качестве GET параметров передать, могут понаписать что-нибудь и положить поиск, так или иначе надо что-то перед ним ставить.

[@pav]

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

[@Abyasov]

Решение интересное. Сколько будет стоить в перспективе уже прикидывали?

[@Cher]

мы пока не знаем, есть мысли что поиск должен окупать себя сам и еще приносить прибыль владельцу контента (привет гугл). Хотя для интернет магазинов это не вариант. Думаем.

[@antonydevanchi]

Читал пост со слезами на глазах. Просто рыдал. У меня истерика.
Ваши бы слова да клиентам в уши, но клиентам надо «Поиск» и «Расширенный поиск» и что бы поля были в 99px и не больше.

[@Cher]

умные клиенты очень хорошо внимают когда им говоришь цифры повышения просмотра страниц после внедрения такого поиска (читай больше показов баннеров, больше $). Не говоря уже о том что убогие проекты постепенно вытесняются сделанными с душой

[@AmirL]

А что будет с теми, кто получит сейчас бесплатный доступ, после того как определитесь с политикой оплаты?

[@Cher]

они останутся бесплатными, это обычная практика