RAG üle tükkide: graafi-RAG, agentne RAG, pika-konteksti RAG

Kui sa oled klassikalise RAG süsteemi ehitanud, tead selle tugevusi: see leiab asjakohased tükid, LLM toodab maandatud vastused, jõudlus on mõistlik, kulud on prognoositavad. Enamiku teadmusbaasi päringute jaoks on see okei.

Aga mõned päringud lõhuvad klassikalist RAG-i. Mitme-hüppe küsimused ("Millised meie klientidest kasutavad funktsiooni X ja on viimase 6 kuu jooksul churninud?"). Suhete-rohked küsimused ("Kuidas meie hinnastik võrdleb konkurentide A, B ja C lõikes?"). Sünteesi-küsimused ("Tee kokkuvõte kõigest, mida me selle kliendi teekonnast teame"). Klassikaline tüki-põhine otsing ei komponeeri tükke hästi; LLM jätab tihti ilma kontekstist, mis on hajutatud paljudesse kohtadesse.

"Üle tükkide" lähenemised — graafi-RAG, agentne RAG, pika-konteksti RAG — tegelevad nende piiridega erinevatel viisidel. See artikkel käsitleb, mis kumbki on, millal kumb on õige tööriist, kuidas need tootmises päriselt töötavad ja milliseid vahetusi tasub kaaluda.

Tüki-põhise RAG-i piirid

Et mõista, mida me parandame, piirid:

Piir 1: Pole suhtestruktuuri. Tükid on iseseisvad ühikud. Fakt, et tükk A räägib kliendi X kontost ja tükk B räägib kaebusest, mille klient X esitas, läheb kaduma — need on lihtsalt kaks tükki vektoriruumis, leitakse (või mitte) sõltumatult.

Piir 2: Pole mitme-hüpet. "Kliendid, kes kasutavad funktsiooni X ja kaebasid Y kohta" nõuab kahe erineva allika info ühendamist hulgaloogikaga. Tüki-põhine otsing seda ei tee.

Piir 3: Piiratud süntees. "Tee kokkuvõte selle konto suhtest aja jooksul" peab kokku tooma palju tükke sidusas narratiivis. Tükid esitatakse fragmentidena; LLM peab tegema sünteesi iga kord nullist.

Piir 4: Fikseeritud-konveieri jäikus. Klassikaline RAG teeb alati: embedi päring → otsi K → genereeri. Keerulised päringud, mis vajavad iteratiivset otsingut või mitmesammulist arutlust, ei mahu sellesse konveierisse.

Piir 5: Konteksti lahjenemine. Top 5 tükki võivad sisaldada mõnda, mis vastab päringule, aga on teema-välised. LLM on sunnitud neist läbi rabelema; kvaliteet kannatab.

Variandid, mida arutame, tegelevad igaüks nende alamhulkadega.

Graafi-RAG

Idee: esita oma andmed teadmusgraafina. Olemid (inimesed, tooted, dokumendid, sündmused) on tipud; suhted on servad. Päringud läbivad graafi, mitte (või lisaks) ei tee vektorotsingut.

Millal graafi-RAG aitab

Suhetel põhinevad domeenid. Klient-konto-tehing-suhtlus struktuurid. Organisatsiooni hierarhiad. Toote taksonoomiad. Tsiteerimisvõrgustikud. Kõik, kus olemite-vahelised seosed loevad sama palju kui olemid ise.

Mitme-hüppe arutlus. "Kes on selle meeskonna juht, kes ostis Q3-s toote X?" nõuab hüpamist: toode → tehing → meeskond → juht. Graafi-RAG käsitleb seda loomulikult.

Agregeerimine. "Mitu klienti segmendis Y on integreerunud süsteemiga Z?" nõuab hulgaoperatsioone üle olemite. SQL teadmusgraafil lööb tekstiotsingu.

