Frankfurto studija daugiakalbiams skaitmeniniams projektams +49 69 95209894 [email protected] Pirm–Penk 9–17 val. Klientų sritis →
LietuviųLT

Valiuta

Užsienio valiutos sumos yra neįpareigojančios orientacinės vertės; atsiskaitymas atliekamas eurais.

2026-03-10 · Redakcija Baduno · 24 blog.readMin · Blogas ir žinios

Vidinė daugiakalbė paieška: kai naudotojai ieško savo kalba

Daugiakalbė vidinė paieška nėra prabanga, o būtinybė tarptautinėms svetainėms. Sužinokite, kodėl standartiniai sprendimai žlunga, kaip įveikti kalbai būdingas kliūtis, tokias kaip umliautai, sudurtiniai žodžiai ir rašybos klaidos, bei kokia strategija jūsų vartotojai kiekviena kalba ras norimus rezultatus – praktiškai ir be klaidingų pažadų.

Didinamasis stiklas virš kortelių simbolizuoja vidinę paiešką įvairiomis kalbomis.

Kodėl standartinė paieška tarptautiniu mastu žlunga

Daugiakalbių svetainių valdytojai dažnai pasitiki standartine savo platformos paieškos funkcija – ar tai būtų Elasticsearch, MySQL FULLTEXT ar vidinis modulis. Šie standartiniai sprendimai dažnai yra orientuoti į anglų kalbą ir nepakankami tarptautiniams poreikiams. Jie taiko paprastą tokenizaciją (žodžių skaidymą pagal tarpus), ignoruoja kalbai būdingą normalizaciją ir nepalaiko nei stabdomųjų žodžių sąrašų, nei sinonimų skirtingoms kalboms. Rezultatas: naudotojai, ieškantys gimtąja kalba, gauna nereikšmingus rezultatus arba visai nieko – ir palieka svetainę.

Tipiška problema – diakritinių ženklų tvarkymas: standartinė angliškoji analizė nepašalina kirčių (arba pašalina neteisingai), todėl paieška pagal „cafe“ neranda „café“. Umlautai, tokie kaip „ö“ ar „ü“, dažnai traktuojami kaip „o“ ir „u“ – praktiškai tai reiškia, kad „München“ neberandamas, kai naudotojas įveda „Munchen“. Taip pat sudurtiniai žodžiai (pvz., „Lebensversicherung“) nėra skaidomi; ieškant „Versicherung“ terminas nerandamas, nors jis ir yra.

Sprendimas: naudokite paieškos sistemą, leidžiančią kalbai būdingą analizę kiekvienai kalbai. Elasticsearch siūlo kalbinius analizatorius (pvz., vokiečių, prancūzų, lenkų), kurie integruoja stebėjimą (stemming), stabdomuosius žodžius ir Unicode normalizaciją. Kiekvienai kalbai sukonfigūruokite atskirą indeksą arba naudokite kalbai būdingus analizės filtrus. Įjunkite Unicode normalizaciją (pvz., ICU-Folding), kad suvienodintumėte diakritinių ženklų ir umlautų variantus. Išbandykite paiešką su realiais paieškos raktažodžiais iš savo žurnalų – pamatysite, kiek rezultatų anksčiau buvo prarasta.

Rekomendacija: peržiūrėkite dabartinę paieškos konfigūraciją. Naudokite kalbai būdingą analizatorių, kuris moka tiek tokenizaciją, tiek stebėjimą (stemming) kiekvienai kalbai. Atlikite simbolių normalizaciją (ä→ae ar ä→a? Pasirinkite pagal tikslinę kalbą). Apibrėžkite stabdomųjų žodžių sąrašus visoms kalboms. Be šių pritaikymų jūsų vidinė paieška išliks kliūtimi tarptautiniams naudotojams – ir stabdys pardavimus.

Kalbai būdingi iššūkiai: diakritiniai ženklai, umlautai ir sudurtiniai žodžiai

Be umlautų (ä, ö, ü) ir diakritinių ženklų (kirčiai, cedilė, tildė) sudurtiniai žodžiai yra viena didžiausių kliūčių daugiakalbei paieškai. Ypač germanų kalbose (vokiečių, olandų, skandinavų) daiktavardžiai dažnai sujungiami į ilgus terminus: „Versicherungspflicht“, „Arbeitsunfähigkeitsbescheinigung“. Naudotojas, ieškantis tik „Versicherung“, vis tiek tikisi rezultatų. Standartinė tokenizacija neskiria – žodis lieka bloku.

Diakritiniai ženklai ir umlautai reikalauja normalizacijos, kuri gali skirtis priklausomai nuo kalbos. Prancūzas ieško „café“ su akūtu, bet gali įvesti „cafe“ – panašiai ispanas „años“ vs. „anos“ (kitas žodis!). Čia padeda ASCII-Folding, kuris diakritinius ženklus paverčia pagrindiniais (é→e, ñ→n). Tačiau prarandamas kalbos specifiškumas: vokiečių kalboje „ß“ turėtų tapti „ss“, o ne „s“. Vien tik ASCII-Folding yra per daug bendrinis.

Sudurtiniams žodžiams rekomenduojama naudoti dekompounderį. Elasticsearch siūlo „compound_word“ token filtrą, kuris skaido žodžius pagal žodyną. Pavyzdžiui: „Krankenversicherung“ padalijamas į „Kranken“ ir „Versicherung“. Taip pat būtina sinonimų paieška: „Handy“ ir „Mobiltelefon“ Vokietijoje yra tapatūs, Austrijoje sakoma „Handy“, o „Mobiltelefon“ retas. Tvarkykite sinonimus kalbai būdingai faile (pvz., synonym.txt) ir nurodykite juos analizatoriuje.

Rekomendacija: kiekvienai kalbai nuspręskite, kaip elgtis su diakritiniais ženklais: arba Folding (skaidymas), arba išlaikymas. Vokiečių kalbai: įgyvendinkite umlautų plėtrą (ä→ae, ö→oe, ü→ue) arba normalizaciją į pagrindines raides (ä→a) – priklausomai nuo duomenų. Kiekvienai kalbai sudarykite sinonimų sąrašą ir išbandykite dažniausius paieškos žodžius. Vokiečių sudurtiniams žodžiams integruokite dekompounderį, pvz., „word_delimiter_graph“ arba „dictionary_decompounder“. Be šių pritaikymų svarbus turinys lieka nematomas.

Dėmesio: dėl sinonimų sąrašų pasikonsultuokite su teisininkais dėl prekių ženklų teisių. Ir: išbandykite paieškos kokybę su reprezentatyviu užklausų žurnalu – tik taip pamatysite optimizavimo galimybes.

