Definiranje opsega RAG ili AI asistent projekta: popis provjere

Većina projekata AI asistenata koji razočaraju ne propada zbog modela. Propadaju zato što se nitko nije dogovorio čemu asistent zapravo služi, zato što je sadržaj na kojem se temelji 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.

Ovaj popis provjere okuplja pitanja koja prolazimo prije izrade sustava za generiranje potpomognuto pretraživanjem (RAG) ili AI asistenta nad podacima tvrtke. Koristite ga za pripremu internog projekta, za brief dobavljaču ili kako biste provjerili 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 uporabe i kriteriji uspjeha#

Zapišite ovo prije nego što itko otvori notebook ili počne uspoređivati modele.

• Jedan glavni zadatak. Imenujte jedan zadatak koji asistent prvo mora dobro obavljati, primjerice odgovaranje na pitanja o proizvodima za tim podrške ili pronalaženje klauzula u ugovorima s dobavljačima. Daljnji slučajevi uporabe 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 tko postavlja pitanja, koliko često, na kojem jeziku i na kojem uređaju te što radi s odgovorom. Interni stručnjak koji provjerava izvore treba nešto drugo od klijenta koji na temelju odgovora izravno djeluje.
• Stvarna pitanja s idealnim odgovorima. Prikupite 20–50 stvarnih pitanja iz tiketa, e-poruka ili razgovora u chatu i neka stručnjak za područje napiše idealan odgovor i navede izvor iz kojeg bi trebao doći. Taj skup definira što znači „dobro” i postaje temelj vašeg evaluacijskog skupa.
• Izvan opsega i odbijanja. Navedite što asistent ne smije raditi: davati pravne, medicinske ili financijske savjete, odgovarati izvan svojih izvora, preuzimati obveze u ime tvrtke. Odlučite što će umjesto toga reći i kamo će uputiti korisnika.
• Polazna vrijednost trenutnog procesa. Zabilježite kako se posao danas obavlja, koliko traje, tko ga radi i koliko košta. Bez polazne vrijednosti tvrdnja „asistent pomaže” mišljenje je, a ne rezultat.

2. Izvori podataka#

Kvaliteta odgovora ograničena 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, sustave za tikete, baze podataka, PDF-ove, web-stranice. Za svaki zabilježite kako mu se pristupa (API, izvoz, crawling) i je li taj pristup dopušten.
• Formati i kvaliteta dokumenata. Provjerite postoje li skenirani PDF-ovi kojima treba OCR, složene tablice, obrasci, prezentacije i slike s bitnim sadržajem. Tablice i skenovi mjesta su 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, nitko 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 mjerodavna. Zabilježite jezike dokumenata i pitanja jer se pretraživanje preko više jezika mora izričito testirati.

3. Kontrola pristupa i privatnost#

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

• Prava pristupa u pretraživanju. Ako korisnici smiju vidjeti samo određene dokumente, pretraživanje mora filtrirati prema pravima korisnika koji postavlja pitanje, sinkroniziranima iz izvornih sustava. Upute u promptu ili oslanjanje na to da će model prešutjeti sadržaj nisu kontrola pristupa.
• Osobni podaci i pravna osnova. Utvrdite osobne 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 pružateljem i lokacija podataka. Sklopite ugovor o obradi podataka sa svakim pružateljem modela i infrastrukture, provjerite njihove podizvršitelje 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 pružatelja.
• Zadržavanje, logiranje i redakcija. Odlučite koliko se dugo čuvaju promptovi, dohvaćeni odlomci i odgovori, tko ih smije čitati i uklanjaju li se osobni podaci prije logiranja. Logovi su potrebni za otklanjanje pogrešaka i evaluaciju, pa je cilj kontrolirano zadržavanje, a ne potpuno odustajanje od logova.

4. Dizajn pretraživanja#

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

• Chunking prema strukturi dokumenta. Dijelite sadržaj po naslovima, odjeljcima, stavkama popisa i granicama tablica, a ne po fiksnom broju znakova. Uz svaki chunk zadržite putanju naslova kako bi odlomak imao smisla i sam za sebe.
• Metapodaci i filtri. 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.
• Hibridno pretraživanje i reranking. Kombinirajte pretraživanje po ključnim riječima za točne pojmove poput šifri proizvoda, brojeva artikala i imena s vektorskim pretraživanjem preko embeddinga za značenje, a zatim zajedničke kandidate ponovno 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 poveznicom na izvorni dokument i odjeljak. Citati korisnicima omogućuju provjeru odgovora, a recenzentima pokazuju je li pogrešan odgovor nastao zbog lošeg pretraživanja ili loše generacije.

5. Odabir modela i pružatelja#

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

• Način hostanja. Usporedite 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 kvalitete 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 pretraživanje, 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 što se događa kada pružatelj ne radi ili povuče model: drugi pružatelj, ograničeni način rada ili jasna poruka o pogrešci. Promptove, evaluacijski skup i sloj pretraživanja držite neovisnima o pružatelju, tako da je promjena pitanje konfiguracije i jednog eval pokretanja, a ne ponovnog razvoja.

6. Evaluacija#

Ako ne možete mjeriti kvalitetu, ne možete je 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.
• Kvaliteta pretraživanja i odgovora. Zasebno mjerite jesu li dohvaćeni pravi odlomci i je li odgovor točan, potpun i vjeran tim odlomcima. Provjerite točnost citata: citirani odlomak mora doista potkrepljivati 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 usporedite rezultate s prethodnim pokretanjem. Automatsko ocjenjivanje pomoću modela to ubrzava, ali stručnjak za područje trebao bi redovito provjeravati uzorke rezultata.

7. Integracija i rad#

Asistent mora negdje živjeti, a netko 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 sustavu 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. Definirajte kako korisnik dolazi do osobe kada mu asistent ne može pomoći, uz prijenos dotadašnjeg razgovora. Dodajte jednostavne gumbe 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 proračun. Pratite latenciju, stopu pogrešaka, stopu odbijanja i povratne informacije korisnika, uz logove redigirane 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 tko ispravlja probleme sa sadržajem i definirajte 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 ovisila o dojmu s uspješnog demoa.

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

Kako vam možemo pomoći#

Ako ovaj popis želite proći zajedno s nama, najizravniji put je naš AI Proof-of-Value Sprint s fiksnim opsegom. U dva tjedna s vama definiramo slučaj uporabe, 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 donositeljima 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 uporabe koji imate na umu.