AI asistent ali RAG: kontrolni seznam pred projektom

Večina projektov AI asistentov, ki razočarajo, ne odpove zaradi modela. Odpovejo, ker se nihče ni dogovoril, čemu je asistent namenjen, ker je bila vsebina v ozadju nepopolna ali zastarela, ker so bila dovoljenja stvar naknadnega razmisleka ali ker ni bilo načina, da bi ugotovili, ali je neka sprememba stvari izboljšala ali poslabšala. Izbira modela je pomembna, a je običajno ena lažjih odločitev.

Ta kontrolni seznam zbira vprašanja, ki jih predelamo, preden zgradimo sistem RAG (retrieval-augmented generation, generiranje, podprto z iskanjem) ali AI asistenta na podatkih podjetja. Uporabite ga za pripravo internega projekta, za navodila ponudniku ali za preverjanje, ali ponudba, ki ste jo prejeli, pokriva bistveno. Prvi dan ne potrebujete vseh odgovorov, morate pa vedeti, kateri so še odprti.

1. Primer uporabe in merila uspeha#

To zapišite, preden kdor koli odpre notebook ali začne primerjati modele.

• Ena glavna naloga. Poimenujte eno samo nalogo, ki jo mora asistent najprej opravljati dobro, na primer odgovarjanje na vprašanja sodelavcev v podpori o izdelkih ali iskanje klavzul v pogodbah z dobavitelji. Nadaljnji primeri uporabe lahko sledijo, ko je prvi izmerjen; mešanje več primerov na začetku zamegli tako zahteve kot evalvacijo.
• Uporabniki in njihova situacija. Opišite, kdo sprašuje, kako pogosto, v katerem jeziku in na kateri napravi ter kaj z odgovorom naredi. Interni strokovnjak, ki preverja vire, potrebuje nekaj drugega kot stranka, ki po odgovoru neposredno ukrepa.
• Resnična vprašanja z idealnimi odgovori. Zberite 20–50 resničnih vprašanj iz zahtevkov, e-pošte ali dnevnikov klepeta, področni strokovnjak pa naj zapiše idealen odgovor in navede vir, iz katerega naj odgovor izhaja. Ta nabor določa, kaj pomeni „dobro“, in postane zametek vašega evalvacijskega nabora.
• Zunaj obsega in zavrnitve. Naštejte, česa asistent ne sme početi: dajati pravnih, zdravstvenih ali finančnih nasvetov, odgovarjati onkraj svojih virov, sprejemati zavez v imenu podjetja. Odločite se, kaj naj reče namesto tega in kam naj uporabnika usmeri.
• Izhodišče trenutnega procesa. Zabeležite, kako se naloga opravlja danes, koliko časa traja, kdo jo opravlja in koliko stane. Brez izhodišča je „asistent pomaga“ mnenje in ne rezultat.

2. Viri podatkov#

Kakovost odgovorov je navzgor omejena s kakovostjo in dostopnostjo vsebine, ki stoji za njimi.

• Popis virov. Naštejte vse vire, ki naj jih asistent uporablja: wikije, mape v SharePointu ali Google Drivu, sisteme za zahtevke, podatkovne baze, PDF-je, spletne strani. Pri vsakem zapišite, kako je do njega mogoče dostopati (API, izvoz, crawl) in ali je tak dostop dovoljen.
• Formati in kakovost dokumentov. Preverite, ali so med njimi skenirani PDF-ji, ki potrebujejo OCR, zapletene tabele, obrazci, prosojnice in slike, ki nosijo bistveno vsebino. Pri tabelah in skenih naivni cevovodi izgubijo največ informacij, zato jih zgodaj vzorčite.
• Lastništvo in svežina. Za vsak vir določite lastnika in zabeležite, kako pogosto se spreminja. Če vsebina nima lastnika, nihče ne bo popravil napačnih odgovorov, ki iz nje izhajajo.
• Dvojniki, različice in jeziki. Poiščite zastarele kopije, osnutke in vzporedne različice istega pravilnika ter določite, katera je merodajna. Zabeležite jezike dokumentov in vprašanj, saj je treba medjezično iskanje izrecno testirati.

3. Nadzor dostopa in zasebnost#

To uredite, preden kakršni koli resnični podatki zapustijo vaše sisteme.

