Çfarë është RAG? Retrieval-Augmented Generation i shpjeguar thjesht

RAG (retrieval-augmented generation) është një mënyrë për ta bërë një model AI të përgjigjet pyetjeve duke përdorur informacionin tënd. Kur dikush bën një pyetje, aplikacioni yt kërkon së pari në dokumentet e tua pasazhet më përkatëse, pastaj ia jep ato pasazhe modelit së bashku me pyetjen. Modeli e shkruan përgjigjen nga ai tekst në vend që të mbështetet vetëm në atë që mësoi rastësisht gjatë trajnimit.

Pse ka rëndësi RAG kur ndërton me AI

Një model i madh gjuhësor di shumë gjëra të përgjithshme për botën, por asgjë për biznesin tënd: çmimet, politikat, manualin e produktit, biletat e mbështetjes të javës së kaluar. Ka gjithashtu një datë ndalimi të trajnimit, kështu që nuk di asgjë të re. Nëse e pyet, mund të prodhojë një përgjigje të sigurt, të besueshme por të gabuar.

Keni tre rrugë të gjera për ta zgjidhur këtë:

Modelet e sotme pranojnë prompt-e të gjata, kështu që për një FAQ të shkurtër opsioni i parë shpesh është i mjaftueshëm. RAG e meriton vendin kur ke më shumë tekst sesa do të dëshiroje ta dërgosh çdo herë — sepse çdo fjalë që dërgon kushton para dhe kohë (shiko si faturojnë API-t e LLM).

Nëse po ndërton një veçori “bisedo me dokumentet tona”, një asistent mbështetjeje ose një mjet njohurish të brendshëm, pothuajse sigurisht po ndërton një formë RAG.

Një analogji e përditshme

Imagjino një provim me libër të hapur. Një student që duhet të përgjigjet nga memoria mund të gabojë ose të bluajë. Një student që lejohet të hapë faqet e duhura, t’i lexojë dhe pastaj të përgjigjet është shumë më i besueshëm — me kusht që të gjejë faqet e duhura.

• Studenti është modeli gjuhësor.
• Libri janë dokumentet e tua.
• Hapja e faqeve të duhura është kërkimi (retrieval).
• Shkrimi i përgjigjes nga ato faqe është gjenerimi.

RAG është versioni me libër të hapur. Dhe, si në provim, cilësia e përgjigjes varet shumë nga fakti nëse u gjetën faqet e duhura.

Si funksionon RAG, hap pas hapi

Një konfigurim tipik RAG ka dy faza.

Përgatitja e dokumenteve (bëhet paraprakisht):

1. Mblidh materialin burimor — artikuj ndihme, PDF-e, politika, të dhëna produktesh.
2. Ndaji në pjesë (chunk): ndaj dokumentet e gjata në copa më të vogla, shpesh disa paragrafë secila, që kërkimi të kthejë vetëm pjesën përkatëse.
3. Embed çdo pjesë: dërgoje te një model embedding-u, që e shndërron tekstin në një embedding — një listë e gjatë numrash që kap kuptimin e tij. Tekstet për gjëra të ngjashme marrin numra të ngjashëm.
4. Ruaj pjesët dhe embedding-et e tyre në një bazë të dhënash që mund të kërkojë sipas ngjashmërisë (shpesh quhet bazë vektoriale ose indeks vektorial).

Përgjigjja e një pyetjeje (bëhet çdo herë):

1. Embed pyetjen me të njëjtin model embedding-u.
2. Rikthe pjesët me embedding-un më të afërt me atë të pyetjes — p.sh. pesë më të mirat.
3. Ndërto prompt-in: udhëzimet, pjesët e rikthyera dhe pyetjen.
4. Gjenero: modeli gjuhësor shkruan një përgjigje bazuar në ato pjesë, më mirë duke treguar cilat përdori.

Kërkimi sipas kuptimit është ajo që e bën këtë të funksionojë: një pyetje si “si ta marr përsëri paratë” mund të gjejë një pjesë me titull “Politika e rimbursimit” edhe pse nuk kanë asnjë fjalë të përbashkët.

Një shembull i punuar: asistenti i një palestre

Të themi se një palestër ka 40 artikuj ndihme dhe dëshiron një asistent chat në faqen e saj. Një anëtar pyet: "A mund ta pezull anëtarësimin kur jam duke udhëtuar?"

Aplikacioni embed-on pyetjen dhe rikthen tre pjesët më të afërta. Njëra prej tyre thotë:

Pezullimi i anëtarësimit: Anëtarët me plan mujor mund ta pezullojnë
anëtarësimin deri në 2 muaj në vit. Kërkojeni te recepsioni ose në
aplikacion të paktën 7 ditë përpara fillimit të pezullimit.

Prompt-i që i dërgohet modelit më pas duket diçka si kjo:

Je asistenti i ndihmës për Northside Gym.
Përgjigju vetëm nga burimet më poshtë. Nëse përgjigjja nuk gjendet në to,
thuaj që nuk e di dhe sugjero të kontaktojë recepsionin.
Përmend cilin burim përdore.

