Kako smo v platformo SaaS dodali AI-pomočnika — ne da bi jo pokvarili

Vsaka ekipa SaaS, s katero se pogovarjamo, prej ali slej naglas izgovori isti stavek: "Sem bi morali dati AI-pomočnika." Včasih je to pritisk uprave, včasih zagon konkurenta, včasih je iskren. Zanimivi del nikoli ni ideja — idejo ima skoraj vsak. Zanimivi del je vrzel med tem stavkom in funkcijo, na katero se pravi uporabniki resnično zanašajo. To je zgodba o eni ekipi, ki jo je prečkala, in o neblesteči odločitvah, ki so jo pripeljale do cilja.

Kratka opomba pred začetkom: stranko smo anonimizirali in številke zaokrožili. Gre za majhno, dobičkonosno podjetje B2B SaaS — manj kot dvajset ljudi — ki operativnim ekipam prodaja orodje za delovne tokove. Spremenili smo dovolj podrobnosti, da jih ne boste prepoznali, a oblika projekta je natanko takšna, kot se je zgodila. Številke so ponazoritvene, ne revidirane; raje vam pokažemo vzorec, kot da olepšujemo graf.

To pišemo, ker je projekt skoraj popoln primer tega, kako te stvari v resnici potekajo. Ni šlo tako, kot je obljubljala uvodna predstavitev. Šlo je bolje — a le zato, ker smo bili pripravljeni izbrisati prvo različico.

Situacija: dve težavi v istem kostumu

Ko se je ustanovitelj prvič oglasil, je bila zahteva preprosta: "Želimo AI-klepetalnega robota v aplikaciji." Tam se začne večina projektov in tam gre večina med njimi tudi tiho narobe. "AI-klepetalni robot" ni cilj, temveč oblika. Naša prva naloga je bila ugotoviti, katero težavo naj bi ta klepetalni robot rešil — in ali gre sploh za eno težavo.

Ni šlo. Pod to eno zahtevo sta se skrivali dve povsem različni bolečini. Prva je bila obremenitev podpore: dvočlanska ekipa za podporo strankam se je utapljala v ponavljajočih se zahtevkih — "kako to izvozim", "kje je nastavitev za ono", "zakaj se moje poročilo ni izvedlo". Približno 60 % dohodnih zahtevkov so bila vprašanja, ki so bila že nekje odgovorjena v njihovi dokumentaciji za pomoč. Druga bolečina je bila tišja in dražja: aktivacija. Njihov izdelek je imel resnično zmogljivo funkcijo, skrito tri klike globoko, ki je skoraj nihče ni odkril sam. Uporabniki, ki so jo našli, so ostajali leta. Tisti, ki je niso, so odšli v prvih dveh mesecih.

Isti kostum, dve težavi. In vlekli sta v različni smeri. Robot za podporo želi odbiti vprašanja in se umakniti s poti. Pomočnik za aktivacijo želi začeti pogovore in potiskati ljudi k stvarem, po katerih niso vprašali. Če bi zgradili "AI-klepetalnega robota" brez ločevanja tega, bi zgradili nekaj, kar obe nalogi opravlja slabo.

Zožitev obsega na nekaj, kar lahko dokončamo

Ko se soočite z dvema težavama, se pojavi skušnjava, da bi zgradili veličastnega pomočnika, ki od prvega dne obvlada oboje. Ekipo smo od tega odgovorili. Ne zato, ker bi bila vizija napačna, temveč zato, ker je šestmesečni "pomočnik za vse" natanko tista vrsta projekta, ki zamuja, pade v prazno in vse za naslednji dve leti napravi živčne glede AI.

