Pith. sign in

REVIEW 4 major objections 4 minor 29 references

GraphRunner: A Multi-Stage Framework for Efficient and Accurate Graph-Based Retrieval

T0 review · 4 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read GraphRunner claims that separating graph traversal planning from execution, with a verification step in between, beats iterative LLM traversal by 10-50% in accuracy while cutting inference cost by 3.0-12.9x.

desk verdict A sensible planning-verification-execution framework for graph retrieval, but the experimental write-up overclaims: Figure 2 shows GraphRunner losing to Graph-CoT in several cells, so the headline 10-50% claim needs reconciliation. read the letter →

arxiv 2507.08945 v1 pith:7FZOQFIH submitted 2025-07-11 cs.IR cs.AI

Savini Kashmira , Jayanaka L. Dantanarayana , Krisztián Flautner , Lingjia Tang , Jason Mars This is my paper
classification cs.IRcs.AI
keywords graph-basedretrievalretrieval-augmentedgenerationknowledgegraphtraversalLLMplanningplanverificationhallucinationdetectionmulti-hopGRBENCH
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper is trying to establish that graph-based retrieval for question answering does not need to be iterative: an LLM can write a complete traversal plan in one pass, a structural checker can reject impossible or hallucinated steps before they run, and then a deterministic agent can execute the plan using high-level actions that jump multiple hops at once. If true, the practical consequence is that knowledge-graph question answering becomes both more accurate and substantially cheaper than the leading step-by-step traversal baseline, because the LLM reasons once instead of at every hop. The claim matters because existing graph RAG approaches either drown the model in noisy subgraph context or let an unverified LLM steer each traversal step, and both failure modes are what GraphRunner targets. The paper backs the claim with GRBENCH results across five domains, showing consistent GPT4Score gains and large reductions in token cost, response time, and error rates.

What carries the argument

The load-bearing mechanism is the verified holistic traversal plan: a single LLM inference produces the entire sequence of traversal actions, and a separate verification module checks each action against the graph's node types, edge types, and the allowed action vocabulary before the GraphRunner Agent executes it. The plan is what lets complex operations like multi-hop traversal or shared-neighbor intersection happen in one step rather than through repeated LLM reasoning, and the verification is what catches hallucinated actions, nonexistent types, and impossible edge connections before they waste tokens. The three high-level actions (Find_Node, Fetch_Neighbors, Find_Common_Nodes) are the vocabulary the plan is written in, and the verification module's structural checks are what make the plan safe to execute deterministically.

What would settle it

Run GraphRunner on GRBENCH with an open-source LLM replacing GPT-4 and compare the GPT4Score gap to Graph-CoT; if the 10-50% advantage disappears, the three-stage design's reported benefit depends on the planner's reasoning strength, not on verification alone.

Watch

Extended reading notes

Core claim

GraphRunner's central claim is that separating traversal planning from execution, plus verifying the plan against the known graph schema before running it, removes most of the errors and token waste of LLM-guided graph traversal. The framework defines three actions — Find_Node (semantic match on node attributes), Fetch_Neighbors (single-hop by edge type or multi-hop by node type), and Find_Common_Nodes (shared neighbors across several start nodes) — and asks the LLM to produce one holistic sequence of these actions. A verification module then checks that every action is in the supported set, that node and edge types exist in the schema, and that each proposed edge connection is actually possible; invalid plans are sent back for revision. On the GRBENCH benchmark with GPT-4, GraphRunner reports 10-50% higher GPT4Score than Graph-CoT across all five domains, with inference costs lower by 3.0-12.9x and response times faster by 2.5-7.1x, and its error analysis attributes roughly half of Graph-CoT's hallucination errors and about 80% of its context-window errors to the verification stage.

Load-bearing premise

The approach assumes the graph's node and edge types are fully known and that Find_Node's semantic similarity search, with an unreported threshold $\theta$, reliably locates the intended start nodes; if the schema description is incomplete or the search picks the wrong node, the whole plan is built on the wrong foundation and verification cannot repair it.

Editorial extensions

