Tradicionalna arhitektura aplikacije chatbota se sastoji od tri sloja: frontenda sa kojim korisnik stupi u interakciju, backenda koji upravlja stanjem razgovora i poslovnom logikom, i AI servisa koji generiše odgovore. Pravljenje svih triju slojeva je velik inženjerski projekat. Frontend treba imati interfejs za ćaskanje sa renderovanjem poruka, rukovanjem ulaza i ažuriranjima u realnom vremenu. Backend treba da ima upravljanje sesijama, skladištenje poruka, niti razgovora, limitiranje brzine i autentifikaciju. AI integracija treba da ima izgradnju upita, upravljanje kontekstom i analizu odgovora. Zajedno, ove komponente predstavljaju sedmice ili mesece razvoja za tim koji može biti počeo projekat očekujući nešto jednostavnije.

ChatBot API potpuno eliminira srednji sloj. API upravlja upravljanjem sesijama, stanjem razgovora, istorijom poruka i generisanjem odgovora AI-a kao hostovani servis. Programer gradi samo frontend, interfejs za ćaskanje koji šalje poruke API-ju i prikazuje odgovore. Nema backenda za pravljenje, nema baze podataka za upravljanje, nema infrastrukture sesija za održavanje. API je backend, i upravlja sve između korisnikove poruke i odgovora chatbota bez zahtevanja bilo kakvog koda na strani servera od strane programera.

Ova arhitektura, ponekad nazvana "API-first" ili "backend-as-a-service", nije nova u principu. API-ji za obradu plaćanja su eliminisali potrebu za pravljenjem backend-a za plaćanja. API-ji za autentifikaciju su eliminisali potrebu za pravljenjem backend-a za autentifikaciju. ChatBot API primenjuje isti princip na konverzacijski AI: kompleksan, stateful i infrastrukturno-težak backend se pruža kao servis, a programer se fokusira isključivo na korisničko iskustvo. Rezultat je da programer koji može da napravi veb stranicu može da napravi chatbot, jer je pravljenje veb stranice jedina potrebna veština.

Sesije i kako razgovori održavaju kontekst preko poruka

Chatbot koji se ne može sjetiti šta je rečeno prije tri poruke nije vodio razgovor. Odgovara na izdvojene pitanja, što je fundamentalno drugačiji i mnogo manje koristan obrazac interakcije. Razlika između bot za pitanja i odgovore i konverzacijskog agenta je kontekst: sposobnost da se referencira na prethodne poruke, gradi se na uspostavljenim informacijama i održava koherentan tok preko više razmena. Ovaj kontekst je ono što čini razgovore prirodnim i što omogućava složene viši interakcije kao što su tokovi otklanjanja greške, vodjeni konfiguracije i progresivni prikupljanje informacija.

Sistem sesija u ChatBot API-ju pruža ovaj kontekst automatski. Kada se razgovor počinja, API kreira sesiju identifikovanu jedinstvenim žetonom sesije. Svaka naredna poruka poslata sa tim žetonom sesije se tretira kao deo iste razgovora. API održava celu istoriju razgovora u sesiji, i svaki novi odgovor se generiše sa svešću o svemu što je bilo rečeno pre. Korisnik može postaviti pitanje, dobiti odgovor, postaviti nastavno pitanje koje se referencira na prethodni odgovor i dobiti koherentan odgovor koji se gradi na uspostavljenom kontekstu bez ponavljanja ili zbunjenosti.

Upravljanje sesijama na strani programera zahteva čuvanje i prosleđivanje žetona sesije sa svakim API pozivom. Žeton se prima kada se razgovor počni i uključuje se u sve naredne poruke. Ovo je jedino stanje koje frontend treba da upravlja. Istorija razgovora, prozor konteksta, izgradnja upita i sve druge stateful operacije se dešavaju na strani API-ja. Odgovornost frontenда je ograničena na znanje kojoj sesiji pripada, što je jedan string vrednost skladištena u memoriji ili u memoriji sesije pregledača.

