RAG je postao podrazumevani potez u svakom razgovoru u kome se kaže „želimo da AI poznaje naše stvari". Ali je pogrešan potez u otprilike polovini slučajeva. Rešenje retko je bolji embedding. Posezanje za drugim alatom jeste.
Ovo je kratka beleška o četiri situacije u kojima treba prestati da se poseže za RAG-om, i šta koristiti umesto toga.
01. Kada je odgovor broj, ne pasus
Ako je pitanje na koje agent treba da odgovori suštinski SQL upit — koliko smo ovih isporučili prošlog meseca, i kakva je bila prosečna marža? — RAG je pogrešan oblik. Ne preuzimate prozu; agregirate strukturirane podatke. Stavljanje vektorske baze ispred ovoga je, skoro uvek, dug put do gore verzije SELECT izjave.
Pravi alat je text-to-SQL, na vašem postojećem skladištu podataka. Moderni frontijer modeli to rade dovoljno dobro da je okolni posao opis šeme, kontrola pristupa i evaluacioni skup. Preuzimanje se dešava — ali se dešava nad tabelama, ne nad delovima.
02. Kada je korpus mali i stabilan
Ako se cela baza znanja udobno smesti u kontekst modela — recimo, sto strana operativne politike koja se ne menja sedmično — odgovor je da se uopšte ne preuzima. Stavite dokument u prompt. Kešujte ga. Gotovo.
Ovo zvuči previše jednostavno da bi bila prava preporuka. To je prava preporuka. Vektorske baze imaju fiksni trošak — operativno, u inferenciji, u inženjeringu koji morate da uradite da bi bile sveže — koji ne plaćate ako modelu jednostavno možete predati ceo dokument. Više od jednog produkcionog RAG sistema zamenjeno je sa tri linije koda za keširanje prompta.
Polovina projekata „dodajmo RAG" trebalo je da budu „samo stavimo dokument u kontekst i kešujmo ga". — radna beleška
03. Kada pitanje zahteva zaključivanje, ne pretragu
Ako je posao agenta da misli o nečemu — da poredi, planira, sastavlja — dodavanje preuzimanja često čini odgovor lošijim. Model troši deo svog budžeta na sumiranje preuzetih delova umesto na zaključivanje, a sami delovi često nisu ni od značaja.
Pravi potez je da držite obim preuzimanja uskim — samo dokumenti koji zaista usidruju pitanje — i da ostavite modelu prostora da zaključuje. Ponekad je pravi odgovor da se ne preuzima ništa i da se oslonite na sopstveno znanje modela, posebno za pitanja o širokim, opštepoznatim pojmovima. RAG je za uzemljenje. Zaključivanje traži prostor, ne više uzemljenja.
04. Kada se podaci menjaju brže nego indeks
Preuzimanje radi kada je indeks, uglavnom, ažuran. Kada se osnovni podaci menjaju brže nego što vaš indeksacioni pipeline može da prati — cene, zalihe, stanje klijenta u realnom vremenu — RAG proizvodi samouvereno zastarele odgovore. Model nema načina da zna da je deo koji je upravo preuzeo star dva sata.
Pravi potez ovde je function calling: dajte modelu alat koji upituje izvor istine u trenutku zahteva. Agent pita API, dobija trenutno stanje, i odgovara. Granica se pomera sa „preuzmi, pa generiši" na „pretraži, pa generiši", i odgovori su tačni na način na koji indeks ne bi mogao da ih učini.
Kada jeste RAG pravi izbor
Da budemo uravnoteženi: RAG je tačan odgovor kada je korpus velik, podaci su uglavnom tekstualni, pitanja su otvorena, i odgovor treba da citira ili navodi izvorni materijal. Pomoćnici za znanje nad korpusom dokumentacije, agenti podrške nad bazom pomoći, interno pitanje-i-odgovor preko godina politika — to su kanonski slučajevi, i stvarni su.
Greška nije korišćenje RAG-a. Greška je posezanje za njim pre nego što se zapita koja od četiri prethodna uslova može da važi.
Kratko zatvaranje
RAG je korisna tehnika. Nije odgovor na „želimo da AI poznaje naše stvari". Odgovor je na jedan specifičan oblik tog pitanja — a postoje bar tri druga oblika, svaki sa boljim alatom. Birajte promišljeno. Agent koji nastane biće jeftiniji za pokretanje, brži za odgovor, i lakše branjiv kada pitanje postane teže.
