Solr 4.0 i możliwości analizy języka polskiego

Ze względu na to, iż wsparcie dla języka polskiego w Lucene (i Solr) jest już od jakiegoś czasu, postanowiłem przyjrzeć się jak zmieni się to wraz z premierą Lucene i Solr w wersji 4.0.

Dostępne opcje

W obecnej chwili dostępne są trzy opcje, jeżeli chodzi o analizę języka polskiego:

  • Wykorzystanie możliwości  biblioteki Stempel (od wersji 3.1 Solr)
  • Wykorzystanie możliwości biblioteki Hunspell i słownika języka polskiego (od wersji 3.5 Solr)
  • Wykorzystanie możliwości biblioteki Morfologik (od wersji 4.0 Solr, SOLR-3272)

Konfiguracja

Przyjrzyjmy się konfiguracji każdej z wyżej wymienionych funkcjonalności (należy pamiętać, że poniższe konfiguracje zostały oparte o Solr 4.0).

Stempel

W celu dodania stemmingu języka polskiego przy pomocy biblioteki Stempel, to proste dodanie filtra do definicji typu:

Oprócz tego, do SOLR_HOME/lib należy dodać bibliotekę lucene-analyzers-stempel-4.0.jar oraz apache-solr-analysis-extras-4.0.jar. Dobrym pomysłem jest także użycie solr.LowerCaseFilterFactory przed Stemplem.

Hunspell

Podobnie, jak w powyższym przypadku, skorzystanie z Hunspell’a to dodanie filtra do definicji typu. Na przykład w taki sposób:

Parametry dictionary oraz affix odpowiadają za definicję słownika z którego korzystamy. Natomiast parametr ignoreCase ustawiony na wartość true mówi filtrowi, aby nie zwracać uwagi na wielkość znaków. Słowniki można znaleźć m.in. pod adresem: http://wiki.services.openoffice.org/wiki/Dictionaries.

Morfologik

Tak jak w wyżej wymienionych przypadkach, tak samo i tutaj, skorzystanie z Morfologika to dodanie filtra do definicji typu. Tym razem w następujący sposób:

Parametr dictionary to definicja z którego słownika chcemy skorzystać, do wyboru mamy:

  • MORFOLOGIK
  • MORFEUSZ
  • COMBINED

Oprócz tego, do SOLR_HOME/lib należy dodać bibliotekę lucene-analyzers-morfologik-4.0.jar, apache-solr-analysis-extras-4.0.jar, morfologik-fsa-1.5.2.jar, morfologik-polish-1.5.2.jar oraz morfologik-stemming-1.5.2.jar.

Porównanie działania

Oczywiście nie byłem w stanie ocenić działania dla całego korpusu słów języka polskiego, dlatego wybrałem sobie cztery słowa, aby sprawdzić, jak zachowuje się każdy z wymienionych wyżej filtrów. Słowa te to: „urodzić urodzony urodzona urodzeni”. Wyniki przedstawiają się następująco:

Stempel

Wynikiem działania Stempla były następujące tokeny:

Należy jednak pamiętać, iż Stempel to stemmer, a więc wyniki jego działania mogą i będą odbiegać od form podstawowych, czy też tematów słów. Ważne jest to, aby interesujące nas słowa sprowadzane były do tej samej formy, co umożliwi znalezienie odpowiedniego słowa przez Lucene/Solr. Pamiętając jednak o tym, widać iż wyniki nie są zadowalające, przynajmniej dla mnie. Na przykład zadając zapytanie urodzić, nie znaleźlibyśmy dokumentów ze słowami urodzona, czy urodzony. Dodatkowo widać, iż Stempel wyprodukował po jednym tokenie dla każdego ze słów.

Hunspell

Wynikiem działania Hunspell’a były następujące tokeny:

Porównując wyniki uzyskane z pomocą Hunspell’a do tych uzyskanych z pomocą Stempla widać różnicę. Nasze przykładowe zapytanie o słowo urodzić, znalazłoby zarówno dokumenty ze słowem urodzony, jak również ze słowem urodzona, czy urodzeni. Całkiem miło. Dodatkowo widać, iż na trzy z czterech słów wejściowych Hunspell wygenerował więcej, niż jeden token (oczywiście umieszczając je na odpowiednich pozycjach w strumieniu tokenów). Wynik działania Hunspell’a mnie satysfakcjonuje, natomiast spójrzmy jeszcze na działanie najnowszego filtra dostępnego w Lucene i Solr pozwalającego na analizę języka polskiego, czyli na Morfologika.

Morfologik

Wynikiem działania Morfologika były następujące tokeny:

Porównując wyniki uzyskane za pomocą Morfologika do tych uzyskanych za pomocą Hunspell’a ciężko zauważyć różnicę (oczywiście w tym wypadku). Jedyną różnicą pomiędzy Hunspell’em, a Morfologikiem jest ostatni term dla słowa urodzeni, czyli urodzenie, którego nie otrzymaliśmy w wyniku działania Morfologika. Moim zdaniem wynik działania Morfologika, podobnie jak w przypadku Hunspell’a można uznać za satysfakcjonujący.

Wydajność

Test wydajności został zrobiony bardzo prosto – każdorazowo zostało zaindeksowanych 5 milionów dokumentów, gdzie wszystkie pola tekstowe były oparte o analizę języka polskiego z odpowiednim filtrem (do tego kilka standardowych filtrów, jak usuwanie stopwordów, synonimy, itp). Za każdym razem indeksowanie rozpoczynane było od nowa na nowej instancji Solr 4.0. Ze względu na korzystanie z Data Import Handlera polecenie commit wysyłane było co 100.000 dokumentów. Indeks składał się z kilkunastu pól, jednak sama struktura nie jest ważna ze względu na to, że zamierzałem zobaczyć, jak wygląda porównanie poszczególnych filtrów. Poniżej wyniki testu:

FiltrStempelHunspellMorfologik
Czas indeksowania99 minut> 10 godzin100 minut

Uwaga: W chwili pisania niniejszego tekstu, zgodnie ze zgłoszeniem SOLR-3245 istnieje problem z wydajnością Hunspella z polskimi słownikami w Solr 4.0. Najprawdopodobniej, sytuacja ta zostanie rozwiązana do czasu wypuszczenia wersji 4.0 Solr, jednak jeżeli zastanawiacie się nad korzystaniem z Solr 4.0 i Hunspell’a z polskimi słownikami wydajność takiego tandemu może być niezadowalająca.

Niestety ze względu na problemy wydajnościowe z Hunspell’em nie byliśmy w stanie porównać wydajności trzech dostępnych filtrów umożliwiających analizę języka polskiego. Natomiast z powyższej tabeli wnioskować można, iż w większości przypadków zarówno Stempel, jak i Morfologik będą charakteryzowały się podobną wydajnością.

Krótkie podsumowanie

Pomimo braku wyników wydajnościowych dotyczących Hunspell’a (bo te które są uważam za błędne i jestem pewien, że zostaną poprawione), widać iż Hunspell i Morfologik są dobrymi kandydatami do wykorzystania jeżeli chodzi o filtr umożliwiający analizę języka polskiego. W przypadku Morfologika, mamy wydajność podobną do Stempla, a w testach wychodzi na to, że Morfologik daje sobie radę z większą ilością polskich słów, co wpłynie pozytywnie na odczucia użytkowników.

