
The abstractions are at the right level. I can go from raw documents to a working retrieval pipeline in just a few dozen lines, yet each layer—node parsing, embedding model, vector store, retriever, and response synthesizer—is swappable without having to rewrite everything else. We're running on the open-source framework, so the direct cost is zero and the value is easy to justify. The real cost is engineering time: keeping up with API changes across releases, and the work of tuning retrieval quality yourself. That trade-off has been worth it for us — building equivalent ingestion, chunking, retrieval, and agent orchestration in-house would have taken far longer than the time we've spent on upgrades. For teams evaluating this, the honest framing is that the framework is free but not effort-free, and you should budget for someone who maintains it as the library evolves. Review collected by and hosted on G2.com.
The pace of change is the biggest cost for me. Between the package split into llama-index-core plus separate integration packages, and the shift from the older query-engine patterns to Workflows, code we wrote a year ago has needed real rework. On top of that, blog posts and Stack Overflow answers are often written against an older API, so they’re less reliable as references.
The documentation reflects this churn: it’s broad, but the examples sometimes lag behind the current release. I often end up reading the source or digging through GitHub issues just to confirm what the current behavior actually is.
Debugging retrieval quality also feels more opaque than I’d like. When answers are wrong, it takes extra instrumentation to figure out whether the issue is chunking, embeddings, or the synthesis step, and the built-in observability only gets you part of the way. Review collected by and hosted on G2.com.