Title: Can Graph Learning Improve Planning in LLM-based Agents?
Venue: NeurIPS 2024
Accepted: yes
Keywords: Task Planning

Language Agents

Graph Learning

Graph Neural Networks

Language Model
Abstract: Task planning in language agents is emerging as an important research topic alongside the development of large language models (LLMs). It aims to break down complex user requests in natural language into solvable sub-tasks, thereby fulfilling the original requests. In this context, the sub-tasks can be naturally viewed as a graph, where the nodes represent the sub-tasks, and the edges denote the dependencies among them. Consequently, task planning is a decision-making problem that involves selecting a connected path or subgraph within the corresponding graph and invoking it. In this paper, we explore graph learning-based methods for task planning, a direction that is orthogonal to the prevalent focus on prompt design. Our interest in graph learning stems from a theoretical discovery: the biases of attention and auto-regressive loss impede LLMs' ability to effectively navigate decision-making on graphs, which is adeptly addressed by graph neural networks (GNNs). This theoretical insight led us to integrate GNNs with LLMs to enhance overall performance. Extensive experiments demonstrate that GNN-based methods surpass existing solutions even without training, and minimal training can further enhance their performance. The performance gain increases with a larger task graph size.

Can Graph Learning Improve Planning in LLM-based Agents?

Abstract

Task planning in language agents is emerging as an important research topic alongside the development of large language models (LLMs). It aims to break down complex user requests in natural language into solvable sub-tasks, thereby fulfilling the original requests. In this context, the sub-tasks can be naturally viewed as a graph, where the nodes represent the sub-tasks, and the edges denote the dependencies among them. Consequently, task planning is a decision-making problem that involves selecting a connected path or subgraph within the corresponding graph and invoking it. In this paper, we explore graph learning-based methods for task planning, a direction that is orthogonal to the prevalent focus on prompt design. Our interest in graph learning stems from a theoretical discovery: the biases of attention and auto-regressive loss impede LLMs' ability to effectively navigate decision-making on graphs, which is adeptly addressed by graph neural networks (GNNs). This theoretical insight led us to integrate GNNs with LLMs to enhance overall performance. Extensive experiments demonstrate that GNN-based methods surpass existing solutions even without training, and minimal training can further enhance their performance. The performance gain increases with a larger task graph size. 3

1 Introduction

LLM-based agents have recently emerged as a rapidly growing field of research and are considered a significant step towards artificial general intelligence (AGI) [61, 7]. These agents have achieved remarkable successes across a variety of domains, as evidenced by their ability to address complex AI challenges (e.g., HuggingGPT [46]), excel in gaming environments (e.g., Voyager [58]), and drive innovation in chemical research (e.g., [5]). Within this burgeoning field, task planning in language agents emerges as a critical area of study. It involves LLMs autonomously interpreting user instructions, breaking user's instructions in natural language into concrete and solvable sub-tasks, and then fulfilling the user's request by executing each sub-task [43, 46, 45]. For instance, in the case of HuggingGPT [46], task planning involves invoking expert AI models from the HuggingFace website to solve complex AI tasks beyond the capabilities of GPT alone.

Given its practical significance, numerous algorithms have been proposed, with a major focus on prompt design [45, 46, 33, 30, 60, 49, 71, 4, 63]. This paper proposes to explore an orthogonal

direction, i.e., graph-learning-based approaches. In task planning, solvable sub-tasks can be naturally represented as a task graph , wherein each node corresponds to a distinct sub-task, and each edge signifies the dependencies between these sub-tasks. The crux of task planning, therefore, involves selecting a connected path or subgraph to satisfy the user's request, which is a decision-making problem on graphs. Adopting this framework, we analyze the task planning capabilities of LLMs, specifically within the context of HuggingGPT [46]. Our empirical investigation uncovers that a considerable portion of planning failures can be ascribed to the LLMs' inefficacy in accurately discerning the structure of the task graph. This finding presents intriguing questions from both theoretical and empirical perspectives. Theoretically, it initiates a discussion on the inherent limitations of LLMs in processing task graphs. Empirically, it highlights the urgent need for developing effective and efficient strategies to mitigate this deficiency and improve task planning performance.

For the theoretical question, we first investigate the expressiveness of Transformer architectures when applied to graph tasks with sequential graph input, such as edge list representations, which is the graph input format for task planning. Our initial hypothesis is that the format of sequential graph input might not align with the inductive bias inherent to graph structures, potentially reducing expressiveness. Contrary to this hypothesis, it is proved that by taking edge lists as the input, a constant-width Transformer can solve graph decision-making problems by simulating dynamic programming algorithms on edge lists. Nevertheless, we find that LLMs' solutions lack invariance under graph isomorphism, an important property for graph decision-making problems. In addition, the expressiveness is weakened if the attention is sparse, which is typically observed in LLMs [66]. Beyond expressiveness, we also examine the influence of auto-regressive loss, demonstrating that it introduces spurious correlations that can be harmful to graph decision-making tasks. These insights expose the inherent limitations of LLMs in task planning and, more broadly, in graph-related problems (e.g., the challenges in [14, 59, 34]).

To tackle the limitations, we take the use of GNNs, which have been shown to adeptly handle graph decision-making problems, both in theory and in practice [24, 68]. Initially, we deploy LLMs to interpret an ambiguous user request, breaking it down into more detailed steps. Subsequently, we utilize a GNN to retrieve the relevant sub-tasks based on these detailed steps and the corresponding sub-task descriptions. Notably, this approach can be implemented without training if we adopt parameter-free GNN models such as SGC [65]. In the case of training-based methods, we apply the Bayesian Personalized Ranking (BPR) loss [41] to facilitate learning from the implicit sub-task rankings. Extensive experiments demonstrate that the proposed methods achieve better performance than baselines. Specifically, our main contributions are summarized as follows:

Task Planning Formulation: This study presents a formulation of task planning as a graph decision-making problem. In the realm of task planning, our work initiates the exploration of graph learning methodologies to enhance performance. Concurrently, it introduces task planning as a new application in the graph learning domain.

Theoretical Insights: We prove that Transformers have expressiveness to solve graph decision-making problems based on edge list input , but inductive biases of attention and the auto-regressive loss function may serve as obstacles to their full potential.

Novel Algorithms: Based on the theoretical analysis, we introduce an additional GNN for sub-task retrieval, available in both training-free and training-based variants. The experiments on diverse LLMs and planning datasets demonstrate that the proposed method outperforms existing solutions with much less computation time. Furthermore, the performance is further enhanced by improved prompts or a fine-tuned model.

2 Preliminaries

In this section, we introduce task planning in language agents and the current LLM-based solutions.

2.1 Task Planning in Language Agents

We start with the definition of task planning with a concrete example of HuggingGPT [46]. In task planning, there is a pool of pre-defined tasks. Task planning inputs include this task pool and a user request. The user request is expressed in natural language, which is ambiguous and could encompass

Image

Segmentation

Object

Detection

Image

Editing

Language

Agents

Task Graph

User Request

Please generate an image

where a girl is reading a

book, and her pose is the

same as the boy in

'example.jpg', then please

describe the new image

with your voice.

Task Planning

Pose

Detection

Pose-to-Image

Summarization

Image

Classification

Image-

to-Text

Audio

Classification

Text-to-

Speech

Translation

task node

Image

Caption

Pose

Detection

Pose-to-Image

Image-

to-Text

Text-to-

Speech

Image Editing node Tool Invocation Graph multiple complex tasks. The output is a sequence of tasks and the order of their invocation to address the user's request.

I have an image named 'example.jpg'. I want to make all the red cars in the image blue and then identify and label the objects in the image. Finally, I need token classification of the object labels in the text. Image Segmentation Object Detection Token Classification link Figure 1 features the task planning in HuggingGPT, with the pre-defined tasks corresponding to APIs from the HuggingFace website, such as Translation and Pose-to-Image , accompanied by detailed descriptions. For instance, the detailed description for Translation is 'Translation is the task of converting text from one language to another'. The user request is 'Please generate an image where a girl is reading a book, and her pose matches the boy in 'example.jpg', then describe the new image with your voice.' The ground-truth output is a sequence of four APIs (nodes): { Pose Detection , Pose-to-Image , Image-to-Text , Text-to-Speech } , outlining the order of their invocation (a path). By invoking these APIs on HuggingFace, the user request can be fulfilled.

2.2 Current LLM-based Solution to Task Planning

The current solution of task planning is purely based on LLMs and involves two stages [45, 46]. The first stage involves request decomposition, where a user's ambiguous request is broken down into concrete steps via LLMs. For instance, the request illustrated in Figure 1 is decomposed into the following steps: (1) analyze the pose of the boy; (2) take that pose and generate a new image; (3) generate the caption for newly generated image; (4) convert the generated text into audio. The second stage is task retrieval. For each decomposed step, LLMs are employed to retrieve an appropriate task from the task pool and execute them in sequence. For example, 'Analyze the pose of the boy' corresponds to Pose detection . The output tasks should be (1) Pose detection ; (2) Pose-to-Image ; (3) Image-to-Text ; (4) Text-to-Speech . Figure 6 illustrates this procedure.

3 Graph Formulation and Insights

3.1 Graph Formulation of Task Planning

In this subsection, we formulate the task planning as a decision-making problem on the task graph. The task graph is a special kind of text-attributed graphs and we define it as G = ( V, E, T ) . Each node v ∈ V represents a pre-defined task in the task pool, associated with a text t v ∈ T describing its function (e.g., 'Translation. Translation is the task of converting text from one language to another.'). Each edge ( u, v ) ∈ E indicates a dependency between tasks (e.g., the output format of task u matches the input format of task v ). Task planning is to select a path or connected sub-graph on the task graph.

Viewed from this angle, task planning bears resemblance to traditional decision-making problems on graphs, such as planning for the shortest path. Compared with traditional planning, task planning in language agents involves diverse and open-ended goals due to the varied users' personal requests. For example, on platforms like HuggingFace, users' intentions span across video, text, and image domains. On the contrary, classic planning has a fixed goal for a given domain, which is often explicitly expressed by mathematical formulas [55, 36].

3.2 Failures of LLMs in Planning: Empirical Findings

With the task graph at hand, we diagnose LLMs in task planning in Figure 2. We adopt the experimental settings as outlined in the work of HuggingGPT [46], where the prompts are specifically optimized for task planning on HuggingFace. The evaluation metric calculates the F1 score to assess the accuracy of the tasks identified by LLMs against the ground-truth tasks. Additionally, we report

Baichuan2-13B

Vicuna-13B

CodeLlama-13B

Mistral-7B

GPT-3.5-turbo

20

40

60

80

Score (%)

Performance-Task F1

Hallucination-Edge

Hallucination-Node

(a) Performance and Hallucination ratios

30

20

10

0

60

40

20

CodeLlama-13B

GPT-3.5-turbo

GPT-4-turbo

0

(b) Hallucination ratios across datasets

two task-graph-related metrics: the node hallucination ratio and the edge hallucination ratio. These metrics measure the frequency of non-existent nodes (i.e., tasks) and edges (i.e., dependencies) outputted by LLMs, respectively, indicative of the models' misinterpretation of the graph input.

Our empirical findings reveal that (1) LLMs exhibit a certain hallucination ratio, and (2) there is a strong correlation between the hallucination ratio and planning performance. This suggests that LLMs struggle to accurately interpret the task graph while the task graph is the key to the performance.

We further explore whether the incidence of hallucinations correlates with the number of sub-tasks. The HuggingGPT dataset contains 23 sub-tasks, and our analysis is expanded to incorporate the UltraTool dataset [20], which consists of 260 sub-tasks. Figure 2b illustrates that the hallucination ratio increases with a larger task graph size.

3.3 Failures of LLMs in Planning: Theoretical Insights

In this subsection, we provide theoretical insights into the limitations of LLMs in processing task graphs. In contrast to previous graph learning approaches for graph decision-making problems, LLMs process the graph input by flattening it into a sequence and are trained using an auto-regressive loss. We will then examine the impact of these two factors.

How does sequential graph input impact the expressiveness? We consider general graph decisionmaking problems that can be resolved using dynamic programming (DP) as described in (2). The input comprises the edge list and initial states:

The intended output format is u 1 Answer [ k ][ u 1 ] . . . u n Answer [ k ][ u n ] . In existing studies, task graphs are often presented in (1), where the edge list is described by natural language and the initial states are the task descriptions of each task node, detailed in Appendix A.9 of [45].

As discussed in the previous subsection, task planning is a decision-making problem on the task graph. The decision-making problems on graphs are often solved by DP [3] and its general formulation is given by

where Answer [ k ][ i ] is the solution to state i in the k -th iteration, c [ i ][ j ] is a cost associated with state i and j , T ( i ) is the set of state can be transited to i , □ j ∈T ( i ) is an aggregation function such as MAX or SUM, and f, g are task-specific update functions. We give the formulation of typical DP algorithms in Appendix D.1 including some NPC problems. For the decision-making problems on the text-attributed graphs (e.g., task planning), one may conceptualize them as DP in the feature space, as discussed in [68].

To our surprise, although the edge list input does not directly reflect the geometric structures of graphs, it enables Transformers to simulate DP efficiently, in terms of expressiveness, as demonstrated by the following theorem.

Node (HuggingFace)

Node (UltraTool)

Edge (HuggingFace)

Edge (UltraTool)

Theorem 1. (LLMs have enough expressiveness) Assume the input format is given in (1) and f, g, □ in DP update (2) satisfy the assumptions 1 and 2 in Appendix. There exists a log-precision constantdepth and constant-width Transformer that simulates one step of DP update in (2) . As a consequence, there exists a log-precision O ( k ) -depth and constant-width Transformer that simulates k steps of DP update in (2) .

The proof is presented in Appendix D.2. However, certain aspects of the proof's constructions are challenging to be realized in Transformers that have been pretrained on natural language. First, the embedding process must be carefully filtered to ensure invariance under graph isomorphism. This invariance property does not align with the inductive biases inherent in natural language, making it difficult to achieve. Consequently, if an LLM can accurately produce the correct answer for a specific ordering of nodes, it might not maintain this accuracy after the nodes have been reordered (experiments given in Appendix D.3). Second, each token needs to synchronize its hidden states with all other tokens sharing the same token ID, which is of order O ( | V | ) . In practice, the attention trained from natural language is typically sparse [66], leading to intractability issues. The formal lower bound is provided in the following proposition and the proof is given in Appendix D.4.

Proposition 1. (Inductive bias of language hinders expressiveness) Assume the input format is described (1) and that the attention mechanism is limited to attending to a constant number of tokens. There exists at least one instance of one-step DP update such that no log-precision constant-width constant-depth transformer can simulate.

How does auto-regressive Loss impact the generalization? Our investigation next focuses on the auto-regressive loss and considers the following scenario: given a fixed task graph, user data is collected to perform instruction tuning with next-token-prediction loss. For a tractable theoretical study, we conceptualize this issue as a path-planning problem, since the output of task planning is essentially a path. We consider the training dataset comprises input sequences of the form s t s v 1 v 2 · · · t , where s represents the source node, t the target node, and the sequence s v 1 v 2 · · · t is a path that adheres to specified constraints. During testing, given the initial and target nodes s and t , the model is expected to generate a path with the same constraint. Our findings indicate that auto-regressive loss can lead to the emergence of a frequency-based spurious correlation, as substantiated by the following theorem and the proof is given in Appendix D.5.

Theorem 2. (Spurious correlations of auto-regressive loss) Assume (1) the loss employed is a nexttoken-prediction loss utilizing cross-entropy, applied to the sub-sequence v 1 v 2 · · · t during training; (2) the output logits are determined by target node t and the current node v i -1 . Let N t,v i -1 ,u be the number of times in the training dataset such that t is the target node, v i -1 is the current node and v i = u is the next node. The optimal logits for predicting the next node u from current node v i -1 towards target node t is given by ˆ v i [ u ] = N t,v i -1 ,u ∑ u N t,v i -1 ,u if ∑ u N t,v i -1 ,u > 0 . If ∑ u N t,v i -1 ,u = 0 , ˆ v i [ u ] can be any non-negative number subject to ∑ u ˆ v i [ u ] = 1 .

In our setup, s t is the instruction and the third token is a duplicate of the first token. It is reasonable to exclude these tokens in the loss calculation, which is the first assumption. The second assumption assumes that the output only depends on the current node and target node, which is a minimal requirement for path-related problems. For DP problems, the frequency-based prediction contradicts to the value-based ground-truth. We then give an example that auto-regressive loss even cannot find a valid path.

Example 1. Consider a training dataset consisting of a sufficient number of valid paths. Suppose the dataset contains two paths a b c and b c d and there are no other paths such that t = d and the current node v i = a for all i . Then we have N d,a,u ≡ 0 for all u and the logits for the next node can be arbitrary. This results in the model's inability to predict the next node of a when given a as the source node and d as the target node.

To a human, finding a path from a to d simply involves concatenating the paths a b c and b c d . However, auto-regressive loss fails under such circumstances. In task planning datasets, we indeed observe that the performance of fine-tuned LLMs is inferior to that of GNNs trained on the same dataset, as shown in Figure 3b.

4 Integrating GNNs and LLMs for Planning

4.1 Motivations

In the last section, we find that a considerable portion of planning failures can be ascribed to the LLMs' inefficacy in accurately discerning the structure of the task graph, due to the hallucination, the inductive bias of the attention, and next-token prediction loss. In contrast to LLMs, GNNs can strictly operate on the task graph, thereby avoiding hallucinations. Additionally, they leverage the graph structure as input, rather than flattening the graph into a sequence, thus overcoming the theoretical limitations discussed previously. Furthermore, GNNs have demonstrated proficiency in handling graph decision-making problems, both theoretically and empirically [68, 11, 24]. As a result, the simplest fix is to integrate GNNs into the task-planning algorithm.

In the following subsections, we propose both training-free and training-based approaches to enhance performance. Training-free methods are necessary when the available tasks are continuously changing, or new tasks are emerging constantly. This scenario is common when the task planning module is deployed in a new system. Once the task planning module has been deployed for a period, it becomes possible to collect users' requests and label a small proportion of the data, enabling lightweight training-based methods.

4.2 A Training-free GNN-based Approach

As we discussed in Section 2.2, the current solution to task planning involves two stages. The first stage requires the ability to understand users' requests in natural language and break them down into concrete instructions, which is the unique ability of LLMs. The second stage is to select a path on the task graph, where each node corresponds to a decomposed step. Thus, we can integrate GNNs in this stage. The illustration of our framework is shown in Figure 7 in Appendix .

For each decomposed step outputted by the first stage, we use a GNN to select a corresponding node within the task graph. Suppose we are selecting the node for the i -th decomposed step. First, we utilize a small pre-trained language model, e5-335M [62], to embed the i -th decomposed step. The resulting embedding is denoted as x step i . Second, for the task graph, we first use the same pre-trained language model e5-335M to convert each node's description into embeddings, denoted as the node feature h 0 v , where the superscript indicates the layer and the subscript represents the node. Then we adopt a K -layer SGC [65] to compute the final node embeddings, resulting in h v = h ( K ) v . Given a sequence of previously selected task nodes { v 1 , · · · , v i -1 } , the next node v i is chosen according to v i = argmax v ∈N ( v i -1 ) ⟨ h v , x step i ⟩ , where h v is the final node embedding, and N ( v i -1 ) denotes the neighbors of node v i -1 in the task graph. Particularly, v 1 can be selected from the whole graph.

As e5-335M is pre-trained and SGC is parameter-free, the proposed method requires no additional training and can be effectively applied in a zero-shot manner.

4.3 A Training-required GNN-based Approach

The inference process in training-required methods mirrors that of the training-free approach, with the difference being the substitution of parameter-free GNNs with parametric counterparts, such as GAT [57] or GraphSAGE [15]. Here we specify the training process of GNNs.

Data Preparation: We assume that each entry in the task planning dataset comprises a user request, a sequence of decomposed steps, and the corresponding ground-truth tasks, denoted as ( request , { s 1 , . . . , s n } , { v 1 , . . . , v n } ) . If the dataset does not adhere to this format, we reformat it accordingly using GPT-4, with details provided in Appendix C.2. It is important to note that there is a one-to-one correspondence between the steps and tasks in the dataset. Therefore, the training dataset can be represented as { ( s i , v i ) } n i =1 , where s i is a step described in natural language, and v i is its corresponding invoked task.

