Chatboti keele automaatne tuvastamine: eelistused, varuvalikud ja kasutaja valik

Mitmekeelne veebisaidi chatbot ei tohiks külastajat juba esimese vastusega valesse keelde suunata. Kuid chatboti keele automaatne tuvastamine tähendab enamat kui lihtsalt esimese brauseriväärtuse üle võtmist. Brauseriseaded võivad olla vananenud, seadet võidakse jagada ja inimene võib eelistada lugeda tehnilist sisu inglise keeles, kuigi tema operatsioonisüsteem kasutab saksa keelt.

Töökindel lahendus käsitleb seetõttu automaatset tuvastamist vaid algussignaalina. Kasutaja selge valik on alati eesõigusega, liidese, teadmusbaasi ning üleminekuprotsessi kättesaadavus seab piirid ja nähtav varuvalik hoiab ära olukorra, kus näiliselt sobiv keel viib puudulike või välja mõeldud vastusteni.

Miks brauseri keel on vaid vihje

Brauserid saadavad sageli HTTP-päise Accept-Language. See sisaldab keelepiirkondi ja saab nn kvaliteediväärtuste abil väljendada järjekorda, näiteks de-AT,de;q=0.9,en;q=0.7. Standard RFC 9110 kirjeldab neid eelistusi selgesõnaliselt abivahendina esitusviisi valimisel, mitte kindla faktina isiku kohta.

Brauseris tagastab navigator.languages järjestatud nimekirja eelistatud BCP-47 keelemärgenditest. Vastavalt MDN-ile võivad brauserid aga andmekaitse kaalutlustel avaldada vähem eelistusi. Lisaks võib brauser vajadusel täiendada nimekirja üldisemate variantidega: näiteks de-AT põhjal võib võrdluseks täiendavalt de asjakohaseks muutuda.

Järeldus chatbotide jaoks on praktiline: Accept-Language ja navigator.languages on head kandidaadid esimeseks ettepanekuks. Kuid need ei tohi asendada asukohta ega kodakondsust. IP-aadress ei reeda usaldusväärset keelesoovi. Samuti ei piisa ainult domeenist ega lehe keelest, kui külastaja on teadlikult üle läinud mõnele teisele keeleversioonile.

Selge prioriteediahel hoiab ära üllatused

Valik peaks olema deterministlik. Praktikas on end tõestanud järjekord, mis kaalub iga allikat selgelt:

1. Selge valik praeguses sessioonis: kui kasutaja klõpsab prantsuse keelel, peab chatboti järgmine vastus olema prantsuse keeles.
2. Salvestatud, ikka veel kehtiv eelistus: varasem valik võib kehtida ka hilisema külastuse ajal, kui salvestamine on läbipaistev ja tehniliselt lubatud.
3. Praeguse lehe keel: chatbot ei tohiks ilma põhjuseta kõrvale kalduda teadlikult avatud keeleversioonist.
4. Brauseri eelistused: nimekirja võrreldakse tegelikult toetatud chatboti lokaatidega.
5. Dokumenteeritud vaikeväärtus: kui miski ei sobi, järgneb juhusliku tulemuse asemel teadlikult valitud baaskeel.

See ahel eraldab tuvastamise otsustamisest. Seda saab logida ja testida: source=user, source=stored, source=page, source=browser või source=default. Analüütika jaoks piisab tavaliselt allikast ja valitud lokaadist. Brauseri täielikku keelenimekirja ei tohiks asjatult salvestada, sest RFC 9110 viitab üksikasjalike keele-eelistuste võimalikule andmekaitse- ja profiilianalüüsi (fingerprinting) riskile.

Normaliseeri BCP-47 märgendid tähendust kaotamata

Keelemärgendid ei koosne ainult kahest tähest. pt-BR ja pt-PT jagavad keelt, kuid võivad erineda tonaalsuse, sõnavara, vormingute ja õiguslike mõistete poolest. Samuti võivad otsustavaks saada kirjasüsteemid. Seetõttu peaks rakendus sissetulevad märgendid süntaktiliselt normaliseerima ja seejärel kontrollima neid toetatud lokaatide selge nimekirja vastu.

Spetsiifilisest märgendist turvalise varuvalikuni

Mõistlik sobitamine üritab esmalt täpset varianti. Kui de-AT pole saadaval, võib de järgnesid. Pärast seda võib rakenduda teadaolev, toimetatud standardne lokaat. Kõikide alammärgendite lihtne eemaldamine pole aga alati turvaline. Mitme kirjasüsteemi või väga erinevate variantidega keelte puhul vajab toode teadlikult määratletud vastavust.

Varuvalikut tuleb kontrollida eraldi kolmel tasandil: kas vestlusliides on tõlgitud? Kas on olemas sobivad teadmusallikad? Kas klienditoe meeskond saab selle keele üle võtta? Lokaliseeritud nupp ei tõesta veel, että teadmusbaasil on sama kaetus. Kuidas allikaid keele, versiooni ja juurdepääsu järgi eraldatakse, näitab artikkel RAG-i metandmete filtritest tehisintellekti chatbotidele.

Paku automaatikat, hoia kasutaja valik nähtavana

W3C rahvusvaheliseks muutmise soovitus ühendab automaatse keelevahenduse kergesti leitavate linkidega alternatiivsetele keeleversioonidele. Kui kasutaja vahetab ise keelt, peab see valik brauseri eelistuse üle trumpama ja soovi korral järgmistel lehtedel säilima.

Chatboti jaoks tähendab see: aktiivne keel kuulub nähtavalt vestluse päisesse või kergesti ligipääsetavasse menüüsse. Keelevahetus ei tohi käsilolevat mustandit märkamatult ära saata. Selle asemel sisend säilib, bot selgitab keelevahetust lühidalt ja jätkab vestlust kontrollitult. Kui varasemad sõnumid on teises keeles, peaks süsteem säilitama nende tähenduse konteksti jaoks, kuid mitte tõlkima kogu ajalugu küsimata.

Hea sõnastus on näiteks: „Eesti keel võeti üle sellelt lehelt. Muuda keelt.“ Varuvaliku puhul võib teavitus olla konkreetsem: „Selle teema kohta puudub eesti keeles kinnitatud teave. Võin kasutada ingliskeelset allikat või suunata teid klienditukke.“ Nii mõistab kasutaja, miks keel või vastuse sügavus muutus.

Eralda lehe keel, vestluse keel ja sisu lokaat

Kolm väärtust koondatakse sageli ekslikult ühte väljasse:

• Lehe keel: HTML-dokumendi peamine keel;
• Vestluse keel: keel, milles ilmuvad kasutajaliides ja vastused;
• Sisu lokaat: variant, kust chatbot tohib kinnitatud teavet pärida.

Need väärtused võivad olla samad, kuid ei pea olema. Eestikeelne kasutaja võib ingliskeelsel tootelehel esitada eestikeelse küsimuse. Bot tohib vastata eesti keeles ja viidata läbipaistvalt ingliskeelsele originaalallikale. Kuid ta ei tohiks väita, et kasutas eestikeelset allikat, kui tõlgiti ainult vastus.

Kättesaadavuse (ligipääsetavuse) tagamiseks peavad dokumendi ja sisu keel olema õigesti märgistatud. W3C tehnik H57 kirjeldab lang-atribuuti html-elemendil, et muu hulgas ekraanilugejad saaksid hääldust ja süntaksit sobivalt töödelda. Kui üksik lõik vahetab keelt, vajab ka see ala sobivat märgistust. Täiendavad kontrollid koondab WCAG kontrollnimekiri veebisaidi chatbotidele.

Puhvermälu ja URL-id peavad keeleotsust austama

Kes valib sisu serveri poolel päise Accept-Language põhjal, peab arvestama puhverdamisstrateegiaga. RFC 9110 selgitab, et päis Vary: Accept-Language annab puhvritele märku, et päis mõjutas esitust. Kui see eraldatus puudub, võib puhver edastada eestikeelse variandi ingliskeelsele külastajale.

Avaliku, indekseeritava sisu puhul on stabiilseid keelespetsiifilisi URL-e sageli lihtsam kontrollida ja jagada. Automaatne tuvastamine võib siis viia sobiva URL-ini, ilma et eri sisu peidetaks sama aadressi alla. Vestluses endas peaks lokaat olema sessiooni oleku ja iga serveripoolse päringu osa. Keelevahetus peab uuendama korraga puhvrivõtmed, päringufiltrid ja vastuste genereerimise.

Sellesse lepingusse kuuluvad ka vormindatud väärtused. Kuupäev, arv, valuuta ja ajavöönd ei tulene automaatselt teksti keelest. Juhend Chatboti vastuste lokaliseerimine näitab, kuidas neid andmeid eraldi ja konsistentselt käsitleda.

Varuvalikud ei tohi varjata sisulisi lünki

Kõige riskantsem viga on teadmusbaasi vaikne vahetamine. Kui eestikeelse küsimuse kohta eestikeelset artiklit pole, võib bot kasutada ingliskeelset allikat, eeldusel et toode seda võimaldab. Kuid ta peab kontrollima allikat, ajakohasust ja õigusi täpselt samamoodi nagu otsese kattuvuse korral.

Turvaline varuvaliku maatriks sisaldab vähemalt: taotletud lokaati, saadaval olevat UI-lokaati, saadaval olevat sisu lokaati, lubatud asenduslokaati, tõlkerežiimi ja klienditoele ülemineku sihti. Tulemus ei ole alati vastus. Tundlike või tugevalt kontekstipõhiste teemade puhul on vastus „selles keeles puudub kinnitatud teave“ parem kui sujuv, kuid ilma aluseta tõlge. Artikkel varuvalikutest teadmiste lünkade korral kirjeldab, kuidas ebakindlus ja üleminek koos toimivad.

Keeleloogika testjuhtumid

Väike süstemaatiline testkomplekt leiab rohkem vigu kui üksik brauserikontroll. See peaks katma vähemalt järgmised juhtumid:

• de-AT pakutakse, toetatud on vaid de;
• brauseri esimene eelistus pole saadaval, kuid teine on;
• kasutaja valik on vastuolus lehe ja brauseri keelega;
• salvestatud eelistus viitab lokaadile, mis on vahepeal eemaldatud;
• kasutajaliides on olemas, kuid teadmusbaasi või üleminekut pole;
• keelevahetus toimub keset vestlust koos saatmata tekstiga;
• puhver tagastab pärast vahetust tõepoolest uue lokaadi;
• ekraanilugeja tuvastab lehe ja lõigu keele õigesti;
• analüütika registreerib valikuallika ja varuvaliku, kuid mitte asjatult üksikasjalikku eelistuste nimekirja.

Iga kombinatsiooni puhul peaksid meeskonnad fikseerima oodatava lokaadi, otsuse allika, nähtava teavituse ja lubatud sisuruumi. Lisaks vajab iga keel sisulisi pistelisi kontrolle. Täielikkust ja vastuse kvaliteeti ei saa tuletada pelgalt tõlkerida olemasolust.

Praktiline juurutamise kontrollnimekiri

1. Inventariseeri eraldi kõik toetatud liidese-, sisu- ja üleminekulokaadid.
2. Dokumenteeri selge prioriteediahel kasutaja valiku, salvestatud valiku, lehe, brauseri ja vaikeväärtuse jaoks.
3. Määratle BCP-47 sobitamine koos regionaalsete ja kirjasüsteemiga seotud eranditega.
4. Kujunda keelevahetus nähtavaks ja ilma sisendandmete kaotsiminekuta.
5. Piira varuvalikud allikate kaetuse, ajakohasuse ja õigustega.
6. langKontrolli päist Vary: Accept-Language, keelespetsiifilisi URL-e, kanoonilisi aadresse ja puhvri käitumist.
7. Salvesta ainult vajalikke analüütikaandmeid ja määra säilitamistähtaeg.
8. Testi lauaarvuti, mobiilseadme, klaviatuuri ja ekraanilugejaga, kasutades realistlikke eelistuste nimekirju.

Toote peamine otsus ei ole seega: „Mis keelt see külastaja räägib?“ Vaid pigem: „Mis keelt sooviti, milline sisu on selles keeles usaldusväärselt saadaval ja kuidas selgitame vajalikku asendusteed?“ Kui vastate neile kolmele küsimusele eraldi, saate chatboti, mis alustab automaatselt abivalmilt, kuid jätab kontrolli kasutajale.

Allikad

• RFC 9110: Accept-Language, Vary ja andmekaitse
• MDN: Navigator.languages
• W3C Internationalization: Kasutajate suunamine tõlgitud lehtedele
• W3C WAI: Dokumendi keele märgistamine atribuudiga lang