DI pokalbių robotas atnaujinant svetainę: Staging, nukreipimai ir Go-live QA

Svetainės atnaujinimas pakeičia ne tik dizainą, navigaciją ir URL adresus. Jis taip pat pakeičia DI pokalbių roboto žinių bazę. Nauji produktų puslapiai pakeičia senus kelius, pagalbos tekstai perkeliami į kitas skiltis, o tam tikras turinys visai išnyksta. Jei robotas šio perėjimo metu toliau dirba su pasenusiu indeksu, jis pateiks rišlius, tačiau galbūt neteisingus arba nebereikšmingus atsakymus.

Todėl DI pokalbių roboto nereikėtų traktuoti kaip antrinio valdiklio. Jis turi būti įtrauktas į svetainės atnaujinimo planą kartu su nukreipimais, svetainės medžiu (sitemap), analitika ir formomis. Svarbiausia – kontroliuojama grandinė: inventorizuoti šaltinius, švariai atskirti „staging“ aplinką, suindeksuoti naują turinį, išbandyti atsakymus ir tik tada patvirtinti duomenis gamybinei (produkcinei) aplinkai.

Kodėl pokalbių robotas turi būti svetainės atnaujinimo plano dalis

Įprastas svetainės atnaujinimo testas tikrina, ar puslapiai užsikrauna, ar veikia nukreipimai ir ar galima išsiųsti formas. RAG grįsto pokalbių roboto atveju atsiranda antras lygmuo: kokios teksto ištraukos randamos, koks šaltinis cituojamas ir ar atsakymas vis dar tinka naujai puslapių struktūrai?

Informatyvusis generavimas išplečiant paiešką (angl. Retrieval-Augmented Generation, RAG) sujungia kalbos modelį su jūsų pačių turiniu. Paieškos komponentas iš indekso pateikia atitinkamas teksto ištraukas, o modelis iš jų suformuluoja atsakymą. Microsoft kaip pagrindines užduotis, be kitų, įvardija aktualius (užuot buvusius tiesiog išsamius) rezultatus, laiku atliekamą indeksavimą ir kontroliuojamą prieigą prie šaltinių. Svetainės atnaujinimo atveju tai reiškia: teisingas nukreipimas naršyklėje automatiškai neatnaujina pokalbių roboto indekso.

Todėl suplanuokite tris tarpusavyje susijusius duomenų srautus. Žiniatinklio serveris nukreipia senus URL adresus. Paieškos sistemos gauna kanonines nuorodas, būsenos kodus ir atnaujintą svetainės medį (sitemap). Pokalbių robotas gauna iš naujo sukurtą arba tikslingai atnaujintą žinių bazę. Tik tada, kai visi trys lygmenys rodo į tuos pačius tikslinius puslapius, perkėlimas yra nuoseklus.

„Staging“ aplinkos parengimas saugiai ir realistiškai

Apsaugoti peržiūrą neiškraipant testo rezultatų

Bandomoji („staging“) svetainė neturėtų būti netyčia suindeksuota viešai. Įprastoms paieškos sistemoms papildomi apsaugos sluoksniai gali būti noindex arba atitinkama X-Robots-Tag žyma. Tačiau Google atkreipia dėmesį, kad noindex nurodymą galima perskaityti tik tuo atveju, jei paieškos robotui leidžiama pasiekti puslapį. Todėl tikrai konfidencialiam „staging“ turiniui prieigos apsauga ir teisės yra svarbesnės nei vien tik Robots taisyklė.

Pokalbių roboto paieškos robotui (crawler) vis tiek reikia kontroliuojamos prieigos. Tam naudokite atskirus prisijungimo duomenis, aiškiai apibrėžtą leidžiamų adresų sąrašą (allowlist) ir atskirą „staging“ indeksą. Taip apsisaugosite, kad juodraščiai nepatektų į gamybinius atsakymus. Kartu robotą bus galima išbandyti naudojant realistišką navigaciją, PDF dokumentus ir struktūrizuotą turinį.

Griežtai atskirti konfigūracijas

„Staging“ ir gamybinė (produkcinė) aplinka neturėtų naudoti to paties indekso, saityno kibeklio (webhook) ar analitikos duomenų srauto. Suteikite unikalius pavadinimus ir prieš kiekvieną testą patikrinkite, į kurį tikslą rodo atitinkama konfigūracija. Paprastame patvirtinimo sąraše turėtų būti bent domenas, crawl pradiniai taškai, leidžiami failų tipai, išimtys, indekso pavadinimas ir atsakingas asmuo.

Ypač svarbios yra formos ir perdavimas žmonėms. Bandomasis pokalbis negali siųsti tikrų potencialių klientų (leads) pardavimų skyriui ir kurti gamybinių aptarnavimo užklausų. Naudokite pažymėtus testavimo tikslus ir patikrinkite perdavimą žmogui (Human-Handoff) kaip atskirą procesą.

URL adresų susiejimą ir šaltinių inventorių tvarkyti kartu

Keičiantis URL adresams, Google rekomenduoja tiksliai susieti senus adresus su naujais ir naudoti nuolatinius serverio pusės nukreipimus. Pokalbių robotui tą patį susiejimo (mapping) sąrašą reikėtų papildyti žinių laukais. Taip SEO lentelė tapo bendru svetainės, turinio ir DI valdymo instrumentu.

Kiekvienam svarbiam šaltiniui užfiksuokite bent šiuos duomenis:

• senąjį ir naująjį URL bei tikėtiną HTTP būseną,
• puslapio tipą, kalbą ir profesinę atsakomybę,
• ar šaltinis vis dar galioja, yra pakeistas ar pašalintas,
• ar jis gali būti įtrauktas į pokalbių roboto indeksą,
• kokius testinius klausimus šis šaltinis turėtų padengti.

Nenukreipkite seno puslapio bendrai į pagrindinį puslapį. Naujas tikslinis puslapis turėtų tikti pagal turinį. Visam laikui perkeltam turiniui nuolatiniai nukreipimai yra teisingas signalas; Google įvardija serverio pusės 301 ir 308 nukreipimus kaip nuolatinius variantus. Pašalintas turinys be tikro pakaitalo neturėtų dirbtinai rodyti į netinkamą puslapį.

Taip pat patikrinkite vidines nuorodas, kanonines nuorodas ir svetainės medį (sitemap). Pokalbių roboto crawler'is turėtų tiesiogiai įtraukti naujus tikslinius URL adresus, o ne nuolat eiti per senus adresus. Tai sumažina nereikalingas užklausas ir daro šaltinių nuorodas atsakymuose suprantamesnes.

Kontroliuojamas žinių bazės atkūrimas iš naujo

Svetainės atnaujinimas yra geras metas išvalyti žinių bazę. Pašalinkite dubliuotus juodraščius, pasenusius PDF failus ir puslapius, skirtus tik kampanijoms ar vidiniams testams. Tada apibrėžkite leidžiamus nuskaitymo (crawl) pradinius taškus ir išimtis. Instrukciją rasite straipsnyje Palaikykite DI pokalbių roboto žinių bazę atnaujintą.

Indeksuojant antraštes, pastraipas, sąrašus ir lenteles reikėtų prasmingai padalyti į skiltis. Per dideli teksto blokai dažnai pateikia per daug konteksto, o labai mažos fragmentų dalys praranda savo reikšmę. Microsoft įvardija skaidymą (chunking), vektorizavimą ir hibridinę paiešką kaip įprastų RAG sistemų dalis. Tačiau svarbiausia ne vien tik metodas, o tai, ar svarbus naujas turinys patikimai randamas užduodant tikrus vartotojų klausimus.

Atlikite pirmąjį pilną nuskaitymą „staging“ indekse ir registruokite klaidos puslapius, užblokuotus failus bei neįprastai mažus ar didelius dokumentus. Po to paleiskite antrąjį, inkrementinį (prieauginį) nuskaitymą. Taip patikrinsite, ar pakeitimai iš tiesų atpažįstami ir ar ištrintas turinys pašalinamas iš indekso.

„Golden Set“ sukūrimas svetainės atnaujinimo QA patikrai

Atsitiktinės imties iš kelių malonių klausimų nepakanka. Sukurkite „Golden Set“ iš realių paieškos tikslų ir tikėtinų pagrindinių teiginių. Kaip struktūrizuotai įvertinti tokius testus, rodoma vadove Matuoti DI pokalbių roboto atsakymų kokybę.

Svetainės atnaujinimui rinkinį turėtų sudaryti įvairios rizikos kategorijos:

• klausimai apie pagrindinius produktus, paslaugas, kainas ir sąlygas,
• klausimai, kurių atsakymai persikėlė į naują URL adresą,
• klausimai apie sąmoningai pašalintą arba sujungtą turinį,
• dviprasmiškos formuluotės ir tipinės rašybos klaidos,
• klausimai visomis faktinėmis siūlomomis kalbomis,
• atvejai, kai robotas neturi teisės pateikti užtikrinto atsakymo.

Vertinkite ne tik pačią formuluotę. Patikrinkite, ar buvo pateiktas teisingas šaltinis, ar nuorodos rodo į naują domeną bei teisingą kalbos kelią, ir ar skaičiai, datos bei produktų pavadinimai buvo perimti tiksliai. Gražus sakinys su senu URL adresu nėra išlaikytas testas.

Maršrutizavimą, formas ir perdavimą testuoti atskirai

Daugelis pokalbių robotų ne tik atsako į klausimus, bet ir kvalifikuoja užklausas arba perduoda pokalbius. Po svetainės atnaujinimo nauji formų laukai, kiti įvykiai ar pasikeitusios maršrutizavimo taisyklės gali pastebimai sutrikti. Todėl išbandykite bent vieną sėkmingą ir vieną atmestą eigą kiekvienam svarbiam tikslui. Taip pat patikrinkite, ar matomi sutikimo tekstai ir ar perduoti duomenys patenka į teisingą sistemą.

