LongLive-RAG: Long-Lived Retrieval-Augmented Generation

• LongLive-RAG is a retrieval-augmented generation framework that supports long-lived, evolving knowledge systems and long video generation by leveraging dynamic retrieval memory.
• It co-evolves system documentation, embeddings, retrievers, prompts, and human feedback to continuously refine answers and mitigate errors.
• The framework extends to long video generation by retrieving self-generated latent histories, enabling error control over long-horizon diffusion rollouts.

LongLive-RAG denotes a family of retrieval-augmented generation practices oriented toward long-lived, evolving knowledge sources, and it also names a specific retrieval framework for autoregressive long video generation. In the systems literature, it is presented as a form of knowledge transfer in which developers, administrators, documents, embeddings, retrievers, prompts, and human evaluation loops co-evolve over time; in adjacent 2025–2026 work, the same long-lived perspective is extended through clustered retrieval, iterative query refinement, nugget-based context curation, trust layers against poisoning, time-aware retrieval over structured sequences, multimodal streaming indices, online embedding adaptation, and parameterized “LLM-native memory” (Naikov et al., 23 Jan 2025, Bakagianni et al., 18 Jun 2025, Ran et al., 17 Jun 2025, Łajewska et al., 27 Jun 2025, Zhou et al., 1 Jan 2025, Cao et al., 29 Jan 2026, Wandre et al., 4 Nov 2025, Pan et al., 24 Sep 2025, Wei et al., 20 Mar 2025). In the video domain, “LongLive-RAG” is the title of a 2026 method that treats self-generated latent history as content-addressable retrieval memory for long-horizon diffusion rollouts (Hu et al., 1 Jun 2026).

1. Conceptual scope and terminological usage

The term has two distinct but related uses in the current literature. One use describes a long-term RAG discipline for evolving technical systems: documentation is treated as the primary knowledge substrate, retrieval is local and secure, and answer quality is governed through repeated human-in-the-loop correction cycles (Naikov et al., 23 Jan 2025). The other use is domain-specific: in long video generation, LongLive-RAG is a retrieval layer over previously generated latents that augments sliding-window attention with non-local historical context (Hu et al., 1 Jun 2026).

Usage	Core object retrieved	Representative source
Long-lived system knowledge	Documents, logs, records, descriptions	(Naikov et al., 23 Jan 2025)
LiveRAG-style scalable QA	Passages, nuggets, clustered evidence	(Bakagianni et al., 18 Jun 2025, Ran et al., 17 Jun 2025, Łajewska et al., 27 Jun 2025)
Long video generation	Historical latent blocks and context states	(Hu et al., 1 Jun 2026)

At the conceptual level, the long-lived systems formulation is explicit that RAG is a knowledge transfer mechanism from developers and administrators to documents, then to embeddings, retrievers, the LLM, and finally the user, with a reverse path from LLM answers back to human evaluation, documentation updates, and index refreshes. Its standard formalism is the familiar retrieve-then-generate pattern,

$y \sim p_\theta(y \mid x, D(x), \text{prompt}),$

but the emphasis is not on a new probabilistic derivation; it is on the closed loop in which the system description and the RAG apparatus are developed interactively and in parallel (Naikov et al., 23 Jan 2025).

This usage also rejects a common simplification: long-lived RAG is not merely “RAG with a large context window.” Several later papers make the same point from different angles. Vanilla RAG can underperform direct generation in long-horizon EHR prediction; attention-guided pruning is introduced because long retrieved contexts dilute attention; and long-unit retrieval is proposed because short passages create an imbalanced “heavy retriever, light reader” architecture (Cao et al., 29 Jan 2026, Fang et al., 13 Mar 2025, Jiang et al., 2024). This suggests that LongLive-RAG is better understood as a systems property—co-evolution, retrieval discipline, governance, and adaptation—than as a single model family.

2. Documentation-driven and local LongLive-RAG for large computing systems

In its most explicit long-lived systems formulation, LongLive-RAG is implemented as a local platform for a computing network segment. The hardware is a Linux server with four GeForce GTX 1080 Ti GPUs; the software stack comprises ollama for LLM hosting, open embedding models from HuggingFace, a Streamlit web UI, and a vector database built from document embeddings (Naikov et al., 23 Jan 2025). The ingestion workflow is concrete: PDF system descriptions are placed into a docs directory, chunked and embedded, and indexed in the vector database; users then ask questions in the browser, retrieved chunks plus the query plus a prompt template are passed to the selected LLM via ollama, and the answer is displayed in Streamlit.

