RelevancyFeedback
1.0.0
Os plugins Solr do DICE.com para realizar pesquisas personalizadas e recomendações (através do plug -in de feedback de relevância) e pesquisa conceitual / semântica (através do plug -in de feedback não supervisionado).
Um arquivo JAR pré-criado pode ser encontrado na pasta ./target . O projeto contém um arquivo maven pom.xml que também pode ser usado para construí -lo a partir da fonte.
Se houver uma versão específica do Solr para a qual você precisa, crie um problema do Github e eu verei o que posso fazer. Para compilá -lo manualmente para uma versão específica, use o Maven para compilar os plug -ins usando o arquivo pom.xml e atualize as versões das bibliotecas Solr e Lucene nesse arquivo e use o Maven para puxar essas dependências. Em seguida, corrija quaisquer erros de compilação.
Consulte as diretrizes oficiais do Solr para registrar plugins no Solr. Isso basicamente envolve simplesmente soltar o arquivo JAR em uma das pastas que o Solr verifica para os arquivos de classe e jar no Reload Core.
Um exemplo de solicitação de configuração do manipulador para o Solrconfig.xml é mostrado abaixo, com comentários descrevendo os parâmetros principais:
<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 & ROWS = 10 & DF = Título & FL = Título, Habilidades, Geocode, Cidade, Estado e 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"
},...
]
}
}
Um exemplo de solicitação de configuração do manipulador para o Solrconfig.xml é mostrado abaixo, com comentários descrevendo os parâmetros principais:
<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 = máquina+aprendizado+engenheiro & start = 0 & linhas = 10 & uf.logtf = false & fl = título, habilidades, geocódigo, cidade, estado e fq = {! geofilt+sfield = JobEndEcageCode+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"
},...
]
}
Embora seja vagamente baseado no código e no algoritmo do manipulador Solr MLT (que é apenas o algoritmo Rocchio), existem algumas diferenças importantes no design do algoritmo. O manipulador MLT leva os principais termos de K em todos os campos configurados ao construir a consulta MLT. Se você possui um campo com um vocabulário mais amplo que os outros campos, a frequência média do documento de um termo será menor do que em outros campos com vocabulários menores. Isso significa que esses termos terão altas pontuações relativas de IDF e tendem a dominar os termos principais selecionados pelo manipulador Solr MLT. Nosso manipulador de solicitação assume os principais termos K por campo. Ele também garante que, não importa quantos termos sejam correspondidos por campo (até o limite configurado), esse campo tenha a mesma ponderação na consulta resultante que todos os outros campos, antes que os pesos específicos do campo especificados no parâmetro RF.QF sejam aplicados. Este é o segundo problema com o manipulador Solr MLT que abordamos. Também fornecemos muita funcionalidade extra. Permitimos a transmissão de fluxos de conteúdo, combinando com vários documentos (mais como 'estes', em oposição a mais como 'isso'), aplicando o analisador de consulta Boost na consulta MLT resultante para permitir que qualquer impulso arbitrário do Solr seja aplicado (multiplicativo). E apoiamos o parâmetro MM, para que possamos forçar os documentos a voltar que correspondem apenas a um conjunto de termos principais.
Se você deseja usá -lo para executar a personalização da pesquisa, como demonstrado na minha palestra do Lucene Revolution 2017, precisa passar na consulta de pesquisa atual do usuário usando o parâmetro Q regular, e as informações usadas para gerar a consulta ROCCHIO são passadas por meio do parâmetro RF.Q (quando o uso de documentos. Observe, no entanto, que os aumentos aplicados aos termos na consulta de Rocchio não são de pesos comparativos aos da sua consulta de usuário, devido ao processo de normalização que o algoritmo aplica. Portanto, você precisará experimentar diferentes valores de RF.QF até encontrar o nível certo de influência em sua consulta, com base na configuração da sua pesquisa. Além disso, dado que a consulta Rocchio gerada para cada usuário é provavelmente a mesma em toda a sessão de pesquisa do usuário (dependendo do seu caso de uso, é claro), uma maneira mais eficaz de usar isso para fazer a personalização é simplesmente usar o manipulador de RF para gerar a consulta Substetente (a sessão de tempo, o que é um dos usuários de que o RF), em busca de um reflexão, o que é um dos usuários de que a busca é uma queda de que o RF), e depois, a busca de RF). O manipulador retorna a consulta Rocchio no parâmetro RF.Query na resposta. Se você deseja usar o manipulador apenas para obter a consulta (e não executar a pesquisa), você pode definir o parâmetro de linhas como 0. Você também pode iterar sobre o conjunto de 'termos interessantes' retornados pelo algoritmo, juntamente com o seu pesos, se você definir rf.Interestingterms = Detalhes e usar isso para construir o seu boost query.
Além de garantir que isso funcione com mais versões do Solr (por favor, deixe feedback sobre quais versões que todos desejam), há vários aprimoramentos possíveis:
Se você tiver uma solicitação de recurso, envie -a para a lista de problemas. Se você tiver dúvidas, esse também é um bom lugar para publicá -las, mas você também pode entrar em contato comigo em [email protected] se não estiver aqui de volta.
