RAG paloja pidemmälle: graafi-RAG, agenttipohjainen RAG ja pitkän kontekstin RAG

Jos olet rakentanut perinteisen RAG-järjestelmän, tunnet sen vahvuudet: se hakee olennaisia paloja, LLM tuottaa lähteisiin perustuvia vastauksia, suorituskyky on kohtuullinen ja kustannukset ennakoitavia. Tämä riittää useimpiin tietopankin kyselyihin.

Jotkin kyselyt kuitenkin rikkovat perinteisen RAG:n toimintamallin. Monivaiheiset kysymykset (”Ketkä asiakkaistamme käyttävät ominaisuutta X ja ovat lopettaneet asiakkuutensa viimeisten 6 kuukauden aikana?”). Suhteita painottavat kysymykset (”Miten hinnoittelumme vertautuu kilpailijoihin A, B ja C?”). Synteesiä edellyttävät kysymykset (”Tiivistä kaikki, mitä tiedämme tämän asiakkaan polusta”). Perinteinen paloihin perustuva haku ei yhdistä paloja hyvin, joten LLM:ltä jää huomaamatta eri paikkoihin hajautunutta kontekstia.

Paloja pidemmälle menevät lähestymistavat — graafi-RAG, agenttipohjainen RAG ja pitkän kontekstin RAG — ratkaisevat näitä rajoituksia eri tavoin. Tässä artikkelissa käsitellään, mitä ne ovat, milloin mikäkin niistä on oikea työkalu, miten ne todella toimivat tuotannossa ja mitkä kompromissit ovat olennaisia.

Paloihin perustuvan RAG:n rajat

Jotta ymmärtäisimme ratkaisut, on ensin tunnettava rajoitukset:

Rajoitus 1: suhteiden rakenne puuttuu. Palat ovat itsenäisiä yksiköitä. Tieto siitä, että pala A käsittelee asiakkaan X tiliä ja pala B asiakkaan X tekemää valitusta, katoaa. Ne ovat vain kaksi palaa vektoriavaruudessa, ja kumpikin haetaan tai jätetään hakematta itsenäisesti.

Rajoitus 2: monivaiheinen päättely puuttuu. ”Asiakkaat, jotka käyttävät ominaisuutta X ja valittivat asiasta Y” edellyttää kahden eri lähteen tietojen yhdistämistä joukko-operaatioilla. Paloihin perustuva haku ei tee tätä.

Rajoitus 3: rajallinen synteesi. ”Tiivistä tämän asiakkuuden kehitys ajan mittaan” edellyttää monien palojen yhdistämistä johdonmukaiseksi kertomukseksi. Palat annetaan katkelmina, joten LLM:n on tehtävä synteesi joka kerta alusta.

Rajoitus 4: kiinteän putken jäykkyys. Perinteinen RAG toimii aina näin: upota kysely → hae K → generoi. Iteratiivista hakua tai monivaiheista päättelyä vaativat kyselyt eivät sovi tähän putkeen.

Rajoitus 5: kontekstin laimentuminen. 5 parhaan palan joukossa voi olla kyselyä vastaavia mutta aiheeseen kuulumattomia paloja. LLM joutuu kahlaamaan niiden läpi, mikä heikentää laatua.

Seuraavaksi käsiteltävät muunnelmat ratkaisevat kukin osan näistä ongelmista.

Graafi-RAG

Ajatus on esittää tieto tietämysgraafina. Entiteetit, kuten ihmiset, tuotteet, asiakirjat ja tapahtumat, ovat solmuja ja niiden väliset suhteet kaaria. Kysely kulkee graafissa vektorihaun sijasta tai sen lisäksi.

Milloin graafi-RAG auttaa

Suhteita painottavat toimialat. Asiakkaan, tilin, kaupan ja vuorovaikutuksen rakenteet. Organisaatiohierarkiat. Tuoteluokittelut. Viittausverkostot. Kaikki tilanteet, joissa entiteettien väliset yhteydet ovat yhtä tärkeitä kuin entiteetit itse.

Monivaiheinen päättely. ”Kuka johtaa tiimiä, joka osti tuotteen X Q3:lla?” edellyttää kulkua tuotteesta kauppaan, tiimiin ja johtajaan. Graafi-RAG käsittelee tämän luontevasti.

Koostaminen. ”Kuinka moni segmentin Y asiakas on integroinut järjestelmän Z?” edellyttää entiteettien välisiä joukko-operaatioita. Tietämysgraafiin kohdistuva SQL voittaa tekstihaun.

Viittaukset ja selitykset. Graafin suhteet ovat eksplisiittisiä ja auditoitavia. LLM voi viitata tietoon ”John johtaa Team Acmea [kaari: manages]” sen sijaan, että se sanoisi ”Kontekstin perusteella luulen Johnin johtavan Team Acmea.”

Miten graafi-RAG todella toimii

Tyypillinen putki:

1. Poiminta. Rakenna graafi tiedoistasi. Kaksi yleistä tapaa:

• Rakenteiset lähteet (tietokannat, rakenteiset API:t): tuo tiedot suoraan. Asiakkaat, tuotteet ja tapahtumat ovat jo taulukoissa.
• Rakenteettomat lähteet (asiakirjat, litteroinnit, sähköpostit): poimi entiteetit ja suhteet LLM:llä. ”Poimi tästä litteroinnista ihmiset, organisaatiot ja niiden väliset suhteet.”

Tuloksena ovat tyyppejä ja ominaisuuksia sisältävät solmut sekä tyyppejä ja ominaisuuksia sisältävät kaaret.

2. Tallennus. Graafitietokanta, kuten Neo4j, Memgraph tai oma kaaritauluja käyttävä Postgres-toteutus. Valinta riippuu kyselymalleista ja mittakaavasta.

3. Täydennä upotuksilla. Jokainen solmu saa myös tekstiesityksen ja upotuksen. Tämä mahdollistaa hybridimallin: kulje graafissa JA tee semanttinen haku.

4. Tee kysely hakuhetkellä. Kolme yleistä mallia:

• Pelkkä graafikysely. LLM tai reitityslogiikka tuottaa graafikyselyn (Cypher, SQL). Suorita se ja palauta tulokset LLM:lle.
• Ensin upotus, sitten graafin laajennus. Etsi olennaiset entiteetit upotuksella ja laajenna sitten niiden naapureihin ja niihin liittyviin entiteetteihin.
• Hybridi. Yhdistä vektorihaku ja graafin läpikäynti samaan putkeen.

5. Muotoile LLM:lle. Graafin tulokset muotoillaan rakenteiseksi tekstiksi, jota LLM voi käyttää. Entiteetit esitetään ominaisuuksineen ja suhteet eksplisiittisesti.

Konkreettinen esimerkki

SaaS-yrityksellä on asiakastietoa. Entiteettejä ovat asiakkaat, sopimukset, tuotteet, tukipyynnöt, vuorovaikutukset ja työntekijät.

Perinteinen RAG: pilko asiakasasiakirjat, muodosta upotukset ja hae. Suhteiden rakenne katoaa.

Graafi-RAG:

• Solmut: asiakas, sopimus, tuote, tukipyyntö, vuorovaikutus ja työntekijä.
• Kaaret: asiakas→has→sopimus, asiakas→subscribed_to→tuote, asiakas→submitted→tukipyyntö, tukipyyntö→assigned_to→työntekijä, sopimus→sold_by→työntekijä.

Kysely: ”Millä SaaS-tason asiakkailla oli yli 3 tukipyyntöä Q1:llä ja sopimuksen uusiminen Q2:lla?”

Tämä on luonteva graafikysely:

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 tuottaa tämän kyselyn tai valitsee sen kyselymalleista. Suorita kysely, muotoile tulokset ja tuota vastaus.

Perinteinen RAG ei vastaa tähän helposti. Graafi-RAG ratkaisee sen selkeästi.

Kompromissit

Hyödyt:

• Käsittelee suhteisiin perustuvia kyselyjä luontevasti.
• Rakenne on eksplisiittinen ja auditoitava.
• Yhdistettävissä upotuksiin.

Haitat:

• Graafin rakentaminen on todellista ohjelmistokehitystyötä. Etenkin rakenteettomista lähteistä tehtävä poiminta on epätäydellistä.
• Skeeman suunnittelulla on merkitystä: huono skeema rajoittaa järjestelmää.
• Ylläpito: tiedon muuttuessa myös graafi muuttuu.
• Työkalut ovat vektorihakua kehittymättömämpiä.

Milloin valita:

Valitse graafi-RAG, kun suhteet ovat toimialallasi keskeisiä. Älä valitse sitä vain siksi, että se kuulostaa edistyneeltä. Monilla asiakirjapainotteisilla aloilla perinteinen RAG on yksinkertaisempi ja aivan yhtä hyvä.

Microsoftin Graph RAG ja siihen liittyvä työ

Microsoftin avoimen lähdekoodin GraphRAG-projekti (2024) teki tunnetuksi tietyn lähestymistavan:

1. Poimi asiakirjoista entiteetit ja suhteet LLM:llä.
2. Ryhmittele entiteetit yhteisöiksi.
3. Tuota kustakin yhteisöstä yhteenvetoja hierarkian useilla tasoilla.
4. Hae kyselyhetkellä olennaiset yhteisöyhteenvedot ja käytä niitä kontekstina.

Tämä toimii hyvin koko aineiston kattavissa ”globaaleissa” kysymyksissä, kuten ”Mitkä ovat tämän asiakkaan valitushistorian pääteemat?”, yksittäisten hakujen sijaan.

Muunnelmia ovat LightRAG, Graphiti ja muut, joilla kullakin on omat arkkitehtuurivalintansa.

Agenttipohjainen RAG

Ajatus on käyttää kiinteän hae ja generoi -putken sijasta LLM-agenttia, joka päättää, mitä haetaan, milloin ja miten hakua tarkennetaan. Agentti voi tehdä täydentäviä hakuja, tarkastella tuloksia, todeta ne riittämättömiksi ja kokeilla eri näkökulmia.

Milloin agenttipohjainen RAG auttaa

Iterointia vaativat monimutkaiset kyselyt. ”Auta minua ymmärtämään, miksi asiakaspoistumamme kasvoi Q1:llä” edellyttää monien näkökulmien tutkimista: mikä segmentti, mikä ajanjakso, mitkä ominaisuudet ja mitkä kilpailijat. Agentti voi tutkia niitä iteratiivisesti.

Kyselyt, joihin yksi haku ei riitä. Jos vastaus edellyttää usean erillisen haun tietojen yhdistämistä, agentti käsittelee sen luontevasti.

Ehdollista logiikkaa sisältävät kyselyt. ”Haku 1, tulos: jos X on totta, hae Y; muussa tapauksessa hae Z.” Agentit käsittelevät haarautumisen, kiinteät putket eivät.

Monitulkintaiset kyselyt. Agentti voi pyytää käyttäjältä tai aineistosta tarkennusta.

Miten agenttipohjainen RAG toimii

Putki:

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

Toteutukseen kuuluvat:

Haku työkaluina. Anna agentille hakufunktiot: search_documents(query), lookup_by_id(id), aggregate(field, filter). Agentti kutsuu niitä tarpeen mukaan.

Muisti. Agentti muistaa eri kutsuilla hakemansa tiedot eikä hae samaa sisältöä uudelleen.

Päätöksenteko. Agentti päättelee eksplisiittisesti, onko tietoa riittävästi. ”Tiedänkö vastauksen käyttäjän kysymykseen? Jos en, mitä muuta minun pitää hakea?”

Lopettaminen. Agentin on tiedettävä, milloin lopettaa. Käytä vaiheiden enimmäismäärää, luottamusrajaa tai ”olen vastannut” -ehtoa.

Konkreettinen esimerkki

Kysely: ”Mitkä olivat asiakkaiden kolme yleisintä huolta Q1:llä? Anna myös esimerkkejä.”

Perinteinen RAG: hae joitakin asiakaspalautteen paloja ja toivo, että ne kattavat aiheen.

Agenttipohjainen RAG:

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.

Hakuja tehdään useita ja niitä tarkennetaan iteratiivisesti. Agentti päättää rakenteen löytämiensä tietojen perusteella.

Kompromissit

Hyödyt:

• Käsittelee monimutkaisia, monivaiheisia kyselyjä.
• Mukautuu kyselyn monimutkaisuuteen, joten yksinkertaiset kyselyt eivät käynnistä pitkiä agenttiajoja.
• Voi pyytää tarkennusta monitulkintaiseen kyselyyn.

Haitat:

• Suurempi viive useiden hakujen vuoksi.
• Suurempi kustannus useiden LLM-kutsujen vuoksi.
• Agentin luotettavuus on tärkeää: huonot agentit jäävät silmukkaan tai luovuttavat.
• Vaikeampi arvioida vaihtelevien suorituspolkujen vuoksi.
• Vaikeampi hallita, sillä agentti voi toimia odottamattomasti.

Milloin valita:

Valitse agenttipohjainen RAG, kun kyselyjen monimutkaisuus vaihtelee suuresti. Yksinkertaiset kyselyt voivat käyttää nopeita polkuja, ja monimutkaiset ohjataan agentille. Jos kyselyt ovat poikkeuksetta yksinkertaisia, lisäkustannus ei kannata.

Agenttipohjaisen RAG:n mallit

Muutamia yleisiä malleja:

Malli 1: ReAct (Reason + Act). Agentti päättelee eksplisiittisesti, toimii eli hakee, havainnoi ja päättelee uudelleen. Silmukka jatkuu, kunnes tehtävä on valmis.

Malli 2: suunnittele ja suorita. Agentti laatii ensin monivaiheisen suunnitelman siitä, mitä haetaan ja missä järjestyksessä, ja suorittaa sen sitten tarvittaessa mukauttaen.

Malli 3: itsekritiikki. Agentti arvioi haun jälkeen, riittävätkö löydetyt tiedot. Muussa tapauksessa se tarkentaa kyselyä ja hakee uudelleen.

Malli 4: monipuoliset työkalut. Agentilla on useita hakutyökaluja, kuten kokotekstihaku, SQL-kysely, graafikysely ja API-kutsut, joista se valitsee sopivan.

Eri mallit sopivat eri käyttötapauksiin. Monipuoliset työkalut sopivat heterogeenisiin tietolähteisiin, ReAct tutkiviin kyselyihin ja suunnittele ja suorita -malli tilanteisiin, joissa monimutkaisen kyselyn rakenne voidaan suunnitella etukäteen.

Pitkän kontekstin RAG

Ajatus: miksi paloja pitäisi hakea lainkaan, kun konteksti-ikkunat kattavat 1M+ tokenia (Gemini, GPT-5)? Lisää koko aineisto kontekstiin.

Milloin pitkän kontekstin RAG auttaa

Pienet aineistot. 100K tokenin aineisto mahtuu helposti 1M tokenin ikkunaan. Hakuinfrastruktuuria ei tarvita.

Kokonaisen asiakirjan ymmärtäminen. ”Tiivistä tämä koko 500-sivuinen asiakirja.” Pitkän kontekstin malli käsittelee sen suoraan.

Pieneen joukkoon kohdistuvat asiakirjojen väliset kyselyt. ”Vertaa näitä 10 sopimusta.” Kaikkien lisääminen kontekstiin on helpompaa kuin huolellinen haku.

Prototyypit. Pitkä konteksti on yksinkertaisin reitti toimivaan järjestelmään. Rakenna prototyyppi pitkällä kontekstilla ja optimoi tarvittaessa myöhemmin haulla.

Miten pitkän kontekstin RAG toimii

Putki on hyvin yksinkertainen:

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

Ei vektorivarastoa, pilkkomista eikä uudelleenjärjestelyä.

Käytännössä aineistoa saatetaan silti hakea kevyesti, jotta se mahtuu kontekstiin. Esimerkiksi 5M tokenin aineistosta voidaan hakea 500K tokenin osajoukko. Haku on kuitenkin karkearakeinen: LLM etsii itse tarkasti olennaiset kohdat.

Kontekstin rapautumisen ongelma

Vuosien 2025-2026 todellisuus on, etteivät pitkän kontekstin mallit käytä pitkiä konteksteja erityisen hyvin.

Kokeellisten tulosten perusteella:

• Laatu on parhaimmillaan noin 5-50K kontekstitokenilla. Taustalla oleva paikkaan sidotun tarkkaavaisuuden ilmiö on kuvattu Liu et al:n ”Lost in the Middle” -tutkimuksessa ja sitä seuranneissa pitkän kontekstin arvioinneissa.
• Laatu heikkenee huomattavasti 100K+ tokenin kohdalla.
• Kun tokeneita on 500K+, tärkeä tieto jää usein huomaamatta tai sitä sovelletaan väärin.

Mallit pystyvät teknisesti käsittelemään pitkiä konteksteja, mutta neula heinäsuovassa -vertailut antavat suorituskyvystä liian hyvän kuvan. Todellisissa käyttötapauksissa pitkä konteksti kärsii ongelmista.

Siksi pitkän kontekstin RAG toimii luotettavasti enintään noin 50K tokenin aineistoilla. Tätä suuremmilla aineistoilla laatu jää hyvää hakua heikommaksi.

Kompromissit

Hyödyt:

• Mahdollisimman yksinkertainen arkkitehtuuri.
• Ei ylläpidettävää hakuputkea.
• Paras koko aineiston ymmärtämistä edellyttäviin tehtäviin.

Haitat:

• Laatu heikkenee suurilla kontekstimäärillä.
• Kyselykohtainen kustannus on suuri, koska maksat aina koko kontekstista.
• Viive on suuri, sillä laaja konteksti hidastaa vastausta.
• Ei skaalaudu luotettavasti mahtuvaa aineistoa suuremmaksi.

Milloin valita:

Pienet aineistot (alle 50K tokenia), kertaluonteiset analyysit ja prototyypit. EI suurten tietopankkien yleiskäyttöiseen hakuun.

Hybridi: haku + pitkä konteksti

Yleisessä mallissa haetaan perinteistä RAG:a laajempi konteksti, esimerkiksi 50-200K tokenia olennaista sisältöä, joka on kuitenkin koko aineistoa pienempi. LLM saa tarpeeksi kontekstia kyselyn käsittelyyn ilman kontekstin rapautumista.

Toteutus: hae top-50 palaa top-5:n sijaan, lisää ne kaikki ja anna LLM:n seuloa sisältö.

Tämä toimii hyvin, kun:

• Kyselyt vaativat laajaa kontekstia.
• Mallit käsittelevät keskipitkiä konteksteja hyvin (50-200K).
• Kustannus on hyväksyttävä.

Vuoden 2026 tasapainoinen ratkaisu on hakea runsaasti (50-100 palaa), lisätä kaikki kontekstiin ja antaa LLM:n käyttää olennaisia kohtia. Kustannus vaihdetaan yksinkertaisuuteen ja laatuun.

Oikean muunnelman valinta

Päätösmalli:

Käytä perinteistä paloihin perustuvaa RAG:a, kun:

• Asiakirjat ovat ensisijainen tieto.
• Kyselyt ovat enimmäkseen hakutyyppisiä.
• Määrällä ja kustannuksella on merkitystä, ja tarvitset halvimman kyselykohtaisen vaihtoehdon.
• Tarvitset ennakoitavan viiveen.

Käytä graafi-RAG:a, kun:

• Tiedolla on rikas entiteetti-suhderakenne.
• Kyselyihin sisältyy monivaiheista päättelyä, joukko-operaatioita tai koostamista.
• Voit investoida graafin rakentamiseen ja ylläpitoon.

Käytä agenttipohjaista RAG:a, kun:

• Kyselyjen monimutkaisuus vaihtelee suuresti.
• Osa kyselyistä vaatii iteratiivista tutkimista.
• Olet valmis hyväksymään vaikeissa kyselyissä suuremman viiveen ja kustannuksen.
• Käytössäsi on havainnoitavuus agenttiajojen virheiden selvittämiseen.

Käytä pitkän kontekstin RAG:a, kun:

• Aineisto on pieni (alle 50K tokenia).
• Haluat mahdollisimman yksinkertaisen arkkitehtuurin.
• Kyse on kertaluonteisista analyyseista tai prototyypeistä.

Yhdistä, kun:

• Useimmat todelliset järjestelmät tekevät niin.
• Käytä perinteistä RAG:a ja graafi-RAG:a suhteisiin perustuvissa kyselyissä.
• Käytä perinteistä ja agenttipohjaista RAG:a monimutkaisissa kyselyissä.
• Käytä perinteistä RAG:a tavallista laajemmalla haulla eli keskipitkällä kontekstilla rajatapauksissa.

Vuoden 2026 kypsä vastaus on ”kaikki edellä mainitut kyselykohtaisesti sovellettuina”. Reititin valitsee kyselyn ominaisuuksien perusteella käytettävän muunnelman.

Tuotannon realiteetit

Muutamia havaintoja todellisista käyttöönotoista:

Monimutkaisuus kertautuu. Jokainen muunnelma lisää monimutkaisuutta. Kaikkia neljää käyttävä järjestelmä on huomattava ohjelmistokehityshanke. Aloita perinteisestä RAG:sta ja lisää muunnelmia vasta, kun törmäät selviin rajoihin.