Atidarytas kortelių katalogo stalčius, tradicinė paieškos sistema bibliotekose.

Stemming ir lematizacija pagal kalbą: metodai ir apribojimai

Stemming ir lematizavimas yra pagrindiniai metodai, skirti sumažinti žodžių formas iki bendros bazės. Stemming veikia taisyklėmis pagrįstai ir nukerta galūnes (pvz., „laufen“ → „lauf“). Lematizavimas naudoja žodynus ir morfologinę analizę, kad nustatytų pagrindinę formą (lemą) („lief“ → „laufen“). Kalboms su stipria linksniavimo sistema, pvz., vokiečių, suomių ar rusų, lematizavimas yra pranašesnis, bet reikalauja daugiau skaičiavimo išteklių.

Stemming ribos: Per didelis redukavimas (overstemming) sukelia klaidingai teigiamus rezultatus – pvz., kai „Computer“ ir „computational“ redukuojami iki to paties kamieno, nors semantiškai skiriasi. Nepakankamas redukavimas (understemming) palieka susijusias formas atskiras („laufen“ ir „läuft“ lieka atskirti). Algoritmo pasirinkimas priklauso nuo kalbos: vokiečių kalbai Snowball stemeris duoda gerus rezultatus, lenkų kalbai geriau naudoti Stempel arba Hunspell. Elasticsearch siūlo daugeliui kalbų iš anksto sukonfigūruotus kalbos analizatorius, kuriuose jau yra tinkami stemeriai.

Praktinis įgyvendinimas: Kiekvienai kalbai naudokite rekomenduojamą analizatorių. Pavyzdžiui, vokiečių kalbai Elasticsearch nustatymuose naudokite „german“, kuris apima Snowball stemerį ir sustabdymo žodžių sąrašą. Prancūzų kalbai – „french“ su lengvu stemmingu. Patikrinkite, ar randamos norimos žodžių formos – atkreipkite dėmesį į klaidingai teigiamus rezultatus. Sudarykite „protected words“ sąrašą, kurių nereikia steminti (pvz., produktų pavadinimai, tikriniai vardai).

Rekomendacija: Įvertinkite stemming vs. lematizavimą pagal savo turinį. El. prekybai su daugybe produktų pavadinimų lematizavimas dažnai tinkamesnis (pvz., vokiečių k.: „Küche“ vs. „kochen“). Naudokite esamas bibliotekas, tokias kaip ICU4J arba Stanford CoreNLP lematizavimui, tačiau nepamirškite našumo sąnaudų. Dokumentuokite savo sprendimą kiekvienai kalbai ir reguliariai tikrinkite paieškos kokybę. Nėra vieno sprendimo visiems: kas tinka anglų kalbai, gali būti visiškai netinkama suomių kalbai. Išbandykite su realiomis vartotojų užklausomis.

Pastaba: Sudėtingo lematizavimo diegimas reikalauja kalbinių žinių arba išorinių paslaugų. Pasikonsultuokite su kalbos specialistu – arba pasirinkite gerai sureguliuotą stemerį kaip pragmatišką kompromisą.

Sinonimai ir nuo kalbos priklausančios žodžių variacijos: nustatymas ir priežiūra

Keliakalbė vidinė paieška turi atsižvelgti į kalbai būdingus sinonimus ir žodžių variantus, kad pateiktų aktualius rezultatus. Vartotojai tikisi, kad naudodami skirtingus terminus ras tą patį – pavyzdžiui, „Schuhe“ ir „Treter“ vokiečių kalboje arba „shoes“ ir „trainers“ anglų kalboje. Iššūkis yra tvarkyti sinonimus ne tik pagal kalbą, bet ir pagal kontekstą. Paprasto sąrašo dažnai nepakanka, nes reikšmės skiriasi priklausomai nuo srities.

Nustatymui rekomenduojama daugiapakopė metodika: pirmiausia išanalizuokite esamas paieškos užklausas ir nustatykite dažnas terminų poras, nukreiptas į tuos pačius produktus ar turinį. Tam naudokite svetainės paieškos žurnalo duomenis. Papildykite juos pramonėje įprastais sinonimais – pavyzdžiui, iš tezaurų arba atlikdami rankinį tyrimą. Tada paieškos indekse sinonimai turėtų būti saugomi kaip lygiaverčiai žetonai. Atkreipkite dėmesį, kad sinonimai neturėtų sumažinti aktualumo: pavyzdžiui, paieška pagal „laptop“ neturėtų automatiškai vienodai traktuoti „notebook“ ir „tablet“, o pirmenybę teikti pagal vartotojo intenciją.

Sinonimų priežiūra yra nuolatinis procesas. Planuokite reguliarias peržiūras – pavyzdžiui, kas ketvirtį – ir įtraukite vietinius gimtakalbius. Kalbos variantai, tokie kaip austriškas „Marille“ vietoj „Aprikose“ ar šveicariškas „Velo“ vietoj „Fahrrad“, turi būti atskirai fiksuojami. Naudokite sinonimų valdymo įrankį, kuris centralizuotai valdo pakeitimus ir juos perkelia į visus kalbų indeksus. Kiekvieno pakeitimo poveikį išbandykite A/B testais su reprezentatyvia paieškos užklausų imtimi.

Praktika rodo, kad sinonimų valdymas gali sumažinti nulinės paieškos rezultatų dalį 20–30 procentų, priklausomai nuo pramonės šakos ir kalbų apimties. Tačiau atminkite, kad sinonimai nėra vienintelis paieškos trūkumų sprendimas: jie turi būti derinami su kamienavimu, neapibrėžtąja paieška ir diakritinių ženklų tolerancija. Reguliarus derinimas su SEO komanda užtikrina, kad sinoniminiai terminai būtų įtraukti ir į turinio kūrimą. Teisiniu požiūriu reikia patikrinti, ar sinonimai nepažeidžia trečiųjų šalių prekių ženklų teisių – dėl to konsultuokitės su teisės skyriumi.

Rašybos klaidų tolerancija ir neapibrėžtoji paieška per kalbas

Vartotojai dažnai įveda klaidingus simbolius – ypač mobiliuosiuose įrenginiuose. Todėl keliakalbė paieška turi atpažinti rašybos klaidas, neteisingus įvedimus ir alternatyvias rašybos formas. Neapibrėžtoji paieška yra patikimas būdas rasti panašius žodžius. Tačiau reikalavimai labai skiriasi priklausomai nuo kalbos. Trumpose kalbose, pvz., anglų, dažnai pakanka 1–2 redagavimo atstumų (Levenshteino atstumas), o kalbose su daugybe ilgų sudurtinių žodžių, pvz., vokiečių ar olandų, gali prireikti didesnės tolerancijos.