If this is right

  • Graph-based retrieval can be made non-iterative: a single planning inference plus deterministic execution can replace repeated LLM reasoning steps, cutting token use per query by a factor of 3 to 12.9 on the domains tested.
  • Complex traversals that iterative methods handle in many steps, such as finding nodes shared by two paths, can be compressed into one high-level action, which is the main source of the accuracy gains on medium-difficulty questions.
  • Pre-execution verification roughly halves hallucination errors and removes about 80% of context-window failures relative to Graph-CoT, so structural validation is a workable mechanism for catching LLM mistakes before they become retrieval failures.
  • Because the plan is verified against the schema, the approach transfers to any knowledge graph whose node and edge types are known, without fine-tuning or changing the LLM.
  • Hard questions remain the weak spot: the paper reports only modest gains there, consistent with questions where the answer is not determined by a single traversal path.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Going beyond the paper: the same plan-verify-execute pattern should transfer to other structured tool-use settings, such as SQL or API calls, where a schema check can reject invalid operations before an LLM's tool call executes.
  • The Find_Node similarity threshold is not reported or swept; a natural testable extension is to measure how retrieval accuracy varies with that threshold, since a too-high threshold would make the whole plan fail before verification can help.
  • Because verification checks structural validity rather than semantic intent, the remaining reasoning errors (still nearly 30% of responses) are unlikely to disappear without a semantic or commonsense validation pass, which the paper itself does not propose.
  • The efficiency numbers are reported for GPT-4 only; an open-source model with weaker instruction following might produce more invalid plans, so the cost savings could shrink if retries become frequent.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 4 minor

Summary. The paper proposes GraphRunner, a three-stage graph-based retrieval framework that separates traversal planning, plan verification, and execution. The planner uses LLMs to produce a holistic traversal plan from high-level actions (Find_Node, Fetch_Neighbors, Find_Common_Nodes), the verifier checks the plan against the graph schema and action definitions before execution, and the executor runs the plan to retrieve context for answer generation. The authors evaluate on GRBENCH with GPT-4, reporting GPT4Score and ROUGE-L across five domains, and claim consistent 10–50% improvements over Graph-CoT together with 3.0–12.9x inference cost reduction and 2.5–7.1x speedup.

Significance. If the reported results hold, GraphRunner would offer a meaningful advance over iterative graph traversal methods by reducing token usage and pre-execution hallucinations, and the high-level action design is a clean idea that others could adopt. The paper is transparent about its limitations (proprietary GPT-4 only, GRBENCH-only evaluation), and the efficiency analysis is a useful contribution. However, the central 'consistent outperformance' claim is weakened by internal contradictions between the text and Figure 2, and by the absence of statistical rigor and ablations. The contribution is therefore plausible but not yet fully substantiated.

major comments (4)
  1. [Section 4.2 / Figure 2] The claim that 'GraphRunner outperforms GRAPH-COT across all difficulty levels' is directly contradicted by Figure 2, which shows GraphRunner below Graph-CoT in four domain-difficulty cells: Easy E-Commerce (60.5 vs 62.4), Easy Healthcare (69.0 vs 76.2), Medium E-Commerce (19.0 vs 20.4), and Medium Legal (30.7 vs 51.2). The text also states a 44% improvement in easy Healthcare, but the figure shows GraphRunner lower there. This discrepancy undermines the abstract and Section 4.2's central claim of consistent improvement and the 10–50% range per difficulty level. The authors must correct the figure or the narrative, and provide per-difficulty results that reconcile with the domain-level aggregates in Table 1.
  2. [Section 4.1 (Evaluation Metrics)] The primary metric GPT4Score is computed by GPT-4 judging whether the answer is correct, while the same GPT-4 model generates the answers. This risks favoring the model's own style rather than ground-truth correctness. The paper reports only point estimates: no standard errors, confidence intervals, or significance tests, and no indication that multiple runs were performed. Given the central quantitative claims, the authors should report variance across repeated runs and validate GPT4Score against a human-annotated subset, especially for the cells where GraphRunner underperforms.
  3. [Section 3.3 / Section 4.4] The framework's two key mechanisms, the verification stage and the high-level traversal actions, are never isolated in an ablation study. The paper attributes performance gains to 'reducing reasoning errors' and 'detecting hallucinations' (Section 4.2), but without ablations that disable verification or replace high-level actions with 1-hop steps, these attributions are not supported. Table 2's manual error classification also lacks inter-annotator agreement measures or confidence intervals, so the claimed reductions in error probabilities (e.g., 50% of hallucination errors) are not established beyond the authors' subjective coding.
  4. [Section 3.1.1 / Section 3.2] The Find_Node action is load-bearing because it seeds every traversal, yet its implementation depends on an unreported similarity threshold θ, an unspecified semantic embedding model, and unspecified few-shot example selection. The paper also does not report the number of verification retries or the LLM sampling parameters. These unspecified components make the results difficult to reproduce and prevent assessment of how sensitive the framework is to the threshold; the authors should release these details or include a sensitivity analysis.