Arviointi vaikeutuu. Kun hakupolkuja on useita, arvioinnin on katettava ne kaikki. Testiaineistossa pitäisi olla jokaista polkua käyttäviä kyselyjä.

Kustannukset vaihtelevat suuresti. Graafi-RAG voi olla edullinen tietokantakysely. Pitkän kontekstin RAG on kallis. Agenttipohjaisen RAG:n kustannus vaihtelee: yksinkertainen on halpa ja monimutkainen kallis. Seuraa kustannuksia kyselykohtaisesti.

Viive vaihtelee samoin. Agenttipohjaisen RAG:n 30 sekunnin vastaus sopii joihinkin käyttötapauksiin mutta ei toisiin. Valitse muunnelma käyttökokemuksen mukaan.

Ylläpitotaakka. Graafiskeemat ajautuvat erilleen todellisuudesta, agenttien kehotteita pitää hienosäätää ja upotusmallit päivittyvät. Jokaisella muunnelmalla on oma ylläpitokustannuksensa. Varaudu siihen.

80/20. Perinteinen RAG käsittelee 80% kyselyistä riittävän hyvin. Vaikeat 20% ovat kyselyjä, joissa perinteinen malli toimii huonosti ja jotka paloista pidemmälle menevät muunnelmat käsittelevät. Älä korvaa, vaan täydennä.

Yhdistetty arkkitehtuuri

Useita muunnelmia hyödyntävä käytännöllinen arkkitehtuuri:

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.

Tämä on mitä tahansa yksittäistä muunnelmaa monimutkaisempi mutta käsittelee koko kyselykirjon hyvin. Erilaisia kyselytyyppejä sisältävissä kypsissä järjestelmissä tästä muodostuu lopullinen arkkitehtuuri.

Käytännön laajennuspolku

Jos aloitat toimivasta perinteisestä RAG:sta ja haluat laajentaa sitä:

Lisää pitkä konteksti ensin. Sen ohjelmistokehityskustannus on pienin. Se on hyödyllinen tietyille kyselytyypeille ja tuottaa usein hyötyä heti.

Lisää agenttipohjainen RAG monimutkaisiin kyselyihin. Tunnista kyselyt, joissa perinteinen RAG toimii huonosti. Rakenna niitä käsittelevä agentti ja reititä kyselyt sille ehdollisesti.

Lisää graafi-RAG viimeisenä. Sen ohjelmistokehityskustannus on suurin. Se kannattaa vain, jos suhteisiin perustuvat kyselymallit ovat selkeitä.

Tämä järjestys vastaa yleensä investoinnin tuottoa. Pitkä konteksti: pieni kustannus, todellista arvoa. Agenttipohjainen: kohtuullinen kustannus, korjaa todellisia puutteita. Graafi: suuri kustannus, tarkat käyttötapaukset.

Täydennä, älä korvaa

Perinteinen paloihin perustuva RAG on työjuhta, mutta sillä on rajansa. Paloja pidemmälle menevät muunnelmat — graafi-RAG, agenttipohjainen RAG ja pitkän kontekstin RAG — mahdollistavat kukin erilaisia asioita.

Ratkaisu ei ole perinteisen RAG:n korvaaminen vaan täydentäminen. Kypsät järjestelmät käyttävät useita muunnelmia, reitittävät kyselyt tarkoituksenmukaisesti ja antavat kunkin käsitellä sille sopivat kyselyt.

Investointi on merkittävä, sillä jokainen muunnelma vaatii todellista ohjelmistokehitystyötä. Kun perinteisen RAG:n laatu ei enää parane, lisäominaisuuksien tuoma hyöty on kuitenkin todellinen. Vain hakukyselyt hyvin käsittelevä järjestelmä on paljon vähemmän hyödyllinen kuin järjestelmä, joka käsittelee myös suhteisiin perustuvia, monimutkaisia ja koko aineistoa koskevia kyselyjä.

Kartoita kyselysi. Tunnista ne, joissa perinteinen RAG toimii huonosti. Valitse sopiva muunnelma, rakenna täydennys ja kehitä sitä iteratiivisesti.

Näin RAG-järjestelmä kasvaa joissakin kyselyissä hyödyllisestä aidosti kyvykkääksi todellisten kysymysten koko kirjossa.