Viited ja seletused. Graafisuhted on selgesõnalised ja auditeritavad. LLM saab viidata "John on Team Acme juht [serv: juhib]", mitte "ma arvan, et John juhib Team Acme't konteksti põhjal."

Kuidas graafi-RAG päriselt töötab

Tüüpiline konveier:

1. Eraldamine. Ehita graaf oma andmetest. Kaks levinud lähenemist:

• Struktureeritud allikad (andmebaasid, struktureeritud API-d): impordi otse. Kliendid, tooted, tehingud on juba tabelites.
• Struktureerimata allikad (dokumendid, transkriptid, e-kirjad): kasuta LLM-i, et eraldada olemeid ja suhteid. "Sellest transkriptist eralda inimesed, organisatsioonid ja nende-vahelised suhted."

Väljund: tipud (tüüpide ja omadustega) ja servad (tüüpide ja omadustega).

2. Salvestus. Graafiandmebaas — Neo4j, Memgraph, kohandatud Postgres serva-tabelitega. Valik sõltub päringumustritest ja skaalast.

3. Täiendamine embeddingutega. Iga tipp saab ka tekstilise esituse ja embedingu. See võimaldab hübriidi: läbida graafi JA teha semantilist otsingut.

4. Päringu tegemine otsingu ajal. Kolm levinud mustrit:

• Ainult-graafi päring. LLM (või marsruutimise loogika) genereerib graafi päringu (Cypher, SQL). Käivita. Tagasta tulemused LLM-ile.
• Embedding-esmaselt, graafi-laiendus. Leia asjakohased olemid embedingu kaudu. Siis laiene nende naabriteni ja seotud olemiteni.
• Hübriid. Kombineeri vektorotsing + graafi läbimine ühes konveieris.

5. Vorminda LLM-ile. Graafi tulemused vormindatakse struktureeritud tekstina, mida LLM saab kasutada. Olemid oma omadustega; suhted selgesõnaliselt.

Konkreetne näide

SaaS-ettevõte kliendiandmetega. Olemid: kliendid, lepingud, tooted, tugipiletid, suhtlused, töötajad.

Klassikaline RAG lähenemine: tükelda kliendi-dokumendid, embedi, otsi. Kaotab suhtestruktuuri.

Graafi-RAG lähenemine:

• Tipud: klient, leping, toode, pilet, suhtlus, töötaja.
• Servad: klient→omab→leping, klient→tellinud→toode, klient→esitas→pilet, pilet→määratud→töötaja, leping→müüdud→töötaja.

Päring: "Millistel SaaS-tasemel klientidel oli Q1-s rohkem kui 3 tugipiletti ja kelle leping uueneb Q2-s?"

See on loomulikult graafi-päring:

MATCH (c:Customer)-[:HAS]->(contract:Contract)
WHERE contract.tier = "SaaS"
  AND contract.renewal_date BETWEEN "2026-04-01" AND "2026-06-30"
MATCH (c)-[:SUBMITTED]->(t:Ticket)
WHERE t.created BETWEEN "2026-01-01" AND "2026-03-31"
WITH c, count(t) as ticket_count
WHERE ticket_count > 3
RETURN c, ticket_count

LLM genereerib selle päringu (või valib mallide hulgast). Käivita. Vorminda tulemused. Genereeri vastus.

Klassikaline RAG ei vasta sellele lihtsasti. Graafi-RAG teeb seda puhtalt.

Vahetused

Plussid:

• Käsitleb suhtepäringuid loomulikult.
• Selge, auditeritav struktuur.
• Komponeeritav embeddingutega.

Miinused:

• Graafi ehitamine on päris insenertöö. Eriti struktureerimata allikate puhul on eraldus ebatäiuslik.
• Skeemikujundus loeb; halvad skeemid piiravad.
• Hooldus: kui andmed arenevad, graaf areneb.
• Vähem küps tööriistastik kui vektorotsing.

Millal valida:

