Kako izraditi RAG chatbot koji radi u praksi

Ovaj vodič je za timove koji imaju RAG chatbot koji radi na laptopu, a trebaju ga za cijelu organizaciju. RAG (retrieval-augmented generation) odgovara na pitanja iz vaših dokumenata: pronađe relevantne odlomke, preda ih jezičkom modelu i traži odgovor zasnovan na njima. Prva verzija koja odgovara na nekoliko pitanja nastane za jedno popodne. Verzija koja sedmično odgovara na hiljade pitanja, iz dokumenata koji se mijenjaju i za korisnike s različitim pravima pristupa, traži ozbiljan inženjerski rad.

U stvarnoj upotrebi RAG chatbot mora:

• Pronaći pravi odlomak za pitanje, uključujući tačne pojmove kao što su šifre proizvoda, brojevi članova i imena.
• Navesti izvore, da korisnik može provjeriti odgovor za nekoliko sekundi.
• Poštovati prava pristupa, da niko ne vidi odgovor sastavljen iz dokumenta koji sam ne može otvoriti.
• Reći kada ne zna, umjesto da praznine popuni tekstom koji samo zvuči uvjerljivo.
• Ostati mjerljivo dobar dok se dokumenti, prompti i modeli mijenjaju.

U nastavku prolazimo kroz svaki sloj, redom kojim ih izrađujemo.

Pretraga može vratiti samo ono što je unos dokumenata (ingestion) izvukao. PDF-ovi s tekstom u dvije kolone, skenirane stranice, tabele koje se prelamaju preko više stranica i zaglavlja ponovljena na svakoj stranici postaju neuredan tekst kada ih provučete kroz običan alat za izvlačenje teksta. Model tada odgovara iz fragmenata, a to ne popravlja nikakav rad na promptu.

Dobar proces unosa dokumenata dobro radi četiri stvari:

1. 01Parsira prema vrsti dokumenta. Za PDF-ove koristite parsiranje koje razumije raspored stranice, strukturu tabela sačuvajte kao Markdown ili HTML, a OCR ili vision model pokrećite samo na stranicama kojima to treba.
2. 02Uklanja ponavljajući sadržaj. Izbacite ponovljena zaglavlja, podnožja, brojeve stranica i pravne napomene koje bi se inače poklapale sa svakim upitom.
3. 03Čuva metapodatke. Zapišite URI izvora, naslov, putanju sekcije, verziju, datum, jezik i grupe koje smiju čitati dokument.
4. 04Sinhronizuje samo izmjene. Izračunajte hash svakog dokumenta, ponovo indeksirajte samo ono što se promijenilo i obrišite dijelove teksta kada se obriše izvor. Zastarjeli dijelovi česti su uzrok samouvjerenih pogrešnih odgovora.

Unos dokumenata tretirajte kao proces s logovima i ponovnim pokušajima, koji se pokreće po rasporedu ili na događaje o izmjenama iz izvornog sistema. Za neuredne ulaze kao što su fakture i obrasci pogledajte naš vodič o parsiranju dokumenata uz LLM.

Chunking određuje kako izgleda jedna jedinica koju pretraga može pronaći, jedan dio teksta (chunk). Ako je dio premali, gubi kontekst koji mu daje smisao. Ako je prevelik, razvodnjava embedding (brojčani prikaz značenja teksta) i puni kontekstni prozor modela nevažnim tekstom.

Obično počinjemo s dijelovima prema strukturi, od otprilike 300 do 800 tokena. Svakom dodamo naslov i putanju sekcije i čuvamo pokazivač na sekciju kojoj pripada. Onda odluku prepuštamo skupu testova. Veličina dijela je parametar koji se mjeri, a postavka koja je najbolja za arhivu ugovora rijetko je najbolja i za bazu znanja korisničke podrške.

Vektorska pretraga je dobra u prepoznavanju značenja: pitanje o "ranijem raskidu ugovora" pronađe član s naslovom "raskid bez navođenja razloga". Slabija je na tačnim nizovima kao što su ISO 27001, broj člana ili šifra artikla (SKU). Pretraga po ključnim riječima s algoritmom BM25 ima suprotan profil. Hibridna pretraga pokreće obje i spaja rezultate, i zato je to naš standardni izbor za poslovne dokumente.

Ako su vaši podaci već u Postgresu, to možete uraditi s pgvector i ugrađenom full-text pretragom, a rezultate spojiti metodom reciprocal rank fusion (RRF). Rangiranje full-text pretrage u Postgresu po ideji je slično BM25. Gdje je tačno BM25 bodovanje važno, dodajte BM25 ekstenziju ili pretraživač uz bazu.

