Definisanje obima 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 kome se zasniva bio nepotpun ili zastareo, zato što su se prava pristupa rešavala naknadno ili zato što nije postojao način da se utvrdi da li je neka promena stvari poboljšala ili pogoršala. Izbor modela je važan, ali je obično jedna od lakših odluka.

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

1. Slučaj upotrebe i kriterijumi uspeha#

Zapišite ovo pre nego što iko otvori notebook ili počne da poredi modele.

• Jedan glavni zadatak. Imenujte jedan zadatak koji asistent prvo mora dobro da obavlja, na primer odgovaranje na pitanja o proizvodima za tim podrške ili pronalaženje klauzula u ugovorima sa dobavljačima. Dalji slučajevi upotrebe mogu da dođu kada se prvi izmeri; mešanje više njih na početku zamagljuje i zahteve i evaluaciju.
• Korisnici i njihov kontekst. Opišite ko postavlja pitanja, koliko često, na kom jeziku i na kom uređaju i šta radi sa odgovorom. Internom stručnjaku koji proverava izvore potrebno je nešto drugo nego klijentu koji na osnovu odgovora direktno postupa.
• Stvarna pitanja sa idealnim odgovorima. Prikupite 20–50 stvarnih pitanja iz tiketa, mejlova ili razgovora u četu i neka stručnjak za oblast napiše idealan odgovor i navede izvor iz kog bi trebalo da potiče. Taj skup definiše šta znači „dobro” i postaje osnova vašeg evaluacionog skupa.
• Van obima i odbijanja. Navedite šta asistent ne sme da radi: da daje pravne, medicinske ili finansijske savete, da odgovara van svojih izvora, da preuzima obaveze u ime kompanije. Odlučite šta će umesto toga reći i kuda će uputiti korisnika.
• Polazna vrednost trenutnog procesa. Zabeležite kako se posao danas obavlja, koliko traje, ko ga radi i koliko košta. Bez polazne vrednosti tvrdnja „asistent pomaže” jeste 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 trebalo da koristi: vikije, foldere u SharePointu ili Google Driveu, sisteme za tikete, baze podataka, PDF-ove, veb-sajtove. Za svaki zabeležite kako mu se pristupa (API, izvoz, crawling) i da li je taj pristup dozvoljen.
• Formati i kvalitet dokumenata. Proverite da li postoje skenirani PDF-ovi kojima je potreban OCR, složene tabele, obrasci, prezentacije i slike sa bitnim sadržajem. Tabele i skenovi su mesta na kojima jednostavni pipeline-ovi gube najviše informacija, pa ih rano proverite na uzorku.
• Vlasništvo i ažurnost. Za svaki izvor imenujte odgovornu osobu i zabeležite koliko se često menja. Ako sadržaj nema vlasnika, niko neće ispraviti pogrešne odgovore koji iz njega proističu.
• Duplikati, verzije i jezici. Pronađite zastarele kopije, nacrte i paralelne verzije iste politike i odlučite koja je merodavna. Zabeležite jezike dokumenata i pitanja, jer se pretraga preko više jezika mora izričito testirati.

3. Kontrola pristupa i privatnost#

Rešite ovo pre nego što stvarni podaci napuste vaše sisteme.

• Prava pristupa u pretrazi. Ako korisnici smeju da vide samo određene dokumente, pretraga mora da filtrira prema pravima korisnika koji postavlja pitanje, sinhronizovanim iz izvornih sistema. Uputstva u promptu ili oslanjanje na to da će model prećutati sadržaj nisu kontrola pristupa.
• Podaci o ličnosti i pravni osnov. Utvrdite podatke o ličnosti u dokumentima, pitanjima i logovima i dokumentujte pravni osnov i svrhu obrade prema GDPR-u i domaćim propisima koji se primenjuju. Uključite lice za zaštitu podataka o ličnosti na početku, a ne pri pokretanju.
• Ugovor sa pružaocem i lokacija podataka. Zaključite ugovor o obradi podataka sa svakim pružaocem modela i infrastrukture, proverite njihove podobrađivače i potvrdite da obrada može da ostane u regionu EU ako vam je to potrebno. Zatražite pisanu potvrdu da se vaši podaci ne koriste za treniranje modela pružaoca.
• Čuvanje, logovanje i redakcija. Odlučite koliko dugo se čuvaju promptovi, preuzeti odlomci i odgovori, ko sme da ih čita i da li se podaci o ličnosti uklanjaju pre logovanja. Logovi su potrebni za otklanjanje grešaka i evaluaciju, pa je cilj kontrolisano čuvanje, 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 sa prompt cachingom može u potpunosti da zameni pretragu (vidi RAG ili fine-tuning).

• Chunking prema strukturi dokumenta. Delite sadržaj po naslovima, odeljcima, stavkama liste i granicama tabela, a ne po fiksnom broju karaktera. Uz svaki chunk zadržite putanju naslova kako bi odlomak imao smisla i sam za sebe.
• Metapodaci i filteri. Uz svaki chunk sačuvajte naslov, izvor, odeljak, datum, jezik, verziju i grupe pristupa. Metapodaci omogućavaju filtriranje prema pravima, pravila poput „samo najnovija verzija” i korisne citate.
• Hibridna pretraga i reranking. Kombinujte pretragu po ključnim rečima za tačne pojmove poput šifara proizvoda, brojeva artikala i imena sa vektorskom pretragom preko embedinga za značenje, a zatim zajedničke kandidate ponovo rangirajte (reranking). Svaki korak testirajte na svojim primerima pitanja umesto da pretpostavite da su podrazumevana podešavanja dovoljno dobra.
• Obavezni citati. Zahtevajte da asistent citira odlomke koje je koristio, sa linkom na izvorni dokument i odeljak. Citati korisnicima omogućavaju proveru odgovora, a recenzentima pokazuju da li je pogrešan odgovor nastao zbog loše pretrage ili loše generacije.

5. Izbor modela i pružaoca#

Model izaberite kada imate evaluacioni skup, kako bi se odluka zasnivala na vašim podacima, a ne na opštim benchmarkovima.

• Način hostovanja. Uporedite hostovani API, iste ili slične modele u cloud regionu EU i open-weight model koji sami hostujete na sopstvenoj infrastrukturi. Svaka opcija menja ravnotežu između kvaliteta odgovora, kontrole nad podacima, operativnog napora i troška.
• Latencija i trošak po upitu. Izmerite ukupno vreme odziva i trošak po odgovorenom pitanju na sopstvenim primerima pitanja, uključujući pretragu, reranking i ulazne i izlazne tokene. Prompt caching i manji modeli za jednostavne korake mogu znatno da promene te brojke.
• Rezervna opcija i vezanost za dobavljača. Isplanirajte šta se dešava kada pružalac ne radi ili povuče model: drugi pružalac, ograničeni režim rada ili jasna poruka o grešci. Promptove, evaluacioni skup i sloj pretrage držite nezavisnim od pružaoca, tako da je promena pitanje konfiguracije i jednog eval pokretanja, a ne ponovnog razvoja.

6. Evaluacija#

Ako ne možete da merite kvalitet, ne možete ni da ga poboljšate ni da odbranite odluku o puštanju u rad.

• Eval skup pre izrade. Pretvorite stvarna pitanja iz odeljka 1 u verzionisani evaluacioni skup sa očekivanim odgovorima i očekivanim izvorima i proširite ga teškim i graničnim slučajevima. Napravite ga pre prvog prototipa, a ne posle prvog demoa.
• Kvalitet pretrage i odgovora. Zasebno merite da li su preuzeti pravi odlomci i da li je odgovor tačan, potpun i veran tim odlomcima. Proverite tačnost citata: citirani odlomak mora zaista da potkrepljuje tvrdnju.
• Testovi odbijanja i prompt injectiona. Uključite pitanja koja asistent mora da odbije i pitanja na koja njegovi izvori ne daju odgovor i proverite da on to i kaže umesto da nagađa. Dodajte dokumente i unose koji pokušavaju da zaobiđu njegova uputstva ili izvuku podatke drugih korisnika i potvrdite da ne uspevaju.
• Regresiona pokretanja i ljudska provera. Pokrenite ceo eval skup pri svakoj promeni promptova, modela, chunkinga ili podataka i uporedite rezultate sa prethodnim pokretanjem. Automatsko ocenjivanje pomoću modela to ubrzava, ali bi stručnjak za oblast trebalo redovno da proverava uzorke rezultata.

7. Integracija i rad#

Asistent mora negde da živi, a neko mora da ga vodi i posle pokretanja.

• Kanal i prijava. Odlučite gde će asistent biti dostupan: kao vidžet na veb-sajtu, 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 sa istog mesta kao i svuda drugde.
• Predaja čoveku i povratne informacije. Definišite kako korisnik dolazi do osobe kada mu asistent ne može pomoći, uz prenos dotadašnjeg razgovora. Dodajte jednostavne dugmiće za povratnu informaciju i negativne povratne informacije usmerite u evaluacioni skup.
• Model troškova i nadzor. Procenite trošak po upitu i mesečno pri očekivanom i vršnom opterećenju i podesite upozorenja za budžet. Pratite latenciju, stopu grešaka, stopu odbijanja i povratne informacije korisnika, uz logove redigovane kako je dogovoreno u odeljku 3.
• Ponovno indeksiranje, vlasništvo nad sadržajem i incidenti. Automatizujte ponovno indeksiranje pri promeni 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šćeno otkrivenih odgovora, uključujući brzo isključivanje asistenta.

8. Kriterijumi za odluku go/no-go#

Dogovorite pravila odlučivanja pre nego što stignu rezultati, kako odluka ne bi zavisila od utiska sa uspešnog demoa.

• Unapred dogovoreni pragovi. Zapišite minimalne nivoe tačnosti odgovora i tačnosti citata na eval skupu, prihvatljivu latenciju i trošak po upitu i nultu toleranciju za odgovore koji prelaze granice prava pristupa. Uporedite rezultate sa polaznom vrednošću iz odeljka 1.
• Vremenski ograničen pilot sa jasnim izlazom. Sprovedite pilot sa malom grupom stvarnih korisnika tokom unapred određenog perioda, uz imenovanu osobu koja donosi odluku. Sužavanje obima ili odustajanje jeste legitiman ishod i znatno je jeftinije od saznanja posle punog uvođenja.

Kako možemo da pomognemo#

Ako ovu listu želite da prođete zajedno sa nama, najdirektniji put je naš AI Proof-of-Value Sprint sa fiksnim obimom. Za dve nedelje sa vama definišemo slučaj upotrebe, pravimo RAG ili agentski prototip na vašim sopstvenim podacima, sastavljamo evaluacioni skup, pripremamo model troškova i isporučujemo go/no-go izveštaj koji možete da predstavite donosiocima odluka. Detalji su na stranici sa cenama i među našim uslugama AI i automatizacije.

Pre nego što ijedan vaš dokument stigne do modela, sa vama dogovaramo način postupanja sa podacima; unapred možete da pročitate kako postupamo sa podacima klijenata u AI projektima. Ako radije želite da počnete razgovorom, zatražite besplatnu procenu i opišite slučaj upotrebe koji imate na umu.