Návrh jak vyhledávat v textu - skloňování a časování

[xblaha]

Měl by prosím někdo nápad či odkaz na způsob, jak alespoň trochu rozumně vyhledávat ve velkém množství českého textu podle hledaného výrazu, kde hledaný výraz nemusí (bohužel ani nemůže) být ve stejném tvaru (pád, čas...), jako je výraz v hledaném textu?

Hledal jsem slovníky, dokonce jsem oslovil i Ústav pro jazyk český, ale výsledek veškerý nepraktický, prakticky žádný.

Děkuji za nápady

[Reklama]

[Pavel Stěhule]

Podívejte se jak je implementovaný fulltext v Postgresql a podpora češtiny na bázi ispellu https://forum.root.cz/index.php?topic=14943.0

[Filip Jirsák]

K tomu se používá lemmatizace – při indexování převedena všechna slova na základní tvar a pak hledáte základní tvary. Případně, pokud byste neměl možnost ovlivnit podobu indexu, můžete pro všechna slova v dotazu vygenerovat všechny jejich možné tvary a pak hledat to.

Vše jsou to běžně používané postupy, takže stačí jenom správně hledat. Pokud nemáte nějaké specifické využití, použil bych nějaký už hotový fulltextový index s podporou češtiny. Např. Apache Solr, nebo pokud už máte data v PostgreSQL databázi, tak zmíněný fulltextový index PostgreSQL.

[Kada]

Stalo by za to trochu rozvest:
- "velkém množství českého textu" -- kolik zhruba dokumentu, jak jsou velke?
- jake dotazy se budou hledat? (kraticke 2-3 slovne dotazy vs cele dlouhe vety o desitkach slov)
- jakym zpusobem se maji vysledky radit? (pouze podle textove relevance/shody s dotazem, nebo i neceho dalsiho)

Reseni zalozene na lemmatizaci/ispelech pocitaji s indexovanim dokumentu pres slova. Kvalita hledani pro kratke dotazy nebyva dobra, zejmena pro to, ze lemmata/ohackovani nejsou jednoznacne a pokud generujete vsechny varianty, vybublaji zcela nerelevantni dokumenty.

Zvazil bych vygenerovani embdedingu z dokumentu/dotazu pomoci jazykoveho modelu a pouziti podobnostniho hledani. Nevyhoda je vyrazne vyssi narok na zdroje (CPU/GPU/RAM).

[xblaha]

Jedná se o DB (MS SQL), která obsahuje poměrně značné množství článků ve smyslu znalostní databáze, kterou si vytváří příslušné oddělení. A to (bohužel) ještě včetně příloh (PDF, DOCX atd.), ale to bych (snad) považoval za technikálii dostat z nich něco na způsob plain textu, který by následně prošel úplně stejným vyhledáváním...

Vyhledávaly by se právě podle krátkých řetězců, obvykle jedno až čtyři slova. Velmi zřídka podle více slov.

Řazení výsledků... ta logika už může být poměrně komplikovaná, protože počet shod v příslušném článku nemusí nutně znamenat, že se jedná o nejrelevantnější výsledek. Dalo by se do toho zařadit s určitou váhou i četnost zobrazení takových článků za např. poslední tři měsíce apod.

Nerozumím až tak návrhu "Zvazil bych vygenerovani embdedingu z dokumentu/dotazu pomoci jazykoveho modelu a pouziti podobnostniho hledani." Případné HW nároky bychom si vyřešili - na příslušné farmě máme výkonu dost

Stalo by za to trochu rozvest:
- "velkém množství českého textu" -- kolik zhruba dokumentu, jak jsou velke?
- jake dotazy se budou hledat? (kraticke 2-3 slovne dotazy vs cele dlouhe vety o desitkach slov)
- jakym zpusobem se maji vysledky radit? (pouze podle textove relevance/shody s dotazem, nebo i neceho dalsiho)

[Reklama]

[Kada]

...
poměrně značné množství článků
...

To jsme se moc od "velkém množství českého textu" neposunuli. Kolik to je, 10k, 10M, 10G clanku?

Řazení výsledků... ta logika už může být poměrně komplikovaná, protože počet shod v příslušném článku nemusí nutně znamenat, že se jedná o nejrelevantnější výsledek. Dalo by se do toho zařadit s určitou váhou i četnost zobrazení takových článků za např. poslední tři měsíce apod.