Įgyvendinant reikia naudoti nuo kalbos priklausančius parametrus: kiekvienai kalbai nustatykite maksimalų simbolių pakeitimų procentą – paprastai nuo 10 iki 20 procentų žodžio ilgio. Atkreipkite dėmesį, kad neapibrėžtoji paieška nepateiktų per daug nereikšmingų rezultatų. Tinkama riba – leisti ne daugiau kaip tris simbolių pakeitimus vienam žodžiui. Kalbose su diakritiniais ženklais, pvz., prancūzų ar ispanų, turite integruoti diakritinių ženklų toleranciją: „café“ turėtų būti randamas ir įvedus „cafe“. Tai pasiekiama indekse diakritinius ženklus apdorojant kaip atskirą normalizavimo taisyklę.

Kitas aspektas – rašybos klaidų tolerancija tarp kalbų. Pavyzdžiui, vokiečių vartotojas gali netyčia įvesti anglišką žodį. Čia padeda keliakalbis indeksas, sujungiantis terminus iš visų kalbų – tačiau su kalbos žymėjimu, kad būtų išlaikytas aktualumas. Išbandykite savo paiešką su tikromis rašybos klaidomis iš paieškos žurnalo: rinkite klaidingus įvedimus kelis mėnesius ir sukurkite tekstyną. Pagal šiuos duomenis koreguokite tolerancijos ribas.

Praktiniam įgyvendinimui rekomenduojame nustatyti dviejų etapų paiešką: pirmiausia tikslią paiešką, tada neapibrėžtąją, jei tiksli neranda rezultatų. Derinkite tai su pasiūlymais („Ar norėjote?“) atitinkama kalba. Atminkite, kad per didelė rašybos klaidų tolerancija gali pabloginti našumą – atlikite apkrovos testus. Teisiniu požiūriu patikrinkite, ar panašių terminų atpažinimas neaplenkia prekių ženklų teisių; prireikus kreipkitės į teisininkus.

Indeksavimo strategijos: atskiri vs. kombinuoti indeksai pagal kalbą

Sprendimas tarp atskirų ir kombinuotų paieškos indeksų pagal kalbą turi didelį poveikį keliakalbės paieškos našumui, aktualumui ir priežiūros paprastumui. Atskiras indeksas kiekvienai kalbai reiškia: kiekviena kalba turi savo indeksą su savo analizės taisyklėmis (kamienavimas, sustabdymo žodžiai, tokenizatorius). Tai suteikia maksimalią kontrolę ir tikslią kalbos specifiką. Kombinuotas indeksas sujungia visas kalbas į bendrą indeksą, kiekvieną dokumentą pažymint kalbos žyma.

Patirtis rodo, kad atskiras indeksas ypač tinka svetainėms su aiškiai atskirtomis kalbų versijomis (pvz., atskirais subdomenais ar poaplankiais). Privalumai: individualus optimizavimas kiekvienai kalbai, geresnis aktualumas dėl kalbai būdingo kamienavimo ir paprastesnė priežiūra atnaujinant kalbas. Trūkumai: didesni išteklių poreikiai, nes lygiagrečiai veikia keli indeksai, ir sudėtingesnės keliakalbės paieškos funkcijos, jei reikia. Kombinuotas indeksas, priešingai, sumažina administravimo naštą ir leidžia atlikti keliakalbę paiešką – pavyzdžiui, kai vartotojas ieško vokiškai, bet nori gauti ir angliškus rezultatus. Tačiau dėl to dažnai nukenčia tikslumas, nes bendras kamienavimas retai optimaliai aprėpia visas kalbas.

Praktikoje hibridinė strategija dažnai būna geriausias sprendimas: naudokite kombinuotą indeksą visateksčiai paieškai, tačiau papildykite jį kalbai būdingais laukais. Paieškos užklausos metu nustatoma vartotojo kalba – per naršyklės nustatymus ar geolokaciją – ir atitinkamai koreguojamas aktualumo svarbos koeficientas. Dokumentai, atitinkantys vartotojo kalbą, teikiami pirmenybę. Be to, kiekvienai kalbai galite sugeneruoti atskirus analizatoriaus tokenus ir saugoti juos indekse. Taip gaunate abiejų pasaulių privalumus.

Konkreti rekomendacija: pradėkite nuo kombinuoto indekso ir tikslinkite aktualumą naudodami didinimo veiksnius. Stebėkite vidutinę paspaudimų poziciją pagal kalbą – jei vienos kalbos rodikliai yra žymiai prastesni, verta apsvarstyti atskirą indeksavimą. Planuokite reguliarius indekso optimizavimus, pavyzdžiui, po turinio atnaujinimų. Teisiniu požiūriu reikia atkreipti dėmesį, kad asmens duomenys paieškos indeksuose gali būti tvarkomi tik laikantis duomenų apsaugos reikalavimų – dėl to derėtų tartis su savo duomenų apsaugos skyriumi.

Teleskopas, nukreiptas į knygų lentyną, simbolizuoja tikslinę informacijos paiešką.

Užklausos analizė: kalbos atpažinimas ir paieškos termino analizė

Norint sukurti vartotojui patogią keliakalbę paiešką, būtina patikimai atpažinti paieškos termino kalbą. Praktikoje sistemos dažnai naudoja simbolių rinkinio analizės (pvz., Unikodo intervalai: kirilica, graikų, lotynų su diakritiniais ženklais) ir žodynais pagrįstų detektorių derinį. Populiarus metodas – n-gramų naudojimas: tam tikrų raidžių sekų dažnis (pvz., „sch“ vokiečių kalboje, „ou“ prancūzų) atskleidžia kalbą. Pasirūpinkite, kad atpažinimas veiktų ir su trumpais įvesties žodžiais (1–3 simboliai) – čia padeda išankstinė klaviatūros išdėstymo atpažinimas arba kiekvienos kalbos sustabdymo žodžių sąrašas.

Po kalbos atpažinimo seka analizė: normalizuokite terminą prieš perduodami jį paieškos sistemai. Pašalinkite nereikalingus tarpus, konvertuokite HTML objektus ir atsižvelkite į diakritinius variantus. Pavyzdys: vartotojas ieško „café“ – jūsų paieška turėtų rasti ir „cafe“. Todėl diegkite taisyklėmis pagrįstą perrašymą: ne tiesiog šalinkite kirčio ženklus, o papildykite indeksą alternatyviomis rašybos formomis. Vokiški umlautai (ä, ö, ü) ir ß paliekami originalūs, tačiau sukuriamos ir perrašymo formos (ae, oe, ue, ss). Sudėtiniams žodžiams, pvz., „Lebensversicherungsgesellschaft“, naudinga segmentuoti į atskirus žodžius, kad būtų rasta dalinių atitikmenų.

