Lataa tietämys, ehdota käyttötapauksia, hyväksy SQL ja ota käyttöön: täydellinen chatbotin työnkulku

Matka "meidän pitäisi lisätä chatbotti" -ajatuksesta "chatbotti on live-tilassa ja käsittelee keskusteluja" mitataan yleensä viikoissa tai kuukausissa. Vaatimusdokumentit kirjoitetaan. Myyjät arvioidaan. Integraatiokokousten varaus. Pilottiohjelmat ehdotetaan. Siihen mennessä kun chatbotti lopulta käynnistyy, alkuperäinen kiireellisyys joka motivoi projektia, on usein haihtunut organisaation taustalle, korvattuna uusilla prioriteeteilla jotka imivät huomion ja budjetin jota chatbot-projekti tarvitsi loppuunsaattamiseen. Käyttöönottotaikataulu on hautausmaa, jonne hyvät chatbot-aikomukset menevät kuolemaan.

ChatBot API tiivistää tämän aikajanan rakentamalla käyttöönottoprosessin lineaariseksi putkeksi selkeillä, erillisillä vaiheilla. Jokaisella vaiheella on määritetty syöte, määritetty tulos ja selkeä siirtymä seuraavaan vaiheeseen. Ei ole epäselvyyttä siitä, mitä on tehtävä jokaisessa vaiheessa, ei pyöräviä riippuvuuksia jotka vaativat aiempien päätösten uudelleentarkastelua, ja ei arkkitehtuurivalinnat jotka vaativat syvällistä teknistä asiantuntemusta. Putki kulkee yhteen suuntaan, raakoista tietämysdokumenteista live-chatbottiin, ja jokainen vaihe kestää minuutteja eikä päiviä.

Ymmärtäminen tämä putki yksityiskohdissaan on arvokasta ei vain toteutukselle vaan myös realististen odotusten asettamiselle siitä, mitä kukin vaihe vaikuttaa lopputulokseen. Chatbotin laatu riippuu siitä, mitä tapahtuu jokaisessa vaiheessa, ja tietäminen mihin sijoittaa ylimääräistä huomiota verrattuna mihin oletusarvot riittävät tuottaa parempia tuloksia lyhyemmässä ajassa kuin koko prosessin käsittely mustana laatikkona joka joko toimii tai ei.

Ensimmäinen vaihe: tietämyksen lataaminen, joka määrittää mitä chatbotti tietää

Putki alkaa tietämyksen lataamisen. Tämä on perustava vaihe, koska kaikki mitä seuraa riippuu tietämyskannan laadusta ja täydellisyydestä. Tässä vaiheessa ladatut dokumentit tulevat chatbotin koko ymmärryksestä liiketoiminnasta, sen tuotteista, sen käytännöistä ja sen menettelyistä. Mitään mitä ei ole esitetty ladatuissa dokumenteissa ei ole chatbotin näkökulmasta tuntematon alue, jota se joko käsittelee tunnistamalla tietämättömyyden tai palautumalla yleiseen tietämykseen, joka saattaa tai ei välttämättä ole tarkka tietylle liiketoiminnalle.

Latausprosessi hyväksyy dokumentit vakiomuodoissa ja käsittelee niitä ingestointipipeen kautta, joka suorittaa useita toimintoja automaattisesti. Teksti poimitaan dokumentin muodosta, säilyttäen rakenteelliset elementit kuten otsikot, osiot ja luettelot samalla hylätään muotoilu, joka ei kuljeta semanttista arvoa. Poimittu teksti jaetaan sitten segmentteihin, jotka ovat riittävän pieniä yksittäin haettavaksi mutta riittävän suuri säilyttää konteksti jokaisessa segmentissä. Nämä segmentit upotetaan vektoriavaruuteen, joka mahdollistaa semanttisen haun, mikä tarkoittaa, että chatbotti löytää merkityksen perusteella, eikä tarkan avainsana-vastaavuuden perusteella.

