RelevancyFeedback
1.0.0
Плагины Solr Dice.com для выполнения персонализированного поиска и рекомендаций (через плагин с обратной связи с релевантностью) и концептуальный / семантический поиск (через плагин с неконтролируемым обратной связью).
Предварительно построенный файл JAR можно найти в папке ./target . Проект содержит файл Maven pom.xml, который также можно использовать для его создания из источника.
Если есть определенная версия Solr, вам нужна, пожалуйста, создайте проблему GitHub, и я посмотрю, что я могу сделать. Чтобы вручную скомпилировать его для определенной версии, используйте Maven для компиляции плагинов, используя файл pom.xml, и обновите версии библиотек Solr и Lucene в этом файле, и используйте Maven для привлечения этих зависимостей. Затем исправьте любые ошибки компиляции.
Пожалуйста, смотрите официальные рекомендации SOLR для регистрации плагинов с помощью Solr. Это в основном включает в себя простое сброс файла JAR в одну из папок, которые SOL проверяет на файлы класса и JAR на перезагрузке ядра.
Пример конфигурации обработчика запроса для solrconfig.xml показан ниже, с комментариями с указанием основных параметров:
<requestHandler name="/rf" class="org.dice.solrenhancements.relevancyfeedback.RelevancyFeedbackHandler">
<lst name="defaults">
<str name="omitHeader">true</str>
<str name="wt">json</str>
<str name="indent">true</str>
<!-- Regular query configuration - query parser used when parsing the rf query-->
<str name="defType">lucene</str>
<!-- fields returned -->
<str name="fl">jobTitle,skill,company</str>
<!-- fields to match on-->
<str name="rf.fl">skillFromSkill,extractTitles</str>
<!-- field weights. Note that term weights are normalized so that each field is weighted exactly in this ratio
as different fields can get different numbers of matching terms-->
<str name="rf.qf">skillFromSkill^3 extractTitles^4.5</str>
<int name="rows">10</int>
<!-- How many terms to extract per field (max) -->
<int name="rf.maxflqt">10</int>
<bool name="rf.boost">true</bool>
<!-- normalize the weights for terms in each field (custom to dice rf, not present in solr MLT) -->
<bool name="rf.normflboosts">true</bool>
<!-- Take the raw term frequencies (false) or log of the term frequenies (true) -->
<bool name="rf.logtf">true</bool>
<!-- Minimum should match settings for the rf query - determines what proportion of the terms have to match -->
<!-- See Solr edismax mm parameter for specifics -->
<bool name="rf.mm">25%</bool>
<!-- Returns the top k terms (see regular solr MLT handler) -->
<str name="rf.interestingTerms">details</str>
<!-- Turns the rf query into a boost query using a multiplicative boost, allowing for boosting -->
<str name="rf.boostfn"></str>
<!-- q parameter - If you want to execute one query, and use the rf query to boost the results (e.g. for personalizing search),
pass the user's query into this parameter. Can take regular query syntax e.g.rf.q={!edismax df=title qf=.... v=$qq}&qq=Java
The regular q parameter is reserved for the rf query (see abpve)
-->
<str name="q"></str>
<!-- Query parser to use for the q query, if passed -->
<str name="defType"></str>
<!-- rf.q parameter - Note that the regular q parameter is used only for personalized search scenarios, where you have a main query
and you want to use the rf query generated to boost the main queries documents. Typically the rf.q query is a query that identifies
one or more documents, e.g. rf.q=(id:686867 id:98928980 id:999923). But it cam be any query. Note that it will process ALL documents
matched by the q query (as it's intended mainly for looking up docs by id), so use cautiously.
-->
<str name="rf.q"></str>
<!-- query parser to use for the rf.q query -->
<str name="rf.defType"></str>
<!-- Settings for personalized search - use the regular parameter names for the query parser defined by defType parameter -->
<str name="df">title</str>
<str name="qf"> company_text^0.01 title^12 skill^4 description^0.3</str>
<str name="pf2">company_text^0.01 title^12 skill^4 description^0.6</str>
<!-- Content based recommendations settings (post a document to the endpoint in a POST request). The stream.body and stream.head are form parameters
You can send them in a GET request, but a POST handles larger data. If you have really large documents, you will need to change the buffer settings
so that the request doesn't blow the buffer limits in Solr or your web server.
-->
<!-- Fields used for processing documents posted to the stream.body and stream.head parameters in a POST call -->
<str name="stream.head.fl">title,title_syn</str>
<str name="stream.body.fl">extractSkills,extractTitles</str>
<!-- pass a url in this parameter for Solr to download the webpage, and process the Html using the fields configured in the stream.qf parameters -->
<str name="stream.url"></str>
<!-- Note that we have two different content stream fields to pass over in the POST request. This allows different analyzers to be appkied to each.
For instance, we pass the job title into the stream.head field and parse out job titles, while we pass the job description to the stream.head parameter
to parse out skills -->
<!-- Pass the document body in this parameter as a form parameter. Analysed using the stream.body.fl fields-->
<str name="stream.body"></str>
<!-- Pass the second document field in this parameter. Analysed using the stream.head.fl fields-->
<str name="stream.head"></str>
<!-- Specifies a separate set of field weights to apply when procesing a document posted to the request handler via the
stream.body and stream.head parameters -->
<str name="stream.qf">extractSkills^4.5 extractTitles^2.25 title^3.0 title_syn^3.0</str>
</lst>
</requestHandler>
http: // localhost: 8983/solr/jobs/rf? q = id: 11f407d319d6cc707437fad874a097c0+id: a2fd2f2e 34667D61FADCDCABFD359CF4 & ROW = 10 & DF = TITLE & FL = TITE, навыки, GeoCode, City, State & WT = JSON
{
"match":{
"numFound":2,
"start":0,
"docs":[
{
"id":"a2fd2f2e34667d61fadcdcabfd359cf4",
"title":"Console AAA Sports Video Game Programmer.",
"skills":["Sports Game Experience a plus.",
"2-10 years plus Console AAA Video Game Programming Experience"],
"geocode":"38.124447,-122.55051",
"city":"Novato",
"state":"CA"
},
{
"id":"11f407d319d6cc707437fad874a097c0",
"title":"Game Engineer - Creative and Flexible Work Environment!",
"skills":["3D Math",
"Unity3d",
"C#",
"3D Math - game programming",
"game programming",
"C++",
"Java"],
"geocode":"33.97331,-118.243614",
"city":"Los Angeles",
"state":"CA"
}
]
},
"response":{
"numFound":5333,
"start":0,
"docs":[
{
"title":"Software Design Engineer 3 (Game Developer)",
"skills":["C#",
"C++",
"Unity"],
"geocode":"47.683647,-122.12183",
"city":"Redmond",
"state":"WA"
},
{
"title":"Game Server Engineer - MMO Mobile Gaming Start-Up!",
"skills":["AWS",
"Node.JS",
"pubnub",
"Websockets",
"pubnub - Node.JS",
"Vagrant",
"Linux",
"Git",
"MongoDB",
"Jenkins",
"Docker"],
"geocode":"37.777115,-122.41733",
"city":"San Francisco",
"state":"CA"
},...
]
}
}
Пример конфигурации обработчика запроса для solrconfig.xml показан ниже, с комментариями с указанием основных параметров:
<requestHandler name="/ufselect" class="org.dice.solrenhancements.unsupervisedfeedback.UnsupervisedFeedbackHandler">
<lst name="defaults">
<str name="omitHeader">true</str>
<str name="wt">json</str>
<str name="indent">true</str>
<!-- Regular query configuration -->
<str name="defType">edismax</str>
<str name="df">title</str>
<str name="qf">title^1.5 skills^1.25 description^1.1</str>
<str name="pf2">title^3.0 skills^2.5 description^1.5</str>
<str name="mm">1</str>
<str name="q.op">OR</str>
<str name="fl">jobTitle,skills,company</str>
<int name="rows">30</int>
<!-- Unsupervised Feedback (Blind Feedback) query configuration-->
<str name="uf.fl">skillsFromskills,titleFromJobTitle</str>
<!-- How many docs to extract the top terms from -->
<str name="uf.maxdocs">50</str>
<!-- How many terms to extract per field (max) -->
<int name="uf.maxflqt">10</int>
<bool name="uf.boost">true</bool>
<!-- Relative per-field boosts on the extracted terms (similar to edismax qf parameter -->
<!-- NOTE: with uf.normflboosts=true, all terms are normalized so that the total importance of each
field on the query is the same, then these relative boosts are applied per field-->
<str name="uf.qf">skillsFromskills^4.5 titleFromJobTitle^6.0</str>
<!-- Returns the top k terms (see regular solr MLT handler) -->
<str name="uf.interestingTerms">details</str>
<!-- unit-length norm all term boosts within a field (recommended) - see talk for details -->
<bool name="uf.normflboosts">true</bool>
<!-- use raw term clounts or log term counts? -->
<bool name="uf.logtf">false</bool>
</lst>
</requestHandler>
http: // localhost: 8983/solr/dicejobscp/ufselect? Q = machine+Learning+Engineer & Start = 0 & Rows = 10 & uf.logtf = false & fl = заголовок, навыки, геокод, город, государство и fq = {! Geofilt+sfield = jobendecageocode+d = 48+pt = 39.6955, -105.0841} & wt = json
{
"match":
{
"numFound":7729,
"start":0,
"docs":[
{
"title":"NLP/Machine Learning Engineer",
"skills":["Linux",
"NLP (Natural Language Processing)",
"SQL",
"Bash",
"Python",
"ML (Machine Learning)",
"JavaScript",
"Java"],
"geocode":"42.35819,-71.050674",
"city":"Boston",
"state":"MA"
},
{
"title":"Machine Learning Engineer",
"skills":["machine learning",
"java",
"scala"],
"geocode":"47.60473,-122.32594",
"city":"Seattle",
"state":"WA"
},
{
"title":"Machine Learning Engineer - REMOTE!",
"skills":["Neo4j",
"Hadoop",
"gensim",
"gensim - C++",
"Java",
"R",
"MongoDB",
"elastic search",
"sci-kit learn",
"Python",
"C++"],
"geocode":"37.777115,-122.41733",
"city":"San Francisco",
"state":"CA"
},...
]
}
Хотя он свободно основан на коде и алгоритме Handler Solr MLT (который является только алгоритмом Роккио), в дизайне алгоритма существуют некоторые ключевые различия в дизайне алгоритма. Обработчик MLT принимает верхние члены K во всех настроенных полях при построении запроса MLT. Если у вас есть поле, которое имеет более широкий словарный запас, чем в других областях, средняя частота документов термина будет ниже, чем в других областях с меньшими словари. Это означает, что эти термины будут иметь высокие относительные показатели IDF и имеют тенденцию доминировать в верхних терминах, выбранных обработчиком Solr MLT. Наш обработчик запроса берет верхние k термины в поле. Это также гарантирует, что независимо от того, сколько терминов соответствует по поле (до настроенного предела), это поле имеет одинаковое взвешивание в результирующем запросе, что и все другие поля, до применения в параметре RF.QF, указанных в параметре RF.QF. Это вторая проблема с обработчиком Solr MLT, к которому мы обращаемся. Мы также предоставляем много дополнительных функций. Мы допускаем передачу потоков контента, сопоставляя с несколькими документами (больше похожими на «эти», в отличие от большего, похожего на «это»), применяя анализатор запроса Boost к полученному запросу MLT, чтобы позволить применять какое -либо произвольное повышение Solr (множественное). И мы поддерживаем параметр MM, поэтому мы можем заставить документы вернуться, которые соответствуют только набору % от лучших терминов.
Если вы хотите использовать это для выполнения персонализации поиска, как показано в моем разговоре Lucene Revolution 2017, вам необходимо пройти в текущем поисковом запросе пользователя, используя обычный параметр Q, а информация, используемая для генерации запроса Rocchio, передается через параметр RF.Q (при использовании документов для создания rocchio Query) или через параметры контента (RF. Обратите внимание, что повышения, применяемые к терминам в запросе Роккио, не имеют сравнительных весов для подразделений в вашем пользовательском запросе, из -за процесса нормализации, который применяет алгоритм. Таким образом, вам нужно будет экспериментировать с различными значениями rf.qf, пока вы не найдете правильный уровень влияния на ваш запрос, на основе вашей конфигурации поиска. Кроме того, учитывая, что запрос Rocchio, сгенерированный для каждого пользователя, вероятно, одинаковым для поискового сеанса пользователя (в зависимости от вашего использования, конечно), более эффективным способом использования ее для персонализации является просто использование RF Handler для генерации запроса Rochio для вас, когда пользователь входит в систему, кэшируйте этот запрос, а затем используйте его в качестве запроса на подъем (в пределах вашего регулярного запроса поиска). Обработчик возвращает запрос Роккио в параметре rf.query в ответе. Если вы хотите использовать обработчик, просто чтобы получить запрос (и не выполнить поиск), вы можете установить параметр Rows на 0. Вы также можете перевернуть на набор «интересных терминов», возвращаемых алгоритмом, наряду с их весами, если вы устанавливаете rf.interestingtermes = детали и используете его для создания вашего подразделения.
Помимо обеспечения того, чтобы это работает с большим количеством версий Solr (пожалуйста, оставьте отзыв о том, какие версии вы все хотите), есть ряд возможных улучшений:
Если у вас есть запрос на функции, пожалуйста, отправьте его в список проблем. Если у вас есть вопросы, это также хорошее место для их публикации, но вы также можете обратиться ко мне по адресу [email protected], если вы не вернулись.
