KI-tšatboti teadmuslünkade tuvastamine: vastamata küsimuste süstemaatiline lahendamine

Veebisaidi tšatbot saab usaldusväärselt vastata ainult siis, kui sellele on kättesaadav sobiv, kinnitatud ja leitav teave. Tegelikkuses ei ilmu teadmuslüngad aga peaaegu kunagi puhta aruandena. Need peituvad turvalistes varuvastustes (fallback), korduvates täpsustavates küsimustes, mittevajalikes ülevõtmistes inimeste poolt või vastustes, mis kõlavad küll usutavalt, kuid millel puudub usaldusväärne allikas. Neile, kes vaatavad pelgalt vastamata küsimuste arvu, jääb suur osa probleemist nähtamatuks.

Tõhus protsess ühendab seetõttu kasutusandmed, toimetusliku kontrolli ja testimise. Eesmärk ei ole kopeerida iga ebatavalist sõnastust kohe teadmusbaasi. Eesmärk on tuvastada korduvaid teabevajadusi, teha kindlaks nende põhjus ning kinnitada ainult sellised vastused, mille eest saab sisuliselt vastutada. See juhend tutvustab praktilist töövoogu klienditoe-, sisu- ja tootetiimidele.

Mis on teadmuslünk KI-tšatbotis?

