Традиционната архитектура на приложение за чатбот се състои от три слоя: фронтенд, с който потребителят взаимодейства, бекенд, който управлява състоянието на разговора и бизнес логиката, и услуга за изкуствен интелект, която генерира отговори. Изграждането на всички три слоя е значителен инженерен проект. Фронтендът се нуждае от интерфейс за чат с изобразяване на съобщения, управление на входа и актуализации в реално време. Бекендът се нуждае от управление на сеансите, съхранение на съобщения, преработка на разговорите, ограничаване на скоростта и удостоверяване. Интеграцията на изкуствения интелект се нуждае от изграждане на подсказки, управление на контекста и анализ на отговорите. Заедно тези компоненти представляват седмици или месеци работа по развитие за екип, който може да е начал проекта, очаквайки нещо по-просто.

ChatBot API напълно елиминира средния слой. API управлява управлението на сеансите, състоянието на разговора, историята на съобщенията и генериране на отговори на изкуствения интелект като хостирана услуга. Разработчикът изграждат само фронтенда, интерфейс за чат, който изпраща съобщения към API и показва отговори. Няма бекенд за изграждане, няма база данни за управление, няма инфраструктура на сеансите за поддържане. API е бекендът и управлява всичко между съобщението на потребителя и отговора на чатбота без да изисква никакъв код от страна на сървъра от разработчика.

Тази архитектура, понякога наричана "API-first" или "backend-as-a-service", не е нова по принцип. API за обработка на плащания елиминираха необходимостта от изграждане на бекенди за плащания. API за удостоверяване елиминираха необходимостта от изграждане на бекенди за удостоверяване. ChatBot API прилага същия принцип към разговорния изкуствен интелект: сложният, статически и тежък по отношение на инфраструктурата бекенд се предоставя като услуга, а разработчикът се фокусира изключително върху потребителския опит. Резултатът е, че разработчик, който може да изгради уеб страница, може да изгради чатбот, защото изграждането на уеб страница е единственото необходимо умение.

Сеанси и как разговорите поддържат контекста между съобщенията

Чатбот, който не може да си припомни какво е било казано преди три съобщения, не водит разговор. Той отговаря на изолирани въпроси, което е принципно различен и много по-малко полезен модел на взаимодействие. Разликата между Q&A бот и разговорен агент е контекста: способността да се прави препратка към предишни съобщения, да се разграждат установените информации и да се поддържа последователен поток в множество обмени. Именно този контекст прави разговорите естествени и прави възможни сложни многостепенни взаимодействия, като потоци за отстраняване на неизправности, управлявани конфигурации и прогресивна събирка на информация.

Системата за сеанси в ChatBot API предоставя този контекст автоматично. Когато разговорът започнете, API създава сеанс, идентифициран чрез уникален жетон на сеанса. Всяко последващо съобщение, изпратено с този жетон на сеанса, се третира като част от един и същи разговор. API поддържа пълната история на разговора в сеанса и всеки нов отговор се генерира със знанието на всичко, което е було казано преди. Потребителят може да задам въпрос, да получи отговор, да задам уточняващ въпрос, който прави препратка към предишния отговор, и да получи последователен отговор, който се основава на установения контекст без никаква повторение или объркване.

Управлението на сеансите от страна на разработчика изисква съхранението и предаването на жетона на сеанса при всеки API повик. Жетонът се получава при начало на разговора и се включва във всяко последващо съобщение. Това е единственото състояние, което фронтендът трябва да управлява. Историята на разговора, контекстният прозорец, изграждането на подсказки и всички други операции със състояние се случват на страна на API. Отговорността на фронтенда е ограничена до знанието кой сеанс принадлежи, което е една стойност на низ, съхранена в памет или в хранилище на сеанса на браузъра.

Трайността на сеансите гарантира, че разговорите преживяват обновления на страницата, промени на разделите и дори промени на устройствата. Докато жетонът на сеанса се запазва и се предава със следващото съобщение, разговорът продължава точно откъдето е прекъснат. Потребител, който стартира разговор за поддръжка на компютъра, затваря браузъра и отвори отново страницата часове по-късно, може безпроблемно да продължи разговора, защото сеансът и пълната му история се съхраняват на страна на API. Тази трайност се управлява от инфраструктурата на сеансите на API и не изисква база данни или хранилище от страна на разработчика.

Обратни повиквания и получаване на отговори без проучване

Отговорите на чатбота отнемат време за генериране. Изкуствения интелект трябва да обработи контекста на разговора, да намери съответстващи знания, да изгради подсказка, да генерира отговор и да форматира резултата. В зависимост от сложността на въпроса и размера на базата от знания, това може да отнеме от един до няколко секунди. През това време фронтендът трябва да знае кога отговорът е готов, за да го покаже на потребителя.

