LangChain apo LlamaIndex: orkestrimi dhe rikërkimi nuk kushtojnë njësoj

Për një sistem RAG, zgjidhni LangChain kur vështirësia kryesore është të përcaktoni se kur agjenti kërkon dokumente, përdor mjete të tjera ose provon sërish. Dokumentacioni i LangChain shpjegon se agjentët e tij përdorin komponentët e LangGraph dhe se një agjent RAG mund të ndërtohet drejtpërdrejt me ta për kontroll më të imët. Ky kontroll ka vlerë kur degëzimet janë pjesë e kërkesës së produktit, por shton logjikë që ekipi duhet ta mirëmbajë.

Zgjidhni LlamaIndex kur puna kryesore është të ktheni dokumentet e brendshme në kontekst të përshtatshëm për përgjigjen. Udhëzuesi RAG i LlamaIndex përfshin motorë të gatshëm pyetjesh dhe rrjedha të personalizuara mbi burime si PDF, Notion e Slack. Të dy framework-et mbështesin rikërkimin dhe orkestrimin; dallimi i dobishëm për zgjedhjen është se cilën pjesë të sistemit doni të ndërtoni, të ndryshoni dhe të diagnostikoni më shpesh. Edhe kostoja e matur lidhet me rrjedhën konkrete, jo vetëm me emrin e framework-ut.

Dy arkitektura minimale për të njëjtën kërkesë

Merrni si shembull hipotetik një asistent që u përgjigjet pyetjeve mbi dokumentacionin e brendshëm të një produkti. Ai merr pyetjen, gjen fragmente përkatëse, ia jep modelit si kontekst dhe kthen një përgjigje të mbështetur në ato fragmente. Kërkesa funksionale është e njëjtë për të dyja qasjet; ndryshon mënyra si shprehen lidhjet mes përgatitjes së dokumenteve, rikërkimit dhe vendimeve të agjentit.

Në një zbatim minimal me LangChain, dokumentet ngarkohen, ndahen në fragmente, kthehen në paraqitje vektoriale dhe ruhen për rikërkim. Rikërkuesi mund t’i jepet agjentit si mjet, që ai ta thërrasë kur pyetja kërkon informacion nga dokumentet. Nëse produkti kërkon kontroll të veçantë për vlerësimin e fragmenteve ose për një kërkim alternativ, LangGraph lejon që këto vendime të modelohen si hapa dhe kalime të shprehura qartë. Kjo e bën të dukshëm vendimin e rrugëzimit, por kërkon edhe gjendje, kushte kalimi dhe trajtim të secilës rrugë ekzekutimi.

Në një zbatim minimal me LlamaIndex, pika e nisjes janë dokumentet, indeksi dhe motori i pyetjeve. Shembulli zyrtar i VectorStoreIndex ngarkon dokumente me SimpleDirectoryReader dhe ndërton indeksin me VectorStoreIndex.from_documents; gjatë këtij procesi dokumentet ndahen në nyje që ruajnë metadata dhe lidhjet me burimin. Kështu, ndarja dhe përshkrimi i fragmenteve bëhen pjesë e qartë e arkitekturës. Indeksi i shembullit ruhet në memorie si parazgjedhje, ndaj një shërbim që duhet t’i mbajë të dhënat ndërmjet ekzekutimeve kërkon një zgjidhje të veçantë ruajtjeje.

Asnjëra arkitekturë minimale nuk e zgjidh vetvetiu cilësinë e përgjigjes. Në të dyja, dokumentet duhet të përgatiten, pyetja duhet të sjellë fragmente të dobishme dhe modeli duhet të marrë kontekst brenda kufijve të tij. Zgjedhja e framework-ut ndryshon kryesisht vendin ku ekipi e shpreh këtë punë: në një rrjedhë të agjentit me vendime të kontrolluara, apo rreth indeksit dhe mënyrës si rikthehet konteksti.

Ku shfaqet vështirësia: te konteksti apo te vendimet?

Kur përgjigjja ekziston në dokumente, por nuk hyn në fragmentet e rikthyera, problemi është te përgatitja ose kërkimi i kontekstit. Një PDF mund të ndahet në vende të papërshtatshme; metadata mund të mos ndihmojë në dallimin e versioneve; pyetja mund të drejtohet te burimi i gabuar. Për një ekip me shumë lloje dokumentesh, një pikënisje rreth ngarkimit, indeksimit dhe përzgjedhjes së fragmenteve e bën këtë problem më të drejtpërdrejtë për t’u trajtuar.

Kur fragmentet e duhura gjenden, por përgjigjja varet nga zgjedhja mes bazës së dokumenteve, kërkimit në web dhe një mjeti tjetër, vështirësia zhvendoset te rrjedha. Hapat e shprehur në LangGraph e bëjnë të mundur të dalloni një vendim të gabuar të rrugëzimit nga një rikërkim i dobët. Çmimi i këtij kontrolli është kompleksiteti i degëzimeve: ndryshimi i një kushti mund të prekë disa rrugë të agjentit, edhe kur indeksi i dokumenteve mbetet i njëjtë.