Vali graafi-RAG, kui suhted on sinu domeenis esmaklassilised. Ära vali seda lihtsalt selle pärast, et see kõlab keerukas; paljude dokumendi-rohkete domeenide jaoks on klassikaline RAG lihtsam ja sama hea.

Microsofti Graph RAG ja sellega seotud töö

Microsofti avatud lähtekoodiga GraphRAG projekt (2024) populariseeris konkreetse lähenemise:

1. Eralda olemid ja suhted dokumentidest (LLM-põhiselt).
2. Klasterda olemid kogukondadeks.
3. Genereeri kokkuvõtted kogukonna kohta mitmel hierarhilisel tasandil.
4. Päringu ajal: leia asjakohased kogukonna-kokkuvõtted; kasuta neid kontekstina.

See töötab hästi "globaalsete" küsimuste jaoks, mis ulatuvad üle korpuse (nt "millised on selle kliendi kaebuste ajaloo peamised teemad?"), mitte konkreetsete otsingute jaoks.

Variandid hõlmavad LightRAG-i, Graphitit ja teisi — igaühel oma konkreetsed arhitektuurivalikud.

Agentne RAG

Idee: fikseeritud otsi-siis-genereeri konveieri asemel kasuta LLM agenti, kes otsustab, mida leida, millal ja kuidas viimistleda. Agent saab esitada järelpäringuid, vaadata tulemusi ja otsustada, et need pole piisavad, proovida erinevaid nurki.

Millal agentne RAG aitab

Keerulised päringud, mis vajavad iteratsiooni. "Aita mul mõista, miks meie churn Q1-s tõusis" nõuab paljude nurkade vaatamist (milline segment, milline aeg, millised funktsioonid, millised konkurendid). Agent saab iteratiivselt uurida.

Päringud, kus üks otsing ei piisa. Kui vastus nõuab info ühendamist mitmest eraldi otsingust, käsitleb agent seda loomulikult.

Päringud tingimusliku loogikaga. "Kui X on tõene otsingu 1 põhjal, siis otsi Y; muidu otsi Z." Agendid käsitlevad hargnemist; fikseeritud konveierid mitte.

Mitmeti mõistetavad päringud. Agent saab küsida kasutajalt (või andmetelt) täpsustust.

Kuidas agentne RAG töötab

Konveier:

User query
    ↓
Agent reasons about what it needs
    ↓
Agent calls retrieval tools (one or many)
    ↓
Agent reads results
    ↓
Agent decides: enough info? Or another retrieval?
    ↓
Loop until done
    ↓
Generate final answer

Teostus hõlmab:

Otsing tööriistadena. Paljasta otsingufunktsioonid agendile: search_documents(query), lookup_by_id(id), aggregate(field, filter). Agent kutsub neid vastavalt vajadusele.

Mälu. Agent jätab meelde, mida ta on leidnud üle kõnede. Väldib sama sisu uuesti-pärimist.

Otsustamine. Agent arutleb selgesõnaliselt, kas tal on piisavalt infot. "Kas ma tean vastust kasutaja küsimusele? Kui ei, mida ma veel pean leidma?"

Lõpetamine. Agent peab teadma, millal peatuda. Maks-sammude eelarve. Kindluse lävi. "Olen vastanud" tingimus.

Konkreetne näide

Päring: "Millised olid Q1-s kolm peamist kliendi muret, koos näidetega?"

Klassikaline RAG lähenemine: leia mõned kliendi tagasiside tükid, looda, et need katavad teema.

Agentne RAG lähenemine:

Agent: I need to find Q1 customer concerns. Let me start by searching for customer complaints in that period.
> Tool: search_documents(query="customer complaints Q1 2026", filter={date_range: "Q1 2026"})

Agent: I got 25 results. Let me see what topics they cover.
> [reads results]

Agent: I see three main themes: pricing, slow support, and missing integrations. Let me get specific examples for each.
> Tool: search_documents(query="customer pricing complaints", filter={...})
> Tool: search_documents(query="customer support speed complaints", filter={...})
> Tool: search_documents(query="customer integration missing complaints", filter={...})