Teadmuslünk tekib siis, kui kasutaja õigustatud küsimusele ettenähtud kasutusvaldkonnas ei saa usaldusväärselt vastata kinnitatud teabega. See võib tähendada, et teave puudub täielikult. Sagedamini on see aga olemas, kuid vananenud, liiga üldine, keeleliselt sobimatu, otsimootoritele kättesaamatu (ei ole crawl'itav) või teabeotsingus (retrieval) mitteleitav. Ka vastuolulised allikad on lünk: sellisel juhul on tšatbotil liiga vähese teabe asemel hoopis liiga palju ebamäärast teavet.

Seda mõistet ei tohiks samastada iga No-Match (vasted puuduvad) olukorraga. Google dokumenteerib Dialogflow CX-is sisseehitatud No-Match sündmusi, kui sisend ei vasta ühelegi kavatsusele (intent). Microsoft nimetab Copilot Studio analüütikas neid sündmusi mõistega „unrecognized utterances“ – ehk sõnastusteks, mis ei käivita eraldi teemat. Sellised signaalid on kasulikud alguspunktid, kuid ei tõesta veel, et vaja on uut sisu. Võib-olla jäi küsimus tegevusraamistikust (scope) välja, sõnastus oli kahemõtteline või ei leitud olemasolevat allikat lihtsalt üles.

Millised signaalid kuuluvad lünkade analüüsi?

Turvalised varuvastused (fallbacks) ja vastamata küsimused

Kõige selgem jälg on vastus nagu „Mul puudub selle kohta usaldusväärne teave“. Selline turvaline varuvastus on parem kui väljamõeldud väide, kuid seda tuleks jäädvustada kontrollitava sündmusena. Sealjuures pole oluline ainult küsimuse sõnastus, vaid ka keel, asjaomane lehekülg, aeg, valitud raamistik (scope) ja vestluse edasine kulg. Isikuandmed või konfidentsiaalne sisu ei tohi filtreerimata toimetussüsteemi jõuda.

Madal usaldusväärsus ja nõrk allikabaas

Ka antud vastus võib paljastada teadmuslünga. Näideteks on puuduvad allikad, halva sobivusega otsingutulemus (retrieval), mitu vastuolulist allikat või vastus, mis katab ainult osa küsimusest. Tehnilisest kindlustundemäärast (confidence score) üksi otsuse tegemiseks ei piisa: läved erinevad mudeli, süsteemi ja riski järgi. Otsustav on see, kas tiim saab väidet autoriteetse allika põhjal kontrollida ja kinnitada.

Korduvad täpsustused, katkestamised ja ülevõtmised (handoffs)

Kui kasutajad sõnastavad sama küsimuse ümber, küsivad mitu korda üle või nõuavad kohe pärast seda inimest, võis esimene vastus eesmärgist mööda rääkida. Sama kehtib ka ebatavaliselt paljude poolelijätmiste kohta pärast teatud teemat. Selliseid vestlusliine tuleb kontrollida kontekstis. Inimesele ülevõtmine (handoff) võib olla õige lahendus, näiteks üksikjuhtumite otsuste, kaebuste või tundlikke andmete puhul. See ei ole automaatselt sisuviga.

Lokaadi (locale) ja kanalite erinevused

Saksakeelne vastus võib toimida, samal ajal kui prantsuskeelne variant puudub või kasutatakse tootenimetust teistmoodi. Samamoodi võidakse küsimusi hinnalehel sõnastada teisiti kui abikeskuses. Seetõttu peaksid klastrid olema kontrollitavad vähemalt keele ehk lokaadi (locale) ja kasutuskonteksti kaupa. Üldine kokkuvõte võib muidu varjata selgelt lokaliseeritud lünka.

Toorsignaalist prioritiseeritud sisutööde nimekirjani (content backlog)

Sujuv töövoog hoiab ära selle, et tiim kogub vestlussalvestusi valimatult või hindab üksikuid tähelepanekuid üle. Järgmisi seitset sammu saab läbi viia kord nädalas või suurema mahu korral tihedamini.

1. Määratlege jäädvustamine: Määrake kindlaks, milliseid sündmusi peetakse kandidaatideks: turvaline varuvastus, usaldusväärse allika puudumine, korduv küsimus, negatiivne tagasiside, mittevajalik ülevõtmine või teatatud vale väide. Dokumenteerige ka see, milliseid andmeid teadlikult ei salvestata.
2. Puhastage sisu: Eemaldage või maskeerige isikuandmed, tellimuse numbrid, kontaktandmed ja vabatekst, mis pole analüüsi jaoks vajalikud. Artikkel andmesäästliku tšatbotianalüütika kohta näitab, kuidas sündmusi, diskreetimist (sampling) ja säilitamist saab eraldi planeerida.
3. Normaliseerige küsimused: Koondage samatähenduslikud sõnastused kokku ilma olulisi erinevusi kaotamata. „Kui kaua saan kaupa tagastada?“ ja „Milline on tagastamise tähtaeg?“ kuuluvad tõenäoliselt ühte klastrisse; „Kas saan tagastada personaliseeritud kaupa?“ võib vajada eraldi reeglit.
4. Klassifitseerige põhjus: Eristage puuduvat sisu, vananenud allikat, otsingu- või struktuuriprobleemi, ebaselget reeglistikku (policy), lokaadilünka, tahtlikult välistatud raamistikku ja vajalikku inimese otsust. See diagnoos määrab edasise tegevuse.
5. Määrake prioriteet: Hinnake sagedust, mõju kasutajale, ärialast olulisust ja riski. Harva esinev teave ohutuskriitilise piirangu kohta võib olla olulisem kui sagedane vestluse alustamise küsimus (smalltalk). Valem peab olema teie ettevõtte jaoks arusaadav ja kontrollitav, mitte matemaatiliselt keeruline.
6. Määrake allika vastutus: Iga planeeritud vastus vajab autoriteetset allikat ja isikut või rolli, kes tohib selle sisu kinnitada. Kui mõlemad puuduvad, jääb kirje avatuks; keelemudel ei tohi reegleid ise välja mõelda. Sobivat töömudelit kirjeldab juhend KI-tšatbottide sisuhalduse (content governance) kohta.
7. Looge vastuvõtutest: Salvestage esinduslikud küsimused, oodatavad põhiväited, lubatud allikad ja oodatav käitumine väljaspool raamistikku. Pärast iga muudatust kontrollitakse, kas lünk on suletud ja olemasolevad vastused jäävad stabiilseks.

Milliseid välju vajab hea töönimekirja kirje?

Pilet pealkirjaga „Tšatbot ei tea tagastusaega“ on liiga pinnapealne. See viib kergesti tekstini, mis küll vastab näidispäringule, kuid ei võta arvesse variante, erandeid ega vastutusalasid. Tööleminev kirje sisaldab vähemalt järgmist:

• neutraalset klastri teemat ja kahte kuni viite anonüümseks tehtud näidisküsimust,
• lokaati (locale), lehe konteksti ja puudutatud kasutajateekonda,
• täheldatud käitumist ja soovitud käitumist,
• põhjuse klassi ja põhjendatud prioriteeti,
• autoriteetset allika URL-i või staatust „Allikas puudub“,
• sisulist omanikku, ülevaataja rolli ja tähtaega,
• kehtivuskuupäeva, teadaolevaid erandeid ja soovitud inimesele üleandmise (handoff) käitumist,
• testjuhtumeid ja mõõdetavaid vastuvõtukriteeriume.

Nii saab vestluse tähelepanekust toimetuslik tööülesanne. Samal ajal jääb nähtavaks, kas probleemi saab tõesti sisuga lahendada. Tehniline otsinguviga kuulub näiteks otsingu- või platvormitiimile; lahendamata tagastamisreegel aga sisuliselt vastutavale osakonnale.

Praktiline näide: tagastamist puudutavate küsimuste õige lahendamine

Oletame, et kasutajad küsivad korduvalt personaliseeritud toodete tagastamise kohta. Tšatbot nimetab vahel üldist tähtaega, vahel ebakindlat erandit ning suunab vahel vestluse klienditulle. Tiim ei tohiks seniste vastuste põhjal uut reeglit tuletada. Kõigepealt tehakse kindlaks, milline kinnitatud reeglistik (policy) kehtib, milliste riikide ja tooterühmade suhtes see kehtib ning millal on vajalik üksikjuhtumi kontroll.

Pärast seda luuakse struktureeritud allikas üldise reegli, selgelt nimetatud erandite, kehtivusalaga ja eskaleerimiskriteeriumiga. Testjuhtumid katavad otseseid küsimusi, kõnekeelseid variante, teist lokaati ja teadlikult mitteautomatiseeritavat piirjuhtumit. Piirjuhtumi puhul oodatakse läbipaistvat üleminekut inimesele (human handoff) – mitte sunnitud iseteeninduse vastust.

Miks rohkem sisu ei tähenda automaatselt paremat tulemust

Sagedane ebaõnnestunud katse on vastata igale klastrile uue KKK-ga. See võib tekitada duplikaate, vastuolusid ja halvemaid otsingutulemusi. Enne uue sisu loomist kontrollige, kas olemasolevat lehte tuleks täiendada, paremini struktureerida või veebirullimise alast (crawl scope) eemaldada. Protsess teadmusbaasi ajakohasena hoidmiseks aitab allikate valikul, indekseerimissageduse määramisel ja vananenud sisu kontrollimisel.

Sama riskant on võtta tegelikud kasutajate sõnastused kontrollimata üle treening- või testandmeteks. Google juhib oma disainijuhistes tähelepanu sellele, et No-Match sisendite valimatu lisamine võib põhjustada soovimatut intent-kallutatust (intent bias). Alles põhjuse kontroll otsustab, kas sõnastust tuleks täiendada, olemasolevat sõnastust puhastada või valesti konkureerivat intenti parandada.

Protsessiringi sulgemine regressioonitestidega

Lünka ei loeta suletuks kohe, kui uus tekst on avaldatud. See on suletud siis, kui esinduslikud küsimused näitavad ettenähtud kontekstis oodatud käitumist. Google kirjeldab testjuhtumeid ootustega vestluse või vahetuse (turn) tasemel ning võrdlust näidisjuhtumiga (golden case). Veebisaidi tšatbottide puhul saab seda põhimõtet rakendada mudelist sõltumatult: dokumenteeritakse küsimus, oodatav põhiväide, lubatud allikas, nõutav ülevõtmine (handoff) ja keelatud väited.

Väike ja hästi hooldatud testkogumik on väärtuslikum kui suur kontrollimata kollektsioon. Lisage kinnitatud lüngad olemasolevasse kuldkomplekti (golden set) ning käivitage asjakohased juhtumid uuesti pärast sisu-, viiba (prompt), mudeli- või otsingumuudatusi. Põhjalik juhend KI-tšatboti vastuste kvaliteedi mõõtmise kohta selgitab seda ülevaatuse töövoogu lähemalt.

Millised mõõdikud näitavad progressi?

Ärge jälgige pelgalt üldist varuvastuste määra (fallback rate). Palju kõnekam on väike komplekt järgmistest näitajatest: avatud prioritiseeritud klastrid, aeg sisulise selguseni jõudmiseni, autoriteetse allikaga töönimekirja kirjete osakaal, läbitud regressioonitestid ja pärast kinnitamist uuesti ilmnenud lüngad. Segmentige tulemused lokaadi ja peamise kasutusraja järgi, hindamata väikeseid rühmi nii üksikasjalikult, et isikud saaksid kaudselt tuvastatavaks.

Microsoft toob tuvastamata sõnastused ja madala lahendusmääraga teemad välja võimalike optimeerimissignaalidena. NIST rõhutab oma tehisintellekti riskijuhtimise raamistikus (AI Risk Management Framework) samal ajal pidevat monitooringut, dokumenteeritud testkomplekte, tagasisidet ja käitumise jälgimist reaalajas töös. Sestap tuleneb oluline reegel: mõõdikud peavad toetama otsuseid, kuid ei tohi asendada vastuse allika sisulist kontrolli.

Iganädalane meelespea klienditoele ja toimetusele

• Koguge uued kandidaadid andmesäästlikult ja sorteerige välja ilmselge kuritarvitamine.
• Rühmitage samatähenduslikud küsimused lokaatide kaupa ning täiendage olemasolevaid klastreid.
• Kinnitage olulisemate klastrite puhul põhjus, mõju ja risk.
• Otsige olemasolevaid allikaid, märgistage vastuolud ja selgitage välja vastutaja.
• Avaldage ainult kinnitatud muudatusi; hoidke raamistik (scope) ja inimüleminek (handoff) selgelt piiritletuna.
• Käivitage esinduslikud testjuhtumid ja dokumenteerige tulemused.
• Kontrollige mõne kasutuspäeva järel, kas klaster ilmneb uuesti või on ainult oma vormi muutnud.

Kokkuvõte: teadmuslüngad moodustavad toimetusliku tsükli

Vastamata küsimused muutuvad väärtuslikuks alles siis, kui tiim ei käsitle neid üksikute vestluslogidena, vaid kontrollitavate vihjetena. Kogumine, puhastamine, rühmitamine, põhjuse määramine, prioritiseerimine, allika kinnitamine ja testimine: see tsükkel ühendab klienditoe reaalsuse usaldusväärse teadmusbaasiga. See ei vähenda igat inimülevõtmist ega vasta teadlikult igale küsimusele automaatselt. Küll aga teeb see nähtavaks, kus tšatbot saab usaldusväärselt abiks olla – ja kus selge piiri seadmine tagab parema kasutajakogemuse.

Allikad

• Microsoft Learn: Measure and improve agent performance with KPIs and analytics
• Google Cloud: Dialogflow CX state handler'id ja No-Match sündmused
• Google Cloud: General agent design best practices
• Google Cloud: Dialogflow CX testjuhtumid
• NIST AIRC: AI Risk Management Framework Core