tutorial query example español search lucene search-engine

query - lucene vs elasticsearch



Puntuación de Lucene: ¿en qué contexto se usa queryNorm? (2)

Estoy un poco confundido por la estrategia de puntuación de lucene. Sé que la fórmula de puntuación de Lucene es como:

score(q,d) = coord(q,d) x queryNorm(q) X SUM <t_in_q> ( tf(t_in_d) x idf(t)^2 x t.getBoost() x norm(t,d))

Entiendo cada componente de esta fórmula, excepto queryNorm (q) . Como se explica en la documentación oficial,

queryNorm (q) es un factor de normalización utilizado para hacer que las puntuaciones entre consultas sean comparables. Este factor no afecta la clasificación de los documentos (dado que todos los documentos clasificados se multiplican por el mismo factor), sino que simplemente intenta hacer que los puntajes de diferentes consultas (o incluso índices diferentes) sean comparables.

¿Por qué debo comparar puntajes entre diferentes consultas? En otra palabra, ¿podría dar un ejemplo para mostrar en qué contexto queryNorm (q) es útil?


Buena pregunta, me lo he preguntado yo mismo. De acuerdo con este argumento de ScoresAsPercentages , intentar comparar diferentes puntajes de consultas o índices, o incluso puntajes en la misma consulta e índice en diferentes momentos, es una mala idea, y estoy de acuerdo.

Mi comprensión es que, aunque queryNorm realmente no los hace estrictamente comparables, sí ayuda. Están más cerca de ser comparable con la queryNorm predeterminada que sin.

Supongo que también podría permitir a las personas escribir su propia similitud y usar esta llamada para crear puntajes comparables, normalizados, usando algoritmos que funcionen en su caso particular.

Se ha debatido sobre descartarlo , lo que puede resultarle interesante.


Sé que la pregunta es antigua pero tuve un problema similar. El motivo por el que queryNorm no era el mismo en todos los resultados de búsqueda es que los documentos pueden estar en fragmentos diferentes y queryNorm es constante solo dentro del mismo fragmento.

Desde mi entendimiento, este problema se puede resolver de 2 maneras:

  • naturalmente, cuando hay una gran cantidad de datos

  • estableciendo el número de fragmentos en 1. Por supuesto, esto tiene consecuencias en las actuaciones.

    {"configuración": {"number_of_shards": 1}}

Ver http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/relevance-is-broken.html