Най-простият подход е синхронна заявка-отговор: фронтендът изпраща съобщение и чака отговорът да се върне в один HTTP запрос. Това работи, но създава потребителски опит, при който интерфейсът се замразява при генериране, без указание за напредък и без възможност за отмяна или пренасочване. За бързи отговори, това е приемливо. За отговори, които отнемат няколко секунди, замразеният интерфейс изглежда счупен за потребителя.

URL адресите на обратни повиквания предоставят асинхронна алтернатива, която дава много по-добър потребителски опит. При изпращането на съобщение към API разработчикът включва URL адрес на обратен повик, който API ще повика, когато отговорът е готов. Запитването на фронтенда се връща веднага с потвърждение, което позволява на интерфейсът да покаже "писане" индикатор или други обратни сведения за напредък, докато отговорът се генерира в фонов режим. Когато отговорът е готов, API го изпраща към URL адреса на обратния повик, което активира интерфейсът да покаже завършеното съобщение. Потребителят вижда естествен разговорен ритъм: тяхното съобщение се показва, кратък индикатор за писане се възпроизвежда и отговорът пристига, всичко без видимо чакане или замразяване на интерфейса.

За разработчици, които изграждат чисто клиентски приложения (единична страница приложения, статични сайтове или браузърни инструменти), URL адресите на обратни повиквания могат да бъдат комбинирани с события, изпратени от сървъра или WebSocket връзки, за да пушнат отговори директно на браузъра. API изпраща завършения отговор към крайната точка на обратния повик, която го пушва към свързаната браузърна сесия. Този модел изисква минимален компонент на страна на сървъра (само приемник на обратен повик и механизъм на пушване), но поддържа цялата разговорна логика и управление на състоянието на страна на API. Сървърът на разработчика управлява маршрутизиране, не мислене.

Механизмът на обратния повик също поддържа потоци отговорите, при които резултатът на изкуствения интелект се доставля постепенно, докато се генерира, вместо всички наведнъж, когато е завършен. Потокът произвежда характерния ефект "писане в реално време", който потребителите са свикнали да очакват от интерфейсите за чат. Всеки жетон или фраза пристига, докато се генерира, създавайки естествен поток, който изглежда, че чатботът мисли и отговаря в реално време, вместо да изчезне за няколко секунди и след това да излее пълен отговор. Това поведение на потока е особено важно за по-дълги отговори, при които общото време на генериране може да бъде пет или повече секунди.

История на разговорите и изграждане на функции над съхранени съобщения

Всяко съобщение във всеки сеанс се съхранява и е достъпно чрез крайните точки на историята на API. Тази съхранена история служи на множество цели над позволяването на разговорния контекст в един сеанс. Тя предоставя суровия материал за анализ, мониториране на качеството, събиране на данни за обучение и функции на потребителския опит, които добавят стойност към разгръщането на чатбота.

Анализът на основата на историята на разговорите разкрива закономерности в поведението на потребителя и производителността на чатбота. Кои въпроси се задават най-често? Кои отговори водят до последващи въпроси (указвайки, че първоначалният отговор е бил недостатъчен)? Кои разговори завършват с позитивна резолюция и кои завършват с потребителя, напускащ сеанса? Тези закономерности, видими в съвкупност в сотици или хиляди разговори, ръководят непрекъснатото подобрение на базата от знания и определенията на случаите на употреба. Без история на разговорите, този процес на подобрение разчита на анекдотични отзиви, а не на систематичен анализ.

Мониторингът на качеството използва историята на разговорите, за да идентифицира определени взаимодействия, при които производителността на чатбота е падала под очаквания. Рецензент може да прочете отбелязани разговори, да идентифицира определената пропуск на знанията или несъответствието на случай, което причини проблема, и да направи целевите подобрения, които предотвратят същия неуспех в бъдещите разговори. Това целевото прекомпилиране е много по-ефикасно от общото разширение на базата от знания, защото се занимава със специфични, демонстрирани слабости, вместо с хипотетични.

Потребителски функции, изграждане на историята на разговорите, подобряват самия чат опит. Представянето "скорошни разговори" позволява на потребителите да се върнат към предишни сеанси и да прегледат информацията, която са получили. Функция за търсене на историята на разговорите позволява на потребителите да намерят определена информация, без да задават същия въпрос отново. Функция за експортиране позволява на потребителите да запазят важни разговори като справочни документи. Всяка от тези функции е изградена напълно от данните на историята, предоставени от API, не изискващи допълнително съхранение или управление на данни от страна на разработчика.

Пълният фронтенд и как изглежда чатбот интерфейс без бекенд

