PaperlayerView exact revision on arXiv

Source-linked AI summary

Federated Graph Retrieval-Augmented Generation

Xiaobao Wang, Renda Han, Zhiliang Xia, Meng Liu, Renxiang Guan, Di Jin

arXiv:2610.30728v1cs.LG

TL;DR

GraphRAG relies on centralized graph repositories, but knowledge is distributed across organizations and privacy constraints limit centralization. FedGRAG routes queries to relevant clients and abstracts retrieved subgraphs, and it consistently outperforms existing baselines on retrieval and downstream generation tasks.

  • Problem

    GraphRAG relies on centralized graph repositories, while distributed knowledge and privacy or ownership constraints limit centralization and vector-based FedRAG does not capture graph structure.

    Source: §1 · pp. 1–2

  • Method

    FedGRAG routes queries using lightweight client-level knowledge indices and converts locally retrieved subgraphs into limited-exposure evidence representations.

    Source: §1 · p. 2

  • Results

    FedGRAG consistently outperforms existing baselines on both retrieval and downstream generation tasks.

    Source: §1 · p. 2

  • Takeaways & Limitations

    FedGRAG provides a practical paradigm for knowledge-enhanced generation over distributed knowledge ecosystems while reducing data privacy risks.

    Source: §5 · p. 9

    The system assumes each client has a private document corpus that is generally non-IID.

    Source: §3.1 · p. 3

Abstract

from arXiv · show

Graph Retrieval-Augmented Generation (GraphRAG) leverages centralized knowledge graphs to enhance large language models with structured knowledge retrieval. However, real-world knowledge is inherently distributed across multiple organizations rather than being centrally accessible. Privacy constraints further prohibit sharing entire local knowledge graphs, preventing GraphRAG from effectively retrieving and utilizing distributed knowledge. To this end, we propose Federated GraphRAG (FedGRAG), a unified framework for distributed graph retrieval and knowledge-enhanced generation over multiple clients with knowledge graphs. Specifically, we address two fundamental challenges in federated GraphRAG. First, the absence of a global knowledge graph makes unified retrieval impossible. To address this, we develop a Federated Knowledge Routing mechanism that efficiently identifies relevant clients through lightweight knowledge indices without exposing local graph structures. Second, local graph memory cannot be shared directly because it contains sensitive entities and knowledge information. We therefore propose a controlled-disclosure evidence construction method. It extracts retrieved evidence subgraphs and converts them into an evidence abstract, enabling evidence conversion and reconstruction on the server. Extensive experiments demonstrate that Federated GraphRAG consistently outperforms existing baselines in both retrieval and downstream generation tasks, establishing a new paradigm for deploying GraphRAG in federated environments.

1 INTRODUCTION

GraphRAG depends on centralized graph repositories, while distributed knowledge and privacy constraints make centralized access impractical. FedGRAG combines client routing and controlled-disclosure evidence abstraction, and the paper reports stronger retrieval and generation performance than existing baselines.

1 INTRODUCTION

  • GraphRAG assumes a centralized graph repository, while distributed knowledge and privacy or ownership constraints prevent many organizations from centralizing it.The introduction also notes that vector-oriented FedRAG methods cannot directly capture graph memories’ structural semantics.Source: §1 · p. 1, Figure 1 · p. 2
  • Isolated textual retrieval can miss explicit entity relations and multi-hop dependencies, increasing retrieval cost for complex queries.Repeated retrieval over fragmented evidence can also limit coherent reasoning paths.Source: §1 · p. 2
  • Federated GraphRAG must identify relevant and complementary clients while preserving query-relevant relations and limiting disclosure of sensitive subgraphs.Local subgraphs may contain sensitive entities, relations, and structural information; restricting exchange can obscure dependencies needed for cross-client reasoning.Source: §1 · p. 2
  • FedGRAG consistently outperforms existing baselines on retrieval and downstream generation tasks across multiple benchmarks.The introduction identifies both retrieval and generation as evaluation targets.Source: §1 · p. 2
  • Federated Knowledge Routing uses lightweight client-level indices, while evidence abstraction converts retrieved subgraphs into limited-exposure representations.The framework is designed to route queries without exposing entire local graphs and enable collaborative knowledge use without directly sharing entire graph knowledge.Source: §1 · p. 2

