A chatbot alkalmazás hagyományos architektúrája három rétegből áll: egy felhasználói felületből, amellyel a felhasználó interakcióba lép, egy háttérrendszerből, amely kezeli a beszélgetés állapotát és az üzleti logikát, valamint egy mesterséges intelligencia szolgáltatásból, amely válaszokat generál. A mindhárom réteg megépítése jelentős mérnöki projekt. A felhasználói felületnek szükséges egy csevegő felület, amely üzeneteket jelenít meg, bemenetet kezel és valós idejű frissítéseket végez. A háttérrendszernek szükséges a munkaülések kezelése, az üzenettárolás, a beszélgetés szálazása, a sebesség korlátozása és a hitelesítés. A mesterséges intelligencia integrációjához szükséges a prompt-konstruálás, a kontextus kezelése és a válaszok elemzése. Összességében ezek az összetevők heteket vagy hónapokat jelentenek fejlesztési munkában egy olyan csapat számára, amely talán egyszerűbb valami kezdte a projektet.

A ChatBot API teljesen kiküszöbüli a középső réteget. Az API kezeli a munkaülés-kezelést, a beszélgetés állapotát, az üzenetek előzményeit és a mesterséges intelligencia által generált válaszokat, mint egy üzemeltetett szolgáltatást. A fejlesztő csak a felhasználói felületet építi meg, egy csevegő felületet, amely üzeneteket küld az API-nak és megjeleníti a válaszokat. Nincs háttérrendszer a felépítéshez, nincs adatbázis a kezeléshez, nincs munkamenet-infrastruktúra a fenntartáshoz. Az API a háttérrendszer, és kezeli a felhasználó üzenete és a chatbot válasza közötti mindent anélkül, hogy a fejlesztőtől bármilyen szerver oldali kódot igényelne.

Ez az architektúra, amelyet néha "API-first" vagy "backend-as-a-service" néven emlegetnek, elvileg nem új. A fizetési feldolgozó API-k kiküszöbölték a fizetési háttérrendszerek felépítésének szükségességét. Az azonosítási API-k kiküszöbölték az azonosítási háttérrendszerek felépítésének szükségességét. A ChatBot API ugyanazt az elvet alkalmazza a beszélgetési mesterséges intelligenciára: az összetett, állapot-teljes és infrastruktura-nehéz háttérrendszert szolgáltatásként nyújtják, és a fejlesztő kizárólag a felhasználói élményre összpontosít. Az eredmény az, hogy egy fejlesztő, aki képes egy weboldalat készíteni, képes egy chatbotot készíteni, mivel egy weblap készítése az egyetlen szükséges készség.

Munkamenetek és hogyan tartják a beszélgetések a kontextust az üzenetek között

Egy chatbot, amely nem emlékszik rá, mit mondtak három üzenettel ezelőtt, nem beszélgetést folytat. Elszigetelten válaszol kérdésekre, ami alapvetően eltérő és sokkal kevésbé hasznos interakciós minta. Az Q&A bot és a beszélgetési ügynök közötti különbség a kontextus: az előző üzenetek hivatkozásának képessége, az etablálódott információk alapján történő fejlesztés és a koherens szál fenntartása több csere között. Ez a kontextus az, amely természetessé teszi a beszélgetéseket és amely lehetővé teszi az összetett, többlépcsős interakciókat, például hibaelhárítási folyamatokat, irányított konfigurációkat és fokozatos információgyűjtést.

A ChatBot API-ban a munkamenet-rendszer automatikusan biztosítja ezt a kontextust. Amikor egy beszélgetés elkezdődik, az API egy munkamenetet hoz létre, amelyet egy egyedi munkamenet-token azonosít. Minden ezt követő üzenet, amely ezzel a munkamenet-tokennel kerül elküldésre, ugyanannak a beszélgetésnek a része. Az API megőrzi a beszélgetés teljes előzményeit a munkamenetben, és minden új válasz a korábban elmondottak teljes tudatában generálódik. A felhasználó felteheti a kérdést, választ kaphat, felteheti az előző választ hivatkozó nyomon követő kérdést, és kaphat egy koherens választ, amely az etablálódott kontextusra épül anélkül, hogy ismétlés vagy zavar lenne.

A fejlesztő oldali munkamenet-kezeléshez szükséges a munkamenet-token tárolása és továbbítása az API-nak küldött összes híváshoz. A tokent a beszélgetés elkezdelésekor kapja meg, és minden ezt követő üzenetben szerepel. Ez az egyetlen állapot, amelyet a felhasználói felületnek kezelnie kell. A beszélgetés előzményei, a kontextus-ablak, a prompt-készítés és az összes többi állapot-teljes művelet az API oldalán történik. A felhasználói felület feladata arra korlátozódik, hogy tudja, melyik munkamenethez tartozik, ami egy karakterláncként tárolódik a memóriában vagy a böngésző munkamenet-tárhelyében.

A munkamenet-tartósság biztosítja, hogy a beszélgetések túléljék az oldal frissítéseit, a fülváltásokat és még az eszközváltásokat is. Amíg a munkamenet-token megmarad és átadásra kerül a következő üzenettel, a beszélgetés pontosan ott folytatódik, ahol abbahagyta. Egy felhasználó, aki támogatási beszélgetést kezd az asztali gépén, bezárja a böngészőt és órák múlva ismét megnyitja az oldalt, zökkenőmentesen folytathatja a beszélgetést, mivel a munkamenet és teljes előzményei az API oldalán megmaradnak. Ezt a tartósságot az API munkamenet-infrastruktúrája teljes mértékben kezeli, és nem igényel adatbázist vagy tárhely a fejlesztő oldalán.

Visszahívások és válaszok fogadása szavazás nélkül

A chatbot válaszok időt vesznek igénybe. Az mesterséges intelligenciának feldolgoznia kell a beszélgetés kontextusát, le kell kérdnie a releváns tudást, prompt-ot kell készítenie, választ kell generálnia és a kimenetet formáznia. A kérdés összetettségétől és a tudásbázis méretétől függően ez egy-több másodpercig tarthat. Ez idő alatt a felhasználói felületnek tudnia kell, mikor áll a válasz készen, hogy megjeleníthesse azt a felhasználónak.

A legegyszerűbb megközelítés a szinkron kérés-válasz: a felhasználói felület üzenetet küld és vár, amíg a válasz ugyanabban a HTTP-kérésben visszaérkezik. Ez működik, de olyan felhasználói élményt hoz létre, amelyben az interfész befagy a generálás során, progresszió-visszajelzés nélkül és visszavonás vagy átirányítás lehetősége nélkül. Gyors válaszok esetén ez elfogadható. Több másodpercig tartó válaszok esetén a megfagyott interfész felhasználó számára törtnek tűnik.

A visszahívási URL-ek aszinkron alternatívát nyújtanak, amely sokkal jobb felhasználói élményt eredményez. Amikor üzenetet küld az API-nak, a fejlesztő egy visszahívási URL-t tartalmaz, amelyet az API meghív, amikor a válasz készen áll. A felhasználói felület kérése azonnal visszatér egy nyugtázással, lehetővé téve az interfésznek, hogy "gépelés" indikátort vagy egyéb előrehaladás-visszajelzést jelenítsen meg, miközben a válasz a háttérben generálódik. Amikor a válasz készen áll, az API ezt elküldi a visszahívási URL-re, amely a felhasználói felületet elindítja a befejezett üzenet megjelenítésére. A felhasználó természetes beszélgetési ritmusát látja: üzenete megjelenik, rövid gépelési indikátor lejátszódik és a válasz érkezik, mindenféle látható várakozás vagy interfész-megfagyás nélkül.

Azok a fejlesztők, akik tisztán kliens oldali alkalmazásokat építenek (egyoldalas alkalmazások, statikus webhelyek vagy böngészőalapú eszközök), kombinálhatják a visszahívási URL-eket kiszolgáló által küldött eseményekkel vagy WebSocket-kapcsolatokkal, hogy közvetlenül küldjék el a válaszokat a böngészőnek. Az API elküldi a befejezett választ a visszahívási végpontra, amely ezt továbbítja az összekapcsolt böngésző-munkamenethez. Ez a minta minimális szerver oldali összetevőt igényel (csak a visszahívás-vevő és az leküldési mechanizmust), de az API oldalán tartja a teljes beszélgetési logikát és állapotkezelést. A fejlesztő szervere az útválasztást kezeli, nem a gondolkodást.

A visszahívási mechanizmusi támogatja az adatfolyam-válaszokat is, ahol az mesterséges intelligencia kimenete lépcsőzetesen kerül kézbesítésre, ahogy generálódik, ahelyett, hogy egyszerre, amikor befejezés érkezik. Az adatfolyam az a jellegzetes "valós idejű gépelés" hatást hozza létre, amelyre a felhasználók a csevegő felületektől várhatók. Minden token vagy kifejezés úgy érkezik, ahogy generálódik, természetes áramlást hozva létre, amely úgy tűnik, hogy a chatbot gondolkodik és valós időben válaszol ahelyett, hogy eltűnne több másodpercre, majd kiköpne egy teljes választ. Ez az adatfolyam-viselkedés különösen fontos a hosszabb válaszok esetén, ahol a generálás teljes ideje öt vagy több másodperc lehet.

Beszélgetés előzményei és funkciók felépítése tárolt üzenetek felett