Tämä käsittely tapahtuu lataamisen jälkeen taustalla ja tyypillisesti valmistuu muutamissa minuuteissa kohtuullisissa asiakirjoissa. Käsittelyn aikana järjestelmä analysoi sisältöä ymmärtääkseen sen aiherakenteet, joka syötetään seuraavaan putken vaiheeseen. Käyttäjä ei tarvitse ymmärtää vektoriupoituksia tai semanttista hakua niistä hyötyäkseen. Heidän on ymmärrettävä, että heidän lataamat dokumentit tulevat chatbotin tietämykseksi, ja että täydellisemmät, selkeämmin kirjoitetut dokumentit tuottavat kyvykkäämmän chatbotin.

Käytännöllinen lähestymistapa tietämyksen lataamisessa priorisoi dokumentit, jotka käsittelevät yleisimpiä vuorovaikutuksia joita chatbotti käsittelee. Jos ensisijainen tarkoitus on asiakastuki, UKK-dokumentti, vianmääritysopas ja tuotteen käyttöopas ovat korkeimman prioriteetin latauksia. Jos ensisijainen tarkoitus on myynninedistävä oikaiseminen, tuotteiden vertailuoppaat, hinnoittelun dokumentaatio ja ihanteellisen asiakkaan profiilin kuvaukset ovat tärkeitä. Aloittamalla korkeimman vaikutuksen dokumenteista ja lisäämällä toissijaiset materiaalit myöhemmin sallii chatbotille käsitellä yleisimmät skenaariot heti kun tietämyskanta jatkaa laajentumista.

Toinen vaihe: käyttötapausten ehdottaminen ladatun tietämyksen perusteella

Tietämyskannan käsittelyn jälkeen järjestelmä analysoi sisältöä ehdottaakseen käyttötapauksia joita chatbotti voisi kohtuullisesti käsitellä käytettävissä olevan tiedon perusteella. Tämä ehdottelun vaihe on yksi putken arvokkaimpia osia, koska se siltoittaa kuilun "tässä ovat dokumenttimme" ja "tässä on mitä chatbottin tulisi tehdä", kuilua, jonka monet chatbot-toteutukset kamppailevat ylittääkseen ilman laajoja suunnitteluistuntoja.

Ehdotukset luodaan tutkimalla ladattujen dokumenttien aihepiirin kattavuutta ja kartoittamalla tämä kattavuus yleisiin chatbot-vuorovaikutuskuvioihin. Jos tietämyskanta sisältää tuotteen dokumentaatiota, järjestelmä ehdottaa tuotetietojen käyttötapausta. Jos se sisältää vianmääritysoppaita, se ehdottaa teknisen tuen käyttötapausta. Jos se sisältää hinnoittelutietoja, se ehdottaa hintatiedustelu-käyttötapausta. Jokaisessa ehdotuksessa on kuvaus skenaariosta jonka se kattaa, vuorovaikutustyypit joita käyttäjät saattavat esittää, ja odotettu käytös chatbottista käsiteltäessä kyseistä skenaariota.

Nämä ehdotukset ovat lähtökohtia, ei lopullisia konfiguraatioita. Käyttäjä tarkistaa jokaisen ehdotuksen ja joko hyväksyy sen sellaisenaan, muokkaa sitä paremmin omiin tarpeisiinsa, tai hylkää sen, jos skenaario ei ole merkityksellinen. Lisäkäyttötapaukset voidaan määrittää manuaalisesti skenaarioille, joita automatisoitu analyysi ei tunnistanut, kuten erikoistuneet työnkulut tai rajatapaukset, jotka ovat liiketoiminnalle tärkeitä mutta joita ei ole hyvin esitetty vakioasiakirjojen malleissa. Automatisoitua ehdotusta ja manuaalista hienosäätöä yhdistämällä tuotetaan käyttötapausjoukko, joka on sekä kattava että räätälöity liiketoiminnan todellisiin tarpeisiin.

Automatisoitua käyttötapausten ehdotusta hyödyllinen praktinen etu on, että se eliminoi tyhjän kankaan ongelman joka pysäyttää monet chatbot-toteutukset. Sijaan kysymyksestä "mitä meidän chatbotin tulisi tehdä?" ja yrityksestä luetella jokainen mahdollinen skenaario tyhjästä, tiimi aloittaa kuratoidulla ehdotuslistalla, joka perustuu todelliseen sisältöön jonka he ovat toimittaneet. Tämä on fundamentaalisesti helpompi lähtökohta joka nopeutaa päätöksentekoa ja vähentää riskiä jäädä huomaamatta tärkeitä skenaarioita joita dokumentit selvästi tukevat.

