LangChain vai LlamaIndex: vienāda precizitāte, trīskārša latentuma starpība

Vienā 10 000 tehnisku Markdown dokumentu pārbaudē LangChain un LlamaIndex konfigurācijām ziņots par vienādu 94 % izguves rezultātu, bet vidējais vaicājuma laiks bija attiecīgi 1,85 un 0,62 sekundes — aptuveni trīskārša starpība. Vienkāršai dokumentu jautājumu un atbilžu sistēmai tas padara LlamaIndex par pamatotu sākumpunktu, ja pārējie nosacījumi ir līdzīgi.

Pielāgotai izguves ķēdei vai aģentam ar dokumentu meklēšanu kā vienu no rīkiem ātrākais noklusējuma ceļš vairs nav vienīgais izvēles kritērijs. Jāsalīdzina tieši vajadzīgās darbplūsmas izguves kvalitāte, kopējais gaidīšanas laiks, atmiņas patēriņš un modeļa ievades apjoms. Publicētais mērījums attiecas uz konkrētām, atšķirīgi saliktām konfigurācijām, nevis uz visām iespējamām abu ietvaru ieviešanām.

Ko patiesībā mēra vienādais izguves rezultāts

Pārbaudē izmantotas LangChain 0.1.0 un LlamaIndex 0.9.28 versijas, viens iegulumu modelis un FAISS vektoru meklēšana. Publicētajos koda fragmentos LangChain sadala tekstu pēc rakstzīmju skaita, bet LlamaIndex fragmenta lielumu nosaka tokenos. Tātad vienāds skaitlis fragmentēšanas iestatījumā vēl nenozīmē vienādus fragmentus, pat ja dokumentu kopa un atgriezto fragmentu skaits šķiet saskaņoti.

Autors savu 94 % rādītāju nosauc par precision@5, taču aprakstītā procedūra skaita jautājumus, kuriem pareizais fragments atradās piecu pirmo rezultātu vidū. Tas pēc būtības ir veiksmīgas atrašanas īpatsvars jautājumu kopā; klasiskā precision@5 vērtētu, cik no visiem pieciem atgrieztajiem fragmentiem ir atbilstoši. Abām konfigurācijām vienāds šis rādītājs arī nenosaka, vai ģenerētās atbildes bija vienlīdz pareizas un pamatotas ar dokumentiem.

Vaicājuma laiks ietver ieguluma izveidi, meklēšanu, atrasto objektu apstrādi, uzvednes sagatavošanu un modeļa atbildi. Izmērītā starpība tādēļ nav tikai Python ietvara pieskaitāmo izmaksu rādītājs. Tests veikts ar senākām bibliotēku versijām, un publiskotie koda fragmenti ir vienkāršoti; precīzu rezultātu nevar pārnest uz jaunāku versiju vai citu modeļa pakalpojumu bez jauna mērījuma.

Konteksta režīms ietekmē gaidīšanu un cenu

Abās ķēdēs vektoru meklēšana ir tikai ceļa sākums. Pēc fragmentu atrašanas sistēma lemj, kā tos ievietot modeļa konteksta logā. Ja vienā vaicājumā modelim tiek nosūtīts vairāk tokenu vai jāveic papildu izsaukumi, var mainīties gan atbildes laiks, gan izmaksas. Šīs atšķirības ir jāatdala no pašas meklēšanas ātruma, citādi ietvaram tiek piedēvēts tas, ko radījusi atbildes veidošanas konfigurācija.

LlamaIndex atbildes režīmu aprakstā noklusējuma compact režīms apvieno atrastos fragmentus līdz modeļa konteksta loga robežai; ja teksts tajā neietilpst, tas tiek sadalīts un apstrādāts turpmākos modeļa izsaukumos. Savukārt simple_summarize ir režīms, kurā teksts tiek apgriezts līdz vienai uzvednei. Tāpēc compact izvēle pati par sevi nepierāda, ka liekie fragmenti klusējot atmesti un tieši tas izraisījis izmērīto ātruma vai cenas starpību.

Salīdzinot abus risinājumus vienam projektam, jāfiksē modelim faktiski nosūtītie ievades tokeni, ģenerētie tokeni un modeļa izsaukumu skaits katram jautājumam. Vienāds atrasto fragmentu skaits nav vienāds konteksta budžets. Ja abām ķēdēm nosaka vienādu nosūtītā teksta apjomu un vienādu atbildes veidošanas politiku, novērotā laika starpība var mainīties; tas ir pārbaudāms pieņēmums, nevis publicētā testa secinājums.

Vienkāršs dokumentu RAG

Ja uzdevums ir ielādēt dokumentus, izveidot indeksu un atbildēt uz jautājumiem ar atrastiem fragmentiem, LlamaIndex augsta līmeņa pieeja saīsina ceļu līdz strādājošai ķēdei. LlamaIndex Framework dokumentācija apraksta gan šo ceļu, gan zemāka līmeņa sastāvdaļas izguves un atbildes veidošanas pielāgošanai. Tāpat tā paredz RAG ķēdi izmantot kā rīku aģentā, ja lietotnes uzdevums vēlāk kļūst plašāks.

Šādai sistēmai izšķirošais nav tikai vidējais vaicājuma laiks. Jēgpilns salīdzinājums ietver kopējā vaicājuma mediānu un lēnāko vaicājumu grupu, maksimālo atmiņu indeksēšanas laikā, tokenus vienai atbildei un to, vai nepieciešamais fragments patiešām ir atrasts. Atsevišķi jāvērtē atbildes pareizība un tās pamatojums atrastajā tekstā. Latvijas lietotnei jautājumu kopā vajadzīgi arī latviešu valodas pieprasījumi un pašu dokumentu formāti: angļu tehnisko Markdown dokumentu pārbaude neatspoguļo, piemēram, skenētu līgumu vai daudzvalodu arhīvu.

Pielāgota izguves ķēde

Ja atbilde ir atkarīga no piekļuves tiesībām, metadatu filtriem, vairāku avotu apvienošanas vai fragmentu pārkārtošanas, izvēli nosaka tas, cik skaidri var salikt un uzturēt šos posmus. LangChain piedāvā maināmas ielādes, fragmentēšanas, iegulumu un glabāšanas sastāvdaļas; LlamaIndex arī ļauj aizstāt zemāka līmeņa komponentus. Neviena no šīm spējām pati par sevi negarantē labāku atbildi: svarīgi, kurā posmā pazūd vajadzīgais fragments un cik dārgi ir to atgūt.

Šeit jāmēra latentums pa posmiem — ieguluma izveide, meklēšana, filtrēšana, pārkārtošana un modeļa atbilde — kopā ar visa pieprasījuma laiku un maksimālo atmiņu. Kvalitātei jāskatās ne vien sākotnējā meklēšanas iznākumā, bet arī pēc filtriem un pārkārtošanas. Piemēram, ja piekļuves filtrs noņem neatļautu, taču ļoti līdzīgu fragmentu, tā radītais papildu laiks ir daļa no pareizas sistēmas darbības. Ietvara izvēli šādā gadījumā attaisno izmērāms uzdevuma kvalitātes ieguvums un uzturamas integrācijas.

Aģents ar RAG kā vienu rīku

Ja lietotne papildus dokumentu meklēšanai izsauc datubāzi, API vai citas darbības, viena RAG vaicājuma etalons vairs neapraksta lietotāja gaidīšanas laiku. LangChain izguves dokumentācija nošķir tiešu izguvi pirms atbildes no aģenta darbplūsmas, kurā modelis lemj, kad izmantot zināšanu iegūšanas rīku. Arī LlamaIndex atbalsta aģentus, tāpēc salīdzinājumā jāvērtē konkrēts uzdevums un rīku savienojums, nevis abu ietvaru vispārīgi apzīmējumi.

Aģentam lietderīga kvalitātes mēraukla ir pareizi pabeigts uzdevums ar atbilstošu pamatojumu; tai līdzās jāuzskaita visa uzdevuma lēnāko izpildes reižu laiks, rīku izsaukumu skaits, tokenu patēriņš un atmiņa ilgākā sarunā. Atkārtota meklēšana vai nevajadzīgs rīka izsaukums var aizēnot ieguvumu vienas izguves ātrumā. Tādēļ izvēle šeit vairāk saistīta ar rīku maršrutēšanu, kļūdu apstrādi un stāvokļa uzturēšanu; dokumentu meklēšanas ātrums paliek viens izmērāms posms plašākā darbplūsmā.

Lasiet arī:

• RAG vai modeļa pielāgošana: lielākai precizitātei ir sava cena
• Hugo.lv vai Tilde: vienā latviešu testā 10,8% pret 4,9%
• MailerLite vai Brevo: kontaktu skaits un sūtījumu apjoms apgriež cenu