57 thoughts on “Solr 4.0 i możliwości analizy języka polskiego

  • 30 maja 2012 at 20:03
    Permalink

    Witam,

    Mam problem z dodaniem modułu MORFOLOGIK.

    Oto co zrobiłem, aby go dodać:

    1. Dodałem do solrconfig.xml linijkę:

    2. Skopiowałem wymagane pliki do domyślnego foleru example/lib

    3. Stworzyłem nowy typ pola z MORFOLOGIK, po czym przypisałem go do pola text:

    <!– in this example, we will only use synonyms at query time

    –>

    Oczywiście moja wersja to SOLR 4.0 Nightly. Po wejściu do admina sypie błędem z solrconfig.xml, ale jest tak zawsze gdy coś jest nie tak.

    Bardzo proszę i z góry dziękuję za pomoc 🙂

    Reply
  • 30 maja 2012 at 21:17
    Permalink

    Poprosiłbym o wymienione w 1) i 3) dane na blog(at)solr.pl. WordPress wycina XML’a 😉

    Reply
  • 18 września 2012 at 19:08
    Permalink

    Witam,

    Próbuje dodać moduł MORFOLOGIK, dodałem wymienione w artykule pliki jar, definicje filtra do schema.xml ale przy uruchamianiu dostaję błąd:

    SEVERE: java.lang.RuntimeException: Default dictionary resource for language ‚plnot found.
    at morfologik.stemming.Dictionary.getForLanguage(Dictionary.java:163)
    at morfologik.stemming.PolishStemmer.(PolishStemmer.java:64)
    …..
    Caused by: java.io.IOException: Could not locate resource: morfologik/dictionaries/pl.dict
    at morfologik.util.ResourceUtils.openInputStream(ResourceUtils.java:56)
    at morfologik.stemming.Dictionary.getForLanguage(Dictionary.java:156)

    Rozumiem, że nie udaje się wczytać pl.dict ale w morfologik-polish-1.5.3.jar taki istnieje.
    W czym może być problem ??

    SOLR 4.0-BETA

    Z góry dziękuje za pomoc 😉

    Reply
    • 24 września 2012 at 08:36
      Permalink

      Czy ścieżki są poprawnie ustawione ? W solrconfig.xml można ustawić ścieżki do dodatkowych bibliotek za pomocą znacznika Reply

  • 20 września 2012 at 03:53
    Permalink

    Witam,
    Próba skorzystania z morfologika skutkuje wyjątkiem:
    null:java.lang.RuntimeException: Default dictionary resource for language ‚plnot found. at morfologik.stemming.Dictionary.getForLanguage(Dictionary.java:163) at morfologik.stemming.PolishStemmer.(PolishStemmer.java:64) at org.apache.lucene.analysis.morfologik.MorfologikFilter.(MorfologikFilter.java:70) at org.apache.lucene.analysis.morfologik.MorfologikFilterFactory.create(MorfologikFilterFactory.java:59) at (potem jeszcze dużo błędów) ….
    na końcu:
    … org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534) at java.lang.Thread.run(Unknown Source) Caused by: java.io.IOException: Could not locate resource: morfologik/dictionaries/pl.dict at morfologik.util.ResourceUtils.openInputStream(ResourceUtils.java:56) at morfologik.stemming.Dictionary.getForLanguage(Dictionary.java:156) … 52 more

    Przy czym nie ma nigdzie słownika pl.dict ani katalogów, których szuka Solr.

    Czy jest jakiś element konfiguracji, który należy wykonać w solrconfig.xml lub w innym miejscu (np. skopiować odpowiednie słowniki z pakietów – które? – do odpowiednich miejsc – jakich?).

    Będę wdzięczny za wskazówki

    Wersja Solr: apache-solr-4.0-2012-09-14_02-55-18

    Reply
    • 24 września 2012 at 08:44
      Permalink

      Podejrzewam, że Solr nie widzi dodatkowych bibliotek. Na pewno konieczne są:
      * lucene-analyzers-morfologik-4.0.0-BETA.jar
      * morfologik-fsa-1.5.3.jar
      * morfologik-polish-1.5.3.jar
      * morfologik-stemming-1.5.3.jar
      * apache-solr-analysis-extras-4.0.0-BETA.jar

      W zależności, jak zainstalowany jest Solr, konieczne może być dodanie w solrconfig.xml odpowiedniego wpisu (), który pokaże Solr, gdzie są dodatkowe biblioteki. Reply

  • 24 września 2012 at 07:47
    Permalink

    Cześć, wystawilem sobie oddzielną istancje solr’a u siebie na serwerze w ścieżce /opt/solr/dev/solr. W tym folderze umieściłem zawartość tego co znajduje się w folderze example/solr w paczce pobranej ze strony. Wszystko działa w oparciu o tomcata i ogólnie działa. Chciałem do tego dorzucić obsługę języka polskiego (Morfologik) i zrobiłem wszystko zgodnie z tym co znalazłem w Twoim wpisie. Tak mi się przynajmniej wydaje. Problem w tym, że w przekopiowanym z przykładu folderze nie było był folderu lib więc stworzyłem go i teraz mam go w ścieżce: /opt/solr/dev/solr/lib.
    Przekopiowałem wszystkie wymagane pliki i dostaje taki błąd: „collection1: org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: Plugin init failure for [schema.xml] fieldType „text_pl”: Plugin init failure for [schema.xml] analyzer/filter: Error loading class ‚solr.MorfologikFilterFactory'” . Domyślam się, że problem jest w ścieżkach. Możesz mi pomóc poprawnie to skonfigurować? Z góry dzięki!

    Reply
    • 24 września 2012 at 08:35
      Permalink

      Podejrzewam, że problemem jest brak zdefinionwanych ścieżek do bibliotek. W solrconfig.xml można ustawić ścieżki do dodatkowych bibliotek za pomocą znacznika . Reply

  • 24 września 2012 at 09:17
    Permalink

    Dzięki za szybką odpowiedź:), w związku z tym że folder lib znajduje się w SOLR_HOME, dodałem do solrconfig.xml węzeł lib z paramatrem dir=”./lib” tak jak jest napisane w komentarzach. Mimo to nic się nie zmieniło…

    Reply
  • 24 września 2012 at 09:28
    Permalink

    Swoją drogą, tam są bardzo dziwne ścieżki w solrconfig.xml, np. dir=”../../../dist/” regex=”apache-solr-cell-\d.*\.jar” i wydaje mi się, że przy stawianiu oddzielnej instacji na tomcat te ścieżki nijak się mają do rzeczywistości. Czy się mylę?

    Reply
    • 24 września 2012 at 09:30
      Permalink

      Zdecydowanie tak – to są tylko przykładowe ścieżki, jeżeli rozpakowałbyś archiwum, które pobierasz i wrzucił wszystko bez żadnych zmian.

      Reply
  • 24 września 2012 at 09:50
    Permalink

    Już prawie działa, ścieżka bezwzględna pomogła, ale teraz mam taki błąd: Could not locate resource: morfologik/dictionaries/pl.dict. Widziałem, że kolego wyżej miał to samo. Gdzie właściwie siedzi ten plik? Czy w solrconfig.xml można ustawić ścieżkę do niego?

    Reply
    • 24 września 2012 at 09:54
      Permalink

      Muszę przyjrzeć się bliżej Morfologikowi w 4.0.0-BETA, wcześniej nie było tych problemów. Z tego co widzę słowniki (fizycznie) znajdują się w /contrib/analysis-extras/lib/morfologik-polish-1.3.5.jar

      Reply
  • 24 września 2012 at 10:02
    Permalink

    No ja właśnie rozpakowałem jara z morfologik-polish-1.5.3 i faktycznie plik tam jest, więc powinno być ok, oczywiście jeśli o ten plik chodzi.

    Reply
  • 24 września 2012 at 10:06
    Permalink

    Może skorzystanie z Solr’a w starszej wersji rozwiązałoby problem? Mam jeszcze wersje 3.6.1, nie przyglądałem się różnicom, ale do przetestowania silnika jako takiego nie powinno to mieć chyba dużego znaczenia, prawda?

    Reply
    • 24 września 2012 at 10:08
      Permalink

      Morfologika niestety nie ma w 3.6.1 🙁 Spróbuje się przyjrzeć co się dzieje z Morfologikiem w beta 4.0, ale to dopiero późnym wieczorem.

      Reply
  • 24 września 2012 at 10:11
    Permalink

    Będę niesamowicie wdzięczny :), tymczasem przetestuję na 3.6.1 Hunspella i zobaczymy jak ten daje rade.

    Reply
  • 25 września 2012 at 23:07
    Permalink

    @Pawel – w 4.0-BETA jest jakiś problem z morfologikiem, a dokładniej ze słownikiem, który nie chce działać. Spróbuje sprawdzić w najbliższym czasie kod, co może to powodować. W 4.0-alpha działało.

    Reply
  • 26 września 2012 at 08:57
    Permalink

    Ok, będę tu co jakiś czas zaglądał. Pozdr.

    Reply
  • 28 września 2012 at 15:32
    Permalink

    Jakimś rozwiązaniem problemu „Default dictionary resource for language ‚plnot found.” jest rozpakowanie pliku morfologik-polish-1.5.3.jar do odpowiedniego katalogu. W domyślnej testowej instalacji rozpakowujemy do katalogu example/ .

    Reply
  • 18 października 2012 at 09:13
    Permalink

    Faktycznie w 3.6.1 nie ma Morfologika, ale przy niezbyt dużym nakładzie pracy udało mi się przepisać kod z 4.0 na 3.6.1. Wymagało to napisania własnego Filter Factory i przekompilowania źródeł z lucene-analyzers-morfologik-4.0.0-*.jar z biblotekami z Solr 3.6.1.
    Jedynie trochę czasu mi zajęło żeby czytał słowniki z katalogu konfiguracyjnego Solr.

    Testowałem jedynie z Tomcat 6.0, ale myślę że będzie działać też z innymi.

    Reply
    • 18 października 2012 at 09:21
      Permalink

      Dokładnie, zmiany nie powinny być aż tak drastyczne. Przez długi okres czasu korzystaliśmy z własnej implementacji filtra i fabryki do Morfologika, kiedy nie było jeszcze integracji z Solr. Wbrew pozorom nie jest to trudne do zrobienia.

      Reply
  • 27 października 2012 at 14:28
    Permalink

    mam pytanie: jakie filtry najlepiej uzyc dla jezyka polskiego w konfiguracji.

    aby dodac jezyk polski zmienilem (testowo) fieldType o nazwie text_en_splitting i dodalem tam morphologica

    ale nie wiem czy w dobrym miejscu i czy te inne filtry sa potrebne i czy w dobrej kolejnosci

    please help 🙂

    <!– in this example, we will only use synonyms at query time

    –>

    Reply
    • 28 października 2012 at 09:09
      Permalink

      Przykładowa konfiguracja:

      <fieldType name=”text_en_splitting” class=”solr.TextField”
      positionIncrementGap=”100″ autoGeneratePhraseQueries=”true”>
      <analyzer type=”index”>
      <tokenizer class=”solr.WhitespaceTokenizerFactory”/>
      <filter class=”solr.SynonymFilterFactory” synonyms=”index_synonyms.txt” ignoreCase=”true” expand=”false”/>
      <filter class=”solr.StopFilterFactory” ignoreCase=”true” words=”lang/stopwords_pl.txt” enablePositionIncrements=”true” />
      <filter class=”solr.WordDelimiterFilterFactory” generateWordParts=”1″ generateNumberParts=”1″ catenateWords=”1″ catenateNumbers=”1″ catenateAll=”0″ splitOnCaseChange=”1″/>
      <filter class=”solr.LowerCaseFilterFactory”/>
      <filter class=”solr.KeywordMarkerFilterFactory” protected=”protwords.txt”/>
      <filter class=”solr.MorfologikFilterFactory” dictionary=”MORFOLOGIK” />
      </analyzer>
      <analyzer type=”query”>
      <tokenizer class=”solr.WhitespaceTokenizerFactory”/>
      <filter class=”solr.SynonymFilterFactory” synonyms=”synonyms.txt” ignoreCase=”true” expand=”true”/>
      <filter class=”solr.StopFilterFactory” ignoreCase=”true” words=”lang/stopwords_pl.txt” enablePositionIncrements=”true” />
      <filter class=”solr.WordDelimiterFilterFactory” generateWordParts=”1″ generateNumberParts=”1″ catenateWords=”0″ catenateNumbers=”0″ catenateAll=”0″ splitOnCaseChange=”1″/>
      <filter class=”solr.LowerCaseFilterFactory”/>
      <filter class=”solr.KeywordMarkerFilterFactory” protected=”protwords.txt”/>
      <filter class=”solr.MorfologikFilterFactory” dictionary=”MORFOLOGIK” />
      </analyzer>
      </fieldType>

      Reply
  • 9 listopada 2012 at 01:28
    Permalink

    W kwestii wydajności hunspell’a: łatwo napisać mechanizm buforowania wyników stemowania, po ‚warmingu’ (ok. 1000 dokumentów) zaczyna pracować z prędkością zbliżoną (różnica kilku %) do indeksowania bez użycia hunspell’a.

    Reply
  • 13 grudnia 2012 at 11:03
    Permalink

    Witajcie Panowie,

    Czy moglibyście mi podpowiedzieć jak mogę zainstalować (skąd mogę sciągnąć) wersje solr’a 4.1. Jestem w trakcie konfiguracji Solr 4.0 z Morfologikiem i natknąłem się na błąd:
    SEVERE: null:java.lang.RuntimeException: Default dictionary resource for language ‚plnot found.

    Wyżej wyczytałem, że została zaimplementowana poprawka w wersji 4.1 ale niestety nie mam pojecia jak jej uzyc 🙁

    Jestem ogromnie wdzieczny za pomoc 🙂
    pozdrawiam,
    Marek

    Reply
    • 13 grudnia 2012 at 16:41
      Permalink

      Jeden z komentarzy powyżej sugeruje, że można po prostu rozpakować jar’a ze słownikiem. Jest to jedna z możliwości.

      Reply
  • 3 stycznia 2013 at 15:49
    Permalink

    Witam,
    uzywam solr 4.0+morfologik. w konfiguracji typu mam:

    zarowno w sekcji index jak i query. Generalnie mialo to umozliwic wyszukiwanie niezaleznie od wpisanych polskich ogonkow, ale jest z tym problem taki: jesli wpisuje fraze z polskimi ogonkami, to wszystko zadziala prawidlowo (morfologik znajdzie formy wyrazow, asciifolding usunie z nich ogonki), ale jesli podamy kwerende bez polskich ogoknow, to morfologik nie potraktuje ich jako prawidlowych wyrazow, nie rozszerzy o mozliwe odmiany i w efekcie wyszukaja mi sie tylko frazy identyczne z wpisana (z dokladnoscia do polskich znaczkow). Czy jest jakis sposob na to, aby wyszukiwanie uwzglednialo odmiane i bylo „odporne” na polskie znaczki (dzialalo w obu wypadkach)?

    Reply
  • 3 stycznia 2013 at 15:51
    Permalink

    w konfiguracji mam:
    [filter class=”solr.LowerCaseFilterFactory”/]
    [filter class=”org.apache.lucene.analysis.morfologik.MorfologikFilterFactory” dictionary=”MORFOLOGIK” /]
    [filter class=”solr.ASCIIFoldingFilterFactory”/]

    (poprzednio wycięło mi tagi xml-owe).

    Reply
    • 7 stycznia 2013 at 08:28
      Permalink

      Tak zadzaiała morfologik – w drugim przypadku nie będzie w stanie znaleźć poprawnego dopasowania słowa bez polskich znaków, ponieważ nie ma takich w jego słowniku. Co do sposobu rozwiązania, to można próbować z modyfikacją słownika Morfologika, takie rozwiązanie działa, ale niestety nie mogę opisać tego dokładnie ze względu na to, że przygotowywaliśmy tego typu funkcjonalność dla klienta, a on nie chce tego rozpowszechniać.

      Reply
  • 13 sierpnia 2013 at 15:08
    Permalink

    Cześć! Mam taki problem: Chciałbym aby po wpisaniu w wyszukiwarkę „gdańsk” albo „gdansk” otrzymać te same wyniki. Czy te biblioteki to umożliwiają czy może jest na to inny sposób? Wersja solr to 3.5.0

    Reply
    • 17 sierpnia 2013 at 20:16
      Permalink

      Robiliśmy to kiedyś za pomocą własnego filtra do Solr, działającego w oparciu o zmodyfikowany słownik Morfologika. Możesz spróbować ze stemplem lub właśnie morfologikiem, ale nie sądzę, abyś dostał w 100% takie rezultaty, jakich oczekujesz.

      Reply
  • 28 października 2013 at 10:25
    Permalink

    Można też tak 🙂

    Reply
  • 28 października 2013 at 10:25
    Permalink

    filter class=”solr.ASCIIFoldingFilterFactory”

    Reply
  • 6 kwietnia 2014 at 13:10
    Permalink

    Jeżeli chodzi o polskie znaki i przeróbkę Morfologika:

    Jeszcze nie próbowałem przerobić słownika, ale wydaje mi się, że da się to zrobić dość łatwo.

    To co potrzebujemy to oczywiście sam oryginalny słownik, który jest postaci mniej więcej takiej:

    królowalibyście królować verb:pot:pl:m1.p1:sec:imperf:nonrefl
    królowalibyśmy królować verb:pot:pl:m1.p1:pri:imperf:nonrefl

    tutaj nieco większy wycinek: https://gist.github.com/noisy/10005033
    a tutaj kompletne słowniki morfologika: http://sourceforge.net/projects/morfologik/files/morfologik/

    Wydaje mi się, że wystarczyłoby wszystkie wpisy, które w pierwszej kolumnie posiadają wyraz z polskimi ogonkami, zduplikować i pierwszy wyraz zamienić na słowo bez polskich liter.

    Jeżeli to by wystarczyło, to należałoby dalej już tylko skompilować słownik do postaci binarnej, gdyż to właśnie w takim formacie występuje on w pakietach używanych przez SOLRa.

    Skrypty znalezione w tym repo: https://github.com/morfologik/morfologik-scripts powinny wykonywać dokładnie tą robotę 🙂

    Potem należałoby już chyba tylko zbudować sobie całą biblioteczkę: https://github.com/morfologik/morfologik-stemming

    albo prościej (to chyba też powinno zadziałać), rozpakować jara (czyli zipa) i podmienić stosowny plik binarny.

    Czy to zadziała? Nie wiem… jak i mi się uda, to dam znać 🙂

    Reply
  • 21 grudnia 2015 at 00:11
    Permalink

    Bardzo przydatny artykuł. Spróbuję na początek opcję morfologik. Zastanawiam się, czy jest możliwość dodawania własnych wpisów do słownika morfologik. Może być przydatne np. w wypadku rzadkich słów.

    Reply
    • 6 marca 2016 at 22:24
      Permalink

      Zdecydowanie się zgadzamy – post opublikowany był trzy lata temu i dotyczył wersji 4.0 Solr 🙂

      Reply
  • 10 marca 2016 at 09:09
    Permalink

    Witam,

    Czy objawem poprawnie zainstalowanego słownika powinno być że jeśli w panelu wyszukiwania solr wpisze np „wiec”, a produkt ma w nazwie „więc” to znajdzie? Czy również zostanie wyszukana odmiana tak jak w artykule „urodzić, urodzony itp”? I jeszcze do samej aplikacji czy te biblioteki .jar wystarczy skopiować do katalogu z libami czy trzeba to rozpakowywać?

    Reply
    • 10 marca 2016 at 09:35
      Permalink

      Ten post ma już trochę lat, widać, że trzeba napisać coś nowego 🙂 Ale do rzeczy. Niżej w komentarzach jest link do opisu wersji 5.3, 5.5 jest analogicznie. Analizator polski da radę ze słowami „urodzić, urodzony”. Do usuwania polskich znaków i zamiany ich na te z podstawowego zbioru ASCII – ładnie opisane jest to tu: https://wiki.apache.org/solr/LanguageAnalysis#Ignoring_Diacritics

      Reply
  • 10 marca 2016 at 09:49
    Permalink

    A czy przy instalacji np. słownika Morfologik te biblioteki .jar trzeba rozpakować, czy wystarczy dodać do katalogu z bibliotekami? Czy jest szansa że opisany tutaj sposób zadziała dla wersji 5.5? Niby kopiuje te biblioteki ale ciągle czegoś brakuje w stylu org.apache.lucene.itp.biblioteka a jak rozpakować taki .jar to widać że ta klasa tam jest

    Reply
    • 10 marca 2016 at 10:11
      Permalink

      Nie, nie trzeba, wystarczy wrzucić pliki jar i Solr załaduje wszystko, tak jak powinien.

      Reply
  • 15 marca 2016 at 09:48
    Permalink

    Po zainstalowaniu słownika Hunspell mam taki problem kiedy wpiszę frazę np. madonna na pierwszych kilku frazach mam w tytule produktu madonna, trochę niżej już pojawiają się odmiany np. madonny itp. jeszcze dalej znowu produkty z frazą madonna. Jak zrobić aby najpierw były te najbardziej pasujące. Kombinowałem z premiowaniem fraz dismax itp. z ustawieniami typu w schemie positionIncrementGap

    Reply
  • 1 kwietnia 2016 at 08:48
    Permalink

    Jak można ułożyć zapytanie żeby znalazło frazę błędnie wpisaną np „hary poter” – suggester nic nie podpowiada albo jakieś inne nieprzydatne słowa, a sama fraza błędnie wpisana nic nie zwraca. Instalowałem również słownik Hunspell polski i angielski. Co jeszcze można do tego wykorzystać?

    Reply
    • 2 kwietnia 2016 at 17:49
      Permalink

      Suggester działa na podstawie danych, które są w indeksie. I to jest cały problem. Jeżeli dane w indeksie nie są najlepsze, lub zawierają dużo słów o podobnej pisowni, wtedy Suggester też będzie działać kiepsko. Zacząłbym jednak od suggestera z FuzzyLookupFactory i z DocumentDictionaryFactory, najlepiej oparte o pole, które jest wyczyszczone ze stop words, nie ma stemmingu, ewentualnie lowercase.

      Reply
  • 17 lipca 2017 at 13:39
    Permalink

    Witam mam problem z Solr Admin przy tworzeniu indeksu nie działa mi Reload” zapala sie na czerwono i wyskakuje błąd:

    SolrCore Initialization Failures

    blog: org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: Could not load conf for core blog: java.io.IOException: Error parsing synonyms file:
    w skrócie zainstalowałem :
    pip install django-haystack==2.4.0
    pip install pysolr==3.3.2
    W settings.py umieściłem ‚haystack’ oraz HAYSTACK_CONNECTIONS http://wklej.org/id/3216871/

    Utworzyłem search_indexes.py http://wklej.org/id/3216875/
    post_text.txt http://wklej.org/id/3216881/
    W solr -> conf solrconfig.xml http://wklej.org/id/3216882/ i schema.xml http://wklej.org/id/3216886/
    Do tego momentu wszystko działa (reload również) nawet dodane przez Add Core ” blog ” jest widoczny natomiast według książki z której się uczę zmieniam w pliku schema.xml za pomocą:
    python manage.py build_solr_schema kopiuje wszystko od <?xml version.. aż do http://wklej.org/id/3216890/ wklejam zapisuje ponownie uruchamiam java -jar start.jar i wyskakuje błąd a poniżej Add Core znika utworzony przeze mnie blog.

    Reply
    • 17 lipca 2017 at 22:21
      Permalink

      Cześć. Z błędu, który wkeliłeś wynika, że jest problem z plikiem z synonimami. Sprawdź pliki z synonimami (zauważyłem synonyms.txt i index_synonyms.txt, może jest coś więcej) i zobacz, czy mają na pewno dobry format i czy są zapisane przy wykorzystaniu UTF-8.

      Reply
  • 23 lipca 2017 at 20:53
    Permalink

    Sprawdzałem pliki w conf : protwords.txt, stopwords.txt, synonyms.txt oraz w lang stopwords_en.txt w settings sublime wychodzi „default_encoding”: „UTF-8″, czyli jest ok? dodałem w schema.xml encoding=”UTF-8” tylko teraz chciałbym się zapytać jak ma wyglądać plik synonyms.txt wrzuciłem coś takiego http://www.wklej.org/id/3223174/ dalej znalazłem z polskimi słówkami http://wklej.org/id/3223181/ utworzyłem i zapisałem to w stopwords_pl.txt .
    W schema.xml dodałem

    oraz :

    Do folderu solr-4.10.4/example/lip wrzuciłem ucene-analyzers-morfologik-4.0.jar, apache-solr-analysis-extras-4.0.jar, morfologik-fsa-1.5.2.jar, morfologik-polish-1.5.2.jar oraz morfologik-stemming-1.5.2.jar. ściągnięte z internetu.
    niestety wyskakuje mi błąd : blog: org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: Could not load conf for core blog: Unknown fieldType ‚text_pl’ specified on field text_pl. Schema file is /home/nowymint/Programy/solr-4.10.4/example/solr/blog/conf/schema.xml

    Pewnie coś namieszałem ale jestem dosyć świeży 🙂 i męcze się z tym dobry tydzień jeśli mógłbyś coś podpowiedzieć będę wdzięczny 🙂
    przerobiony schema.xml http://wklej.org/id/3223233/

    Reply
    • 23 lipca 2017 at 21:34
      Permalink

      Przydałby się pełny wyjątek z logów, będę wtedy w stanie powiedzieć coś więcej.

      Reply
    • 26 lipca 2017 at 12:35
      Permalink

      Z tego co widzę, to Solr marudzi, że nie widzi typu text_pl. I już chyba wiem dlaczego. Korzystasz z Solr 4.10 – definicja pól musi się znaleźć w sekcji , a definicja typów musi się znaleźć w sekcji . Z tego co widzę w schema.xml w poprzednim komentarzu, definicja typu text_pl wrzucona jest do sekcji . Przenieś ją do sekcji i Solr powinien wstać 🙂

      Reply
    • 27 lipca 2017 at 10:54
      Permalink

      Linia 30 w pliku synonimów wydaje się zła, najprawdopodobniej występują w niej białe znaki, które są usuwane, a tym samym synonim jest zły.

      Reply
  • 25 marca 2018 at 11:04
    Permalink

    Mam pytanie odnośnie Morfologika – używam Pythona, którego dopiero się uczę. W przypadku stemmowania dla słownika angielskiego (Lancaster stemmer) słowa są bezposrednio zamieniane na rdzeń po użyciu stemmera. W przypadku morfologika, outputem jest fragment słownika:
    >>> stemmer.stem([‚Ala ma kota’], parser)
    [(u’Ala’,
    {u’Al’: [u’subst:sg:acc:m1+subst:sg:gen:m1′],
    u’Ala’: [u’subst:sg:nom:f’],
    u’Alo’: [u’subst:sg:acc:m1+subst:sg:gen:m1′]}),
    (u’ma’,
    {u’mieć’: [u’verb:fin:sg:ter:imperf:refl.nonrefl’],
    u’mój’: [u’adj:sg:nom.voc:f:pos’]}),
    (u’kota’, {u’kot’: [u’subst:sg:acc:m1′], u’kota’: [u’subst:sg:nom:f’]})]

    Czy jest jakieś dodatkowe polecenie/sposób, żeby uzyskać od razu listę przyciętych wyrazów, zamiast powyższego wyniku?

    Reply

Pozostaw odpowiedź Marcin Mańk Anuluj pisanie odpowiedzi

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.