LlamaIndex teszt: a legszélesebb adat-eszközkészlet, aminek a súlypontja már elmozdult

A LlamaIndex MIT-licencű Python-keretrendszer, amely LLM-alkalmazásokat köt össze adatokkal. Konnektorok és indexabsztrakciók halmazaként indult retrievalre, és máig a legszélesebb ilyen eszközkészlet: a repository több mint 300 integrációs csomagot publikál modell-szolgáltatókhoz, embedding modellekhez, vektortárakhoz, dokumentum-betöltőkhöz és rerankerekhez. Ez a szélesség az oka, hogy a legtöbb csapat először ezzel találkozik, és az is, hogy hasznos marad akkor is, ha a cég figyelme már máshol jár. Az itt felvett állás egyszerű: használd az open source magot, és tudatosan döntsd el, melyik hosztolt részt veszed fel.

A modell-szolgáltató és az alkalmazás között helyezkedik el. A magban semmi nem beszél közvetlenül modell-szolgáltatóval; minden modell, embedder és vektortár egy integrációs csomagon keresztül érkezik, amely a mag egy absztrakt osztályát implementálja. Ez tiszta határ, és egyben a fő panasz forrása is: ugyanaz az absztrakciónak le kell fednie az OpenAI-t, egy helyi Ollama-folyamatot és egy tucat embedding modellt, így a hasznos közös nevező keskenyebb, mint a felület sugallja. A LangGraphgel ugyanazt az orchestrációs szerepet versenypályázza, a LangChainnel az adatkezelést, a kézzel összerakott vektortár-plusz-reranker kombinációval pedig a kényelmet versenyezi, nem a képességet.

Mi ez

A csomagstruktúra az első, amit ellenőrizni kell, és ott kezdődik a legtöbb zavar. A llama-index-core tartalmazza az absztrakciókat, és a Workflows-ot is mellé szállítja. A llama-index az induló csomag, amely a magot és egy választott integrációcsoportot telepíti. A Workflows önállóan is megjelent llama-index-workflows néven, és ha a magon keresztül érkezik, akkor llama_index.core.workflow néven importálják. Minden más külön telepítés, és csak ezért marad kezelhető a függőségi fa.

• MIT-licenc. A llama-index-core aktuális kiadása 0.14.25, 2026. szeptember 21-én.
• Több mint 300 integrációs csomag a PyPI-n, mindegyik vékony adapter a mag egy absztrakt osztálya fölött.
• A Workflows, az orchestrációs réteg eseményvezérelt: egy lépés egy eseményt kap, és egy másikat ad vissza, a framework pedig típusannotáció alapján irányít, nem deklarált él mentén.
• Az eseménygráfot a futás előtt validálja a framework. Elutasítja az olyan workflow-kat, ahol egy eseménynek nincs termelője, egy előállított eseménynek nincs fogyasztója, vagy nem érhető el végső esemény.
• A futások alapértelmezés szerint efemerisek. A perzisztencia opcionális Context.to_dict() pillanatképeken keresztül, vagy egy futásidejű pluginnon, mint a DBOS, amely a lépésátmeneteket adatbázisba naplózza.
• A framework gyakorlati célplatformja a Python. Csak a LiteParse, a cég új helyi parserje szállít bindingokat a Pythonon túl.

Hogyan működik a Workflows

A Workflows az a rész, amit érdemes megérteni, mert az is az, ami túléri a framework RAG-múltját. Egy workflow a Workflow egy alosztálya, amelynek metódusait a @step díszíti. Minden lépés egy eseménytípust fogad, és egy másikat ad vissza; a kezdeti eseménytípus visszaadása indítja a futást, a StopEvent visszaadása zárja. Az elágazások szokásos if utasítások, amelyek különböző eseménytípusokat adnak vissza, a hurok pedig olyan lépés, amely korábban kezelt eseménytípust ad vissza. A párhuzamosság egy list[Event]-et visszaadó lépés, egy list[Event]-et fogadó lépéssel párban, amely a gyűjtő.

