LangChain, nebo LlamaIndex: základ pro agenta a RAG

Pro aplikaci, jejíž složitost spočívá v řízení nástrojů a stavu, zvolte jako výchozí základ LangChain. Pokud většinu návrhové práce představuje načítání dokumentů, tvorba indexu a vyhledávání podkladů pro odpověď, začněte u LlamaIndexu. U systému, který potřebuje obojí, mohou oba frameworky dostat oddělenou úlohu.

Jde o volbu podle hlavního úzkého místa, nikoli o trvalý žebříček rychlosti. LlamaIndex umí stavět agenty a LangChain lze použít pro RAG; rozdíl je v tom, kterou část aplikace chcete navrhovat jako první. Výkon výsledné aplikace navíc závisí také na dokumentech, embeddingovém modelu, úložišti a době odezvy jazykového modelu.

Rozhodovací strom začíná u složitější vrstvy

Nejprve si pojmenujte práci, která bude vyžadovat nejvíc pravidel, změn a ladění. Odpověď vede k základu architektury:

Agent musí vybírat z několika nástrojů, uchovávat stav, čekat na schválení nebo pokračovat po přerušení: začněte agentní orchestrací v LangChainu a vyhledávání připojte jako nástroj.
Aplikace především načítá soubory z různých zdrojů, aktualizuje index a vybírá správné pasáže: začněte dokumentovou vrstvou v LlamaIndexu.
Obě části mají vlastní složitá pravidla: vymezte mezi nimi rozhraní. Dokumentová komponenta může přijmout dotaz a vrátit úryvky s metadaty; agent rozhodne, kdy ji zavolat.

Tento strom řeší složitost implementace lépe než otázka, který framework má více funkcí. Pro jednoduchý dotaz nad malou stabilní sadou textů může být rozsáhlý agentní pracovní tok zbytečnou vrstvou. Naopak samotný index neřídí pořadí několika externích akcí ani schvalování zásahu do systému.

Co přináší LangChain agentovi

Přehled LangChainu popisuje create_agent jako konfigurovatelný základ složený z modelu, nástrojů, promptu a middleware. Agenti využívají LangGraph, který podporuje perzistenci, pokračování běhu a zapojení člověka do rozhodování. Pro aplikaci s více nástroji jsou to podstatnější vlastnosti než pohodlí při vytvoření prvního vektorového indexu.

Uvažujme podmíněný příklad: asistent vyhledá interní pravidlo, ověří stav žádosti přes API a změnu provede až po schválení. Návrhový problém leží v pořadí kroků, přístupu k nástrojům a uchování stavu mezi nimi. V takovém toku záleží také na omezení nástrojů a schvalování, protože nalezená pasáž nemá sama udělovat oprávnění k akci.

Middleware může upravovat chování agenta, ale volba LangChainu sama neřeší kvalitu podkladů. Když vyhledávání vrací chybnou verzi dokumentu nebo pasáž vytrženou z kontextu, další kroky agenta mohou chybu převzít. Vyhledávací vrstvu je proto třeba navrhnout podle povahy korpusu, i když celou aplikaci řídí agent.

Co přináší LlamaIndex dokumentovému RAG

Úvodní příklad LlamaIndexu načítá soubory pomocí SimpleDirectoryReader, vytváří VectorStoreIndex a zpřístupňuje dotaz nad indexem jako nástroj agenta. Ukazuje také možnost nahradit hostované embeddingy lokálním modelem. Je tedy dobře vidět cesta od dokumentu přes index k odpovědi i možnost předat vyhledávání další vrstvě.

U měnícího se korpusu záleží na tom, jak se nové soubory načtou, rozdělí a znovu zpracují. Průvodce načítáním dat odděluje datové konektory, transformace včetně dělení textu a opakovatelnou ingestion pipeline s cache. To pomáhá tam, kde je drahé stále zpracovávat nezměněné podklady nebo kde metadata rozhodují o tom, který úryvek smí být použit.

