Tooteandmete ajakohasena hoidmine tehisintellekti vestlusbotis: hinnad, laoseis ja variandid

Veebisaidi vestlusbot saab tootealastele küsimustele usaldusväärselt vastata vaid siis, kui selle andmed on sama värsked kui esitatud küsimus. Üldine teadmusbaas selgitab küll materjale, kasutusvaldkondi või hooldusjuhiseid. Hindade, tarnevalmiduse, värvuse, suuruse ja piirkondliku laoseisu puhul ei piisa aga vaid aeg-ajalt tehtavast veebisaidi roomamisest (crawl). Need andmed muutuvad kiiremini, kehtivad sageli vaid konkreetse variandi kohta ning võivad sõltuda turust, klienditüübist või ajahetkest.

Määrav arhitektuuriküsimus ei ole seetõttu: „Kuidas me saame kogu kataloogi keelemudelisse üle viia?“ Vaid pigem: Milline allikas tohib millise väärtuse anda, kui kaua see kehtib ja mida ütleb vestlusbot siis, kui ta ei saa seda kindlalt kinnitada? See juhend esitab praktilise ülesehituse e-kaubanduse, tootejuhtimise, klienditoe ja arendusmeeskondadele.

Miks tooteandmed vajavad teistsuguseid värskendusreegleid

Tooteinformatsioon koosneb erineva dünaamikaga väljadest. Tootenimi või materjalikirjeldus püsib sageli kaua muutumatuna. Soodushind võib seevastu muutuda päeva jooksul, laoseis aga kasvõi kahe vestlussõnumi vahel. Kui kõike töödeldakse ühtemoodi, tekib kaks tüüpilist viga: kas stabiilse sisu kohta tehakse tarbetult palju päringuid või jäävad dünaamilised andmed liiga kauaks vahemällu (cache).

Jaotage andmed seepärast vähemalt nelja klassi:

• Põhiandmed: toote ID, variandi ID, nimetus, kaubamärk, mõõtmed ja materjal.
• Müügiandmed: hind, valuuta, käibemaksuteave, kampaania periood ja miinimumkogus.
• Kättesaadavuse andmed: tarnitavus, konkreetse asukoha laoseis, eeldatav tarneaeg ja juurdeboundmise staatus.
• Nõustamisteadmised: sobivus, ühilduvus, kasutus, hooldus ja dokumenteeritud piirangud.

Ka otsingumootorid eraldavad toote, pakkumise, hinna ja kättesaadavuse. Ametlik Google'i dokumentatsioon tooteandmete kohta kirjeldab struktureeritud andmeid ja tootevooge kui täiendavaid allikaid selliste andmete jaoks. Vestlusboti jaoks on need formaadid kasulikud signaalid, kuid mitte automaatselt siduvad reaalaja-allikad.

Määrake iga välja jaoks kindel ja siduv allikas

Vestlusbot ei tohiks väärtust arvata mitme võrdväärse koha seast. Määrake selle asemel iga välja jaoks ametlik andmeallikas (System of Record). Põhiandmed võivad tulla tooteinfohaldusest (PIM), hinnad e-poe süsteemist või ERP-st ning asukohapõhine laoseis laoarvestusest. Nõustamisteadmised võivad pärineda jätkuvalt kinnitatud veebilehtedelt ja dokumentidest.

Alustuseks piisab väikesest andmevastutuse maatriksist:

• Millisele süsteemile väli kuulub?
• Milline ID ühendab toodet ja varianti kõigis süsteemides?
• Kui värske peab väärtus olema?
• Millise piirkonna, kliendirühma ja valuuta kohta see kehtib?
• Milline on turvaline vastus, kui allikas lakkab töötamast?

Tuvastage toode ja variant üheselt

Vestlusbot peab kõigepealt mõistma, millist konkreetset objekti mõeldakse. „Roheline mudel“ ei ole ilma tooteperekonna, suuruse ja muude tunnusteta ühene. Kasutage tehniliste võtmetena ettevõttesiseseid toote- ja variandi ID-sid. Kaubanduslikud tähised nagu GTIN võivad samuti abiks olla; näiteks Schema.org Product sisaldab selleks muuhulgas GTIN-omadusi. Need ei asenda aga teie sisemist variandiloogikat.

Kui andmed on puudulikud, peaks dialoog küsima täpsustavalt: „Kas mõtlete 30 või 40 sentimeetrit?“ Alles pärast seda käivitatakse hinna- või laoseisupäring. See säästab API-päringuid ja hoiab ära olukorra, kus vestlusbot kuvab valed andmed vale variandi kohta.

Ärge ajage hinda ja pakkumist sekmappingu tootega

Ühel tootel võib olla mitu pakkumist: erinevad valuutad, müügipiirkonnad, kogusepõhised hinnad või ajaliselt piiratud kampaaniad. Seetõttu eraldab Schema.org Offer hinna, valuuta ja kättesaadavuse tootest endast. Rakendage seda põhimõtet ka ettevõttesiseselt. Iga hinda sisaldav vastus peaks arvesse võtma vähemalt varianti, valuutat, kehtivust ja – vajaduse korral – turgu või klienditüüpi.

Pärige dünaamilisi väärtusi alles küsimuse esitamise hetkel

Kiiresti muutuvate andmete puhul on reaalajas päringute tegemine (retrieval) tavaliselt töökindlam kui täielik importimine vestlusboti otsinguindeksisse. Protsess võib välja näha järgmine:

1. Küsimust analüüsitakse toote, variandi, piirkonna ja soovitud välja suhtes.
2. Puuduvad tunnused täpsustatakse dialoogis.
3. Kompaktne serveripoolne funktsioon pärib ainult vajalikud väljad.
4. Vastus sisaldab väärtust, konteksti ja ajakohasuse ajahetke.
5. Ebamäärasuse korral rakendub määratletud asendusvastus või pöördumise üleandmine inimesele.

Ärge andke mudelile kogu ERP-andmekogumit. Lühike vastus nagu „Variant X, turg AT, hind 49 eurot, kontrollitud kell 14:05, laoseis teadmata“ on kergemini kontrollitav kui mahukas objekt sisekulude, tarnijaväljade ja märkmetega. See vähendab ühtlasi andmeriske ja märgiste (tokenite) kulu.

Veebisaidi skaneerimine ehk crawl on sellest hoolimata kasulik: see annab kirjeldused, kategooriad ja avalikult kinnitatud nõustamistekstid. Kuidas sellist sisu jälgida, selgitab artikkel Tehisintellekti vestlusboti teadmusbaasi ajakohasena hoidmine. Hinnad ja reaalajas laoseis kuuluvad aga eraldi päringuteekonda.

Valige vahemälu kestus riski, mitte mugavuse järgi

Ilma vahemäluta suureneb koormus e-poele ja laoarvestussüsteemile. Liiga pika vahemälu kestuse korral kasvab aga valede lubaduste andmise risk. Standard RFC 9111 HTTP vahemällu salvestamise kohta eristab värskeid, aegunud ja uuesti valideeritud vastuseid. Seda mõttemudelit saab üle kanda ka tootepäringutele.

Määratlege kehtivusaeg igale väljale eraldi. Näiteks materjali kirjeldus võib kehtida märksa kauem kui soodushind. Laoseisu puhul võib olla vajalik väga lühike kestus või valideerimine enne lõpliku lubaduse andmist. Määrav ei ole universaalne number, vaid dokumenteeritud reegel, mis sobib muutumisrütmi ja võimaliku kahju suurusega.

Salvestage täiendavalt:

• Allikapäringu ajahetk ja aegumisaeg,
• Toote, variandi ja turu ID,
• Allikas ja versiooni- või muudatustähis,
• Viimase valideerimise tulemus,
• Asenduslahenduse (fallback) rakendamise põhjus.

