Ismeret feltöltése, majd használati esetek javasása, majd az SQL jóváhagyása és telepítése – a teljes chatbot munkafolyamat

Az "adjunk hozzá egy chatbotot" és az "a chatbot él és kezeli a beszélgetéseket" közötti távolság általában hetekben vagy hónapokban mérhető. Megírják a követelményeket. Értékelnek szállítókat. Integrációs értekezleteket ütemeznek. Pilot programokat javasolnak. Amikor a chatbot végre elindul, az eredeti sürgősség, amely motiválta a projektét, gyakran elmosódott a szervezeti háttérbe, helyét átvette az az újabb prioritás, amely elnyelte a figyelmet és költségvetést, amelyre a chatbot projektnek szüksége volt a befejezéshez. A megvalósítási idővonal az a sír, ahol a jó chatbot szándékok meghalnak.

A ChatBot API a telepítést egy lineáris folyamatú megoldásként strukturálja, amely világos, különálló lépésekből áll. Minden lépésnek van egy definiált bemenete, egy definiált kimenete, és egy világos átmenet a következő lépésbe. Nincs félreérthetőség azzal kapcsolatban, hogy mi kell történjen az egyes szakaszokban, nincsenek körkörös függőségek, amelyek korábbi döntések felülvizsgálatát igényelik, és nincsenek olyan építészeti döntések, amelyek mély technikai szakértelmét igényelik. A folyamat egy irányban mozog, a nyers ismeretekből az élő chatbotig, és minden lépés perceket vesz igénybe, nem napokat.

A folyamat részletes megértése értékes nemcsak a megvalósítás, hanem a reális elvárások felállítása szempontjából is, hogy milyen hozzájárulást ad az egyes szakaszok a végeredményhez. A chatbot minősége attól függ, hogy mi történik az egyes szakaszokban, és az, hogy hol fektet be többletfigyelmet szemben azzal, ahol az alapértelmezések elegendőek, jobb eredmények adódnak rövidebb idő alatt, mint a teljes folyamatot olyan fekete dobozként kezelni, amely vagy működik, vagy nem.

Az első lépés – az ismeret feltöltése, amely meghatározza, mit tud a chatbot

A folyamat az ismeret feltöltésével kezdődik. Ez az alapvető lépés, mert minden, ami következik, az ismeretalap minőségétől és teljességétől függ. Az ebben a szakaszban feltöltött dokumentumok az chatbot teljes megértésévé válnak az üzletről, annak termékeiről, politikáiról és eljárásairól. Bármi, amely nincs képviselve a feltöltött dokumentumokban, a chatbot perspektívájából ismeretlen terület, amelyet vagy a tudatlanság elismerésével, vagy az általános tudásra való visszaesésre kezel, amely lehet, hogy nem pontos az adott üzletre nézve.

A feltöltési folyamat szabványos formátumban elfogadja a dokumentumokat, és egy feldolgozási folyamaton keresztül dolgozza fel őket, amely automatikusan több műveletet végez. A szöveg kivonatot készítik a dokumentum formátumából, megőrizve a szerkezeti elemeket, például a fejléceket, szakaszokat és listákat, miközben elvetik az olyan formázást, amely semmilyen szemantikai értéket nem hordoz. A kinyert szöveget ezután olyan szegmensekre darabolják, amelyek elég kicsik ahhoz, hogy egyénileg visszakereshetőek legyenek, de elég nagyok ahhoz, hogy megőrizzék az egyes szegmenseken belüli kontextust. Ezeket az adattömbeket egy olyan vektortérbe ágyazzák, amely szemantikai keresést tesz lehetővé, vagyis a chatbot olyan információt találhat, amely a jelentésre és nem az exakt kulcsszó-egyezésre alapul.