This platform frames the LLM as a “partner for the developing team,” not merely as a static QA interface. Its documented roles include answering questions about architecture, components, and configuration in a CNS description of a little more than a hundred pages; helping locate information in large documentation sets; exposing gaps and ambiguities when answers are wrong or incomplete; making it “much easier to involve additional developing team members”; and, in the authors’ planned extension, analyzing logs and current system state for troubleshooting and maintenance (Naikov et al., 23 Jan 2025).

Several properties define the long-lived aspect. First, the deployment is explicitly local and on-prem: system descriptions and logs are not sent outside the organization, because for many development authorities sending technical details to an Internet service is unacceptable. Second, maintenance is documentation-driven: “Any changes in the system must be entered into the description which must be introduced into the RAG.” Third, the implementation is deliberately conservative: temperature is set to 0.1 to reduce hallucinations, and no custom training or fine-tuning is introduced. Fourth, updates are manual and iterative: developers assess answers, accept them or revise the documentation and/or prompt, rebuild the index, and re-ask (Naikov et al., 23 Jan 2025).

The paper reports that an initial naïve RAG produced many erroneous answers and hallucinations, but that refining the system description, filling omitted “obvious” details, adjusting prompts, and lowering temperature significantly improved inference quality. The practical governance rule is also explicit: they prepared an initial set of about 10 questions, repeated the full loop around ten times, and used “the usual criterion” of receiving the right answers to all prepared questions as the stop condition (Naikov et al., 23 Jan 2025). In this form, LongLive-RAG is a living mirror of the system’s knowledge base rather than a one-off deployment.

3. Retrieval and context-structuring architectures

LiveRAG-style work broadens LongLive-RAG from local document QA to large-scale, latency-constrained retrieval over heterogeneous corpora. “TopClustRAG” retrieves 200 results from BM25 in OpenSearch and 200 from a Pinecone dense index built with intfloat/e5-base-v2, fuses them with Reciprocal Rank Fusion, keeps the top $p=100$ passages, computes TF–IDF vectors, reduces them to 100 dimensions via SVD, clusters them with K-Means using macro-averaged silhouette to choose $k$, and selects $r=5$ passages per cluster by hybrid retrieval score rather than centroid proximity (Bakagianni et al., 18 Jun 2025). Cluster-specific prompts are then sent to Falcon3-10B-Instruct, abstentions of exactly “I don’t know.” are filtered out, surviving intermediate answers are reranked with ms-marco-MiniLM-L6-v2, and a final synthesis prompt produces one answer. On the official LiveRAG leaderboard this system ranked 2nd in faithfulness with 0.460062 and 7th in correctness with 0.685146, while processing 500 questions in about one hour on CPU-only Google Colab (Bakagianni et al., 18 Jun 2025).

“RMIT-ADM+S” replaces clustering with generation-driven retrieval augmentation. Its GRAG pipeline uses Falcon3-10B-Instruct to generate a short hypothetical answer in a HyDE-style step, uses that answer alongside the original question for hybrid retrieval through OpenSearch and Pinecone with RRF at $k=60$, applies pointwise LLM reranking by the probability of token “Yes” in a binary relevance prompt, discards documents scoring below 0.5, and caps final context length at 10k tokens for efficiency (Ran et al., 17 Jun 2025). A systematic Grid of Points exploration over 96 configurations, followed by N-way ANOVA, identifies Question Augmentation as the dominant factor affecting relevance with $F=125.6920$ and $p<0.0001$, and the official submission reaches Relevance 1.199 and Faithfulness 0.477, placing among the top four finalists (Ran et al., 17 Jun 2025).

“UiS-IAI@LiveRAG” shifts context curation from passages to “information nuggets,” defined as minimal, atomic units of relevant information. Its GINGER pipeline generates a short answer, then multiple aspect-focused rewrites, concatenates the original query with the rewrites, retrieves top-500 documents with hybrid sparse+dense search, reranks them with MonoT5 and DuoT5, runs Falcon-based nugget detection using <START> and </END> tags on the top-$m$ passages, clusters nuggets with BERTopic, ranks facet clusters with DuoT5, summarizes top clusters into one-sentence summaries of approximately 35 words, and performs a final fluency rewrite that is explicitly instructed not to add or change information (Łajewska et al., 27 Jun 2025). On TREC RAG’24 retrieval, “Original + Multi Rewrite (5)” yields Recall@500 of 0.400, and on their DataMorgana-based study the $k=20, m=10$ setting reaches $V_{strict}=0.404$ in 42 minutes for 100 queries, nearly matching $p=100$0 at $p=100$1 but with much lower runtime (Łajewska et al., 27 Jun 2025).

A more deployment-oriented variant appears in “RAGtifier,” whose final LiveRAG system combines InstructRAG prompting with Pinecone retrieval and a BGE reranker. It reports a correctness score of 1.13 and a faithfulness score of 0.55, placing fourth in the challenge (Cofala et al., 17 Jun 2025). Across these systems, the recurrent pattern is not a single retrieval recipe but a family of context-structuring strategies: hybrid recall, explicit reranking, decomposition or augmentation of the query, then compression, clustering, nuggeting, or synthesis before the final generation step.

4. Evaluation, governance, and lifecycle control

LongLive-RAG is also defined by how it is evaluated and maintained. The SIGIR 2025 LiveRAG Challenge provides the clearest shared benchmark: 500 unseen questions had to be answered in a strict two-hour window using Fineweb-10BT, a 15 million document corpus, and Falcon3-10B-Instruct as the fixed answer generator (Carmel et al., 7 Jul 2025). Seventy teams from 27 countries participated. The organizers evaluated systems in two stages: first with an LLM-as-a-judge pipeline that computed Correctness and Faithfulness, then with manual review of top systems on a shared seed set (Carmel et al., 7 Jul 2025).

The challenge report formalizes Correctness as a combination of coverage of “Direct” and “Useful” claims in the reference answer and relatedness of the system answer to the question, and Faithfulness as the degree to which answer claims are supported by the retrieved passages (Carmel et al., 7 Jul 2025). It also documents practical system patterns: most teams used hybrid search over the pre-built sparse and dense indices; most passed 3–10 retrieved passages into the final prompt; and aggressive truncation could improve compactness at the cost of grounding, as illustrated by BagBag’s negative Faithfulness score of $p=100$2 (Carmel et al., 7 Jul 2025).

The challenge evaluation has a second governance function: it makes clear that RAG quality is not exhausted by answer accuracy alone. In manual evaluation over 105 shared questions, the top systems were also compared on Coverage, Relatedness, and Quality, aggregated with a Borda count, and the correlation between automated Correctness and manual Borda reached 0.8826 (Carmel et al., 7 Jul 2025). This does not remove the need for human oversight; it establishes a practical hierarchy of evidence in which automated evaluation is scalable, but manual review remains the final arbiter for top systems and borderline cases.

The earlier long-lived systems paper reaches the same conclusion at a smaller scale. Its test question suite is a local regression harness; its stop condition is that all prepared questions receive the right answers; and its selection of embedding tool, LLM model, prompt, number of test questions, number of loops, and other parameters is explicitly assigned to the developer’s responsibility (Naikov et al., 23 Jan 2025). A plausible implication is that LongLive-RAG governance requires both continuous local regression testing and episodic benchmark-style evaluation, because documentation drift, retrieval drift, and prompt drift are all first-class failure modes.

5. Robustness, temporality, streaming adaptation, and memory

Several adjacent papers specify what long-lived RAG must do once corpora become adversarial, temporal, multimodal, or continuously updated. “TrustRAG” inserts a two-stage trust layer between retrieval and generation: K-means cluster filtering, usually with $p=100$3, plus an ROUGE-L-based preservation strategy for low-poisoning cases, followed by LLM self-assessment that generates internal knowledge, removes manipulative or instruction-like documents, consolidates consistent information, and answers from the result (Zhou et al., 1 Jan 2025). Under PoisonedRAG on NQ with Llama-3.1-8B and 100% poisoning, vanilla RAG reports ACC $p=100$4 and ASR $p=100$5, while full TrustRAG reaches ACC $p=100$6 and ASR $p=100$7; its full pipeline is about $p=100$8 slower than vanilla RAG rather than $p=100$9 slower like RobustRAG (Zhou et al., 1 Jan 2025).

“EHR-RAG” addresses long-horizon structured EHRs with three modules: Event- and Time-Aware Hybrid EHR Retrieval (ETHER), Adaptive Iterative Retrieval (AIR), and Dual-Path Evidence Retrieval and Reasoning (DER) (Cao et al., 29 Jan 2026). Its temporal retrieval function is explicitly non-monotonic, using a U-shaped time-aware score so that both early and recent clinical events can be salient, and its experiments over four long-horizon prediction tasks show an average Macro-F1 improvement of 10.76% over the strongest LLM-based baselines (Cao et al., 29 Jan 2026). The paper is explicit that vanilla RAG can underperform direct generation, which directly contradicts the misconception that any retrieval layer automatically improves long-context reasoning.

“AttentionRAG” and “LongRAG” approach the same problem from opposite ends of the context budget. AttentionRAG reformulates query conditioning as a next-token prediction problem, uses the first generated answer token as a focal token, sums cross-layer attention to each chunk token, and keeps the sentences containing top-$k$0 attention-scored tokens; it reports up to $k$1 context compression while outperforming LLMLingua methods by around 10% in key metrics (Fang et al., 13 Mar 2025). LongRAG instead enlarges the retrieval unit itself: on NQ, it groups Wikipedia into approximately 4K-token units, reduces the number of retrieval units from about 22M passages to 600K grouped documents, retrieves fewer than 8 long units, and reaches 62.7 EM on NQ and 64.3 EM on HotpotQA without training, which the paper describes as on par with a fully trained state-of-the-art model on NQ and strongly competitive on HotpotQA (Jiang et al., 2024).

Long-lived deployment also requires persistence under streaming updates. “LUMA-RAG” introduces a lifelong multimodal agent architecture with a hot HNSW tier, a compressed IVFPQ warm tier, a streaming CLAP$k$2CLIP alignment bridge updated by orthogonal Procrustes, and Safe@$k$3 telemetry that jointly bounds alignment drift and quantization error (Wandre et al., 4 Nov 2025). “Online-Optimized RAG for Tool Use and Function Calling” provides a different streaming mechanism: tool embeddings are updated online from bandit-style success/failure feedback using lightweight gradient steps, yielding a no-regret adaptive retriever with $k$4 regret under stated conditions (Pan et al., 24 Sep 2025). Finally, “Tuning LLMs by RAG Principles” moves the long-lived memory into the model itself: GraphRAG-style global and local QA synthesis is used to LoRA-tune Qwen-2-7B-Instruct into a “RAG-Tuned-LLM,” which then answers without retrieval at inference and beats both long-context LLMs and vanilla RAG across the paper’s three datasets (Wei et al., 20 Mar 2025). Taken together, these papers suggest that LongLive-RAG can remain external, become online-adaptive, or be partially compiled into parametric memory, but it cannot remain static.

6. LongLive-RAG as a retrieval framework for long video generation

The 2026 paper titled “LongLive-RAG” gives the term a second, specialized meaning: a general retrieval-augmented framework for autoregressive long video generation (Hu et al., 1 Jun 2026). The problem setting is not document QA but error accumulation in AR video diffusion. Existing systems commonly use sliding-window attention,

$k$5

so once the recent window drifts in appearance or identity, later blocks can only condition on that degraded trajectory. LongLive-RAG replaces this irreversible trajectory with a dynamic, searchable history bank of previously generated latents (Hu et al., 1 Jun 2026).

Its mechanism is explicit. Each completed latent block $k$6 is mapped by a lightweight encoder $k$7 to a normalized embedding $k$8, stored in an embedding bank $k$9, while the corresponding attention-format context $r=5$0 is stored in a paired context bank $r=5$1 (Hu et al., 1 Jun 2026). Before generating block $r=5$2, the model uses $r=5$3 as a query, computes cosine similarities $r=5$4 over eligible historical entries, retrieves top-$r=5$5 matches, and constructs an augmented context

$r=5$6

In the reported configuration, the total attention budget is 12 entries: the baseline uses 1 sink and 11 local entries, whereas LongLive-RAG uses 1 sink, 5 local entries, and 6 retrieved entries (Hu et al., 1 Jun 2026).

To make retrieval non-trivial, the paper trains the latent embedding space with a reconstruction loss, a Window Temporal Delta Loss, and a smoothing loss. The delta term penalizes excessively high cosine similarity between temporally nearby latent embeddings up to a window size $r=5$7, with margin $r=5$8, so that retrieval does not waste slots on redundant local neighbors already present in the local cache (Hu et al., 1 Jun 2026). The paper evaluates the method on Causal-Forcing, Self-Forcing, and LongLive backbones, at 30s, 60s, and 120s durations, and reports the best average VBench-Long rank across all three backbones and all three durations. It also reports a retrieval overhead of 4.08 ms per block, consisting of 3.96 ms for latent encoding and 0.08 ms for top-$r=5$9 similarity search, for a total additional runtime of about 490 ms over a 120-second rollout (Hu et al., 1 Jun 2026).

This video-specific LongLive-RAG preserves the core long-lived theme: a generator is coupled to a growing memory bank; retrieval is content-addressable rather than purely local or positional; and the system remains lightweight because retrieval reuses the native attention interface of the backbone rather than introducing a separate reasoning stack (Hu et al., 1 Jun 2026). Its significance within the broader LongLive-RAG literature is that it generalizes the idea of retrieval memory beyond text corpora to self-generated latent histories, making “long-lived retrieval” a property of generative dynamics as well as knowledge access.