Daugiakalbėse svetainėse kiekviena kalba turi būti tikrinama kaip atskiras vartotojo kelias. Veikiantis dialogas vokiečių kalba neįrodo, kad prancūziškos nuorodos, kroatiški šaltiniai ar angliški perdavimo tekstai yra teisingi.

Paskelbimas („Go-live“) kontroliuojama tvarka

Pats perjungimo momentas turėtų būti trumpas ir aiškus. Įšaldykite turinio pakeitimus aiškiai apibrėžtam laikotarpiui, eksportuokite galutinį URL susiejimą ir užfiksuokite patvirtintą indekso būseną. Po to galima paskelbti naująją svetainę ir aktyvuoti nukreipimo logiką.

Praktiška eiliškumo tvarka yra ši:

1. Pateikti gamybinę aplinką ir patikrinti pagrindinį puslapių užkrovimą.
2. Patikrinti nukreipimus, kanonines nuorodas, svetainės medį (sitemap) ir Robots signalus.
3. Sukurti gamybinį pokalbių roboto indeksą su patvirtintais šaltiniais.
4. Atsiųsti „Golden Set“ testus gamybinėje aplinkoje.
5. Patikrinti formas, analitiką ir perdavimą žmogui (Human-Handoff) naudojant pažymėtus testinius atvejus.
6. Tik po to padaryti pokalbių robotą matomą visiems lankytojams.

Jei pokalbių robotas turi likti matomas perkėlimo metu, prasminga naudoti apribotą režimą: atsakinėti tik į stabilias temas, esant neaiškiems klausimams skaidriai nurodyti apie vykstantį atnaujinimą ir pasiūlyti galimybę susisiekti su žmogumi. Neišgalvokite laikinų informacijos variantų.

Po svetainės atnaujinimo: tikslingas klaidų stebėjimas

Pirmosiomis dienomis komanda turėtų stebėti ne tik puslapių peržiūras. Svarbūs ir neatsakyti klausimai, Fallback dažnumas, paspaudimai ant šaltinių, dažni seni URL adresai ir pokalbiai, kurie netikėtai perduodami žmonėms. Šie signalai rodo, kur susiejimo ar žinių bazės srityse dar yra spragų.

Rankiniu būdu patikrinkite dažniausiai naudojamų atsakymų pavyzdžius. Jei robotas nukreipia į seną URL, priežastis gali būti išsaugotame dokumente, indekse arba standžiai užkoduotame atsakymo šablone. Ištaisykite šaltinį, atlikite tikslingą pakartotinį indeksavimą ir pakartokite tą patį testinį atvejį. Bendras viso turinio generavimas iš naujo apsunkina klaidų paiešką.

Taip pat suplanuokite „staging“ prieigų ir testinių saityno kibeklių (webhooks) pašalinimą. Nebereikalingi prisijungimo duomenys turėtų būti išjungti, laikini leidžiamų adresų sąrašo įrašai pašalinti, o bandomieji indeksai aiškiai archyvuojami arba ištrinami. Taip atnaujinimo infrastruktūra nepastebėtai neliks kaip nuolatinis atakos plotas.

Trumpas svetainės atnaujinimo kontrolinis sąrašas komandoms

• Pokalbių roboto atsakingi asmenys yra įvardyti atnaujinimo plane ir patvirtinimo procese.
• „Staging“ aplinka yra apsaugota prieiga ir atskirta nuo gamybinio indekso.
• Seni ir nauji URL adresai susieti su šaltinio būsena ir testavimo klausimais.
• Nuskaitymo (crawl) taisyklės, kalbos, PDF ir išimtys buvo patikrintos.
• Naujasis indeksas išbandytas visiškai, o po to – inkrementiškai.
• „Golden Set“ padengia pagrindinius klausimus, senus URL adresus, neigiamus atvejus ir perdavimą žmogui.
• Visos nuorodos, skaičiai, pavadinimai ir kalbų keliai atsakymuose sutampa.
• Stebėjimas (monitoringas) ir atsakomybės po Go-live paleidimo yra nustatyti.

Tie, kurie pokalbių robotą traktuoja kaip atskirą atnaujinimo darbų srautą, išvengia pasenusių atsakymų ir neaiškių šaltinių. Kartu sukuriamas švarus procesas, kurį galima pakartotinai panaudoti vėlesniems turinio pakeitimams. Informaciją apie techninį integruojamumą taip pat rasite straipsnyje DI pokalbių roboto integravimas į svetainę.

Šaltiniai

• Google Search Central: Site Moves and Migrations
• Google Search Central: Redirects and Google Search
• Google Search Central: Robots Meta Tags Specifications
• Microsoft Learn: Retrieval-augmented generation in Azure AI Search

Planuojate atnaujinti svetainę ir norite kontroliuojamai perkelti savo svetainės pokalbių roboto žinių bazę? Apibrėžkite šaltinius, testavimo klausimus ir perdavimo taisykles prieš Go-live. ChatReact padeda struktūrizuoti svetainės turinį kaip patikimą pagrindą daugiakalbiams dialogams.