Izdržljivost sesije osigurava da razgovori prežive osvežavanja stranice, izmene tabela i čak izmene uređaja. Dok se žeton sesije čuva i prosleđuje sa sledećom porukom, razgovor nastavlja tačno gde je ostao. Korisnik koji počne razgovor o podršci na svom radnom stolu, zatvori pregledač i ponovo otvori stranicu sati kasnije može nesmetano nastaviti razgovor jer sesija i njena puna istorija ostaju na strani API-ja. Ova trajnost se u potpunosti upravlja infrastrukturom sesije API-ja, ne zahtevajući bazu podataka ili skladištenje na strani programera.

Povratni pozivi i primanje odgovora bez istraživanja

Odgovori chatbota traju vrijeme za generisanje. AI mora obraditi kontekst razgovora, preuzeti relevantan znanje, sagraditi upit, generisati odgovor i formatirati output. U zavisnosti od složenosti pitanja i veličine baze znanja, ovo može potrajati od jedne do nekoliko sekundi. Tokom ovoga vremena, frontend treba znati kada je odgovor spreman da bi ga mogao prikazati korisniku.

Najjednostavniji pristup je sinhron zahtev-odgovor: frontend šalje poruku i čeka odgovor da se vrati u istom HTTP zahtjevu. Ovo funkcioniše ali stvara korisničko iskustvo gde se interfejs zamrzava tokom generisanja, bez indikacije napretka i bez mogućnosti otkazivanja ili preusmeravanja. Za brze odgovore, ovo je prihvatljivo. Za odgovore koji traju nekoliko sekundi, zamrznutog interfeja izgleda slomljen korisniku.

Povratni URL-ovi pružaju asincroni alternativu koja proizvodi mnogo bolje korisničko iskustvo. Kada šalje poruku API-ju, programer uključuje povratni URL koji će API pozvati kada je odgovor spreman. Zahtev frontenда se vraća odmah sa potvrdom, dozvoljavajući interfejsu da prikaže "pisanje" indikator ili drugi napredak povratne informacije dok se odgovor generiše u pozadini. Kada je odgovor spreman, API ga šalje na povratni URL, što pokrenuje interfejs da prikaže završenu poruku. Korisnik vidi prirodan razgovorni ritam: njihova poruka se pojavljuje, kraća pisanja indikator se reprodukuje i odgovor stigne, sve bez vidnog čekanja ili zamrzavanja interfeja.

Za programere koji prave čisto klijentske aplikacije (aplikacije sa jednom stranicom, statične sajtove ili alatke zasnovane na pregledaču), povratni URL-ovi se mogu kombinovati sa serverskim događajima ili WebSocket vezama da šalju odgovore direktno pregledaču. API šalje završenu odgovor na povratnu krajnju tačku, koja je potom gura na povezanu sesiju pregledača. Ovaj obrazac zahteva minimalnu komponentu na strani servera (samo povratna prijemnika i potisni mehanizam) ali čuva svu razgovornu logiku i upravljanja stanjem na strani API-ja. Serverski programer upravlja rutom, ne razmišljanjem.

Mehanizam povratnog poziva podržava i odgovore sa streaming-om, gde se AI izlaz isporučuje postepeno kako se generiše umesto sve odjednom kada je završeno. Streaming proizvodi karakteristični "pisanja u realnom vremenu" efekta koji su korisnici naučili da očekuju od interfejsa za ćaskanje. Svaki token ili fraza stigne kako se generiše, stvarajući prirodan tok koji se čini da chatbot misli i odgovara u realnom vremenu umesto da nestane nekoliko sekundi a onda izbaci potpun odgovor. Ovo ponašanje streaming-a je posebno važno za duže odgovore gde je ukupno vrijeme generisanja može biti pet ili više sekundi.

Istorija razgovora i pravljenje mogućnosti na skladištenim porukama

Svaka poruka u svakoj sesiji se skladišti i dostupna je kroz krajnje tačke istorije API-ja. Ova skladištena istorija služi višestruke svrhe izvan omogućavanja razgovornog konteksta u sesiji. Ona pruža sirovu materijal za analizu, nadzor kvaliteta, prikupljanje podataka o obučavanju i mogućnosti korisničkog iskustva koje dodaju vrednost ChatBot implementaciji.

Analiza zasnovana na istoriji razgovora otkriva obrasce u ponašanju korisnika i performansama chatbota. Koja pitanja se postavljaju najčešće? Koji odgovori vode do nastavnih pitanja (što ukazuje da je početni odgovor bio nedovoljan)? Koji razgovori se završavaju sa pozitivnom rezolucijom i koji završavaju sa korisnikom napuštajućim sesiju? Ovi obraci, vidljivi u zbiru tokom stotina ili hiljada razgovora, vodjani su neprekidnog poboljšanja baze znanja i definicija slučaja upotrebe. Bez istorije razgovora, ovaj proces poboljšanja se oslanja na anegdotske povratne informacije umesto sistemske analize.

Nadzor kvaliteta koristi istoriju razgovora da identifikuje specifične interakcije gdje je performansa chatbota bila ispod očekivanja. Pregledač može čitati označene razgovore, identifikovati specifičnu prazninu znanja ili pogrešno poklapanje slučaja koji je izazvao problem, i praviti ciljana poboljšanja koja sprečavaju istu neuspeh u budućim razgovorima. Ovo ciljano usavršavanje je mnogo efikasnije od opšte ekspanzije baze znanja jer se bavi specifičnim, demonstriranim slabostima umesto hipotetičkim.

Mogućnosti orijentisane korisnicima izgrađene na istoriji razgovora poboljšavaju samo čet iskustvo. Pregled "nedavnih razgovora" omogućava korisnicima da se vrate na prethodne sesije i pregledaju informacije koje su primili. Funkcija pretraživanja kroz istoriju razgovora omogućava korisnicima da pronađu specifične informacije bez postavljanja istog pitanja ponovo. Funkcija izvoza omogućava korisnicima da sačuvaju važne razgovore kao referentne dokumente. Svaka od ovih mogućnosti je izgrađena čisto iz istorijskih podataka koje pruža API, ne zahtevajući dodatno skladištenje ili upravljanje podacima na strani programera.

Kompletan frontend i kako izgleda interfejs ćaskanja bez pozadine

Kompletan interfejs chatbota izgrađen na ChatBot API-ju se sastoji od područja prikaza poruke, tekstualni ulaz, dugme slanja i JavaScript-a (ili ekvivalentnog koda na strani klijenta) koji povezuje ove elemente interfeja sa API krajnjim tačkama. Područje prikaza poruka prikazuje istoriju razgovora kao naizmeničnih poruka korisnika i bota. Tekstualni ulaz hvatanja korisnikovu poruku. Dugme slanja pokreće API poziv koji šalje poruku i započinje generisanje odgovora. Kada odgovor stigne (bilo sinhron ili kroz povratni poziv), dodaće se oblasti prikaza poruka i interfejs je spreman za sledeću razmenu.

Stil, raspored i dizajn interakcije ovog frontenда su potpuno pod kontrolom programera. API ne nameće nikakva ograničenja na vizuelnu prezentaciju interfejsa ćaskanja. Može biti aplikacija za ćaskanje sa punom stranicom, bočni panel, plutajući vidžet, modalni dijalog ili bilo koji drugi UI obrazac koji se uklanja sa dizajnom aplikacije. API pruža razgovorna mehanika; programer pruža lice. Ovo razdvajanje znači da je izgled chatbota ograničen samo na veštine dizajna programera, a ne na ograničenja unapred izgrađenog okvira vidžeta.

