Planiranje RAG ili AI asistent projekta: kontrolna lista

Većina projekata AI asistenata koji razočaraju ne propada zbog modela. Propadaju zato što se niko nije dogovorio čemu asistent zapravo služi, zato što je sadržaj na kojem se zasniva bio nepotpun ili zastario, zato što su se prava pristupa rješavala naknadno ili zato što nije postojao način da se utvrdi je li neka promjena stvari poboljšala ili pogoršala. Odabir modela je važan, ali je obično jedna od lakših odluka.

Ova kontrolna lista okuplja pitanja koja prolazimo prije izrade sistema za generisanje potpomognuto pretragom (RAG) ili AI asistenta nad podacima firme. Koristite je za pripremu internog projekta, za brief dobavljaču ili da provjerite pokriva li ponuda koju ste dobili ono bitno. Ne morate imati sve odgovore prvog dana, ali trebate znati koji su još otvoreni.

1. Slučaj upotrebe i kriteriji uspjeha#

Zapišite ovo prije nego što iko otvori notebook ili počne porediti modele.

• Jedan glavni zadatak. Imenujte jedan zadatak koji asistent prvo mora dobro obavljati, na primjer odgovaranje na pitanja o proizvodima za tim podrške ili pronalaženje klauzula u ugovorima s dobavljačima. Dalji slučajevi upotrebe mogu doći kada se prvi izmjeri; miješanje više njih na početku zamagljuje i zahtjeve i evaluaciju.
• Korisnici i njihov kontekst. Opišite ko postavlja pitanja, koliko često, na kojem jeziku i na kojem uređaju te šta radi s odgovorom. Interni stručnjak koji provjerava izvore treba nešto drugo od klijenta koji na osnovu odgovora direktno djeluje.
• Stvarna pitanja s idealnim odgovorima. Prikupite 20–50 stvarnih pitanja iz tiketa, e-mailova ili razgovora u chatu i neka stručnjak za oblast napiše idealan odgovor i navede izvor iz kojeg bi trebao doći. Taj skup definiše šta znači „dobro" i postaje temelj vašeg evaluacijskog skupa.
• Izvan opsega i odbijanja. Navedite šta asistent ne smije raditi: davati pravne, medicinske ili finansijske savjete, odgovarati izvan svojih izvora, preuzimati obaveze u ime firme. Odlučite šta će umjesto toga reći i kamo će uputiti korisnika.
• Polazna vrijednost trenutnog procesa. Zabilježite kako se posao danas obavlja, koliko traje, ko ga radi i koliko košta. Bez polazne vrijednosti tvrdnja „asistent pomaže" je mišljenje, a ne rezultat.

2. Izvori podataka#

Kvalitet odgovora ograničen je kvalitetom i dostupnošću sadržaja iza njih.

• Popis izvora. Navedite svaki izvor koji bi asistent trebao koristiti: wikije, mape u SharePointu ili Google Driveu, sisteme za tikete, baze podataka, PDF-ove, web stranice. Za svaki zabilježite kako mu se pristupa (API, izvoz, crawling) i je li taj pristup dozvoljen.
• Formati i kvalitet dokumenata. Provjerite postoje li skenirani PDF-ovi kojima treba OCR, složene tabele, obrasci, prezentacije i slike s bitnim sadržajem. Tabele i skenovi su mjesta na kojima jednostavni pipelineovi gube najviše informacija, pa ih rano provjerite na uzorku.
• Vlasništvo i ažurnost. Za svaki izvor imenujte odgovornu osobu i zabilježite koliko se često mijenja. Ako sadržaj nema vlasnika, niko neće ispraviti pogrešne odgovore koji iz njega proizlaze.
• Duplikati, verzije i jezici. Pronađite zastarjele kopije, nacrte i paralelne verzije iste politike i odlučite koja je merodavna. Zabilježite jezike dokumenata i pitanja jer se pretraga preko više jezika mora izričito testirati.

3. Kontrola pristupa i privatnost#

Riješite ovo prije nego što stvarni podaci napuste vaše sisteme.

