RAG vs fine-tuning: kaj podjetja zares potrebujejo

Skoraj vsak AI projekt, o katerem se pogovarjamo z naročniki, se začne z istim vprašanjem: „Ali naj model s fine-tuningom naučimo na naših podatkih?“ Včasih je odgovor da. Pogosteje pa je resnična potreba nekaj drugega: asistent, ki pozna vaše aktualne dokumente, navaja svoje vire in ga je mogoče posodobiti v torek popoldne brez učnega cikla. V tem članku v preprostem jeziku razložimo glavne možnosti, kdaj je katera primerna in kako se odločiti, ne da bi mesece zapravili za napačen pristop.

Štiri orodja v zaboju#

Ko ljudje rečejo „naučimo model o našem poslovanju“, običajno mislijo na eno od štirih različnih tehnik. Rešujejo različne probleme in jih je mogoče kombinirati.

Generiranje, podprto z iskanjem (RAG)#

RAG (retrieval-augmented generation) modela ne spreminja. Namesto tega sistem ob vsakem vprašanju najprej preišče vašo lastno vsebino, na primer priročnike, pogodbe, zahtevke ali katalog izdelkov, in najustreznejše odlomke skupaj z vprašanjem preda modelu. Model nato odgovori na podlagi teh odlomkov.

Tu so pomembne tri zamisli:

• Iskanje (retrieval): najti prave odlomke. Običajno gre za kombinacijo semantičnega iskanja po embeddingih in klasičnega iskanja po ključnih besedah, ki ji pogosto sledi korak ponovnega razvrščanja (reranking).
• Opiranje na vire (grounding): modelu naročimo, naj odgovarja iz predloženega gradiva in naj pove, kadar gradivo odgovora ne vsebuje.
• Navedbe virov: kažejo na točen dokument, stran ali odlomek, iz katerega odgovor izhaja, da ga človek lahko preveri.

RAG se izkaže, kadar se znanje pogosto spreminja, kadar je korpus velik in kadar morajo ljudje odgovore preverjati.

Fine-tuning#

Fine-tuning nadaljuje učenje modela na vaših primerih, tako da se njegovo vedenje premakne. Dober je za učenje tega, kako odgovarjati: dosleden ton, strog izhodni format, področju prilagojena klasifikacijska shema ali ozka naloga, ki se izvede tisočkrat na dan. Slab pa je za učenje tega, kaj je ta trenutek res. Dejstva, naučena s fine-tuningom, je težko posodobiti, težko jim je slediti do vira, model pa jih lahko pomeša ali si jih zapomni narobe.

Fine-tuning omogoča tudi, da ozko nalogo prenesete na manjši, cenejši in hitrejši model, kar je pri velikem obsegu lahko zelo pomembno.

Dolg kontekst s prompt cachingom#

Sodobni modeli podjetij Anthropic in OpenAI ter več odprtokodnih družin sprejemajo zelo dolge vnose. Če je vaša baza znanja zmerno velika, na primer priročnik za izdelek, zbirka pravilnikov ali nabor pogostih vprašanj, jo lahko pogosto v celoti vstavite neposredno v prompt. Brez indeksa, brez iskalnega cevovoda, brez odločitev o razrezu na odseke.

Očiten ugovor sta strošek in latenca: pošiljanje istega velikega dokumenta z vsako zahtevo je potratno. To rešuje prompt caching. Ponudniki lahko stabilno predpono prompta predpomnijo, zato ponovljene zahteve znova uporabijo že obdelano vsebino ter so obračunane in postrežene učinkoviteje. Za stabilen, omejen obseg znanja je dolg kontekst s predpomnjenjem pogosto najpreprostejša rešitev, ki deluje.

Strukturirani izhodi#

Številni „AI“ projekti so v resnici projekti zajema podatkov: preberi račun, življenjepis, pogodbo ali e-sporočilo in vrni čista polja. Tu je ključna zmožnost strukturiranih izhodov (structured outputs), pri katerih je model omejen na vračanje podatkov, skladnih s shemo, ki jo določite sami, na primer JSON z določenimi polji in tipi. Pri tem sploh ne gre za znanje. Gre za zanesljivost formata, ki pri nalogah zajema podatkov običajno odpravi potrebo po fine-tuningu.

Kdaj je kateri pristop primeren#

Koristen način razmišljanja: ločite znanje od vedenja.