• Dovoljenja, prenesena v iskanje. Če uporabniki smejo videti le določene dokumente, mora iskanje filtrirati po dovoljenjih uporabnika, ki sprašuje, sinhroniziranih iz izvornih sistemov. Navodila v promptu ali zaupanje, da bo model vsebino zadržal zase, niso nadzor dostopa.
• Osebni podatki in pravna podlaga. Prepoznajte osebne podatke v dokumentih, vprašanjih in dnevnikih ter dokumentirajte pravno podlago po GDPR in namen njihove obdelave. Pooblaščeno osebo za varstvo podatkov vključite na začetku, ne ob zagonu.
• Pogodba s ponudnikom in lokacija podatkov. Z vsakim ponudnikom modelov in infrastrukture sklenite pogodbo o obdelavi osebnih podatkov, preglejte njihove podobdelovalce in potrdite, da lahko obdelava ostane v regiji EU, če to zahtevate. Pridobite pisno potrditev, da se vaši podatki ne uporabljajo za učenje ponudnikovih modelov.
• Hramba, beleženje in prekrivanje podatkov. Odločite se, kako dolgo se hranijo prompti, najdeni odlomki in odgovori, kdo jih lahko bere in ali se osebni podatki pred beleženjem prekrijejo. Dnevniki so potrebni za odpravljanje napak in evalvacijo, zato je cilj nadzorovana hramba in ne ničelno beleženje.

4. Zasnova iskanja#

Večina napačnih odgovorov v sistemih RAG izvira iz iskanja (retrieval) in ne iz modela; pri majhnem, stabilnem korpusu lahko dolg kontekst s prompt cachingom iskanje v celoti nadomesti (glejte RAG vs fine-tuning).

• Razrez po strukturi dokumenta. Vsebino razdelite po naslovih, razdelkih, alinejah in mejah tabel, ne po fiksnem številu znakov. Ob vsakem odseku (chunk) ohranite pot naslovov, da je odlomek smiseln tudi sam zase.
• Metapodatki in filtri. Z vsakim odsekom shranite naslov, vir, razdelek, datum, jezik, različico in skupine z dostopom. Prav metapodatki omogočajo filtriranje po dovoljenjih, pravila „samo zadnja različica“ in uporabne navedbe virov.
• Hibridno iskanje in reranking. Združite iskanje po ključnih besedah za natančne izraze, kot so kode izdelkov, številke artiklov in imena, z vektorskim iskanjem po embeddingih za pomen, nato pa združene kandidate ponovno razvrstite (reranking). Vsak korak testirajte na svojih vzorčnih vprašanjih, namesto da predpostavljate, da so privzete nastavitve dovolj dobre.
• Obvezne navedbe virov. Od asistenta zahtevajte, da navede odlomke, ki jih je uporabil, s povezavo do izvornega dokumenta in razdelka. Navedbe virov uporabnikom omogočajo preverjanje odgovorov, pregledovalcem pa pokažejo, ali je napačen odgovor posledica slabega iskanja ali slabega generiranja.

5. Izbira modela in ponudnika#

Model izberite, ko imate evalvacijski nabor, da odločitev temelji na vaših podatkih in ne na splošnih primerjalnih testih.

• Možnost gostovanja. Primerjajte gostovani API, iste ali podobne modele v oblačni regiji EU in lastno gostovani model z odprtimi utežmi na vaši infrastrukturi. Vsaka možnost premakne ravnovesje med kakovostjo odgovorov, nadzorom nad podatki, operativnim naporom in stroški.
• Latenca in strošek na poizvedbo. Na svojih vzorčnih vprašanjih izmerite odzivni čas od začetka do konca in strošek na odgovorjeno vprašanje, vključno z iskanjem, rerankingom ter vhodnimi in izhodnimi tokeni. Prompt caching in manjši modeli za preproste korake lahko te številke občutno spremenijo.
• Rezervna rešitev in vezanost na ponudnika. Načrtujte, kaj se zgodi, ko ponudnik ne deluje ali model umakne: drugi ponudnik, okrnjen način delovanja ali jasno sporočilo o napaki. Prompti, evalvacijski nabor in iskalni sloj naj ostanejo nevtralni do ponudnika, da je zamenjava sprememba konfiguracije in ena evalvacija, ne pa ponovno pisanje.

6. Evalvacija#

Če kakovosti ne morete meriti, je ne morete izboljšati niti zagovarjati odločitve o zagonu.