Training Loss: The problem in the dataset can be viewed as a binary ranking problem, where the labeled node is 1 and the other nodes are 0 . Therefore, we adopt the Bayesian Personalized Ranking (BPR) loss [41] designed for recommendation with binary rankings. The loss function is given by ℓ = ∑ ( x step ,v,v ′ ) -log σ ( ⟨ h v , x step ⟩ - ⟨ h v ′ , x step ⟩ ) , where x step represents the embedding of the step's textual description generated by e5-335M, v is the ground-truth task, and v ′ is a negative task.

We select negative tasks that are textually similar to the positive task, and for computational efficiency, we limit our selection to 2 negative tasks per positive task. The trainable parameters may merely include GNNs or both GNNs and e5-335M with illustrative configurations shown in Figure 8 in Appendix .

5 Experiments and Analysis

5.1 Experimental Setup

Datasets: We utilize four datasets across two task planning benchmarks: HuggingFace tasks, Multimedia tasks, and Daily Life API tasks from TaskBench [45], as well as TMDB API tasks from RestBench [50]. The HuggingFace dataset includes AI models on the HuggingFace. The Multimedia dataset provides a wide range of user-centric tasks, such as file downloading and video editing. The Daily Life APIs cater to everyday services like web search and shopping functionalities. TMDB focuses on movie-related search and retrieval tasks. Statistics for each dataset are presented in Table 7 with illustrative examples shown in Figure 4 in Appendix. Other benchmarks, such as ToolBench [39] and ToolAlpaca [54], are less suitable for our experiments due to (1) the absence of a well-defined task graph detailing tasks and their dependencies, and (2) a scarcity of samples involving multi-task planning, with a focus on single-task retrieval.

Evaluation: For the datasets from TaskBench, we split 3000 samples for training and 500 samples for testing, each containing an invocation path with at least two tasks. For the TMDB dataset, we first filter to include the samples with two or more invoked tasks, and then randomly select a sample served as the in-context learning example. The remaining 94 samples are designated for testing. We adopt the evaluation metric in TaskBench [45] and HuggingGPT [46], i.e., Node F1-Score ( n-F1 ) and Link F1-Score ( l-F1 ), which measure the accuracy of invoked tasks and invoked dependencies, respectively. Besides, the Accuracy ( Acc ) can measure the success rate from task level. We also measure the token consumption ( # tok ) as the efficiency metric.

Choices of LLMs: We consider close-sourced LLMs, i.e., GPT-3.5-turbo and GPT-4-turbo, as well as open-sourced LLMs with different parameter scales, including CodeLlama-13B(or 7B)-Instruct-hf [42], Mistral-7B-Instruct-v0.2 [23], Vicuna-13B-v1.5 [72], and Baichuan2-13B-Chat [69].

Choices of GNNs: To comprehensively investigate the effectiveness of different graph learning methods for task planning, we consider a wide range of graph neural networks, including SGC [65], GCN [26], GAT [57], GraphSAGE [15], GIN [67], and Graph Transformers [47].

5.2 Performance of the Training-free Approach

We compare the performance across three training-free methods: (1) LLM's Direct Inference is introduced in Section 2.2. (2) GraphSearch [33, 52, 32] leverages the classic graph search method to generate the candidate nodes and uses LLMs to give a score for node selection. Given a step, GreedySearch consistently selects the node with the highest score and adjacent to the previous task node; AdaptiveSearch selects the nodes with scores above a fixed threshold, adjusting the breadth of the search space in an adaptive mode; BeamSearch retains the k nodes with highest scores. (3) SGC [65] employs a training-free SGC for task retrieval based on decomposed task steps. The details of baselines are given in Section E.1 and illustrated in Figure 6. Table 1 shows both the overall performance and token consumption costs, with results of Accuracy ( Acc ) moved to Table 9 in Appendix.

Compared with direct inference, integrating an SGC consistently improves performance, underscoring the effectiveness of the proposed method. GraphSearch-type methods rely on beam search to identify paths and employ LLMs for evaluation, where longer processing times generally lead to better outcomes. Notably, our proposed method achieves comparable or superior performance (Table 1 and Table 9) to BeamSearch while requiring 5 -10 times fewer tokens (Table 1) and inference time (Table 10). The case studies are provided in Appendix H. However, we observed only marginal improvements with GPT-4-turbo. A unique feature of GPT-4-turbo is its ability to manage ChatGPTplugins, and it may have been specially trained on task planning datasets. In addition, the pre-trained language model used for feature extraction in SGC is e5-335M, which may not be sufficiently powerful to effectively analyze GPT-4's output. A detailed diagnostic analysis of cases involving GPT-4 is provided in Figure 11 in Appendix.

5.3 Performance of the Training-based Approaches

Settings: We further explore the efficacy of training-based GNNs in three TaskBench datasets. The TMDB dataset is excluded due to its limited sample size. Throughout our experiments, we trained a spectrum of GNN variants, both with and without co-training the small LM (i.e., e5-335M), whose role is to generate node embeddings derived from task names and descriptions. Owing to space constraints, we only show the performance of GraphSAGE in the main text, relegating a detailed comparison of all the situations to Table 11 and Table 12 in Appendix.

Compared Methods: Due to the lack of training-based baseline methods specifically for task planning, we adapt two existing approaches that combine LLMs and GNNs for graph-related tasks, including: (1) TAPE [16] employs a LLM → LM → GNN architecture for node classification task. In this framework, LLMs generate high-quality explanatory text for each predicted node, which is then fine-tuned by an LM to produce node embeddings. Finally, a GNN performs the downstream classification. We adapt TAPE for task planning by reformulating the problem as classifying user requests into corresponding node labels within the task graph. (2) GraphToken [38] uses GNNs to tokenize graph nodes, which are then fed into LLMs to generate textual outputs. In our adaptation for task planning, we treat the user request as the input question and the expected plan as the generated answer. Additional implementation details are provided in the Appendix F.2.

Observations: From Table 2, we observe a significant improvement in performance when employing a training-based GraphSAGE approach over the training-free method. However, the co-training of GNNs with e5-335M does not yield a marked improvement, suggesting that message passing is the crucial element for enhancing performance. Further analysis across a broad spectrum of GNNs (as shown in Table 11 and Table 12) reveals that powerful GNNs, such as GINs, perform similarly to networks perceived as less complex, like GCNs, and even underperform compared to GraphSAGE. This pattern indicates that the task's challenge may not lie in the expressiveness of the models but rather in their ability to generalize. Regarding baselines, TAPE is unsuitable for task planning as its classification approach simplifies task planning, overlooking task dependencies. While GraphToken demonstrates superior performance over LLMs' direct inference, we have noted instances of minor hallucination. This observation suggests that GraphToken's understanding of the task graph is not yet perfect. In addition, GraphToken is limited to open-sourced LLMs. Besides, our proposed approaches also greatly boost the parameter prediction performance, as given in Appendix G (e.g. 9% improvement to GPT-3.5-turbo and 3% improvement to GPT-4-turbo).

Efficiency: The details of the training time are given in Table 13. The training cost is remarkably low because we use e5-335M [62] as the text embedding model for GNNs. If the trainable parameters are limited to the GNNs alone, training typically concludes within just 3 minutes. Furthermore, the

training duration extends to only 15 minutes when GNNs are jointly trained with e5-335M model. This efficiency stands in stark contrast to the 10-20 hours required for tuning open-sourced LLMs.

5.4 Scaling to Large Task Graphs

To demonstrate the scalability of our method to larger task graphs, we conducted a supplementary experiment on the newly released planning benchmark UltraTool [20], which features a relatively large task graph with 260 nodes. Details on processing this dataset are provided in Appendix C.3. We present a performance comparison of GNN models (training-free SGC and training-required GraphSAGE) against strong baselines like BeamSearch in Table 3. Among the metrics, accuracy ( Acc ) is calculated based on whether the predicted tasks match the ground-truth tasks, measuring the success rate at each case level. In such conditions, integrating a GNN significantly enhances performance and mitigates planning failures, e.g., GPT-4-turbo undergoes a 9.05% accuracy improvement with the introduction of GraphSAGE.

GLYPH<c=25,font=/AAAAAF+DejaVuSans>GLYPH<c=3,font=/AAAAAF+DejaVuSans>GLYPH<c=5,font=/AAAAAF+DejaVuSans>GLYPH<c=4,font=/AAAAAF+DejaVuSans>GLYPH<c=6,font=/AAAAAF+DejaVuSans>

GLYPH<c=19,font=/AAAAAF+DejaVuSans>GLYPH<c=30,font=/AAAAAF+DejaVuSans>GLYPH<c=24,font=/AAAAAF+DejaVuSans>GLYPH<c=25,font=/AAAAAF+DejaVuSans>GLYPH<c=3,font=/AAAAAF+DejaVuSans>GLYPH<c=17,font=/AAAAAF+DejaVuSans>GLYPH<c=9,font=/AAAAAF+DejaVuSans>GLYPH<c=7,font=/AAAAAF+DejaVuSans>GLYPH<c=21,font=/AAAAAF+DejaVuSans>GLYPH<c=23,font=/AAAAAF+DejaVuSans>GLYPH<c=30,font=/AAAAAF+DejaVuSans>

GLYPH<c=18,font=/AAAAAB+DejaVuSans>%GLYPH<c=30,font=/AAAAAB+DejaVuSans>GLYPH<c=31,font=/AAAAAB+DejaVuSans>GLYPH<c=23,font=/AAAAAB+DejaVuSans>"GLYPH<c=28,font=/AAAAAB+DejaVuSans>#GLYPH<c=28,font=/AAAAAB+DejaVuSans>GLYPH<c=7,font=/AAAAAB+DejaVuSans>GLYPH<c=14,font=/AAAAAB+DejaVuSans>GLYPH<c=17,font=/AAAAAB+DejaVuSans>

GLYPH<c=21,font=/AAAAAB+DejaVuSans>

GLYPH<c=26,font=/AAAAAB+DejaVuSans>

GLYPH<c=7,font=/AAAAAB+DejaVuSans>GLYPH<c=18,font=/AAAAAB+DejaVuSans>%GLYPH<c=30,font=/AAAAAB+DejaVuSans>GLYPH<c=31,font=/AAAAAB+DejaVuSans>GLYPH<c=23,font=/AAAAAB+DejaVuSans>"GLYPH<c=28,font=/AAAAAB+DejaVuSans>#GLYPH<c=28,font=/AAAAAB+DejaVuSans>

GLYPH<c=27,font=/AAAAAB+DejaVuSans> !GLYPH<c=29,font=/AAAAAB+DejaVuSans>)$GLYPH<c=28,font=/AAAAAB+DejaVuSans>GLYPH<c=7,font=/AAAAAB+DejaVuSans>GLYPH<c=9,font=/AAAAAB+DejaVuSans>GLYPH<c=10,font=/AAAAAB+DejaVuSans>GLYPH<c=17,font=/AAAAAB+DejaVuSans>

GLYPH<c=21,font=/AAAAAB+DejaVuSans>

GLYPH<c=26,font=/AAAAAB+DejaVuSans>

GLYPH<c=7,font=/AAAAAB+DejaVuSans>

GLYPH<c=27,font=/AAAAAB+DejaVuSans> !GLYPH<c=29,font=/AAAAAB+DejaVuSans>)$GLYPH<c=28,font=/AAAAAB+DejaVuSans>

GLYPH<c=11,font=/AAAAAB+DejaVuSans>GLYPH<c=8,font=/AAAAAB+DejaVuSans>

GLYPH<c=13,font=/AAAAAB+DejaVuSans>GLYPH<c=12,font=/AAAAAB+DejaVuSans>

GLYPH<c=15,font=/AAAAAB+DejaVuSans>GLYPH<c=8,font=/AAAAAB+DejaVuSans>

GLYPH<c=24,font=/AAAAAB+DejaVuSans>%GLYPH<c=30,font=/AAAAAB+DejaVuSans>GLYPH<c=31,font=/AAAAAB+DejaVuSans>GLYPH<c=3,font=/AAAAAB+DejaVuSans>GLYPH<c=21,font=/AAAAAB+DejaVuSans>GLYPH<c=9,font=/AAAAAB+DejaVuSans>GLYPH<c=7,font=/AAAAAB+DejaVuSans>GLYPH<c=25,font=/AAAAAB+DejaVuSans>GLYPH<c=29,font=/AAAAAB+DejaVuSans>%' GLYPH<c=31,font=/AAAAAB+DejaVuSans>GLYPH<c=3,font=/AAAAAB+DejaVuSans>GLYPH<c=5,font=/AAAAAB+DejaVuSans>GLYPH<c=4,font=/AAAAAB+DejaVuSans>GLYPH<c=6,font=/AAAAAB+DejaVuSans>

GLYPH<c=4,font=/AAAAAC+DejaVuSans-Bold>GLYPH<c=12,font=/AAAAAC+DejaVuSans-Bold>GLYPH<c=9,font=/AAAAAC+DejaVuSans-Bold>GLYPH<c=11,font=/AAAAAC+DejaVuSans-Bold>GLYPH<c=8,font=/AAAAAC+DejaVuSans-Bold>GLYPH<c=10,font=/AAAAAC+DejaVuSans-Bold>GLYPH<c=7,font=/AAAAAC+DejaVuSans-Bold>GLYPH<c=6,font=/AAAAAC+DejaVuSans-Bold>GLYPH<c=8,font=/AAAAAC+DejaVuSans-Bold>GLYPH<c=5,font=/AAAAAC+DejaVuSans-Bold>

GLYPH<c=19,font=/AAAAAB+DejaVuSans>!' GLYPH<c=31,font=/AAAAAB+DejaVuSans>GLYPH<c=29,font=/AAAAAB+DejaVuSans>(

GLYPH<c=22,font=/AAAAAB+DejaVuSans>'GLYPH<c=28,font=/AAAAAB+DejaVuSans>& GLYPH<c=25,font=/AAAAAB+DejaVuSans> GLYPH<c=16,font=/AAAAAB+DejaVuSans> GLYPH<c=22,font=/AAAAAB+DejaVuSans>GLYPH<c=20,font=/AAAAAB+DejaVuSans>

GLYPH<c=17,font=/AAAAAD+DejaVuSans>$GLYPH<c=29,font=/AAAAAD+DejaVuSans>GLYPH<c=30,font=/AAAAAD+DejaVuSans>GLYPH<c=22,font=/AAAAAD+DejaVuSans>!GLYPH<c=27,font=/AAAAAD+DejaVuSans>"GLYPH<c=27,font=/AAAAAD+DejaVuSans>GLYPH<c=7,font=/AAAAAD+DejaVuSans>GLYPH<c=13,font=/AAAAAD+DejaVuSans>GLYPH<c=16,font=/AAAAAD+DejaVuSans>

GLYPH<c=20,font=/AAAAAD+DejaVuSans>

GLYPH<c=25,font=/AAAAAD+DejaVuSans>

GLYPH<c=7,font=/AAAAAD+DejaVuSans>GLYPH<c=17,font=/AAAAAD+DejaVuSans>$GLYPH<c=29,font=/AAAAAD+DejaVuSans>GLYPH<c=30,font=/AAAAAD+DejaVuSans>GLYPH<c=22,font=/AAAAAD+DejaVuSans>!GLYPH<c=27,font=/AAAAAD+DejaVuSans>"GLYPH<c=27,font=/AAAAAD+DejaVuSans>