minor comments (4)
  1. [Figure 4] The figure contains the typo 'Genarated' and uses inconsistent spacing in action names; please proofread the figure and ensure action names match the notation in Section 3.1.
  2. [Section 4.1] The metric is written as 'Rogue-L' in Table 1 and Section 4.1; use the standard spelling 'ROUGE-L'.
  3. [Section 3.1.1] The notation defines Find_Node(h, t) using attr(v) and similarity but does not formally define the embedding/similarity function or the domain of hints H; adding a one-line definition would improve clarity.
  4. [Section 4.4] Table 2 reports error probabilities as single scalars without sample sizes or confidence intervals; please state how many questions were manually classified and whether one annotator or multiple annotators performed the classification.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: GraphRunner's accuracy and efficiency are measured against external baselines on GRBENCH, not derived from fitted parameters or self-citation.

full rationale

GraphRunner's claimed derivation chain is an empirical system evaluation, not a mathematical derivation. The traversal actions are defined by graph operations (Find_Node, Fetch_Neighbors, Find_Common_Nodes) with formal definitions independent of the evaluation results; the planning and verification stages use LLM reasoning and structural checks against the graph schema. No parameter is fitted to the benchmark and then renamed as a prediction. The threshold theta in Find_Node is unreported but is not used to claim a prediction and is a reproducibility issue rather than circularity. The paper contains no load-bearing self-citations or imported uniqueness theorems; all references are to external prior work. The main non-circular concern is that GPT-4 generates answers and GPT4Score uses GPT-4 to judge correctness, which is a self-consistency/validity risk, but it does not make the reported numbers equivalent to the inputs by construction. The inconsistency between the text's claim of consistent outperformance and Figure 2's cells where GraphRunner is below Graph-CoT (e.g., Easy E-Commerce 60.5 vs 62.4) is an internal-consistency/reporting error, not circular reasoning. Therefore the circularity score is 0.

Assumptions & free parameters 5 free parameters · 4 assumptions · 0 invented entities

The framework's central claims rest on an incomplete specification: the similarity threshold, embedding model, prompt templates, and retry limits are not reported, so the specific numbers in the evaluation cannot be reproduced. No new physical entities are introduced; the three traversal actions are algorithmic components whose effectiveness is measured only through the paper's own experiments.

free parameters (5)
  • Find_Node similarity threshold theta = not reported
    Used in Find_Node to filter candidate nodes by semantic similarity. The paper never reports its value, and it directly controls which start nodes are retrieved.
  • Semantic similarity/embedding model = not reported
    The similarity function in Find_Node is unspecified. Choice of embedding model affects retrieval quality and cannot be reproduced.
  • Few-shot example selection = not reported
    The prompt includes few-shot examples of traversal plans, but the specific examples and their number are not given. Different selections could change planner behavior.
  • Retry limit for verification = not reported
    If validation fails, the plan is regenerated, but no maximum retry count or fallback behavior is specified. This affects both cost and success rate.
  • LLM sampling parameters (temperature, etc.) = not reported
    Experiments use GPT-4, but decoding parameters are not stated. Sampling variability could affect all reported metrics.