Zato smo izbrali eno. Najprej smo izbrali odbijanje podpore, iz treh dolgočasnih, a odločilnih razlogov. Imelo je jasen, merljiv cilj — obseg zahtevkov. Uporabljalo je vsebino, ki je že obstajala — njihovo dokumentacijo in pretekle zahtevke. In če bi bilo neuspešno, je bila škoda majhna: uporabnik, ki ni dobil dobrega odgovora, je preprosto storil to, kar je že prej, in odprl zahtevek. Nizko tveganje, hitre povratne informacije, poštena metrika. To je vsakič dobra prva funkcija AI.

Pomočnik za aktivacijo ni izginil — parkirali smo ga, na papirju, z jasno opombo: druga faza, takoj ko se sloj pridobivanja izkaže. Ta ena odločitev je projekt verjetno rešila. Ekipi je dala ciljno črto, ki jo je dejansko lahko dosegla v tednih namesto v četrtletjih.

Prvi prototip, ki smo ga zgradili — in izbrisali

Tukaj je del, ki ga večina študij primerov izpusti. Naš prvi delujoč prototip je bil, milo rečeno, slab. Naredili smo očitno: povezali smo članke za pomoč izdelka z velikim jezikovnim modelom, dodali polje za klepet in pustili uporabnike, da postavljajo vprašanja. V predstavitvi je izgledalo čarobno. Pri pravem preizkušanju je razpadlo na zelo specifičen, zelo poučen način.

Model se je samozavestno motil. Ob vprašanju o nastavitvi, ki je bila preimenovana pol leta prej, je veselo izmislil staro pot v meniju. Ob vprašanju o funkciji na višjem paketu je pojasnil, kako jo uporabljati — stranki, ki do nje ni imela dostopa. Vsak odgovor je zvenel avtoritativno, kar je napačne naredilo slabše od nobenega odgovora. Robot za podporo, ki vljudno laže, ne zmanjšuje zahtevkov; ustvarja bolj jezne.

Lahko bi to zakrpali s prilagoditvami poziva. Namesto tega smo naredili nekaj, kar se je zdelo korak nazaj, izkazalo pa se je za celotno bistvo: prvi prototip smo zavrgli in ga znova zgradili okoli strogega pravila — pomočnik sme odgovoriti le iz virov, ki jih lahko navede, sicer pa mora reči "ne vem".

Kaj smo pravzaprav zgradili

Različica, ki je bila objavljena, je bila namerno skromna v tem, kar je poskušala, in stroga v tem, kako se je vedla. Pod pokrovom je šlo za pomočnika, utemeljenega na pridobivanju: ko je uporabnik nekaj vprašal, je sistem najprej preiskal skrbno vzdrževano, sveže znanje, nato pa modelu naročil, naj odgovori samo iz tega, kar je našel, s povezavo do vira. Ni vira, ni samozavestnega odgovora — le čista predaja človeku.

Tri odločitve o zasnovi so opravile večino težkega dela in nobena ni razburljiva. Prav v tem je bistvo — dolgočasne odločitve so običajno tiste, ki odločajo, ali je funkciji AI zaupano ali je tiho izklopljena.

Utemeljenost pred iznajdljivostjo

Vsak odgovor je bil vezan na resničen, aktualen dokument. Več časa smo porabili za čiščenje in strukturiranje baze znanja kot za nastavljanje modela. Neblesteče in daleč najbolj učinkovito delo v projektu. Povprečen model na odlični, dobro vzdrževani vsebini premaga briljanten model na zastarelem neredu.

Elegantna predaja

Ko pomočnik ni bil prepričan, ni ugibal. Povedal je to in ponudil pot do človeka z enim klikom — s seboj je nesel kontekst pogovora, da uporabniku nikoli ni bilo treba ponavljati. V nasprotju s pričakovanji je to ljudi pripravilo, da so robotu bolj zaupali: pomočnik, ki priznava svoje meje, deluje pošteno, in nanj so se zanašali pri lahkih 60 % prav zato, ker se je pri težkih 40 % umaknil.

Zaveda se, kdo sprašuje