• Sveže ali spremenljivo znanje in odgovori, ki jih morajo ljudje preveriti: uporabite RAG ali dolg kontekst, če je gradiva dovolj malo. Oba omogočata, da znanje posodobite s posodobitvijo dokumentov, in oba podpirata navedbe virov.
• Stabilno, omejeno znanje, ki gre v kontekstno okno: začnite z dolgim kontekstom in prompt cachingom. Na RAG preidite, ko ga gradivo preraste ali ko potrebujete natančen nadzor dostopa za vsak dokument posebej.
• Dosleden slog, ton ali format pri številnih izhodih: najprej poskusite z jasnimi navodili in nekaj dobrimi primeri v promptu. Če to pri vašem obsegu ni dovolj, je fine-tuning legitimna možnost.
• Ozka klasifikacija ali usmerjanje v velikem obsegu: fine-tuning manjšega modela ali preprosto uporaba manjšega splošnega modela z dobro zasnovanim promptom je pogosto najbolj ekonomična pot.
• Zajem polj iz dokumentov: strukturirani izhodi, po želji v kombinaciji z dokumentnimi vnosi in navedbami virov, da je mogoče slediti vsaki izluščeni vrednosti.

Možnosti se med seboj ne izključujejo. Zrel sistem lahko za znanje uporablja RAG, za format odgovora strukturirane izhode, za usmerjanje dohodnih zahtev pa majhen model s fine-tuningom.

Primerjava drug ob drugem#

Praktični kontrolni seznam za odločanje#

Preden izberete arhitekturo, si iskreno odgovorite na ta vprašanja:

1. Kaj natančno je naloga? Odgovarjanje na vprašanja, priprava besedil, klasifikacija ali zajem podatkov? Zapišite pet resničnih primerov vnosa in idealnega izhoda.
2. Kako pogosto se spreminja znanje v ozadju? Dnevne ali tedenske spremembe močno govorijo proti fine-tuningu.
3. Ali morajo uporabniki odgovore preverjati? Na področjih prava, financ, skladnosti, podpore ali zdravstva o navedbah virov običajno ni pogajanj.
4. Kako velika je baza znanja? Če gre udobno v kontekstno okno, najprej poskusite dolg kontekst s cachingom.
5. Kdo sme kaj videti? Če imajo različni uporabniki dostop do različnih dokumentov, potrebujete iskanje s filtriranjem po dovoljenjih, ne pa enega skupnega prompta ali modela, naučenega na vsem.
6. Kakšen obseg in latenco pričakujete? Velik obseg pri ozki nalogi je tisto, kjer manjši modeli ali modeli s fine-tuningom upravičijo svojo ceno.
7. Ali imate označene primere? Fine-tuning brez obsežnega nabora dobrih primerov le redko premaga dobro napisan prompt.
8. Kako boste merili uspeh? Če na to ne znate odgovoriti, se ustavite in najprej zgradite evalvacijski nabor.

Če večina odgovorov kaže na „spremenljivo znanje, potrebne navedbe virov, zmeren obseg“, potrebujete RAG ali dolg kontekst. Če kažejo na „stabilna naloga, strog format, zelo velik obseg“, razmislite o fine-tuningu ali manjšem modelu.

Pogoste pasti#

To so težave, ki jih najpogosteje vidimo, ko pregledujemo AI sisteme, ki „skoraj delujejo“.

• Slab razrez na odseke (chunking). Razrez dokumentov na poljubne kose fiksne velikosti prepolovi tabele, loči naslove od njihove vsebine in izgubi kontekst. Režite po strukturi dokumenta in ohranite uporabne metapodatke, kot so naslov, razdelek in datum.
• Brez evalvacij. Brez testnega nabora je vsaka sprememba ugibanje. Ekipe pilijo prompte, menjajo modele in spreminjajo velikost odsekov, ne da bi vedele, ali je postalo bolje ali slabše.
• Zastareli indeksi. Izvorni dokumenti so bili posodobljeni, indeks pa ne. Asistent samozavestno navaja lanski pravilnik. Ponovno indeksiranje mora biti del procesa dela z vsebino, ne ročen naknadni opravek.
• Halucinacije brez navedb virov. Če sistem ne pokaže, od kod odgovor izvira, uporabniki ne morejo ločiti odgovora, oprtega na vire, od izmišljenega. Zahtevajte navedbe virov in model naučite reči „ne vem“, kadar viri molčijo.
• Zasebnost in GDPR. Osebni podatki v dokumentih, promptih in dnevnikih so še vedno osebni podatki. Vedeti morate, kateri ponudnik jih obdeluje, v kateri regiji, po kateri pogodbi o obdelavi osebnih podatkov in kako dolgo se dnevniki hranijo. Fine-tuning na osebnih podatkih zahteva posebno previdnost, saj jih je pozneje težko odstraniti.
• Prompt injection iz dokumentov. Najdena vsebina je vnos, ki mu ne gre zaupati. Dokument lahko vsebuje besedilo, ki poskuša modelu dajati navodila, na primer naj prezre svoja pravila ali razkrije druge podatke. Najdeno besedilo obravnavajte kot podatke, omejite, kaj model lahko počne z orodji, in nikoli ne dovolite, da bi vsebina dokumenta podeljevala dovoljenja.

Najprej evalvirajte, nato optimizirajte#

Najdragocenejši korak v vsakem AI projektu je hkrati najmanj bleščeč: zgradite evalvacijski nabor, preden izberete arhitekturo.

Dober začetni nabor je preprosto nekaj deset do nekaj sto resničnih vprašanj ali vnosov, vsak s pričakovanim odgovorom ali dokumenti, ki naj bodo navedeni. Nato merite:

• Kakovost iskanja: je sistem našel prave odlomke?
• Kakovost odgovora: je odgovor pravilen, popoln in oprt na vire?
• Točnost navedb: ali navedeni odlomki trditev dejansko podpirajo?
• Vedenje pri zavrnitvah: ali reče „ne vem“, kadar bi moral?
• Skladnost formata: ali se pri zajemu podatkov vsak izhod ujema s shemo?

Ko je to vzpostavljeno, primerjave postanejo stvar dejstev. Dolg kontekst lahko primerjate z RAG, en model z drugim ali model s fine-tuningom z modelom, vodenim samo s promptom, in to na svojih podatkih, ne na splošnih primerjalnih testih. Pogosto boste ugotovili, da je najcenejši popravek boljše iskanje ali jasnejši prompt, ne pa večji model ali učni cikel.

Samodejno ocenjevanje z modelom lahko to pospeši, vendar ga vzorčno preverjajte s človeškimi pregledovalci, zlasti na začetku.

Kako te vzorce ponazarjajo naši demo primeri#

Trudimo se delati to, kar priporočamo, in dva demo primera na tej strani pokažeta vzorca v praksi.

sigmacode Assistant odgovarja na vprašanja o naših storitvah in pristopu. Njegova baza znanja je majhna in namenoma zamrznjena, zato namesto iskalnega cevovoda uporablja dolg kontekst s prompt cachingom: celotna baza znanja je v predpomnjeni predponi prompta, modelu pa je naročeno, naj odgovarja samo iz nje. Za omejen obseg znanja je to preprosteje zgraditi in laže ohranjati pravilno kot vektorski indeks.

Demo primer Vprašanja o dokumentih z navedbo virov pokaže drugo plat. Priskrbite dokument, postavljate vprašanja, vsak odgovor pa pride z navedbami, ki kažejo na odlomke, na katere se je oprl. To je osrednja obljuba AI, oprtega na vire: vsako trditev je mogoče preveriti ob njenem viru.

Noben od demo primerov ni potreboval fine-tuninga. To je značilno. Pri večini poslovnih problemov, povezanih z znanjem, sta opiranje na vire in dobra evalvacija pomembnejša od učenja po meri.

Na kratko#

• RAG uporabite, kadar je znanja veliko, se pogosto spreminja, potrebuje nadzor dostopa ali ga je treba navajati z viri.
• Dolg kontekst s prompt cachingom uporabite, kadar je znanje stabilno in gre v okno.
• Fine-tuning ali manjše modele uporabite za dosledno vedenje ali ozke naloge v velikem obsegu, ne za dejstva.
• Strukturirane izhode uporabite za zajem podatkov in vsak izhod, ki ga mora razčleniti sistem.
• Najprej evalvirajte, nato optimizirajte tisto, na kar pokažejo številke.

Če te možnosti tehtate za resničen projekt, vam naša ekipa za AI in avtomatizacijo, ki jo vodi tehnični vodja z več kot 20 leti izkušenj, lahko pomaga opredeliti obseg, zgraditi evalvacijski nabor in dostaviti prvo različico, ki jo lahko dejansko merite. Pišite nam in povejte, kaj poskušate rešiti.