Praktinis pavyzdys: prancūzų vartotojas ieško „hôtel paris“ – kalbos atpažinimas turėtų atpažinti prancūzų kalbą, o analizė konvertuoja „hôtel“ į indeksuotą formą (pvz., „hotel“) ir prideda sinonimų, tokių kaip „logement“. Žodžiai su brūkšneliu ar apostrofu (pvz., „l'école“, „know-how“) taip pat turi būti suskaidyti. Kiekvienai kalbai naudokite atskirą normalizavimo procedūrą: vokiečių kalbai žodžius geriausia iš anksto apdoroti Snowball kamienavimo algoritmu, o turkų kalbai reikia specialios didžiųjų/mažųjų raidžių tvarkymo (be taško i).

Rekomendacija: savo paieškos architektūroje sukurkite kelių lygių atpažinimo procesą – pradėkite nuo klaviatūros išdėstymo testų (jei įvestis atliekama klaviatūra), tada simbolių rinkinio analizę, po to n-gramų atitikmenis. Atsarginis variantas: jei patikimas atpažinimas neįmanomas (pvz., su skaičiais ar trumpais žodžiais), paklauskite vartotojo arba naudokite numatytąją svetainės kalbą. Patikrinkite atpažinimo tikslumą naudodami realias paieškos užklausas iš savo žurnalų ir iteratyviai koreguokite taisykles. Teisės patarėjas turėtų įvertinti, ar paieškos užklausų saugojimas atitinka duomenų apsaugos reikalavimus.

Rezultatų reitingavimas: aktualumo veiksniai daugiakalbėse situacijose

Paieškos rezultatų reitingavimas daugiakalbėje aplinkoje iš esmės skiriasi nuo vienkalbės paieškos. Turite vertinti ne tik dokumento aktualumą pagal užklausą, bet ir užtikrinti, kad rezultatai būtų pirmenybę teikiami teisinga kalba. Praktikoje patyrę operatoriai indeksus skirsto pagal kalbas, kad reitingavimas vyktų tik kalbos indekso viduje. Taip išvengiama, kad angliškas rezultatas vokiškai užklausai atsidurtų aukštai vien todėl, kad jame yra tas pats terminas.

Klasikiniai reitingavimo veiksniai – TF-IDF, BM25 ar modernūs neuroniniai metodai – skaičiuojami atsižvelgiant į kalbą. Stop žodžiai skiriasi priklausomai nuo kalbos („der“, „die“, „das“ vokiečių vs. „the“ anglų) ir turėtų būti atitinkamai pažymėti indekse. Taip pat įtakos turi žodžių ilgis: vokiški sudurtiniai žodžiai, tokie kaip „Donaudampfschifffahrtsgesellschaftskapitän“, turi didelį savąjį aktualumą, o kitose kalbose ilgį reikia normalizuoti. Įprastas reitingavimas pervertintų tokius ilgus žodžius – kompensuokite tai logaritminiu žodžio ilgio svoriu.

Sinonimai ir žodžių variantai taip pat turi įtakos reitingavimui. Jei vartotojas ieško „Handy“, o jūsų indekse yra „Mobiltelefon“, rezultatas neturėtų būti prarastas. Sinonimams priskirkite pagerinimo koeficientą (pvz., 0,8 tiksliam atitikmeniui, 0,5 sinonimui). Užtikrinkite, kad šie koeficientai būtų sukonfigūruoti pagal kalbą: „iPhone“ vokiečių kalboje yra pastovus terminas, o prancūzų kalboje dažnai vartojamas sinonimas „téléphone intelligent“. Tikrinkite žurnalus, kad nustatytumėte dažnas sinonimų poras.

Konkretus pavyzdys: Italijos vartotojas ieško „scarpe da corsa“ (bėgimo bateliai). Jūsų reitingavimas pirmiausia turėtų pateikti itališkus produktų puslapius su tiksliu atitikmeniu, po to puslapius su sinonimais („scarpe per running“) ir galiausiai poskyrius, kuriuose terminas yra aprašyme. Venkite, kad būtų rodomi angliški produktų puslapiai su „running shoes“ – tai klaidina vartotoją. Todėl prieš reitingavimą pritaikykite kalbos filtrą ir, jei reikia, išverskite paieškos terminą anglų indekso užklausai. Tam reikia lygiagretaus indekso arba užklausos vertimo, tačiau nenaudokite jo aklai: versti reikia tik tada, kai vartotojas aiškiai pasirenka kitą kalbą.

Rekomendacija: Sukurkite reitingavimo eigą: 1) kalbos atpažinimas, 2) kalbos filtras (leisti tik tos pačios kalbos rezultatus), 3) kalbai būdinga reitingavimo formulė su sinonimų pagerinimu, 4) prireikus atsarginė galimybė naudoti antrines kalbas, jei pirminėje kalboje nėra rezultatų. Matuokite 1–5 pozicijų paspaudimų dažnį ir nuosekliai optimizuokite svorius. Pasikonsultuokite su informacijos paieškos ekspertu, nes BM25 parametrų (k1, b) konfigūracija gali skirtis priklausomai nuo kalbos.

Naudotojo sąsaja: kalbos perjungimas ir standartinė paieška

Daugiakalbės paieškos naudotojo sąsaja visada turi aiškiai nurodyti, kuria kalba vartotojas ieško ir kaip gali perjungti. Šalia paieškos lauko arba jame patalpinkite kalbos perjungiklį, geriausia su šalies vėliavėlėmis ar kalbų santrumpomis (pvz., DE/EN/FR). Užtikrinkite, kad dabartinė kalba būtų paryškinta. Jei naudojate automatinį kalbos atpažinimą, parodykite vartotojui atpažintą kalbą – pavyzdžiui, mažu mygtuku su vėliavėle ir išskleidžiamuoju sąrašu, kad galėtų pataisyti. Pavyzdžiui: vartotojas įveda „hôtel“ – jūsų sistema atpažįsta prancūzų kalbą ir rodo „FR“ piktogramą. Jei klysta (pvz., esant vokiškam žodžiui „Hütte“), vartotojas gali akimirksniu perjungti į vokiečių kalbą.

Standartinė paieška – t. y. paieška be aiškaus kalbos pasirinkimo – turėtų remtis pagrindine svetainės kalba arba vartotojo naršyklės kalba. Praktikoje daugelis svetainių kaip pirmąjį užuominą naudoja naršyklės nustatymus (Accept-Language antraštę) kartu su IP geolokacija. Jei negalima vienareikšmiškai priskirti, pradėkite nuo kalbos, kuria yra didžioji dalis jūsų turinio. Venkite automatiškai perjungti į neteisingą kalbą – geriau pasirinkite neutralią parinktį ir palikite vartotojui pasirinkimą. Taip pat siūlykite parinktį „Visos kalbos“, kuri lygiagrečiai ieško visuose indeksuose, tačiau rezultatus rūšiuoja sugrupuotus pagal kalbą.