• Prava pristupa u pretrazi. Ako korisnici smiju vidjeti samo određene dokumente, pretraga mora filtrirati prema pravima korisnika koji postavlja pitanje, sinhroniziranim iz izvornih sistema. Upute u promptu ili oslanjanje na to da će model prešutjeti sadržaj nisu kontrola pristupa.
• Lični podaci i pravna osnova. Utvrdite lične podatke u dokumentima, pitanjima i logovima te dokumentirajte pravnu osnovu i svrhu obrade prema GDPR-u. Uključite službenika za zaštitu podataka na početku, a ne pri pokretanju.
• Ugovor s provajderom i lokacija podataka. Sklopite ugovor o obradi podataka sa svakim provajderom modela i infrastrukture, provjerite njihove podizvođače i potvrdite da obrada može ostati u regiji EU-a ako vam je to potrebno. Zatražite pisanu potvrdu da se vaši podaci ne koriste za treniranje modela provajdera.
• Zadržavanje, logiranje i redakcija. Odlučite koliko se dugo čuvaju promptovi, dobavljeni odlomci i odgovori, ko ih smije čitati i uklanjaju li se lični podaci prije logiranja. Logovi su potrebni za otklanjanje grešaka i evaluaciju, pa je cilj kontrolisano zadržavanje, a ne potpuno odustajanje od logova.

4. Dizajn pretrage#

Većina pogrešnih odgovora u RAG sistemima potiče od pretrage, a ne od modela; za mali i stabilan skup sadržaja dugi kontekst s prompt cachingom može u potpunosti zamijeniti pretragu (vidi RAG ili fine-tuning).

• Chunking prema strukturi dokumenta. Dijelite sadržaj po naslovima, odjeljcima, stavkama liste i granicama tabela, a ne po fiksnom broju znakova. Uz svaki chunk zadržite putanju naslova kako bi odlomak imao smisla i sam za sebe.
• Metapodaci i filteri. Uz svaki chunk pohranite naslov, izvor, odjeljak, datum, jezik, verziju i grupe pristupa. Metapodaci omogućuju filtriranje prema pravima, pravila poput „samo najnovija verzija" i korisne citate.
• Hibridna pretraga i reranking. Kombinujte pretragu po ključnim riječima za tačne pojmove poput šifri proizvoda, brojeva artikala i imena s vektorskom pretragom preko embeddinga za značenje, a zatim zajedničke kandidate ponovo rangirajte (reranking). Svaki korak testirajte na svojim primjerima pitanja umjesto da pretpostavite da su zadane postavke dovoljno dobre.
• Obavezni citati. Zahtijevajte da asistent citira odlomke koje je koristio, s linkom na izvorni dokument i odjeljak. Citati korisnicima omogućuju provjeru odgovora, a recenzentima pokazuju je li pogrešan odgovor nastao zbog loše pretrage ili loše generacije.

5. Odabir modela i provajdera#

Model odaberite kada imate evaluacijski skup, kako bi se odluka zasnivala na vašim podacima, a ne na općim benchmarkovima.

• Način hostanja. Uporedite hostani API, iste ili slične modele u cloud regiji EU-a i open-weight model koji sami hostate na vlastitoj infrastrukturi. Svaka opcija mijenja ravnotežu između kvaliteta odgovora, kontrole nad podacima, operativnog napora i troška.
• Latencija i trošak po upitu. Izmjerite ukupno vrijeme odziva i trošak po odgovorenom pitanju na vlastitim primjerima pitanja, uključujući pretragu, reranking te ulazne i izlazne tokene. Prompt caching i manji modeli za jednostavne korake mogu znatno promijeniti te brojke.
• Rezervna opcija i vezanost uz dobavljača. Isplanirajte šta se dešava kada provajder ne radi ili povuče model: drugi provajder, ograničeni način rada ili jasna poruka o grešci. Promptove, evaluacijski skup i sloj pretrage držite nezavisnima od provajdera, tako da je promjena pitanje konfiguracije i jednog eval pokretanja, a ne ponovnog razvoja.

6. Evaluacija#

Ako ne možete mjeriti kvalitet, ne možete ga ni poboljšati ni obraniti odluku o puštanju u rad.