WITH semantic AS (
  SELECT id, row_number() OVER (ORDER BY embedding <=> $1) AS rank
  FROM chunks
  WHERE tenant_id = $2 AND access_groups && $4
  ORDER BY embedding <=> $1
  LIMIT 50
),
keyword AS (
  SELECT id, row_number() OVER (ORDER BY ts_rank_cd(tsv, q) DESC) AS rank
  FROM chunks, plainto_tsquery('english', $3) AS q
  WHERE tenant_id = $2 AND access_groups && $4 AND tsv @@ q
  ORDER BY ts_rank_cd(tsv, q) DESC
  LIMIT 50
)
SELECT c.id, c.content, c.source_uri,
       COALESCE(1.0 / (60 + s.rank), 0) + COALESCE(1.0 / (60 + k.rank), 0) AS score
FROM semantic s
FULL OUTER JOIN keyword k ON s.id = k.id
JOIN chunks c ON c.id = COALESCE(s.id, k.id)
ORDER BY score DESC
LIMIT 20;

Primijetite da filteri za tenanta (klijenta u sistemu) i prava pristupa stoje unutar obje pretrage. Filtriranje nakon pretrage može vam ostaviti premalo rezultata, a znači i da zaštićeni tekst prolazi kroz kod koji ga nikad ne bi smio vidjeti.

Reranker (model za ponovno rangiranje) zatim ocijeni prvih 20 do 50 kandidata u odnosu na pitanje, uz cross-encoder ili LLM, i zadrži najboljih pet do deset. Ponovno rangiranje je često najjeftinije veliko poboljšanje kvaliteta odgovora, uz nešto duže vrijeme odziva.

Tražite od modela da uz svaku tvrdnju navede ID dijela teksta, a zatim te izvore provjerite u kodu prije nego što odgovor stigne do korisnika:

• Svaki navedeni ID mora pripadati jednom od dijelova koje ste stvarno predali modelu.
• Citirani tekst mora postojati u navedenom dijelu, nakon normalizacije razmaka.
• Odgovor bez navedenih izvora zamjenjuje se jasnom porukom "Ovo nisam pronašao u dokumentima", a slučaj se bilježi za pregled.

Ove provjere su determinističke i jeftine, a hvataju velik dio izmišljenih referenci. Za dublje provjere da li izvori zaista potkrepljuju odgovor pogledajte kako evaluirati RAG.

Prava pristupa pripadaju pretrazi. Grupe pristupa zapišite na svaki dio teksta već pri unosu, držite ih usklađenim s izvornim sistemom i grupe korisnika proslijedite u svaku pretragu. Ne oslanjajte se na prompt da sakrije zaštićeni sadržaj.

RAG chatbot može pogriješiti na dva mjesta: pretraga ne pronađe pravi odlomak, ili model loše iskoristi odlomak koji je dobio. Mjerite oboje. Sastavite skup od 100 do 300 stvarnih pitanja s dokumentima koji na njih odgovaraju i pratite:

• Pretraga: recall@k i nDCG, koji pokazuju da li su pravi dijelovi teksta među prvim rezultatima.
• Odgovori: tačnost u odnosu na referentni odgovor, vjernost pronađenim izvorima i tačnost navedenih izvora.
• Odbijanja: da li chatbot odbija pitanja na koja dokumenti nemaju odgovor.
• Rad sistema: p95 vrijeme odziva i trošak po razgovoru.

Skup pokrenite pri svakoj promjeni chunkinga, prompta, modela ili rerankera i blokirajte nove verzije koje su lošije. Naš članak o LLM evaluacijama prije svake nove verzije detaljnije opisuje tu provjeru.

1. 01Prikupite 100 stvarnih pitanja od ljudi koji će koristiti chatbot, s dokumentima koji na njih odgovaraju.
2. 02Izradite unos dokumenata za dva ili tri najvažnija izvora, s metapodacima i pravima pristupa.
3. 03Počnite s dijelovima teksta prema strukturi i hibridnom pretragom, pa izmjerite recall@10.
4. 04Dodajte reranker i provjeru izvora, pa ponovo mjerite.
5. 05Skup testova stavite u CI prije nego što dodate nove izvore.
6. 06Pustite chatbot jednom timu, svake sedmice pregledajte uzorak razgovora i greške vraćajte u skup testova.

Ovim redom radimo kada izrađujemo RAG sisteme za klijente, od unosa dokumenata do rada u stvarnoj upotrebi. Naš RAG projekat za advokatsku kancelariju pokazuje rezultat, a kako radimo objašnjava kako vodimo ovakve projekte.