Agent: Now I have 3-5 specific examples per theme. Let me compile the answer.

Mitu otsingut, iteratiivselt viimistletud. Agent otsustab struktuuri leitud info põhjal.

Vahetused

Plussid:

• Käsitleb keerulisi, mitmesammulisi päringuid.
• Kohaneb päringu keerukusele (lihtsad päringud ei käivita pikka agendi-jooksu).
• Saab täpsustada mitmeti mõistetavust küsides.

Miinused:

• Kõrgem latentsus (mitu otsingut).
• Kõrgem kulu (mitu LLM-kõnet).
• Agendi usaldusväärsus loeb; halvad agendid silmustuvad või annavad alla.
• Raskem hinnata (rohkem varieeruvaid täitmisteid).
• Raskem kontrollida (agent võib teha ootamatuid asju).

Millal valida:

Vali agentne RAG, kui päringu keerukus varieerub laialt. Lihtsad päringud saavad kiire tee; keerulised saavad agentse käsitluse. Ühtlaselt lihtsate päringute jaoks ei ole üldkulu seda väärt.

Mustrid agentse RAG-i sees

Mõned levinud mustrid:

Muster 1: ReAct (Reason + Act). Agent arutleb selgesõnaliselt, siis tegutseb (leiab), siis vaatleb, siis arutleb uuesti. Silmustab kuni valmis.

Muster 2: Plan-and-execute. Agent loob esiteks mitmesammulise plaani (mida millises järjekorras leida), siis täidab plaani, võimalik et kohandades.

Muster 3: Enesekriitika. Pärast otsingut hindab agent, kas leitud info on piisav. Kui mitte, viimistleb päringut ja otsib uuesti.

Muster 4: Tööriista-rikas agent. Agendil on palju otsinguvahendeid (täisteksti otsing, SQL päring, graafi päring, API kõned) ja ta valib nende seast.

Erinevad mustrid sobivad erinevatele kasutusjuhtudele. Tööriista-rikas töötab heterogeensete andmeallikate jaoks; ReAct töötab uurimuslike päringute jaoks; plan-and-execute töötab, kui keerulise päringu struktuuri saab ette planeerida.

Pika-konteksti RAG

Idee: 1M+ tokeni konteksti-akendega (Gemini, GPT-5), milleks üldse tükke leida? Pane lihtsalt kogu korpus konteksti.

Millal pika-konteksti RAG aitab

Väikesed korpused. 100K-tokeni korpus mahub lihtsasti 1M-tokeni aknas. Otsinguinfrastruktuuri pole vaja.

Terve-dokumendi mõistmine. "Tee kokkuvõte sellest tervest 500-leheküljelisest dokumendist." Pika-konteksti mudel käsitleb seda otse.

Üle-dokumentide päringud väikestel komplektidel. "Võrdle neid 10 lepingut." Lihtsam panna kõik konteksti kui hoolikalt otsida.

Prototüüpimine. Pikk kontekst on lihtsaim tee töötava süsteemini. Ehita prototüüp pika kontekstiga; optimeeri otsinguga hiljem, kui vaja.

Kuidas pika-konteksti RAG töötab

Konveier on triviaalne:

[corpus, possibly 100K-1M tokens]
    ↓
+ [user query]
    ↓
LLM call
    ↓
[answer]

Pole vektorpoodi. Pole tükeldamist. Pole ümberreastamist.

Praktikas võid siiski teha kerge otsingu, et korpus konteksti mahutada (nt 5M-tokeni korpuse jaoks leia 500K-tokeni alamhulk). Aga otsing on jämedakoeline — LLM teeb peenema "leia asjakohased osad" töö.

"Konteksti mädanemise" probleem

2025–2026 reaalsus: pika-konteksti mudelid päriselt ei kasuta pikki kontekste hästi.

Empiiriliselt:

