Comments 30
После опыта с Alfred (Mac) сразу обратил внимание на отсутствие Fuzzy Search.
А вообще выглядит очень круто!
А вообще выглядит очень круто!
у нас вся семантика строится на параметрах которые уже есть в вашей базе, и эти параметры должны быть четко определены. Даже когда мы расширяем это понятие с помощью данных из DbPedia мы должны отталкиваться от чего-то. Например, у вас базе есть аттрибут — город производства товара: Гуанчжоу. Мы можем расширить его до Китай, Южный Китай, Кантон
Задача каталогизации новостей это другая сложная задача )
Задача каталогизации новостей это другая сложная задача )
я думаю задача про новости ближе к тому что пилит abbyy www.abbyy.ru/science/technologies/business/compreno/
Словари синонимов — да, поддерживаются, но мы его пока не загрузили. Хороший пример с пурпурным диваном.
безбрежный|необозримый|необъятный пурпурный диван ))
Словари синонимов — да, поддерживаются, но мы его пока не загрузили. Хороший пример с пурпурным диваном.
безбрежный|необозримый|необъятный пурпурный диван ))
если длина > 2000мм— ok ;)
А можно реальный пример
article1: tag1, tag2, tag3 (теги конечно лежат в базе)
Супер!
Возникли пара вопросов:
1. Использование Freebase. Расскажите это автоматически при необходимости может быть интегрировано в поисковую выдачу по сайту для посетителя? Как я понял Freebase сама по себе просто ссылается на статьи википедии, то есть если я ищу ОС Windows, то в выдачу приедет, ровно то что уже находится в википедии? В чем преимущество Freebase не очень понял — в структурированном представлении полей википедии и в связях между объектами?
2. Получится ли использовать ваш сервис для поиска без сохранения в БД (например, если есть api для получения информации и нет желания осуществлять предварительно сохранение в БД эти данных, сразу получится скормить вашему сервису)?
3. Предположительные тарифы? Сейчас бесплатно, потом будет какая то бесплатная версия или все станет платным?
Возникли пара вопросов:
1. Использование Freebase. Расскажите это автоматически при необходимости может быть интегрировано в поисковую выдачу по сайту для посетителя? Как я понял Freebase сама по себе просто ссылается на статьи википедии, то есть если я ищу ОС Windows, то в выдачу приедет, ровно то что уже находится в википедии? В чем преимущество Freebase не очень понял — в структурированном представлении полей википедии и в связях между объектами?
2. Получится ли использовать ваш сервис для поиска без сохранения в БД (например, если есть api для получения информации и нет желания осуществлять предварительно сохранение в БД эти данных, сразу получится скормить вашему сервису)?
3. Предположительные тарифы? Сейчас бесплатно, потом будет какая то бесплатная версия или все станет платным?
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. Мы пока думаем как монетизироваться. Но если мы подключили кого-то бесплатно, платным оно не станет
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. Мы пока думаем как монетизироваться. Но если мы подключили кого-то бесплатно, платным оно не станет
Как вы кстати.
Имеется проект, на несколько десятков тысяч нод (на Друпале). Посетители часто пользуются поиском (пока что спасаемся с помощью Solr). Однако люди как раз чаще задают запросы человеческим языком, а не по параметрам забитым в базу.
Хотел глянуть вашу демку для Друпала, а у вас там ажамбех пашамбе эшельбе шайтанама — Apache 2 Test Page powered by CentOS. Печально.
Имеется проект, на несколько десятков тысяч нод (на Друпале). Посетители часто пользуются поиском (пока что спасаемся с помощью Solr). Однако люди как раз чаще задают запросы человеческим языком, а не по параметрам забитым в базу.
Хотел глянуть вашу демку для Друпала, а у вас там ажамбех пашамбе эшельбе шайтанама — Apache 2 Test Page powered by CentOS. Печально.
Пытаюсь понять логику системы.
Вводим «DE» — видим DeBarge, Deodato и еще что-то.
Вводим «DEP» — видим только юзеров
И только после «DEPE» появляется Depeche Mode.
Ни в коем случае не наезд, конечно :) Но как оно работает? В смысле какой приоритет релевантности?
Вводим «DE» — видим DeBarge, Deodato и еще что-то.
Вводим «DEP» — видим только юзеров
И только после «DEPE» появляется Depeche Mode.
Ни в коем случае не наезд, конечно :) Но как оно работает? В смысле какой приоритет релевантности?
а чем вы лучше swiftype?
ну мы нацелены на более структурированную исходную информацию из базы данных, она как правило содержит больше данных по релевантности. Например, на форуме очень логично было бы учесть в выдаче количество комментариев к топику, грубо говоря отсортировать выдачу по количеству комментариев. Swiftype так не сможет
А скажите, JJAMZ из проигрывателя на Myspace у вас специально нет? :-)
Из административного интерфейса есть возможность влиять на бустинг поисковых запросов/полей по которым осуществляется поиск? То есть в конечном итоге влиять на релевантность. Например мне нужно чтобы релевантность зависала от временной актуальности искомой сущности в solr я бы воспользовался стандартным {!boost b=recip(ms(NOW, поле_даты),3.16e-11,1,1)} тем самым более новые сущности имели бы больший score. В общем как обстоят с этим дела у вас.
У нас под капотом elastic search который имхо даже гибче SOLR в плане бустов.
В простейшем случае можно обернуть основной запрос в custom_score запрос, где можно вставить JS и сделать любой буст:
такой запрос пишется в «виджете», например у нас на сайте блок Artists это отдельный виджет, со своим запросом. А блок Users — другой виджет со своим запросом. В Users логично сделать буст по какому-нибудь параметру типа карма.
Запросы исполняются параллельно в разных потоках, и потом результат складывается в JSON. Довольно гибкая схема получается, можно запросить результаты одного виджета, можно нескольких. Это уже наша надстройка. Как я помню в Solr пока нельзя несколько запросов выполнить в один заход.
Кстати здесь еще плюс в том что лишнее не торчит наружу, то есть запрос на результаты поиска выглядит вот так:
gate.indexisto.com/51d587807d3e114babf91418/edit?q=hi&items=hdfkl;JrEXH;
где 51d587807d3e114babf91418 номер индекса, q — введеные символы, items=hdfkl;JrEXH; — id виджетов.
а параметры передаются в запрос написанный в виджете (запрос лежит на сервере) вот так:
в SOLR многовато можно в качестве GET параметров передать, могут понаписать что-нибудь и положить поиск, так или иначе надо что-то перед ним ставить.
В простейшем случае можно обернуть основной запрос в 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 параметров передать, могут понаписать что-нибудь и положить поиск, так или иначе надо что-то перед ним ставить.
Решение интересное. Сколько будет стоить в перспективе уже прикидывали?
Читал пост со слезами на глазах. Просто рыдал. У меня истерика.
Ваши бы слова да клиентам в уши, но клиентам надо «Поиск» и «Расширенный поиск» и что бы поля были в 99px и не больше.
Ваши бы слова да клиентам в уши, но клиентам надо «Поиск» и «Расширенный поиск» и что бы поля были в 99px и не больше.
А что будет с теми, кто получит сейчас бесплатный доступ, после того как определитесь с политикой оплаты?
Sign up to leave a comment.
Новый взгляд на поиск по сайту