Atomic-fact decomposition is the part that has to hold. RAC takes a finished answer, splits it into atomic facts, verifies each one against retrieved content, and revises the answer from the verdicts [2]. Retrieval is either a search engine such as Google or a corpus such as Wikipedia [8]. On the request path that is generation, then decomposition, then one retrieval, then one verify-and-correct pass, all in sequence [13]. The efficiency claim rests on retrieving once and correcting once, which the authors say cuts latency sharply against similar prior methods [5]. Read the comparison class carefully: it is other correction pipelines, not the pipeline you are running now with no correction stage in it.
The 30% is a ceiling [3]. Two datasets, each evaluated with and without RAG, is four measurement conditions per model before you count models [12]. The reported figure is the best cell in that grid. For it to transfer to your service, three things have to be true at once: your quality metric has to be the factuality metric those datasets score, your outputs have to decompose into propositions that are independently checkable, and your retrieval has to be as strong on your questions as web search was on theirs.
That last condition is where the paper is most useful, and it is buried in the introduction rather than the abstract. The authors report that RAG with Google search alone lands more than ten points above previous baselines, which is why they skipped the two obvious research moves of improving retrieval quality and correcting retrieved content [6]. Treat that as an ordering for your own work. Retrieval reach is the large term. Post-hoc correction is the smaller term stacked on top of it, and if you are grounding on a private corpus you are not starting from the base they measured.
The adoption cost is genuinely low, and that is the craft worth praising here. No additional fine-tuning, any instruction-tuned model, positioned as a post-processing component of RAG [4]. That means you can put it behind a flag, measure it, and delete it, and nothing has to be retrained when the base model changes underneath you. The code is published [9], so the margins in the paper's Table 2 are checkable by someone outside the group, which is more than the excerpt I have supports on its own: it ends mid-sentence and carries no tables and no dataset names [11].
Where it breaks is the independence assumption. A biography splits cleanly into facts that a retriever can adjudicate one at a time. A summary's faithfulness to its source document does not decompose that way, and neither does a chain of arithmetic where fact four is only wrong because fact two was. The paper also gives the honest reason the stage exists at all: correct retrieved content in the context does not guarantee correct output [7]. The same is true one layer up, since the component doing the correcting is the same class of model that produced the error, and nothing in the described loop verifies the corrector.
So the pitch that survives contact with the mechanism is narrower than 30% off a fine-tune. It is a deletable stage, priced in one extra model pass and one retrieval per answer, on outputs that are lists of separable claims.