Konkretus sąsajos pavyzdys: Sukurkite paieškos juostą, kuri įvedant tekstą įgautų šalies kalbos spalvos rėmelį (pvz., mėlyna vokiečių, raudona anglų). Po paieškos lauku rodomos pirmosios trijų rezultatų peržiūros su maža kalbos etikete. Kalbos perjungiklis pateikiamas kaip išskleidžiamasis sąrašas arba plytelių eilutė. Vartotojui spustelėjus kitą kalbą, paieška automatiškai pakartojama atitinkamame indekse. Užtikrinkite pritaikytą prieinamumą: ekrano skaitytuvai turi galėti perskaityti dabartinę kalbą. Venkite techninių terminų, tokių kaip „NLP“ arba „tokenizavimas“ sąsajoje – vietoj to naudokite „Jūsų kalba: lietuvių | Keisti į …“.

Rekomendacija: Išbandykite sąsają su gimtakalbiais vartotojais iš kiekvienos tikslinės rinkos. Ypač patikrinkite, ar automatinis kalbos atpažinimas veikia tinkamai su mišriais įvesties duomenimis („Hotel Berlin“) ir ar perjungiklis yra intuityvus. Dokumentuokite elgseną tuo atveju, jei pasirinkta kalba nėra rezultatų: tokiu atveju pasiūlykite pranešimą, kad paiešką galima pakartoti visomis kalbomis. Teisiškai įvertinkite, ar kalbos pasirinkimo saugojimas slapukuose atitinka BDAR, ir prireikus gaukite sutikimą.

Daugiakalbė vidinė paieška nėra prabanga, o būtinybė tarptautinėms svetainėms. Sužinokite, kodėl standartiniai sprendimai žlunga, kaip įveikti kalbai būdingas kliūtis, tokias kaip umliautai, sudurtiniai žodžiai ir rašybos klaidos, bei kokia strategija jūsų vartotojai kiekviena kalba ras norimus rezultatus – praktiškai ir be klaidingų pažadų.

Veikimas: vėlavimas ir apkrova daugiakalbėse paieškos užklausose

Daugiakalbės paieškos veikimas labai priklauso nuo to, kaip struktūruojate indeksus ir apdorojate užklausas. Dažna klaida – vieno didelio indekso naudojimas visoms kalboms: jis greitai tampa nevaldomas, didina vėlavimą dėl didesnio duomenų kiekio ir apsunkina kalbai būdingus optimizavimus, pvz., skirtingus steminimo algoritmus. Praktikoje rekomenduojame kiekvienai kalbai sukurti atskirą indeksą arba bent jau skaidyti pagal kalbos kodą. Taip kiekvienam kalbos segmentui galite naudoti atskiras analizės grandines (tokenizaciją, stop žodžių filtrus, stemyklą), neužlaikydami užklausos dėl nereikšmingų kitų kalbų dokumentų.

Vėlavimą taip pat veikia užklausų analizė. Jei prieš pasirenkant tinkamą indeksą kiekvienai paieškai pirmiausia reikia atpažinti kalbą, esant dideliam srautui gali atsirasti delsų. Todėl naudokite greitą kalbos atpažinimą, pagrįstą keliais simboliais, arba kalbą nustatykite iš vartotojo profilio ar sąsajos kalbos pasirinkimo. Talpyklos kaupimas keliuose lygiuose – pvz., dažnai vartojamiems kiekvienos kalbos paieškos terminams – sumažina indekso serverio apkrovą ir pagerina atsako laiką pasikartojančioms užklausoms. Atminkite, kad daugiakalbėje aplinkoje talpykla turi būti kalbai specifinė: vokiečių paieškos talpyklos įrašas neturi būti netyčia pateiktas anglų paieškai.

Apkrovos paskirstymas – dar vienas kritinis aspektas: jei viena kalba sukuria žymiai daugiau paieškos apimties (pvz., anglų kalba tarptautinėje svetainėje), atitinkamas indeksas gali tapti kliūtimi. Todėl suplanuokite horizontalų mastelio keitimą, pateikdami indekso replikatus dažnai naudojamoms kalboms. Užtikrinkite replikacijos nuoseklumą – ypač tiesioginio indekso atnaujinimo metu. Realiu laiku veikiančioms programoms rekomenduojame asinchroninius indekso atnaujinimus, kad rašymo apkrova būtų atskirta nuo paieškos. Reguliariai matuokite kiekvienos kalbos vėlavimą ir nustatykite slenksčius, kuriems pasiekus automatiškai skiriami papildomi ištekliai. Konkreti rekomendacija: atlikite apkrovos testus su realistiškais kiekvienos kalbos paieškos modeliais ir optimizuokite indekso dydį pašalindami nereikalingus laukus (pvz., neindeksuokite paieškos nenaudojamų metaduomenų).

Žalvarinis kompasas tinklalapyje su paieškos rezultatais įvairiomis kalbomis.

Testavimas: kokybės užtikrinimas kiekvienai kalbos variantei

Daugiakalbės paieškos kokybės užtikrinimui reikalingas kelių etapų procesas, kai kiekviena kalba vertinama atskirai. Bendrinio testinių duomenų rinkinio nepakanka, nes kalbai būdingi reiškiniai, tokie kaip sudurtiniai žodžiai vokiečių kalboje ar tonų žymėjimai vietnamiečių kalboje, matomi tik atitinkamoje kalbos variante. Kiekvienai kalbai sukurkite reprezentatyvų korpusą iš tikrų vartotojų paieškos užklausų, papildytą tipinėmis klaidingomis įvestimis. Šis korpusas turėtų apimti visas svarbias kalbos dalis, diakritinius ženklus, umlautus ir sudurtinius terminus. Paprašykite gimtakalbių įvertinti paieškos rezultatų tinkamumą – geriausia pagal kelių lygių skalę (pvz., puikiai, priimtina, nereikšminga). Automatinės metrikos, tokios kaip Precision@k ar Mean Reciprocal Rank, gali papildyti šį procesą, tačiau nepakeičia žmogiškojo vertinimo.

