# Why RAGFlow Keeps Trending After RAG Was Declared Dead > Source: > Published: 2026-08-14 03:08:10+00:00 [AI](https://sourcefeed.dev/c/ai)Article # Why RAGFlow Keeps Trending After RAG Was Declared Dead The 88k-star engine proves the bottleneck was document parsing all along, even as it drifts toward platform sprawl. [Priya Nair](https://sourcefeed.dev/u/priya_nair) "RAG is dead" has been declared at least three times now — first when 128k context windows landed, again when million-token models made stuffing whole corpora into a prompt look plausible, and once more when agentic search suggested models could just grep their way to answers. And yet [RAGFlow](https://ragflow.io), an open-source RAG engine that launched in April 2024, is sitting at 88k GitHub stars and still climbing the trending charts in August 2026. That's not nostalgia. It's a signal about where the actual bottleneck in document-grounded AI has been all along — and it was never the retrieval algorithm. ## The hard part was always parsing Every RAG tutorial starts the same way: split your documents into 512-token chunks, embed them, cosine-similarity your way to relevance. That works beautifully on clean markdown and falls apart the moment you feed it what enterprises actually have: scanned PDFs, financial statements with nested tables, slide decks, contracts where the meaning of clause 4.2(b) depends on a heading three pages back. Naive chunking shreds table rows away from their headers and returns confident garbage. RAGFlow's founding bet — the repo's original tagline was "quality in, quality out" — is that this ingestion step deserves a real computer-vision pipeline, not a regex. Its DeepDoc component runs OCR, layout recognition, and table-structure recognition before anything gets chunked, so a table survives as a table and a figure keeps its caption. Chunking is template-based per document type (papers, laws, resumes, manuals), the results are visible and editable in a UI, and answers cite the specific chunk they came from, highlighted in the source document. One practitioner writeup reported DeepDoc correctly parsing single-column tables that AWS Textract misreads — I haven't reproduced that benchmark myself, but it matches the general pattern of why people pick this tool: the parsing, not the retrieval. Compare the ecosystem's other posture. [LlamaIndex](https://www.llamaindex.ai) and LangChain treat parsing as a pluggable loader and monetize the hard part separately (LlamaParse is a paid cloud API). Haystack gives you clean pipeline abstractions and leaves document understanding largely to you. RAGFlow vertically integrated the ugly part into the open-source core, and that's the moat the star count reflects. ## What "drop it into your pipeline" actually means Here's the framing to be skeptical of: RAGFlow is routinely described as something you drop into an LLM pipeline. It isn't a library. There's no `pip install` that embeds it in your process. It's a platform — a Docker Compose stack pulling in Elasticsearch (or [Infinity](https://github.com/infiniflow/infinity), InfiniFlow's own AI-native database, or OpenSearch), MySQL, MinIO, and Redis, with a documented floor of 4 cores, 16 GB of RAM, and 50 GB of disk. You integrate over its HTTP API or Python/JS SDKs, point your app's chat endpoint at it, and treat it the way you'd treat a search cluster: infrastructure you operate, not a dependency you import. That distinction decides who should use it. If your corpus is clean markdown and your team is comfortable with pgvector, RAGFlow is overkill — fifty lines of code and a Postgres extension will beat operating a five-container stack. If your corpus is ten thousand scanned PDFs with tables that legal and finance actually query, the calculus flips: you were going to spend weeks building ingestion anyway, badly, and RAGFlow's parsing pipeline plus citation grounding is the part you'd never match in-house. Adoption in practice looks like: `docker compose up` , pick a chunking template per knowledge base, spot-check the chunk visualization on your worst documents (this step is the whole point — do not skip it), then wire the retrieval API into whatever agent framework you already run. MCP support means Claude or any MCP client can use a RAGFlow knowledge base as a tool without custom glue. ## The scope-creep question The v0.26 line, shipped through June and July, is where you can watch RAGFlow deciding what it wants to be. It added data connectors for SharePoint, OneDrive, Teams, Slack, Salesforce, and BigQuery; chat-channel deployments to WhatsApp, Discord, Telegram, DingTalk, and WeCom; GraphRAG indexing with checkpoint/resume; orchestrable ingestion pipelines replacing the old fixed chunking templates; and a visual agent builder on top of it all. The project now brands itself as a "context layer for LLMs" — a rebrand that rides the context-engineering wave and conveniently sidesteps the "RAG is dead" discourse entirely. Some of this is genuinely load-bearing. The composable ingestion pipeline is the right answer to a real limitation — a dozen fixed chunking templates couldn't cover the variety of documents production users throw at it. Connectors matter because the documents live in SharePoint whether you like it or not. But the chat channels and agent canvas put RAGFlow in direct collision with [Dify](https://dify.ai) and the broader low-code LLM-app crowd, a space that's already crowded and where RAGFlow has no particular edge. The risk is a familiar open-source failure mode: the differentiated core (parsing) starves while the team chases platform breadth. The issue tracker already shows the tension — parser-quality questions sitting alongside WhatsApp-integration feature requests. ## Verdict RAGFlow is production-viable today for the specific job it's best at: turning messy, table-heavy, scanned document collections into a queryable, citation-grounded knowledge layer you self-host under Apache 2.0. The monthly release cadence is real, the parsing differentiation is real, and the trade-offs are legible — a heavy footprint, an opinionated API-first workflow, and per-document-type tuning that demands hands-on attention. Judged as an embeddable RAG component, it's the wrong shape; judged as self-hosted knowledge infrastructure, it's arguably the strongest open-source option right now. The larger lesson from its staying power is worth internalizing even if you never deploy it: two years of "RAG is dead" takes were aimed at retrieval, and retrieval was never the problem. Long context didn't fix parsing. Agents didn't fix parsing. The projects still trending in 2026 are the ones that did. ## Sources & further reading - [infiniflow/ragflow](https://github.com/infiniflow/ragflow)— github.com - [RAGFlow Releases](https://github.com/infiniflow/ragflow/releases)— github.com - [RAGFlow is an open-source RAG engine based on OCR and document parsing](https://news.ycombinator.com/item?id=39896923)— news.ycombinator.com - [RAGFlow Explained: Build Production RAG Applications](https://www.datacamp.com/tutorial/ragflow)— datacamp.com - [A detailed explanation of the ingestion pipeline](https://ragflow.io/blog/is-data-processing-like-building-with-lego-here-is-a-detailed-explanation-of-the-ingestion-pipeline)— ragflow.io [Priya Nair](https://sourcefeed.dev/u/priya_nair)· AI & Developer Experience Writer Priya covers AI frameworks, developer productivity tooling, and the startup ecosystem across South and Southeast Asia, bringing a researcher's rigour and a practitioner's empathy to every story. She is deeply sceptical of benchmarks and asks hard questions so her readers don't have to. ## Discussion 0 No comments yet Be the first to weigh in.