Nii on hiljem võimalik tuvastada, miks mingit vastust kasutati või see tagasi lükati. Vahemälu võti, mis koosneb vaid tootenimest, on liiga üldine; sellesse peavad kuuluma vähemalt variant, piirkond, valuuta ja asjakohane kliendirühm.

Vastake aegunud andmete korral kontrollitult

Pelk ajatempel ei muuda vana teavet turvaliseks. Määratlege iga dünaamilise välja puhul, kas aegunud vastust tohib veel kasutada. Üldise vihje puhul nagu „seda mudelit pakutakse tavaliselt kolmes suuruses“ võib piisata vastavast märkest. Hinna, konkreetse laoseisu või siduva tarneaja puhul ei tohiks vestlusbot aegunud väärtuse põhjal lubadusi sõnastada.

Hea asendusvastus on konkreetne: „Ma ei saa praegu reaalajas laoseisu kinnitada. Saan teile selgitada saadaolevaid variante või suunata päringu meie meeskonnale.“ See määratleb piiri ja pakub välja järgmise mõistliku sammu. Mahukamate käitusereeglite jaoks on abiks piiratud funktsionaalsuse ja tagasirullimise (rollback) plaan.

Kaitske kliendipõhiseid hindu ja sisemisi välju

Toote API-d sisaldavad sageli rohkem andmeid kui avalikult nähtavad teated: ostuhinnad, sisemised marginaalid, tarnijamärkused või kliendipõhised eritingimused. Vestlusbot ei tohi neid välju näha puhtalt seetõttu, et selle serveril on tehniline juurdepääs API-le. OWASP-i soovitus objektipõhise omaduste autoriseerimise kohta soovitab tagastatavaid omadusi teadlikult valida ja kontrollida nendele juurdepääsu.

Kasutage seetõttu lubatud väljade valget nimekirja (whitelist). Sisselogimata külastajad saavad näha vaid avalikke pakkumisi. Kliendipõhised hinnad eeldavad kontrollitud identiteeti, kliendiseost ja õigusi. See otsus kuulub serveripoolsesse integratsioonikihti, mitte viipa (prompti) sisse. Logid ei tohiks tundlikke hinna- või kliendiandmeid tarbetult salvestada.

Lahendage variantidega seotud küsimused süsteemselt

Keelemudel oskab teksti loomulikult sõnastada, kuid see ei tohiks välja mõelda olematuid variantikombinatsioone. Salvestage lubatud väärtused ja suhted struktureeritud reeglitena: milline suurus on saadaval millises värvis? Milline pinge sobib millisele turule? Milline komponent ühildub? Vestlusbot kogub vestluse käigus tunnused ja edastab need deterministlikule kontrollile.

Keerukate valiku- ja pakkumisprotsesside puhul tasub nõustamine ja siduvus teineteisest eraldada. Artikkel Tehisintellekti vestlusbot tootekonfiguraatorite jaoks näitab, kuidas variante kontrollida ja pakkumisi ette valmistada. Ajakohane andmepäring täiendab seda protsessi: lubatud konfiguratsioon ei pruugi olla automaatselt tarnitav või saadaval viimati teadaoleva hinnaga.

Esitage vastused koos kontekstiga, mitte pelga numbrina

Väljund ei tohiks kasutajat tehniliste üksikasjadega üle koormata, kuid peab mainima olulisi tingimusi. Usaldusväärne vastusemuster sisaldab:

• toote ja variandi ühest nimetust,
• väärtust koos ühiku või valuutaga,
• kehtivusala, näiteks turgu või asukohta,
• mõistetavat ajakohasuse viidet,
• märkust mittekohustavate andmete puhul,
• järgmist sammu kinnituse puudumisel.