• Adj vissza list[Event]-et, ha egy lépés véges halmazzal dolgozik, és minden munkaelemet előállíthat, mielőtt a további workerek elindulnak.
• Fogadj el list[Event]-et, ha a lépésnek az eredmények teljes halmazára szüksége van a folytatáshoz.
• Hívd a ctx.send_event(...) metódust, ha az események száma előre ismeretlen, vagy ha egy eseményt lépen kívülről kell kibocsátani.
• A ctx.store a futáson belüli megosztott állapotra való, a Resource(...) pedig azokra a kliensekre, modellekre és konfigurációra, amelyek nem kerülhetnek egy pillanatképbe.

A típusannotációk nem díszítőelemek, hanem teherhordók. Végrehajtás előtt a framework a lépésszignatúrákból levezeti az eseménygráfot, és megtagadja az indulást, ha van nem előállított esemény, elfogyasztatlanul maradó esemény vagy el nem érhető StopEvent. Ez olyan bekötési hibákat fog meg, amelyeket a kézzel megírt függvénykompozíció egyáltalán nem, és ez a tervezés legerősebb érve. Az ár az, hogy a szándékosan dinamikus workflow-nak a ctx.send_event-hez kell visszatérnie, és meg kell jelölnie, mely statikus ellenőrzések hagyhatók ki, ami gyakorlatban azt jelenti: minél képesebb egy workflow, annál kevésbé ellenőrizhető statikusan.

Első lépések

A legkisebb használható workflow körülbelül húsz sor. Két telepítési forma támogatott, és az importútban különböznek, ez a részlet szokott sokaknak megbukni:

import asyncio

from llama_index.core import VectorStoreIndex
from workflows import Workflow, step
from workflows.events import Event, StartEvent, StopEvent


class Answered(Event):
    question: str
    answer: str


class TriageFlow(Workflow):
    index: VectorStoreIndex

    @step
    async def retrieve(self, ev: StartEvent) -> Answered:
        retriever = self.index.as_retriever(similarity_top_k=8)
        nodes = await retriever.aretrieve(ev.question)
        best = max(nodes, key=lambda n: n.score or 0.0)
        return Answered(question=ev.question, answer=best.node.get_content())

    @step
    async def answer(self, ev: Answered) -> StopEvent:
        return StopEvent(result=ev.answer)


async def main():
    flow = TriageFlow(index=VectorStoreIndex.from_documents(documents), timeout=60)
    result = await flow.run(question="What is the refund window?")
    print(result.result)

asyncio.run(main())

A run() egy WorkflowHandler-t ad vissza. Awaitelhető, és ha nem awaitelsz azonnal, hanem megtartod a handlert, közben hozzáférsz a stream_events()-hez a folyamatjelzéshez. A timeout argumentum másodpercben értendő, és a konstruktorban adod át. Minden lépés szándékosan async, ezért egy önálló szkripthez egyetlen asyncio.run belépési pont kell; FastAPI-ben vagy jegyzetfüzetben nem szükséges.

Perzisztencia és újrapróbálkozás

A Workflows alapértelmezés szerint efemer: amint a run() visszatér, az állapot megszűnik, és a következő futás nulláról indul. Sok száz dokumentumra kiterjedő kiszámoláshoz, amelynek nem szabad nulláról újrakezdődnie, a dokumentáció checkpoint hurkot ír elő. A Context.to_dict() szerializálja a még folyamatban lévő eseményeket és az állapottárolót, a Context.from_dict() visszaépíti őket, a run(ctx=...) pedig egy másik folyamatban folytatja. Beépített checkpointer nincs: a futás belső StepStateChanged eseményt ad le, amikor egy lépés befejeződik, és ez a mentési jel.

import json

from workflows.events import StepState, StepStateChanged

handler = flow.run(question=q)

async for ev in handler.stream_events(expose_internal=True):
    if isinstance(ev, StepStateChanged) and ev.step_state == StepState.NOT_RUNNING:
        json.dump(handler.ctx.to_dict(), open("run.json", "w"))

result = await handler

# after a restart: resume from the last snapshot
ctx = Context.from_dict(flow, json.load(open("run.json")))
result = await flow.run(ctx=ctx)

A dizájn két tulajdonsága üzemeltetéskor jelentkezik. A folytatás at-least-once: az a lépés, amely a pillanatkép idején még futott, visszatekeredik és újrafut, tehát legfeljebb num_workers elem duplázódik. A pillanatkép pedig JSON, így ha a szerializáló nem tud kódolni egy értéket, a to_dict() feldob, és az egész mentés elhasal, nem csak az érintett mező. A nehéz bemenetek ezért Resource-be kerülnek, amely folytatáskor újraalkotódik ahelyett, hogy szerializálódna. Aki nem akarja magát kezelni a hurkot, használhatja a DBOS futásidejű plugint, amely a lépésátmeneteket adatbázisba naplózza, és nem kell hozzá checkpoint-kód.

Hol gyengül

A gyengeségek strukturálisak, nem bugok. A szélesség karbantartási felület: több száz integrációval egy frissítés olyan modell-wrappert is mozgathat, amelyet senki nem akart hozzáérni, és egy integráció rögzítése gyakran a mag rögzítését is jelenti. A magas szintű API annyit elrejt, hogy egy prototípus anélkül juthat productionbe, hogy bárki feljegyezné, melyik chunkméret, melyik top-k és melyik prompt-sablon adta a választ; az alapértékek kényelmesek, és nincsenek alapértékként dokumentálva. A perzisztencia opcionális és kézzel írandó, vagyis épp az ellentéte annak, amit egy hosszú életű batch feladat kér. És a framework mögötti cég nyíltan szűkítette a fókuszát, ami 2026-ban kínos értékelési tényező.

Végigolvasva a perzisztencia oszlopot a gyakorlati metszet jól látszik. A LangGraph alapértelmezetté teszi a checkpointot, és ezt azzal fizeti meg, hogy a gráf explicit, ami gondolkodási munka, viszont olvashatóságot vásárol. A Workflows a vezérlést normál Pythonban tartja, ami jobban olvasható és rosszabbul átlátható: egy workflow, amely 500 dokumentumra is kiterjed, 500 párhuzamos hívás, amelyek sorrendjét egyetlen eszköz sem segít meglátni. Egy csapat számára, amelynek munkája az állapotátmenetek átgondolása, ez rossz csere. Egy csapat számára, amely normál Pythont akar írni és elvárja, hogy előre nem láthatóan viselkedjen, ez jó csere.

Ide tartozik egy második megjegyzés. A dinamikus workflow elveszíti a statikus analízist, és a dokumentáció kimondja, hogy az el nem érhető lépések és az egyszeri események pontosan azok, amit ezek az ellenőrzések nem látnak. Aki kézzel rajzolt gráfot ültet át Workflows-ba, elég korán nyúl a skip_graph_checks opcióhoz, és ezzel csendben letiltja azt az ellenőrzést, amely az elhalt ágakat megtalálná, vagyis ugyanazt az ellenőrzést, amely eredetileg a bekötési hibát kiszúrta volna.

A fordulópont a dokumentumfeldolgozás felé

A repository README-je mostantól feltűnő jegyzetet visel: a LlamaIndex aktuális fókusza a dokumentumparsolás és kinyerés, a LlamaParse pedig a cég vállalati platformja ehhez. Ez megváltoztatja, hogy mit finanszíroz egy karbantartási keret. Az integrációs csomagok továbbra is megjelennek és működnek; az már nem garantált, hogy mindegyik bővül, amikor új szolgáltató jelenik meg.

• A LlamaParse a fizetős termék: agentikus OCR, parsolás, kinyerés és indexelés, kreditben értékesítve, nem felhasználói helyek szerint.
• A LiteParse az open source ellensúly: egy Rust parser, amely helyben fut, LLM, felhőfüggőség és API-kulcs nélkül, TypeScripthez, Pythonhoz, Rusthoz és böngészős WASM-hez való bindingokkal.
• A ParseBench és az ExtractBench a cég saját nyilvános benchmarkjai parsolásra és kinyerésre.
• A framework MIT-licencű marad, és megjelent a PyPI-n, a llama-index-core 0.14.25 verzióval 2026. szeptember 21-én.
• Az eredmény egy megosztott stratégia: nyílt eszközök a helyi parsoláshoz, hosztolt platform a nehéz dokumentumokhoz, és közöttük az agent-framework mint integrációs felület.

Ez megindokolható üzleti döntés, és enyhe figyelmeztetés mindenkinek, aki most keretrendszert választ. A halom azon részei, amelyeket leginkább karbantartanak, a fizetős fal mögött vannak, és a MIT-mag az, ami könyvtárként hasznos marad. Ezt úgy olvasd, hogy a framework hatókörét érdemes kicsire tartani: a Workflows-ot az orchestrációra használd, a betöltést és a parsolást tartsd házban, ahol ez lehetséges, és légy explicit abban, melyik hívások hagyják el az infrastruktúrádat.

Ítélet

Az ítélet az, hogy a LlamaIndex a legteljesebb válasz egy szűk kérdésre, hogyan kerülnek dokumentumok egy LLM-alkalmazásba saját integrációs réteg írása nélkül, és közepes válasz a tágabb kérdésre, hogyan kell orchestrálni egy agentet. A Workflows valóban jól fordítja elágazó logikát tipizált, validált Pythonná, és az at-least-once checkpoint modellje őszinte a saját hibaértelmezésével. Amit a framework nem kínál, az egy olyan futásideje, amelyre rámutathatsz és megnézhetsz: nincs állapotgráf átvizsgálásra, nincs alapértelmezett perzisztencia, és a karbantartás iránya nyilvánosan máshová tolódott.

1. Vedd, ha az adataid többsége dokumentum, és a konektor-, chunker-, embedder- és reranker-absztrakciók már meg vannak írva. Ez valódi megtakarítás, és ez volt az eredeti cél.
2. Vedd a Workflows-ot önálló, kis könyvtárként, ha az orchestráció elágazó, hurkozó Python, amely most az asyncio-ban összekeveredve él. A tipizált eseménygráf és az indulás előtti validáció az ok.
3. Ne válaszd egy olyan gráf miatt, amelyen végig kell gondolkodni. Ha az állapotátmenetek maguk a vizsgálandó anyag, az explicit gráf ver a Python vezérlési struktúrája.
4. Ne válaszd a hosztolt platform miatt. A LlamaParse, az Extract és az index szolgáltatás külön fizetős termék kreditárazással, és az ingestion-számládat frameworkhez kötni döntés, nem alapértelmezés.
5. Kerüld TypeScript- vagy Go stackhez. A mag Python, csak az új LiteParse parser szállít szélesebb bindingokat.
6. Értékeld újra egy év múlva, ha az integrációs szélesség hordozó. A cég parsolásra és kinyerésre fókuszáló iránya mellett a vektortár- és embedder-integrációk hosszú farka az, ami a leginkább kitett a lassú karbantartásnak.

The current focus of LlamaIndex is to build the best AI-powered engine for document parsing and extraction.

Ez a mondat a projekt README-jében áll, nem egy blogbejegyzésben, ami szokatlan és megjegyzésre érdemes: maguk a framework fenntartói nevezik meg, merre tart az ütterv. Mérnöki olvasatban ez azt jelenti, hogy az orchestrációs réteget karbantartják, de nem az a cél, a fizetős dokumentumfeldolgozás viszont az.

Források

1. LlamaIndex repository README and focus note
2. Agent Workflows: introduction
3. Agent Workflows: writing durable workflows
4. Agent Workflows: observability
5. LlamaAgents overview
6. llama-index-core on PyPI
7. LlamaIndex and LlamaParse pricing
8. LiteParse documentation
9. LangGraph on GitHub