A research framework called TRIAGE proposes a way to catch knowledge graph failures before they become wrong answers.
Graph-based Retrieval-Augmented Generation systems work by building knowledge graphs from documents and then querying those graphs to generate answers. Increasingly, those graphs are assembled automatically by large language models rather than hand-curated by experts — which means errors can slip in at extraction, at graph construction, or at the retrieval step itself, with no clean way to tell which stage broke down. TRIAGE attaches a distinct set of metrics to each stage: triple confidence and source coverage at the construction layer, structural quality checks at validation, and retrieval faithfulness and cost at query time. The key design choice is that most of these metrics require no gold-standard annotations to run in production — the annotation-heavy checks are reserved for offline calibration.
The practical promise is a diagnostic chain: if retrieval coverage is low but the graph structure looks fine, the problem is localized to extraction, not to the retrieval logic. That kind of stage-aware accountability is largely absent from current Graph-RAG tooling, where a bad output offers little signal about where the pipeline went wrong. For teams building production RAG systems on automatically extracted graphs, that ambiguity is expensive.
TRIAGE is still a theoretical framework with a proof-of-concept implementation, not a shipping product — so the gap between the paper's diagnostic promise and real-world messiness remains to be closed.