Ez a feldolgozás a feltöltés után a háttérben történik, és általában észszerű méretű dokumentumkészletekhez néhány percen belül befejeződik. A feldolgozás során a rendszer elemzi a tartalmat, hogy megértse annak tematikus szerkezetét, amely a folyamat következő lépéseihez vezet. A felhasználónak nem kell megértenie a vektoros beágyazásokat vagy a szemantikai keresést, hogy ezekből haszna legyen. Azt kell megérteniük, hogy a feltöltött dokumentumok a chatbot tudásává válnak, és hogy a teljesebb, világosabban megírt dokumentumok egy képesebb chatbotot produkálnak.

A gyakorlati megközelítés az ismeret feltöltésénél azt az irányultságot követi, hogy olyan dokumentumokat priorizáljon, amelyek az olyan leggyakoribb interakciókat kezelik, amelyeket a chatbot kezelni fog. Ha az elsődleges célja az ügyfélszolgálat, akkor az GYIK dokumentum, a hibaelhárítási útmutató és a termék kézikönyve a legmagasabb prioritású feltöltések. Ha az elsődleges célja az értékesítés kvalifikálása, akkor a termékkomplex útmutatók, az árképzési dokumentáció és az ideális ügyfélprofil-leírások a legfontosabbak. A legmagasabb hatású dokumentumokkal való kezdés és a másodlagos anyagok későbbi hozzáadása lehetővé teszi, hogy a chatbot azonnal kezelje a leggyakoribb forgatókönyveket, miközben az ismeretalap továbbra is bővül.

A második lépés – használati esetek javaslata a feltöltött ismeret alapján

Az ismeretalap feldolgozása után a rendszer elemzi a tartalmat, hogy javaslatot tegyen a felhasználati esetekre, amelyeket a chatbot ésszerűen kezelhetne az elérhető információ alapján. Ez a javaslatási lépés az egyik legértékesebb része a folyamatnak, mert áthidalja az "itt vannak a dokumentumaink" és az "itt van, mit kell tennie a chatbotnak" közötti szakadékot, amely szakadék számos chatbot megvalósítása szorong átlépni, anélkül, hogy kiterjedt tervezett üléseket tartana.

A javaslatokat a feltöltött dokumentumok tematikus lefedettségének vizsgálatával és ennek a lefedettségnek a közös chatbot interakciós mintákhoz való leképezésével hozzák létre. Ha az ismeretalap terméktartalmú dokumentumokat tartalmaz, a rendszer egy termékinformációs felhasználási esetet javasol. Ha hibaelhárítási útmutatókat tartalmaz, egy technikai támogatási felhasználási esetet javasol. Ha árképzési információt tartalmaz, egy árképzési lekérdezési felhasználási esetet javasol. Minden javaslattal együtt jár annak a forgatókönyvnek a leírása, amelyet lefed, azok a kérdések, amelyeket a felhasználók feltehetnek, és az erre a forgatókönyvre reagáló chatbot várható viselkedése.

Ezek a javaslatok kiindulópontok, nem végleges konfigurációk. A felhasználó felülvizsgálja az egyes javaslatokat, és vagy így fogadja el, vagy módosítja, hogy jobban illeszkedjenek az ő konkrét igényeihez, vagy elutasítja, ha a forgatókönyv nem lényeges. Az extra felhasználási esetek manuálisan definiálhatók az olyan forgatókönyvekhez, amelyeket az automatizált analízis nem azonosított, például a speciális munkafolyamatok vagy olyan peremterületek, amelyek fontosak az üzlet számára, de nem jól reprezentáltak a szabványos dokumentummintákban. Az automatizált javaslat és a manuális finomítás kombinációja olyan felhasználási esetek halmazát hozza létre, amely egyaránt átfogó és az üzlet tényleges igényeihez igazított.