• Eval skup prije izrade. Pretvorite stvarna pitanja iz odjeljka 1 u verzionirani evaluacijski skup s očekivanim odgovorima i očekivanim izvorima te ga proširite teškim i rubnim slučajevima. Izradite ga prije prvog prototipa, a ne nakon prvog demoa.
• Kvalitet pretrage i odgovora. Zasebno mjerite jesu li dobavljeni pravi odlomci i je li odgovor tačan, potpun i vjeran tim odlomcima. Provjerite tačnost citata: citirani odlomak mora doista podržavati tvrdnju.
• Testovi odbijanja i prompt injectiona. Uključite pitanja koja asistent mora odbiti i pitanja na koja njegovi izvori ne daju odgovor te provjerite da to i kaže umjesto da nagađa. Dodajte dokumente i unose koji pokušavaju zaobići njegove upute ili izvući podatke drugih korisnika i potvrdite da ne uspijevaju.
• Regresijska pokretanja i ljudska provjera. Pokrenite cijeli eval skup pri svakoj promjeni promptova, modela, chunkinga ili podataka i uporedite rezultate s prethodnim pokretanjem. Automatsko ocjenjivanje pomoću modela to ubrzava, ali stručnjak za oblast trebao bi redovno provjeravati uzorke rezultata.

7. Integracija i rad#

Asistent mora negdje živjeti, a neko ga mora voditi i nakon pokretanja.

• Kanal i prijava. Odlučite gdje će asistent biti dostupan: kao widget na web stranici, u Slacku ili Microsoft Teamsu, u internom alatu ili u postojećem sistemu za tikete. Koristite postojeći SSO kako bi identitet i prava pristupa dolazili s istog mjesta kao i svugdje drugdje.
• Predaja čovjeku i povratne informacije. Definišite kako korisnik dolazi do osobe kada mu asistent ne može pomoći, uz prenos dotadašnjeg razgovora. Dodajte jednostavna dugmad za povratnu informaciju i negativne povratne informacije usmjerite u evaluacijski skup.
• Model troškova i nadzor. Procijenite trošak po upitu i mjesečno pri očekivanom i vršnom opterećenju te postavite upozorenja za budžet. Pratite latenciju, stopu grešaka, stopu odbijanja i povratne informacije korisnika, uz logove redaktirane kako je dogovoreno u odjeljku 3.
• Ponovno indeksiranje, vlasništvo nad sadržajem i incidenti. Automatizirajte ponovno indeksiranje pri promjeni izvornih dokumenata, uključujući brisanja, kako asistent nikada ne bi citirao povučeni sadržaj. Odredite ko ispravlja probleme sa sadržajem i definišite proces za incidente zbog pogrešnih, štetnih ili neovlašteno otkrivenih odgovora, uključujući brzo isključivanje asistenta.

8. Kriteriji za odluku go/no-go#

Dogovorite pravila odlučivanja prije nego što stignu rezultati, kako odluka ne bi zavisila od utiska s uspješnog demoa.

• Unaprijed dogovoreni pragovi. Zapišite minimalne nivoe tačnosti odgovora i tačnosti citata na eval skupu, prihvatljivu latenciju i trošak po upitu te nultu toleranciju za odgovore koji prelaze granice prava pristupa. Uporedite rezultate s polaznom vrijednošću iz odjeljka 1.
• Vremenski ograničen pilot s jasnim izlazom. Provedite pilot s malom grupom stvarnih korisnika tokom unaprijed određenog perioda, uz imenovanu osobu koja donosi odluku. Sužavanje opsega ili odustajanje je legitiman ishod i znatno jeftiniji od saznanja nakon punog uvođenja.

Kako vam možemo pomoći#

Ako ovu kontrolnu listu želite proći zajedno s nama, najdirektniji put je naš AI Proof-of-Value Sprint s fiksnim opsegom. U dvije sedmice s vama definišemo slučaj upotrebe, izrađujemo RAG ili agentski prototip na vašim vlastitim podacima, sastavljamo evaluacijski skup, pripremamo model troškova i isporučujemo go/no-go izvještaj koji možete predstaviti donosiocima odluka. Pojedinosti su na stranici s cijenama i među našim uslugama AI i automatizacije.

Prije nego što ijedan vaš dokument dođe do modela, s vama dogovaramo način postupanja s podacima; unaprijed možete pročitati kako postupamo s podacima klijenata u AI projektima. Ako radije želite započeti razgovorom, zatražite besplatnu procjenu i opišite slučaj upotrebe koji imate na umu.