Dažna klaida – testavimas tik su sintetiniais duomenimis. Todėl sukurkite nuolatinį stebėsenos procesą, kuris logina paieškos užklausas iš gamybinės aplinkos ir leidžia jas atsitiktinai tikrinti kalbos ekspertams. Užtikrinkite, kad testai apimtų ir rašybos klaidų toleranciją: įveskite tipinių klaidų kiekvienoje kalboje (pvz., „scheiße“ vietoj „Schuhe“ vokiečių k.) ir patikrinkite, ar fuzzy paieška pateikia teisingus rezultatus. Kalboms su keliomis rašto sistemomis (pvz., serbų k. kirilica ir lotyniškais rašmenimis) turi būti išbandytos abi versijos. Konkreti rekomendacija: kiekvienai kalbai nustatykite priimtinumo kriterijus, pvz., kad bent 90 % pirmųjų 10 rezultatų būtų įvertinti kaip tinkami. Prieš kiekvieną diegimą atlikite regresinį testą su fiksuotu užklausų ir rezultatų porų rinkiniu.

Testų rezultatus dokumentuokite pagal kalbą ir tvarkykite klaidų duomenų bazę, kurioje fiksuokite žinomas problemas (pvz., trūkstamus sinonimus ar neteisingus steminimo rezultatus). Planuokite reguliarius testų duomenų atnaujinimus, nes keičiasi vartotojų elgsena ir žodynas. Agile metodas su mėnesinėmis paieškos žurnalų peržiūromis padeda anksti pastebėti naujus iššūkius. Taip pat atsižvelkite į vartotojo sąsają: patikrinkite, ar paieškos rezultatai rodomi tinkama kalba ir ar kalbos perjungimas veikia sklandžiai. Atminkite, kad automatiniai testai niekada nepakeičia visiškos apimties – investuokite į reguliarius rankinius patikrinimus, atliekamus gimtakalbių.

Spąstai: Venkite automatinio paieškos terminų vertimo

Automatinis paieškos terminų vertimas yra viliojanti idėja suvienodinti kelių kalbų paieškas, tačiau praktikoje lemia didelius kokybės praradimus. Paieškos užklausos dažnai būna trumpos, be konteksto ir turi ypatybių, tokių kaip prekių ženklai, produktų kodai ar šnekamosios kalbos išraiškos, kurių negalima išversti vienas prie vieno. Pavyzdžiui, vartotojui vokiškai ieškant „Laufschuhe Dämpfung“, mašininis vertimas į anglų kalbą („running shoes cushioning“) gali neduoti tokių pat rezultatų kaip tiesioginė paieška vokiškame indekse. Be to, verčiant prarandami niuansai: prancūzų vartotojas, įvedęs „chaussures de course“, tikisi kitokių rezultatų nei tas, kuris naudoja „running shoes“. Automatinis vertimas taip pat ignoruoja kalbai būdingus optimizavimus, tokius kaip kamienavimas ar sinonimai, kuriuos kruopščiai sukonfigūravote.

Kita rizika – klaidingi vertimai, dėl kurių gaunami nereikšmingi ar net neteisingi rezultatai. Pavyzdžiui, „Gift“ vokiškai reiškia „nuodai“, o angliškai – „dovana“. Jei paieškos užklausą verčiate be konteksto, vartotojai gali gauti visiškai netinkamus produktus. Vietoj to turėtumėte atpažinti įvesties kalbą ir atlikti paiešką atitinkamame indekse – be vertimo. Jei norite pasiūlyti kelių kalbų paiešką (pvz., vartotojas ieško angliškai vokiškame puslapyje), geriau įgyvendinkite kryžminės kalbos gavimo sistemą, pagrįstą vektoriniais įdėjimais ar rankiniu būdu parengtais pagrindinių terminų vertimais, o ne viso paieškos eilutės mašininiu vertimu.

Konkreti rekomendacija: Išjunkite bet kokį automatinį paieškos terminų vertimą, nebent dirbate kontroliuojamoje aplinkoje su fiksuotu žodynu. Vietoj to naudokite atskirą paiešką kiekvienai kalbai, taikydami ankstesniuose skyriuose aprašytus metodus (kamienavimą, diakritinių ženklų toleranciją, sinonimus). Jei kelių kalbų paieška yra būtina verslui, sukurkite dažnų terminų įvairiomis kalbomis atvaizdavimą į bendrą produkto ID – ir neverčkite laisvo teksto. Taip pat patikrinkite savo analizės dujotiekį: įsitikinkite, kad kalbos atpažinimas atliekamas prieš paiešką, o ne po galimo vertimo. Dokumentuokite visas išimtis ir reguliariai atlikite auditą, kad nustatytumėte ir išjungtumėte atsitiktinai integruotus vertimo modulius.

Kontrolinis sąrašas: Daugiakalbės paieškos įdiegimas per 10 žingsnių

1. Apibrėžkite kalbas ir regionus: Nustatykite, kokias kalbas ir šalių specifinius variantus turėtų apimti jūsų paieška. Atsižvelkite ne tik į pagrindinę kalbą, bet ir į dialektus ar regioninius skirtumus (pvz., brazilų vs. europietiška portugalų).

2. Surinkite testinius duomenis: Kiekvienai kalbai sudarykite reprezentatyvų paieškos užklausų rinkinį. Naudokite esamus žurnalinius duomenis, klientų atsiliepimus ar tipinius terminus iš savo produktų katalogo. Atkreipkite dėmesį į umliautus, akcentus, sudėtinius žodžius ir sinonimus.

3. Pasirinkite paieškos sistemą: Patikrinkite, ar jūsų dabartinis paieškos sprendimas siūlo kelių kalbų funkcijas, tokias kaip kalbai būdingas kamienavimas, diakritinių ženklų tolerancija ir sinonimų valdymas. Jei ne, įvertinkite specializuotus tiekėjus arba atviro kodo alternatyvas.

4. Nustatykite indekso strategiją: Nuspręskite, ar naudoti atskirus indeksus kiekvienai kalbai (lengviau pritaikyti, bet daugiau atminties) ar kombinuotą indeksą su kalbos lauku. Praktikoje atskiri indeksai užtikrina geresnį aktualumą, nes stabdomieji žodžiai ir kamienavimas išlieka gryni.

5. Konfigūruokite kalbai būdingus nustatymus: Kiekvienai kalbai nustatykite tinkamą kamienavimą, simbolių normalizavimą (pvz., ß→ss) ir sudėtinių žodžių apdorojimą. Išbandykite su savo testiniais duomenimis, ar paieškos terminai atpažįstami teisingai.

6. Tvarkykite sinonimus ir žodžių variantus: Kiekvienai kalbai sukurkite sinonimų sąrašą, apimantį tipinius sutrumpinimus, terminus ir šnekamosios kalbos variantus. Planuokite reguliarius atnaujinimus pagal paieškos užklausas ir naujus produktus.