Az automatizált felhasználási esetek javaslatának gyakorlati előnye, hogy kiküszöböli azt a "üres vászon" problémát, amely sok chatbot megvalósítást megtorpanít. Ahelyett, hogy azzal a kérdéssel kezdenénk, hogy "mit kell tennie a chatbotnak?" és megpróbálnánk minden lehetséges forgatókönyvet nulláról felsorolni, a csapat egy olyan kurált javaslatlistával kezd, amely az általuk biztosított tényleges tartalomhoz kötött. Ez egy alapvetően könnyebb kiindulópont, amely felgyorsítja a döntéshozatali folyamatot, és csökkenti az olyan fontos forgatókönyvek figyelmen kívül hagyásának kockázatát, amelyeket a dokumentumok egyértelműen támogatnak.

A harmadik lépés – SQL jóváhagyása és bővítmény titkos kód generálása

A chatbot működésének támogatásához szükséges technikai infrastruktúra adatbázis-struktúrákat igényel a beszélgetések, munkamenet-állapot, felhasználói interakciók és ismeretlekérdezési naplók tárolásához. A folyamat az SQL sémát a jóváhagyott felhasználási esetek alapján hozza létre, és a végrehajtás előtt felülvizsgálatra terjeszti azt. Ez a jóváhagyási lépés azért létezik, hogy biztosítsa az átláthatóságot: a felhasználó pontosan azt látja, milyen adatbázis-struktúrák jönnek létre, mielőtt azok létre lennének hozva, fenntartva az adatok teljes láthatóságát a chatbot telepítésének technikai lábnyomában.

A technikai háttérrel rendelkező felhasználók számára az SQL-felülvizsgálat lehetőséget nyújt arra, hogy ellenőrizzék, az infrastruktúraigények, elnevezési konvenciók és adatkezelési politikák összhangba vannak-e az sémával. A nem technikai felhasználók számára a felülvizsgálati lépés elsősorban egy megerősítési kapuként szolgál, amely biztosítja, hogy a folyamat ne módosítsa az adatbázis-struktúrákat kifejezett jóváhagyás nélkül. Mindkét esetben a jóváhagyás egyetlen cselekmény: vizsgálja felül a generált sémát, erősítse meg, hogy az elfogadható, és folytatódjon. A séma saját struktúrájú, új táblákat és indexeket hoz létre anélkül, hogy módosítaná az adatbázis meglévő struktúráit.

Az SQL-jóváhagyást követően a rendszer egy bővítmény titkos kódot hoz létre, amely a chatbot API-interakcióinak hitelesítési azonosítójaként szolgál. Ezt a titkos kódot a bővítmény szerkezete (egy webhelyi widget, egy mobil alkalmazás komponense vagy egy egyéni felület) használja a chatbot háttér-rendszerrel való hitelesítéshez és az engedélyezett beszélgetési munkamenetek létrehozásához. A titkos kód generálása automatikus, és betartja az olyan biztonsági ajánlott eljárásokat, mint az elég nagy entrópia és a biztonságos tárolás. A felhasználó átmásolja a titkos kódot, és tárja az alkalmazásuk konfigurációjában, befejezve a hitelesítés beállítását.

Az SQL-jóváhagyás és a titkos kód generálásának kombinációja az konfigurációból a telepítéskészültségre való átmenetet reprezentálja. Ezek a lépések előtt a chatbot olyan konfigurációként létezik: ismeretalap, felhasználási esetek és viselkedési paraméterek. Ezek után ez egy olyan telepíthető szolgáltatásként létezik, amelynek van az adatbázis-infrastruktúrája a beszélgetések megőrzésére és az a hitelesítési mechanizmusa a hozzáférés védelmére. A folyamat az absztrakt meghatározásból a konkrét megvalósításba helyezte át, és az utolsó lépés az elülső rész összekapcsolása.

A negyedik lépés – telepítés és az első élő beszélgetések

Az telepítés csatlakoztatja a chatbotot a felhasználóval való felületéhez. Az adott integrációs mechanizmus attól függ, hol fog élni a chatbot: egy weboldali csevegés widget, egy mobil alkalmazás képernyő, egy Slack-integráció, egy egyéni irányítópult, vagy bármilyen más felület, amely képes HTTP-kéréseket küldeni az API-nak. A chatbot API végpontokat biztosít a munkamenetek indítására, üzenetek küldésére, válaszok fogadására és a beszélgetési történet lekérésére. Bármely olyan elülső, amely képes meghívni ezeket a végpontokat, lehet a chatbot otthona.

