Let's say you're the head of technology at a technology company. Last year, you used GraphRAG to build an

Let's say you're the head of technology at a technology company. Last year, you used GraphRAG to build an internal knowledge base and used 20,000 contracts to do PoC. The Q&A results were amazing, and the boss made the decision to establish the project, approve the budget, and start production on the spot. Then the number of documents grew to five million. The problem started to go wrong: it took a whole weekend to build a knowledge graph, and the R&D fee and token fee were higher than the business value generated by this query; the compliance department changed a contract, and it took three days for the knowledge base to be updated; The security team insists that data cannot go out of the domain, but the large cloud model you rely on must send documents out. Three questions pop up in your mind:

• GraphRAG is clearly SOTA in terms of benchmark results. Why do they all start to pull their hips as soon as they enter a real enterprise scenario?
• In the multi-hop Q&A style of "Manager Zhang → the client he signed last year → the client's contract renewal this year", at which level are you stuck?
• Is there a solution that can not only win in benchmarking, but also be able to handle 500 million documents, same-day increments, and privatized deployment? This paper gives a new way of thinking and path: https://arxiv.org/abs/2606.15971 SAG gave a counter-intuitive answer: SQL retrieval enhanced generation. SQL has been maturely used in almost all storage systems for decades. Use this mature structured standard directly for retrieval and Agent systems! That's the point! Very smart approach. It reminds me of the recent Agentic Search solution of ClaudeCode based on the existing file system, which has the same effect but similar approach. It may not look sexy at first glance, but it is effective and practical. And the project has been open sourced: https://github.com/Zleap-AI/SAG SAG converts each data block into a semantically complete event and a set of index entities, then uses SQL join queries to dynamically link the events of the shared entities to local hyperedges, and builds a dynamically instantiated local index structure at query time. This design avoids the need for global graph reconstruction and ongoing maintenance. It pulled the Recall from
• 13% to
• 04% on the most difficult MuSiQue multi-hop question and answer, and also withstood online second-level retrieval of about 500 million pieces of data. This article breaks down what SAG does right—and why it might make “re-mapping” routes like GraphRAG slow and expensive in the enterprise. Multi-hop question and answer, vector recall has already reached its peak. Almost all of the most difficult questions in the enterprise are multi-hop. "Manager Zhang, who is responsible for compliance in our Shanghai office, what is the renewal status of this year for the client he signed last year?" - To answer, you must first find Manager Zhang, then find the client he signed last year, and then find the renewal record of that client this year. Three jumps, three pieces of evidence scattered in different documents. Ordinary vector retrieval has reached its peak for this type of problem very early. It will only find fragments with similar semantics and cannot piece together the evidence chain of "Manager Zhang → Customer → Contract Renewal". What's even more terrible is that when the Agent performs multi-step retrieval, single-step errors will accumulate and amplify along the reasoning chain - a key entity is missed in the first step, and the next three steps are all built on the wrong foundation. For the Agent, the real capability that the retrieval system should provide is to stably organize evidence into a chain in multi-hop queries. Vector search cannot provide this capability. As a result, the industry has divided into several routes, and the core difference is one: when to build the structure and how big to build it. Naive RAG: dicing, vectorization, top-k. It’s fast, cheap, and can handle volumes, but its accuracy is limited to shallow semantic matching. GraphRAG: The global knowledge graph is built when entering the database. Entities and relationships are extracted from the full text first, and then community clustering is done. HippoRAG 2: imitates the human hippocampus for cognitive mapping, and is currently recognized as a strong multi-hop baseline. SAG: There is almost no pre-construction of the map, only a lightweight partial structure is extracted when storing, and a chain is "grown" on the spot during retrieval. The first three are all in the right direction, but they are all very heavy. SAG is betting on the opposite. The real root cause of GraphRAG: the structure is built, but it is not used when querying. GraphRAG (Graph Enhanced Retrieval Enhanced Generation) is an advanced retrieval technology that combines knowledge graphs (Knowledge Graphs) and large language models (LLM). Traditional RAG relies on slicing text and leveraging vector similarity for retrieval, which is easily blinded when dealing with cross-document "global problems" or complex "multi-hop reasoning". By building a structured network of entities and relationships, GraphRAG gives AI the ability to connect dots and form lines like humans. The selling point of GraphRAG is to use graphs to express entity relationships, but when actually querying, the system either performs similarity retrieval on graph nodes or performs matching on community summaries - it does not really "walk" the multi-hop structure of that graph. There is a disconnect between the fine structure built offline and the recall logic actually executed online. You paid for mapping, but what you bought was the illusion of "you can move as much as you want when querying." This "structure-retrieval decoupling" is the most frustrating thing about GraphRAG in the enterprise: it can be built elegantly, but it cannot be used when it is used. Breaking down the account further, companies cannot escape these three transactions: The first one: warehousing cost. GraphRAG needs to extract entities and relationships from each document, and then perform community clustering and summary across documents. Moreover, traditional knowledge graphs use triplets such as "subject-relationship-object" to express relationships, but real events are almost always diverse: a transaction involves multiple subjects such as buyer, seller, product, amount, and time. It is hard to split it into two-by-two triplets, the semantics are chopped up, and the redundancy is doubled. There are 500 million documents. Just constructing the map is a considerable amount of money, and it also has to bear the accumulation of errors in triplet splitting. Second: Incremental Costs Corporate documents change every day. Once a document changes in the global graph of GraphRAG, the community structure may change accordingly, and theoretically it must be re-clustered. In practice, no one really reruns, so the map and reality drift further and further apart, and the knowledge base becomes a snapshot that "always stays at last Wednesday." One saying is accurate: when data continues to evolve, the cost of maintaining a global graph may even exceed the initial construction. The third item: the cost of privatization. This is the most terrible. Financial, medical, government, and legal data cannot go out of the domain, but GraphRAG's rounds of heavy-duty extraction either rely on strong large cloud models, or a strong enough model must be deployed privately on the intranet to handle it. Either way, it’s a dual pressure of money and compliance. The three together, is the most common complaint in the company: "We have tried GraphRAG, and the effect is good, but it cannot be used, cannot be modified, and cannot be brought online." HippoRAG 2 HippoRAG 2 upgrades traditional vector retrieval to "associative memory retrieval" through knowledge graph, Passage Node and Personalized PageRank. It is significantly better than traditional RAG in multi-hop reasoning (Multi-hop Retrieval), cross-document association and complex context understanding scenarios. HippoRAG 2 essentially adds a layer of "long-term memory network" in addition to vector retrieval to solve the problem of associative reasoning, at the cost of introducing additional complexity such as graph construction, entity alignment, and memory maintenance. HippoRAG 2 finds a good balance between retrieval efficiency and reasoning capabilities, achieving results close to graph reasoning systems with lower index costs. But for enterprise scenarios, cognitive maps still need to be continuously constructed and maintained. When faced with long-term incremental data, system complexity has not completely disappeared. SAG's judgment: Move the structure into the search itself. Since the root cause is "the structure is built but not used", the solution is clear - move the structuring capabilities into the search execution itself, and don't build the structure in the offline stage. During the offline phase, each data block is converted into an event and a set of entities and written to SQL, vector and full-text indexes. In the online phase, the system performs initial recall, then query-time expansion, and finally completes selection within the compressed candidate set. The core structure of SAG is simple. For each document slice, it extracts only two things: an event that retains the complete semantics of the slice, and a set of entities that are responsible for indexing and bridging. chunk -> event # A complete matter, retaining semantics chunk -> entities # Multiple entities, responsible for indexing event <-> entities # Many-to-many connection between matters and entities The key to understanding it is: matters and entities are two types of parallel results of the same slice. Matters carry semantics, entities only do indexing and bridging, and the two are connected through associated queries in the database. An event is associated with several entities (person, time, place, organization, product...), which is a natural network of relationships. This is the most fundamental difference between SAG and GraphRAG. GraphRAG "prepare the entire picture on the wall, and if anyone moves it, it will have to be redrawn"; SAG is "when querying, based on this question, starting from the hit entity, a link is temporarily calculated along the matter-entity connection." In words that enterprises can understand: GraphRAG is like a company that spent half a year drawing a giant organizational chart and pasting it on the wall. Anyone who transfers positions has to redraw it; SAG is like a query system. When you ask, it will check the current situation. The line "Manager Zhang → the customer he signed last year → the customer's contract renewal this year" is grown on demand and does not move the wall. What’s even better is that SAG’s multi-hop extension is a relational extension of the database. It relies on SQL correlation queries to jump between different matters along shared entities. By default, it only runs one hop. It doesn't need the heavy stuff of a graph database, a database that can do table connections is enough. The three roles each perform their own duties: SQL, vector, and LLM. Who does what? SAG also has a pragmatic design: split the retrieval pipeline into three roles, each doing their own work, and no one crosses the line. SQL is responsible for deterministic filtering and connection - the association of entities and matters, multi-hop expansion, all relying on the relational query of the database, which is accurate, interpretable and cheap. Vector retrieval is responsible for semantic expansion - aliases, synonyms, such as "Manager Zhang" and "Lao Zhang", "renewal" and "renewal", which are bridged by vector similarity. LLM only performs a fine ranking on the final compressed candidate set - it only appears after the first two passes have reduced the number of candidates from hundreds of thousands to a hundred. This corresponds exactly to the cost account of the enterprise. In the past, many RAGs easily inserted LLM into the main search path, asking the model at every step and spending tokens at every step. SAG is the other way around: whatever can be handed over to SQL will never be handed over to the model. Expensive calls will be pushed back and used on the cutting edge. There is another trade-off worth mentioning: SAG deliberately "enough is enough" in entity processing - it only does simple string normalization and duplication checking, and does not pursue perfect entity alignment. This sounds like laziness, but it is actually very sober: what really carries semantics is the matter, and the entity is just a signpost for "it can be bridged". Instead of spending a lot of effort to do perfect entity alignment (GraphRAG burned a lot of money on this), it is better to save the budget. Hard evidence: What are the high running scores? On three standard multi-hop question and answer data sets, using the same configuration (bge-large-en-v1.5 + qwen3.6-flash) and the recognized strong baseline HippoRAG 2 for comparison: MuSiQue is recognized as the most difficult multi-hop data set. SAG pulled Recall@5 from
• 04%, an absolute improvement of nearly 15 percentage points. The average Recall@2 of the three episodes increased by
• 16 points, a relative improvement of approximately
• 4%. Here is a detail that deserves a closer look at the enterprise: The most significant improvement is Recall@2, which is the ability to “retrieve only two pieces of key evidence”. This directly means that the Agent can feed evidence to the model earlier with less context - in the enterprise this means saving money, with fewer tokens, lower latency, and less interference from irrelevant context in long tasks. There is also a controlled experiment that illustrates the problem. By replacing the embedding with the stronger NV-Embed-v2, MuSiQue's Recall@5 further reaches
• 71%, and HippoRAG 2 with the same model reaches
• 55%. Of course it can go up if you switch to a stronger model, but SAG's lead is still there. This shows that its benefits mainly come from structural design - this is critical for enterprises that want to deploy privately and have limited model choices. SAG's strength is really requiring long chains, multiple hops across documents - and this happens to be the hardest and most valuable kind of problem in the enterprise. Whether it can really run in the enterprise: look at the code and scale. Experience address: https://wiki.zleap.com/search Benchmarking is a matter of research, and enterprises only recognize one thing: whether this set of things can run in their own computer rooms, on their own data, and on their own models. SAG gave two warehouses. One is the supporting Benchmark replication code (github.com/Zleap-AI/SAG-Benchmark), with version management and experimental records, which makes the evaluation script open source as it is: # Upload data set: Convert the evaluation data into corpus, write it into the database and ES uv run python scripts/run_upload.py --dataset musique # Run replication benchmark: multi-path recall + multi-hop extension uv run python scripts/run_search_benchmark.py \ --dataset-name musique \ --strategy multi \ --top-k 10 \ --k-values "1,2,5,10" \ --max-concurrency 1 0 The reproduction script supports MLflow to record experiments, supports fixed data source versions, and outputs complete evaluations of Recall, Precision, and F1. Reproducible, reconciled, and traceable, this is what enterprise technical reviewers want to see. The other is an out-of-the-box local workbench (github.com/Zleap-AI/SAG). The technology stack is TypeScript full stack, and the data layer uses PostgreSQL + pgvector + full-text search + SQL multi-hop. The model side is compatible with the OpenAI-compatible interface - enterprises can use their own privately deployed models, and the data does not leave the intranet at all. For enterprise implementation, there are several designs that are particularly suitable: writing uses chunk as the concurrency unit. This is the key to "increment" becoming a native capability. Each slice is independently extracted and stored in the database, without blocking each other. There is no need to wait for batch processing or global recalculation - contracts that are changed on the same day can be found on the same day. The entire search process is visualized. Every time a question is asked, the right panel displays in real time which search link is taken, which layer the multi-hop is extended to, and how much time each step takes. The biggest headache when something goes wrong with RAG is "I don't know why it answered this way." You can locate it if you can see the middle process. MCP is connected to make the Agent’s data base. The workbench can be exposed to external agents as an MCP server. Customer service, risk control, and legal agents within the enterprise share the same set of data base. Documents can be extracted once and reused by multiple agents, each of which stores its own data. It is already running a Wikipedia retrieval demo (wiki.zleap.com/search) with a data scale of about 500 million items online, and the online retrieval delay remains within seconds. It is not difficult for PoC to achieve effective results with 20,000 documents. What is difficult is that it can respond in seconds to 500 million pieces of data online. This scale proves that SAG's "light structure" can really handle the workload in engineering. Put these few things together - a reproducible benchmark script, a workbench that can be deployed privately, 500 million-level online verification, and a reusable data base for agents - it is a material that can be used for enterprise technology selection and project establishment, and is far more than an idea in a paper. Where is its boundary? Don’t use it in any scenario. First, it depends on the extraction quality. The matters and entities of SAG are extracted by LLM. The model is too weak, the extraction is a mess, and subsequent searches are completely useless. If an enterprise wants to save money by using a small local model during privatization, it must first evaluate whether its extraction quality can pass the test. If the foundation is not good, no matter how clever the structure is, it will be useless. Second, it may not be optimal for simple scenarios. As mentioned before, its Recall@5/10 on 2WikiMultiHopQA is slightly lower. When most of the business is single-hop and evidence-intensive (such as pure FAQ, single-document retrieval), ordinary vector retrieval or even BM25 is enough, and there is no need to use a multi-hop structure. SAG is designed for long chains of issues that are chained across documents. Third, slicing long documents is still the foundation. Things are cut into slices. If the slices are not cut well, the things will be incomplete. As with all RAGs, there is no silver bullet. Fourth, it requires the PostgreSQL + pgvector infrastructure. A little heavier than pure vector libraries (Milvus, Qdrant), but much lighter than GraphRAG, which requires a graph database plus a full set of extraction pipelines. For enterprises already using PG, migration costs are almost zero. To be honest, what SAG wants to replace is that specific position where "enterprises need to jump multiple times, need increments, need to be privatized, need to scale, and at the same time want to get rid of the cost of re-mapping." And this position happens to be the most painful and valuable part of the business. Back to that judgment. The article said at the beginning that the enterprise RAG is dead because it cannot be built, modified, or scaled up. Looking deeper, the real root cause of the problem is: the structure you spent a lot of money to build is not used at all when querying. The solution given by SAG is just one sentence: move the structuring capabilities into the retrieval execution itself, and grow a chain as needed during the query. Only one layer of lightweight indexes is built offline, and multi-hop relationships are checked and calculated online using SQL. The structure becomes something that is actually executed when a query is made, rather than just a decoration hanging on the wall. The valuable thing about this judgment is that it dares to make subtractions. The default action of the entire RAG circle in recent years is to "add things" - add more maps, add more communities, and add stronger models. SAG in turn asks: What is the truly necessary structure? Can you use the lightest version to accomplish the same thing? The answer is yes, and the running score is better. For those who choose enterprise technology, here is a more practical revelation. In the past, when choosing the RAG solution, it mainly depended on running scores and accuracy. But in real enterprise projects, what determines whether the plan can survive into the second year is the cost of construction, incremental timeliness, privatization capabilities, and the upper limit of scale. Running scores determine whether the PoC is beautiful or not, and engineering indicators determine whether the system can survive. I even think this matter can be taken one step further. The index structure of the matter-entity is so light and can be continuously written incrementally. It is naturally suitable as a memory base for long-term running Agents - with versions and time awareness, it can remember what the Agent checked three months ago and how the status evolved. This may be a further imaginative space for this structure besides RAG. But that's all for later. What is certain at the moment is: RAG's next round of progress will most likely come from this topological trade-off of "focusing on where it should be important and being lazy on where it should be". It represents a direction that deserves a serious look by everyone who works as a RAG in the enterprise.