Kolmas vaihe: SQL-hyväksyntä ja laitteen salaisuuden luominen

Tekninen infrastruktuuri joka tukee chatbotin toimintaa vaatii tietokantarakenteita keskustelujen, istunnon tilan, käyttäjän vuorovaikutuksen ja tiedon haun lokien tallentamiseen. Putki luo tarvittavan SQL-skeeman hyväksyttyjen käyttötapausten perusteella ja esittää sen tarkastelulle ennen suorittamista. Tämä hyväksyntävaihe olemassa varmistaa läpinäkyvyys: käyttäjä näkee tarkalleen mitä tietokantarakenteita luodaan ennen niiden luomista, säilyttäen täyden näkyvyyden chatbotin käyttöönottamisen tekniseen jalanjälkeen.

Käyttäjille, joilla on tekninen tausta, SQL-tarkistus antaa mahdollisuuden tarkistaa että skeema vastaa heidän infrastruktuurin standardeja, nimeämiskäytäntöjä ja tiedon hallinnan käytäntöjä. Ei-teknisille käyttäjille tarkistusvaihe palvelee pääasiassa vahvistusporttina, joka varmistaa putken ei muokkaa tietokantarakenteita nimenomaisesti ilman suostumusta. Joka tapauksessa hyväksyntä on yksi toiminto: tarkista luotu skeema, vahvista se on hyväksyttävä, ja jatka. Skeema on suunniteltu olemaan itsenäinen, luoden uusia tauluja ja indeksejä muuttamatta mitään olemassa olevia tietokantarakenteita.

SQL-hyväksynnän jälkeen järjestelmä luo laitteen salaisuuden joka palvelee autentikointilupauksena kaikille chatbot-API:n vuorovaikutuksille. Tämä salaisuus käytetään frontend-integraation (olipa se verkkosivuston widgetia, mobiilisovelluksen komponenttia tai mukautettua käyttöliittymää) käyttäjien tuntemiseksi chatbot-taustalla ja luomalla valtuutettuja keskustelu-istuntoja. Salaisuuden luominen on automatisoitu ja noudattaa turvallisuuden parhaita käytäntöjä sisältäen riittävät entropian ja turvallisen tallennuksen. Käyttäjä kopioi salaisuuden ja tallentaa sen sovelluksensa konfiguraatiolle, suorittaen autentikoinnin asetuksen.

SQL-hyväksynnän ja salaisuuden luomisen yhdistelmä edustaa siirtymistä määrittelystä käyttöönottovalmiuteen. Ennen näitä vaiheita chatbotti on olemassa konfiguraationa: tietämyskanta, käyttötapaukset, ja käyttäytymisparametrit. Näiden vaiheiden jälkeen se on olemassa käyttöönotoitavana palveluna, jonka tietokantainfrastruktuuri on keskustelujen pysyvyys ja autentikoinnimekanismi on turvallinen pääsy. Putki on siirtynyt abstraktista määrittelystä konkreettiseen toteutukseen, ja lopullinen vaihe on yhdistää frontend.

Neljäs vaihe: käyttöönotto ja ensimmäiset live-keskustelut

Käyttöönotto yhdistää chatbotin sen käyttäjille vastakkaiseen käyttöliittymään. Erityinen integrointimekanismi riippuu missä chatbotti elää: verkkosivuston chat-widget, mobiilisovelluksen näyttö, Slack-integraatio, mukautettu hallintapaneeli, tai mikä tahansa muu käyttöliittymä, joka voi tehdä HTTP-pyyntöjä API:lle. Chatbot-API toimittaa päätepisteet istuntojen aloittamiselle, viestien lähettämiselle, vastausten vastaanottamiselle, ja keskustelun historian hakemiselle. Mikä tahansa frontend, joka voi kutsua näitä päätepisteistä voi isännöidä chatbottia.