• Kvaliteet on kõrgeim 5–50K tokeni kontekstiga.
• Kvaliteet langeb märgatavalt 100K+ tokeni juures.
• 500K+ tokeni juures jääb oluline info sageli kahe silma vahele või rakendatakse valesti.

Mudelid suudavad tehniliselt pikkade kontekstidega hakkama saada, aga "nõel heinakuhjas" võrdlustestid ülemüüvad nende jõudlust. Päris pika-konteksti kasutus kannatab.

See tähendab, et pika-konteksti RAG töötab usaldusväärselt kuni ~50K tokeni korpusteni. Üle selle on see halvenenud heale otsingule.

Vahetused

Plussid:

• Lihtsaim võimalik arhitektuur.
• Pole otsingukonveieri, mida hooldada.
• Parim terve-korpuse mõistmise ülesannete jaoks.

Miinused:

• Kvaliteedi halvenemine suurte konteksti suuruste juures.
• Kulu päringu kohta on kõrge (maksad iga kord täiskonteksti eest).
• Latentsus on kõrge (suur kontekst = aeglasem vastus).
• Ei skaleeru üle korpuste, mis usaldusväärselt mahuvad.

Millal valida:

Väikesed korpused (alla 50K tokeni). Ühekordsed analüüsid. Prototüübid. EI üldotstarbeline otsing suurte teadmusbaaside jaoks.

Hübriid: otsing + pikk kontekst

Levinud muster: leia suurem kontekst (50–200K tokenit asjakohast sisu), kui klassikaline RAG seda teeks, aga väiksem kui täiskorpus. LLM saab piisavalt konteksti, et päringut hästi käsitleda ilma konteksti mädanemiseta.

Teostus: leia top-50 tükki (top-5 asemel), lisa kõik, lase LLM-il läbi sortida.

See töötab hästi, kui:

• Päringud vajavad laia konteksti.
• Mudelid käsitlevad keskmist konteksti hästi (50–200K).
• Kulu on aktsepteeritav.

2026 kuldne kesktee: leia agressiivselt (50–100 tükki), lisa kõik, lase LLM-il kasutada asjakohaseid osi. Vahetab kulu lihtsuse ja kvaliteedi vastu.

Õige variandi valimine

Otsustusraamistik:

Kasuta klassikalist tüki-põhist RAG-i, kui:

• Dokumendid on peamine andmestik.
• Päringud on enamasti otsingu-stiilis.
• Maht ja kulu loevad (odavaim päringu kohta).
• Vajad prognoositavat latentsust.

Kasuta graafi-RAG-i, kui:

• Andmetel on rikkalik olem-suhete struktuur.
• Päringud hõlmavad mitme-hüppe arutlust, hulgaoperatsioone, agregeerimist.
• Saad investeerida graafi ehitamisse ja hooldamisse.

Kasuta agentset RAG-i, kui:

• Päringu keerukus varieerub laialt.
• Mõned päringud vajavad iteratiivset uurimist.
• Oled valmis maksma kõrgemat latentsust/kulu raskete päringute eest.
• Sul on seire agendi-jooksude silumiseks.

Kasuta pika-konteksti RAG-i, kui:

• Korpus on väike (alla 50K tokeni).
• Tahad lihtsaimat arhitektuuri.
• Ühekordsed analüüsid või prototüübid.

Kombineeri, kui:

• Enamik päris süsteeme kombineerib.
• Klassikaline + graaf suhtepäringuteks.
• Klassikaline + agentne keeruliste päringute jaoks.
• Klassikaline laiema otsinguga (keskmine kontekst) piiripealsetele juhtudele.

2026 küps vastus on "kõik eelpool, päringu kohta rakendatud." Marsruuter määrab, millist varianti kasutada päringu omaduste põhjal.

Tootmisreaalsused

Mõned tähelepanekud päris juurutustest:

Keerukus akumuleerub. Iga variant lisab keerukust. Süsteem, mis kasutab kõiki nelja, on märkimisväärne insenertöö ettevõtmine. Alusta klassikalisest; lisa variante ainult siis, kui tabad selgeid piire.