GLYPH<c=26,font=/AAAAAD+DejaVuSans>  GLYPH<c=28,font=/AAAAAD+DejaVuSans>(#GLYPH<c=27,font=/AAAAAD+DejaVuSans>GLYPH<c=7,font=/AAAAAD+DejaVuSans>GLYPH<c=9,font=/AAAAAD+DejaVuSans>GLYPH<c=10,font=/AAAAAD+DejaVuSans>GLYPH<c=16,font=/AAAAAD+DejaVuSans>

GLYPH<c=20,font=/AAAAAD+DejaVuSans>

GLYPH<c=25,font=/AAAAAD+DejaVuSans>

GLYPH<c=7,font=/AAAAAD+DejaVuSans>

GLYPH<c=26,font=/AAAAAD+DejaVuSans>  GLYPH<c=28,font=/AAAAAD+DejaVuSans>(#GLYPH<c=27,font=/AAAAAD+DejaVuSans>

GLYPH<c=11,font=/AAAAAD+DejaVuSans>GLYPH<c=8,font=/AAAAAD+DejaVuSans>

GLYPH<c=12,font=/AAAAAD+DejaVuSans>GLYPH<c=8,font=/AAAAAD+DejaVuSans>

GLYPH<c=14,font=/AAAAAD+DejaVuSans>GLYPH<c=8,font=/AAAAAD+DejaVuSans>

GLYPH<c=23,font=/AAAAAD+DejaVuSans>$GLYPH<c=29,font=/AAAAAD+DejaVuSans>GLYPH<c=30,font=/AAAAAD+DejaVuSans>GLYPH<c=3,font=/AAAAAD+DejaVuSans>GLYPH<c=20,font=/AAAAAD+DejaVuSans>GLYPH<c=9,font=/AAAAAD+DejaVuSans>GLYPH<c=7,font=/AAAAAD+DejaVuSans>GLYPH<c=24,font=/AAAAAD+DejaVuSans>GLYPH<c=28,font=/AAAAAD+DejaVuSans>$& GLYPH<c=30,font=/AAAAAD+DejaVuSans>GLYPH<c=3,font=/AAAAAD+DejaVuSans>GLYPH<c=5,font=/AAAAAD+DejaVuSans>GLYPH<c=4,font=/AAAAAD+DejaVuSans>GLYPH<c=6,font=/AAAAAD+DejaVuSans>

GLYPH<c=5,font=/AAAAAE+DejaVuSans-Bold>GLYPH<c=12,font=/AAAAAE+DejaVuSans-Bold>GLYPH<c=9,font=/AAAAAE+DejaVuSans-Bold>GLYPH<c=9,font=/AAAAAE+DejaVuSans-Bold>GLYPH<c=10,font=/AAAAAE+DejaVuSans-Bold>GLYPH<c=11,font=/AAAAAE+DejaVuSans-Bold>GLYPH<c=9,font=/AAAAAE+DejaVuSans-Bold>GLYPH<c=4,font=/AAAAAE+DejaVuSans-Bold>

GLYPH<c=6,font=/AAAAAE+DejaVuSans-Bold>GLYPH<c=7,font=/AAAAAE+DejaVuSans-Bold>GLYPH<c=8,font=/AAAAAE+DejaVuSans-Bold>

GLYPH<c=18,font=/AAAAAD+DejaVuSans> & GLYPH<c=30,font=/AAAAAD+DejaVuSans>GLYPH<c=28,font=/AAAAAD+DejaVuSans>'

GLYPH<c=21,font=/AAAAAD+DejaVuSans>&GLYPH<c=27,font=/AAAAAD+DejaVuSans>%GLYPH<c=31,font=/AAAAAD+DejaVuSans>GLYPH<c=24,font=/AAAAAD+DejaVuSans> GLYPH<c=15,font=/AAAAAD+DejaVuSans> GLYPH<c=21,font=/AAAAAD+DejaVuSans>GLYPH<c=19,font=/AAAAAD+DejaVuSans>

GLYPH<c=9,font=/AAAAAF+DejaVuSans>GLYPH<c=7,font=/AAAAAF+DejaVuSans>!GLYPH<c=26,font=/AAAAAF+DejaVuSans>GLYPH<c=30,font=/AAAAAF+DejaVuSans>"GLYPH<c=3,font=/AAAAAF+DejaVuSans>GLYPH<c=20,font=/AAAAAF+DejaVuSans>   GLYPH<c=30,font=/AAAAAF+DejaVuSans>GLYPH<c=29,font=/AAAAAF+DejaVuSans>GLYPH<c=31,font=/AAAAAF+DejaVuSans>"

GLYPH<c=10,font=/AAAAAF+DejaVuSans>GLYPH<c=7,font=/AAAAAF+DejaVuSans>!GLYPH<c=26,font=/AAAAAF+DejaVuSans>GLYPH<c=30,font=/AAAAAF+DejaVuSans>"GLYPH<c=3,font=/AAAAAF+DejaVuSans>GLYPH<c=20,font=/AAAAAF+DejaVuSans>   GLYPH<c=30,font=/AAAAAF+DejaVuSans>GLYPH<c=29,font=/AAAAAF+DejaVuSans>GLYPH<c=31,font=/AAAAAF+DejaVuSans>"

GLYPH<c=20,font=/AAAAAF+DejaVuSans>GLYPH<c=28,font=/AAAAAF+DejaVuSans>GLYPH<c=22,font=/AAAAAF+DejaVuSans>GLYPH<c=18,font=/AAAAAF+DejaVuSans>GLYPH<c=3,font=/AAAAAF+DejaVuSans>GLYPH<c=20,font=/AAAAAF+DejaVuSans>  GLYPH<c=30,font=/AAAAAF+DejaVuSans>GLYPH<c=29,font=/AAAAAF+DejaVuSans>GLYPH<c=31,font=/AAAAAF+DejaVuSans>"

GLYPH<c=11,font=/AAAAAF+DejaVuSans>GLYPH<c=8,font=/AAAAAF+DejaVuSans>

GLYPH<c=12,font=/AAAAAF+DejaVuSans>GLYPH<c=8,font=/AAAAAF+DejaVuSans>

GLYPH<c=13,font=/AAAAAF+DejaVuSans>GLYPH<c=8,font=/AAAAAF+DejaVuSans>

GLYPH<c=19,font=/AAAAAF+DejaVuSans>GLYPH<c=30,font=/AAAAAF+DejaVuSans>GLYPH<c=24,font=/AAAAAF+DejaVuSans>GLYPH<c=25,font=/AAAAAF+DejaVuSans>GLYPH<c=3,font=/AAAAAF+DejaVuSans>GLYPH<c=17,font=/AAAAAF+DejaVuSans>GLYPH<c=9,font=/AAAAAF+DejaVuSans>GLYPH<c=7,font=/AAAAAF+DejaVuSans>GLYPH<c=21,font=/AAAAAF+DejaVuSans>GLYPH<c=23,font=/AAAAAF+DejaVuSans>GLYPH<c=30,font=/AAAAAF+DejaVuSans>

GLYPH<c=25,font=/AAAAAF+DejaVuSans>GLYPH<c=3,font=/AAAAAF+DejaVuSans>GLYPH<c=5,font=/AAAAAF+DejaVuSans>GLYPH<c=4,font=/AAAAAF+DejaVuSans>GLYPH<c=6,font=/AAAAAF+DejaVuSans>

GLYPH<c=8,font=/AAAAAG+DejaVuSans-Bold>GLYPH<c=15,font=/AAAAAG+DejaVuSans-Bold>GLYPH<c=11,font=/AAAAAG+DejaVuSans-Bold>GLYPH<c=12,font=/AAAAAG+DejaVuSans-Bold>GLYPH<c=9,font=/AAAAAG+DejaVuSans-Bold>GLYPH<c=13,font=/AAAAAG+DejaVuSans-Bold>GLYPH<c=10,font=/AAAAAG+DejaVuSans-Bold>GLYPH<c=14,font=/AAAAAG+DejaVuSans-Bold>GLYPH<c=10,font=/AAAAAG+DejaVuSans-Bold>GLYPH<c=4,font=/AAAAAG+DejaVuSans-Bold>GLYPH<c=5,font=/AAAAAG+DejaVuSans-Bold>GLYPH<c=6,font=/AAAAAG+DejaVuSans-Bold>GLYPH<c=7,font=/AAAAAG+DejaVuSans-Bold>

GLYPH<c=15,font=/AAAAAF+DejaVuSans>GLYPH<c=27,font=/AAAAAF+DejaVuSans>  GLYPH<c=25,font=/AAAAAF+DejaVuSans>GLYPH<c=23,font=/AAAAAF+DejaVuSans>"

GLYPH<c=18,font=/AAAAAF+DejaVuSans> GLYPH<c=22,font=/AAAAAF+DejaVuSans>GLYPH<c=31,font=/AAAAAF+DejaVuSans>GLYPH<c=26,font=/AAAAAF+DejaVuSans>GLYPH<c=21,font=/AAAAAF+DejaVuSans> GLYPH<c=14,font=/AAAAAF+DejaVuSans> GLYPH<c=18,font=/AAAAAF+DejaVuSans>GLYPH<c=16,font=/AAAAAF+DejaVuSans>

GLYPH<c=9,font=/AAAAAH+DejaVuSans>GLYPH<c=7,font=/AAAAAH+DejaVuSans>!GLYPH<c=26,font=/AAAAAH+DejaVuSans>GLYPH<c=30,font=/AAAAAH+DejaVuSans>"GLYPH<c=3,font=/AAAAAH+DejaVuSans>GLYPH<c=20,font=/AAAAAH+DejaVuSans>   GLYPH<c=30,font=/AAAAAH+DejaVuSans>GLYPH<c=29,font=/AAAAAH+DejaVuSans>GLYPH<c=31,font=/AAAAAH+DejaVuSans>"

GLYPH<c=10,font=/AAAAAH+DejaVuSans>GLYPH<c=7,font=/AAAAAH+DejaVuSans>!GLYPH<c=26,font=/AAAAAH+DejaVuSans>GLYPH<c=30,font=/AAAAAH+DejaVuSans>"GLYPH<c=3,font=/AAAAAH+DejaVuSans>GLYPH<c=20,font=/AAAAAH+DejaVuSans>   GLYPH<c=30,font=/AAAAAH+DejaVuSans>GLYPH<c=29,font=/AAAAAH+DejaVuSans>GLYPH<c=31,font=/AAAAAH+DejaVuSans>"

GLYPH<c=20,font=/AAAAAH+DejaVuSans>GLYPH<c=28,font=/AAAAAH+DejaVuSans>GLYPH<c=22,font=/AAAAAH+DejaVuSans>GLYPH<c=18,font=/AAAAAH+DejaVuSans>GLYPH<c=3,font=/AAAAAH+DejaVuSans>GLYPH<c=20,font=/AAAAAH+DejaVuSans>  GLYPH<c=30,font=/AAAAAH+DejaVuSans>GLYPH<c=29,font=/AAAAAH+DejaVuSans>GLYPH<c=31,font=/AAAAAH+DejaVuSans>"

GLYPH<c=11,font=/AAAAAH+DejaVuSans>GLYPH<c=8,font=/AAAAAH+DejaVuSans>

GLYPH<c=12,font=/AAAAAH+DejaVuSans>GLYPH<c=8,font=/AAAAAH+DejaVuSans>

GLYPH<c=13,font=/AAAAAH+DejaVuSans>GLYPH<c=8,font=/AAAAAH+DejaVuSans>

GLYPH<c=19,font=/AAAAAH+DejaVuSans>GLYPH<c=30,font=/AAAAAH+DejaVuSans>GLYPH<c=24,font=/AAAAAH+DejaVuSans>GLYPH<c=25,font=/AAAAAH+DejaVuSans>GLYPH<c=3,font=/AAAAAH+DejaVuSans>GLYPH<c=17,font=/AAAAAH+DejaVuSans>GLYPH<c=9,font=/AAAAAH+DejaVuSans>GLYPH<c=7,font=/AAAAAH+DejaVuSans>GLYPH<c=21,font=/AAAAAH+DejaVuSans>GLYPH<c=23,font=/AAAAAH+DejaVuSans>GLYPH<c=30,font=/AAAAAH+DejaVuSans>

GLYPH<c=25,font=/AAAAAH+DejaVuSans>GLYPH<c=3,font=/AAAAAH+DejaVuSans>GLYPH<c=5,font=/AAAAAH+DejaVuSans>GLYPH<c=4,font=/AAAAAH+DejaVuSans>GLYPH<c=6,font=/AAAAAH+DejaVuSans>

GLYPH<c=7,font=/AAAAAI+DejaVuSans-Bold>GLYPH<c=9,font=/AAAAAI+DejaVuSans-Bold>GLYPH<c=12,font=/AAAAAI+DejaVuSans-Bold>GLYPH<c=13,font=/AAAAAI+DejaVuSans-Bold>GLYPH<c=11,font=/AAAAAI+DejaVuSans-Bold>GLYPH<c=8,font=/AAAAAI+DejaVuSans-Bold>GLYPH<c=10,font=/AAAAAI+DejaVuSans-Bold>GLYPH<c=4,font=/AAAAAI+DejaVuSans-Bold>GLYPH<c=5,font=/AAAAAI+DejaVuSans-Bold>GLYPH<c=6,font=/AAAAAI+DejaVuSans-Bold>

GLYPH<c=15,font=/AAAAAH+DejaVuSans>GLYPH<c=27,font=/AAAAAH+DejaVuSans>  GLYPH<c=25,font=/AAAAAH+DejaVuSans>GLYPH<c=23,font=/AAAAAH+DejaVuSans>"

GLYPH<c=18,font=/AAAAAH+DejaVuSans> GLYPH<c=22,font=/AAAAAH+DejaVuSans>GLYPH<c=31,font=/AAAAAH+DejaVuSans>GLYPH<c=26,font=/AAAAAH+DejaVuSans>GLYPH<c=21,font=/AAAAAH+DejaVuSans> GLYPH<c=14,font=/AAAAAH+DejaVuSans> GLYPH<c=18,font=/AAAAAH+DejaVuSans>GLYPH<c=16,font=/AAAAAH+DejaVuSans>

(a) Different Prompts

GLYPH<c=18,font=/AAAAAB+DejaVuSans>%GLYPH<c=30,font=/AAAAAB+DejaVuSans>GLYPH<c=31,font=/AAAAAB+DejaVuSans>GLYPH<c=23,font=/AAAAAB+DejaVuSans>"GLYPH<c=28,font=/AAAAAB+DejaVuSans>#GLYPH<c=28,font=/AAAAAB+DejaVuSans>GLYPH<c=7,font=/AAAAAB+DejaVuSans>GLYPH<c=14,font=/AAAAAB+DejaVuSans>GLYPH<c=17,font=/AAAAAB+DejaVuSans>

GLYPH<c=21,font=/AAAAAB+DejaVuSans>

GLYPH<c=26,font=/AAAAAB+DejaVuSans>

GLYPH<c=7,font=/AAAAAB+DejaVuSans>GLYPH<c=18,font=/AAAAAB+DejaVuSans>%GLYPH<c=30,font=/AAAAAB+DejaVuSans>GLYPH<c=31,font=/AAAAAB+DejaVuSans>GLYPH<c=23,font=/AAAAAB+DejaVuSans>"GLYPH<c=28,font=/AAAAAB+DejaVuSans>#GLYPH<c=28,font=/AAAAAB+DejaVuSans>

GLYPH<c=27,font=/AAAAAB+DejaVuSans> !GLYPH<c=29,font=/AAAAAB+DejaVuSans>)$GLYPH<c=28,font=/AAAAAB+DejaVuSans>GLYPH<c=7,font=/AAAAAB+DejaVuSans>GLYPH<c=9,font=/AAAAAB+DejaVuSans>GLYPH<c=10,font=/AAAAAB+DejaVuSans>GLYPH<c=17,font=/AAAAAB+DejaVuSans>

GLYPH<c=21,font=/AAAAAB+DejaVuSans>

GLYPH<c=26,font=/AAAAAB+DejaVuSans>

GLYPH<c=7,font=/AAAAAB+DejaVuSans>

GLYPH<c=27,font=/AAAAAB+DejaVuSans> !GLYPH<c=29,font=/AAAAAB+DejaVuSans>)$GLYPH<c=28,font=/AAAAAB+DejaVuSans>

GLYPH<c=11,font=/AAAAAB+DejaVuSans>GLYPH<c=8,font=/AAAAAB+DejaVuSans>

GLYPH<c=13,font=/AAAAAB+DejaVuSans>GLYPH<c=12,font=/AAAAAB+DejaVuSans>

GLYPH<c=15,font=/AAAAAB+DejaVuSans>GLYPH<c=8,font=/AAAAAB+DejaVuSans>

GLYPH<c=24,font=/AAAAAB+DejaVuSans>%GLYPH<c=30,font=/AAAAAB+DejaVuSans>GLYPH<c=31,font=/AAAAAB+DejaVuSans>GLYPH<c=3,font=/AAAAAB+DejaVuSans>GLYPH<c=21,font=/AAAAAB+DejaVuSans>GLYPH<c=9,font=/AAAAAB+DejaVuSans>GLYPH<c=7,font=/AAAAAB+DejaVuSans>GLYPH<c=25,font=/AAAAAB+DejaVuSans>GLYPH<c=29,font=/AAAAAB+DejaVuSans>%' GLYPH<c=31,font=/AAAAAB+DejaVuSans>GLYPH<c=3,font=/AAAAAB+DejaVuSans>GLYPH<c=5,font=/AAAAAB+DejaVuSans>GLYPH<c=4,font=/AAAAAB+DejaVuSans>GLYPH<c=6,font=/AAAAAB+DejaVuSans>

GLYPH<c=4,font=/AAAAAC+DejaVuSans-Bold>GLYPH<c=12,font=/AAAAAC+DejaVuSans-Bold>GLYPH<c=9,font=/AAAAAC+DejaVuSans-Bold>GLYPH<c=11,font=/AAAAAC+DejaVuSans-Bold>GLYPH<c=8,font=/AAAAAC+DejaVuSans-Bold>GLYPH<c=10,font=/AAAAAC+DejaVuSans-Bold>GLYPH<c=7,font=/AAAAAC+DejaVuSans-Bold>GLYPH<c=6,font=/AAAAAC+DejaVuSans-Bold>GLYPH<c=8,font=/AAAAAC+DejaVuSans-Bold>GLYPH<c=5,font=/AAAAAC+DejaVuSans-Bold>

GLYPH<c=19,font=/AAAAAB+DejaVuSans>!' GLYPH<c=31,font=/AAAAAB+DejaVuSans>GLYPH<c=29,font=/AAAAAB+DejaVuSans>(

GLYPH<c=22,font=/AAAAAB+DejaVuSans>'GLYPH<c=28,font=/AAAAAB+DejaVuSans>& GLYPH<c=25,font=/AAAAAB+DejaVuSans> GLYPH<c=16,font=/AAAAAB+DejaVuSans> GLYPH<c=22,font=/AAAAAB+DejaVuSans>GLYPH<c=20,font=/AAAAAB+DejaVuSans>

GLYPH<c=17,font=/AAAAAD+DejaVuSans>$GLYPH<c=29,font=/AAAAAD+DejaVuSans>GLYPH<c=30,font=/AAAAAD+DejaVuSans>GLYPH<c=22,font=/AAAAAD+DejaVuSans>!GLYPH<c=27,font=/AAAAAD+DejaVuSans>"GLYPH<c=27,font=/AAAAAD+DejaVuSans>GLYPH<c=7,font=/AAAAAD+DejaVuSans>GLYPH<c=13,font=/AAAAAD+DejaVuSans>GLYPH<c=16,font=/AAAAAD+DejaVuSans>

GLYPH<c=20,font=/AAAAAD+DejaVuSans>

GLYPH<c=25,font=/AAAAAD+DejaVuSans>

GLYPH<c=7,font=/AAAAAD+DejaVuSans>GLYPH<c=17,font=/AAAAAD+DejaVuSans>$GLYPH<c=29,font=/AAAAAD+DejaVuSans>GLYPH<c=30,font=/AAAAAD+DejaVuSans>GLYPH<c=22,font=/AAAAAD+DejaVuSans>!GLYPH<c=27,font=/AAAAAD+DejaVuSans>"GLYPH<c=27,font=/AAAAAD+DejaVuSans>