Za programere koji preferiraju da ne prave prilagođeni interfejs, formati sesije i poruke API-ja su kompatibilni sa otvorenim komponentama interfejsa ćaskanja koji se mogu prilagoditi sa minimalnim izmenama. React, Vue i vanilla JavaScript komponente ćaskanja su dostupne u javnim skladištima, a povezivanje sa ChatBot API-jem zahteva zamenu njihovog zadanog rukovanjem porukama sa API pozivima. Autentifikacija koristi tajnu priključka, poruke koriste žeton sesije i prikaz koristi bilo koju logiku renderiranja koju pruža izabrana komponenta. Prilagođavanje obično traje manje od sata za programera poznatog sa okvirom komponente.

Odsustvo pozadine u ovoj arhitekturi je njegova najpraktičnija prednost. Nema servera za opremanje, nema baze podataka za upravljanje, nema skladištenja sesija za održavanje, nema infrastrukture za skaliranje za konfiguraciju. API upravlja svim problemima na strani servera, a frontend se pokreće u potpunosti u pregledaču korisnika. Ovo znači da chatbot može biti razvučan na statičku platformu za hosting, GitHub Pages sajt, Netlify uvođenje ili bilo koji drugi host okruženja koji služi HTML i JavaScript. Operativna režija je nula, što čini chatbot održivim čak i za projekte bez namenske infrastrukturnog budžeta ili tima za operacije.

Često postavljena pitanja

Koliko dugo sesije ostaju pre nego što isteknu

Sesije ostaju aktivne tokom konfigurabilnog trajanja koje zadano iznosi dvadeset četiri sata neaktivnosti. Sesija koja prima poruku u ovom prozoru ima svoje isteklo tajmer resetovan, tako da aktivni razgovori ostaju neograničeni. Istekle sesije i njihova istorija ostaju dostupne kroz API istorije ali ne mogu više primati nove poruke.

Može li se istorija razgovora obrisati za poštovanje privatnosti

Da. Istorija razgovora se može obrisati kroz API po sesiji ili po korisniku. Ovo podržava usklađenost sa zakonima o privatnosti kao što je GDPR koji korisnicima daju pravo da traže brisanje svojih podataka. Brisanje je trajno i uklanja sve poruke i metapodatke povezane sa određenim sesijama.

Šta se dešava ako povratni URL nije dostupan kada je odgovor spreman

API ponovlja pokušaj povratnog isporuke sa eksponencijalno zaostaju za konfigurabilnim brojem pokušaja. Ako svi pokušaji propadnu, odgovor je još dostupan kroz krajnju tačku istorije razgovora, dozvoljavajući frontendu da istražuje propuštene odgovore kao zamenu. Ovaj mehanizam ponovnog pokušaja osigurava da privremeni problemi sa mrežom ne rezultiraju u izgubljenim odgovorima.

Postoji li ograničenje brzine na poruke po sesiji

Ograničenja brzine se primenjuju na nivou računa umesto na nivou sesije, sprečavajući zloupotrebu dok dopuštaju legitimnu upotrebu visokog volumena. Zadano ograničenje brzine je dovoljno velikodušno za normalne razgovorne interakcije. Računi očekujući neobično visoke količine poruka mogu zahtevati korekcije ograničenja kroz API upravljačko sučelje.

Može li frontend otkriti kada chatbot ne zna odgovor

API odgovor uključuje metapodatke koji ukazuje na nivo pouzdanosti odgovora i da li je relevantan znanje pronađeno u bazi znanja. Frontend može koristiti ove metapodatke da prilagodi svoju prezentaciju, kao što je prikaz odricanja kada je pouzdanost niska ili sugerisanje da korisnik kontaktira ljudsku podršku kada baza znanja ne sadrži relevantne informacije za upit.

Da li API podržava obogaćene formate poruka kao slike ili dugmići

API podržava strukturirane formate odgovora koji uključuju tekst, predložena nastavna pitanja i linkove akcije. Frontend interpretira ove strukturirane elemente i prikazuje ih u skladu sa svojim vlastitim konvencijama dizajna. Ovo omogućava bogatstvene interaktivne iskustvo kao što su klikljive sugestije, uključeni linkovi i formatiran sadržaj bez zahtevanja da API razume specifične mogućnosti renderiranja frontenда.