Eval on raskem. Mitme otsinguteega peab hindamine kõiki katma. Testkomplekt peaks sisaldama päringuid, mis treenivad iga teed.

Kulud varieeruvad laialt. Graafi-RAG võib olla odav (andmebaasi päring). Pika-konteksti RAG on kallis. Agentne RAG varieerub (lihtne = odav, keeruline = kallis). Jälgi päringu-kulusid.

Latentsus varieerub sarnaselt. 30-sekundi agentse RAG-i vastus on okei mõnele kasutusjuhule; mitte teistele. Vali variandid UX konteksti kohta.

Hoolduskoormus. Graafiskeemid triivivad, agendi-promptid vajavad häälestust, embedding-mudelid uuenevad. Igal variandil on oma hoolduskulu. Planeeri vastavalt.

80/20. Klassikaline RAG käsitleb 80% päringutest piisavalt. Üle-tükkide variandid käsitlevad raske 20%, mida klassikaline halvasti teeb. Ära asenda; täienda.

Kombineeritud arhitektuur

Praktiline arhitektuur, kasutades mitut varianti:

Query
  ↓
Router (classify the query)
  ├→ "Lookup" → Classic RAG (cheap, fast)
  ├→ "Relational" → Graph RAG
  ├→ "Complex / open-ended" → Agentic RAG
  └→ "Whole-corpus / small corpus" → Long-context

Each variant produces an answer.
Observability tracks which path was used.
Eval suites cover all paths.

See on keerulisem kui mis tahes üks variant, aga käsitleb kogu päringuvalikut hästi. Küpsete süsteemide jaoks, kus on mitmekesised päringutüübid, on see lõplik arhitektuur.

Praktiline ülesehitus

Kui alustad töötavast klassikalisest RAG-ist ja tahad laieneda:

Lisa kõigepealt pikk kontekst. Madalaim insenertöö kulu. Kasulik konkreetsete päringutüüpide jaoks. Tihti toodab võite kohe.

Lisa agentne keerukate päringute jaoks. Tuvasta päringud, millega klassikaline RAG võitleb. Ehita agent, mis neid käsitleb. Marsruuta sellele tingimuslikult.

Lisa graafi-RAG viimasena. Kõrgeim insenertöö kulu. Tasub ainult, kui sul on selged suhte-päringu-mustrid.

See järjekord vastab tüüpiliselt ROI-le. Pikk kontekst: madal kulu, päris väärtus. Agentne: mõõdukas kulu, tegeleb päris lünkadega. Graaf: kõrge kulu, konkreetsed kasutusjuhud.

Kokkuvõte

Klassikaline tüki-põhine RAG on töömoonas, aga sellel on piirid. "Üle tükkide" variandid — graafi-RAG, agentne RAG, pika-konteksti RAG — avavad igaüks erinevaid võimekusi.

Tee edasi ei ole klassikalise RAG-i asendamine, vaid selle täiendamine. Küpsed süsteemid kasutavad mitut varianti, asjakohaselt marsruutides, igaüks käsitleb päringuid, mille jaoks see on hea.

Investeering on tähenduslik — iga variant on päris insenertöö. Aga süsteemide jaoks, kus klassikaline RAG saavutab platoo, on võimekuse võidud päris. Süsteem, mis käsitleb ainult "otsingu" päringuid hästi, on palju vähem kasulik kui see, mis käsitleb ka suhte-, keerulisi ja terve-korpuse-päringuid.

Kaardista oma päringud. Tuvasta need, mida klassikaline RAG halvasti käsitleb. Vali variant, mis sobib. Ehita täiendus. Itereeri.

Nii kasvavad RAG süsteemid kasulik-mõnedele-päringutele süsteemidest tõeliselt võimekateks süsteemideks, mis katavad päris-elu küsimuste mitmekesisuse.