• Evalvacijski nabor pred gradnjo. Resnična vprašanja iz 1. razdelka pretvorite v evalvacijski nabor z različicami, s pričakovanimi odgovori in pričakovanimi viri, ter ga razširite s težkimi in robnimi primeri. Zgradite ga pred prvim prototipom, ne po prvi demo predstavitvi.
• Kakovost iskanja in odgovorov. Ločeno merite, ali so bili najdeni pravi odlomki in ali je odgovor pravilen, popoln in zvest tem odlomkom. Preverite točnost navedb: navedeni odlomek mora trditev dejansko podpirati.
• Testi zavrnitev in prompt injectiona. Vključite vprašanja, ki jih mora asistent zavrniti, in vprašanja, na katera njegovi viri ne morejo odgovoriti, ter preverite, da to pove, namesto da ugiba. Dodajte dokumente in vnose, ki poskušajo preglasiti njegova navodila ali izvleči podatke drugih uporabnikov, in potrdite, da jim ne uspe.
• Regresijski zagoni in človeški pregled. Celoten evalvacijski nabor poženite ob vsaki spremembi promptov, modelov, razreza ali podatkov in rezultate primerjajte s prejšnjim zagonom. Samodejno ocenjevanje z modelom to pospeši, vendar naj področni strokovnjak rezultate redno vzorčno preverja.

7. Integracija in obratovanje#

Asistent mora nekje živeti in nekdo ga mora po zagonu upravljati.

• Kanal in prijava. Odločite se, kje asistent živi: v gradniku na spletni strani, v Slacku ali Microsoft Teams, v internem orodju ali obstoječem sistemu za zahtevke. Uporabite obstoječi SSO, da identiteta in dovoljenja prihajajo iz istega vira kot povsod drugje.
• Predaja človeku in povratne informacije. Določite, kako uporabnik pride do človeka, ko asistent ne more pomagati, pri čemer se pogovor preda naprej. Dodajte preproste gumbe za povratne informacije in negativne odzive usmerite v evalvacijski nabor.
• Stroškovni model in spremljanje. Ocenite strošek na poizvedbo in na mesec pri pričakovani in konični uporabi ter nastavite proračunska opozorila. Spremljajte latenco, deleže napak, deleže zavrnitev in povratne informacije uporabnikov, z dnevniki, v katerih so podatki prekriti, kot je dogovorjeno v 3. razdelku.
• Ponovno indeksiranje, lastništvo vsebine in incidenti. Avtomatizirajte ponovno indeksiranje ob spremembah izvornih dokumentov, vključno z izbrisi, da asistent nikoli ne navaja umaknjene vsebine. Določite, kdo odpravlja težave z vsebino, in opredelite postopek za incidente ob napačnih, škodljivih ali razkritih odgovorih, vključno s tem, kako asistenta hitro izklopiti.

8. Merila go/no-go#

O pravilih odločanja se dogovorite, preden pridejo rezultati, da odločitev ne pade na podlagi dobre demo predstavitve.

• Vnaprej dogovorjeni pragovi. Zapišite minimalne ravni pravilnosti odgovorov in točnosti navedb na evalvacijskem naboru, sprejemljivo latenco in strošek na poizvedbo ter ničelno toleranco do odgovorov, ki prestopijo meje dovoljenj. Rezultate primerjajte z izhodiščem iz 1. razdelka.
• Časovno omejen pilot z jasnim izhodom. Pilot izvedite z majhno skupino resničnih uporabnikov v določenem obdobju in z imenovano osebo, ki sprejme odločitev. Zožitev obsega ali ustavitev je legitimen izid in veliko cenejši, kot če to ugotovite po polni uvedbi.

Kako lahko pomagamo#

Če želite ta kontrolni seznam predelati z nami, je najbolj neposredna pot naš AI Proof-of-Value Sprint s fiksnim obsegom. V dveh tednih z vami opredelimo primer uporabe, zgradimo prototip RAG ali agenta na vaših podatkih, ustvarimo evalvacijski nabor, pripravimo stroškovni model in predamo poročilo go/no-go, ki ga lahko odnesete svojim odločevalcem. Podrobnosti so na strani Cene in pri naših storitvah AI in avtomatizacije.

Preden kateri koli vaš dokument pride do modela, se z vami dogovorimo, kako se ravna s podatki; vnaprej lahko preberete, kako ravnamo s podatki naročnikov v AI projektih. Če bi raje začeli s pogovorom, zahtevajte brezplačno oceno in opišite primer uporabe, ki ga imate v mislih.