Полно приложение интерфейс на чатбот, разработено на ChatBot API се състои от зона за показване на съобщения, текстов вход, бутон за изпращане и JavaScript (или еквивалентен код на страна на клиента), който свързва тези елементи на интерфейса към крайните точки на API. Зоната за показване на съобщения визуализира историята на разговора като редуващи се потребителски и чатбот съобщения. Текстовият вход улавя съобщението на потребителя. Бутонът за изпращане активира API повик, който изпраща съобщението и инициира генериране на отговор. Когато отговорът пристигне (синхронно или чрез обратен повик), се добавя към зоната за показване на съобщения и интерфейсът е готов за следващия обмен.

Стилизирането, оформлението и дизайн на взаимодействие на този фронтенд са напълно под контрола на разработчика. API не налага никакви ограничения на визуалната презентация на интерфейса за чат. Може да е приложение за чат на пълна страница, странична панел, плаващ уиджет, модален диалог или всякакъв друг UI модел, който отговаря на дизайна на приложението. API предоставя разговорния двигател; разработчикът предоставя лицето. Това разделение означава, че появата на чатбота е ограничена само от умелите способности на разработчика, а не от ограниченията на предварително конструираната рамка на уиджета.

За разработчици, които предпочитат да не изграждат персонализиран интерфейс, форматите на сеанси и съобщения на API са съвместими с компоненти на чат интерфейс с отворен код, които могат да бъдат адаптирани с минимална модификация. Компоненти на чат React, Vue и JavaScript vanilla са достъпни в публични хранилища, а свързването им с ChatBot API изисква замяната на стандартното управление на съобщенията с API повиквания. Удостоверяването използва тайната на приставката, съобщенията използват жетона на сеанса и показването използва каквото е логиката на визуализиране, предоставена от избрания компонент. Адаптацията обикновено отнема по-малко от един час за разработчик, познат с рамката на компонента.

Отсъствието на бекенд в тази архитектура е неговото най-значително практическо предимство. Няма сървър за подготовка, няма база данни за управление, няма хранилище на сеанс за поддържане, няма инфраструктура за мащабиране за конфигуриране. API управлява всички проблеми на страна на сървъра и фронтенда работи напълно в браузъра на потребителя. Това означава, че чатботът може да бъде разгръщен на статична платформа за хостване, сайт GitHub Pages, разгръщане на Netlify или всякакъв друг хост среда, която служи HTML и JavaScript. Оперативното натоварване е нула, което прави чатбота устойчив, дори за проекти без дедикиран бюджет на инфраструктура или отбор за операции.

Често задавани въпроси

Как дълго сеансите се съхраняват преди изтичане

Сеансите остават активни за конфигурируемо време, което подразбира двадесет и четири часа неактивност. Сеанс, който получава съобщение в този прозорец, има своя таймер на изтичане преустановен, така че активните разговори продължават неограничено. Изтеклите сеанси и тяхната история остават достъпни чрез API на историята, но вече не могат да получават нови съобщения.

Може ли историята на разговорите да бъде изтрита за съответствие с приватността

Да. История на разговорите може да бъде изтрита чрез API по сеанс или по потребител. Това поддържа съответствието със законите за приватност, като GDPR, които дават на потребителите право да поискат изтриване на своите данни. Изтриването е постоянно и премахва всички съобщения и метаданни, свързани с определени сеанси.

Какво се случва, ако URL адресът на обратния повик е недостъпен, когато отговорът е готов

API опитва отново доставката на обратен повик с експоненциална защита за конфигурируемо число опити. Ако всички опити се провалят, отговорът все още е достъпен чрез крайната точка на историята на разговора, което позволява на фронтенда да проучи за пропуснатите отговори като резервно решение. Този механизъм за повторни опити гарантира, че преходни проблеми с мрежата не причиняват загуба на отговори.

Има ли ограничение на скоростта на съобщения по сеанс

Ограниченията на скоростта се прилагат на ниво счета, а не на ниво сеанс, което предотвратява злоупотреба и позволява законния висок обем. Ограничението на скоростта по подразбиране е достатъчно щедро за нормални разговорни взаимодействия. Сметки, очаквайте необичайно високи обеми на съобщения, могат да поискат корекции на лимита чрез интерфейса за управление на API.

Може ли фронтендът да открие, когато чатботът не знае отговора

Отговорът на API включва метаданни, които указват нивото на достоверност на отговора и дали съответстващи знания се намерят в базата от знания. Фронтендът може да използва тези метаданни, за да коригира своята презентация, като показва отказ, когато доверието е ниско или предлага потребителят да контактува човешка поддръжка, когато базата от знания не съдържа съответстващи информации за запитването.

API поддържа ли боготи формати на съобщения като изображения или бутони

API поддържа структурирани формати на отговори, които включват текст, предложени последващи въпроси и връзки на действие. Фронтендът интерпретира тези структурирани елементи и ги визуализира в съответствие със своите собствени конвенции за дизайн. Това позволява богатите интерактивни опити, като кликаеми предложения, встроени връзки и форматирано съдържание, без да е необходимо API да разбира определените възможности за визуализиране на фронтенда.