Näide: „40-sentimeetrise rohelise variandi hind Austrias on praegu kinnitatud. Soovitud asukoha laoseisu kontrollin eraldi.“ See on täpsem kui „Jah, saadaval“, ehkki mõlemad vastused on pikkuselt sarnased. Tehniliste selgituste puhul võivad lisaks abiks olla viited allikatele; selleks sobib juhend Vestlusboti vastuste põhjendamine allikatega.

Jälgige kvaliteeti realistlike testidega

Ärge testige ainult edukalt toimivaid päringuid. Korralik testpakett sisaldab ka ümbernimetatud tooteid, tootmisest maha võetud variante, hinnamuutusi, kahte samanimelist mudelit, tühje API-välju, päringu aegumisi ja puuduvaid õigusi. Võrrelge vestlusboti vastust samal ajahetkel saadud allikavastusega.

Igapäevatöös on kasulikud järgmised signaalid:

• kinnitatud väärtusega dünaamiliste päringute osakaal,
• vahemälu tabamused, uuesti valideerimised ja tagasilükatud aegunud väärtused,
• veamäär ja päringu kestus allikasüsteemide kaupa,
• täpsustavad küsimused ebaselgete variantide tõttu,
• asenduslahendused ja üleminekud inimesele andmetüübi lõikes,
• lahknevused vestlusboti ja e-poe andmete vahel kontrollihetkel.

Jälgige samuti, kas sagedased valepäringud viitavad andmeprotsessi probleemile. Kui kasutajad küsivad regulaarselt variandi kohta, mida kataloogis ei ole üheselt nimetatud, võib tootestruktuuri parandamine olla tõhusam kui keerukama viiba koostamine.

Meeleelespea juurutamiseks

1. Inventariseerige kõik vestlusboti kasutatavad tooteväljad.
2. Määrake iga välja jaoks allikas, vastutajad ja lubatud kehtivusala.
3. Ühtlustage toote ja variantide ID-d erinevate süsteemide vahel.
4. Pärige dünaamilisi välju kompaktsete serveripoolsete funktsioonide kaudu.
5. Dokumenteerige vahemälu kestus, valideerimine ja aegumise reegel iga välja kohta.
6. Eraldage tehniliselt avalikud ja kliendipõhised andmed.
7. Määratlege asenduslahendus (fallback) ja üleandmine inimesele iga kriitilise päringu jaoks.
8. Automatiseerige standard-, vea- ja õiguste testid.
9. Analüüsige pidevalt vastuste kvaliteeti ja andmete lahknevusi.

Alustage vähestest sagedasti küsitavatest väljadest, näiteks selgelt piiritletud tooterühma hinnast ja kättesaadavusest. Alles siis, kui tuvastamine, ajakohasus ja asenduslahendused toimivad, tuleks lisada muid süsteeme ja variante. Nii jääb integratsioon kontrollitavaks ja vastuste kvaliteet kasvab juhtitult.

Kokkuvõte: ajakohasus on vastamisreegel, mitte importimisprojekt

Tooteandmete ajakohasena hoidmine tehisintellekti vestlusbotis tähendab enamat kui lihtsalt korrapärast sünkroneerimist. Usaldusväärsus tekib ühestest variandi ID-dest, kindlast allikast iga välja jaoks, riskipõhistest vahemälureeglitest, serveripoolsetest õigustest ning ausast vastusest kinnituse puudumisel. Keelemudel sõnastab dialoogi; hind, laoseis ja lubatavus peavad pärinema kontrollitud süsteemidest.

Kui soovite selliseid andmevooge samm-sammult üles ehitada, leiate ülevaate lehelt ChatReacti funktsioonid. Alustage ühe tooterühmaga ja mõõtke, kas vestlusbot kinnitab infot sagedamini õigesti, küsib täpsustusi ja annab vajalikul hetkel suhtluse üle inimesele.

Allikad

• Google Search Central: Product structured data
• RFC 9111: HTTP Caching
• Schema.org: Product ja Schema.org: Offer
• OWASP API Security Top 10: Broken Object Property Level Authorization