LangChain vai LlamaIndex RAGiin? Viive voi kolminkertaistua

Dokumenttipainotteiseen RAGiin LlamaIndex on luonteva lähtökohta, kun taas LangChain sopii erityisesti sovellukseen, jossa haku liittyy muihin työkaluihin ja agentin päätöksiin. TildAlicen julkaisemassa RAG-vertailussa 10 000 Markdown-dokumentin aineistolla LangChain-putken keskimääräinen vastausviive oli 1,85 sekuntia ja LlamaIndex-putken 0,62 sekuntia: ero oli lähes kolminkertainen, ja oikea katkelma löytyi kummassakin viiden kärjestä 94 kysymyksessä sadasta.

Vertailu koskee kahta rakennettua kokonaisuutta, joten nopeuslukua ei voi siirtää suoraan oman palvelun kehysvalintaan. Ratkaisevaa on erottaa toisistaan aineiston indeksointi, varsinaisen haun laatu, kielimallille koottu konteksti ja mahdollisten agenttivaiheiden kustannus.

Miksi samasta hausta syntyi eri vastausviive?

Mittauksen putkissa oli sama upotusmalli ja FAISS-vektorihaku. Raportoidussa vaihejaossa kyselyn upottaminen ja vektorihaku kestivät lähes yhtä kauan, mutta dokumenttien tai solmujen kokoaminen ja kielimallikutsu erosivat enemmän. Näin käyttäjän kokema viive voi kasvaa, vaikka varsinainen hakukone ei juuri hidastuisi. Tuloksen perusteella nopeuseroa ei pidä selittää pelkällä kehyksen nimellä.

Kirjoittajan LangChain-toteutus kokosi haetut katkelmat samaan kehotteeseen stuff-tavalla; LlamaIndex-toteutus käytti compact-vastaustilaa. Kun kielimallille päätyvän tekstin määrä muuttuu, myös mallikutsun kesto voi muuttua. Raportissa LangChainin mallikutsun viive tasoittui katkelmien määrää rajoittamalla, mikä tekee kehotteen koostamisesta olennaisen osan vertailua. Compact-tila sovittaa katkelmia käytettävissä olevaan kehoteikkunaan ja voi käsitellä loput erillisissä kutsuissa; sitä ei pidä tulkita yleiseksi automaattiseksi lyhennystakuuksi.

Vertailun toistettavuudessa on myös käytännön raja. Esimerkkikoodissa LangChainin pilkkoja laskee merkkejä, kun taas LlamaIndexin pilkkojan koko ilmoitetaan tokeneina. Samaksi kuvattu lohkokoko ei siis välttämättä tuota samanpituisia katkelmia. Sivulla ilmoitettu aineistokoko ja koodin katkelmamäärä eivät myöskään sovi yhteen esitetyn pilkkomiskoon kanssa. Raportissa käytettyjen kirjastoversioiden varaan ei voi rakentaa nykyisen asennuksen suorituskykytakuuta. Näistä syistä lukema kertoo juuri kuvatuista toteutuksista eikä nykyisten versioiden pysyvästä nopeusjärjestyksestä.

Miten indeksointi vaikuttaa hakutulokseen?

LlamaIndex rakentaa aineistosta Document-olioita ja niiden osista Node-solmuja. LlamaIndexin Document- ja Node-kuvauksen mukaan solmu voi periä lähdedokumentin metatiedot ja säilyttää suhteita muihin solmuihin. Kun tiedoston tunniste, otsikko tai muu alkuperätieto kulkee katkelman mukana, sovellus voi näyttää, mistä vastauksen tausta-aineisto löytyi.

Rakenne ei yksin takaa hyvää hakua. Liian lyhyt katkelma voi irrottaa vastauksen asiayhteydestä, kun taas suuri katkelma vie enemmän tilaa kielimallin kehotteesta. Aineiston pilkkominen, metatietojen säilyminen ja indeksin päivitys lähteen muuttuessa kannattaa arvioida yhtenä kokonaisuutena. LangChainin puolella samat kysymykset ratkaistaan dokumenttien, pilkkojan ja valitun tietovaraston asetuksilla; toteutustapa vaikuttaa sekä palautuviin katkelmiin että viitteiden jäljitettävyyteen.

Kummassa oma hakulogiikka on helpompi liittää mukaan?

LangChainin retriever-rajapinnan kuvauksessa hakija voi olla myös kehyksen ulkopuolella rakennettu komponentti. Tämä sopii tilanteeseen, jossa sovelluksella on jo oma hakupalvelu, useita tietolähteitä tai erityinen tulosten järjestämistapa. Rajapinnan idea on erottaa relevanttien dokumenttien palauttaminen muusta vastausketjusta.