A weboldali telepítéshez a leggyakoribb minta egy csevegési widget, amely megjelenik a meghatározott oldalakon vagy az egész weboldal felett. A widget kezeli a beszélgetés vizuális megjelenítését, a felhasználó üzeneteinek beviteli mezőjét és a chatbot válaszainak megjelenítését. A chatbot API-val kommunikál a bővítmény titkos kódjával a hitelesítéshez és egy munkamenet-azonosítóval a beszélgetés folytonosságához. A widget a nulláról felépíthető az API dokumentáció használatával, vagy az előre elkészített widget sablonok adaptálhatók, hogy illeszkedjenek a webhely vizuális tervéhez.

Az első élő beszélgetések egyrészt az ezüst kő és egyrészt a teljes folyamat legkölcsönösebb szórakoztató részei. A valódi felhasználók olyan kérdéseket tesznek fel, amelyeket egyetlen tervezett ülés sem várt. Úgy fogalmaznak dolgokat, amelyeket egyetlen felhasználási esetek meghatározása sem jósolt meg. Azt várják az információt, amely az ismeretalapból majdnem, de nem teljesen van jelen. Ezen interakciók mindegyike egy tanulási lehetőség, amely visszatáplálódik az ismeretalap és az előző folyamatmeghatározásban említett felhasználási esetek finomításaiba. A folyamat ebben az értelemben nem tisztán lineáris. Az elsődleges telepítés során lineáris, és az üzemeltetés során ciklikus lesz, az élő beszélgetés adatai vezérlik az ismeretalap és a felhasználási esetek meghatározásainak folyamatos javítását.

Az API által biztosított beszélgetési történet és elemzések nyújt a chatbot fenntartójának láthatóságot arra vonatkozóan, hogy mely kérdéseket kérdezik leggyakrabban, mely válaszok elégedik meg a felhasználókat, és hol szorong rá a chatbot. Ezek az adatok átalakítják a chatbotot egy statikus telepítésből egy dinamikus rendszerré, amely az adatok felhasználásával javul. Az kezdeti tizenötperces beállítás beindítja a chatbotot. A folyamatos finomítás, az élő beszélgetés adatai alapján, a következő hetekben és hónapokban fokozatosan értékesebbé teszi azt.

A teljes folyamat az összefüggésben

Az elejétől a végéig megtekintve a folyamat átalakítja az üzleti dokumentumokat egy élő beszélgetési mesterséges intelligenciává négy különálló lépésben: ismeret feltöltése, felhasználási esetek meghatározása, infrastruktúra jóváhagyása és telepítés. Mindegyik lépésnek világos bemenetei és kimenetei vannak. Mindegyik lépés az előzőre épül. És mindegyik lépés percekben el lehet végezni, nem napokban, ez az oka annak, hogy az olyan szervezetek számára, amelyek olyan dokumentumokkal érkeznek az eljárásra, amelyek már szervezve és a beszélgetési célok már ismertek, a tizenötperces telepítési idővonal elérhető.

Azok a szervezetek, amelyeknek nincsenek szervezett dokumentumaik, többet fognak tölteni az előkészítésre, mint a folyamatra magára, amely valójában egy értékes eredmény. A chatbot telepítési folyamat arra kényszeríti a szervezetet, hogy konszolidálja és strukturálja az intézményi tudást, amely olyan előnyöket biztosít, amelyek messze túlmutatnak a chatboton. Ugyanaz a szervezett ismeretalap, amely a chatbotot működteti, belső dokumentációként, új alkalmazottak képzési anyagaként és az egyéb tudáskezelési kezdeményezések jobb alapjaként szolgál.