Ker je živel znotraj izdelka, je pomočnik poznal uporabnikov paket, vlogo in to, kje v aplikaciji se nahaja. Zato nikoli ni pojasnjeval funkcije, do katere uporabnik ni imel dostopa, in je znal reči "gumb, ki ga iščete, je na zaslonu, na katerem že ste." Ta zavedanje o izdelku je prava prednost pomočnika v aplikaciji pred generičnim klepetalnim robotom, prilepljenim na tržno stran.

1. 1
   Očistili in strukturirali bazo znanja

   Pregledali smo vsak dokument za pomoč, odstranili zastarele, preostale pa označili glede na paket in funkcijo. To je bil prvi teden in bil je najpomembnejši.
2. 2
   Zgradili sloj pridobivanja

   Najprej iskanje, nato odgovor. Model je vedno videl le preverjeno, aktualno vsebino — z navodilom, naj zavrne vse, česar ne more utemeljiti v viru.
3. 3
   Povezali kontekst izdelka

   Pomočnika smo povezali z uporabnikovim paketom, vlogo in trenutnim zaslonom, tako da so bili odgovori prilagojeni in nikoli niso kazali na funkcije, ki jih niso mogli uporabljati.
4. 4
   Zasnovali pošteno rezervno pot

   Pot 'nisem prepričan — tukaj je človek' smo zgradili kot prvorazredno funkcijo, s polnim kontekstom pogovora, predanim ekipi za podporo.
5. 5
   Objavili za 10 % uporabnikov za zastavico

   Tiho smo funkcijo uvedli delu računov, dva tedna spremljali prave pogovore, popravili, kar se je lomilo, in nato razširili uvedbo.

Rezultati — in tisti, ki nas je presenetil

Ko je bil pomočnik v živo za vse približno tri mesece, je bila slika jasna. Dali vam bomo zaokrožene, ponazoritvene številke — smer je pomembnejša od decimalk.

Številka podpore je bila tista, ki smo jo obljubili, in je dostavila: nekaj več kot polovica ponavljajočih se zahtevkov je preprosto nehala prihajati, dvočlanska ekipa pa je dobila nazaj svoj teden za primere, ki so človeka resnično potrebovali. Dober izid, natanko po obsegu.

A rezultat, ki je ustanovitelja resnično presenetil, je bil tisti, za katerega sploh nismo optimizirali. Ker je pomočnik ves dan odgovarjal na vprašanja "kako naredim X", je naravno vseskozi usmerjal uporabnike k tisti skriti, lepljivi funkciji — tisti, vezani na zadržanje. Pomočnika za aktivacijo še nismo zgradili. Robot za podporo je tiho opravljal del njegovega dela kot stranski učinek, samo s tem, da je bil koristen in poznal izdelek. Novi uporabniki so funkcijo našli tedne prej kot prej.

Kaj bi rekli naslednji ekipi

Če ste ekipa SaaS, ki strmi v isti stavek "morali bi dodati AI-pomočnika", se nekaj stvari iz tega projekta dobro posplošuje tudi zunaj njega.

• Ločite težave, preden začnete graditi. "AI-klepetalni robot" skoraj vedno skriva dve ali tri različne naloge, ki želijo drugačno zasnovo.
• Začnite s primerom uporabe, kjer napačen odgovor stane najmanj. Odbijanje podpore je skoraj popolna prva poteza; rezervna možnost je status quo.
• Namenite večino truda vsebini, ne modelu. Utemeljenost na čistih, aktualnih podatkih je tisto, kar naredi pomočnika vrednega zaupanja.
• Naj bo 'ne vem' funkcija, ne neuspeh. Poštena predaja gradi zaupanje, zaradi katerega se uporabniki zanesejo na dele, ki jih robot opravlja dobro.
• Najprej objavite za zastavico manjšemu delu. Pravi pogovori vas bodo naučili to, česar nobena predstavitev nikoli ne bo.

Pogosta vprašanja