[Burimi 1: Pezullimi i anëtarësimit] Anëtarët me plan mujor mund të pezullojnë...
[Burimi 2: Anulimi i anëtarësimit] ...
[Burimi 3: Kalimet për mysafirë] ...

Pyetja: A mund ta pezull anëtarësimin kur jam duke udhëtuar?

Dhe modeli përgjigjet: "Po — me plan mujor mund ta pezullosh anëtarësimin deri në dy muaj në vit. Kërkoje te recepsioni ose në aplikacion të paktën 7 ditë më parë (burimi: Pezullimi i anëtarësimit)."

Palestra nuk trajnoi asgjë. Kur ndryshon politikën e pezullimit, përditëson artikullin, aplikacioni ri-embed-on atë pjesë dhe përgjigjja e radhës pasqyron ndryshimin.

Termat kryesorë

Keqkuptime të zakonshme

• “RAG e trajnon modelin me të dhënat e mia.” Jo. Asgjë në model nuk ndryshon; ai thjesht lexon tekst shtesë në momentin e pyetjes.
• “RAG do të thotë pa halucinacione.” Do të thotë më pak. Nëse kërkimi humbet pjesën e duhur, ose përgjigjja nuk gjendet në dokumentet e tua, modeli mund prapëseprapë të hamendësojë. Udhëzoje të thotë “nuk e di” dhe testoje me pyetje që i njeh përgjigjet.
• “Më duhet një bazë vektoriale e veçantë.” Shpesh nuk të duhet. Për sasi të moderuara të dhënash, një shtesë vektoriale në bazën që ke tashmë, ose edhe kërkim i thjeshtë me fjalë kyçe, mund të mjaftojë.
• “Pjesët më të mëdha janë më të mira.” Shumë të mëdha dhe dërgon tekst të panevojshëm (më shumë kosto, më shumë konfuzion); shumë të vogla dhe pjesa humbet kontekstin që e bënte kuptimplote. Pritet të rregullosh.
• “Thjesht ngarko gjithçka.” Dokumentet e vjetruara, të dyfishta ose kontradiktore prodhojnë përgjigje kontradiktore. Pastrimi i materialit burimor është shpesh përmirësimi më i madh që mund të bësh.
• “Kushdo mund të shohë çdo dokument.” Vetëm nëse e ndërton kështu. Nëse disa dokumente janë private për përdorues të caktuar, vetë kërkimi duhet të filtrojë sipas asaj që pyet — përndryshe asistenti mund të citojë të dhënat e një kliendi për një tjetër.

Sa kushton

Një veçori RAG ka zakonisht tre kosto të vazhdueshme: embedding-u i dokumenteve (e vogël dhe kryesisht një herë), embedding-u i secilës pyetje (shumë i vogël), dhe thirrja e modelit gjuhësor (kostoja kryesore, që rritet me numrin e pjesëve që dërgon). Plus depozitimi në bazën e të dhënave. Ofruesi yt i AI i faturon këto në llogarinë tënde, ndaj vendos një kufi shpenzimesh atje.

Çfarë t’i kërkosh ndërtuesit tënd të AI-së

• “Para se të ndërtosh RAG, kontrollo: a është përmbajtja jonë mjaft e vogël që të përfshihet thjesht në prompt?”
• “Ndaji artikujt e ndihmës në pjesë me disa paragrafë, mbaj titullin dhe lidhjen e burimit të secilës pjesë, dhe ruaj embedding-et në bazën tonë të të dhënave.”
• “Përdor kërkim hibrid — sipas kuptimit dhe me fjalë kyçe — që kodet e produkteve të përputhen gjithsesi.”
• “Thuaji modelit të përgjigjet vetëm nga burimet e rikthyera, të thotë kur nuk di, dhe të shfaqë burimet nën çdo përgjigje.”
• “Kërko vetëm në dokumentet që përdoruesi i kyçur ka leje t’i shohë.”
• “Ri-embed një dokument automatikisht sa herë që përditësohet.”
• “Mbaje çelësin e ofruesit të AI në server, në një sekret, kurrë në shfletues.”
• “Regjistro çdo pyetje, pjesët e rikthyera dhe përgjigjen, që të mund të rishikoj përgjigjet e këqija.”

RAG në Mythex

Mythex nuk përfshin një produkt gati për bazën e njohurive ose RAG. Ajo që bën është të shkruajë kodin për një të tillë brenda aplikacionit tënd: sjell dokumentet dhe çelësin tënd të ofruesit të AI, të ruajtur si sekret projekti, dhe agjenti ndërton pjesët e kërkimit dhe të chat-it, duke përdorur bazën e të dhënave Postgres të projektit për depozitim. Përdorimi i ofruesit faturohet në llogarinë e tij, jo në kredite Mythex. Dokumentacioni sugjeron të nisësh me një veçori të thjeshtë AI dhe të shtosh RAG kur ajo funksionon — shiko ndërtimin e një aplikacioni me AI, dhe udhëzuesit tanë për ndërtimin e një aplikacioni chatbot me AI dhe shtimin e veçorive AI.

Pyetje