7. Nustatykite rašybos klaidų toleranciją: Konfigūruokite neaiškią paiešką su kalbai būdingais atstumo matais. Trumpiems žodžiams (pvz., angl. "cat") leiskite ne daugiau 1–2 pakeitimų; ilgesniems sudėtiniams žodžiams (pvz., vok. "Versicherungsvertrag") leiskite daugiau.

8. Įgyvendinkite užklausų analizę: Užtikrinkite, kad gaunamos paieškos užklausos prieš apdorojimą būtų automatiškai atpažintos kalbos atžvilgiu. Atsarginis variantas: jei kalba nėra aiški, naudokite naršyklės lokalę arba standartinę kalbą.

9. Pritaikykite rezultatų reitingavimą: Apibrėžkite aktualumo veiksnius, kurie sveriami pagal kalbą (pvz., tiksliems žodžių atitikmenims suteikti didesnę reikšmę nei kamieno formoms). Išbandykite reitingavimą su tikrais vartotojais ir atlikite koregavimus.

10. Kokybės užtikrinimas ir stebėsena: Prieš paleidimą kiekvienai kalbai atlikite atskirus testus: funkcinius, naudojamumo ir A/B testus. Po paleidimo stebėkite metrikas, tokias kaip nulinių rezultatų rodiklis, pirmųjų rezultatų paspaudimų dažnį ir vartotojų atsiliepimus. Nuolat tobulinkite.

Perspektyva: DI pagrįsta, personalizuota paieška visoms kalboms

Kita daugiakalbės paieškos karta bus smarkiai paveikta DI modelių. Vietoj taisyklėmis pagrįsto kamienavimo ar rankinių sinonimų sąrašų, neuroniniai tinklai gali mokytis semantinių panašumų tarp kalbų. Pagrindinis metodas – daugiakalbiai įterpiniai (embeddings), kurie skirtingų kalbų žodžius ir sakinius atvaizduoja į bendrą vektorinę erdvę. Tai leidžia vykdyti paiešką, kuri remiasi ne tiksliais žodžių atitikmenimis, o randa prasminius atitikmenis – net jei užklausa pateikiama kita kalba nei turinys.

Personalizavimas bus pagrindinis veiksnys. DI gali sukurti profilį iš naudotojo elgsenos (pvz., ankstesnių paspaudimų, vietovės, kalbos nustatymų) ir dinamiškai pritaikyti paieškos rezultatus. Vokiečių naudotojas, ieškantis „Handy“, gaus kitokius rezultatus nei prancūzas, įvedęs „téléphone portable“, net jei jie abu naršo tą patį produktų katalogą. DI atpažįsta, kurie produktai populiarūs atitinkamame regione arba kurias kategorijas naudotojas mėgsta.

Kita tendencija – didelių kalbų modelių (LLM) naudojimas tiesioginiam užklausų apdorojimui. Užuot tik nukreipęs į indekso įrašus, LLM gali suprasti klausimą ir pateikti apibendrinantį atsakymą – panašiai kaip pokalbių robotas. Kalbant apie daugiakalbį įgyvendinimą, tai reiškia, kad modelis turi būti mokomas visomis tikslinėmis kalbomis, geriausia naudojant bendrą daugiakalbį modelį, pvz., mBERT ar XLM-R.

Tačiau yra praktinių kliūčių: DI modeliams reikia didelių mokymo duomenų ir skaičiavimo galingumo, o tai mažesnėms įmonėms yra iššūkis. Taip pat reikia atsižvelgti į teisinius aspektus, tokius kaip duomenų apsauga (BDAR) ir šališkumo vengimas. Praktikoje dažnai derinami DI komponentai su klasikinėmis paieškos funkcijomis: DI praturtina rezultatus arba juos personalizuoja, o pagrindinė paieškos sistema užtikrina našumą ir mastelio keitimą.

Laipsniškam diegimui rekomenduojame pirmiausia išbandyti DI prototipą viena kalba. Išmatuokite tokių metrikų kaip nulinio rezultato dažnis ar naudotojų pasitenkinimas pagerėjimą. Tik po sėkmingo bandomojo projekto diegkite sprendimą kitoms kalboms. Svarbu: išlaikykite visišką paieškos logikos kontrolę – nepasikliaukite DI aklai. Hibridinė architektūra, apjungianti taisyklėmis pagrįstą apsaugą su DI lankstumu, praktikoje duoda tvirčiausius rezultatus.

Įrankiai ir sistemos daugiakalbei paieškai

Tinkamos paieškos technologijos pasirinkimas yra lemiamas daugiakalbės paieškos sėkmei. Iš esmės yra du keliai: savarankiška plėtra naudojant paieškos biblioteką (pvz., Elasticsearch, Apache Solr ar Meilisearch) arba valdomo sprendimo naudojimas (pvz., Algolia, Searchify ar AWS CloudSearch). Abu būdai turi specifinių privalumų ir trūkumų.

Elasticsearch yra de facto standartas daugiakalbėms paieškos programoms. Jis siūlo įtaisytuosius kalbų analizatorius daugiau nei 30 kalbų, įskaitant kamienavimą, sustabdymo žodžių sąrašus ir sudurtinių žodžių tokenizavimo taisykles. Naudojant papildinių architektūrą, galima pridėti savo sinonimų arba rašybos klaidų toleranciją. Trūkumas: konfigūravimas reikalauja gilių analizės grandinių ir indekso struktūros žinių. Apache Solr, kaip giminingas projektas, siūlo panašias galimybes, tačiau su savo konfigūracijos sintakse ir šiek tiek skirtingu reikšmingumo akcentavimu.

Valdomos paslaugos, tokios kaip Algolia, atleidžia nuo administravimo užduočių ir suteikia aukštą reikšmingumą iš karto. Daugiakalbiškumas valdomas per vadinamuosius kalbos konfigūracijos profilius, kurie nustato, kokia analizė taikoma kiekvienam indeksui. Tačiau čia greitai pasiekiamos ribos, kai susiduriama su labai specifiniais kalbos reikalavimais (pvz., kroatų linksniavimu ar arabų kamieno analize). Be to, didelės paieškos apimties sąnaudos dažnai nėra tiesinės.

Praktinis patarimas: prieš sprendimą atlikite koncepcijos įrodymą su savo konkrečiais duomenimis ir atitinkamomis kalbomis. Išbandykite ne tik pataikymo rodiklį, bet ir atsako laiką esant apkrovai bei sinonimų ar sustabdymo žodžių priežiūros pastangas. Atkreipkite dėmesį, kad pasirinktas sprendimas leistų atskirą indeksavimą kiekvienai kalbai arba bent jau kalbai specifinius analizės laukus – sujungus visas kalbas viename lauke, nukenčia reikšmingumas ir našumas. Taip pat įvertinkite integraciją į esamą sistemų aplinką (CMS, parduotuvės sistemą). Dažnai tokios sistemos kaip Elasticsearch siūlo paruoštus papildinius populiariausioms platformoms, o tai pagreitina diegimą.