Při jednoduchém korpusu může stačit načtení souborů a základní index. Složitější pipeline má hodnotu až ve chvíli, kdy se projeví konkrétní problém: aktualizace dokumentů mění výsledky, parser ztrácí důležité části nebo dělení textu odděluje tvrzení od jeho podmínek. Takové potíže se posuzují podle nalezených pasáží, ne podle toho, zda agent dokáže napsat plynulou odpověď.

Hybridní hledání a lokální provoz mají vlastní podmínky

Potřeba hybridního hledání sama o sobě neurčuje vítěze. Přehled vektorových úložišť LlamaIndexu uvádí filtrování metadat a hybridní hledání zvlášť pro jednotlivé backendy. Podporu je tedy nutné vztáhnout ke konkrétnímu úložišti a jeho integraci, ne ji připsat každému indexu vytvořenému ve frameworku.

Hybridní postup dává smysl například tehdy, když dotaz obsahuje přesný kód výrobku nebo označení ustanovení, ale zároveň hledá významově podobnou formulaci. Přesná shoda a sémantická podobnost řeší odlišné části problému; výsledky je třeba vhodně spojit a vyhodnotit na skutečných dotazech. Pokud se v korpusu pracuje s verzemi a oprávněními, musí tyto podmínky zachovat i filtry nad nalezenými pasážemi.

Podobně „lokální model“ neznamená automaticky lokální RAG. Lokální embeddingy pokrývají převod textu na vektory, zatímco generování odpovědi může stále volat vzdálený model. Pro provoz bez takového volání je třeba řešit také generativní model a úložiště. U českých dokumentů je zvlášť důležité vyzkoušet české dotazy a formulace: anglicky laděný ukázkový embeddingový model není důkazem dobrého vyhledávání v češtině.

Čísla z benchmarku patří ke konkrétní konfiguraci

Publikované srovnání Markaicode uvádí pro LangChain 0.3.10 a LlamaIndex 0.11.2 na autorem deklarované instanci AWS EC2 G4dn.xlarge odezvu prvního dotazu 1,424 proti 0,912 sekundy a paměť 3,8 proti 2,7 GB na 100 000 dokumentů. Tato čísla popisují tvrzený výsledek uvedených konfigurací, nikoli obecnou vlastnost současných verzí frameworků.

Ukázkový kód přiřazuje označení all-MiniLM-L6-v2 třídám OpenAIEmbeddings a OpenAIEmbedding a obě větve navíc výslovně nenastavují stejné dělení dokumentů. Z publikovaných ukázek proto nelze spolehlivě vyvodit, že samotná výměna frameworku způsobila uvedený rozdíl. Čtenáři z nich přesto získají užitečné upozornění: bez popisu modelů, indexu a podmínek běhu je tabulka latence slabým podkladem pro architektonickou volbu.

Pro vlastní aplikaci oddělte čas ingestování, vyhledání pasáží a generování odpovědi. Při srovnání ponechte stejný korpus, pravidla dělení, embeddingový i generativní model, úložiště, počet vracených pasáží a hardware. Vedle latence sledujte kvalitu nalezených úryvků a chování po aktualizaci dokumentů; u agenta také chybné volání nástrojů a navázání na přerušený běh. Tím zjistíte, která vrstva omezuje právě váš systém.

Kdy oba frameworky spojit

Spojení dává smysl, pokud dokumentový korpus potřebuje samostatná pravidla ingestování a vyhledávání, zatímco aplikace zároveň koordinuje další nástroje a stav. LlamaIndex může obsluhovat dotaz nad dokumenty a LangChain rozhodovat, kdy výsledek použít v pracovním toku. Přínos plyne z jasně oddělených odpovědností; samotné spojení nezaručuje rychlejší odpověď.

Rozhraní mezi vrstvami by mělo zachovat text nalezené pasáže, její původ a metadata potřebná pro rozhodnutí agenta. Pokud lze požadovanou aplikaci jednoduše sestavit v jednom frameworku, další závislost nemusí nic usnadnit. Druhou vrstvu má smysl přidat ve chvíli, kdy řeší doložené úzké místo lépe než rozšíření první.

Přečtěte si také: