Haystack vai LlamaIndex? Valitse RAG työnkulun mukaan

Valitse Haystack, kun dokumenttien käsittely, haku ja vastauksen muodostaminen on luontevaa kytkeä näkyväksi komponenttiputkeksi. Haystackin putkimallissa komponenttien syötteet ja tulosteet yhdistetään toisiinsa, ja rakenne voi sisältää myös haaroja ja silmukoita. Tämä antaa kehittäjälle selkeän paikan muuttaa yksittäistä käsittelyvaihetta.

Valitse LlamaIndex Workflows, kun seuraava vaihe riippuu prosessin aikana syntyvästä tapahtumasta: haun tuloksesta, työkalun vastauksesta tai ihmisen syötteestä. Workflows-mallissa vaihe vastaanottaa tapahtuman ja palauttaa tapahtuman, joka käynnistää seuraavan vaiheen. Molemmilla voi rakentaa RAG-sovelluksia ja agentteja. Valintaa ohjaa siksi ennen kaikkea se, kummalla tavalla oman sovelluksen eteneminen on helpompi ilmaista.

Onko tehtävä hakuketju vai agentin ohjaama prosessi?

Rajatussa RAG-sovelluksessa työn järjestys on usein ennakoitava: aineisto valmistellaan hakua varten, kysymykseen etsitään sopivia kohtia ja malli muodostaa vastauksen niiden pohjalta. Kun samat vaiheet toistuvat jokaisella kyselyllä, Haystackin kytketyt komponentit tekevät hakureitistä suoraan näkyvän. LlamaIndexissäkin tähän voi käyttää yksinkertaisempia haku- ja kyselyrakenteita; Workflowsia ei tarvitse ottaa käyttöön vain siksi, että sovellus käyttää LlamaIndexiä.

Agentissa ohjaus muuttuu, jos malli valitsee työkalun, tekee uuden haun tai jatkaa välituloksen perusteella eri suuntaan. Haystackin putkeen voi rakentaa tällaisia haaroja ja silmukoita, ja sillä on myös erillinen Agent-rajapinta. Workflowsissa haaran valinta voidaan kirjoittaa vaiheen Python-logiikkaan ja ilmaista seuraavan tapahtuman tyypillä. Ero koskee siis ohjauksen esitystapaa, ei yksinoikeutta monivaiheiseen toimintaan.

Mitä dokumenteille tapahtuu ennen hakua?

Datan sisäänotossa kannattaa erottaa lähteen lukeminen, sisällön muuntaminen, pilkkominen ja indeksointi. LlamaIndexin sisäänoton ohje kuvaa lataajat, Document- ja Node-oliot, tekstin muunnokset sekä toistettavan ingestion-putken. Se tarjoaa valmiita rakennusosia etenkin silloin, kun aineisto tulee useista lähteistä. Käytettävissä oleva liitin on silti vasta alku: sen tuottaman sisällön on sovittava haun tarpeisiin.

Haystackissa indeksointi voidaan rakentaa omaksi putkekseen, jossa esimerkiksi muunnos, puhdistus, pilkkominen ja kirjoitus dokumenttivarastoon ovat erillisiä komponentteja. Tämä sopii tilanteeseen, jossa kunkin vaiheen paikka ja tulos halutaan määritellä tarkasti. Kummankaan kehyksen rakenne ei yksin ratkaise hankalan PDF-aineiston laatua. Jos lähteissä on taulukoita tai monimutkainen sivuasettelu, valintaan vaikuttaa se, säilyykö vastauksen kannalta olennainen sisältö käyttökelpoisena pilkkomisen jälkeen.

Missä virheen syy näkyy?

Haystackin putki kuvaa komponenttien väliset yhteydet etukäteen. Tämä on hyödyllistä, kun on selvitettävä, muuttuiko sisältö vääräksi jo puhdistuksessa, palauttiko hakija väärät kohdat vai muodostuiko vastaus löydetystä aineistosta huolimatta huonosti. Yhteyksiä tarkistetaan putkea rakennettaessa, ja putken voi tallentaa YAML-muotoon. Vastineeksi kehittäjä määrittelee kytkennät ja huolehtii komponenttien syötteiden yhteensopivuudesta.

Workflowsissa tapahtumatyypit kuvaavat vaiheiden välisiä siirtymiä, mutta päätös seuraavasta tapahtumasta voi syntyä vaiheen sisällä. Se voi olla luettavampi ratkaisu, jos sama prosessi kulkee eri reittejä haun tuloksen tai hyväksyjän vastauksen mukaan. Tällöin tapahtumien nimet, jaettu tila ja välitulosten kirjaaminen tarvitsevat yhtä paljon huomiota kuin putken komponentit: muuten ajon kulkua on vaikea selvittää jälkikäteen. Kummassakaan mallissa pelkkä rungon valinta ei selitä sovelluksen omia päätössääntöjä.

