Как добавихме ИИ асистент към SaaS платформа — без да я счупим

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

Кратка бележка преди да започнем: анонимизирахме клиента и закръглихме числата. Става дума за малка, печеливша B2B SaaS компания — под двайсет души — която продава инструмент за работни процеси на оперативни екипи. Променихме достатъчно детайли, за да не ги разпознаете, но формата на проекта е точно такава, каквато се случи. Числата са илюстративни, не одитирани; предпочитаме да ви покажем модела, отколкото да разкрасяваме графика.

Описваме го, защото проектът е почти идеален пример за това как всъщност се случват тези неща. Не мина така, както обещаваше началната презентация. Мина по-добре — но само защото бяхме готови да изтрием първата версия.

Ситуацията: два проблема в един костюм

Когато основателят се свърза с нас за първи път, заявката беше проста: "Искаме ИИ чатбот в приложението." Оттам започват повечето проекти и точно там повечето от тях тихо тръгват накриво. "ИИ чатбот" не е цел, а форма. Затова първата ни задача беше да разберем какъв проблем трябва да реши този чатбот — и дали изобщо е един проблем.

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

Един костюм, два проблема. И те дърпаха в различни посоки. Ботът за поддръжка иска да отклонява въпроси и да се маха от пътя. Асистентът за активация иска да започва разговори и да побутва хората към неща, за които не са питали. Ако бяхме изградили "ИИ чатбот" без да ги разделим, щяхме да изградим нещо, което върши и двете задачи зле.

Стесняване на обхвата до нещо, което можем да завършим

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

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

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

Първият прототип, който изградихме — и изтрихме

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

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

Можехме да го закърпим с промени в подканите. Вместо това направихме нещо, което изглеждаше като крачка назад, но се оказа цялата същина: изхвърлихме първия прототип и го изградихме отново около строго правило — асистентът може да отговаря само от източници, които може да цитира, а иначе трябва да каже "не знам".

Какво всъщност изградихме

Версията, която пуснахме, беше умишлено скромна в това, което опитваше, и строга в това, как се държеше. Под капака беше асистент, обоснован върху извличане: когато потребител попиташе нещо, системата първо търсеше в грижливо поддържана, актуална база знания, после искаше от модела да отговори само от намереното, с връзка обратно към източника. Няма източник, няма самоуверен отговор — само чисто предаване на човек.

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

Обоснованост вместо изобретателност

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

Изящно предаване

Когато асистентът не беше уверен, не гадаеше. Казваше го и предлагаше път към човек с едно кликване — носейки контекста на разговора със себе си, така че потребителят никога да не се налага да повтаря. Противно на очакванията, това накара хората да се доверяват повече на бота: асистент, който признава границите си, изглежда честен, и разчитаха на него за лесните 60% именно защото се отдръпваше при трудните 40%.

Наясно кой пита

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

1. 1
   Почистихме и структурирахме базата знания

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

   Първо търсене, после отговор. Моделът винаги виждаше само проверено, актуално съдържание — с указание да отказва всичко, което не може да обоснове с източник.
3. 3
   Свързахме контекста на продукта

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

   Изградихме пътя 'не съм сигурен — ето човек' като първокласна функция, с пълния контекст на разговора, предаден на екипа по поддръжка.
5. 5
   Пуснахме за 10% от потребителите зад флаг

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

Резултатите — и този, който ни изненада

След като асистентът беше на живо за всички около три месеца, картината беше ясна. Ще ви дадем закръглени, илюстративни цифри — посоката е по-важна от десетичните.

Числото на поддръжката беше това, което обещахме, и то се сбъдна: малко над половината от повтарящите се заявки просто спряха да пристигат, а двучленният екип си върна седмицата за случаите, които наистина се нуждаеха от човек. Добър резултат, точно според обхвата.

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

Какво бихме казали на следващия екип

Ако сте SaaS екип, който се взира в същото изречение "трябва да добавим ИИ асистент", няколко неща от този проект се обобщават добре и извън него.

• Разделете проблемите, преди да строите. "ИИ чатбот" почти винаги крие две или три различни задачи, които искат различен дизайн.
• Започнете със сценария, при който грешният отговор струва най-малко. Отклоняването на поддръжка е почти идеален първи ход; резервният вариант е статуквото.
• Заделете по-голямата част от усилията за съдържанието, не за модела. Обосноваването върху чисти, актуални данни е това, което прави асистента достоен за доверие.
• Направете 'не знам' функция, а не провал. Честното предаване изгражда доверието, което кара потребителите да разчитат на частите, които ботът върши добре.
• Първо пуснете зад флаг за малка част. Реалните разговори ще ви научат на неща, които никоя демонстрация няма да ви покаже.

Чести въпроси