Textova relevance je trochu slozitejsi obor nez "pocet shod". Asi bych nedoporucil to vymyslet/programovat, ale nechal to na pouzitem vyhledavaci, Elasticsearch napriklad pouziva variantu BM25.

Pokud mate dalsi atributy (jako treba cetnost zobrazeni clanku), tim lepe. Musite nicmene vymyslet formuli, jak z vektoru atributu, vcetne textove relevance, vydestilujete radici kriterium. Typicky postup je:
dotaz->vyhledavaci stroj vrati N matchujicich dokumentu->pretrideni N dokumentu->vyber top K, ktere se zobrazi.
Velke vyhledavace pouzivaji na onu formuli strojove uceni, da se nicmene zacit i s z prstu vycucanym vzorcem typu:
("textove score"+(log("pocet zobrazeni"))

Nerozumím až tak návrhu "Zvazil bych vygenerovani embdedingu z dokumentu/dotazu pomoci jazykoveho modelu a pouziti podobnostniho hledani."

1. Predpocitate embedding pro dokumenty pomoci jazykoveho modelu, aka cerne skrinky, ktera z textu v cestine vyrobi vektor cisel pevne delky (napriklad 1024 8bit cisel).
2. Pomoci stejneho modelu spocitate embedding/vektor dotazu
3. Podobnostnim vyhledavanim vyhledate dokumenty nejpodobnejsi vektoru dotazu. Podobnosti se typicky mysli kosinova podobnost.

Pro pocitani vektoru, mate-li nekonecne zdroje a spoustu casu, lze pouzit OpenAI embedings jako sluzbu. Na vlastnim HW pro cestinu napriklad Small-E-Czech.
Jako podobnostni databazi muzu doporucit Faiss. Ale i dnesni nektere relacni databaze umi podobnostni hledani.

Nicmene, kdyz odhlednu od toho, co pisu, doporucil bych vyzkouset zminovany PostgreSQL/Elasticsearch se slovnikem typu ispell. Pokud to bude stacit, konec pribehu. Pokud ne, viz vyse .

[_Jenda]

Byly tady o tom skvělé články, ale implementovat to od nuly je tak na rok práce imho.

https://www.root.cz/clanky/jazykove-modely-pro-vyhledavani-naucte-stroj-chapat-vyznam-jazyka/
https://www.root.cz/clanky/rychla-oprava-dotazu-ve-vyhledavaci-pomoci-neuronovych-siti/

Lemmatizér byl nějaký fakt dobrý od ÚFALu, ale nevím jestli český model k tomu nebyl jen pro nekomerční použití.

[Logik]

V pythonu máš balíček hunspell, který stačí nakrmit slovníkem z openoffice a použít na tu lematizaci. Mám s tím poměrně dobré zkušenosti.Pro samotné vyhledávání pak používám postgresql (vlastní lematizaci děláme kvůli tomu, že ne všude jsou dostupné či instalovatelné vlastní slovníky) a funguje to více než dobře.
V MS SQL je nějaký fulltext také:https://learn.microsoft.com/en-us/sql/relational-databases/search/full-text-search?view=sql-server-ver16nic o něm nevím, ale asi přinejmenším s tím externím hunspell stemmerem by Ti měl dát rozumný výsledky.

[Filip Jirsák]

MS SQL má v sobě také fulltextový index – ale měli jsme s ním dost špatné zkušenosti (na druhou stranu, už je to dost dávno).

Určitě bych nevymýšlel vlastní řešení, to by bylo na dlouho. Buď použijte nějaký už hotový vyhledávač, do kterého jenom budete cpát dokumenty – ať už v on-premise řešení nebo jako službu (třeba Algolia). Pokud to potřebujete integrovat do svého řešení (tedy napojit to do vlastního frontendu), použijte alespoň už hotový fulltextový vyhledávač, který si poradí s těmi dokumenty. Například zmíněný Apache Solr, který podporuje PDF, Word a další formáty. Alternativou by mohl být Sphinx, ale ten asi není tak známý a má divnou licenci (nikdy jsem ho nepoužil, takže nevím, co umí).