2 RELATED WORK

Related work covers graph-structured retrieval methods and federated retrieval methods. The former vary in graph representation and retrieval strategy, while the latter include client routing and privacy-oriented approaches.

2.1 GRAPH RETRIEVAL-AUGMENTED GENERATION

  • GraphRAG methods use graph memories for hierarchical retrieval, long-range associations, compact subgraph retrieval, continual learning, higher-order relations, and transferable graph-aware retrieval.The surveyed approaches include entity-community graphs, lightweight graph indexing, and hypergraphs.Source: §2.1 · pp. 2–3

2.2 FEDERATED RETRIEVAL-AUGMENTED GENERATION

  • Federated RAG approaches include routing-based client selection to reduce communication overhead and privacy-oriented methods that protect local knowledge during retrieval.The section names RAGRoute and FedE4RAG as routing examples, and C-FedRAG and FRAG as privacy-oriented frameworks.Source: §2.2 · p. 3

3 METHODOLOGY

FedGRAG routes queries across distributed knowledge graphs, then reconstructs and integrates evidence from selected clients for retrieval-augmented generation. Its method combines prototype-based routing, controlled evidence abstraction, and objectives for routing and evidence alignment.

3.1 NOTATION

  • Each client has a private, generally non-IID corpus and constructs a graph G = (V, E, X), with nodes, edges, and a node-attribute matrix.The system consists of a central server and M distributed clients.Source: §3.1 · p. 3

3.2 FEDERATED KNOWLEDGE ROUTING

  • Attribute and graph-structure encoders are fused into node embeddings, which are clustered into K semantic groups whose centroids represent local knowledge regions.The fused representation is formed by an MLP over concatenated attribute and structure representations.Source: §3.2 · pp. 3–4
  • Client prototypes represent semantic regions in local graphs; the server connects them into a global routing graph and propagates query relevance to select the top-scoring clients.Each client's prototypes are cluster centroids of fused node representations, and graph propagation can raise scores for semantically complementary clients.Source: §3.2 · p. 4

3.3 CLIENT EVIDENCE REPRESENTATION

  • Each client selects the most query-relevant entities as seeds, expands to at most H hops, and retains up to Nr edges with the highest query relevance scores.The resulting evidence subgraph remains local before projection into a compact representation for collaboration.Source: §3.3 · pp. 4–5
  • Clients encode query-relevant subgraphs as evidence packages while retaining source documents and the rest of their local graphs.The server's shared decoder reconstructs entity and relation attributes; reconstructed facts are aggregated and connected to compose evidence across clients.Source: §3.3 · p. 5
  • The server connects reconstructed facts across clients into evidence paths, serializes them as context, and supplies that context with the query to an external LLM.The interaction graph represents facts as nodes and potential reasoning dependencies as edges; repeated facts are removed and client provenance retained.Source: §3.3 · p. 5

3.4 JOINT OPTIMIZATION OBJECTIVE

  • Routing uses pairwise ranking to score positive clusters above negative clusters, while global and local evidence-alignment objectives preserve answer-relevant semantics.The global objective aligns reconstructed evidence with a frozen encoding of the reference answer and distinguishes negative answers; local alignment uses positive and irrelevant evidence representations.Source: §3.4 · p. 6

3.5 EFFICIENCY ANALYSIS

  • Online computation is O(MKd + TMKL + B^2d), covering query-prototype matching, T propagation rounds, and evidence interaction graph construction for B selected clients.The routing graph has P = M × K prototype nodes and approximately O(PL) edges after each prototype connects to its top-L neighbors.Source: §3.5 · p. 6