Asynkronisuus ja ihmisen hyväksyntä

Asynkroninen ajo ei yksin erottele vaihtoehtoja. Haystackin putki voi suorittaa toisistaan riippumattomia komponentteja rinnakkain, kun niiden riippuvuudet sen sallivat. Sen Agent-rajapinnan run_async-kuvaus kertoo lisäksi, että agentti käsittelee viestejä ja työkaluja asynkronisesti ja käyttää keskustelugeneraattorin run_async-metodia, jos se on saatavilla. Workflowsissa asynkroniset vaiheet ja rinnakkainen työ liittyvät tapahtumien ohjaamaan etenemiseen.

Ratkaisevampaa on, mitä sovellus odottaa. Useat toisistaan riippumattomat haut voivat edetä rinnakkain kummassakin mallissa, mutta ihmisen hyväksyntä on erilainen odotus: tarkistajan vastauksen pitää ohjata prosessi oikeaan jatkokohtaan. Workflowsissa ihmisen syöte voidaan ilmaista osaksi tapahtumaketjua. Haystackin agentissa vuorovaikutusta voidaan ohjata myös hook-mekanismilla; hyväksynnän paikka riippuu valitusta putki- tai agenttirakenteesta. Jos odotus kestää yli yhden ajokerran, myös tilan säilyminen ja jatkaminen on suunniteltava erikseen.

Valintamatriisi työn muodon mukaan

Datan sisäänotto: LlamaIndexin lataajat ja muunnosketju ovat luonteva lähtökohta, kun lähteiden kokoaminen vie suuren osan työstä. Haystack sopii, kun valmistelun jokainen vaihe halutaan nimetä erilliseksi putkikomponentiksi.
Haun rakenne: Haystackin eksplisiittiset yhteydet palvelevat ennakoitavaa hakureittiä. LlamaIndexin haku voidaan liittää tapahtumien ohjaamaan prosessiin, jos kysely johtaa erilaisiin jatkotoimiin.
Haarautuminen: Haystack ilmaisee reitit komponenttien yhteyksissä; Workflows ilmaisee valinnan palautettavalla tapahtumalla. Molemmissa voi toteuttaa myös toistuvia vaiheita.
Asynkroninen työ: arvioi, mitkä haut ja mallikutsut ovat aidosti toisistaan riippumattomia. Pelkkä asynkronisen suorituspolun olemassaolo ei kerro oman sovelluksen viiveestä.
Ihmisen hyväksyntä: tapahtumamalli sopii prosessiin, jossa tarkistajan vastaus määrää seuraavan vaiheen. Haystackissa sama tarve voidaan sovittaa agentin vuorovaikutukseen tai erikseen rakennettuun ohjausreittiin.

Matriisin painot muuttuvat tehtävän mukana. Jos sovellus hakee dokumenteista vastauksen aina samalla tavalla, monivaiheisen agentin mahdollisuus ei tee monimutkaisemmasta rakenteesta tarpeellista. Jos taas haku on vain yksi vaihe hyväksyntöjä ja työkalukutsuja sisältävässä prosessissa, ohjauksen selkeys alkaa painaa enemmän kuin yksittäisen hakuketjun yksinkertaisuus.

Miksi yksi nopeusluku ei ratkaise valintaa?

Yleistä voittajaa ei voi päätellä irrallisesta viiveluvusta. Markaicoden vertailu poisti aiemmin esittämänsä varmentamattomat nopeusluvut ja julkaisi niiden tilalle toistettavan mittausrungon. Sen mukaan tulokseen vaikuttavat muun muassa dokumenttiaineisto, mallipalvelu, laitteisto ja putken asetukset. Yhden kokoonpanon lukema kertoo siksi vain kyseisestä kokoonpanosta.

Jos viive vaikuttaa valintaan, vertailun mielekäs yksikkö on sama tehtävä samalla aineistolla. Pilkkominen, upotusmalli, hakumenetelmä, haettujen tekstikohtien määrä ja vastausmalli on pidettävä mahdollisimman samoina. Sisäänotto, haku ja vastauksen muodostaminen kannattaa erottaa mittauksessa, koska ne kuormittavat järjestelmää eri tavoin. Samalla on tarkistettava, että molemmat toteutukset löytävät vastauksen kannalta oikeat lähdekohdat: muuten nopeampi tulos voi johtua kevyemmästä tai heikommasta hausta eikä kehyksen ohjaustavasta.

Lue myös: