How does graph structure amplify poisoning compared to flat document retrieval?
This explores whether building a knowledge graph over a corpus widens the blast radius of a poisoned document compared to plain chunk retrieval — and the corpus suggests the answer cuts both ways depending on whether the attack targets edges or the summaries that sit above them.
This question reads as: when one bad document gets into your collection, does turning that collection into a graph make the damage spread further than it would in flat chunk-based retrieval? The corpus doesn't contain a head-to-head poisoning study, but it holds the mechanisms on both sides — and they point in opposite directions, which is the interesting part.
The amplification case comes from how graph-based RAG deliberately *propagates* information upward. GraphRAG runs community detection and pre-generates summaries for each cluster of entities Can community detection enable RAG systems to answer global corpus questions?, and MegaRAG builds a hierarchy where low-level nodes roll up into high-level abstractions Can multimodal knowledge graphs answer questions that flat retrieval cannot?. That rollup is the whole point — it's what lets these systems answer global, cross-chapter questions flat retrieval can't reach. But it's also a poisoning multiplier: a single corrupted entity baked into a community summary now contaminates every global query that touches that community, not just the queries that happen to retrieve the original chunk. Flat retrieval, by contrast, bounds the damage — a poisoned chunk only hurts when it's actually pulled into a specific query's context. That's precisely why the retrieval-time defenses work: RAGPart bounds any single document's influence through partitioned retrieval, and RAGMask flags documents whose similarity collapses abnormally under token masking Can we defend RAG systems from corpus poisoning without retraining?. Those defenses assume a bounded blast radius — the very property a graph's summary layer gives up.
But there's a sharp counter-current. Taobao's Swing algorithm argues that graph *structure* is inherently noise-resistant: it leans on quasi-local bipartite patterns rather than single edges, because a structural signal requires several independent noisy edges to coincidentally line up, which rarely happens by chance Can graph structure patterns outperform direct edge signals in noisy data?. By that logic, a graph dampens poisoning rather than amplifying it — one injected edge gets outvoted by the surrounding topology. So the corpus actually frames a dependency: poisoning that targets *edges* tends to get washed out by structural corroboration, while poisoning that reaches the *summary or hierarchy layer* gets amplified by propagation. The danger isn't the graph per se; it's the abstraction step that compresses many nodes into one reused artifact.
This also reframes where you'd want graphs at all. Graph databases beat vector similarity specifically on relational, multi-hop queries where deterministic traversal matters When do graph databases outperform vector embeddings for retrieval?, and routing work like StructRAG shows the smart move is matching the knowledge structure to the query rather than graphing everything uniformly Can routing queries to task-matched structures improve RAG reasoning?. A query-time graph that's built per-request, like LogicRAG, never persists a poisoned summary at all — it constructs its reasoning structure fresh from the query and discards it Can query-time graph construction replace pre-built knowledge graphs?, which sidesteps the staleness-and-contamination surface that pre-built community summaries create.
The thing worth walking away with: the poisoning risk isn't really "graph vs. flat" — it's *persisted abstraction vs. bounded retrieval*. Flat retrieval is auditable because every retrieved chunk is the actual source you can inspect and mask-test. A graph's value comes from summarizing across sources, and summarization is exactly the operation that launders a single bad input into many trusted answers. If you build the graph at query time and keep the source nodes inspectable, you keep the multi-hop reasoning without manufacturing a contamination amplifier.
Sources 7 notes
GraphRAG uses Leiden community detection to partition entity graphs into modular groups with pre-generated summaries, enabling map-reduce answering of global questions that pure RAG and prior summarization methods cannot handle efficiently.
MegaRAG builds hierarchical multimodal knowledge graphs from text and visuals to answer cross-chapter, global questions that flat chunk retrieval cannot reach. The hierarchy supports abstraction levels from high-level summaries to page-specific details while treating images as first-class graph nodes.
RAGPart and RAGMask provide lightweight, retraining-free defenses that operate at the retrieval layer. RAGPart bounds poisoned-document influence via partitioned retriever learning; RAGMask flags suspicious documents through abnormal similarity collapse under token masking.
Taobao's Swing algorithm constructs more robust product substitute graphs by exploiting quasi-local bipartite patterns rather than single edges. Structural signals are inherently noise-resistant because they require multiple independent noisy edges to coincidentally align, which rarely happens by chance.
Graph-oriented databases solve vector similarity's failure on aggregate queries by replacing probabilistic similarity search with deterministic graph traversal via Cypher. The tradeoff: higher construction cost but precision and completeness for enterprise use cases where query patterns are relational.
StructRAG demonstrates that selecting knowledge structure type based on query demands—via DPO-trained router choosing among tables, graphs, algorithms, catalogues, and chunks—improves knowledge-intensive reasoning over standard retrieval. The approach grounds this in cognitive load and cognitive fit theory from cognitive science.
LogicRAG constructs directed acyclic graphs from queries at inference time rather than pre-building corpus-wide graphs, eliminating construction overhead, avoiding staleness, and enabling query-specific retrieval logic without sacrificing multi-hop reasoning capability.