2010-06-23 7 views
6

Quiero que mis resultados de búsqueda ordenen por puntaje, lo cual están haciendo, pero el puntaje se está calculando incorrectamente. Es decir, no necesariamente incorrectamente, pero de manera diferente a lo esperado y no estoy seguro de por qué. Mi objetivo es eliminar lo que está cambiando el puntaje.Solr: campoNorma diferente por documento, sin aumento de documento

Si realizo una búsqueda que coincide con dos objetos (donde se espera que ObjectA tenga una puntuación más alta que ObjectB), se devuelve ObjectB primero.

Digamos, para este ejemplo, que mi consulta es un término único: "manzanas".

título de Objecta: "las manzanas son manzanas" (2/3) Descripción de términos
de Objecta: "! Había manzanas en las manzanas con las manzanas y ahora las manzanas fueron todas las manzanas por todas las manzanas" (6/18 términos)
Título de ObjectB: "las manzanas son geniales" (1/3 términos)
Descripción de ObjectB: "¡Había manzanas en la habitación de las manzanas y ahora las manzanas se ponían feas en todas las manzanas!" (4/18 términos)

El campo de título no tiene impulso (o más bien, un aumento de 1) y el campo de descripción tiene un impulso de 0.8. No he especificado un aumento de documentos a través de solrconfig.xml ni a través de la consulta que estoy realizando. Si hay otra forma de especificar un aumento de documentos, existe la posibilidad de que me falta uno.

Después de analizar la impresión explain, parece que Objecta es calcular adecuadamente una puntuación más alta que ObjectB, al igual que yo quiero, a excepción de la diferencia uno: fieldNorm título de ObjectB es siempre mayor que Objecta de.


Aquí sigue la impresión explain. Para que lo sepas: el campo título es mditem5_tns y el campo de descripción es mditem7_tns:

ObjectB: 
1.3327172 = (MATCH) sum of: 
    1.0352166 = (MATCH) max plus 0.1 times others of: 
    0.9766194 = (MATCH) weight(mditem5_tns:appl in 0), product of: 
     0.53929156 = queryWeight(mditem5_tns:appl), product of: 
     1.8109303 = idf(docFreq=3, maxDocs=9) 
     0.2977981 = queryNorm 
     1.8109303 = (MATCH) fieldWeight(mditem5_tns:appl in 0), product of: 
     1.0 = tf(termFreq(mditem5_tns:appl)=1) 
     1.8109303 = idf(docFreq=3, maxDocs=9) 
     1.0 = fieldNorm(field=mditem5_tns, doc=0) 
    0.58597165 = (MATCH) weight(mditem7_tns:appl^0.8 in 0), product of: 
     0.43143326 = queryWeight(mditem7_tns:appl^0.8), product of: 
     0.8 = boost 
     1.8109303 = idf(docFreq=3, maxDocs=9) 
     0.2977981 = queryNorm 
     1.3581977 = (MATCH) fieldWeight(mditem7_tns:appl in 0), product of: 
     2.0 = tf(termFreq(mditem7_tns:appl)=4) 
     1.8109303 = idf(docFreq=3, maxDocs=9) 
     0.375 = fieldNorm(field=mditem7_tns, doc=0) 
    0.2975006 = (MATCH) FunctionQuery(1000.0/(1.0*float(top(rord(lastmodified)))+1000.0)), product of: 
    0.999001 = 1000.0/(1.0*float(1)+1000.0) 
    1.0 = boost 
    0.2977981 = queryNorm 

ObjectA: 
1.2324848 = (MATCH) sum of: 
    0.93498427 = (MATCH) max plus 0.1 times others of: 
    0.8632177 = (MATCH) weight(mditem5_tns:appl in 0), product of: 
     0.53929156 = queryWeight(mditem5_tns:appl), product of: 
     1.8109303 = idf(docFreq=3, maxDocs=9) 
     0.2977981 = queryNorm 
     1.6006513 = (MATCH) fieldWeight(mditem5_tns:appl in 0), product of: 
     1.4142135 = tf(termFreq(mditem5_tns:appl)=2) 
     1.8109303 = idf(docFreq=3, maxDocs=9) 
     0.625 = fieldNorm(field=mditem5_tns, doc=0) 
    0.7176658 = (MATCH) weight(mditem7_tns:appl^0.8 in 0), product of: 
     0.43143326 = queryWeight(mditem7_tns:appl^0.8), product of: 
     0.8 = boost 
     1.8109303 = idf(docFreq=3, maxDocs=9) 
     0.2977981 = queryNorm 
     1.6634457 = (MATCH) fieldWeight(mditem7_tns:appl in 0), product of: 
     2.4494898 = tf(termFreq(mditem7_tns:appl)=6) 
     1.8109303 = idf(docFreq=3, maxDocs=9) 
     0.375 = fieldNorm(field=mditem7_tns, doc=0) 
    0.2975006 = (MATCH) FunctionQuery(1000.0/(1.0*float(top(rord(lastmodified)))+1000.0)), product of: 
    0.999001 = 1000.0/(1.0*float(1)+1000.0) 
    1.0 = boost 
    0.2977981 = queryNorm 

Respuesta

6

el problema es causado por la despalilladora. Se expande "las manzanas son manzanas" a "las manzanas son manzanas manzanas", lo que hace que el campo sea más largo. Como el documento B solo contiene 1 término que está siendo expandido por la lentificadora, el campo permanece más corto que el documento A.

Esto da como resultado diferentes camposNormas.

+0

¿Podría elaborar o posiblemente proporcionar un enlace? ¿Por qué el "stemmer" expandiría mi campo a algo que * no es *? ¡Eso parece contrario a la intuición! :) – JMTyler

+0

A menos que el primer "appl" que escribió se suponía que era "apple"? Habiendo examinado la derivación, eso tendría sentido si las "manzanas" se descomponen en su forma raíz. Entonces, avíseme si tengo este derecho, ¿está diciendo que si cambio todas las referencias a "manzana" y busco solo "manzana", debería obtener los resultados en el orden que deseo? – JMTyler

+0

Edité mi publicación, por lo que debería ser más clara ahora. El talmador usa "appl" como forma raíz para "manzana" y "manzanas". Entonces, si deshabilita la derivación, debe obtener el resultado que espera. También puede excluir términos de ser derivados agregándolos a protwords.txt y cambiar el schema.xml Jem

2

FieldNOrm se calcula de 3 componentes - impulso en tiempo índice en el campo, impulso índice de tiempo en el documento y campo de longitud. Suponiendo que no está suministrando ningún aumento en el tiempo del índice, la diferencia debe ser la longitud del campo.

Por lo tanto, ya lengthNorm es mayor para los valores de los campos más cortos, de B a tener un valor más alto para fieldNorm el título, debe tener menor número de fichas en el título que A.

Ver las páginas siguientes para una explicación detallada de Lucene de puntuación:

http://lucene.apache.org/java/2_4_0/scoring.html http://lucene.apache.org/java/2_4_0/api/org/apache/lucene/search/Similarity.html

+0

+1 para mucha información - ¡gracias! Desafortunadamente, sin embargo, notarás en mi publicación que indiqué cuáles son los campos (y sus longitudes). Ambos objetos tienen títulos con 3 tokens y descripciones con 18 tokens.El título de ObjectA tiene 2/3 coincidencias de tokens, ObjectB tiene 1/3 de coincidencia, y las descripciones coincidentes son respectivamente 6/18 y 4/18. Entonces, si entiendo lo que estás diciendo, el lengthNorm no debería estar teniendo ningún efecto. ¿Puedo preguntar, cómo voy a configurar los aumentos de tiempo de indexación? – JMTyler

+0

Lo siento, pensé que su ejemplo estaba compuesto y no los valores reales. En ese caso, tienes razón en que la longitud del campo no debe ser un factor. Puede configurar aumentos en Solr de varias formas: si está usando SolrJ, creo que hay un método "setBoost" en SolrInputDocument. Pero si el Doc B recibía un impulso, el campoNorma debería ser más alto en el campo de descripción también. También es posible que desees consultar a Luke: te permite reconstruir tus datos de campo indexados para que puedas ver lo que realmente se indexa. – KenE

+0

No, no inventado, solo datos de prueba. :) Echaré un vistazo al código y veré si algo sospechoso está sucediendo con los refuerzos de tiempo de indexación. Probablemente también vea a Luke. Gracias por la ayuda. – JMTyler

Cuestiones relacionadas