LlamaIndex ei silti lukitse käyttäjää valmiiseen vektorihakuun. Sen kyselyvaiheiden ohje erottaa haun, solmujen jälkikäsittelyn ja vastauksen muodostuksen sekä näyttää, miten hakija ja suodatus vaihdetaan. Kehyseroa kuvaa siksi paremmin painopiste kuin sallittujen toimintojen lista: LlamaIndex antaa dokumenttien käsittelyyn valmiin rungon, LangChain käsittelee hakijaa helposti vaihdettavana osana laajempaa sovelluslogiikkaa. Oman haun tarvitsemat rajapinnat kannattaa verrata sillä toteutuksella, jota sovellus todella käyttää.

Milloin agentti muuttaa valintaa?

Suora kysymys, haku ja vastaus muodostavat eri työnkulun kuin agentti, joka päättää haun tarpeesta, käyttää muita työkaluja ja yrittää uudelleen heikon osuman jälkeen. LangChainin LangGraphin RAG-esimerkissä päätös haun tekemisestä, löydettyjen dokumenttien arviointi ja kysymyksen uudelleenmuotoilu ovat erillisiä vaiheita. Tällainen ohjaus on hyödyllinen, jos sovellus todella tarvitsee haarautuvaa päätöslogiikkaa.

Jokainen uusi arviointi, lisähaku ja mallikutsu voi kasvattaa kokonaisviivettä. Siksi suoraviivaisen dokumenttihaun nopeustesti ei kerro agenttijärjestelmän vasteajasta. Agenttitarpeen kannalta olennaista on, kuinka selvästi työnkulun tilat, palautumiset ja työkalujen tulokset voi kuvata ja ylläpitää. LlamaIndexilläkin voi rakentaa agentteja; LangGraphin etu tässä vertailussa on erityisesti eksplisiittisen, haarautuvan työnkulun malli.

Miten lähdeviitteet pysyvät mukana vastauksessa?

Lähdeviite alkaa jo aineiston latauksesta. Jos lähdetunniste katoaa ennen pilkkomista tai suodatusta, loppuvaiheen vastaus ei voi palauttaa sitä luotettavasti. LlamaIndexin solmuihin periytyvät metatiedot ja kyselyvastauksen lähdesolmut helpottavat alkuperän seuraamista. LangChainissa vastaava tieto on kuljetettava hakijan palauttamasta dokumentista läpi kehotteen ja vastauksen käsittelyn.

Kumpikaan rakenne ei itsessään osoita, että jokainen muodostettu väite perustuu juuri sen vieressä näytettyyn lähteeseen. Haun onnistuminen, vastauksen uskollisuus katkelmille ja käyttöliittymän viitteet ovat erillisiä laatukysymyksiä. Jos sovelluksen on näytettävä täsmälliset viitteet, arvioinnissa kannattaa tarkastaa sekä palautetut lähteet että se, mihin väitteisiin ne lopullisessa vastauksessa liitetään.

Pieni koe omalla aineistolla erottaa olennaiset erot

Valitse kummallekin kehykselle sama edustava aineistonäyte ja kysymyksiä, joiden oikeat lähteet tiedetään ennakolta. Mukaan kannattaa ottaa sekä yhden katkelman kysymyksiä että tapauksia, joissa vastaus tarvitsee tietoa eri kohdista. Näin vertailu paljastaa sekä osumisen että sen, miten kehys kokoaa löytämänsä aineiston kielimallille.

1. Pidä kielimalli, upotusmalli, aineisto ja palautettavien katkelmien määrä samoina. Kirjaa kirjastoversiot sekä erot pilkkomisessa ja kehotteen rakentamisessa, jos niitä ei voi tasata.
2. Mittaa erikseen indeksointi, haku, mallikutsu ja käyttäjän näkemä kokonaisviive. Tarkista myös, paljonko kontekstia mallille päätyy; sama haku voi johtaa eripituisiin kehotteisiin.
3. Merkitse etukäteen, mittaatko oikean lähteen löytymistä kärkijoukkoon vai relevanttien tulosten osuutta palautetuista katkelmista. Ensimmäinen on kysymyskohtainen osumaosuus, jälkimmäinen hakutulosten tarkkuus.
4. Lisää vain sovellukselle tarpeelliset lähdeviitteet, oma hakija ja mahdollinen agentin työkalukutsu. Mittaa sen jälkeen koko putki uudelleen, sillä juuri nämä osat muuttavat arkkitehtuuripäätöksen hintaa.

Jos työ painottuu dokumenttien lataamiseen, indeksointiin ja lähteiden jäljittämiseen, LlamaIndex on perusteltu ensimmäinen toteutus. Jos haku on vaihdettava osa useita työkaluja käyttävää, haarautuvaa prosessia, LangChain ja LangGraph ovat luonteva lähtökohta. Oman aineiston koe ratkaisee, kumpi toteutus täyttää samanaikaisesti laatu- ja viivevaatimukset.

Lue myös:

• GraphRAG vai vektori-RAG? Kysymyksen rakenne ratkaisee valinnan
• Claude Code vai Codex? Valinta ratkeaa työnkulkuun, ei yhteen testiin
• Signal vai WhatsApp? Salaus on vahva, mutta metatiedot erottavat