Galų gale pasirinkimas priklauso nuo jūsų biudžeto, numatomo paieškos kiekio ir kalbų įvairovės. Skirkite pakankamai laiko konfigūravimui ir testavimui – skuboti sprendimai vėliau pareikalaus brangių pataisymų.

Dažni prieštaravimai daugiakalbei paieškai ir kaip juos atremti

Priimant sprendimą dėl daugiakalbės paieškos, viduje dažnai susiduriama su išlygomis. Trys dažniausi prieštaravimai: „Kaina ir pastangos per didelės“, „Anglų kalba paieškos pakanka“ ir „Kokybė niekada nebus pakankamai gera“. Remiantis faktais pagrįstais argumentais, šias abejones dažniausiai galima išsklaidyti.

Dėl prieštaravimo „Kaina ir pastangos“: Daugiakalbė paieška iš esmės dažnai yra pigesnė, nei manoma, jei naudojatės standartine technologija, pvz., „Elasticsearch“. Pradinė konfigūracija kiekvienai kalbai atsiperka per didesnius konversijų rodiklius ir mažesnius atmetimo rodiklius vartotojų, kurie ieško vokiškai, prancūziškai ar lenkiškai. Reikia atsižvelgti į vienkartines indekso nustatymo ir sinonimų priežiūros išlaidas, tačiau vengti nereikalingų savo kūrimų, kurie gali tapti brangūs. Praktikoje tarptautinių parduotuvių valdytojai praneša apie paieškos rezultatų rodiklio pagerėjimą 15–25 % po kalbai optimizuotos paieškos įdiegimo – be reikšmingo IT išlaidų padidėjimo.

Prieš argumentą „Anglų kalbos pakanka“ kalba vartotojų realybė: tyrimai rodo, kad gimtakalbiai, nemokantys anglų kalbos (pvz., vyresnės amžiaus grupės ar B2B klientai), grynoje anglų kalbos paieškoje žymiai dažniau nutraukia veiksmą. Net jei jūsų svetainėje yra turinio anglų kalba, daugelis vartotojų tikisi paieškos savo gimtąja kalba. Daugiakalbė paieška yra aiškus signalas, kad rimtai žiūrite į vietinę rinką – tai padidina pasitikėjimą ir praleidžiamą laiką.

Prieštaravimas „niekada nebus pakankamai gera“ dažnai kyla iš patirties su automatiniu paieškos terminų vertimu. Tačiau daugiakalbė paieška neverčia, o analizuoja kalbai būdingas savybes, tokias kaip žodžių kamienus, diakritinius ženklus ir sinonimus tiesiogiai indekse. Naudojant gerai prižiūrimą sinonimų žodyną ir tinkamą tokenizavimą, pasiekiate pataikymo rodiklį, labai artimą grynos gimtosios kalbos. Svarbu: išbandykite kokybę realiomis vartotojų užklausomis ir nuolat tobulinkite. Nė viena sistema nėra tobula, tačiau kalbai optimizuota paieška praktiškai yra gerokai pranašesnė už standartinį anglų kalbos sprendimą aktualumo ir vartotojų pasitenkinimo požiūriu.

Siekiant atremti šiuos prieštaravimus, rekomenduojama atlikti bandomąjį projektą vienai kalbai, turinčiai didelį srautą. Išmatuokite paieškos rodiklius prieš ir po (pataikymo rodiklį, atmetimo rodiklį, paspaudimų rodiklį) – rezultatai dažnai įtikina labiau nei teoriniai argumentai. Tačiau atkreipkite dėmesį, kad kiekvienas teiginys apie individualią situaciją turėtų būti pagrįstas išsamia analize. Dėl teisinių ir strateginių pasekmių, jei reikia, konsultuokitės su savo specializuotu skyriumi arba išoriniu konsultantu.

blog.faqT

Kaip nustatyti, kuria kalba vartotojas atlieka paiešką, jei jis nepasirinko kalbos nustatymų?

Galite naudoti naršyklės kalbą, IP geolokaciją arba dabartinę puslapio aplinką. Norėdami gauti tikslesnius rezultatus, išanalizuokite pačią paieškos užklausą: ar joje yra kalbai būdingų simbolių (pvz., „ü“ vokiečių kalbai) ar tipiškų žodžių? Rekomenduojama naudoti svetainės vyraujančią kalbą kaip atsarginį variantą. Tačiau venkite nustatyti kalbą tik pagal kelis simbolius – žodyno palyginimas pagal kalbą yra patikimesnis.

Ar turėčiau kiekvienai kalbai sukurti atskirą paieškos indeksą, ar pakanka kombinuoto indekso?

Kombinuotas indeksas supaprastina priežiūrą, tačiau gali sukelti klaidingų atitikmenų, nes žodis vienoje kalboje gali turėti kitą reikšmę kitoje. Atskiras indeksas kiekvienai kalbai suteikia tikslesnius rezultatus, ypač sudurtiniams žodžiams (pvz., „Donaudampfschifffahrtsgesellschaft“). Nors jo nustatymas reikalauja daugiau darbo, patirtis rodo, kad tai atsiperka. Taip pat galite naudoti hibridinius modelius: atskirus indeksus su bendra paieška kritiniams atvejams.

Kaip elgtis su kalbai būdingomis rašybos klaidomis – pavyzdžiui, sukeistomis raidėmis vokiečių kalboje arba klaidomis su akcentais prancūzų kalboje?

Įdiekite neaiškią paiešką su kalbai būdingais tolerancijos lygiais. Vokiečių kalboje dažniau pasitaiko raidžių sukeitimai („rašybos klaidos“), o prancūzų kalboje – akcentų praleidimai („café“ vs. „cafe“). Kiekvienai kalbai naudokite individualius Levenshteino atstumus arba medžių algoritmus. Svarbu: išbandykite tolerancijos ribas – per didelės sukelia triukšmą, per mažos neleidžia naudingų pataisymų. Vienakalbiai tekstynai padeda optimaliai sureguliuoti.

Prašyti neįpareigojančio pasiūlymo

Atsakymas per 24 valandas darbo dienomis.

Vokietijos MBFrankfurto prie Maino apygardos teismas · HRB 111727
D-U-N-S® registruotas315030052
DSGVO atitinkantis apdorojimasHostingas Vokietijoje
Fiksuotos kainos su rašytine pristatymo garantija