GLYPH<c=26,font=/AAAAAD+DejaVuSans>  GLYPH<c=28,font=/AAAAAD+DejaVuSans>(#GLYPH<c=27,font=/AAAAAD+DejaVuSans>GLYPH<c=7,font=/AAAAAD+DejaVuSans>GLYPH<c=9,font=/AAAAAD+DejaVuSans>GLYPH<c=10,font=/AAAAAD+DejaVuSans>GLYPH<c=16,font=/AAAAAD+DejaVuSans>

GLYPH<c=20,font=/AAAAAD+DejaVuSans>

GLYPH<c=25,font=/AAAAAD+DejaVuSans>

GLYPH<c=7,font=/AAAAAD+DejaVuSans>

GLYPH<c=26,font=/AAAAAD+DejaVuSans>  GLYPH<c=28,font=/AAAAAD+DejaVuSans>(#GLYPH<c=27,font=/AAAAAD+DejaVuSans>

GLYPH<c=11,font=/AAAAAD+DejaVuSans>GLYPH<c=8,font=/AAAAAD+DejaVuSans>

GLYPH<c=12,font=/AAAAAD+DejaVuSans>GLYPH<c=8,font=/AAAAAD+DejaVuSans>

GLYPH<c=14,font=/AAAAAD+DejaVuSans>GLYPH<c=8,font=/AAAAAD+DejaVuSans>

GLYPH<c=23,font=/AAAAAD+DejaVuSans>$GLYPH<c=29,font=/AAAAAD+DejaVuSans>GLYPH<c=30,font=/AAAAAD+DejaVuSans>GLYPH<c=3,font=/AAAAAD+DejaVuSans>GLYPH<c=20,font=/AAAAAD+DejaVuSans>GLYPH<c=9,font=/AAAAAD+DejaVuSans>GLYPH<c=7,font=/AAAAAD+DejaVuSans>GLYPH<c=24,font=/AAAAAD+DejaVuSans>GLYPH<c=28,font=/AAAAAD+DejaVuSans>$& GLYPH<c=30,font=/AAAAAD+DejaVuSans>GLYPH<c=3,font=/AAAAAD+DejaVuSans>GLYPH<c=5,font=/AAAAAD+DejaVuSans>GLYPH<c=4,font=/AAAAAD+DejaVuSans>GLYPH<c=6,font=/AAAAAD+DejaVuSans>

GLYPH<c=5,font=/AAAAAE+DejaVuSans-Bold>GLYPH<c=12,font=/AAAAAE+DejaVuSans-Bold>GLYPH<c=9,font=/AAAAAE+DejaVuSans-Bold>GLYPH<c=9,font=/AAAAAE+DejaVuSans-Bold>GLYPH<c=10,font=/AAAAAE+DejaVuSans-Bold>GLYPH<c=11,font=/AAAAAE+DejaVuSans-Bold>GLYPH<c=9,font=/AAAAAE+DejaVuSans-Bold>GLYPH<c=4,font=/AAAAAE+DejaVuSans-Bold>

GLYPH<c=6,font=/AAAAAE+DejaVuSans-Bold>GLYPH<c=7,font=/AAAAAE+DejaVuSans-Bold>GLYPH<c=8,font=/AAAAAE+DejaVuSans-Bold>

GLYPH<c=18,font=/AAAAAD+DejaVuSans> & GLYPH<c=30,font=/AAAAAD+DejaVuSans>GLYPH<c=28,font=/AAAAAD+DejaVuSans>'

GLYPH<c=21,font=/AAAAAD+DejaVuSans>&GLYPH<c=27,font=/AAAAAD+DejaVuSans>%GLYPH<c=31,font=/AAAAAD+DejaVuSans>GLYPH<c=24,font=/AAAAAD+DejaVuSans> GLYPH<c=15,font=/AAAAAD+DejaVuSans> GLYPH<c=21,font=/AAAAAD+DejaVuSans>GLYPH<c=19,font=/AAAAAD+DejaVuSans>

GLYPH<c=9,font=/AAAAAF+DejaVuSans>GLYPH<c=7,font=/AAAAAF+DejaVuSans>!GLYPH<c=26,font=/AAAAAF+DejaVuSans>GLYPH<c=30,font=/AAAAAF+DejaVuSans>"GLYPH<c=3,font=/AAAAAF+DejaVuSans>GLYPH<c=20,font=/AAAAAF+DejaVuSans>   GLYPH<c=30,font=/AAAAAF+DejaVuSans>GLYPH<c=29,font=/AAAAAF+DejaVuSans>GLYPH<c=31,font=/AAAAAF+DejaVuSans>"

GLYPH<c=10,font=/AAAAAF+DejaVuSans>GLYPH<c=7,font=/AAAAAF+DejaVuSans>!GLYPH<c=26,font=/AAAAAF+DejaVuSans>GLYPH<c=30,font=/AAAAAF+DejaVuSans>"GLYPH<c=3,font=/AAAAAF+DejaVuSans>GLYPH<c=20,font=/AAAAAF+DejaVuSans>   GLYPH<c=30,font=/AAAAAF+DejaVuSans>GLYPH<c=29,font=/AAAAAF+DejaVuSans>GLYPH<c=31,font=/AAAAAF+DejaVuSans>"

GLYPH<c=20,font=/AAAAAF+DejaVuSans>GLYPH<c=28,font=/AAAAAF+DejaVuSans>GLYPH<c=22,font=/AAAAAF+DejaVuSans>GLYPH<c=18,font=/AAAAAF+DejaVuSans>GLYPH<c=3,font=/AAAAAF+DejaVuSans>GLYPH<c=20,font=/AAAAAF+DejaVuSans>  GLYPH<c=30,font=/AAAAAF+DejaVuSans>GLYPH<c=29,font=/AAAAAF+DejaVuSans>GLYPH<c=31,font=/AAAAAF+DejaVuSans>"

GLYPH<c=11,font=/AAAAAF+DejaVuSans>GLYPH<c=8,font=/AAAAAF+DejaVuSans>

GLYPH<c=12,font=/AAAAAF+DejaVuSans>GLYPH<c=8,font=/AAAAAF+DejaVuSans>

GLYPH<c=13,font=/AAAAAF+DejaVuSans>GLYPH<c=8,font=/AAAAAF+DejaVuSans>

GLYPH<c=8,font=/AAAAAG+DejaVuSans-Bold>GLYPH<c=15,font=/AAAAAG+DejaVuSans-Bold>GLYPH<c=11,font=/AAAAAG+DejaVuSans-Bold>GLYPH<c=12,font=/AAAAAG+DejaVuSans-Bold>GLYPH<c=9,font=/AAAAAG+DejaVuSans-Bold>GLYPH<c=13,font=/AAAAAG+DejaVuSans-Bold>GLYPH<c=10,font=/AAAAAG+DejaVuSans-Bold>GLYPH<c=14,font=/AAAAAG+DejaVuSans-Bold>GLYPH<c=10,font=/AAAAAG+DejaVuSans-Bold>GLYPH<c=4,font=/AAAAAG+DejaVuSans-Bold>GLYPH<c=5,font=/AAAAAG+DejaVuSans-Bold>GLYPH<c=6,font=/AAAAAG+DejaVuSans-Bold>GLYPH<c=7,font=/AAAAAG+DejaVuSans-Bold>

GLYPH<c=15,font=/AAAAAF+DejaVuSans>GLYPH<c=27,font=/AAAAAF+DejaVuSans>  GLYPH<c=25,font=/AAAAAF+DejaVuSans>GLYPH<c=23,font=/AAAAAF+DejaVuSans>"

GLYPH<c=18,font=/AAAAAF+DejaVuSans> GLYPH<c=22,font=/AAAAAF+DejaVuSans>GLYPH<c=31,font=/AAAAAF+DejaVuSans>GLYPH<c=26,font=/AAAAAF+DejaVuSans>GLYPH<c=21,font=/AAAAAF+DejaVuSans> GLYPH<c=14,font=/AAAAAF+DejaVuSans> GLYPH<c=18,font=/AAAAAF+DejaVuSans>GLYPH<c=16,font=/AAAAAF+DejaVuSans>

GLYPH<c=9,font=/AAAAAH+DejaVuSans>GLYPH<c=7,font=/AAAAAH+DejaVuSans>!GLYPH<c=26,font=/AAAAAH+DejaVuSans>GLYPH<c=30,font=/AAAAAH+DejaVuSans>"GLYPH<c=3,font=/AAAAAH+DejaVuSans>GLYPH<c=20,font=/AAAAAH+DejaVuSans>   GLYPH<c=30,font=/AAAAAH+DejaVuSans>GLYPH<c=29,font=/AAAAAH+DejaVuSans>GLYPH<c=31,font=/AAAAAH+DejaVuSans>"

GLYPH<c=10,font=/AAAAAH+DejaVuSans>GLYPH<c=7,font=/AAAAAH+DejaVuSans>!GLYPH<c=26,font=/AAAAAH+DejaVuSans>GLYPH<c=30,font=/AAAAAH+DejaVuSans>"GLYPH<c=3,font=/AAAAAH+DejaVuSans>GLYPH<c=20,font=/AAAAAH+DejaVuSans>   GLYPH<c=30,font=/AAAAAH+DejaVuSans>GLYPH<c=29,font=/AAAAAH+DejaVuSans>GLYPH<c=31,font=/AAAAAH+DejaVuSans>"

GLYPH<c=20,font=/AAAAAH+DejaVuSans>GLYPH<c=28,font=/AAAAAH+DejaVuSans>GLYPH<c=22,font=/AAAAAH+DejaVuSans>GLYPH<c=18,font=/AAAAAH+DejaVuSans>GLYPH<c=3,font=/AAAAAH+DejaVuSans>GLYPH<c=20,font=/AAAAAH+DejaVuSans>  GLYPH<c=30,font=/AAAAAH+DejaVuSans>GLYPH<c=29,font=/AAAAAH+DejaVuSans>GLYPH<c=31,font=/AAAAAH+DejaVuSans>"

GLYPH<c=11,font=/AAAAAH+DejaVuSans>GLYPH<c=8,font=/AAAAAH+DejaVuSans>

GLYPH<c=12,font=/AAAAAH+DejaVuSans>GLYPH<c=8,font=/AAAAAH+DejaVuSans>

GLYPH<c=13,font=/AAAAAH+DejaVuSans>GLYPH<c=8,font=/AAAAAH+DejaVuSans>

GLYPH<c=19,font=/AAAAAH+DejaVuSans>GLYPH<c=30,font=/AAAAAH+DejaVuSans>GLYPH<c=24,font=/AAAAAH+DejaVuSans>GLYPH<c=25,font=/AAAAAH+DejaVuSans>GLYPH<c=3,font=/AAAAAH+DejaVuSans>GLYPH<c=17,font=/AAAAAH+DejaVuSans>GLYPH<c=9,font=/AAAAAH+DejaVuSans>GLYPH<c=7,font=/AAAAAH+DejaVuSans>GLYPH<c=21,font=/AAAAAH+DejaVuSans>GLYPH<c=23,font=/AAAAAH+DejaVuSans>GLYPH<c=30,font=/AAAAAH+DejaVuSans>

GLYPH<c=25,font=/AAAAAH+DejaVuSans>GLYPH<c=3,font=/AAAAAH+DejaVuSans>GLYPH<c=5,font=/AAAAAH+DejaVuSans>GLYPH<c=4,font=/AAAAAH+DejaVuSans>GLYPH<c=6,font=/AAAAAH+DejaVuSans>

GLYPH<c=7,font=/AAAAAI+DejaVuSans-Bold>GLYPH<c=9,font=/AAAAAI+DejaVuSans-Bold>GLYPH<c=12,font=/AAAAAI+DejaVuSans-Bold>GLYPH<c=13,font=/AAAAAI+DejaVuSans-Bold>GLYPH<c=11,font=/AAAAAI+DejaVuSans-Bold>GLYPH<c=8,font=/AAAAAI+DejaVuSans-Bold>GLYPH<c=10,font=/AAAAAI+DejaVuSans-Bold>GLYPH<c=4,font=/AAAAAI+DejaVuSans-Bold>GLYPH<c=5,font=/AAAAAI+DejaVuSans-Bold>GLYPH<c=6,font=/AAAAAI+DejaVuSans-Bold>

GLYPH<c=15,font=/AAAAAH+DejaVuSans>GLYPH<c=27,font=/AAAAAH+DejaVuSans>  GLYPH<c=25,font=/AAAAAH+DejaVuSans>GLYPH<c=23,font=/AAAAAH+DejaVuSans>"

GLYPH<c=18,font=/AAAAAH+DejaVuSans> GLYPH<c=22,font=/AAAAAH+DejaVuSans>GLYPH<c=31,font=/AAAAAH+DejaVuSans>GLYPH<c=26,font=/AAAAAH+DejaVuSans>GLYPH<c=21,font=/AAAAAH+DejaVuSans> GLYPH<c=14,font=/AAAAAH+DejaVuSans> GLYPH<c=18,font=/AAAAAH+DejaVuSans>GLYPH<c=16,font=/AAAAAH+DejaVuSans>

(b) Fine-tuned LLMs

(a) Orthogonal to Different Prompts

(b) Orthogonal to Fine-tuned LLMs

(a) Orthogonal to Different Prompts

(b) Orthogonal to Fine-tuned LLMs

The results indicate that (1) LLMs' performance is vulnerable to the scale of task graphs; (2) The performance gain of the proposed method increases with a larger task graph.

5.5 Improved Prompts and Fine-tuned LLMs

In this subsection, we show that the proposed method is orthogonal to two dominant methods, i.e., prompt engineering and fine-tuning.

Orthogonal to Improved Prompts: We investigate GNN's effectiveness when applied to improved prompt templates, i.e., strategically designed prompts that enhance the task planning abilities of LLMs. Specifically, we consider two types of prompts: (1) In-context Learning with Increased Examples [45] During main experiments, we maintain the consistent 1-shot in-context learning example for LLM's direct inference. To realize further improvements, we increase the number of examples to 2 , and results under this setting are denoted as '2-shot Prompt'; (2) Plan like a Graph (PlaG) [30] We adopt the prompt in [30] to encourage LLM to think and plan in a graph-like manner. Specifically, we convert the entire task graph into plain text and then integrate PlaG instructions to enhance LLM's planning. Results under this prompt template are denoted as 'PlaG Prompt'.

From the results shown in Figure 3a, where we apply three different prompts to CodeLlama-13B and Mistral-7B on HuggingFace, it is clear that applying GraphSAGE to improved prompts, where task steps are more concisely decomposed and predictions are more accurate, can also boost performance.

Orthogonal to LLMs' Fine-tuning: To explore whether our framework maintains effectiveness on fine-tuned LLMs, which have acquired dataset-specific task planning capabilities, we conduct further experiments. For each dataset, we use LoRA [19] to fine-tune two LLMs of different parameter scales, including CodeLlama-7B and Vicuna-13B, based on the same training data as GNNs. Details of fine-tuning process are provided in Appendix F.3. The finetuned model is named as 'FT-CodeLlama' and 'FT-Vicuna' in Figure 3b.

The results depicted in Figure 3b demonstrate that fine-tuning markedly enhances the task-planning capabilities of LLMs. Furthermore, applying GraphSAGE to the decomposed tasks of LLMs further improves the accuracy of task planning.

6 Conclusions

This paper presents an initial exploration into graph-learning-based approaches for task planning in language agents. Through theoretical analysis, we demonstrate the inductive bias of the attention mechanism and the utility of auto-regressive loss impedes their effectiveness in task planning. We propose to integrate GNNs for task graph analysis, which yields performance improvements across a range of LLMs and planning benchmarks.

Limitations: Despite the encouraging performance, there are limitations that highlight significant opportunities for enhancement. Firstly, our proposed method, while effective, is straightforward; more sophisticated graph-learning-based decision-making algorithms could potentially offer further improvements. Secondly, the construction of the task graph currently requires manual effort. Investigating automated graph generation techniques for diverse applications is another promising direction for future work.

References

Andrew G Barto, Steven J Bradtke, and Satinder P Singh. Learning to act using real-time dynamic programming. Artificial intelligence , 72(1-2):81-138, 1995.

Timothy EJ Behrens, Timothy H Muller, James CR Whittington, Shirley Mark, Alon B Baram, Kimberly L Stachenfeld, and Zeb Kurth-Nelson. What is a cognitive map? organizing knowledge for flexible behavior. Neuron , 100(2):490-509, 2018.

Richard Bellman. Dynamic programming. science , 153(3731):34-37, 1966.

Maciej Besta, Nils Blach, Ales Kubicek, Robert Gerstenberger, Michal Podstawski, Lukas Gianinazzi, Joanna Gajda, Tomasz Lehmann, Hubert Niewiadomski, Piotr Nyczyk, et al. Graph of thoughts: Solving elaborate problems with large language models. In Proceedings of the AAAI Conference on Artificial Intelligence , volume 38, pp. 17682-17690, 2024.

Daniil A Boiko, Robert MacKnight, Ben Kline, and Gabe Gomes. Autonomous chemical research with large language models. Nature , 624(7992):570-578, 2023.

Blai Bonet and Hector Geffner. Labeled rtdp: Improving the convergence of real-time dynamic programming. In ICAPS , volume 3, pp. 12-21, 2003.

Sébastien Bubeck, Varun Chandrasekaran, Ronen Eldan, Johannes Gehrke, Eric Horvitz, Ece Kamar, Peter Lee, Yin Tat Lee, Yuanzhi Li, Scott Lundberg, et al. Sparks of artificial general intelligence: Early experiments with gpt-4. arXiv preprint arXiv:2303.12712 , 2023.

Quentin Cappart, Didier Chételat, Elias B Khalil, Andrea Lodi, Christopher Morris, and Petar Veliˇ ckovi´ c. Combinatorial optimization and reasoning with graph neural networks. Journal of Machine Learning Research , 24(130):1-61, 2023.

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

Dillon Z Chen, Sylvie Thiébaux, and Felipe Trevizan. Learning domain-independent heuristics for grounded and lifted planning. In Proceedings of the AAAI Conference on Artificial Intelligence , volume 38, pp. 20078-20086, 2024.

Andrew J Dudzik and Petar Veliˇ ckovi´ c. Graph neural networks are dynamic programmers. Advances in neural information processing systems , 35:20635-20647, 2022.

Guhao Feng, Bohang Zhang, Yuntian Gu, Haotian Ye, Di He, and Liwei Wang. Towards revealing the mystery behind chain of thought: a theoretical perspective. Advances in Neural Information Processing Systems , 36, 2024.

Maxime Gasse, Didier Chételat, Nicola Ferroni, Laurent Charlin, and Andrea Lodi. Exact combinatorial optimization with graph convolutional neural networks. Advances in neural information processing systems , 32, 2019.

Jiayan Guo, Lun Du, and Hengyu Liu. Gpt4graph: Can large language models understand graph structured data? an empirical evaluation and benchmarking. arXiv preprint arXiv:2305.15066 , 2023.

William L. Hamilton, Rex Ying, and Jure Leskovec. Inductive representation learning on large graphs. In NIPS , 2017.

Xiaoxin He, Xavier Bresson, Thomas Laurent, Adam Perold, Yann LeCun, and Bryan Hooi. Harnessing explanations: Llm-to-lm interpreter for enhanced text-attributed graph representation learning, 2023.

Xiaoxin He, Yijun Tian, Yifei Sun, Nitesh V Chawla, Thomas Laurent, Yann LeCun, Xavier Bresson, and Bryan Hooi. G-retriever: Retrieval-augmented generation for textual graph understanding and question answering. arXiv preprint arXiv:2402.07630 , 2024.

Malte Helmert and Carmel Domshlak. Landmarks, critical paths and abstractions: what's the difference anyway? In Proceedings of the International Conference on Automated Planning and Scheduling , volume 19, pp. 162-169, 2009.

J. Edward Hu, Yelong Shen, Phillip Wallis, Zeyuan Allen-Zhu, Yuanzhi Li, Shean Wang, and Weizhu Chen. Lora: Low-rank adaptation of large language models. ArXiv , abs/2106.09685, 2021.

Shijue Huang, Wanjun Zhong, Jianqiao Lu, Qi Zhu, Jiahui Gao, Weiwen Liu, Yutai Hou, Xingshan Zeng, Yasheng Wang, Lifeng Shang, Xin Jiang, Ruifeng Xu, and Qun Liu. Planning, creation, usage: Benchmarking llms for comprehensive tool utilization in real-world complex scenarios, 2024.

Wenlong Huang, Pieter Abbeel, Deepak Pathak, and Igor Mordatch. Language models as zero-shot planners: Extracting actionable knowledge for embodied agents. In International Conference on Machine Learning , pp. 9118-9147. PMLR, 2022.

Xu Huang, Weiwen Liu, Xiaolong Chen, Xingmei Wang, Hao Wang, Defu Lian, Yasheng Wang, Ruiming Tang, and Enhong Chen. Understanding the planning of llm agents: A survey. arXiv preprint arXiv:2402.02716 , 2024.

Albert Qiaochu Jiang, Alexandre Sablayrolles, Arthur Mensch, Chris Bamford, Devendra Singh Chaplot, Diego de Las Casas, Florian Bressand, Gianna Lengyel, Guillaume Lample, Lucile Saulnier, L'elio Renard Lavaud, Marie-Anne Lachaux, Pierre Stock, Teven Le Scao, Thibaut Lavril, Thomas Wang, Timothée Lacroix, and William El Sayed. Mistral 7b. ArXiv , abs/2310.06825, 2023.

Elias Khalil, Hanjun Dai, Yuyu Zhang, Bistra Dilkina, and Le Song. Learning combinatorial optimization algorithms over graphs. Advances in neural information processing systems , 30, 2017.

Diederik P. Kingma and Jimmy Ba. Adam: A method for stochastic optimization. CoRR , abs/1412.6980, 2014.

Thomas N. Kipf and Max Welling. Semi-supervised classification with graph convolutional networks. In International Conference on Learning Representations (ICLR) , 2017.

Yuhan Li, Zhixun Li, Peisong Wang, Jia Li, Xiangguo Sun, Hong Cheng, and Jeffrey Xu Yu. A survey of graph meets large language model: Progress and future directions. arXiv preprint arXiv:2311.12399 , 2023.

Yuhan Li, Peisong Wang, Zhixun Li, Jeffrey Xu Yu, and Jia Li. Zerog: Investigating cross-dataset zero-shot transferability in graphs. arXiv preprint arXiv:2402.11235 , 2024.

Zhuwen Li, Qifeng Chen, and Vladlen Koltun. Combinatorial optimization with graph convolutional networks and guided tree search. Advances in neural information processing systems , 31, 2018.

Fangru Lin, Emanuele La Malfa, Valentin Hofmann, Elle Michelle Yang, Anthony Cohn, and Janet B. Pierrehumbert. Graph-enhanced large language models in asynchronous plan reasoning. ArXiv , abs/2402.02805, 2024.

Bo Liu, Yuqian Jiang, Xiaohan Zhang, Qiang Liu, Shiqi Zhang, Joydeep Biswas, and Peter Stone. Llm+ p: Empowering large language models with optimal planning proficiency. arXiv preprint arXiv:2304.11477 , 2023.

Xukun Liu, Zhiyuan Peng, Xiaoyuan Yi, Xing Xie, Lirong Xiang, Yuchen Liu, and Dongkuan Xu. Toolnet: Connecting large language models with massive tools via tool graph. ArXiv , abs/2403.00839, 2024.

Zhaoyang Liu, Zeqiang Lai, Zhangwei Gao, Erfei Cui, Xizhou Zhu, Lewei Lu, Qifeng Chen, Yu Qiao, Jifeng Dai, and Wenhai Wang. Controlllm: Augment language models with tools by searching on graphs. ArXiv , abs/2310.17796, 2023.

Zihan Luo, Xiran Song, Hong Huang, Jianxun Lian, Chenhao Zhang, Jinqi Jiang, Xing Xie, and Hai Jin. Graphinstruct: Empowering large language models with graph understanding and reasoning capability. arXiv preprint arXiv:2403.04483 , 2024.

Jiayuan Mao, Tomás Lozano-Pérez, Josh Tenenbaum, and Leslie Kaelbling. What planning problems can a relational neural network solve? Advances in Neural Information Processing Systems , 36, 2023.

Jiayuan Mao, Tomas Lozano-Perez, Joshua B. Tenenbaum, and Leslie Pack Kaelbing. What Planning Problems Can A Relational Neural Network Solve? In Advances in Neural Information Processing Systems (NeurIPS) , 2023.

Ida Momennejad, Hosein Hasanbeig, Felipe Vieira Frujeri, Hiteshi Sharma, Nebojsa Jojic, Hamid Palangi, Robert Ness, and Jonathan Larson. Evaluating cognitive maps and planning in large language models with CogEval. Advances in Neural Information Processing Systems , 36, 2023.

Bryan Perozzi, Bahare Fatemi, Dustin Zelle, Anton Tsitsulin, Mehran Kazemi, Rami Al-Rfou, and Jonathan Halcrow. Let your graph do the talking: Encoding structured data for llms, 2024.

Yujia Qin, Shihao Liang, Yining Ye, Kunlun Zhu, Lan Yan, Yaxi Lu, Yankai Lin, Xin Cong, Xiangru Tang, Bill Qian, Sihan Zhao, Runchu Tian, Ruobing Xie, Jie Zhou, Mark Gerstein, Dahai Li, Zhiyuan Liu, and Maosong Sun. Toolllm: Facilitating large language models to master 16000+ real-world apis, 2023.

Nils Reimers and Iryna Gurevych. Sentence-bert: Sentence embeddings using siamese bert-networks. In Conference on Empirical Methods in Natural Language Processing , 2019.

Steffen Rendle, Christoph Freudenthaler, Zeno Gantner, and Lars Schmidt-Thieme. Bpr: Bayesian personalized ranking from implicit feedback. arXiv preprint arXiv:1205.2618 , 2012.

Baptiste Rozière, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Tan, Yossi Adi, Jingyu Liu, Tal Remez, Jérémy Rapin, Artyom Kozhevnikov, I. Evtimov, Joanna Bitton, Manish P Bhatt, Cristian Cantón Ferrer, Aaron Grattafiori, Wenhan Xiong, Alexandre D'efossez, Jade Copet, Faisal Azhar, Hugo Touvron, Louis Martin, Nicolas Usunier, Thomas Scialom, and Gabriel Synnaeve. Code llama: Open foundation models for code. ArXiv , abs/2308.12950, 2023.

Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Eric Hambro, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom. Toolformer: Language models can teach themselves to use tools. Advances in Neural Information Processing Systems , 36, 2024.

William Shen, Felipe Trevizan, and Sylvie Thiébaux. Learning domain-independent planning heuristics with hypergraph networks. In Proceedings of the International Conference on Automated Planning and Scheduling , volume 30, pp. 574-584, 2020.

Yongliang Shen, Kaitao Song, Xu Tan, Wenqi Zhang, Kan Ren, Siyu Yuan, Weiming Lu, Dongsheng Li, and Yueting Zhuang. Taskbench: Benchmarking large language models for task automation. arXiv preprint arXiv:2311.18760 , 2023.

Yongliang Shen, Kaitao Song, Xu Tan, Dongsheng Li, Weiming Lu, and Yueting Zhuang. Hugginggpt: Solving ai tasks with chatgpt and its friends in hugging face. Advances in Neural Information Processing Systems , 36, 2024.

Yunsheng Shi, Zhengjie Huang, Wenjin Wang, Hui Zhong, Shikun Feng, and Yu Sun. Masked label prediction: Unified massage passing model for semi-supervised classification. In Proceedings of the Thirtieth International Joint Conference on Artificial Intelligence (IJCA) , 2021.

Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. Reflexion: Language agents with verbal reinforcement learning. Advances in Neural Information Processing Systems , 36, 2024.

Ishika Singh, Valts Blukis, Arsalan Mousavian, Ankit Goyal, Danfei Xu, Jonathan Tremblay, Dieter Fox, Jesse Thomason, and Animesh Garg. Progprompt: Generating situated robot task plans using large language models. In 2023 IEEE International Conference on Robotics and Automation (ICRA) , pp. 11523-11530. IEEE, 2023.

Yifan Song, Weimin Xiong, Dawei Zhu, Wenhao Wu, Han Qian, Mingbo Song, Hailiang Huang, Cheng Li, Ke Wang, Rong Yao, Ye Tian, and Sujian Li. Restgpt: Connecting large language models with real-world restful apis, 2023.

Simon Ståhlberg, Blai Bonet, and Hector Geffner. Learning general optimal policies with graph neural networks: Expressive power, transparency, and limits. In Proceedings of the International Conference on Automated Planning and Scheduling , volume 32, pp. 629-637, 2022.

Jiashuo Sun, Chengjin Xu, Lumingyuan Tang, Sai Wang, Chen Lin, Yeyun Gong, Lionel M. Ni, Heung yeung Shum, and Jian Guo. Think-on-graph: Deep and responsible reasoning of large language model on knowledge graph. 2023.

Jiabin Tang, Yuhao Yang, Wei Wei, Lei Shi, Lixin Su, Suqi Cheng, Dawei Yin, and Chao Huang. GraphGPT: Graph instruction tuning for large language models. arXiv preprint arXiv:2310.13023 , 2023.

Qiaoyu Tang, Ziliang Deng, Hongyu Lin, Xianpei Han, Qiao Liang, and Le Sun. Toolalpaca: Generalized tool learning for language models with 3000 simulated cases, 2023.

Sam Toyer, Felipe W. Trevizan, Sylvie Thiébaux, and Lexing Xie. Asnets: Deep learning for generalised planning. ArXiv , abs/1908.01362, 2019.

Trieu H Trinh, Yuhuai Wu, Quoc V Le, He He, and Thang Luong. Solving Olympiad geometry without human demonstrations. Nature , 625(7995):476-482, 2024.

Petar Veliˇ ckovi´ c, Guillem Cucurull, Arantxa Casanova, Adriana Romero, Pietro Liò, and Yoshua Bengio. Graph attention networks. International Conference on Learning Representations , 2018.

Guanzhi Wang, Yuqi Xie, Yunfan Jiang, Ajay Mandlekar, Chaowei Xiao, Yuke Zhu, Linxi Fan, and Anima Anandkumar. Voyager: An open-ended embodied agent with large language models. arXiv preprint arXiv:2305.16291 , 2023.

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

Lei Wang, Wanyu Xu, Yihuai Lan, Zhiqiang Hu, Yunshi Lan, Roy Ka-Wei Lee, and Ee-Peng Lim. Planand-solve prompting: Improving zero-shot chain-of-thought reasoning by large language models. arXiv preprint arXiv:2305.04091 , 2023.

Lei Wang, Chen Ma, Xueyang Feng, Zeyu Zhang, Hao Yang, Jingsen Zhang, Zhiyuan Chen, Jiakai Tang, Xu Chen, Yankai Lin, et al. A survey on large language model based autonomous agents. Frontiers of Computer Science , 18(6):1-26, 2024.

Liang Wang, Nan Yang, Xiaolong Huang, Binxing Jiao, Linjun Yang, Daxin Jiang, Rangan Majumder, and Furu Wei. Text embeddings by weakly-supervised contrastive pre-training. ArXiv , abs/2212.03533, 2022.

Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Fei Xia, Ed Chi, Quoc V Le, Denny Zhou, et al. Chain-of-thought prompting elicits reasoning in large language models. Advances in neural information processing systems , 35:24824-24837, 2022.

James CR Whittington, Timothy H Muller, Shirley Mark, Guifen Chen, Caswell Barry, Neil Burgess, and Timothy EJ Behrens. The tolman-eichenbaum machine: unifying space and relational memory through generalization in the hippocampal formation. Cell , 183(5):1249-1263, 2020.

Felix Wu, Amauri Souza, Tianyi Zhang, Christopher Fifty, Tao Yu, and Kilian Weinberger. Simplifying graph convolutional networks. In International conference on machine learning , pp. 6861-6871. PMLR, 2019.

Guangxuan Xiao, Yuandong Tian, Beidi Chen, Song Han, and Mike Lewis. Efficient streaming language models with attention sinks. arXiv preprint arXiv:2309.17453 , 2023.

Keyulu Xu, Weihua Hu, Jure Leskovec, and Stefanie Jegelka. How powerful are graph neural networks? In International Conference on Learning Representations , 2019.

Keyulu Xu, Jingling Li, Mozhi Zhang, Simon S Du, Ken-ichi Kawarabayashi, and Stefanie Jegelka. What can neural networks reason about? arXiv preprint arXiv:1905.13211 , 2019.

Ai Ming Yang, Bin Xiao, and et al. Baichuan 2: Open large-scale language models. ArXiv , abs/2309.10305, 2023.

Kai Yang, Jan Ackermann, Zhenyu He, Guhao Feng, Bohang Zhang, Yunzhen Feng, Qiwei Ye, Di He, and Liwei Wang. Do efficient transformers really save computation? arXiv preprint arXiv:2402.13934 , 2024.

Shunyu Yao, Dian Yu, Jeffrey Zhao, Izhak Shafran, Tom Griffiths, Yuan Cao, and Karthik Narasimhan. Tree of thoughts: Deliberate problem solving with large language models. Advances in Neural Information Processing Systems , 36, 2024.

Lianmin Zheng, Wei-Lin Chiang, Ying Sheng, Siyuan Zhuang, Zhanghao Wu, Yonghao Zhuang, Zi Lin, Zhuohan Li, Dacheng Li, Eric P. Xing, Haotong Zhang, Joseph Gonzalez, and Ion Stoica. Judging llm-as-a-judge with mt-bench and chatbot arena. ArXiv , abs/2306.05685, 2023.

Wanjun Zhong, Lianghong Guo, Qiqi Gao, He Ye, and Yanlin Wang. Memorybank: Enhancing large language models with long-term memory. In Proceedings of the AAAI Conference on Artificial Intelligence , volume 38, pp. 19724-19731, 2024.

Contents

A Related Works and Discussions

A.1 Planning Algorithms in LLMs

The existing studies of task planning approaches can be categorized into several directions, including task decomposition, multi-plan selection, the use of external planners, reflection, and memory-aided planning [22]. Task decomposition methods, such as the chain-of-thought approach [63], employ the divide-and-conquer strategy, utilizing LLMs for both task decomposition and sub-task planning. The application of this method to task planning is detailed in Section 2.2 and is referred to as 'Direct' in the baseline comparison. Multi-plan selection strategies, exemplified by the tree-of-thought [71] and graph-of-thought [4], leverage search-based methods to generate plans. Subsequently, LLMs evaluate these plans to select the most effective one. The 'GraphSearch' methods used in our baselines fall into this category. External planner approaches [31] use LLMs to convert the problem into Planning Domain Definition Language (PDDL) and then employ classic solvers to address the planning problem. PDDL requires a pre-defined goal, for example, moving the blocks from one state to another state. However, the goal of task planning investigated in language agents deals with more flexible and personal goals, spanning personal needs in video, text, and image processing. Translating these goals into formal PDDL is very difficult. We instead demonstrate that GNNs can serve as an effective external planner in this application. Reflection-based methods [48] focus on reflecting upon experiences to refine the plan, while memory-aided planning approaches [73] utilize external experiences, such as those from search engines. These approaches are deployed in interactive environments and orthogonal to this paper.

A.2 Task Planning in Traditional AI

Apart from task planning in language agents, there is also a domain in traditional AI called task planning [1, 6, 18, 55, 44, 51, 35, 10]. Task planning in traditional AI is defined as ( S , A , T , C , G , s 0 ) , where S is the states, A is the action space, T : S × S × A → [0 , 1] , a cost function C : S × A → [0 , ∞ ) , a set of goal states G ⊆ S , and an initial state s 0 . An agent following a policy π : A×S → [0 , 1] will start in state s 0 , then repeatedly choose an action a ∼ π ( a | s ) and execute it to reach a new state s ′ ∼ T ( s ′ | s, a ) , incurring a cost C ( s, a ) along its way. An optimal policy π ∗ ( a | s ) is one that reaches the goal state with probability 1 while minimizing the total expected cost. Traditionally, task planning is solved by reinforcement learning approaches [6] and heuristic A ∗ approaches [18]. The neural network-based approaches are employed to accelerate the computation and improve the performance [55, 44, 51, 35, 10].

The task planning in language agents is a different application. It cannot be solved as a constraint satisfaction problem, since both the features of task graph and user request are expressed in natural language. Compared with traditional planning, task planning for language agents involves diverse and open-ended goals due to the varied personal requirements users have. For example, on platforms like Hugging Face, users' intentions span across video, text, and image domains. On the contrary, classic planning has a fixed goal for a given domain, e.g., in the n-puzzle [55], the goal is formally as placing the tiles in numerical order. Within this new application domain, while existing research primarily focuses on prompt design for pre-trained LLMs, our work underscores the importance of traditional planning methods, such as GNNs, in complementing LLMs.

A.3 Planning in Agents and Neuroscience

Planning is a pivotal topic in both agents and neuroscience, where graphs play an indispensable role. We believe the concepts and insights presented in this paper are useful to these fields.

The TaskBench, RestBench, and UltraTool dataset used in this paper belongs to the tool agents. The Math agent, AlphaGeometry, employs LLMs to generate auxiliary constructions in geometry [56]. Considering lemmas as nodes and their interdependencies as edges, the endeavor to prove a theorem resembles the task of identifying a route to the theorem node within the graph constituted by potential lemma nodes and the edges that represent their interdependencies. There are no explicit task graphs in game agents [58], embodied agents [21], and code agents [48]. The core strategy in these domains is to employ verbal reinforcement learning within LLMs. The state and transitions in reinforcement learning can be modeled as nodes and edges in the graph. In addition, there are case-by-case graph models in these agent applications. For example, in code agents, one can view the class as the nodes

and dependencies as the edges. In the embodied agents, the objects in the environment can be viewed as the nodes.

In the neuroscience, animal planning is often assessed through path planning in mazes [2, 64]. Inspired by these animal experiments, planning testbenches have been developed for LLMs [37]. A computational model known as the Tolman-Eichenbaum Machine (TEM) has been proposed to decipher the mechanisms of general planning in animals across various environments, such as mazes [64]. The TEM model posits that hippocampal cells, including place and landmark cells, remap between environments, while entorhinal cells exhibit a range of properties that mirror spatial responses, including grid, band, border, and object-vector cells. In essence, hippocampal cells map sensory inputs onto locations in abstract graphs and remap, and entorhinal cells execute graph operations.

A.4 LLMs for Graphs

With the breakthroughs in LLMs, there has been a surge of interest in applying LLMs to graphrelated problems [27, 28]. GPT4Graph [14] and NLGraph [59] are two prominent benchmarks designed to evaluate the performance of LLMs in the context of graph tasks. They encompass a wide spectrum of challenges, various input formats, and state-of-the-art prompting techniques, demonstrating that LLMs possess basic graph processing capabilities. Importantly, the choice of prompts and formats significantly influences performance. However, these benchmarks also expose the models' susceptibility to spurious correlations within graphs. For instance, GPT-4 achieves only about 50% accuracy on shortest-path tasks, even with the use of complex prompts. GraphInstruct [34] attempts to fine-tune LLMs on graph-theory-related tasks, resulting in improved performance, though it remains far from satisfactory. Despite these empirical efforts, there is a limited theoretical understanding of these evaluation results. The analysis in Section 3.3 aims to shed light on the empirical observations reported in these studies.

Considering these negative results, a new line of research has emerged that utilizes the output of GNNs as tokens for LLMs, as seen in GraphGPT [53], GraphLLM [9], GraphToken [38], and G-Retriever [17]. These approaches have demonstrated significant improvements in performance on GNN-related tasks. However, they have not yet been applied to task planning due to the lack of extensive training data. A promising future direction involves using task planning data generated by GPT to fine-tune graph foundation models, such as GraphGPT [53], and applying them to task planning. This paper proposes to use task planning as a new benchmark for this line of research.

A.5 Theoretical Analysis of Reasoning

Reasoning is closely related to task planning and decision-making. The theoretical exploration of the reasoning abilities of neural networks was initiated by [68]. This work unifies various reasoning tasks, such as intuitive physics, visual question answering, and shortest path calculations, into DP problems. It then analyzes the generalization capabilities of MLPs, DeepSets, and GNNs. It is demonstrated that GNNs exhibit the best generalization bounds, attributed to their architecture's resemblance to the Bellman-Ford algorithm, which is adept at solving DP problems. In terms of reasoning abilities within LLMs, [12] examines how the Chain of Thought (CoT) approach aids in solving arithmetic and DP problems without graphs. By decomposing challenging problems into simpler subproblems, CoT extends the expressive capabilities of Transformers from TC 0 to P. This analysis is further applied to linear and sparse Transformers in [70].

Our proof of Theorem 1 builds upon the proof of Theorem 4.7 in [12]. However, while [12] addresses DP problems without graph structures, Theorem 1 specifically focuses on DP problems with graph edge list inputs. Moreover, unlike [12], which decomposes and solves the DP problem sequentially, Theorem 1 proposes a method to simulate DP on edge lists in parallel. In addition, we analyze the negative results rising from the inductive bias of attention mechanism and auto-regressive loss. These theoretical contributions are novel and promise to be valuable for general reasoning and planning tasks.

A.6 GNNs and GraphSearch for Combinatorial Optimization

GNNs are popular approaches for solving decision-making problems on graphs. The problems investigated are typically NP-hard, such as the minimum vertex cover, maximum cut, and the traveling salesman problem [8]. The basic approach involves selecting nodes one by one in a manner that satisfies the constraints [24]. In this paper, we adopt this method to sequentially select task nodes. Furthermore, reinforcement learning can be used to enhance the performance of GNNs beyond what is achievable with supervised labels alone [24]. In [24], the node with the highest score is selected exclusively. Conversely, [29] employs beam search to improve performance by selecting the topk nodes in a single iteration. Additionally, GNNs are utilized as the method for variable selection in exhaustive searches for exact solutions to combinatorial optimization problems [13]. This paper conceptualizes task planning as a graph-based decision-making problem. Both greedy and beam search algorithms have been adopted in task planning [33, 32]. Given this connection, a promising future direction involves repurposing GNNs for decision-making approaches in taskplanning applications.

B Prompts

Based on the above tasks, I want you to generate task steps and a task invocation graph (including nodes and edges) to address the # USER REQUEST #. The format must be in strict JSON format, like:

Generated task steps and task nodes can resolve the user request # USER REQUEST # perfectly. Task

The task steps should strictly align with the task nodes, and the number of task steps should be same

The task links should reflect the temporal and resource dependencies among task nodes, i.e., the order

Now, please generate your response in a strict JSON format: # RESULT #

C Datasets

C.1 Overview

We provide the statistics of experimental datasets from three task planning benchmarks in Table 7. The illustrative examples from each dataset are shown in Figure 4. For datasets from TaskBench [45], each sample consists of original user request, corresponding decomposed task steps, and groundtruth task invocation path. As RestBench [50] and UltraTool [20] include only user requests and corresponding API invocation sequences, we prompt GPT-4 to infer decomposed task steps aligned with each invoked API, thereby finalizing the dataset.

C.2 Reformatting Details of RestBench

The TMDB dataset from RestBench, focuses on movie-related searching and recommending functions. To align RestBench with our experiments, we have implemented the following processing steps:

Reformatting original APIs by assigning unique task names and descriptions: APIs in RestBench were represented by request paths, such as ' GET /movie/top_rated ', referring to the API that retrieves top-rated movies on TMDB. To enhance semantic differentiation among APIs, we first prompt GPT-4 to assign a unique name and a detailed functional description to each API. These names and descriptions were then manually verified and refined. For example, the API previously mentioned is renamed ' Get Top-Rated Movies ' with the description: 'This API retrieves a list of the highest-rated movies.' Note that though the original TMDB dataset contains 54 APIs, some were never invoked in any data examples. Therefore, we focus only on those APIs that appeared in at least one user request, resulting in a refined set of 46 APIs.

Constructing a Task Graph: Each API is regarded as a unique task node, and we depict their relationships from two aspects: (1) categorical association, and (2) resource dependencies. For instance, APIs that provide movie-related functionalities, such as retrieving movie details or recommending films, are grouped under the movie category. Conversely, APIs focused on person-related functions, like searching for actors, are classified under the person category. Additionally, if two APIs share a common parameter like move_id , we establish a link between them to indicate a resource dependency.

Reformatting Raw Data Examples: The original data samples in RestBench included a single query and its corresponding API invocation sequence. To reformat this data into a path structure, we treated each invoked API as a node and the sequence of invocations as directed links from one API to the next. For example, a TMDB data sample consists of the query ' Who was the lead actor in the movie The Dark Knight ' and corresponding ground-truth API solution [ ' GET /search/movie ', ' GET /movie/{movie_id}/credits ' ] . We transform this solution into a task invocation path as ' { 'task_nodes': [ ' Search Movie ', ' Get Movie Credit ' ] , 'task_links': [ { 'source': ' Search Movie ', 'target': ' Get Movie Credit ' } ] } '.

C.3 Reformatting Details of UltraTool

Motivation: In our main experiments using TaskBench [45] and RestBench [50], we observed that strong LLMs like GPT-4-turbo already perform well. This may be attributed to two factors: (1) the training of GPT-4-turbo likely included knowledge relevent to these benchmarks, as both were released before GPT-4 and utilize popular platforms such as HuggingFace and TMDB; (2) the task

HuggingFace

TMDB

I just finished watching Titanic

and I want some other movie

recommendations.

Step 1

Call Search Movie to find

the movie ID of Titanic

Step 2

Call Movie Recommend

to obtain a list of recommended

movies based on Titanic's ID

Daily Life

Multimedia

I have an image 'example.jpg'. I

want to detect the objects in the

image, generate a brief summary

describing them, and then

modify the image accordingly.

Step 1

Detect objects in the image

Step 2

Apply Summarization on

the output of step 1

Step 3

Modify the image based on

the summarized text

User Request

Task Steps

Task Invocation Path

Object

Detection

Summarization

Image

Editing

I have an old black and white

photo 'example.jpg'. I would

like to colorize the image and

then find other images that are

similar to the colorized version.

Step 1

Colorize the input image

Step 2

Perform a similar image

search using the colorized image

as input to the Image Search tool

Image

Colorizer

Image Search

By Image

Help me order a pizza from Uber

Eats at my place (12 Main St.).

Also, send an invitation email to

my friend at

.

Then, I'll need a taxi to pick up

my friend from her place.

Step 1

Call Order Food Delivery

API with food

'Pizza',

location

'123

and platform

'Uber Eats'

Step 2

Call Send Email with

address … and content …

Step 3

Call Order Taxi with

location

'12 Main St'

Order

Food Delivery

Order Taxi

Search Movie

Movie

Recommend

graphs are relatively small, containing no more than 50 tasks, which falls within the capabilities of LLMs. Therefore, we aim to evacuate planning performance as well as GNN's effectiveness in a more challenging scenario, i.e., one that requires specific knowledge beyond the LLM's training and involves larger task graphs that possibly exceed its memory and reasoning capabilities.

Constructing a Task Graph: We utilized UltraTool [20], released in March 2024, which features complex planning scenarios across thousands of tasks, including travel, tourism, and other daily life domains. The original UltraTool contains 5 , 824 samples with 2 , 032 available tasks across 22 distinct domains. However, we observed that some tasks appear in only one sample, making them quite rare. Therefore, we filtered this dataset as follows: first, we considered only tasks that appeared more than 5 times across all samples, focusing on more common tasks that cater to daily life. Next, we retained samples that incorporated these filtered tasks, ensuring that the number of invoked tasks exceeded 2 to satisfy the multi-task planning scenario. After this filtering, we identified 260 distinct tasks . We then constructed the task graph by treating each task as a node and adding links between tasks that were invoked sequentially in the dataset. For each task, we further verified and refined its functional descriptions to ensure semantic suitability.

Reformatting Raw Data Examples: We allocated 500 samples for testing and 3 , 000 samples for GNN training. Although the original UltraTool provided decomposed steps, we found them too coarse-grained, making it difficult to align step descriptions with suitable tasks. Therefore, we employed a similar strategy by prompting GPT-4 to infer decomposed task steps that align with each invoked task. As a result, each data sample consists of the user request, corresponding steps, and ground-truth invoked tasks, ensuring high quality for GNN training.

D Supplementary Materials for Theoretical Results

D.1 Dynamic Programming

Longest Increasing Subsequence: The Longest Increasing Subsequence (LIS) problem is a classic dynamic programming problem that involves finding the length of the longest subsequence within a given array arr where the elements are in strictly increasing order. The state transition function for the LIS problem can be expressed as:

̸

where T ( i ) = { i }∪{ j | j < i and arr [ j ] < arr [ i ] } denotes the set of states that can transfer to state i , the aggregation function g ( x, y ) is implemented as max( x, y ) , and the cost c [ i ][ j ] is 1 for those candidate states that are not equal to state i as adding the element leads to a longer subsequence while 0 for the state itself.

Bellman-Ford Algorithm: The Bellman-Ford algorithm is also a classic dynamic programming algorithm used to find the shortest paths from a single source vertex to all other vertices in a weighted graph. The core idea behind the Bellman-Ford algorithm is that the distance from the source vertex to a target vertex can be computed as the minimum distance from the source to any of the target's neighboring vertices, plus the weight of the edge connecting the neighbor to the target. Therefore, the state transition function for the Bellman-Ford algorithm can be expressed as:

where Answer [ k ][ i ] represents the length of the shortest path from the source vertex to node i at the k -th iteration, T ( i ) = N -( i ) denotes the set of in-neighbors of node i , and w [ j ][ i ] denotes the weight from node j to i . The aggregation function g ( x, y ) is implemented as min( x, y ) as we try to find the shortest path.

Travelling Salesman Problem (TSP): This problem is defined as, given a set of cities and the distances between every pair of cities, finding the shortest possible route that visits every city exactly once and returns to the starting point. If we regard the set of already visited city S ending at i -th city as the current state, then states that can transfer to current state are those that ending city can reach k . Therefore, the state transition function for the TSP problem can be expressed as:

̸

where Answer [ k ][ i ][ S ] represents the cost of the shortest tour that visits all the cities in the set S and ends at the i -th city, the aggregation function g ( x, y ) is still implemented as min( x, y ) since we aim to find the shortest path, and w [ j ][ i ] denotes the distance from city j to city i .

D.2 Proof of Theorem 1

Assumption 1. Each function f, g in (2) can be approximated by constant size MLP.

Assumption 2. The aggregation function □ in (2) is one of min, max, sum, mean.

The first assumption is mild as MLPs are universal approximators. The second assumption is mild because these are the most commonly used aggregation functions.

Theorem 3. (Expressiveness) Assume the input format is given in (1) and f, g, □ in DP update (2) satisfy the assumptions 1 and 2. There exists a log-precision constant-depth and constant-width Transformer that simulates 1 steps of DP update in (2) . As a consequence, there exists a log-precision O ( k ) -depth and constant-width Transformer that simulates k steps of DP update in (2) .

Proof. Token Embedding and Positional Embedding: The three-dimensional token embedding includes the token type e type1 ( 0 for answer; 1 for node; 2 for edge cost), refined token type e type2 ( 0 for answer, 1 for the node tokens in initial states, 2 for the target node tokens in the edge list, 3 for the source node tokens in the edge list, 4 for edge cost), and the token id e token (from 0 to | V | -1 ). The two-dimensional positional embedding includes the embedding for initial state tokens e pos1 ( 0 for edge list tokens, 1 for the first two elements of initial states, 2 for the second two elements

of initial states, etc.), embedding for edge list tokens e pos2 ( 0 for initial state tokens, 1 for the first three elements of the edge list, 2 for the second three elements of the edge list, etc.). There are also constant-dimensional placeholders to put the states of DP.

Block 1 - Initial State Broadcast: The goal of the first block is to broadcast the initial states from the initial state token to node tokens. (1) Use MLPs to recover the digits of the answer tokens and put them in the first placeholder if e type k == 0 ; (2) Copy the first placeholder from answer token to its previous node token by using COPY in Lemma 1 and setting S k = { j | ( e pos1 k -e pos1 j ) 2 < δ } ; (3) Broadcast the first placeholder with SUM in Lemma 1 and setting S k = { j | ( e type1 k -e type1 j ) 2 +( e token k -e token j ) 2 < δ } . Now the state for every node token u i is [ e type1 , e type2 , e token , e pos1 , e pos2 , Answer [0][ u i ]] .

Block 2 - Edge Feature Operations: The goal of the second block is to copy the edge features from the edge feature token to the corresponding node tokens. (1) Use MLPs to recover the digits of the edge feature tokens and put them in the second placeholder if e type1 == 2 ; (2) Copy the second placeholder from the edge feature token to the node token by using SUM in Lemma 1 and setting S k = { j | ( e pos2 k -e pos2 j ) 2 < δ } . Now the state for every node token u i of the i -th edge is [ e type1 , e type2 , e token , e pos1 , e pos2 , Answer [0][ u i ] , c [ u i ][ v i ]] .

Block 3 -Message Preparation: (1) Use MLPs to compute g and place the results in the third placeholder. Now the state for every node token u i of the i -th edge is [ e type1 , e type2 , e token , e pos1 , e pos2 , Answer [0][ u i ] , c [ u i ][ v i ] , g ( Answer [0][ u i ] , c [ u i ][ v i ])] ; (2) Use MLPs to clean up the first and second placeholder. Now the state for every node token u i is [ e type1 , e type2 , e token , e pos1 , e pos2 , g ( Answer [0][ u i ] , c [ u i ][ v i ])]

Block 4 - Message Passing: The goal of the fourth block is to compute □ and f . (1) Use one or two attention heads (one for max, min, mean aggregations, and two for sum aggregations) to perform the aggregation operation. This is achieved by using MEAN or MAX or SUM for the first placeholder and setting S k = { j | ( e token k -e token j ) 2 +( e type2 k -e type2 j ) 2 < δ } . Now the state for every node token u i is [ e type1 , e type2 , e token , e pos1 , e pos2 , □ v j ∈T ( u i ) g ( Answer [0][ u i ] , c [ u i ][ v j ])] ; (2) Use MLPs to compute f . Now the state for every node token is [ e type1 , e type2 , e token , e pos1 , e pos2 , f ( □ v j ∈T ( i ) g ( Answer [0][ u i ] , c [ u i ][ v j ]))] .

After four blocks, the final state for every node token u i is given by [ e type1 , e type2 , e token , e pos1 , e pos2 , Answer [1][ u i ]] . Answer [ k ][ u i ] can be obtained by repeating the above four blocks k times.

Lemma 1. [12] Let n ∈ N be an integer and x 1 , · · · , x n be a sequence of vectors where x i = (˜ x i , r i , 1) ∈ [ -M,M ] d +2 where M is a large constant. Let K , Q , V ∈ R d ′ × ( d +2) be any matrices with ∥ V ∥ ∞ ≤ 1 and let 0 < ρ, δ < M be any real numbers. Denote q i = Qx i , k j = Kx i , v j = V x j . Define a matching set S = { j || q T i k j | ≤ ρ } . Define two following operations

COPY : The output is a sequence of vectors u 1 , · · · , u n with u i = v pos ( i ) , where pos ( i ) = arg max j ∈S i r j .

MEAN, MAX, SUM : The output is a sequence of vectors u 1 , · · · , u n , where u i = □ j ∈S i v j and □ is min or max or sum or mean.

Specifically, for any sequence of vectors x 1 , x 2 , · · · , x n , denote the corresponding output of the attention layer as o 1 , o 2 , · · · , o n . Then, we have ∥ u i -o i ∥ ∞ ≤ ϵ for all i ∈ [ n ] and S ̸ = ∅ .

D.3 Permutation Invariance Test of LLMs

We test whether LLMs respect the permutation invariance property in graph problems and the results are given in Figure 5.

D.4 Proof of Proposition 1

Proposition 2. Assume the input format is as described in Equation (1) and that the attention mechanism is limited to attending to a constant number of tokens. There exists at least one instance

0

1

2

3

4

5

6

7

8

An undirected graph with edge list: [[0, 1], [1, 2], [2, 3], [3, 4], [0, 4], [2, 4], [0, 3], [2, 5], [5, 6], [6, 7], [7, 8], [5, 8], [5, 7], [6, 8]]. What is the diameter of this graph? Only provide a concrete number.

Mistral-7B

GPT-4-turbo

4

1

2

3

0

5

6

7

8

An undirected graph with edge list: [[4, 1], [1, 2], [2, 3], [3, 0], [4, 0], [2, 0], [4, 3], [2, 5], [5, 6], [6, 7], [7, 8], [5, 8], [5, 7], [6, 8]]. What is the diameter of this graph? Only provide a concrete number.

0

4

5

3

1

2

6

7

8

An undirected graph with edge list: [[0,

4], [4, 5], [5, 3], [3, 1], [0, 1], [5, 1], [0,

3], [5, 2], [2, 6], [6, 7], [7, 8], [2, 8], [2,

7], [6, 8]]. What is the diameter of this

graph? Only provide a concrete number.

3    4     5     6   NA

Predicted diameter distribution

5    6     7

3    4     5     6   NA

3    4     5     6   NA

5    6     7

5    6     7

Predicted diameter distribution

Predicted diameter distribution

of one-step DP update such that no log-precision constant-width constant-depth transformer can simulate.

Proof. We present a proof by contradiction. Assume that a token in a Transformer with a constant depth, constant width, and log-precision can attend to only a constant number of nodes. Under this assumption, the total information accessible to the token in such a Transformer architecture amounts to O (log n ) bits. However, for a graph with | V | nodes, the number of possible outcomes from executing one-step DP is O ( e | V | ) , necessitating Θ( | V | ) bits for representation. By the pigeonhole principle, this scenario inevitably leads to at least two distinct DP outcomes being represented by the same output sequence generated by the model, thereby constituting a contradiction.

D.5 Proof of Theorem 2

Theorem 4. (Spurious correlations of auto-regressive loss) Assume (1) the loss employed is a nexttoken-prediction loss utilizing cross-entropy, applied to the sub-sequence v 1 v 2 · · · t during training; (2) the output logits are determined by target node t and the current node v i -1 . Let N t,v i -1 ,u be the number of times in the training dataset such that t is the target node, v i -1 is the current node and v i = u is the next node. The optimal logits for predicting the next node u from current node v i -1 towards target node t is given by ˆ v i [ u ] = N t,v i -1 ,u ∑ u N t,v i -1 ,u if ∑ u N t,v i -1 ,u > 0 . If ∑ u N t,v i -1 ,u = 0 , ˆ v i [ u ] can be any non-negative number subject to ∑ u ˆ v i [ u ] = 1 .

Proof. We denote D as the training dataset, L i as the sequence length of the i -th sequence in the dataset, v i,j as the one hot embedding of the j -th token in the i -th training sequence, and ˆ v i,j,u as the u -th logit at the j -th token in the i -th sequence. The cross-entropy loss is given by

̸

where (a) uses the assumption that the output logits are determined by target node t and the current node v i -1 . In (b), we assume that ∑ u N t,v i -1 ,u = 0 . The cross-entropy is minimized when ˆ v i,j,u = N t,v j -1 ,u ∑ u N t,v j -1 ,u . If ∑ u N t,v i -1 ,u = 0 , then the corresponding logits will not affect the loss function and ˆ v i,j,u can take any number.

(a) Direct

User Request

Alter the color of red

cars to blue in

'example.jpg', label

the objects, and

classify the labels.

Invocation Path

Image Editing

Object

Detection

Token

Classification

LLM

User Request

Alter the color of red

cars to blue in

'example.jpg', label

the objects, and

classify the labels.

Decomposed Steps

Step 1

Edit the image

based on the given text

Step 2

Detect objects in

the image

Step 3

Perform token

classification on the

detected labels

LLM

Step1

Edit the image

based on the given …

Task Graph

LLM

Image

Editing

Detect objects

in the image

LLM

Step 3

Perform token

classification on …

LLM

Strategy: Greedy / Adaptive /

Beam

All Searched Paths

['Image Editing', 'Object

Detection', 'Token Classification']

['Image Editing', 'Object

Detection', 'Summarization']

······

LLM

Task Assessment

Path Selection

Image

-to-Image

Object

Detection

Image

Segmentation

Tabular

Classification

Token

Classification

Summarization

Translation

Invocation Path

1

2

3

Image Editing

Object

Detection

Token

Classification

(b) GraphSearch

E Supplementary Materials for Training-free Methods

E.1 Implementation of Baselines

In this subsection, we present the implementation details of training-free baselines, including LLM's direct inference, GraphSearch, and ours SGC. Method illustrations are shown in Figure 6.

LLM's Direct Inference: The prompt template for LLM's direct inference is given in Table 4. During experiments, we uniformly apply 1-shot in context learning for LLM's direct inference of task invocation path. For open-sourced LLMs, the temperature parameter is set to 0 . 2 .

GraphSearch: The prompt template for GraphSearch is given in Table 5. This algorithm conducts an iterative search on the task graph to identify an optimal task invocation path that can best satisfy a given request. In each iteration, the neighbors of the last selected task are considered as candidates. These candidates are evaluated by LLM for their suitability for the current step ( Task Assessment ). The search process follows a depth-first approach. After the task assessment in the final step, a set of potential invocation paths is generated. Subsequently, LLM is prompted to select the most appropriate path from these options ( Path Selection ). The GraphSearch algorithm is implemented in three distinct variants, each employing a unique task selection strategy:

GreedySearch consistently selects the task node with the highest score at each step. Although fast and simple, this approach can lead to cascading errors, resulting in degraded performance.

AdaptiveSearch selects tasks with scores above a fixed threshold , adjusting the breadth of the search space in an adaptive mode. During experiments, we empirically set the score threshold to 3 .

BeamSearch retains the topk tasks based on the LLM's assessment scores within candidates. Beam search can expand the search space but slightly reduces the efficiency. We uniformly set the beam width to 2 .

Ours SGC: Regarding the choices of LM backbones, for integrating GPT-3.5-turbo and GPT-4-turbo with SGC, the Roberta-355M [40] serves as the text encoder. For all other datasets and LLMs, the e5-335M [62] configuration is employed.

E.2 Results of All LLMs

Table 8 supplements Table 1 with other LLMs. The proposed methods perform consistently better.

E.3 Accuracy Results of Training-free Methods

Due to space limitations, we present only the Node-F1 and Link-F1 scores for training-free methods in the main text. Here, we provide the Accuracy results in Table 9. These results show that integrating SGC significantly enhances accuracy across different LLMs on all datasets, making previously unsolvable planning scenarios manageable and successful.

E.4 Computational Cost Analysis

In this subsection, we present a comprehensive efficiency study on inference time of training-free methods and results are shown in Table 10.

Open-sourced LLMs were deployed as local API services using the FastChat framework 4 on a single A100-80G GPU. This configuration enables faster and parallel inference. Under this setup, LLM's direct inference requires 3-15 seconds per request. GPT-3.5-turbo and GPT-4-turbo are accessed via API, with the latter generally requiring more time. GraphSearch requires several minutes to complete a request due to its exhaustive search on the task graph, impacting the efficiency. In contrast, SGC achieves comparable efficiency to LLM's direct inference, as it requires only a single LLM query and both LM and SGC's forward propagation processes are extremely efficient (typically completing within seconds). Note that some discrepancies in reported times, such as Mistral-7B's GreedySearch taking longer than other modes, may be attributed to variations in the deployment across different A100 services.

User Request

Alter the color of red

cars to blue in

'example.jpg', label

the objects, and

classify the labels.

Decomposed Steps

Step 1

Edit the image

based on the given text

Step 2

Detect objects in

the image

Step 3

Perform token

classification on the

detected labels

LLM

1

GNN

Extract text from the

image file 'image.jpg'

Step Description

Image-to-Text

Text-to-Image

Positive Task

Negative Task

LM

Step 1

Edit the image

based on  given text ..

Step 2

Detect objects

in the image

Step 3

Perform token

classification on the …

LM

GNN

Invocation Path

Image Editing

Object Detection

Token

Classification

/

LM

BPR Loss

2

3

Task Graph

𝒙

"#$%

!

"#$%

&

"#$%

'

𝒙

"#$%

(

𝒙

F Supplementary Materials for Training-based Methods

F.1 Implementation of Training-based GNNs

LM and GNN Configuration: For training-based GNNs, we uniformly use the e5-335M model [62] as the LM backbone. For the graph encoder, our setup includes a single layer with a hidden dimension of 1024 . During the model training, we set the batch size to 512 and run for 20 epochs with a learning rate of 1 e -3 . We use the Adam optimizer [25] and implement an early stopping mechanism with a patience of 5 epochs to prevent over-fitting. All experiments are conducted on a single NVIDIA A100-80G GPU.

Training Data Preparation: From each dataset in TaskBench, we randomly select 3 , 000 samples to create the trainset. The original data includes specific task steps and corresponding task invocation paths. Therefore, we first employ a topological sort to align each task step accurately with corresponding task, forming '<step, ground-truth task>' pairs. Then, for each pair, we randomly sample two negative tasks to constitute the ' <step, positive task, negative task> ' triplets for model training. These negative samples are selected based on how textually similar they are to the positive one, creating a robust differentiation challenge for the model.

Choices of Different Configurations: Our training-based model offers two configuration options: training only the GNN while keeping the LM frozen, or co-training both the LM and GNN. Illustrations of these configurations are provided in Figure 8. The first configuration is designed to explore the GNN's capability in task retrieval. The latter leverages the LM's dataset-specific semantic embeddings to enhance performance. For the co-training setup, we use a learning rate of 2 e -5 and a training duration of 10 epochs.

F.2 Implementation of TAPE and GraphToken

We adapt TAPE [16] and GraphToken [38] as training-required baselines for task planning. Here, we detail the adaptation processes for each method.

TAPE: To adapt TAPE for task planning, we reformulate the planning task as a node classification problem, aiming to classify a user request into the appropriate task labels within the task graph. Firstly, LLMs interpret user requests by generating high-quality explanatory text, i.e., chain-ofthought reasoning, to understand each request. Then, a fine-tuned LM encodes these chain-of-thought texts into latent embeddings. The fine-tuning process is based on pairs of textual descriptions and their corresponding ground-truth tasks. Finally, GNNs select the suitable tasks by leveraging both the generated text embeddings and the task embeddings. For a fair performance comparison, we fine-tune the LM as e5-335M and configure the GNN as a 2 -layer GraphSAGE with a hidden dimension of

GNN

Extract text from the

image file 'image.jpg'

Step Description

LM

Image-to-Text

Text-to-Image

Positive Task

Negative Task

BPR

Loss

LM

Model Structure (Main Experiments)

GNN

Extract text from the

image file 'image.jpg'

Step Description

LM

Image-to-Text

Text-to-Image

Positive Task

Negative Task

LM

BPR

Loss

LM+GNN Co-trained Structure (Supplementary)

trainable

frozen

Task Graph

Task Graph

𝒉

!

𝒉

!"

𝒙

#$%&

𝒙

#$%&

𝒉

!

𝒉

!"

forward

backward propagation

1024 . The training data for both the LM and GNNs are consistent, utilizing the same split of the training dataset.

GraphToken: For adapting GraphToken, we first encode the task graph G ( V, E, X ) by computing each node's representation x v by feeding its descriptive text into the pre-trained LM, e5-335M. Then, a GNN transforms the initial node embedding matrix into H . The GNN is configured as a 2 -layer GraphSAGE with a hidden dimension of 1024 . A mean pooling operation is further applied to the node embeddings to obtain the graph's overall representation as h G = Mean-Pooling ( H ) . Finally, both h G and the text embeddings of input instruction and user request are concatenated and fed into the LLM to generate the output planning result. During this process, the backbone LLMs are frozen, and only the GNN's parameters are tuned. For each dataset, we train over 4 epochs using the same 3 , 000 training samples consisting of <user request, ground-truth planning> pairs. The batch size is set to 16 , with a maximum input length of 512 and a maximum output length of 300 for HuggingFace and Multimedia datasets, and 600 for DailyLife dataset. The learning rate is configured to 1 e -5 .

F.3 Implementation of Fine-tuning LLMs

To explore the effectiveness of our proposed framework on fine-tuned LLMs, we employ Supervised Fine-Tuning (SFT) on the CodeLlama-7B and Vicuna-13B models. We use the same set of 3 , 000 samples from GNN training as the LLMs' fine-tuning data. In fine-tuning the LLM with LoRA [19], we set the lora_r parameter (dimension for LoRA update matrices) to 8 and the lora_alpha (scaling factor) to 16 . The dropout ratio is set to 0 . 1 , the batch size to 2 , and we conduct training over 2 epochs with a learning rate of 1 e -5 . For HuggingFace dataset, the maximum input length is set to 800, while the maximum output length is 400. For Multimedia and Daily Life datasets, which contain a larger number of tasks and require longer textual inputs, we set the maximum input and output length to 1000 and 500, respectively. We utilize 2 NVIDIA A100-80G GPUs for fine-tuning the LLMs.

F.4 Full Results of Training-based GNNs

In Table 11, we present comprehensive results for all training-based GNNs, including GCN [26], GAT [57], GraphSAGE [15], GIN [67], and Graph Transformer [47]. To highlight the improvements brought by GNNs, we also include results from the strongest baseline, BeamSearch.

From the results, it is obvious that all GNN encoders significantly enhance the task planning abilities . For instance, when applied to Vicuna-13B on HuggingFace dataset, the introduction of GCN results in a performance improvement of 17 . 83% , GAT contributes to a 17 . 48% increase, GraphSAGE leads to a 22 . 59% boost, and GraphTransformer improves predictions by 18 . 0% . This conclusion can be generalized across various LLMs and datasets, demonstrating the robust capabilities of GNNs.

F.5 Performance of LM+GNN Co-trained Mode

During our main experiments, the LM backbone remains frozen while only the GNN is trained to automatically learn the alignment between implicit step descriptions and suitable tasks, facilitating task retrieval. In this subsection, we conduct a supplementary study where the parameters of a pre-trained LM are also tuned along with GNN during model training. The model configuration is illustrated in Figure 8, and the results are presented in Table 12.

The results demonstrate that, compared to the GNN-only tunable mode, co-training LM+GNN can lead to further performance improvements. This enhancement occurs because the language model acquires task-specific semantics, which makes the representations more discriminative and boosts the GNN's effectiveness in task retrieval. Additionally, it is noted that under the co-training setup, the differences between various GNN encoders are relatively minor, with performance variations across GNNs for a specific LLM on any dataset remaining within 2% .

F.6 Computational Cost Analysis

In this subsection, we provide the computational costs of training-based methods: training time for GNN or LM+GNN co-trained, and resources needed for fine-tuning LLMs. Results are shown in Table 13.

Efficiency of Training GNNs: During experiments, each dataset shares the same GNN configuration: 1 single layer with a hidden dimension of 1024 . Therefore, for each GNN, its number of parameters remains consistent across datasets. The parameter scales for GNN variants range from 1M to 4M, and the total training time for each dataset requires only 2-4 minutes , comparable to the time taken by GraphSearch to fulfill a single request. For LM+GNN co-trained mode, where e5-335M [62] serves as the LM backbone, training times increase to approximately 6-12 minutes . In summary, both modes demonstrate high efficiency, with total training times spanning minutes, showcasing their ability to rapidly adapt to new task planning scenarios.

Efficiency of Fine-tuning LLMs: Fine-tuning a LLM with 3 , 000 training samples over 2 epochs requires huge time, typically 10-20 hours on one or two A100-80G GPU devices.

G Experiments on Task Parameter Prediction

To assess the quality of task planning, we primarily focus on the predicted tasks and their dependencies, leaving the parameters for invoking these tasks undiscussed. As LLMs' direct inference for solely predicting tasks has proven unsatisfactory (Figure 2), relying on LLMs alone to directly predict these parameters is unreliable. In this section, we will first demonstrate that it is quite straightforward for LLMs to fill in the parameters given a planned task sequence, which is a simple extension of our framework. Furthermore, we will empirically show that with more accurately planned tasks, i.e., those retrieved by GNNs, LLMs can intelligently fill in the parameters.

G.1 Prompting LLMs to Fill in Parameters

Process: Recall that our framework enables more accurate invoked task sequences, e.g., { v 1 , . . . , v n } , for a specific user request. To finalize the invocation sequence, just adding an additional LLM query can complete the invocation parameters for each task. Specifically, by providing the original user request, planned tasks, and detailed descriptions including each task's input and output requirements, LLMscan be intelligently prompted to fill in the invocation parameters for each planned task, resulting in a well-structured invocation sequence ready for execution. Prompts are provided in Table 6.

Example: Taking the request shown in Figure 1 as an example, which is: 'Please generate an image where a girl is reading a book, and her pose is the same as the boy in 'example.jpg'. Then, please describe the new image with your voice.' Suppose GNN's planned tasks include { Pose Detection , Pose-to-Image , Image-to-Text , Text-to-Speech } . LLMs can intelligently fill in the invocation arguments as follows: [ {'task': Pose Detection , 'arguments': ['example.jpg'] }, {'task': Pose-to-Image , 'arguments': [output pose from Pose Detection ] }, {'task': Image-to-Text , 'arguments': [output image from Pose-to-Image ] }, {'task': Text-to-Speech , 'arguments': [output text from Image-to-Text ]}].

G.2 Empirical Results of LLMs Predicted Parameters

Experimental Setup: We conduct this supplementary experiment on the HuggingFace dataset from TaskBench [45]. Specifically, we compare the directly predicted invocation parameters from LLMs (denoted as Direct ) with the parameters filled automatically by LLMs using our GNN-retrieved tasks (querying prompt as shown in Table 6). For GNNs, we consider both training-free SGC and training-required GraphSAGE. Notably, with SGC, since the query for completing parameters is also training-free, the entire pipeline can be deployed without any extensive model training or labeled data. We adopt evaluation metrics from TaskBench, including Parameter-Type F1-Score ( Param t-F1 ) and Parameter-Value F1-Score ( Param v-F1 ). These metrics measure the accuracy of the predicted parameter types and concrete values, respectively. For example, when filling in the invocation for Pose Detection , the ground-truth parameter type is Image , and the ground-truth value is 'example.jpg' .

Observation: From the results shown in Table 14, we can conclude that: (1) LLMs' direct inference of invocation arguments is unsatisfactory. Even for the strongest LLM, GPT-4-turbo, the ParameterValue F1 score is only 55% , which is far from expectations. (2) With accurate planning provided by GNNs, LLMs can leverage their inherent reasoning abilities to analyze the context and correctly fill in the parameters. Across four LLMs, improvements of 3% to 23% can be observed, highlighting the advantages of GNN-enhanced planning. (3) Our method is well-suited for training-free scenarios, as the tasks retrieved by the training-free SGC already enable LLMs to infer the parameters effectively, with only a minor performance gap compared to the training-required GraphSAGE.

H Case Studies

Effectiveness of GNNs: We show two cases in Figure 9 where the results of LLM's direct inference, BeamSearch, and GraphSAGE are compared. Due to space constraints and issues such as LLM's output content decoding errors or invalid paths, we present only the first four valid paths searched by BeamSearch on the task graph. From the cases, we can conclude that BeamSearch relies on LLM's inherent reasoning abilities. Although LLM can explore the ground-truth invocation path on the task graph, their final solutions are usually not the optimal as either containing the hallucination or wrongly invoked tasks due to limited instruction following and reasoning abilities. On the contrary, GNN can effectively align decomposed steps with suitable tasks, accurately achieving the ground-truth result and enhancing task planning.

Failure Cases of GNNs: We also present the failure cases where GNN performance deteriorates compared to direct inference to provide a comprehensive discussion of our method. Our conclusion is that the method is sensitive to the quality of decomposed task steps, as an ambiguous step may mislead GNN to wrongly select the task, and such errors can cascade due to the sequential selection of tasks on the task graph. As the case shown in Figure 10, step 2 is ambiguously described as 'Segment the image and identify the tabular data', which actually incorporates two distinct steps. This ambiguity causes GNN to choose the unsuitable Tabular Classification instead of the correct Image Segmentation . Since tasks are selected sequentially on the task graph, where the next task is a neighbor of the current selection, such an error can prevent the exploration of the next appropriate task, as it may not be a neighbor of the current, incorrect selection. We also present the BeamSearch explored paths and its final solution, where it hits the ground-truth result.

Diagnosing GraphSearch with GPT-4-turbo: In our experiments, GraphSearch brings marginal or even decreased performance for GPT-4-turbo across most experimental datasets, contradicting current research [33, 32] which suggests that exhaustive search strategies can enhance the performance of more powerful LLMs. To provide a detailed analysis, we show three types of cases in Figure 11: Successful cases, Failure cases, as well as Maintaining cases:

Successful Cases: As shown in the figure, despite inaccuracies in task decomposition (GPT-4 predicts an extra step compared to the three-step ground truth), its inherent reasoning abilities and the knowledge explored along the task graph can fix these mistakes, hitting the ground-truth.

Failure Cases: In the failure case, although GPT-4 identifies the ground-truth solution during searching process, the final decision includes an incorrect task. This occurs because the final solution selection demands complex reasoning abilities of LLM , as the context contains long textual information from different aspects: the full task graph, user request, all searched paths, and related instructions . The demanding context and reasoning challenge exceed GPT-4's capabilities, leading to errors.

Maintaining Cases: These occur when GraphSearch merely replicates the result of LLM's direct inference, indicating no added benefit from exploring the task graph. In these instances, despite navigating the graph, the LLM fails to self-correct inaccuracies due to inherent reasoning limitations.

We emphasize that the results of GraphSearch with GPT-4-turbo, tend to 'maintaining' cases. Under such conditions, even a few failures can degrade overall performance, explaining why GraphSearch does not consistently enhance performance for GPT-4-turbo.

User

Request

Convert the text 'I love nature' into speech audio, classify the audio.

Finally, generate an image according to the audio classification result.

Mistral-7B

Text-to-Speech

Automatic

Speech

Recognition

Image

Generation

x

x

Text-to-Speech

Automatic

Speech

Recognition

Audio

Classification

Text-to-Image

Image

Editing

Text-to-Image

Image

Editing

Text-to-Speech

Audio

Classification

Text-to-Image

Step 1

text 'I love nature'

into speech audio

Step 2

Classify the

generated speech

audio

Step 3

Generate

an image based on

classification result

G

N

N

Searched Paths

Final Solution

Vicuna-13B

Text-to-Speech

Audio

Classification

Audio-to-

Audio

x

Text-to-Speech

Automatic

Speech

Recognition

Audio

Classification

Text-to-Image Translation

Text-to-Image

Translation

Text-to-Speech

Audio

Classification

Text-to-Image

Step 1

Generate

speech audio from

the input text

Step 2

Classify the

generated audio

Step 3

Generate

an image based on

the classification

result

G

N

N

LLM

Direct

BeamSearch

width=2

GraphSAGE (Ours)

Text-to-Speech

Automatic

Speech

Recognition

Image

Generation

x

x

Text-to-Speech

Audio

Classification

Text-to-Image

(a) Direct

(b) BeamSearch

width=2

(c) GraphSAGE (Ours)

CodeLlama-13B

Translation

Token

Classification

Summarization

Text

Generation

Image

Editing

Text

Generation

Image

Editing

Translation

Token

Classification

Text

Generation

Translation

Token

Classification

Text-to-Image

Step 1

Translate

the given text from

English to Spanish

Step 2

Identify key

entities in translated

text

Step 3

Generate an

example image

based on the

identified entities

G

N

N

Translation

Named Entity

Recognition

Text

Generation

x

x

x

Mistral-7B

Translation

Token

Classification

Text

Generation

Text-to-Image

Text

Generation

Text-to-Image

Image

Editing

Translation

Named Entity

Recognition

Text-to-Image

x

Translation

Token

Classification

Text-to-Image

Step 1

Translate

the given English

text to Spanish

Step 2

Identify

key entities in the

translated text

Step 3

Generate

an example image

based on the

identified entities

G

N

N

Searched Paths

Final Solution

LLM

Direct

BeamSearch

width=2

GraphSAGE (Ours)

Translation

Named Entity

Recognition

Text-to-Image

x

User Request I have this image 'example.jpg', and the description is: change the color of the table in the image to blue. After that, segment the image to identify the tabular data. Finally, classify the tabular data.

Direct Inference

Image Editing

Image

Segmentation

Tabular

Classification

GraphSAGE (Ours)

G

N

N

Step 1

Change the

color of the table in the

given input image

Step 2

Segment the

image and identify the

tabular data

Step 3

Classify the

tabular data

Image Editing

Tabular

Classification

Token

Classification

x

x

GraphSearch

Image Editing

Image

Segmentation

Tabular

Classification

Image

Editing

Audio

Classification

Image

Segmentation

Tabular

Classification

Translation

Tabular

Classification

Image

Editing

Final Solution

Tabular

Classification

Translation

Sentence

Similarity

I have a table in an image file

'example.jpg' which is in French.

I need to classify the table,

translate the output text to English

and then compare its similarity to

this reference text: 'This is an

important reference text.'

Tabular

Classification

Translation

Image-to-Text

Sentence

Similarity

Translation

Sentence

Similarity

Token

Classification

Image-to-Text

Translation

Sentence

Similarity

x

User Request

Searched Paths

Final Solution

Direct

BeamSearch

width=2

Failure Case

Most Case (Maintain)

Image

Segmentation

Object

Detection

Image-to-

Image

Image

Segmentation

Object

Detection

Image

Editing

Text-to-

Image

Object

Detection

Text-to-

Image

Image

Editing

Image

Segmentation

Object

Detection

Image-

to-Image

Image

Segmentation

Object

Detection

Image-to-

Image

I would like to input an example

image of a street view scene

(example.jpg) that contains multiple

objects. Please divide the image into

segments, identify the objects, and

generate images showcasing these

detected objects separately.

Success Case

I have an image file named

example.jpg, and I want to

know what the image is about.

Then, I want to ask a question

'What color is the main object

in the image?', and finally, I

want to check the similarity

between the answer to the

question and this sentence:

'The main object in the image

is blue.'

Image

Classification

Image-to-Text

Visual Question

Answering

Sentence

Similarity

Image

Classification

Text

Generation

Visual Question

Answering

Sentence

Similarity

Visual Question

Answering

Question

Answering

Document

Question

Answering

Sentence

Similarity

Sentence

Similarity

Image

Classification

Visual Question

Answering

Sentence

Similarity

I Broader Impacts

In this paper, we did not use any non-public data, unauthorized software, or API in our paper, there are no privacy or other related ethical concerns. Similar to other models designed for autonomous agents, our model also has the unfortunate potential to be used for malicious attacks. We pledge to restrict the usage of our model exclusively to the realm of research to prevent such misuse.

NeurIPS Paper Checklist

1. Claims

Question: Do the main claims made in the abstract and introduction accurately reflect the paper's contributions and scope?

Answer: [Yes]

Justification: The claims made in abstract and introduction truthfully reflect our contribution.

Guidelines:

The answer NA means that the abstract and introduction do not include the claims made in the paper.

The abstract and/or introduction should clearly state the claims made, including the contributions made in the paper and important assumptions and limitations. A No or NA answer to this question will not be perceived well by the reviewers.

The claims made should match theoretical and experimental results, and reflect how much the results can be expected to generalize to other settings.

It is fine to include aspirational goals as motivation as long as it is clear that these goals are not attained by the paper.

2. Limitations

Question: Does the paper discuss the limitations of the work performed by the authors?

Answer: [Yes]

Justification: We have discussed the limitations in Section 6.

Guidelines:

The answer NA means that the paper has no limitation while the answer No means that the paper has limitations, but those are not discussed in the paper.

The authors are encouraged to create a separate "Limitations" section in their paper.

The paper should point out any strong assumptions and how robust the results are to violations of these assumptions (e.g., independence assumptions, noiseless settings, model well-specification, asymptotic approximations only holding locally). The authors should reflect on how these assumptions might be violated in practice and what the implications would be.

The authors should reflect on the scope of the claims made, e.g., if the approach was only tested on a few datasets or with a few runs. In general, empirical results often depend on implicit assumptions, which should be articulated.

The authors should reflect on the factors that influence the performance of the approach. For example, a facial recognition algorithm may perform poorly when image resolution is low or images are taken in low lighting. Or a speech-to-text system might not be used reliably to provide closed captions for online lectures because it fails to handle technical jargon.

The authors should discuss the computational efficiency of the proposed algorithms and how they scale with dataset size.

If applicable, the authors should discuss possible limitations of their approach to address problems of privacy and fairness.

While the authors might fear that complete honesty about limitations might be used by reviewers as grounds for rejection, a worse outcome might be that reviewers discover limitations that aren't acknowledged in the paper. The authors should use their best judgment and recognize that individual actions in favor of transparency play an important role in developing norms that preserve the integrity of the community. Reviewers will be specifically instructed to not penalize honesty concerning limitations.

3. Theory Assumptions and Proofs

Question: For each theoretical result, does the paper provide the full set of assumptions and a complete (and correct) proof?

Answer: [Yes]

Justification: Please see Appendix D.2 & D.5 where we provide detailed theoretical analysis. Guidelines:

The answer NA means that the paper does not include theoretical results.

All the theorems, formulas, and proofs in the paper should be numbered and crossreferenced.

All assumptions should be clearly stated or referenced in the statement of any theorems.

The proofs can either appear in the main paper or the supplemental material, but if they appear in the supplemental material, the authors are encouraged to provide a short proof sketch to provide intuition.

Inversely, any informal proof provided in the core of the paper should be complemented by formal proofs provided in appendix or supplemental material.

Theorems and Lemmas that the proof relies upon should be properly referenced.

4. Experimental Result Reproducibility

Question: Does the paper fully disclose all the information needed to reproduce the main experimental results of the paper to the extent that it affects the main claims and/or conclusions of the paper (regardless of whether the code and data are provided or not)?

Answer: [Yes]

Justification: We detailed all the experimental setups and implementation details in Section 5.1 and Appendix E.1 & F.1.

Guidelines:

The answer NA means that the paper does not include experiments.

If the paper includes experiments, a No answer to this question will not be perceived well by the reviewers: Making the paper reproducible is important, regardless of whether the code and data are provided or not.

If the contribution is a dataset and/or model, the authors should describe the steps taken to make their results reproducible or verifiable.

Depending on the contribution, reproducibility can be accomplished in various ways. For example, if the contribution is a novel architecture, describing the architecture fully might suffice, or if the contribution is a specific model and empirical evaluation, it may be necessary to either make it possible for others to replicate the model with the same dataset, or provide access to the model. In general. releasing code and data is often one good way to accomplish this, but reproducibility can also be provided via detailed instructions for how to replicate the results, access to a hosted model (e.g., in the case of a large language model), releasing of a model checkpoint, or other means that are appropriate to the research performed.

While NeurIPS does not require releasing code, the conference does require all submissions to provide some reasonable avenue for reproducibility, which may depend on the nature of the contribution. For example

(a) If the contribution is primarily a new algorithm, the paper should make it clear how to reproduce that algorithm.

(b) If the contribution is primarily a new model architecture, the paper should describe the architecture clearly and fully.

(c) If the contribution is a new model (e.g., a large language model), then there should either be a way to access this model for reproducing the results or a way to reproduce the model (e.g., with an open-source dataset or instructions for how to construct the dataset).

(d) We recognize that reproducibility may be tricky in some cases, in which case authors are welcome to describe the particular way they provide for reproducibility. In the case of closed-source models, it may be that access to the model is limited in some way (e.g., to registered users), but it should be possible for other researchers to have some path to reproducing or verifying the results.

5. Open access to data and code

Question: Does the paper provide open access to the data and code, with sufficient instructions to faithfully reproduce the main experimental results, as described in supplemental material?

Answer: [Yes]

Justification: Please refer to uploaded Supplementary Materials.

Guidelines:

The answer NA means that paper does not include experiments requiring code.

Please see the NeurIPS code and data submission guidelines ( https://nips.cc/ public/guides/CodeSubmissionPolicy ) for more details.

While we encourage the release of code and data, we understand that this might not be possible, so 'No' is an acceptable answer. Papers cannot be rejected simply for not including code, unless this is central to the contribution (e.g., for a new open-source benchmark).

The instructions should contain the exact command and environment needed to run to reproduce the results. See the NeurIPS code and data submission guidelines ( https: //nips.cc/public/guides/CodeSubmissionPolicy ) for more details.

The authors should provide instructions on data access and preparation, including how to access the raw data, preprocessed data, intermediate data, and generated data, etc.

The authors should provide scripts to reproduce all experimental results for the new proposed method and baselines. If only a subset of experiments are reproducible, they should state which ones are omitted from the script and why.

At submission time, to preserve anonymity, the authors should release anonymized versions (if applicable).

Providing as much information as possible in supplemental material (appended to the paper) is recommended, but including URLs to data and code is permitted.

6. Experimental Setting/Details

Question: Does the paper specify all the training and test details (e.g., data splits, hyperparameters, how they were chosen, type of optimizer, etc.) necessary to understand the results?

Answer: [Yes]

Justification: We have specified all the data splits, hyperparameter settings, and model configurations in both Experimental Setups in Section 5.1 and Appendix E.1.

Guidelines:

The answer NA means that the paper does not include experiments.

The experimental setting should be presented in the core of the paper to a level of detail that is necessary to appreciate the results and make sense of them.

The full details can be provided either with the code, in appendix, or as supplemental material.

7. Experiment Statistical Significance

Question: Does the paper report error bars suitably and correctly defined or other appropriate information about the statistical significance of the experiments?

Answer: [No]

Justification: We follow existing studies to set up experiments, which does not provide the error bar. We can add the error bar if needed.

Guidelines:

The answer NA means that the paper does not include experiments.

The authors should answer "Yes" if the results are accompanied by error bars, confidence intervals, or statistical significance tests, at least for the experiments that support the main claims of the paper.

The factors of variability that the error bars are capturing should be clearly stated (for example, train/test split, initialization, random drawing of some parameter, or overall run with given experimental conditions).

The method for calculating the error bars should be explained (closed form formula, call to a library function, bootstrap, etc.)

The assumptions made should be given (e.g., Normally distributed errors).

It should be clear whether the error bar is the standard deviation or the standard error of the mean.

It is OK to report 1-sigma error bars, but one should state it. The authors should preferably report a 2-sigma error bar than state that they have a 96% CI, if the hypothesis of Normality of errors is not verified.

For asymmetric distributions, the authors should be careful not to show in tables or figures symmetric error bars that would yield results that are out of range (e.g. negative error rates).

If error bars are reported in tables or plots, The authors should explain in the text how they were calculated and reference the corresponding figures or tables in the text.

8. Experiments Compute Resources

Question: For each experiment, does the paper provide sufficient information on the computer resources (type of compute workers, memory, time of execution) needed to reproduce the experiments?

Answer: [Yes]

Justification: Please see Table 13 in the Appendix where we list the experimental devices and costed time.

Guidelines:

The answer NA means that the paper does not include experiments.

The paper should indicate the type of compute workers CPU or GPU, internal cluster, or cloud provider, including relevant memory and storage.

The paper should provide the amount of compute required for each of the individual experimental runs as well as estimate the total compute.

The paper should disclose whether the full research project required more compute than the experiments reported in the paper (e.g., preliminary or failed experiments that didn't make it into the paper).

9. Code Of Ethics

Question: Does the research conducted in the paper conform, in every respect, with the NeurIPS Code of Ethics https://neurips.cc/public/EthicsGuidelines ?

Answer: [Yes]

Justification: We carefully follow the guidelines.

Guidelines:

The answer NA means that the authors have not reviewed the NeurIPS Code of Ethics.

If the authors answer No, they should explain the special circumstances that require a deviation from the Code of Ethics.

The authors should make sure to preserve anonymity (e.g., if there is a special consideration due to laws or regulations in their jurisdiction).

10. Broader Impacts

Question: Does the paper discuss both potential positive societal impacts and negative societal impacts of the work performed?

Answer: [Yes]

Justification: We specify them in Appendix I.

Guidelines:

The answer NA means that there is no societal impact of the work performed.

If the authors answer NA or No, they should explain why their work has no societal impact or why the paper does not address societal impact.

Examples of negative societal impacts include potential malicious or unintended uses (e.g., disinformation, generating fake profiles, surveillance), fairness considerations (e.g., deployment of technologies that could make decisions that unfairly impact specific groups), privacy considerations, and security considerations.

The conference expects that many papers will be foundational research and not tied to particular applications, let alone deployments. However, if there is a direct path to any negative applications, the authors should point it out. For example, it is legitimate to point out that an improvement in the quality of generative models could be used to generate deepfakes for disinformation. On the other hand, it is not needed to point out that a generic algorithm for optimizing neural networks could enable people to train models that generate Deepfakes faster.

The authors should consider possible harms that could arise when the technology is being used as intended and functioning correctly, harms that could arise when the technology is being used as intended but gives incorrect results, and harms following from (intentional or unintentional) misuse of the technology.

If there are negative societal impacts, the authors could also discuss possible mitigation strategies (e.g., gated release of models, providing defenses in addition to attacks, mechanisms for monitoring misuse, mechanisms to monitor how a system learns from feedback over time, improving the efficiency and accessibility of ML).

11. Safeguards

Question: Does the paper describe safeguards that have been put in place for responsible release of data or models that have a high risk for misuse (e.g., pretrained language models, image generators, or scraped datasets)?

Answer: [NA]

Justification:

Guidelines:

The answer NA means that the paper poses no such risks.

Released models that have a high risk for misuse or dual-use should be released with necessary safeguards to allow for controlled use of the model, for example by requiring that users adhere to usage guidelines or restrictions to access the model or implementing safety filters.

Datasets that have been scraped from the Internet could pose safety risks. The authors should describe how they avoided releasing unsafe images.

We recognize that providing effective safeguards is challenging, and many papers do not require this, but we encourage authors to take this into account and make a best faith effort.

12. Licenses for existing assets

Question: Are the creators or original owners of assets (e.g., code, data, models), used in the paper, properly credited and are the license and terms of use explicitly mentioned and properly respected?

Answer: [Yes]

Justification:

Guidelines:

The answer NA means that the paper does not use existing assets.

The authors should cite the original paper that produced the code package or dataset.

The authors should state which version of the asset is used and, if possible, include a URL.

The name of the license (e.g., CC-BY 4.0) should be included for each asset.

For scraped data from a particular source (e.g., website), the copyright and terms of service of that source should be provided.

If assets are released, the license, copyright information, and terms of use in the package should be provided. For popular datasets, paperswithcode.com/datasets has curated licenses for some datasets. Their licensing guide can help determine the license of a dataset.

For existing datasets that are re-packaged, both the original license and the license of the derived asset (if it has changed) should be provided.

If this information is not available online, the authors are encouraged to reach out to the asset's creators.

13. New Assets

Question: Are new assets introduced in the paper well documented and is the documentation provided alongside the assets?

Answer: [NA]

Justification:

Guidelines:

The answer NA means that the paper does not release new assets.

Researchers should communicate the details of the dataset/code/model as part of their submissions via structured templates. This includes details about training, license, limitations, etc.

The paper should discuss whether and how consent was obtained from people whose asset is used.

At submission time, remember to anonymize your assets (if applicable). You can either create an anonymized URL or include an anonymized zip file.

14. Crowdsourcing and Research with Human Subjects

Question: For crowdsourcing experiments and research with human subjects, does the paper include the full text of instructions given to participants and screenshots, if applicable, as well as details about compensation (if any)?

Answer: [NA]

Justification:

Guidelines:

The answer NA means that the paper does not involve crowdsourcing nor research with human subjects.

Including this information in the supplemental material is fine, but if the main contribution of the paper involves human subjects, then as much detail as possible should be included in the main paper.

According to the NeurIPS Code of Ethics, workers involved in data collection, curation, or other labor should be paid at least the minimum wage in the country of the data collector.

15. Institutional Review Board (IRB) Approvals or Equivalent for Research with Human Subjects

Question: Does the paper describe potential risks incurred by study participants, whether such risks were disclosed to the subjects, and whether Institutional Review Board (IRB) approvals (or an equivalent approval/review based on the requirements of your country or institution) were obtained?

Answer: [NA]

Justification:

Guidelines:

The answer NA means that the paper does not involve crowdsourcing nor research with human subjects.

Depending on the country in which research is conducted, IRB approval (or equivalent) may be required for any human subjects research. If you obtained IRB approval, you should clearly state this in the paper.

We recognize that the procedures for this may vary significantly between institutions and locations, and we expect authors to adhere to the NeurIPS Code of Ethics and the guidelines for their institution.

For initial submissions, do not include any information that would break anonymity (if applicable), such as the institution conducting the review.

Peer reviews:
{"IS_META_REVIEW": false, "comments": "SUMMARY:\nThis work proposes to investigate the integration of LLMs and GNNs for task planning. Specifically, LLMs are employed for the request decomposition stage while GNNs are employed for the task retrieval stage. Experiments demonstrate gains on various datasets across various LLMs.\n\nSTRENGTHS:\n+ the intersection of LLMs and graphs is interesting\n+ task planning is an important problem\n\nWEAKNESSES:\n- It would be nice to present a figure/clear description of how LLMs and GNNs are integrated for task planning, somewhere in Section 4. For now it seems that Sec 4.2&4.3 focus on details of existing GNN proposals, which is not the technical contribution of this work, so it might make more sense to better highlight the unique way of composing them.\n\n- There is some literature on combining LMs and GNNs for various purposes, most related ones include [1-3]. I'm not sure if the related work discussion is currently adequate and perhaps it would be helpful to start from [1-3]. In addition, maybe some of these could be valid baselines, especially for works like [2] and [3].\n\n- LLMs are used in stage 1: decomposition while GNNs are used in stage 2: task retrieval, right? One might say that the decomposition step is a more \"planning\" process than just retrieving task descriptions with GNNs, so it might make sense if the proposal could incorporate GNNs in stage 1. This decoupled/independent application of LLMs and GNNs each in one separate step seems less exciting, compared to the deeper combinations of LLMs and GNNs like [1-3]. Perhaps if the authors could empirically show that keeping them separate is better than these existing proposals?\n\n- It would be nice to show qualitative analysis for the improved stage 2, highlighting at least one killer example in the main paper where LLMs failed task retrieval but GNNs helped. Totally understand the space limit so merely a suggestion.\n\n- There is a mismatch between Sec 3.1 and 3.2. While 3.1 is empirically looking at LLM graph reasoning specific to the planning task, Sec 3.2 is looking at more general interpretations of LLM graph reasoning in natural language. As the title suggests, the main focus of this work is specifically task planning, so I'm not sure if 3.2 is integral/significant to the main argument and could be a standalone work.\n\n- Minor point, not sure if Figure 2 is presenting the strongest models both for open and proprietary LLMs. I see that GPT-4 is employed in Section 5.1, why not here?\n\n- Minor point, but the title could be a bit vague. \"Graph learning\" is a broad term, could mean the GNN-centric line of graph representation learning and could also be referring to the more recent LLM&graphs research direction. Maybe better highlight that this work presents a way to combine LLMs and GNNs, that they execute different stage of the task planning pipeline.\n\n[1] Yasunaga, Michihiro, et al. \"Deep bidirectional language-knowledge graph pretraining.\" Advances in Neural Information Processing Systems 35 (2022): 37309-37323.\n\n[2] He, Xiaoxin, et al. \"Harnessing explanations: Llm-to-lm interpreter for enhanced text-attributed graph representation learning.\" The Twelfth International Conference on Learning Representations. 2023.\n\n[3] Perozzi, Bryan, et al. \"Let Your Graph Do the Talking: Encoding Structured Data for LLMs.\" arXiv preprint arXiv:2402.05862 (2024).\n\nQUESTIONS:\nplease see above\n\nLIMITATIONS:\nyes", "TITLE": "Official Review", "RECOMMENDATION": 5, "REVIEWER_CONFIDENCE": 4, "SOUNDNESS_CORRECTNESS": 2, "DATE": "2024-06-23"}

{"IS_META_REVIEW": false, "comments": "SUMMARY:\nThe paper proposes to use GNNs alongside LLMs for decision making problems represented in natural language and task graph inputs. Experimental results show that using GNNs provide improvements over just using LLMs.\n\nSTRENGTHS:\nThe results highlight that the approach makes sense and work, with improvements across benchmarks.\n\nThe paper provides some theory albeit simple and straightforward: graphs encoded as input strings into transformers are limited in expressiveness.\n\nWEAKNESSES:\nThe paper has some clarity problems, as both the problem statement and the methodology of the paper is not clear without several rereads.\n\n1. The proposed definition of planning is vague and not well defined. The authors define task planning as a path finding problem on a task that fulfils user requests, where 'user requests' is not defined.\n\n2. It is not clear anywhere how GNNs are used to improve the performance the task planning problem described in the paper. More specifically, the input to the models in Sec. 4 are unclear, i.e. what is the type of request and $v_i$ in (request, {s_1, \\ldots, s_n}, {v_1, \\ldots, v_n}) in line 231. Furthermore, it is not mentioned what the graph encoding of the inputs of the problem are. What are the nodes, edge and features of the input problem for use with the GNN? It appears later on that the datasets already give you the graphs. Make this clear if this is true and describe the graph encodings in one place.\n\n3. \"The task planning considered here is more flexible and cannot be directly translated into formal languages\" is not explained. Both PDDL planning and the task planning problem the authors both have limitations as they require structured model inputs (PDDL language and graphs, respectively). Furthermore, the second half of the claim \"cannot be directly translated into formal languages\" is given no justification and explanation and appears as a handwavy argument to not consider these fields.\n\n4. GNN and graph representation learning have been employed in task planning and decision making for several years so it is wrong to claim that the paper \"presents an initial exploration into graph-learning-based approaches for task planning as pointed out in Section A.3. Related work concerning GNNs for PDDL planning is also missing, see e.g.\n- Sam Toyer, Sylvie Thiébaux, Felipe W. Trevizan, Lexing Xie: ASNets: Deep Learning for Generalised Planning. J. Artif. Intell. Res. 68: 1-68 (2020)\n- William Shen, Felipe W. Trevizan, Sylvie Thiébaux: Learning Domain-Independent Planning Heuristics with Hypergraph Networks. ICAPS 2020: 574-584\n- Simon Ståhlberg, Blai Bonet, Hector Geffner: Learning General Optimal Policies with Graph Neural Networks: Expressive Power, Transparency, and Limits. ICAPS 2022\n- Jiayuan Mao, Tomás Lozano-Pérez, Joshua B. Tenenbaum, Leslie Pack Kaelbling: What Planning Problems Can A Relational Neural Network Solve? NeurIPS 2023\n- Dillon Ze Chen, Sylvie Thiébaux, Felipe W. Trevizan: Learning Domain-Independent Heuristics for Grounded and Lifted Planning. AAAI 2024\n\nOther comments and suggestions:\n- GNN definition not referenced, (1) is restrictive due to concatenation of edge features in aggregation function, but there are many GNNs that deal with edge features in other ways. \n- (1) is an MPNN\n- Define \"\\oplus is an operator\" more rigorously. A mathematical operator on integers, floats, booleans? What is the XOR operating on, the bit representation of a number, or a cast of a number to a boolean? \n- Figure 2: typos in legend. hallucination ratio not defined nor referenced anywhere in the text\n- Theorem 1: assumptions should not be listed in the appendix, and instead should be given before the statement of the theorem\n- F1-scores do not measure accuracy\n\nQUESTIONS:\n1. What is meant by \"fulfils the users' requests\"? Is this a classification problem, or a constraint satisfaction problem?\n2. What is the explicit graph encoding (nodes, edges, features) of the problem for use with the GNNs?\n3. Why are RestBench results only shown the no training results (Table 1) and not Table 2?\n\nLIMITATIONS:\nThe authors addresses some limitations.\n- The work requires graphs to be part of the input problem.\n- Experiments repeats are not performed and error bars are not reported. Many score have marginal difference (e.g. <0.1 F1 score difference), yet this is not considered when highlighting the best performing model in the tables.", "TITLE": "Official Review", "RECOMMENDATION": 5, "REVIEWER_CONFIDENCE": 3, "SOUNDNESS_CORRECTNESS": 2, "DATE": "2024-06-25"}

{"IS_META_REVIEW": false, "comments": "SUMMARY:\nThe paper proposes a GNN+transformers method to address some theoretical and practical issues in graph planning such as hallucinations. The task consists of matching a prompt that expresses a number of sub-tasks to a larger graph of tasks (the task pool) an agent (e.g., an LLM) can solve and invoke the right procedure to solve it (in the spirit of HuggingGPT).\n\nSTRENGTHS:\nThe general problem is well formulated and the motivation behind GNNs to improve transformers on graph planning easy to follow. Section 3.1 (but not Figure 2) do a good job at describing the hallucination issue and the potential mitigations introduced by GNNs (my understanding is because they have grounded access to the true task graph).\nResults suggest that GNNs improve performance on task planning, both in training and training-free regime.\n\nWEAKNESSES:\nFigure 2 is problematic. It is never referenced in the paper and there is no reference to the dataset used and how the task is specified (I assume is the same setting as HuggingGPT, but just because it appears in the same section).\n\nI don’t follow the argument right after Eq. 3. Such representation may not be the standard representation of a graph, but it’s sufficient to fully reconstruct vertices and relationships (and is, in some cases, optimal, as pointed out by some works that you cite in the second paragraph of the introduction).\n\nWhile I understand Proposition 1 and its demonstration by contradiction in the Appendix, one can always choose a larger Transformer that could attend all the instances in the DP problem. Furthermore, you write that the information accessible by the Transformer is O(logn), with n left undefined (it is the number of tokens?), and compared to |V|, the number of nodes in the graph. It would help to use the same control variable for a comparison. \n\nI am not convinced by Theorem 1 and the following example 1. Despite a model never sees a path to d from a in the training set, that is not a proof (nor can be) that an LLM cannot interpolate (what some researcher in literature refers with the spurious term “emergent abilities”) from abc to bcd from other similar examples. As you correctly mention after Example 1, humans can concatenate abc and bcd. The ability to “correlate” can be learnt at training time by seeing different examples.\n\nIt is not totally clear to me, after reading the paper twice, how the representation of the GNN is combined with the LLM. That should be stated clearly and maybe integrated with Figure 1, which is not very illustrative. I’d like to see a formula that precisely describes the input of the problem (I guess a graph), how it is manipulated by the GNN and then fed to the LLM. I found an informal description of this step at lines 220-222, but I recommend to move that up in the paper.\n\nQUESTIONS:\nSee each point in weaknesses, especially the third, fourth and fifth paragraphs.\n\nLIMITATIONS:\nSee previous points.", "TITLE": "Official Review", "RECOMMENDATION": 6, "REVIEWER_CONFIDENCE": 3, "SOUNDNESS_CORRECTNESS": 3, "DATE": "2024-07-11"}

comments: SUMMARY:
The paper formulates task planning as a graph decision-making problem. Through theoretical analysis, the paper shows the biases of attention and auto-regressive loss impede LLMs’ ability to effectively navigate decision-making on graphs. To mitigate this, the paper proposes to integrate GNNs with LLMs. Experiments demonstrate it can enhance overall performance.

STRENGTHS:
1. The paper provides a solid theoretical analysis of LLMs understanding graph-structured inputs, which is inspiring for future works.
2. The proposed method is effective for task planning.
3. The paper is well-written and easy to follow.

WEAKNESSES:
1. Combining LLM with GNN for graph-related tasks has been studied in many previous works and is not very novel.

QUESTIONS:
N/A

LIMITATIONS:
Yes
TITLE: Official Review
SOUNDNESS_CORRECTNESS: 3
DATE: 2024-07-13