Užklausų inžinerijoje daugiausia dėmesio skiriama tikslumui ir instrukcijų išsamumui. Didžiausia nauda produkcinėse sistemose pasiekiama patį dialogą laikant pagrindine projektavimo užduotimi.
Nurodžius sąlygos ir veiksmo ketinimus, modelis mokomas priimti sprendimus, o ne gauna scenarijų, iš kurio negali ištrūkti. Vieta užklausoje pati savaime yra instrukcija. Pirmiausia pateikiama tapatybė, viduryje – elgsenos niuansai, pabaigoje – griežti apribojimai, o visa, kas išties svarbu, pateikiama abiejose vietose.
Užklausos rašymas norimu tonu, užuot jį apibūdinus, yra vienas didžiausią poveikį darančių pokyčių.
Nuosekliausiai veikia tie agentai, kurių užklausose skirtingi pokalbio momentai laikomi atskiromis sąveikomis, turinčiomis savitą tinkamą formą, tačiau visą laiką išlaikančiomis aiškiai atpažįstamą tą patį toną.
Kai kuriais atvejais mąstančių ir kalbančių agentų atskyrimas padeda pateikti nuoseklesnius, faktais pagrįstus atsakymus ir neleidžia vidiniam protavimui prasiskverbti į atsakymus.
Anksčiau pristatėme naują užklausų kūrimo paradigmą, pagrįstą lingvistikos ir kognityvinės psichologijos įžvalgomis. Rašėme apie tai, kaip svarbu sukurti aiškią, tiksliai apibrėžtą problemos erdvę, kurioje galėtų veikti agentas, ir kaip ši erdvė turi apimti klientams skirtam DI būdingą dialogo meta užduotį.
Dabar apžvelgsime kelis praktinius mūsų užklausų pokyčius, atsiradusius pritaikant šiuos principus produkcinėse sistemose.
Atlikus šimtus užklausų iteracijų veikiančiose klientams skirtose sistemose, didžiausią naudą suteikė ne papildomos instrukcijos, daugybė pavyzdžių ar įprastų užklausų inžinerijos normų laikymasis. Ją suteikė dialogo pavertimas problemos esme.
Nuolat tyrinėjant ir bandant išryškėjo keli veiksmingi metodai. Keisdavome užklausą ir stebėdavome, kur pokalbis pavyksta ar nutrūksta, o nesėkmių priežasčių ieškodavome nurodymų veiksmingume, užklausos struktūroje ir vartojamoje kalboje. Taip atsirado keli pakartojami modeliai, keičiantys tai, kaip agentas supranta savo vaidmenį pokalbyje, pasirenka kitą veiksmą ir išlaiko nuoseklų toną kintant kontekstui.
Toliau pateikiama ne universali sistema ir neteigiama, kad užklausų kūrimo problema jau „išspręsta“. Tai penki modeliai, apibendrinantys tai, kas pasiteisino produkcinėse sistemose, kai siekta ne tik funkcinio tikslumo, bet ir geresnio dialogo – nuoseklių, natūralių atsakymų, galinčių perteikti prekės ženklą.
Nors agentinę sistemą galima kurti įvairiai, orkestruojamos kelių agentų darbo eigos tebėra populiarios. Būtent tokiose sistemose nuosekliausią pagerėjimą pasiekėme atskyrę mąstančius agentus nuo kalbančių agentų.
Ketinimų orkestravimas, klasifikavimas, žinių išgavimas ir įrankių naudojimas – visa tai vidinės operacijos. Klientams skirti atsakymai priklauso išoriniam sluoksniui. Kai tą patį veiksmą vienu metu atlieka tas pats agentas, į atsakymus gali prasiskverbti vidinis protavimas ir logika. Atsakymai tampa pernelyg atsargūs, apkrauti išlygomis arba grindžiami proceso logika, o ne žmogaus poreikiais.
Vien šis apribojimas atlieka stebėtinai daug funkcijų. Jis išlaiko atsakymų sąsają su vykstančiu pokalbiu, neleidžia iš naujo nustatyti konteksto ir padeda pasiekti tai, ką vadiname „tik pokyčio pateikimu“. Galiausiai agentas prideda tik mažiausią naują dalyką, kuris iš tiesų padeda naudotojui judėti pirmyn.
Svarbu nuspręsti ir tai, kokio tipo atsakymą pateikti. Pastebėjome, kad paprašius kalbančio agento prieš rašant pasirinkti veiksmo tipą – atsakyti, patikslinti, nukreipti ar paprašyti palaukti – patikimai sumažėjo dažniausia pokalbio klaida: ne prastai parašytas, o apskritai netinkamas atsakymas.
Verta pažymėti, kad tinkamomis sąlygomis naujausi priešakiniai modeliai jau ima paneigti šio principo prielaidą. Vis dėlto dėl įvairių priežasčių daugelis kūrėjų tebesiremia mažesniais ar senesniais modeliais. Tokiais atvejais tikrai rekomenduojame atskirti vidines ir naudotojui skirtas funkcijas.
Neprotaujantiems modeliams metodas naudojant kelis pavyzdžius tinka, nes pavyzdžiai yra konkretūs, juos greita pateikti, o modeliai į juos gerai reaguoja. Problema – persimokymas. Pateikus modeliui pavyzdį, jis įsikimba į žodžius, ritmą bei formą ir vis kuria labai panašius atsakymus, net kai situacija pasikeičia.
Netyčia parašote scenarijų, iš kurio modelis negali ištrūkti.
Patvaresnė alternatyva – įgyvendinimo ketinimai arba euristinės taisyklės. Užuot rodę modeliui, ką sakyti konkrečiais atvejais*,* pateikiame bendresnę sužadinimo sąlygos ir veiksmo porą: jei įvyksta X, atlik Y.
Esminis skirtumas tas, kad X ir Y ne siauriname po vieną pavyzdį, taip darydami juos vis nelankstesnius, o kiekvieną tiksliai apibrėžiame tokia aiškia instrukcija, kad pavyzdžiai tampa nereikalingi. Taip agentas reaguoja į tikrą pokalbio įvairovę, o ne ieško šabloną atitinkančių dėsningumų.
Praktiškai tai panašiau ne į pavyzdžius, o į vykdytinas taisykles:
Jei trūksta svarbios informacijos, užduok vieną tikslinamąjį klausimą.
Jei atsakymo negalima pagrįsti, pasakyk tai tiesiai ir pasiūlyk geriausią galimą kitą žingsnį.
Jei užklausa pažeidžia apsaugos taisyklę, trumpai atsisakyk ją vykdyti ir be iškilmingų paaiškinimų nukreipk kitur.
Tai neatrodo įspūdingai, bet yra gerokai patikimiau už pavyzdinių atsakymų biblioteką, nes modelis mokomas priimti sprendimą, o ne ką nors kartoti.
Elemento vieta užklausoje lemia jam teikiamą svarbą. Šį dėsningumą nuosekliai stebime įvairiuose modeliuose ir diegimuose. Užklausos pradžia ir pabaiga patraukia neproporcingai daug dėmesio. Viduryje pateikiami niuansai – būtent ten jiems ir vieta.
Atsižvelgdami į tai ir sudarome savo užklausas. Agento vaidmenį ir savivoką pateikiame pradžioje, kad pirmiausia nustatytume jo tapatybę. Viduryje pateikiama išsami elgsenos informacija: tikėtina pokalbio eiga, atsakymus lemiančios euristinės taisyklės ir situacijos, kurias agentas turi gebėti valdyti. Griežtus apribojimus ir neginčijamas taisykles pateikiame pabaigoje, kad jos geriausiai išliktų dėmesio centre.
Viską, kas išties svarbu, pateikiame abiejose vietose. Konkreti išvesties taisyklė, pavyzdžiui, griežtas skyrybos ar formatavimo nurodymas, gali lengvai pasimesti, jei ilgos užklausos viduryje paminima tik kartą. Pakartota pabaigoje ji įsimenama.
Kalbant apie naujausios informacijos poveikį, verta pažymėti, kad naudojamos susistemintos išvestys iš esmės tampa pačia paskutine užklausos instrukcija. Susistemintų išvesčių aprašų laukai daro kokybinį poveikį atsakymams ir sudaro griežtesnę išvesties sutartį nei likusi užklausos dalis.
Taip pat supratome, kad tonui perteikti nereikėtų naudoti kelių pavyzdžių. Šis pokytis padarė vieną didžiausių teigiamų poveikių mūsų klientams skirtiems agentams.
Užuot tai darę, visą užklausą rašome norimu tonu. Ne apibūdiname toną ir ne pateikiame jį apytiksliai nusakančių būdvardžių rinkinį, o iš tiesų rašome tuo tonu – rišliu tekstu nuo pirmos iki paskutinės eilutės. Pati užklausa tampa pavyzdžiu. Tai vadiname „antiscenarijiškumu“: modelį skatiname mėgdžioti įvesties stilių, tačiau leidžiame vartoti įvairesnę kalbą ir frazes, atitinkančias bendrą pačios užklausos kryptį.
Taip užklausa skatiname įvairovę, išlaikydami nuoseklų toną. Tai mūsų strategijos dalis: dialogas tampa kiekvieno agento užduoties pagrindu, o tiesioginių instrukcijų, kurias stengiamės riboti, neprireikia.
Jei pateikiame tiesioginių tono pavyzdžių, jie parodo, „ko nedaryti“. Pavyzdžiui: “No em dashes. Ever. No clichés. No policy dumping. No over-explanation when a single sentence will close the loop.” Neigiami apribojimai yra ir tikslesni, ir mažiau varžantys nei teigiami siekiai, nes jie įvardija klaidas, į kurias modelis dažniausiai linkęs nukrypti.
Čia svarbus ir formatavimas – jis taip pat lemia atsakymo toną. Punktų, antraščių ir skliaustuose pateiktų instrukcijų kupina užklausa skatina modelį pateikti tvarkingesnę, dalykiškesnę išvestį. Jei išvestis turi priminti pokalbį, įvestis neturėtų atrodyti kaip sutrumpintas specifikacijų dokumentas.
Dauguma užklausų tono nurodymų galiausiai apsiriboja asmenybe. Pateikiamas būdvardžių rinkinys, turintis nusakyti, kaip turėtų kalbėti agentas. Šiltai. Profesionaliai. Draugiškai, bet glaustai. Šie apibūdinimai nėra klaidingi, tačiau tai, kaip tonas skamba pokalbyje, iš tiesų lemia registras – kaip tas pats charakteris elgiasi skirtingose socialinėse situacijose.
Laukimo pranešimas, rodomas apdorojant užklausą, neturėtų skambėti kaip galutinis atsakymas. Apsaugos priemonės suaktyvintas atsakymas neturėtų būti toks pat energingas kaip lengvas pokalbis. Nusivylusiam klientui nereikėtų atsakyti taip pat žaismingai ar šmaikščiai kaip tiesiog naršančiam.
Tuo prekės ženklo tonas skiriasi nuo pokalbių projektavimo. Prekės ženklo tonas dažnai apibūdina charakterį, o pokalbių projektavimas lemia, kaip tas charakteris elgiasi kintant aplinkybėms. Jei tai atliekame tinkamai, esame ne vien tekstų kūrėjai, dirbantys su DI išvestimis. Mes projektuojame, kaip tonas kinta vykstant pokalbiui.
Tikriausiai pastebėjote, kad nė vienas iš šių modelių nėra techniškai sudėtingas. Iš dalies tokia ir yra esmė. Agentinės sistemos architektūra svarbi, tačiau norint kokybiško pokalbio reikia daug laiko skirti užklausoms projektuoti ir tobulinti.
Atotrūkį tarp grynai funkcinio ir iš tiesų pokalbiško DI panaikina ne techninis projektavimas, o aiškesnis supratimas, kaip žmonių dialoge veikia kalba ir dėmesys, bei dialogo pavertimas agentų sprendžiamos problemos pagrindu.
DI produktų komandos, inžinieriai ir patirties kūrėjai klientams skirto DI pokalbius turėtų projektuoti taip pat kruopščiai, kaip siekia techninio meistriškumo. Kitoje šių pokalbių pusėje esantys žmonės nemato nei modelio, nei kelių agentų bendradarbiavimo, nei įrankio iškvietimo – jie patiria tik sąveiką, kuri atrodo tinkama arba ne. Sąveiką, kuri arba stiprina pasitikėjimą, arba jį pakerta.
Galiausiai niekas nepatiria architektūros. Žmonės patiria pokalbį.
Pokalbis ir yra produktas.