assumptions (4)
  • domain assumption Knowledge graph has a known schema of node and edge types that can be described to the LLM.
    Section 2.1 states G has known node types Tv and edge types Te; the planning module is given this schema. If the graph schema is unknown or incomplete, the planner cannot produce valid actions.
  • domain assumption Vector-embedding semantic similarity is sufficient to identify correct start nodes for a query.
    Find_Node relies on similarity(h, attr(v)) >= theta. This assumes node attributes are textually similar to query hints, which may fail for paraphrased or abstract queries.
  • domain assumption LLM-generated traversal plans, once structurally verified, lead to correct retrieval.
    The verification step checks only action compatibility and node/edge type validity, not semantic correctness. Section 4.4 admits reasoning errors where the plan is structurally valid but semantically wrong.
  • domain assumption The GRBENCH dataset is representative of graph-based retrieval tasks.
    Evaluation is on GRBENCH only, which the authors themselves note in Limitations has limited question diversity.

how reviews work

0 comments
Cite this review

Pith. "Pith review of GraphRunner: A Multi-Stage Framework for Efficient and Accurate Graph-Based Retrieval." pith.science (2026). https://pith.science/paper/7FZOQFIH

@misc{pith2026250708945,
  author       = {Pith},
  title        = {Pith review of: GraphRunner: A Multi-Stage Framework for Efficient and Accurate Graph-Based Retrieval},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7FZOQFIH}},
  note         = {Machine review of arXiv:2507.08945}
}
read the original abstract

Conventional Retrieval Augmented Generation (RAG) approaches are common in text-based applications. However, they struggle with structured, interconnected datasets like knowledge graphs, where understanding underlying relationships is crucial for accurate retrieval. A common direction in graph-based retrieval employs iterative, rule-based traversal guided by Large Language Models (LLMs). Such existing iterative methods typically combine reasoning with single hop traversal at each step, making them vulnerable to LLM reasoning errors and hallucinations that ultimately hinder the retrieval of relevant information. To address these limitations, we propose GraphRunner, a novel graph-based retrieval framework that operates in three distinct stages: planning, verification, and execution. This introduces high-level traversal actions that enable multi-hop exploration in a single step. It also generates a holistic traversal plan, which is verified against the graph structure and pre-defined traversal actions, reducing reasoning errors and detecting hallucinations before execution. GraphRunner significantly reduces LLM reasoning errors and detects hallucinations through validation. Our evaluation using the GRBench dataset shows that GraphRunner consistently outperforms existing approaches, achieving 10-50% performance improvements over the strongest baseline while reducing inference cost by 3.0-12.9x and response generation time by 2.5-7.1x, making it significantly more robust and efficient for graph-based retrieval tasks.

Figures

Figures reproduced from arXiv: 2507.08945 by the authors.