Minden üzenet minden munkamenetben tárolódik és az API előzményei végpontjain keresztül érhető el. Ez a tárolt előzmények több célt szolgál a munkameneten belüli beszélgetési kontextus lehetővé tételén túl. Nyersanyagot biztosít az elemzéshez, minőségmonitorozáshoz, edzési adatok gyűjtéséhez és felhasználói élmény funkcióihoz, amelyek értéket adnak a chatbot üzembe helyezéshez.

A beszélgetés előzményein alapuló elemzés feltárja a felhasználói viselkedés és a chatbot teljesítmény mintáit. Mely kérdéseket teszik fel a leggyakrabban? Mely válaszok vezetnek nyomon követő kérdésekhez (jelezve, hogy a kezdeti válasz hiányos volt)? Mely beszélgetések végződnek pozitív megoldással és melyek a felhasználó munkamenetet elhagyásával? Ezek a minták, láthatóak összesítve több száz vagy ezer beszélgetésben, irányítják a tudásbázis és az esetek folyamatos javítását. Beszélgetés előzmények nélkül ez a javítási folyamat anekdotikus visszajelzésekre támaszkodik a szisztematikus elemzés helyett.

A minőség-monitorozás a beszélgetés előzményeit használja arra, hogy azonosítsa azokat az egyes interakciókat, ahol a chatbot teljesítménye az elvárások alatt volt. A felülvizsgáló megolvashatja a megjelölt beszélgetéseket, azonosíthatja az adott tudáshiányt vagy az eset-eltérést, amely a problémát okozta, és céltudatos javításokat végezhet, amelyek megakadályozzák ugyanazt a kudarcot a jövőbeli beszélgetésekben. Ez a céltudatos finomítás sokkal hatékonyabb, mint az általános tudásbázis-bővítés, mivel meghatározott, bemutatott gyengeségekre vonatkozik, nem pedig hipotetikusakra.

A felhasználó-orientált funkciók, amelyeket a beszélgetés előzményein felépítenek, javítják magát a csevegés élményt. Az "utolsó beszélgetések" nézet lehetővé teszi a felhasználók számára, hogy visszatérjenek az előzetes munkamenetekhez és felülvizsgálják a kapott információkat. Az előzmények között való keresési funkció lehetővé teszi a felhasználók számára, hogy megtaláljanak meghatározott információkat anélkül, hogy ismét feltennék ugyanazt a kérdést. Az exportálási funkció lehetővé teszi a felhasználók számára, hogy fontos beszélgetéseket referencia-dokumentumként mentsenek. Ezek a funkciók teljesen az API által biztosított előzmény-adatokból épülnek fel, és nem igényelnek további tárolást vagy adatkezelést a fejlesztő oldalán.

A teljes felhasználói felület és hogyan néz ki egy chatbot-felület háttér nélkül

A ChatBot API-ján felépített teljes chatbot felhasználói felület üzenet-megjelenítési terület, szöveg-bevitel, küldés-gomb és JavaScript (vagy azzal egyenértékű kliens oldali kód) elemeiből áll, amely ezeket az felületelem-elemeket az API végpontokhoz csatlakoztatja. Az üzenet-megjelenítési terület a beszélgetés előzményeit felhasználó és robot üzenetek közötti váltakozásként jeleníti meg. A szöveg-bevitel rögzíti a felhasználó üzenetét. A küldés-gomb elindítja az API-hívást, amely elküldi az üzenetet és elindítja a válaszgenerálást. Amikor a válasz megérkezik (szinkronban vagy visszahíváson keresztül), hozzáadódik az üzenet-megjelenítési területhez, és a felhasználói felület készen áll a következő cseréhez.

Ennek a felhasználói felületnek a stílusa, elrendezése és interakció-tervezése teljes mértékben a fejlesztő kontrollja alatt van. Az API nem szab korlátozásokat a csevegő felület vizuális bemutatására. Lehet teljes oldalas csevegés alkalmazás, oldalsó panel, lebegő widgett, modális párbeszédpanel vagy bármely más UI-minta, amely megfelel az alkalmazás tervezésének. Az API biztosítja a beszélgetési motort; a fejlesztő biztosítja az arcot. Ez az elválasztás azt jelenti, hogy a chatbot megjelenése csak a fejlesztő tervezési készségei által korlátozott, nem pedig az előre elkészített widgett-keretrendszer korlátainak.

Azok a fejlesztők, akik nem szeretnének egyéni felhasználói felületet felépíteni, az API munkamenet és üzenet formátumait nyílt forráskódú csevegő felület-összetevőkkel kompatibilis, amelyek minimális módosítással adaptálhatók. A React, Vue és vanilla JavaScript csevegés-komponensek elérhetők nyilvános tárolóhelyekben, és a ChatBot API-hoz való csatlakoztatásuk megköveteli az alapértelmezett üzenetkezelésüket API-hívásokkal való helyettesítését. A hitelesítés a beépülő modul titkát használja, az üzenetek a munkamenet-tokent használják, és a megjelenítés a kiválasztott komponens által nyújtott renderelési logikát használja. Az adaptáció általában kevesebb, mint egy óra a komponens-keretrendszert ismerő fejlesztőtől.

A háttér hiánya ebben az architektúrában a leglényegesebb gyakorlati előnye. Nincs szerver, amelyet el kell végezni, nincs adatbázis, amelyet kezelni kell, nincs munkamenet-tár, amelyet fenntartani kell, nincs skálázási infrastruktúra, amelyet konfigurálni kell. Az API kezeli az összes szerver oldali problémát, és a felhasználói felület a felhasználó böngészőjében futnak. Ez azt jelenti, hogy a chatbot statikus üzemeltetési platformon, GitHub Pages oldalon, Netlify üzembe helyezésen vagy bármely más üzemeltetési környezetben helyezhető üzembe, amely HTML és JavaScript szolgáltat. Az operatív terhelés nulla, amely fenntartható a chatbotot még a dedikált infrastruktúra-költségvetés vagy operatív csapat nélküli projektek számára is.

Gyakran ismételt kérdések

Meddig maradnak meg a munkamenetek lejárat előtt

A munkamenetek konfigurálható ideig maradnak aktívak, amely alapértelmezésben huszonegy év inaktivitást jelent. Az ebben az ablakban üzenetet kapó munkamenetnek lejárati időzítője alaphelyzetbe kerül, így az aktív beszélgetések határozatlan időre megmaradnak. A lejárt munkamenetek és azok előzményei az API előzményein keresztül hozzáférhetők maradnak, de nem kaphatnak új üzeneteket.

Törölhető-e a beszélgetés előzményei az adatvédelem biztosítása miatt

Igen. A beszélgetés előzményei az API-n keresztül munkamenetenként vagy felhasználóként törölhetők. Ez támogatja az olyan adatvédelmi rendelkezéseknek való megfelelést, mint a GDPR, amely a felhasználókat arra jogosítja fel, hogy kérvényt nyújtsanak az adataik törlésérőt. A törlés végleges és eltávolítja az összes megjelölt munkamenetekhez kapcsolódó üzenetet és metaadatot.

Mi történik, ha a visszahívási URL nem elérhető, amikor a válasz készen áll

Az API exponenciális visszaöltésssel kísérli meg újra a visszahívás-kézbesítést a konfigurálható számú próbálkozásokig. Ha az összes próbálkozás sikertelen, a válasz továbbra is az előzmények végpontján keresztül elérhető, így a felhasználói felület szavazhat a kimarad válaszokra alapértelmezett megoldásként. Ez az újrapróbálkozási mechanizmusi biztosítja, hogy a hálózati átmeneti problémák ne vezessenek az elveszett válaszokhoz.

Van-e sebesség korlátozás az üzenetek szerint munkameneten

A sebesség korlátozások a számla szintjén, nem a munkamenet szintjén kerülnek alkalmazásra, ami megelőzi a visszaélést, miközben lehetővé teszi a jogos nagy mennyiségű felhasználást. Az alapértelmezett sebesség korlátozás elég nagylelkű a normál beszélgetési interakciók számára. A szokatlanul magas üzenetmennyiségre számító számlák az API-kezelőfelület segítségével kérheti a korlátozások kiigazítását.

Felismerheti-e a felhasználói felület, ha a chatbot nem ismeri a választ

Az API-válasz metaadatokat tartalmaz, amelyek jelzik a válasz magabiztosságát és azt, hogy releváns tudás található-e a tudásbázisban. A felhasználói felület ezeket a metaadatokat arra használhatja, hogy beállítsa bemutatatásit, például felelősség-nyilatkozat megjelenítésével, ha az bizalom alacsony, vagy javaslat a felhasználónak az emberi támogatás megkeresésére, ha a tudásbázis nem tartalmaz a lekérdezéshez releváns információt.

Támogatja-e az API gazdag üzenet formátumokat, mint képek vagy gombok

Az API strukturált válasz formátumokat támogat, amelyek szöveget, javasolt nyomon követő kérdéseket és cselekvési linkeket tartalmaznak. A felhasználói felület ezeket a strukturált elemeket értelmezi és saját tervezési szokásai szerint jeleníti meg őket. Ez gazdag interaktív élményt tesz lehetővé, mint például kattintható javaslatok, beágyazott linkek és formázott tartalom anélkül, hogy az API-t meg kellene értenem a felhasználói felület konkrét megjelenítési képességeit.