LlamaIndex nuk kufizohet te një pyetje e drejtpërdrejtë mbi indeksin. Përshkrimi i koncepteve të LlamaIndex përfshin agjentë që zgjedhin mjete dhe Workflows që orkestrojnë hapa të bazuar në ngjarje. Një ekip mund të nisë nga rikërkimi dhe të shtojë më pas degëzime pa ndërruar domosdoshmërisht framework. Prandaj pyetja vendimtare nuk është cili produkt e zotëron një aftësi, por sa logjikë të personalizuar kërkon rrjedha që po ndërtohet.

Çfarë matet realisht si kosto

Koha e orkestrimit dhe përdorimi i modelit janë shpenzime të ndryshme. E para lidhet me punën e brendshme të framework-ut për gjendjen dhe kalimet; e dyta ndikohet nga numri i thirrjeve të modelit, përmbajtja e kërkesave dhe sasia e kontekstit të dërguar. Një rrjedhë që shton vlerësim dokumentesh, vlerësim përgjigjeje dhe kërkim rezervë mund të ndryshojë përdorimin e tokenëve edhe kur pyetja e përdoruesit mbetet e njëjtë.

Në benchmark-un e AIMultiple, pesë zbatime të së njëjtës rrjedhë agjentike u krahasuan me 100 pyetje të përsëritura 100 herë; në atë konfigurim, overhead-i mesatar ishte rreth 6 ms për LlamaIndex, 10 ms për LangChain dhe 14 ms për LangGraph, ndërsa përdorimi mesatar ishte rreth 1 600 tokenë për LlamaIndex dhe 2 400 për LangChain. Testi standardizoi modelin, rikërkuesin, mjetin e kërkimit dhe kufirin e kontekstit. Rrjedha përfshinte rrugëzim, vlerësim të dokumenteve, gjenerim dhe vlerësim të përgjigjes, prandaj matjet i përkasin këtyre zbatimeve të plota.

Në këto kushte, diferenca e kohës së brendshme të orkestrimit ishte e vogël krahasuar me thirrjet e jashtme. Përdorimi i tokenëve ndryshoi më shumë, pjesërisht sepse framework-et e formojnë kontekstin dhe mesazhet në mënyra të ndryshme, ndërsa rrugëzimi mund të zgjedhë mjete të ndryshme. Kjo e bën të pasaktë kthimin e renditjes së testit në një tarifë ose parashikim të përgjithshëm për çdo aplikacion RAG. Një rrjedhë e thjeshtë rikërkim–përgjigje ka tjetër profil nga rrjedha agjentike e matur.

Për një korpus në shqip, sidomos me dokumente nga Shqipëria dhe Kosova, krahasimi i dobishëm duhet të përfshijë pyetjet dhe dokumentet që sistemi do të përdorë vërtet. Cilësia e fragmenteve të rikthyera mund të ndryshojë sa kontekst i dërgohet modelit dhe sa shpesh aktivizohet një rrugë rezervë. Tokenët, koha e thirrjeve të jashtme dhe koha e orkestrimit duhen parë veçmas; përndryshe një përgjigje e ngadaltë mund t’i atribuohet gabimisht framework-ut.

Pema e vendimit për ekipin

Zgjedhja bëhet më e qartë kur nis nga forma e rrjedhës që kërkon produkti. Lista e integrimeve ka rëndësi vetëm pasi të dihet nëse kufizimi kryesor është kontrolli i vendimeve apo cilësia e kontekstit.

1. Kur përgjigjja kërkon degëzime të përcaktuara, si vlerësim të fragmenteve, kërkim alternativ dhe një provë tjetër, nisni me LangChain dhe shprehni kontrollin e nevojshëm në LangGraph. Llogaritni edhe punën për mirëmbajtjen e gjendjes dhe të kushteve të kalimit.
2. Kur përgjigjja varet nga burime të ndryshme dokumentesh, nisni me LlamaIndex dhe përqendrojeni zbatimin te ngarkimi, ndarja, metadata dhe cilësia e rikërkimit. Shtoni logjikë agjenti kur kërkesat e produktit e bëjnë të nevojshme.
3. Kur rrjedha është vetëm rikërkim dhe përgjigje, përdorni zbatimin më të vogël që ekipi mund të mirëmbajë. Një graf me më shumë hapa ose një motor më kompleks kërkimi ka kuptim kur zgjidh një problem konkret të rrjedhës ose të kontekstit.

Nëse vendimi paraprak është nëse dokumentet duhen rikërkuar apo njohuria duhet futur në model, krahasimi mes RAG dhe fine-tuning trajton atë dallim. Pasi është zgjedhur RAG, arkitektura më e përshtatshme varet nga vendi ku ekipi pret punën më të madhe: te drejtimi i agjentit apo te ndërtimi i kontekstit të saktë.

Lexoni gjithashtu:

• RAG apo fine-tuning: dokumentet që ndryshojnë favorizojnë rikërkimin
• GitHub Codespaces apo Ona: integrimi i lehtë përballet me kontrollin e cloud-it
• Brave apo Firefox: privatësia standarde përballet me kontrollin e imët