Soltero tokenizador de palabras compuestas - resultados tratados como instrucción OR

Question

El idioma holandés y alemán sí tiene palabras que se pueden combinar con palabras nuevas; palabras compuestas.

Por ejemplo, "accountmanager" se considera una palabra, compuesta por las palabras "account" y "manager". Nuestros usuarios utilizarán "accountmanager" y "account manager" en documentos y consultas, y esperan los mismos resultados para ambas consultas.

Para poder decompound palabras (split), Solr tiene un filtro de diccionario que he configurado en el esquema:

<filter class="solr.DictionaryCompoundWordTokenFilterFactory" dictionary="../../compound-word-dictionary.txt" minWordSize="8" minSubwordSize="4" maxSubwordSize="15" onlyLongestMatch="true"/> 

El archivo compuesto-palabra-dictionary.txt mantiene una lista de palabras que se usan para descomponer palabras compuestas. En esta lista, encontrará, por ejemplo, las palabras "cuenta" y "gerente".

El resultado decompound está bien, cuando se analizaron en el depurador Solr cuando se busca con la consulta "AccountManager": (término texto):

• AccountManager
• cuenta de administrador

Sin embargo, este resultado se trata como una instrucción OR y encuentra todos los documentos que tienen al menos uno de los términos. Quiero que se comporte como una declaración AND (así que solo quiero los resultados que tienen los términos "cuenta" y "gerente" en el documento).

He intentado establecer el operador predeterminado en el esquema en "Y", pero esto se ignora al usar edismax. Por lo tanto, he establecido Mín-to-Match propuesto al 100% (mm = 100%), nuevamente sin ningún resultado deseado. Ajustar los atributos del filtro de diccionario en el esquema no cambia el comportamiento a "Y".

¿Alguien se encontró con este comportamiento al usar la fábrica de tokens de palabras compuestas de diccionario y conoce una solución para que se comporte como una instrucción AND?

Answer 1

funciona como se esperaba, DictionaryCompoundWordTokenFilterFactory simplemente está agregando las 'palabras internas' que encontró, en este caso tanto 'cuenta' como 'administrador', pero podría haber sido solo una, si por ejemplo, la palabra era 'accountbanana' y 'banana' no está en el diccionario, solo se habría agregado 'account'.

Esto sirve para el propósito de alguien que busca 'gerente' y también para encontrar el documento que tiene 'administrador de cuenta'.

el fin de obtener el comportamiento que desea (entiendo que está solicitando esto en el lado de consulta) se puede usar un diccionario que hace AccountManager = "gerente de cuenta"

Answer 2

Sólo una cabeza que estoy tomando una mirada a esto, hay mucho ruido añadido al hacer esto. Como SOLR 3.6 establece el incremento de posición de cada token roto en 0 en CompoundWordTokenFilterBase, obtendrá consultas que se indexan correctamente (más o menos). Sin embargo, al realizar consultas, obtendrá una consulta OR gigante de su palabra compuesta porque AnalyzerQueryNodeProcessor solo verifica si positionCount == 1.

Por ejemplo, una búsqueda de Castaway se consultará (náufrago o elenco o de distancia).Esto agrega mucho ruido, donde la película Castaway (que es realmente Cast Away) funcionará, pero también obtendrás todo lo que tiene solo "Away" o simplemente "Cast".

En realidad han parcheado Lucene a setPositionIncrement a 1 y se añade un poco de código extra en AnalyzerQueryNodeProcessor de modo que no se PhraseQueryNodes donde tendrá ("eliminado" o "desechado") usando OR. Esto también es incorrecto, pero reduce el ruido. Las consultas de frase pueden devolver resultados extraños si establece la posición siempre en 1, ya que (náufrago0, cast1, alejamiento2) puede devolver resultados de "náufrago". También las posiciones de los términos posteriores están ahora desactivadas. Para una mejor descripción, vea: http://blog.mikemccandless.com/2012/04/lucenes-tokenstreams-are-actually.html