Solr tokenizer wyrazów złożonych - wyniki traktowane jako twierdzenie LUB

Question

Język niderlandzki i niemiecki mają słowa, które można łączyć z nowymi słowami; wyrazów złożonych.

Na przykład "accountmanager" jest uważane za jedno słowo, połączone słowami "account" i "manager". Nasi użytkownicy używają "accountmanager" i "account manager" w dokumentach i kwerendach i oczekują tych samych wyników dla obu zapytań.

Aby móc decompound (Split) słowa solr ma słownika filtr, który mam skonfigurowany w schemacie:

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

Plik związek-word-dictionary.txt przechowuje listę słów które są używane do rozłożenia złożonych słów. Na tej liście znajdziesz na przykład słowa "konto" i "menedżer".

Wynik decompound jest ok, gdy analizowane w debugger Solr podczas wyszukiwania z zapytania "AccountManager": (tekst termin):

• AccountManager
• konta
• menedżera

Ten wynik jest jednak traktowany jako wyrażenie LUB i znajduje wszystkie dokumenty, które zawierają co najmniej jedno z zawartych w nim warunków. Chcę, aby zachowywał się jak instrukcja ORAZ (więc chcę tylko wyniki, które mają w dokumencie zarówno terminy "konto" i "menedżer").

Próbowałem ustawić domyślneOperator w schemacie na "AND", ale jest to ignorowane podczas korzystania z edismax. Dlatego ustawiłem proponowany model Min-should-Match na 100% (mm = 100%), ponownie bez żadnego pożądanego rezultatu. Poprawienie atrybutów filtru słownikowego w schemacie nie zmienia zachowania na "AND".

Czy ktoś natknął się na takie zachowanie, gdy używa fabryki słowników złożonych ze słownika i zna rozwiązanie pozwalające mu zachowywać się jak instrukcja ORAZ?

Answer 1

działa zgodnie z oczekiwaniami, DictionaryCompoundWordTokenFilterFactory dodaje właśnie "wewnętrzne słowa", które zostały znalezione, w tym przypadku zarówno "konto", jak i "menedżer", ale mogło to być tylko jedno, jeśli na przykład słowo to "accountbanana" a "banan" nie znajduje się w słowniku tylko "konto" zostałoby dodane.

Służy to komuś, kto szuka "menedżera", a także znajduje dokument, który ma "accountmanager".

Aby uzyskać żądane zachowanie (rozumiem starasz się to na boku zapytań) można użyć słownika, który sprawia AccountManager = „account manager”

Answer 2

tylko głowy jako Biorę spojrzenie w to, że jest dużo dodatkowego hałasu podczas tego. Ponieważ SOLR 3.6 ustawia przyrost pozycji każdego złamanego tokenu na 0 w CompoundWordTokenFilterBase, otrzymasz zapytania, które indeksują się poprawnie (sort). Jednak podczas odpytywania otrzymasz gigantyczną kwerendę OR złożonego słowa, ponieważ AnalyzerQueryNodeProcessor sprawdza tylko jeśli positionCount == 1.

Na przykład wyszukiwanie Castaway będzie dotyczyło (castaway lub cast lub away).To dodaje dużo hałasu, gdzie film Castaway (który jest naprawdę Cast Away) będzie działał, ale dostaniesz również wszystko, co ma po prostu "Away" lub po prostu "Cast".

Naprawiliśmy łatkę Lucene, aby ustawić pozycjęPositionIncrement na 1 i dodaliśmy dodatkowy kod w narzędziu AnalyzerQueryNodeProcessor, dzięki czemu pojawią się OR'd PhraseQueryNodes ("castaway" lub "cast away"). Jest to również nieprawidłowe, ale zmniejsza hałas. Zapytania frazowe mogą zwracać dziwne wyniki, jeśli ustawisz pozycję zawsze na 1, ponieważ (castaway0, cast1, away2), mogą zwracać wyniki "castaway away". Również pozycje z późniejszych terminów są teraz wyłączone. Aby uzyskać lepszy opis, zobacz: http://blog.mikemccandless.com/2012/04/lucenes-tokenstreams-are-actually.html