A folyamat azt is megmagyarázza a chatbot telepítési folyamatát azzal, hogy minden lépést láthatóvá és érthetővé tesz. Nincsen fekete doboz, ahol dokumentumok mennek be, és egy chatbot jön ki anélkül, hogy láthatóság lenne az átalakítódásról. Minden lépés megfigyelhető, minden konfiguráció felülvizsgálható, és minden összetevő egymástól függetlenül állítható. Ez az átláthatóság növeli az önbizalmat a rendszerrel és feljogosítja a chatbot karbantartóit arra, hogy tájékozott döntéseket hozzanak az időben végzett finomításokról és bővítésekről.

Gyakran Ismételt Kérdések

A folyamat újraindítható, ha hiba történik egy korábbi lépésben

Igen. Mindegyik lépés egymástól függetlenül meglátogatható. Az ismeret dokumentumok bármikor hozzáadhatók vagy helyettesíthetők. A felhasználási esetek módosíthatók, hozzáadhatók vagy eltávolíthatók az ismeretalap befolyásolása nélkül. Az SQL séma újragenel

hető, ha szerkezeti változások szükségesek. A folyamat iteratív finomítás helyett egy olyan tökéletes első próbálkozást igényel.

Mennyi idő vesz igénybe az ismeret feldolgozási lépése

A feldolgozási idő a feltöltött dokumentumok térfogatától függ. Egy olyan tipikus öt-tíz dokumentumokból álló készlet, amely ötven oldalt tesz ki, öt percnél kevesebb alatt feldolgozódik. A nagyobb dokumentumkészleteknek arányosan hosszabb időre van szükségük. A feldolgozás a háttérben történik, és a felhasználó értesítést kap, amikor az befejeződik, és az ismeretalap az esetek meghatározásához kész.

Mi történik, ha a felhasználási esetek javaslatai nem felelnek meg a szándékolt chatbot célnak

A javaslatok olyan opscionális kiindulópontok. Az összes javaslat elutasítható és helyettesíthető a szándékolt céllal pontosan illeszkedő manuálisan definiált felhasználási esetekkel. A javaslatási rendszer a legjobban akkor működik, ha a feltöltött dokumentumok egyértelműen a chatbot szándékolt szerepéhez kapcsolódnak, és kevésbé hatékony, amikor a dokumentumok tangenciálisak az elsődleges felhasználási esetre.

Az SQL séma kompatibilis-e bármilyen adatbázis-rendszerrel

A generált SQL az API-fiók konfigurációjához csatolt adatbázis-rendszert célozza. A szabványos relációs adatbázis-rendszerek támogatottak, és a séma széles körben kompatibilis SQL szintaxist használ az hordozhatóság biztosítására. Az adott adatbázis-követelményekkel rendelkező felhasználók felülvizsgálhatják a generált sémát, és jóváhagyás előtt módosításokat kérhetnek.

A bővítmény titkos kódja biztonsági okokból rotálható-e

Igen. A bővítmény titkos kódjai bármikor újragenerálhatók az API-kezelési felületen keresztül. Az egy titkos kód újragenerálása azonnal érvényteleníti az előzőt, ami azt jelenti, hogy az elülső integrációt az új titkos kóddal kell frissíteni. Ez a rotációs képesség támogatja az olyan biztonsági ajánlott eljárásokat, mint az időszakos hitelesítési adatok változtatása és a gyanított titkos kód sérülésre való azonnali reagálása.

Hány beszélgetést tud a chatbot egyszerre kezelni

Az API úgy van kialakítva, hogy kezelje az egyidejű beszélgetéseket teljesítményi romlás nélkül. Mindegyik beszélgetés a saját munkamenet-kontextusában működik, és az alapul szolgáló infrastruktúra skálázódik a forgalmi csúcsok befogadásához. Az egyidejű beszélgetések számára nincsen gyakorlati korlát a szabványos API-felhasználáshoz, bár nagyon magas kötetek koordinációt igényelhetnek a támogatással, hogy az infrastruktúra elosztása megfeleljen az igénynek.