4 EXPERIMENTS

Experiments evaluate FedGRAG on three GraphRAG benchmarks in federated scenarios and report improvements over federated GraphRAG, federated RAG, and GFM-based GraphRAG baselines. Ablations and deployment measurements examine component contributions, routing, parameter sensitivity, communication cost, and latency.

4.1 EXPERIMENTAL SETUP

  • Evaluation uses HotpotQA, MuSiQue, and 2Wiki in partitioned, heterogeneous federated scenarios, comparing centralized GraphRAG and federated RAG baselines on retrieval and generation metrics.Metrics include Recall@2, Recall@5, Exact Match, and F1.Source: §4.1 · pp. 6–7

4.2 COMPARISON EXPERIMENTS

  • FedGRAG consistently beats federated GraphRAG methods across datasets, improves retrieval and generation over federated RAG, and improves both over GFM-based GraphRAG.The comparison covers three datasets.Source: Table 1 · p. 7, §4.2 · p. 8

4.3 ABLATION STUDY

  • FedGRAG performs best; removing routing, evidence-subgraph retrieval, or the evidence interaction graph reduces performance, while raw text increases source-content exposure.Graph-guided composition organizes related facts into connected evidence chains for multi-hop reasoning across clients.Source: Figure 3 · p. 8, §4.3 · p. 8
  • FedGRAG beats random and direct routing; gains indicate query-aware selection matters, while inter-client modeling adds value beyond independent matching.The routing comparison uses three multi-hop QA datasets under 10 clients.Source: Table 2 · p. 8, §4.3 · pp. 8–9

4.4 HYPERPARAMETER SENSITIVITY ANALYSIS

  • Sensitivity analyses report model performance as K varies from 1 to 20 (Figure 4) and as L varies from 1 to 10 under three datasets (Figure 5).Source: Figure 4 · p. 9, Figure 5 · p. 9

4.5 COMMUNICATION COST AND RUNTIME EFFICIENCY

  • FedGRAG has lower communication cost and inference latency than FRAG and C-FedRAG across evaluated settings; communication grows approximately linearly as clients increase.Its runtime advantage over the baselines is maintained as the number of clients increases.Source: Table 3 · p. 9, §4.5 · p. 9

5 CONCLUSION

FedGRAG combines federated knowledge routing and evidence abstraction to support collaborative retrieval and generation over distributed graphs without exposing local graphs. The paper reports gains in retrieval quality and generation across diverse federated settings.

5 CONCLUSION

  • FedGRAG combines federated knowledge routing and evidence abstraction to support collaborative retrieval and use of distributed graph knowledge without exposing local graphs.The conclusion describes this as extending graph retrieval to federated environments while reducing data privacy risks.Source: §5 · p. 9
  • The authors report that generative AI tools assisted with language editing, formatting, and debugging author-written code, but not methodology or experiment design.They state that authors reviewed and verified all AI-assisted content and take responsibility for the final paper.Source: AI USE STATEMENT · p. 10

A DETAILED PROCESS OF THE ALGORITHM

The appendix points readers to the algorithms that summarize preprocessing and retrieval.

A DETAILED PROCESS OF THE ALGORITHM

B.1 DETAIL OF DATASETS

The evaluation uses three multi-document question-answering benchmarks, adapted by distributing graph knowledge across clients.

B.1 DETAIL OF DATASETS

  • HotpotQA, MuSiQue, and 2Wiki evaluate retrieval and evidence aggregation through questions requiring evidence across multiple documents.Source: §B.1 · p. 12
  • For the federated setting, graph knowledge from the centralized benchmarks is distributed across clients, each maintaining a local knowledge graph.Source: §B.1 · p. 12
  • Table 4 summarizes training-data and associated knowledge-graph statistics.Source: §B.1 · p. 12

B.2 DETAILS OF BASELINES