Figure 1
Figure 1. GraphRunner Framework - Given a question, a holistic traversal plan is generated by the Traversal [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Performance improvements of GraphRunner over G [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Efficiency improvements of GraphRunner over G [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: Examples for failure cases in GraphRunner: the first example on the left demonstrates a reasoning error [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

29 extracted references · 9 canonical work pages

  1. [1]

    online" 'onlinestring :=

    ENTRY address archivePrefix author booktitle chapter edition editor eid eprint eprinttype howpublished institution journal key month note number organization pages publisher school series title type volume year doi pubmed url lastchecked label extra.label sort.label short.list INTEGERS output.state before.all mid.sentence after.sentence after.block STRING...

  2. [2]

    write newline

    " write newline "" before.all 'output.state := FUNCTION n.dashify 't := "" t empty not t #1 #1 substring "-" = t #1 #2 substring "--" = not "--" * t #2 global.max substring 't := t #1 #1 substring "-" = "-" * t #2 global.max substring 't := while if t #1 #1 substring * t #2 global.max substring 't := if while FUNCTION word.in bbl.in capitalize " " * FUNCT...

  3. [3]

    Ziwei Chai, Tianjie Zhang, Liang Wu, Kaiqiao Han, Xiaohai Hu, Xuanwen Huang, and Yang Yang. 2023. Graphllm: Boosting graph reasoning ability of large language model. arXiv preprint arXiv:2310.05845

    arXiv 2023

  4. [4]

    Jiawei Chen, Hongyu Lin, Xianpei Han, and Le Sun. 2024 a . Benchmarking large language models in retrieval-augmented generation. In Proceedings of the AAAI Conference on Artificial Intelligence, volume 38, pages 17754--17762

    2024

  5. [5]

    Zhikai Chen, Haitao Mao, Hang Li, Wei Jin, Hongzhi Wen, Xiaochi Wei, Shuaiqiang Wang, Dawei Yin, Wenqi Fan, Hui Liu, and Jiliang Tang. 2024 b . https://doi.org/10.1145/3655103.3655110 Exploring the potential of large language models (llms)in learning on graphs . SIGKDD Explor. Newsl., 25(2):42–61

    work page arXiv 2024

  6. [6]

    Zhuoming Chen, Avner May, Ruslan Svirschevski, Yu-Hsun Huang, Max Ryabinin, Zhihao Jia, and Beidi Chen. 2024 c . Sequoia: Scalable and robust speculative decoding. Advances in Neural Information Processing Systems, 37:129531--129563

    work page 2024

  7. [7]

    Darren Edge, Ha Trinh, Newman Cheng, Joshua Bradley, Alex Chao, Apurva Mody, Steven Truitt, Dasha Metropolitansky, Robert Osazuwa Ness, and Jonathan Larson. 2024. From local to global: A graph rag approach to query-focused summarization. arXiv preprint arXiv:2404.16130

    arXiv 2024

  8. [8]

    Jinlan Fu, See-Kiong Ng, Zhengbao Jiang, and Pengfei Liu. 2023. Gptscore: Evaluate as you desire. arXiv preprint arXiv:2302.04166

    arXiv 2023

Show all 29 references
  1. [9]

    Yunfan Gao, Yun Xiong, Xinyu Gao, Kangxiang Jia, Jinliu Pan, Yuxi Bi, Yi Dai, Jiawei Sun, Meng Wang, and Haofen Wang. 2024. https://arxiv.org/abs/2312.10997 Retrieval-augmented generation for large language models: A survey . Preprint, arXiv:2312.10997

    2024 arXiv

  2. [10]

    Xiaoxin He, Yijun Tian, Yifei Sun, Nitesh Chawla, Thomas Laurent, Yann LeCun, Xavier Bresson, and Bryan Hooi. 2024. G-retriever: Retrieval-augmented generation for textual graph understanding and question answering. Advances in Neural Information Processing Systems, 37:132876--132907

    2024

  3. [11]

    Jinhao Jiang, Kun Zhou, Zican Dong, Keming Ye, Xin Zhao, and Ji-Rong Wen. 2023 a . https://doi.org/10.18653/v1/2023.emnlp-main.574 S truct GPT : A general framework for large language model to reason over structured data . In Proceedings of the 2023 Conference on Empirical Met...

    2023 doi

  4. [12]

    Xinke Jiang, Rihong Qiu, Yongxin Xu, Yichen Zhu, Ruizhe Zhang, Yuchen Fang, Chu Xu, Junfeng Zhao, and Yasha Wang. 2024. Ragraph: A general retrieval-augmented graph learning framework. Advances in Neural Information Processing Systems, 37:29948--29985

    2024

  5. [13]

    Zhengbao Jiang, Frank Xu, Luyu Gao, Zhiqing Sun, Qian Liu, Jane Dwivedi-Yu, Yiming Yang, Jamie Callan, and Graham Neubig. 2023 b . https://doi.org/10.18653/v1/2023.emnlp-main.495 Active retrieval augmented generation . In Proceedings of the 2023 Conference on Empirical Methods...

    2023 doi

  6. [14]

    Bowen Jin, Chulin Xie, Jiawei Zhang, Kashob Kumar Roy, Yu Zhang, Zheng Li, Ruirui Li, Xianfeng Tang, Suhang Wang, Yu Meng, and Jiawei Han. 2024. https://arxiv.org/abs/2404.07103 Graph chain-of-thought: Augmenting large language models by reasoning on graphs . Preprint, arXiv:2...

    2024 arXiv

  7. [15]

    u ttler, Mike Lewis, Wen-tau Yih, Tim Rockt \

    Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich K \"u ttler, Mike Lewis, Wen-tau Yih, Tim Rockt \"a schel, and 1 others. 2020. Retrieval-augmented generation for knowledge-intensive nlp tasks. Advances in neural informati...

    2020

  8. [16]

    Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen tau Yih, Tim Rocktäschel, Sebastian Riedel, and Douwe Kiela. 2021. https://arxiv.org/abs/2005.11401 Retrieval-augmented generation for knowledge-int...

    2021 arXiv

  9. [17]

    Chin-Yew Lin. 2004. https://aclanthology.org/W04-1013/ ROUGE : A package for automatic evaluation of summaries . In Text Summarization Branches Out, pages 74--81, Barcelona, Spain. Association for Computational Linguistics

    2004

  10. [18]

    Dual reasoning: A gnn-llm collaborative framework for knowledge graph question answering

    Guangyi Liu, Yongqi Zhang, Yong Li, and Quanming Yao. Dual reasoning: A gnn-llm collaborative framework for knowledge graph question answering. In The Second Conference on Parsimony and Learning (Proceedings Track)

  11. [19]

    Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, and Percy Liang

    Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, and Percy Liang. 2024 a . https://doi.org/10.1162/tacl_a_00638 Lost in the middle: How language models use long contexts . Transactions of the Association for Computational Linguistics,...

    2024 doi

  12. [20]

    Zheyuan Liu, Xiaoxin He, Yijun Tian, and Nitesh V. Chawla. 2024 b . https://doi.org/10.1145/3589335.3651476 Can we soft prompt llms for graph learning tasks? In Companion Proceedings of the ACM Web Conference 2024, WWW '24, page 481–484, New York, NY, USA. Association for Comp...

    2024

  13. [21]

    OpenAI . 2025. Openai api pricing: Other models. https://platform.openai.com/docs/pricing#other-models. Accessed: 2025-05-19

    2025

  14. [22]

    Gabrijela Perkovi \'c , Antun Drobnjak, and Ivica Boti c ki. 2024. Hallucinations in llms: Understanding and addressing challenges. In 2024 47th MIPRO ICT and Electronics Convention (MIPRO), pages 2084--2088. IEEE

    2024

  15. [23]

    Fabio Petroni, Tim Rockt \"a schel, Patrick Lewis, Anton Bakhtin, Yuxiang Wu, Alexander H Miller, and Sebastian Riedel. 2019. Language models as knowledge bases? arXiv preprint arXiv:1909.01066

    2019 arXiv

  16. [24]

    Jiabin Tang, Yuhao Yang, Wei Wei, Lei Shi, Lixin Su, Suqi Cheng, Dawei Yin, and Chao Huang. 2024. https://doi.org/10.1145/3626772.3657775 Graphgpt: Graph instruction tuning for large language models . In Proceedings of the 47th International ACM SIGIR Conference on Research an...

    2024

  17. [25]

    Heng Wang, Shangbin Feng, Tianxing He, Zhaoxuan Tan, Xiaochuang Han, and Yulia Tsvetkov. 2023. Can language models solve graph problems in natural language? Advances in Neural Information Processing Systems, 36:30840--30861

    2023

  18. [26]

    Xixi Wu, Yifei Shen, Caihua Shan, Kaitao Song, Siwei Wang, Bohang Zhang, Jiarui Feng, Hong Cheng, Wei Chen, Yun Xiong, and 1 others. 2024. Can graph learning improve planning in llm-based agents? In The Thirty-eighth Annual Conference on Neural Information Processing Systems

    2024

  19. [27]

    Zhentao Xu, Mark Jerome Cruz, Matthew Guevara, Tie Wang, Manasi Deshpande, Xiaofeng Wang, and Zheng Li. 2024. https://doi.org/10.1145/3626772.3661370 Retrieval-augmented generation with knowledge graphs for customer service question answering . In Proceedings of the 47th Inter...

    2024

  20. [28]

    Ruosong Ye, Caiqi Zhang, Runhui Wang, Shuyuan Xu, and Yongfeng Zhang. 2024. https://aclanthology.org/2024.findings-eacl.132/ Language is all a graph needs . In Findings of the Association for Computational Linguistics: EACL 2024, pages 1955--1973, St. Julian ' s, Malta. Associ...

    2024

  21. [29]

    Jiawei Zhang. 2023. https://arxiv.org/abs/2304.11116 Graph-toolformer: To empower llms with graph reasoning ability via prompt augmented by chatgpt . Preprint, arXiv:2304.11116

    2023 arXiv

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.