Verkkosivuston käyttöönotolle yleisin kuvio on chat-widget joka näkyy tietyillä sivuilla tai koko sivuston läpi. Widget käsittelee keskustelun visuaalisen esityksen, käyttäjän viestien syöttökentän, ja chatbotin vastausten näyttämisen. Se kommunikoi chatbot-API:n kanssa laitteen salaisuuden käytöllä authentikoimiselle ja istunnon tunnisteella keskustelun jatkuvuudelle. Widget voidaan rakentaa alusta alkaen API-dokumentaation käyttäen, tai valmiita widget-mallit voidaan mukauttaa sivuston visuaaliseen malliin.

Ensimmäiset live-keskustelut ovat samanaikaisesti kaikkein jännittävät ja kaikkein informatiiviset koko prosessin osat. Oikeat käyttäjät esittävät kysymyksiä joita mikään suunnittelusessio ei odottanut. He ilmaisevat asioita tavoilla joita mikään käyttötapauksen määritys ei ennustanut. He odottavat tietoa jonka tietämyskanta melkein mutta ei täsmälleen sisällä. Jokainen näistä vuorovaikutuksista on oppimismahdollisuus joka syötetään takaisin tietämyskannan ja käyttötapausten hienosäätöihin joita kuvataan aiemmissa putken vaiheissa. Putki siis ei ole puhtaasti lineaarinen. Se on lineaarinen alkuperäisen käyttöönottamisen aikana ja tulee sykliseksi käyttöönottamisen aikana, live-keskustelun tiedoilla ohjaten jatkuvaa tietämyskannan ja käyttötapausten määritysten parantamista.

Keskustelun historia ja analyytika, joita API toimittaa, antavat chatbotin ylläpitäjälle näkyvyys mihin kysymyksiin kysytään eniten, mitkä vastaukset tyydyttävät käyttäjiä, ja missä chatbotti on puutteellinen. Tämä data muuntaa chatbotin staattisesta käyttöönotoista dynaamiseksi järjestelmäksi, joka parantuu käytöllä. Alkuperäinen viidentoista minuutin asetukset saavat chatbotin live-tilaan. Jatkuva hienosäätö, ohjattu todellisen keskustelun tiedoilla, tekee siitä vähitellen arvokkaamman seuraavien viikkojen ja kuukausien aikana.

Täydellinen putki kontekstissa

Nähtynä alusta loppuun, putki muuntaa yrityksen dokumentit live-keskustelulliseksi tekoälyä neljässä erillisessä vaiheessa: lataa tietämys, määritä käyttötapaukset, hyväksy infrastruktuuri, ja ota käyttöön. Jokaisella vaiheella on selkeät syötteet ja tulokset. Jokainen vaihe rakentuu edellisellä. Ja jokainen vaihe voidaan suorittaa minuuteissa eikä päivinä, mikä on mitä tekee viidentoista minuutin käyttöönottotaikataulu saavutettavaksi organisaatioille, jotka saapuvat prosessiin heidän tietämysdokumenttiensa jo järjestettyinä ja heidän keskustelullisten tavoitteiden jo ymmärrettyinä.

Organisaatiot, jotka eivät ole järjestäneet dokumenttejaan, käyttävät enemmän aikaa valmistelussa kuin putken itsessä, mikä on itse asiassa arvokas tulos. Chatbotin käyttöönottoprosessi pakottaa organisaation yhdistämään ja rakentamaan sen organisaation tietämystä, mikä toimittaa hyötyjä paljon chatbotia pidemmälle. Sama järjestetty tietämyskanta, joka voimauttaa chatbottia, toimittaa myös paremman sisäisen dokumentaation, paremman koulutusmateriaalin uusille työntekijöille, ja paremman perustan millekään muulle tiedon hallinnan aloitteelle joita organisaatio ryhtyy.

Putki myös demystifioi chatbotin käyttöönottoprosessia tekemällä jokaisen vaiheen näkyväksi ja ymmärrettäväksi. Ei ole mustaa laatikkoa missä dokumentit menivät sisään ja chatbotti tulee ulos ilman näkyvyyttä muutokseen. Jokainen vaihe on havaittava, jokainen konfiguraatio on tarkistettava, ja jokainen komponentti voidaan säätää itsenäisesti. Tämä läpinäkyvyys rakentaa luottamusta järjestelmään ja voimauttaa chatbotin ylläpitäjiä tekemään informoituja päätöksiä hienosäädöistä ja laajennuksista ajan kuluessa.