The baseline set includes graph-based and federated retrieval-augmented generation methods, with graph methods adapted to local client knowledge and a shared federated evaluation setup.

B.2 DETAILS OF BASELINES

  • GraphRAG (MS) uses entity graphs and hierarchical community summaries, while LightRAG combines graph indexing with dual-level retrieval.Source: §B.2 · p. 12
  • HippoRAG uses Personalized PageRank for associative evidence retrieval, and HippoRAG2 adds deeper passage integration and LLM-assisted retrieval.Source: §B.2 · p. 12
  • SubgraphRAG scores query-relevant subgraphs with directional structural distance features; HyperGraphRAG represents relations connecting multiple entities.Source: §B.2 · p. 12
  • GFM-RAG learns transferable query-conditioned graph retrieval across knowledge graphs, while FRAG performs protected approximate nearest-neighbor search over distributed vector databases.Source: §B.2 · p. 12
  • FedE4RAG uses federated embedding learning, distillation, and homomorphic encryption; C-FedRAG uses confidential computing to protect retrieved context.Source: §B.2 · p. 13
  • FedMosaic aggregates relevant document adapters without transmitting raw documents; federated variants otherwise use random client routing and average local retrieval outputs.Source: §B.2 · p. 13
  • Graph-based baselines index and retrieve within individual clients using assigned local knowledge, while preserving each method’s core retrieval mechanism and shared corpus partitions and queries.These configurations are distinguished from centralized execution over the complete corpus; changes to original training, generation, or security mechanisms are documented.Source: §B.2 · p. 13

B.3 DETAILS OF EVALUATION METRICS

The evaluation measures evidence retrieval, client routing, and generated-answer quality using metrics averaged across the test set.

B.3 DETAILS OF EVALUATION METRICS

  • Metrics are computed per query and averaged across the complete test set; higher values indicate better performance.Source: §B.3 · p. 13
  • Recall@2 and Recall@5 measure the proportion of ground-truth supporting evidence covered in the top-k retrieved results.Source: §B.3 · p. 13
  • Hit@2 and Hit@5 count a query as successfully routed when at least one selected client contains ground-truth supporting evidence.Source: §B.3 · p. 13
  • Exact Match measures normalized exact-answer matches, accepting any valid reference when multiple reference answers are available.Source: §B.3 · p. 13
  • Token-level F1 measures token overlap and gives partial credit; with multiple references, the maximum F1 across valid references is reported.Source: §B.3 · p. 13

B.4 DETAIL OF IMPLEMENTATION

FedGRAG encodes client graphs into prototypes for server-side routing, then retrieves and composes local evidence to generate answers.

B.4 DETAIL OF IMPLEMENTATION

  • Experiments use Python, PyTorch 2.4.0, NVIDIA RTX 4090D GPUs, and MiniLM representations of dimension 64; training runs for 10 epochs.Source: §B.4 · pp. 13–14
  • Table 4 reports statistics for the datasets and knowledge graphs used for training.Source: Table 4 · p. 14
  • The routing guarantee bounds missed evidence-bearing clients when B covers their count; zero routing loss selects all evidence-bearing clients.Source: §B.4 · p. 14
  • The proof matches each missed positive client to a distinct selected negative, with each pair contributing at least γ to routing loss.Source: §B.4 · p. 14
  • Each client encodes node attributes and graph structure, fuses representations, clusters them into prototypes, and uploads them for global routing-graph construction.Source: §B.4 · pp. 13–15
  • For routing, the server encodes each query, propagates prototype relevance, aggregates client scores, and selects the top B clients.Source: §B.4 · p. 15
  • Selected clients retrieve seed entities, expand candidate subgraphs within H hops, retain at most Nr relevant edges, and upload evidence abstractions.Source: §B.4 · p. 15
  • The server reconstructs evidence subgraphs, aggregates facts into an interaction graph, serializes selected paths, and prompts the LLM to answer.Source: §B.4 · p. 15

Related papers

Loading 2610.30728v1…