Разстоянието между "трябва да добавим чатбот" и "чатботът е активен и обработва разговори" обикновено се измерва в седмици или месеци. Пишат се документи с изисквания. Оценяват се доставчици. Планират се интеграционни срещи. Предлагат се пилотни програми. До момента, когато чатботът окончателно стане активен, първоначалната спешност, която мотивира проекта, често се размива в организационния шум, заменена от нови приоритети, които погълнаха вниманието и бюджета, от които чатботният проект имаше нужда, за да завърши. Сроковете на внедряване са гробището, където добрите намерения за чатбота отиват да умрат.
ChatBot API компресира този график, структурирайки развертането като линеен тръбопровод с ясни, отделни стъпки. Всяка стъпка има дефиниран вход, дефиниран изход и ясен преход към следващата стъпка. Няма двусмисленост относно това, което трябва да се случи на всеки етап, няма циклични зависимости, които изискват преразглеждане на по-ранни решения, и няма архитектурни избори, които изискват дълбоки технически познания. Тръбопроводът се движи в една посока, от необработени документи със знания до активен чатбот, и всяка стъпка отнема минути, а не дни.
Разбирането на този тръбопровод в детайл е ценно не само за внедряването, но и за определяне на реалистични очаквания относно това, което всяка стъпка внася в крайния резултат. Качеството на чатбота зависи от това, което се случва на всеки етап, и знанието къде да инвестира допълнително внимание, в сравнение със стъпките, където подразбиращите се стойности са достатъчни, дава по-добри резултати за по-малко време, отколкото третирането на целия процес като черна кутия, която или работи, или не.
Първа стъпка: качване на знанията, които определят това, което чатботът знае
Тръбопроводът започва с качване на знания. Това е основната стъпка, защото всичко, което следва, зависи от качеството и пълнотата на базата от знания. Документите, качени на този етап, стават цялото разбиране на чатбота за бизнеса, неговите продукти, неговите политики и неговите процедури. Всичко, което не е представено в качените документи, е от гледната точка на чатбота неизвестна територия, която той ще обработи, като признае незнанието, или като прибегне към общо знание, което може или не може да бъде точно за конкретния бизнес.
Процесът на качване приема документи в стандартни формати и ги обработва чрез тръбопровод за приемане, който автоматично извършва няколко операции. Текстът се извлича от формата на документа, запазвайки структурни елементи като заглавия, секции и списъци, като отхвърля форматиране, което не носи семантична стойност. Извлеченият текст се разделя на сегменти, които са достатъчно малки, за да бъдат поотделно получени, но достатъчно големи, за да запазят контекста в рамките на всеки сегмент. Тези парчета се вграждат в векторно пространство, което позволява семантично търсене, което означава, че чатботът може да намери релевантна информация на основата на значение, а не на точно съвпадение на ключови думи.
Тази обработка се случва в背景 след качване и обикновено завършва в рамките на няколко минути за документи с разумен размер. По време на обработката системата анализира съдържанието, за да разбере неговата тематична структура, която хранва следващата стъпка на тръбопровода. Потребителят не трябва да разбира векторни вграждания или семантично търсене, за да се възползва от тях. Той трябва да разбира, че документите, които качва, стават знанието на чатбота, и че по-пълни, по-ясно написани документи произвеждат по-способен чатбот.
Практичен подход към качването на знания приоритизира документите, които адресират най-често срещаните взаимодействия, които чатботът ще обработи. Ако основната цел е поддържка на клиенти, документът с често задавани въпроси, ръководството за отстраняване на неизправности и ръководството за продукта са качвания с най-висок приоритет. Ако основната цел е квалификация на продажби, ръководствата за сравнение на продукти, документацията за цени и описанията на идеалния профил на клиента имат най-голямо значение. Започването с документите с най-голямо въздействие и добавянето на вторични материали по-късно позволява на чатбота да обработи най-честите сценарии веднага, докато базата от знания продължава да се разширява.
Втора стъпка: предложение на случаи на употреба на основата на качените знания
След като базата от знания е обработена, системата анализира съдържанието, за да предложи случаи на употреба, които чатботът разумно може да обработи на основата на наличната информация. Тази стъпка на предложение е една от най-ценните части на тръбопровода, защото запълва пропастта между "ето нашите документи" и "ето какво трябва да прави чатботът," пропастта, която много внедрявания на чатботи се борят да преодолеят без обширни планирачни сесии.
Предложенията се генерират чрез изследване на тематичното покритие на качените документи и преобразуване на това покритие към обичайни модели на взаимодействие с чатбот. Ако базата от знания включва документация на продукта, системата предлага случай на употреба на информация за продукта. Ако включва ръководства за отстраняване на неизправности, предлага случай на употреба на техническа поддержка. Ако включва информация за цени, предлага случай на употреба на запитване за цена. Всяко предложение идва с описание на сценария, който покрива, вида на въпросите, които потребителите могат да зададат, и очаквното поведение на чатбота при обработката на този сценарий.
Тези предложения са начални точки, не окончателни конфигурации. Потребителят преглежда всяко предложение и или го приема както е, или го модифицира, за да се приспособи по-добре на неговите специфични нужди, или го отхвърля, ако сценарият не е релевантен. Допълнителни случаи на употреба могат да бъдат определени ръчно за сценарии, които автоматичният анализ не открива, като специализирани работни потоци или граничните случаи, които са важни за бизнеса, но не са добре представени в стандартните модели на документи. Комбинацията на автоматично предложение и ръчно уточнение произвежда набор от случаи на употреба, който е както всеобхватен, така и адаптиран към действителните нужди на бизнеса.
Практическата полза от автоматично предложение на случаи на употреба е, че елиминира проблема с празния платно, който спира много внедрявания на чатботи. Вместо да се започне с въпроса "какво трябва да прави нашият чатбот?" и да се опита да се преброят всички възможни сценарии от нула, екипът започва с курирана списък на предложения, основана на действителното съдържание, което е предоставила. Това е коренно по-лесна начална точка, която ускорява процеса на вземане на решения и намалява риска от пропускане на важни сценарии, които документите ясно поддържат.
Трета стъпка: одобрение на SQL и генериране на тайна за приставка
Техническата инфраструктура, която поддържа работата на чатбота, изисква структури от база данни за съхранение на разговори, състояние на сесия, взаимодействия на потребители и дневници на получаване на знания. Тръбопроводът генерира необходимата SQL схема на основата на одобрените случаи на употреба и я представя за преглед преди изпълнение. Тази стъпка на одобрение съществува, за да гарантира прозрачност: потребителят вижда точно какви структури от база данни ще бъдат създадени, преди да бъдат създадени, поддържайки пълна видимост в техническия отпечатък на развертането на чатбота.
За потребители със технически преден план преглеждането на SQL предоставя възможност да се проверят, че схемата отговаря на техните стандарти за инфраструктура, конвенции за именуване и политики на управление на данни. За не-технически потребители, преглеждането служи главно като потвърждение на отворена система, която гарантира, че тръбопроводът не модифицира структури от база данни без явно съгласие. В双방 случаи одобрението е еденствено действие: преглеждане на генерираната схема, потвърждение, че е приемлива, и продължаване. Схемата е проектирана да бъде самостоятелна, създавайки нови таблици и индекси без модифицирането на никакви съществуващи структури от база данни.
След одобрение на SQL системата генерира тайна за приставка, която служи като акредитив на удостоверяване за всички взаимодействия на API на чатбота. Тази тайна се използва от интеграцията на началото (независимо дали е виджет на уебсайт, компонент на мобилно приложение или персонализиран интерфейс) за удостоверяване с бекенда на чатбота и установяване на оторизирани сесии на разговор. Генерирането на тайна е автоматично и следва добрите практики на сигурност, включително достатъчна ентропия и сигурно съхранение. Потребителят копира тайната и я съхранява в конфигурацията на своето приложение, завършвайки настройката на удостоверяване.
Комбинацията на одобрение на SQL и генериране на тайна представлява преходът от конфигурация към подготовка за развертане. Преди тези стъпки чатботът съществува като конфигурация: база от знания, случаи на употреба и параметри на поведение. След тези стъпки съществува като развръщаема услуга с инфраструктурата на база данни за постоянност на разговори и механизма на удостоверяване за сигурност на достъпа. Тръбопроводът преминава от абстрактна дефиниция към конкретно внедряване, и окончателната стъпка е свързване на началото.
Четвърта стъпка: развертане и първите живи разговори
Развертането свързва чатбота с неговия интерфейс на потребител. Специфичният механизъм на интеграция зависи от това, където чатботът ще живее: виджет за чат на уебсайт, екран на мобилно приложение, интеграция в Slack, персонализирана таблица с управление или каквито и да е интерфейс, който може да прави HTTP заявки към API. API на чатбота предоставя крайни точки за стартиране на сесии, изпращане на съобщения, получаване на отговори и получаване на история на разговори. Всяко начало, което може да обслужва тези крайни точки, може да хоства чатбота.
За развертане на уебсайт най-честият модел е виджет за чат, който се появява на специфични страни или по целия сайт. Виджетът обработва визуалното представяне на разговора, полето за вход за съобщения на потребител и показа на отговорите на чатбота. Той комуникира с API на чатбота, използвайки тайната на приставка за удостоверяване и идентификатор на сесия за непрекъснатост на разговора. Виджетът може да бъде построен от нула, използвайки документацията на API, или предварително построени шаблони на виджет могат да бъдат адаптирани, за да съответстват на визуалния дизайн на сайта.
Първите живи разговори са едновременно най-вълнуващата и най-информативната част на целия процес. Реалните потребители задават въпроси, които никоя планирачна сесия не е предвидила. Те фразира нещата по начини, които никоя дефиниция на случай на употреба не е предсказала. Те очакват информация, която базата от знания почти, но не съвсем съдържа. Всяко от тези взаимодействия е възможност за учене, която храни обратно въз основа на базата от знания и случаи на употреба уточнения, описани в по-ранните стъпки на тръбопровода. Тръбопроводът, в този смисъл, не е чисто линеен. Той е линеен по време на първоначално развертане и става циклански по време на текущо работата, с данни за живи разговори, които управляват непрекъсната подобрение на базата от знания и дефиниции на случаи на употреба.
Историята на разговори и аналитика предоставена от API дават поддържателю на чатбота видимост в кои въпроси се задават най-често, кои отговори удовлетворяват потребителите, и където чатботът е падащ. Тези данни преобразуват чатбота от статично развертане в динамична система, която се подобрява при използване. Първоначалната петнадесет-минутна настройка включва чатбота. Текущата подобрение, управлявана от данни за истински разговори, го прави прогресивно по-ценен по време на следващите седмици и месеци.
Полният тръбопровод в контекст
Гледано край до край, тръбопроводът преобразува компанийни документи в активен разговорен ИИ в четири отделни стъпки: качване на знания, дефиниране на случаи на употреба, одобрение на инфраструктура и развертане. Всяка стъпка има ясни входове и изходи. Всяка стъпка се гради на предходната. И всяка стъпка може да бъде завършена в минути, а не дни, което е това, което прави достижимо петнадесет-минутния график на развертане за организации, които пристигат към процеса със своите документи със знания вече организирани и техните разговорни цели вече разбирани.
Организациите, които нямат своите документи организирани, ще похарчат повече време на подготовка, отколкото на самия тръбопровод, което всъщност е ценен резултат. Процесът на развертане на чатбота принуждава организацията да консолидира и структурира своите институционални познания, което предоставя предимства много отвъд самия чатбот. Същата организирана база от знания, която управлява чатбота, също служи като по-добра вътрешна документация, по-добър материал за обучение за нови служители и по-добра основа за която и да е друга инициатива за управление на познания, която организацията предприема.
Тръбопроводът също демистифицира процеса на развертане на чатбота, като прави всяка стъпка видима и разбираема. Няма черна кутия, където документи влизат и чатбот излиза без видимост в преобразуването. Всяка стъпка е наблюдаема, всяка конфигурация е преглеждаема, и всеки компонент може да бъде коригиран независимо. Тази прозрачност изграждат доверие в системата и оправомощават поддържателите на чатбота да вземат информирани решения относно уточненията и разширенията над времето.