ToolGen ist ein Rahmenwerk zur direkten Integration von Werkzeugwissen in Large Language Models (LLMs), das einen nahtlosen Werkzeugaufruf und die Generierung von Sprache ermöglicht, indem es jedes Werkzeug als eindeutiges Token darstellt. Es wurde von Renxi Wang et al. entwickelt, um die Leistung der Werkzeugsuche und Aufgabenerfüllung zu verbessern. Werkzeug-Auszeichnung ...
- Tokenisierung von Werkzeugen: Umwandlung von Werkzeugen in eindeutige Token für einen einfachen Modellaufruf.
- Erzeugung von Werkzeugaufrufen: Das Modell kann Werkzeugaufrufe und Parameter erzeugen.
- Aufgabenerledigung: Automatisierung komplexer Aufgaben durch Tool-Aufrufe.
- Datensatzunterstützung: Bietet umfangreiche Datensätze zur Unterstützung der Modellschulung und -bewertung.
Abstracts
Mit der Weiterentwicklung von Large Language Models (LLMs) werden die Grenzen ihrer Unfähigkeit, Aufgaben durch direkte Interaktion mit externen Werkzeugen selbstständig zu erfüllen, besonders deutlich. Traditionelle Ansätze basieren auf der Verwendung von Werkzeugbeschreibungen als Kontexteingabe, die durch die Länge des Kontexts begrenzt ist und einen separaten Abrufmechanismus erfordert, der oft ineffizient ist. Wir schlagen ToolGen vor, eine Methode zum Abrufen von Werkzeugbeschreibungen durch die Darstellung jedes Werkzeugs als eindeutige Token ein Paradigma, das Werkzeugwissen direkt in LLM-Parameter integriert. Dadurch können LLMs Werkzeugaufrufe und Parameter als Teil der Vorhersagefähigkeiten ihres nächsten Tokens verwenden und somit Werkzeugaufrufe nahtlos in die Spracherzeugung integrieren. Unser Framework ermöglicht es LLMs, auf eine große Anzahl von Werkzeugen zuzugreifen und diese zu nutzen, ohne dass zusätzliche Abrufschritte erforderlich sind, was die Leistung und Skalierbarkeit erheblich verbessert. Experimentelle Ergebnisse auf der Basis von über 47.000 Werkzeugen zeigen, dass ToolGen nicht nur überragende Ergebnisse bei der Werkzeugsuche und der autonomen Aufgabenerledigung erzielt, sondern auch den Grundstein für eine neue Generation von KI-Agenten legt, die sich an ein breites Spektrum von Domänenwerkzeugen anpassen können. Indem ToolGen die Werkzeugsuche grundlegend in einen generativen Prozess umwandelt, ebnet es den Weg für flexiblere, effizientere und autonomere KI-Systeme. ToolGen erweitert den Nutzen von LLM, indem es durchgängiges Werkzeuglernen unterstützt und Möglichkeiten zur Integration mit anderen fortschrittlichen Technologien wie Chain Thinking und Reinforcement Learning bietet.
1 Einleitung
Große Sprachmodelle (Large Language Models, LLMs) haben beeindruckende Fähigkeiten bei der Verarbeitung externer Eingaben, der Durchführung von Operationen und der autonomen Erledigung von Aufgaben gezeigt (Gravitas, 2023; Qin et al. 2023; Yao et al. 2023; Shinn et al. 2023; Wu et al. 2024a; Liu et al. 2024). Unter den verschiedenen Ansätzen, die es LLMs ermöglichen, mit der Außenwelt zu interagieren, ist der Aufruf von Werkzeugen über APIs zu einem der gängigsten und effektivsten geworden. Da die Zahl der Werkzeuge jedoch in die Zehntausende geht, sind die bestehenden Methoden zum Auffinden und Ausführen von Werkzeugen nur schwer effizient skalierbar.
In realen Szenarien besteht ein gängiger Ansatz darin, die Werkzeugsuche mit der Werkzeugausführung zu kombinieren, wobei das Suchmodell zunächst die relevanten Werkzeuge herausfiltert, bevor es sie zur endgültigen Auswahl und Ausführung an das LLM übergibt (Qin et al., 2023; Patil et al., 2023). Dieser kombinierte Ansatz ist zwar hilfreich, wenn es um eine große Anzahl von Werkzeugen geht, doch gibt es offensichtliche Einschränkungen: Abfragemodelle stützen sich häufig auf kleine Kodierer, die es schwierig machen, die Semantik komplexer Werkzeuge und Abfragen umfassend zu erfassen, während die Trennung von Abfrage und Ausführung zu Ineffizienz und Verzerrungen bei der Aufgabenerfüllung führen kann.
Darüber hinaus sind LLMs und ihre Disambiguatoren in erster Linie auf natürlichsprachliche Daten trainiert (Brown et al., 2020; Touvron et al., 2023) und verfügen nur über begrenztes eigenes Wissen über werkzeugbezogene Funktionen. Diese Wissenslücke führt zu einer schlechten Leistung, insbesondere wenn LLMs sich bei der Entscheidungsfindung auf die abgerufenen Werkzeugbeschreibungen verlassen müssen.
In dieser Studie stellen wir ToolGen vor, ein neues Framework, das reales Werkzeugwissen direkt in LLM-Parameter integriert und die Werkzeugsuche und -ausführung in eine einheitliche Generierungsaufgabe verwandelt. Insbesondere nutzt ToolGen das bereits vorhandene Wissen des LLM für die Werkzeugsuche und den Werkzeugaufruf effektiver, indem es das LLM-Vokabular erweitert, um Werkzeuge als spezifische virtuelle Token darzustellen und das Modell zu trainieren, diese Token im Dialogkontext zu generieren.
Auf der Grundlage des vortrainierten LLM besteht der Trainingsprozess von ToolGen aus drei Phasen: Werkzeugspeicher, Retrievaltraining und Agententraining. In der Phase des Werkzeugspeichers assoziiert das Modell jedes virtuelle Werkzeug-Token mit seinem Dokument. Während des Retrieval-Trainings lernt das Modell, relevante ToolTokens auf der Grundlage von Benutzeranfragen zu generieren. In der End-to-End-Agententuning-Phase schließlich wird das Modell darauf trainiert, als autonomer Agent zu agieren, der Pläne und Tools generiert und die geeigneten Parameter zur Erfüllung der Aufgabe bestimmt. Durch das Aufrufen von Werkzeugen und das Einholen von Feedback aus der externen Umgebung kann das Modell Benutzeranfragen effizient und integrativ verarbeiten. Abbildung 1 zeigt den Vergleich zwischen ToolGen und dem traditionellen Paradigma.
Wir validieren die Überlegenheit von ToolGen in zwei Szenarien: eine Aufgabe zur Werkzeugsuche, bei der das Modell das richtige Werkzeug für eine gegebene Anfrage findet, und eine LLM-basierte Agentenaufgabe, bei der das Modell komplexe Aufgaben mit echten API-Aufrufen ausführt. Unter Verwendung eines Datensatzes von 47.000 realen Werkzeugen erbringt ToolGen die gleiche Leistung wie die führenden Methoden zur Werkzeugsuche, jedoch zu deutlich geringeren Kosten und mit größerer Effizienz. Darüber hinaus geht es über das traditionelle Paradigma des Tool-Lernens hinaus, was sein Potenzial für die Entwicklung effektiverer Tool-Nutzungssysteme hervorhebt.
Abbildung 1: Vergleich von ToolGen mit bisherigen Retrieval-basierten Ansätzen. Bisherige Ansätze verwenden Retriever, um relevante Werkzeuge durch Ähnlichkeitsabgleich zu finden, und platzieren diese Werkzeuge dann in LLM-Prompts zur Auswahl. ToolGen ermöglicht die Werkzeugsuche durch die direkte Generierung eines Werkzeug-Tokens und kann die Aufgabe erfüllen, ohne auf externe Retriever angewiesen zu sein.
ToolGen stellt ein neues Paradigma für die Interaktion mit Werkzeugen dar, indem es Abfrage und Generierung in einem einheitlichen Modell zusammenfasst. Diese Innovation legt den Grundstein für eine neue Generation von KI-Agenten, die sich an eine breite Palette von Werkzeugen anpassen können. Darüber hinaus schafft ToolGen neue Möglichkeiten für die Kombination fortschrittlicher Techniken wie verkettetes Denken und Verstärkungslernen mit einem einheitlichen generativen Ansatz für die Nutzung von Werkzeugen, wodurch die Fähigkeiten großer Sprachmodelle in realen Anwendungen erweitert werden.
Zusammenfassend lässt sich sagen, dass unsere Beiträge Folgendes umfassen:
- Es wird ein neuartiger Rahmen, ToolGen, vorgeschlagen, der die Abfrage und Ausführung von Werkzeugen in den Prozess der Erstellung großer Sprachmodelle durch virtuelle Token integriert.
- Ein dreistufiger Schulungsprozess wurde entwickelt, um ToolGen effizient und skalierbar für den Abruf von Werkzeugen und API-Aufrufen zu machen.
- Die experimentelle Validierung zeigt, dass ToolGen eine vergleichbare Leistung im Vergleich zu den besten verfügbaren Methoden zum Auffinden von Werkzeugen in großen Werkzeugbeständen aufweist, jedoch zu geringeren Kosten, effizienter und über das traditionelle Paradigma des Werkzeuglernens hinaus.
2 Verwandte Arbeiten
2.1 Werkzeugabruf
Das Auffinden von Werkzeugen ist bei der praktischen Ausführung von Aufgaben großer Sprachmodell-Agenten von entscheidender Bedeutung, da Werkzeuge in der Regel durch ihre Dokumente beschrieben werden. Traditionelle Ansätze wie die spärliche Suche (z. B. BM25 (Robertson et al., 2009)) und intensives Retrieval (z. B. DPR (Karpukhin et al., 2020), ANCE (Xiong et al., 2021)) stützen sich auf große Dokumentenindizes und externe Module, was zu Ineffizienzen und Schwierigkeiten bei der Optimierung in einem End-to-End-Agentenrahmen führt. Mehrere Studien haben sich mit alternativen Ansätzen beschäftigt. So schreiben beispielsweise Chen et al. (2024b) die Abfrage um und extrahieren ihre Intention für eine nicht überwachte Retrieval-Umgebung, obwohl die Ergebnisse nicht so gut sind wie bei überwachten Methoden.Xu et al. (2024) schlagen einen Ansatz vor, der die Retrieval-Genauigkeit verbessert, aber die Latenzzeit erhöht, indem die Abfrage auf der Grundlage von Tool-Feedback iterativ optimiert wird.
In jüngster Zeit hat sich das generative Retrieval als vielversprechendes neues Paradigma herauskristallisiert, bei dem Modelle direkt relevante Dokumentkennungen generieren, anstatt sich auf traditionelle Retrieval-Mechanismen zu verlassen (Wang et al., 2022; Sun et al., 2023; Kishore et al., 2023; Mehta et al., 2023; Chen et al., 2023b). In Anlehnung daran stellt ToolGen jedes Werkzeug als eindeutiges Token dar, so dass das Abrufen und Aufrufen von Werkzeugen als generative Aufgabe behandelt werden kann. Dieses Design vereinfacht nicht nur die Suche, sondern kann auch in Verbindung mit anderen Big Language Models und Big Language Model-basierten Agentenfunktionen verwendet werden, wie z. B. Chained Thought Reasoning (Wei et al., 2023) und ReAct (Yao et al., 2023)) ist nahtlos integriert. Durch die Integration von Abfrage und Aufgabenausführung in einen einzigen großen Sprachmodell-Agenten werden Latenzzeiten und Rechenaufwand verringert und die Effizienz und Effektivität der Aufgabenerledigung verbessert.
2.2 Große Sprachmodell-Agenten mit Tool-Aufrufen
Große Sprachmodelle haben ein großes Potenzial für die Beherrschung der für verschiedene Aufgaben erforderlichen Werkzeuge. Die meisten bisherigen Forschungsarbeiten haben sich jedoch auf eine begrenzte Anzahl von Aktionen konzentriert (Chen et al., 2023a; Zeng et al., 2023; Yin et al., 2024; Wang et al., 2024). Toolformer (Schick et al., 2023) zum Beispiel passt GPT-J so an, dass es nur fünf Werkzeuge (z. B. Taschenrechner) handhaben kann. ToolBench (Qin et al., 2023) erweitert die Studie durch die Einführung von mehr als 16.000 Werkzeugen und verdeutlicht damit die Herausforderungen der Werkzeugauswahl in komplexen Umgebungen.
Für die Toolauswahl verwenden aktuelle Ansätze in der Regel eine Pipeline für die Abfrage und Generierung, bei der das große Sprachmodell zunächst das relevante Tool abruft und es dann nutzt (Patil et al., 2023; Qin et al., 2023). Der Pipeline-Ansatz ist jedoch mit zwei Hauptproblemen konfrontiert: das Überspringen des Abrufschritts und die Schwierigkeit für das große Sprachmodell, die Tools durch einfache Eingabeaufforderungen vollständig zu verstehen und zu nutzen.
Um diese Probleme zu mildern, haben Forscher versucht, Aktionen als Token darzustellen und die Aktionsvorhersage in generative Aufgaben umzuwandeln. So erzeugt RT2 (Brohan et al., 2023) Token, die Roboteraktionen repräsentieren, und Self-RAG (Asai et al., 2023) verwendet spezielle Token, um zu entscheiden, wann ein Dokument abgerufen werden soll.ToolkenGPT (Hao et al., 2023) führt werkzeugspezifische Token ein, um den Einsatz des Werkzeugs auszulösen, ein Konzept, das unserem Ansatz am nächsten kommt. Konzept kommt unserem Ansatz am nächsten.
Unser Ansatz unterscheidet sich deutlich von ToolkenGPT. Erstens konzentrieren wir uns auf reale Werkzeuge, die flexible Parameter für komplexe Aufgaben benötigen (z. B. die YouTube-Kanalsuche), während ToolkenGPT auf einfachere Werkzeuge mit weniger Eingaben beschränkt ist (z. B. mathematische Funktionen mit zwei Zahlen). Außerdem stützt sich ToolkenGPT auf weniger Stichproben, während ToolGen das Wissen über die Werkzeuge direkt in das größere Sprachmodell integriert, indem es eine vollständige Feinabstimmung der Parameter vornimmt, so dass es selbstständig Aufgaben abrufen und ausführen kann. Schließlich umfassen unsere Experimente einen viel größeren Satz von Werkzeugen - 47.000 Werkzeuge, im Vergleich zu ToolkenGPTs 13-300.
Andere Studien wie ToolPlanner (Wu et al., 2024b) und AutoACT (Qiao et al., 2024) haben Verstärkungslernen oder Multiagentensysteme eingesetzt, um das Erlernen von Werkzeugen oder die Aufgabenerledigung zu verbessern (Qiao et al., 2024; Liu et al., 2023; Shen et al., 2024; Chen et al., 2024a). Wir vergleichen diese Ansätze aus zwei Gründen nicht mit unserem Modell: (1) Die meisten dieser Bemühungen stützen sich auf Feedback-Mechanismen wie Reflection (Shinn et al., 2023) oder Belohnungsmodelle, die dem Evaluierungsdesign von ToolBench ähneln, bei dem das große Sprachmodell als Evaluator dient und keinen Zugang zu den echten Antworten hat. Dies ist jedoch nicht der Schwerpunkt unserer Studie, und unsere End-to-End-Experimente stützen sich nicht auf solche Feedback-Mechanismen. (2) Unser Ansatz steht nicht im Widerspruch zu diesen Methoden, sondern kann vielmehr integriert werden. Die Erforschung einer solchen Integration bleibt der zukünftigen Forschung vorbehalten.
3 WerkzeugGen
In diesem Abschnitt stellen wir zunächst die symbolische Darstellung vor, die in dieser Arbeit verwendet wird. Dann beschreiben wir im Detail den spezifischen Ansatz von ToolGen, einschließlich der Werkzeugvirtualisierung, des Werkzeugspeichers, des Abruftrainings und der End-to-End-Agentenabstimmung, wie in Abbildung 2 dargestellt. Schließlich stellen wir unsere Inferenzmethodik vor.
Abbildung 2: Schematische Darstellung des ToolGen-Rahmens. In der Werkzeugvirtualisierungsphase werden Werkzeuge auf virtuelle Token abgebildet, und in den nächsten drei Trainingsphasen merkt sich ToolGen zunächst Werkzeuge, indem es Werkzeug-Token aus Werkzeugdokumenten vorhersagt. Als nächstes lernt ToolGen, Werkzeuge abzurufen, indem es Werkzeug-Token aus Abfragen vorhersagt. Schließlich werden in der letzten Phase Pipeline-Daten (d. h. Trajektorien) zur Feinabstimmung des Abrufmodells verwendet, um das ToolGen-Agent-Modell zu erstellen.
3.1 Vorbereitende Kenntnisse
Für eine gegebene Benutzeranfrage q besteht das Ziel des Tool-Lernens darin, q mit Hilfe von Werkzeugen aus einer großen Menge von Werkzeugen D={d1,d2,...,dN} zu lösen, wobei |D|=N eine große Zahl ist, die es unpraktisch macht, alle Werkzeuge in D in eine große Sprachmodellierungsumgebung aufzunehmen. Daher wird in der aktuellen Forschung typischerweise ein Retriever R verwendet, um k relevante Werkzeuge aus D abzurufen, bezeichnet als Dk,R={dr1,dr2,...,drk}=R(q,k,D), wobei |Dk,R|≪N. Der endgültige Prompter ist eine Verkettung von q und Dk,R, bezeichnet als Prompt=[q,Dk,R]. Um eine Aufgabe (Anfrage) zu erledigen, verwenden Agenten, die auf großen Sprachmodellen basieren, typischerweise eine vierstufige Iteration (Qu et al., 2024 ): Generierung eines Plans pi , Auswahl eines Werkzeugs dsi , Bestimmung der Werkzeugparameter ci und Sammlung von Informationen aus dem Werkzeugfeedback fi . Wir bezeichnen diese Schritte als pi,dsi,ci,fi für die i-te Iteration. Das Modell fährt fort, diese Schritte zu iterieren, bis die Aufgabe abgeschlossen ist, woraufhin die endgültige Antwort a generiert wird. Die gesamte Trajektorie kann als Traj=[Prompt,(p1,ds1,c1,f1),...,(pt,dst,ct,ft),a]=[q,R (q,D),(p1,ds1,c1,f1),...,(pt,dst,ct,ft),a]. Dieser iterative Ansatz ermöglicht es dem Modell, seine Operationen bei jedem Schritt auf der Grundlage der erhaltenen Rückmeldungen dynamisch anzupassen und zu verfeinern und so seine Leistung bei der Bewältigung komplexer Aufgaben zu verbessern.
3.2 Virtualisierung von Werkzeugen
In ToolGen implementieren wir die Werkzeugvirtualisierung, indem wir jedes Werkzeug durch einen Ansatz namens atomare Indizierung einem eindeutigen neuen Token zuordnen. Bei diesem Ansatz wird jedem Werkzeug ein eindeutiges Token zugewiesen, indem das Vokabular eines großen Sprachmodells erweitert wird. Die Einbettung jedes Werkzeug-Tokens wird mit der durchschnittlichen Einbettung des entsprechenden Werkzeugnamens initialisiert, wodurch ein semantisch sinnvoller Ausgangspunkt für jedes Werkzeug geschaffen wird.
Formal ist ein Token-Set definiert als T = Index(d)|∀d ∈ D, wobei Index eine Funktion ist, die Werkzeuge auf Token abbildet. Wir zeigen, dass die atomare Indizierung effizienter ist und Phantomphänomene im Vergleich zu anderen Indizierungsmethoden (z.B. semantische und numerische Mappings; siehe 4.3 und 5.4 für eine Diskussion) reduziert.
3.3 Werkzeugspeicher
Nachdem einem Werkzeug ein Token zugewiesen wurde, fehlt dem Big Language Model noch immer jegliches Wissen über das Werkzeug. Um dieses Problem zu beheben, nehmen wir eine Feinabstimmung der Werkzeugbeschreibung vor, indem wir sie als Eingabe und das zugehörige Token als Ausgabe verwenden, was wir als Werkzeugspeicher bezeichnen. Wir verwenden die folgende Verlustfunktion:
ℒtool=∑d∈D-logpθ(Index(d)|ddoc) |
wobei θ für die Parameter des großen Sprachmodells und ddoc für die Beschreibung des Tools steht. In diesem Schritt werden die Grundlagen des Werkzeugs und die entsprechenden Operationen für das große Sprachmodell beschrieben.
3.4 Suchtraining
Anschließend trainieren wir das große Sprachmodell, um den verborgenen Raum des virtuellen Werkzeug-Tokens (und seiner Dokumente) mit dem Raum der Benutzeranfragen zu verknüpfen, so dass das Modell das richtige Werkzeug auf der Grundlage der Benutzeranfrage generieren kann. Zu diesem Zweck nehmen wir eine Feinabstimmung des großen Sprachmodells vor, indem wir die Benutzeranfragen als Eingabe und das entsprechende Tool Token als Ausgabe verwenden:
ℒretrieval=∑q∈Q∑d∈Dqq-logpθ′(Index(d)|q) |
wobei θ′ die Parameter des großen Sprachmodells nach dem Werkzeugspeicher, Q die Menge der Benutzeranfragen und Dq die Menge der mit jeder Anfrage verbundenen Werkzeuge bezeichnet. Dieser Prozess erzeugt den ToolGen-Retriever, der für eine gegebene Benutzeranfrage das passende Tool-Token generieren kann.
3.5 End-to-End-Agententuning
Nach dem Retrieval-Training ist das Big Language-Modell in der Lage, Tool-Token aus der Abfrage zu generieren. In der letzten Phase verwenden wir Agent-Flan-Aufgaben, um das Trajektorien-Feinabstimmungsmodell zu vervollständigen. Wir verwenden eine Agent-Flan-ähnliche (Chen et al., 2024c) Inferenzstrategie, bei der unsere Pipeline einen iterativen Prozess verwendet, bei dem das Modell zunächst den Gedanken generiert und dann das entsprechende Aktions-Token erzeugt, das zum Abrufen des Tool-Dokuments verwendet wird, das dann vom Big-Language-Modell zur Generierung der erforderlichen Parameter verwendet wird. Der Prozess wird so lange wiederholt, bis das Modell ein "done"-Token erzeugt oder die maximale Anzahl von Runden erreicht ist. Die generierte Trajektorie wird als Traj=[q,(p1,Index(ds1),c1,f1),...,(pt,Index(dst),ct,ft),a] dargestellt. In dieser Struktur wird das Assoziationswerkzeug nicht mehr benötigt.
3.6 Begründungen
Um dies zu verhindern, entwickeln wir eine Methode zur Generierung von Bündeln mit Einschränkungen, um die Ausgabe von Token auf den Satz von Werkzeug-Token zu beschränken. Wir wenden diese eingeschränkte Bündelsuche auf die Werkzeugsuche (bei der das Modell auf einem Abfrageauswahlwerkzeug basiert) und auf End-to-End-Agentensysteme an, wodurch die Illusionen im Schritt der Aktionsgenerierung effektiv reduziert werden. Siehe 5.4 für eine detaillierte Analyse. Siehe Anhang C für Details zur Implementierung.
4 Bewertung des Werkzeugabrufs
4.1 Versuchsaufbau
Wir verwenden das vortrainierte Llama-3-8B-Modell (Dubey et al., 2024) als Basismodell mit einem Vokabular von 128.256. 46.985 Token wurden während der Tool-Virtualisierung durch die atomare Indexierungsmethode hinzugefügt, was zu einem endgültigen Vokabular von 175.241 führt. Lernrate und einer Aufwärmphase von 3%. Die maximale Lernrate betrug 4 × 10-5. Alle Modelle durchliefen Deepspeed ZeRO 3 auf 4 × A100 GPUs (Rajbhandari et al.2020) wurden trainiert. Es wurden acht Runden Werkzeuggedächtnistraining und eine Runde Abruftraining durchgeführt.
Datensatz
Unsere Experimente basieren auf ToolBench, einem realen Tool-Benchmark, der über 16.000 Tool-Sammlungen enthält, von denen jede mehrere APIs enthält, insgesamt also etwa 47.000 einzigartige APIs. Jede API wird mit einem Wörterbuch dokumentiert, das den API-Namen, die Beschreibung und die Aufrufparameter enthält. Im Anhang finden Sie ein Beispiel aus der Praxis AWir behandeln jede API als eine Operation und ordnen sie einem Token zu. Wir behandeln jede API als eine Operation und ordnen sie einem Token zu. Unsere Abruf- und End-to-End-Agententuning-Daten werden aus den Rohdaten von ToolBench umgewandelt. Siehe Anhang für weitere Informationen G. Obwohl jedes Werkzeug mehrere APIs enthalten kann, wird in diesem Dokument der Einfachheit halber jedes API gemeinsam als Werkzeug bezeichnet.
Wir folgten der Datenpartitionierungsmethodik von Qin et al. (2023) und klassifizierten die 200.000 Paare (Abfragen, zugehörige APIs) in drei Kategorien: I1 (Single-Tool-Abfragen), I2 (Multi-Tool-Abfragen innerhalb von Klassen) und I3 (Multi-Tool-Befehle innerhalb von Sammlungen), die jeweils 87.413, 84.815 und 25.251 Instanzen enthalten.
Grundlegende Methodik
Wir vergleichen ToolGen mit den folgenden Benchmarks:
- BM25: Ein klassisches TF-IDF-basiertes unüberwachtes Suchverfahren, das auf der Wortähnlichkeit zwischen Anfrage und Dokument basiert.
- Einbettungsähnlichkeit (EmbSim): Satzeinbettungen, die mit dem Satzeinbettungsmodell von OpenAI generiert wurden; speziell text-embedding-3-large, das in unseren Experimenten verwendet wurde.
- Re-Invoke (Chen et al., 2024b): eine unüberwachte Retrieval-Methode, die das Umschreiben von Anfragen und die Erweiterung von Dokumenten beinhaltet.
- IterFeedback (Xu et al., 2024): ein BERT-basierter Retriever, der gpt-3.5-turbo-0125 als Feedback-Modell für bis zu 10 Runden iterativen Feedbacks verwendet.
- ToolRetriever (Qin et al., 2023): ein BERT-basierter Retriever, der durch Kontrastlernen trainiert wird.
aufstellen
Wir führen Experimente in zwei Einstellungen durch. In der ersten Einstellung schränkt In-Domain Retrieval die Suche auf Werkzeuge ein, deren Suchraum in derselben Domäne liegt. Wenn beispielsweise Abfragen in der Domäne I1 ausgewertet werden, wird die Suche auf Werkzeuge in I1 beschränkt. Diese Einstellung stimmt mit der ToolBench-Einstellung überein. Die zweite Einstellung, Multi-Domain Retrieval, ist komplexer, denn hier wird der Suchraum auf Werkzeuge in allen drei Domänenarten erweitert. In diesem Fall wird das Modell auf zusammengeführten Daten trainiert, was den Suchraum und die Aufgabenkomplexität erhöht. Im Gegensatz zu ToolBench spiegelt die Multi-Domain-Einstellung realistische Szenarien wider, in denen Suchaufgaben sich überschneidende oder gemischte Domänen umfassen können. Diese Einstellung bewertet die Fähigkeit des Modells, über Domänen hinweg zu verallgemeinern und komplexere und vielfältigere Retrievalaufgaben zu bewältigen.
Norm
Wir bewerteten die Abrufleistung anhand des Normalised Discount Cumulative Gain (NDCG) (Järvelin & Kekäläinen, 2002), einer weit verbreiteten Metrik für Ranking-Aufgaben, einschließlich des Abrufs von Werkzeugen.NDCG berücksichtigt sowohl die Relevanz der abgerufenen Werkzeuge als auch die Position im Ranking.
Tabelle 1: Bewertung der Werkzeugsuche in zwei Einstellungen: (1) Intra-Domain Retrieval, bei dem die Modelle auf denselben Domänen trainiert und bewertet werden, und (2) Multi-Domain Retrieval, bei dem die Modelle auf allen Domänen trainiert und auf dem kompletten Satz von Werkzeugen aus allen Domänen bewertet werden.BM25, EmbSim und Re-Invoke sind untrainierte, unüberwachte Benchmarking-Methoden.IterFeedback ist ein Retrievalsystem mit mehreren Modellen und Feedback-Mechanismen.ToolRetriever wird durch Kontrastlernen trainiert, während ToolGen durch Vorhersage des nächsten Tokens trainiert wird. Einträge mit * in den Ergebnissen weisen auf andere Modelle als unsere Implementierung hin, und die Daten stammen aus der Originalarbeit und sind daher nur unter der In-Domain-Einstellung aufgeführt. Für ToolGen in der In-Domain-Einstellung erlauben wir, dass der Generierungsraum alle Token umfasst, was im Vergleich zu anderen Modellen eine größere Herausforderung darstellt. Die optimalen Ergebnisse in jeder Kategorie sind fett gedruckt.
Modellierung | I1 | I2 | I3 | ||||||
---|---|---|---|---|---|---|---|---|---|
NDCG1 | NDCG3 | NDCG5 | NDCG1 | NDCG3 | NDCG5 | NDCG1 | NDCG3 | NDCG5 | |
Region | |||||||||
BM25 | 29.46 | 31.12 | 33.27 | 24.13 | 25.29 | 27.65 | 32.00 | 25.88 | 29.78 |
EmbSim | 63.67 | 61.03 | 65.37 | 49.11 | 42.27 | 46.56 | 53.00 | 46.40 | 52.73 |
Wiederaufruf* | 69.47 | - | 61.10 | 54.56 | - | 53.79 | 59.65 | - | 59.55 |
IterFeedback* | 90.70 | 90.95 | 92.47 | 89.01 | 85.46 | 87.10 | 91.74 | 87.94 | 90.20 |
ToolRetriever | 80.50 | 79.55 | 84.39 | 71.18 | 64.81 | 70.35 | 70.00 | 60.44 | 64.70 |
ToolGen | 89.17 | 90.85 | 92.67 | 91.45 | 88.79 | 91.13 | 87.00 | 85.59 | 90.16 |
Multidomain | |||||||||
BM25 | 22.77 | 22.64 | 25.61 | 18.29 | 20.74 | 22.18 | 10.00 | 10.08 | 12.33 |
EmbSim | 54.00 | 50.82 | 55.86 | 40.84 | 36.67 | 39.55 | 18.00 | 17.77 | 20.70 |
ToolRetriever | 72.31 | 70.30 | 74.99 | 64.54 | 57.91 | 63.61 | 52.00 | 39.89 | 42.92 |
ToolGen | 87.67 | 88.84 | 91.54 | 83.46 | 86.24 | 88.84 | 79.00 | 79.80 | 84.79 |
4.2 Ergebnisse
Tabelle 1 zeigt die Ergebnisse des Werkzeugabrufs. Wie erwartet, übertreffen alle trainierten Modelle die untrainierten Basismodelle (BM25, EmbSim und Re-Invoke) bei allen Metriken deutlich, was die Vorteile des Trainings auf Werkzeugabrufdaten zeigt.
Das von uns vorgeschlagene ToolGen-Modell schneidet in beiden Einstellungen durchweg am besten ab. In der domäneninternen Umgebung liefert ToolGen äußerst konkurrenzfähige Ergebnisse, deren Leistung mit der des IterFeedback-Systems vergleichbar ist, das mehrere Modelle und Feedback-Mechanismen verwendet. Als einzelnes Modell übertrifft ToolGen ToolRetriever bei allen Metriken deutlich und übertrifft sogar IterFeedback in mehreren Szenarien (z. B. NDCG@5 für Domäne I1 und NDCG@1, @3, @5 für I2).
In der Multidomänen-Umgebung bleibt ToolGen robust, übertrifft ToolRetriever und bleibt vor den Basismodellen, trotz des größeren Suchraums und des üblichen Rückgangs der Gesamtleistung. Dies zeigt, dass ToolGen, obwohl es sich um ein einzelnes Modell handelt, immer noch mit komplexen Retrieval-Systemen wie IterFeedback konkurrieren kann und seine Fähigkeit unter Beweis stellt, komplexe Retrieval-Aufgaben in der realen Welt mit unklaren Domänengrenzen zu bewältigen.
4.3 Vergleich der Indizierungsmethoden
Während ToolGen atomare Indizes für die Werkzeugvirtualisierung verwendet, untersuchen wir auch mehrere alternative generative Abrufmethoden. In diesem Abschnitt vergleichen wir sie mit den folgenden drei Ansätzen:
- Digital: Jedes Werkzeug wird einer eindeutigen Nummer zugeordnet. Der erzeugte Token ist rein digital und enthält keine semantischen Informationen, sondern ist eine eindeutige Kennung für jedes Werkzeug.
- Hierarchisch: Bei dieser Methode werden die Werkzeuge in nicht überlappende Gruppen geclustert und diese Cluster rekursiv unterteilt, um eine hierarchische Struktur zu bilden. Ein Index vom Wurzelknoten zu den Blattknoten in dieser Struktur repräsentiert jedes Werkzeug, ähnlich wie bei der Brown-Clustermethode.
- Semantik: Bei diesem Ansatz wird jedes Werkzeug auf seinen Namen abgebildet, der das Large Language Model (LLM) durch den semantischen Inhalt des Werkzeugnamens leitet. Der Name des Werkzeugs liefert direkt eine aussagekräftige Darstellung in Bezug auf seine Funktion.
Abbildung 3: Die Verteilung der Anzahl der Unter-Token pro Werkzeug ist bei jeder Indizierungsmethode unterschiedlich. Die atomare Indizierung stellt sicher, dass jedes Werkzeug ein einzelnes Token ist, während die numerische Indizierung Werkzeuge in N Token kodiert, d.h. die Werkzeugnummer liegt im Bereich (10N-1,10N]. Im Gegensatz dazu erzeugen die semantische und die hierarchische Indizierung eine unterschiedliche Anzahl von Unter-Token, wobei die semantische Indizierung eine längere Folge von Unter-Token und mehr Ausreißer aufweist.
Spezifische Einzelheiten zur Umsetzung sind in Anhang B beschrieben.
Zunächst haben wir die Anzahl der Sub-Token analysiert, die jede Methode zur Darstellung jedes Werkzeugs benötigt (siehe Abbildung 3). Das Diagramm verdeutlicht die Überlegenheit der atomaren Indizierung, bei der jedes Werkzeug durch ein einziges Token repräsentiert wird, während die anderen Methoden mehrere Token benötigen. Diese Effizienz ermöglicht es ToolGen, die Anzahl der Token-Generierung zu reduzieren und die Argumentationszeit sowohl in Retrieval- als auch in Agentenszenarien zu verkürzen.
Als nächstes untersuchten wir die Effektivität der verschiedenen Indizierungsmethoden. Wie aus Tabelle 2 hervorgeht, zeigt die semantische Indizierung in einer Reihe von Metriken und Szenarien die beste Abrufleistung, während die atomare Indizierung in vielen Fällen knapp dahinter liegt. Wir führen dies auf die Tatsache zurück, dass die semantische Indizierung besser zu den vortrainierten Daten des großen Sprachmodells passt. Dieser Vorteil schwindet jedoch mit zunehmender Anzahl der Trainingsdaten und -typen. In Abschnitt 5.3 zeigen wir zum Beispiel, dass atomare Indizes bei End-to-End-Ergebnissen besser abschneiden. Unter Berücksichtigung dieser Faktoren wählen wir atomare Indizes für die ToolGen-Werkzeugvirtualisierung.
Tabelle 2: Retrieval-Bewertungen verschiedener Indizierungsmethoden in der Multidomain-Umgebung. Die besten Ergebnisse sind fett gedruckt und die nächstbesten Ergebnisse sind unterstrichen.
Modellierung | I1 | I2 | I3 | ||||||
---|---|---|---|---|---|---|---|---|---|
NDCG1 | NDCG3 | NDCG5 | NDCG1 | NDCG3 | NDCG5 | NDCG1 | NDCG3 | NDCG5 | |
numerisch | 83.17 | 84.99 | 88.73 | 79.20 | 79.23 | 83.88 | 71.00 | 74.81 | 82.95 |
Lamellierung | 85.67 | 87.38 | 90.26 | 82.22 | 82.70 | 86.63 | 78.50 | 79.47 | 84.15 |
Wortbedeutung | 89.17 | 91.29 | 93.29 | 83.71 | 84.51 | 88.22 | 82.00 | 78.86 | 85.43 |
atomar | 87.67 | 88.84 | 91.54 | 83.46 | 86.24 | 88.84 | 79.00 | 79.80 | 84.79 |
Tabelle 3: Ablationsstudien für die Werkzeugabfrage. Die Auswirkungen der Entfernung des Abruftrainings, des Werkzeugspeichers und der eingeschränkten Strahlensuche auf die ToolGen-Leistung werden separat bewertet.
Modellierung | I1 | I2 | I3 | ||||||
---|---|---|---|---|---|---|---|---|---|
NDCG1 | NDCG3 | NDCG5 | NDCG1 | NDCG3 | NDCG5 | NDCG1 | NDCG3 | NDCG5 | |
ToolGen | 87.67 | 88.84 | 91.54 | 83.46 | 86.24 | 88.84 | 79.00 | 79.80 | 84.79 |
-Gedächtnis | 84.00 | 86.77 | 89.35 | 82.21 | 83.20 | 86.78 | 77.00 | 77.71 | 84.37 |
-Schulung zum Wiederauffinden | 10.17 | 12.31 | 13.89 | 5.52 | 7.01 | 7.81 | 3.00 | 4.00 | 4.43 |
-Verbindlich | 87.67 | 88.79 | 91.45 | 83.46 | 86.24 | 88.83 | 79.00 | 79.93 | 84.92 |
4.4 Experimente zur Ablation
Es wurden Ablationsexperimente durchgeführt, um die Auswirkungen der verschiedenen Trainingsphasen des ToolGen zu bewerten, wie in Tabelle 3 Gezeigt. Die Ergebnisse zeigen, dass das Retrievaltraining ein Schlüsselfaktor ist, der die Leistung des Werkzeugretrievals beeinflusst, da es direkt auf die Retrievalaufgabe abgestimmt ist, bei der die Eingabe eine Abfrage und die Ausgabe ein Werkzeug-Token ist. Die Entfernung von Werkzeugspeichern führt zu einer leichten Leistungsverschlechterung, obwohl sie hilfreich ist, um die Generalisierungsleistung zu verbessern, wie wir im Anhang zeigen werden. F weiter unten erörtert. Ähnlich verhält es sich mit der eingeschränkten Bündelsuche, die zwar nur wenig zur Suchaufgabe beiträgt, aber dazu beiträgt, die Entstehung von Halluzinationen zu verhindern, und somit einen gewissen Wert bei End-to-End-Agentenaufgaben hat (siehe Abschnitt 5.4).
5 End-to-End-Bewertung
5.1 Versuchsaufbau
Wir haben mehrere Änderungen an den Trace-Daten von ToolBench vorgenommen, um sie an das ToolGen-Framework anzupassen. Da ToolGen zum Beispiel keine explizite Auswahl relevanter Werkzeuge als Eingabe erfordert, haben wir diese Information aus den Systemaufforderungen entfernt. Weitere Einzelheiten finden Sie in Anhang G. Auf dieser Grundlage haben wir das Abrufmodell unter Verwendung der neu formatierten Daten feinabgestimmt, um einen durchgängigen ToolGen-Agenten zu erstellen.
Basismodell
- GPT-3.5: Wir verwenden gpt-3.5-turbo-0613 als eines der Basismodelle. Die Implementierung entspricht der von StableToolBench (Guo et al., 2024), wobei die Werkzeugaufruf-Funktionalität von GPT-3.5 zur Bildung von Werkzeugagenten verwendet wird.
- ToolLlama-2: Qin et al. (2023) stellten ToolLlama-2 vor, indem sie das Llama-2-Modell (Touvron et al., 2023) anhand von ToolBench-Daten feinabstimmten.
- ToolLlama-3: Um einen fairen Vergleich zu gewährleisten, haben wir das Basismodell ToolLlama-3 durch Feinabstimmung desselben Basismodells Llama-3 wie ToolGen auf dem ToolBench-Datensatz erstellt. Im weiteren Verlauf des Dokuments wird ToolLlama-3 als ToolLlama bezeichnet, um es von ToolLlama-2 zu unterscheiden.
aufstellen
- Verwendung von Genuine Tools (G.T.): In Anlehnung an Qin et al. (2023) definieren wir die Genuine Tools für eine Anfrage als ChatGPT Ausgewähltes Werkzeug. Bei ToolLlama gaben wir das echte Werkzeug direkt in die Eingabeaufforderung ein, im gleichen Format wie die Trainingsdaten. Da ToolGen nicht mit den Daten des vorausgewählten Werkzeugs trainiert wurde, fügten wir das Präfix: I am using the following tool: [tool tokens] in the planning phase hinzu, wobei [tool tokens] ein virtuelles Token ist, das dem realen Werkzeug entspricht.
- Verwendung von Retrievern: In den End-to-End-Experimenten verwenden wir einen abrufbasierten Aufbau. Für das Basismodell verwenden wir die von ToolRetriever abgerufenen Werkzeuge als zugehörige Werkzeuge. ToolGen hingegen generiert Werkzeug-Token direkt und verwendet daher keinen Retriever.
Alle Modelle wurden mit einem Cosinus-Scheduler feinabgestimmt, wobei die maximale Lernrate auf 4 × 10-5 gesetzt wurde. Die Kontextlänge wurde auf 6.144 und die Gesamtstapelgröße auf 512 gekürzt. Wir verwendeten außerdem Flash-Attention (Dao et al., 2022; Dao, 2024) und Deepspeed ZeRO 3 ( Rajbhandari et al., 2020), um Speicherplatz zu sparen.
ToolGen und ToolLlama folgen unterschiedlichen Paradigmen, um die Aufgabe zu erfüllen; ToolLlama generiert Ideen, Aktionen und Parameter in einer einzigen Runde, während ToolGen diese Schritte voneinander trennt. Für ToolGen haben wir eine Obergrenze von bis zu 16 Runden festgelegt, wobei 5 Runden für Aktionen und 1 Runde für endgültige Antworten vorgesehen sind. Wir vergleichen dies mit dem Limit von ToolLlama von 6 Runden.
Darüber hinaus haben wir für alle Modelle einen Wiederholungsmechanismus eingeführt, um ein vorzeitiges Beenden zu verhindern; die Einzelheiten dazu sind in Anhang D beschrieben. Wenn ein Modell eine Antwort erzeugt, die "Aufgeben" oder "Es tut mir leid" enthält, fordern wir das Modell auf, die Antwort bei einer höheren Temperatur neu zu erzeugen.
Bewertung der Indikatoren
Für die End-to-End-Evaluierung verwenden wir den stabilen Tool-Evaluierungs-Benchmark StableToolBench (Guo et al., 2024), der lösbare Abfragen aus ToolBench auswählt und die Ausgabe von fehlgeschlagenen Tools mit GPT-4 (OpenAI, 2024) simuliert. Wir bewerten die Leistung anhand zweier Metriken: der solvable pass rate (SoPR), die den Prozentsatz der erfolgreich gelösten Anfragen angibt, und der solvable win rate (SoWR), die den Prozentsatz der Antworten angibt, die das Referenzmodell (in dieser Studie GPT-3.5) übertreffen. Darüber hinaus werden für jede Kategorie die mikro-gemittelten Werte angegeben.
Tabelle 4: Leistung der End-to-End-Auswertung von ungesehenen Befehlen in zwei Einstellungen. Für die Einstellung R. verwenden GPT-3.5 und ToolLlama ToolRetriever, während ToolGen keinen externen Retriever verwendet. Alle resultierenden SoPR- und SoWR-Bewertungen werden dreimal durchgeführt und als Mittelwerte angegeben.
Modellierung | SoPR | SoWR | ||||||
---|---|---|---|---|---|---|---|---|
I1 | I2 | I3 | Avg. | I1 | I2 | I3 | Avg | |
Einsatz von echten Werkzeugen (G.T.) | ||||||||
GPT-3.5 | 56.60 | 47.80 | 54.64 | 50.91 | - | - | - | - |
ToolLlama-2 | 53.37 | 41.98 | 46.45 | 48.43 | 47.27 | 59.43 | 27.87 | 47.58 |
ToolLlama | 55.93 | 48.27 | 52.19 | 52.78 | 50.31 | 53.77 | 31.15 | 47.88 |
ToolGen | 61.35 | 49.53 | 43.17 | 54.19 | 51.53 | 57.55 | 31.15 | 49.70 |
Verwendung des Retrievers (R.) | ||||||||
GPT-3.5 | 51.43 | 41.19 | 34.43 | 45.00 | 53.37 | 53.77 | 37.70 | 50.60 |
ToolLlama-2 | 56.13 | 49.21 | 34.70 | 49.95 | 50.92 | 53.77 | 21.31 | 46.36 |
ToolLlama | 54.60 | 49.96 | 51.37 | 51.55 | 49.08 | 61.32 | 31.15 | 49.70 |
ToolGen | 56.13 | 52.20 | 47.54 | 53.28 | 50.92 | 62.26 | 34.42 | 51.51 |
5.2 Ergebnisse
Tabelle 4 zeigt die End-to-End-Evaluierungsleistung jedes Modells in zwei Umgebungen: mit dem echten Tool (G.T.) und dem Retriever (R.). In der G.T.-Umgebung erreicht ToolGen eine durchschnittliche SoPR-Punktzahl von 54,19 und übertrifft damit GPT-3.5 und ToolLlama, und ToolGen erreicht die höchste SoWR-Punktzahl von 49,70. In der Retriever-Umgebung bleibt ToolGen weiterhin führend, mit einer durchschnittlichen SoPR von 53,28 und SoWR von 51,51. ToolLlama zeigt eine konkurrenzfähige Leistung und übertrifft das reale Tool bei einigen einzelnen Instanzen. ToolLlama zeigte eine konkurrenzfähige Leistung und übertraf ToolGen bei einigen einzelnen Instanzen. Eine End-to-End-ToolGen-Ablationsstudie wird in Anhang G vorgestellt.
Tabelle 5: End-to-End-Bewertung verschiedener Indizierungsmethoden.
Indizierungsmethoden | SoPR | SoWR | ||||||
---|---|---|---|---|---|---|---|---|
I1 | I2 | I3 | Avg. | I1 | I2 | I3 | Avg | |
numerischer Index | 34.76 | 29.87 | 46.99 | 35.45 | 25.77 | 33.02 | 29.51 | 28.79 |
hierarchischer Index | 50.20 | 45.60 | 32.79 | 45.50 | 38.04 | 43.40 | 29.51 | 38.18 |
semantische Indizierung | 58.79 | 45.28 | 44.81 | 51.87 | 49.69 | 57.55 | 26.23 | 47.88 |
atomarer Index | 58.08 | 56.13 | 44.81 | 55.00 | 47.85 | 57.55 | 29.51 | 47.58 |
5.3 Vergleich der Indizierungsmethoden
Ähnlich wie beim Vergleich der Indizierungsmethoden für die Retrieval-Aufgabe (Abschnitt 4.3) zeigt Tabelle 5 einen Vergleich der verschiedenen Indizierungsmethoden bei der End-to-End-Agentenaufgabe. In diesem Setup wird die eingeschränkte Dekodierung aufgehoben, so dass der Agent Gedanken, Aktionen und Parameter frei generieren kann. Aus den Ergebnissen geht hervor, dass die atomare Indexierungsmethode unter den vier Indexierungsmethoden am besten abschneidet. Wir führen dies auf die höheren Phantomraten der anderen Methoden zurück, wie in Abschnitt 5.4 beschrieben.
Abbildung 4: Zeigt die Phantomrate verschiedener Modelle bei der Erzeugung nicht vorhandener Werkzeuge. ToolGen erzeugt keine nicht existierenden Werkzeuge, wenn eine eingeschränkte Dekodierung verwendet wird. Ohne diese Einschränkung erzeugt ToolGen jedoch 7% Nicht-Werkzeug-Token in der Aktionsgenerierungsphase, wenn atomare Indizierung verwendet wird, und die Illusionsrate ist höher, wenn semantische Indizierung verwendet wird. Bei ToolLlama und GPT-3.5 tritt die Täuschung auch dann auf, wenn fünf echte Werkzeuge im Hint angegeben sind. Wenn kein Werkzeug im Hinweis angegeben ist, erzeugt ToolLlama nicht existierende Werkzeugnamen, die 50% übersteigen.
5.4 Halluzinationen
Wir evaluieren die Phantomsituation des Modells bei der Werkzeuggenerierung in einem End-to-End-Agentenszenario. Dazu geben wir Abfragen ein, die konsistent mit dem Training des Modells formatiert sind. Insbesondere für ToolGen geben wir die Anfrage direkt ein und fordern das Modell auf, die Antwort gemäß dem ToolGen-Agentenparadigma zu generieren (d.h. Gedanke, Werkzeug und Parameter in der Reihenfolge). Wir haben die Aktionsdekodierung ohne die in Abschnitt 3.6 beschriebenen Einschränkungen bei der Bündelsuche getestet. Für ToolLlama und GPT-3.5 haben wir Abfragen eingegeben und 5 echte Werkzeuge einbezogen. In allen Einstellungen geben wir den Anteil der nicht im Datensatz vorhandenen Werkzeuge an den in allen Aktionen zur Werkzeuggenerierung erzeugten Werkzeugen an. Abbildung 4 veranschaulicht den Anteil der nicht existierenden Werkzeuge, die von den verschiedenen Modellen erzeugt wurden. Wie aus der Abbildung ersichtlich ist, ist die Wahrscheinlichkeit, dass ToolLlama und GPT-3.5 nicht existierende Werkzeugnamen generieren, trotz der Tatsache, dass nur fünf echte Werkzeuge zur Verfügung stehen, immer noch hoch. Im Gegensatz dazu vermeidet ToolGen durch sein eingeschränktes Dekodierungsdesign Halluzinationen vollständig.
6 Schlussfolgerung
In diesem Beitrag stellen wir ToolGen vor, ein umfangreiches Sprachmodellierungssystem (LLM), das die Abfrage und Ausführung von Werkzeugen vereinheitlicht, indem es werkzeugspezifische virtuelle Token in ein Modellvokabular einbettet und so die Interaktion mit Werkzeugen in eine generative Aufgabe verwandelt. Durch einen dreistufigen Trainingsprozess befähigt ToolGen LLMs zum effizienten Auffinden und Ausführen von Tools in realen Szenarien. Dieser einheitliche Ansatz setzt neue Maßstäbe für skalierbare und effiziente KI-Agenten, die in der Lage sind, große Tool-Bibliotheken zu verwalten. In Zukunft öffnet ToolGen die Tür zur Integration fortschrittlicher Technologien wie Chain-of-Thought-Reasoning, Reinforcement Learning und ReAct, um die Autonomie und Vielseitigkeit von LLMs in realen Anwendungen weiter zu verbessern.
Referenzen
- Asai et al. (2023) ↑Akari Asai, Zeqiu Wu, Yizhong Wang, Avirup Sil, and Hannaneh Hajishirzi.Self-rag: Learning to retrieve, generate, and critique durch Selbstreflexion, 2023.URL https://arxiv.org/abs/2310.11511.
- Brohan et al. (2023)↑ Anthony Brohan, Noah Brown, Justice Carbajal, Yevgen Chebotar, Xi Chen, Krzysztof Choromanski, Tianli Ding, Danny Driess, Avinava Dubey, Chelsea Finn, Pete Florence, Chuyuan Fu, Montse Gonzalez Arenas, Keerthana Gopalakrishnan, Kehang Han, Karol Avinava Dubey, Chelsea Finn, Pete Florence, Chuyuan Fu, Montse Gonzalez Arenas, Keerthana Gopalakrishnan, Kehang Han, Karol Hausman, Alexander Herzog, Jasmine Hsu, Brian Ichter, Alex Irpan, Nikhil Joshi, Ryan Julian, Dmitry Kalashnikov, Yuheng Kuang, Isabel Leal, Lisa Lee, Tsang-Wei Edward Lee Sergey Levine, Yao Lu, Henryk Michalewski, Igor Mordatch, Karl Pertsch, Kanishka Rao, Krista Reymann, Michael Ryoo, Grecia Salazar, Pannag Sanketi, Pierre Sermanet, Jaspil Joshi, Ryan Julian, Dmitry Kalashnikov, Yuheng Kuang, Isabel Leal, Lisa Lee, Tsang-Wei Edward Lee Pierre Sermanet, Jaspiar Singh, Anikait Singh, Radu Soricut, Huong Tran, Vincent Vanhoucke, Quan Vuong, Ayzaan Wahid, Stefan Welker, Paul Wohlhart. Jialin Wu, Fei Xia, Ted Xiao, Peng Xu, Sichun Xu, Tianhe Yu, and Brianna Zitkovich.Rt-2: Vision-language-action models transfer web knowledge to Steuerung von Robotern, 2023.URL https://arxiv.org/abs/2307.15818.
- Brown et al. (2020) ↑Tom B. Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam. Girish Sastry, Amanda Askell, Sandhini Agarwal, Ariel Herbert-Voss, Gretchen Krueger, Tom Henighan, Rewon Child, Aditya Ramesh, Daniel M. Ziegler. Jeffrey Wu, Clemens Winter, Christopher Hesse, Mark Chen, Eric Sigler, Mateusz Litwin, Scott Gray, Benjamin Chess, Jack Clark, Christopher Berner, Sam McCandlish, Alec Radford, Ilya Sutskever, and Dario Amodei.Language models are few-shot learners.In Hugo Larochelle, Marc'Aurelio Ranzato, Raia Hadsell, Maria-Florina Balcan, and Hsuan-Tien Lin (eds.). Advances in Neural Information Processing Systems 33: Annual Conference on Neural Information Processing Systems 2020, NeurIPS 2020, 6. bis 12. Dezember, 2020, virtuell, 2020.URL https://proceedings.neurips.cc/paper/2020/hash/1457c0d6bfcb4967418bfb8ac142f64a-Abstract.html.
- Chen et al. (2023a) ↑Baian Chen, Chang Shu, Ehsan Shareghi, Nigel Collier, Karthik Narasimhan, and Shunyu Yao.Fireact: Toward language agent fine- tuning.arXiv-Vorabdruck arXiv:2310.05915, 2023a.
- Chen et al. (2023b)↑Jiangui Chen, Ruqing Zhang, Jiafeng Guo, Maarten de Rijke, Wei Chen, Yixing Fan, and Xueqi Cheng.Continual Learning for Generative Retrieval über dynamische Korpora.In Proceedings of the 32nd ACM International Conference on Information and Knowledge Management, CIKM '23, S. 306-315, New York, NY, USA, 2023b. Association for Computing Machinery. isbn 9798400701245. doi: 10.1145/ 3583780.3614821.URL https://dl.acm.org/doi/10.1145/3583780.3614821.
- Chen et al. (2024a)↑Junzhi Chen, Juhao Liang, and Benyou Wang.Smurfs: Leveraging multiple proficiency agents with context-efficiency for tool planning, 2024a.URL https://arxiv.org/abs/2405.05955.
- Chen et al. (2024b)↑Yanfei Chen, Jinsung Yoon, Devendra Singh Sachan, Qingze Wang, Vincent Cohen-Addad, Mohammadhossein Bateni, Chen-Yu Lee, and Tomas Pfister.Re-invoke: Umschreiben von Werkzeugaufrufen für das Abrufen von Zero-Shot-Werkzeugen.arXiv-Vorabdruck arXiv:2408.01875, 2024b.
- Chen et al. (2024c)↑Zehui Chen, Kuikun Liu, Qiuchen Wang, Wenwei Zhang, Jiangning Liu, Dahua Lin, Kai Chen, and Feng Zhao.Agent-flan: designing data and methods of effective agent tuning for large language models Methoden der effektiven Agentenabstimmung für große Sprachmodelle, 2024c.URL https://arxiv.org/abs/2403.12881.
- Dao (2024)↑Tri Dao.FlashAttention-2: Schnellere Aufmerksamkeit mit besserer Parallelität und Arbeitsteilung.In Internationale Konferenz über lernende Repräsentationen (ICLR), 2024.
- Dao et al. (2022)↑Tri Dao, Daniel Y. Fu, Stefano Ermon, Atri Rudra, and Christopher Ré.FlashAttention: fast and memory-efficient exact attention with IO-Bewusstsein.In Fortschritte in neuronalen Informationsverarbeitungssystemen (NeurIPS), 2022.
- Dubey et al. (2024)↑Abhimanyu Dubey, Abhinav Jauhri, Abhinav Pandey, Abhishek Kadian, Ahmad Al-Dahle, Aiesha Letman, Akhil Mathur, Alan Schelten, Amy Yang, Angela Fan, et al. Die Lama-3-Herde von Modellen.arXiv-Vorabdruck arXiv:2407.21783, 2024.
- Gravitas (2023)↑Gravitas.AutoGPT, 2023.URL https://github.com/Significant-Gravitas/AutoGPT.
- Guo et al. (2024)↑Zhicheng Guo, Sijie Cheng, Hao Wang, Shihao Liang, Yujia Qin, Peng Li, Zhiyuan Liu, Maosong Sun, and Yang Liu.StableToolBench: Towards Stable Large-Scale Benchmarking on Tool Learning of Large Language Models, 2024.URL https://arxiv.org/abs/2403.07714.
- Hao et al. (2023)↑Shibo Hao, Tianyang Liu, Zhen Wang, and Zhiting Hu.Toolkengpt: Augmenting frozen language models with massive tools via tool Embeddings.In Alice Oh, Tristan Naumann, Amir Globerson, Kate Saenko, Moritz Hardt, and Sergey Levine (eds.) Fortschritte in neuronalen Informationsverarbeitungssystemen 36: Jahreskonferenz über neuronale Informationsverarbeitungssysteme 2023, NeurIPS 2023, New Orleans, LA, USA, 10. bis 16. Dezember 2023 USA, 10. bis 16. Dezember 2023, 2023.URL http://papers.nips.cc/paper_files/paper/2023/hash/8fd1a81c882cd45f64958da6284f4a3f-Abstract-Conference.html.
- Järvelin & Kekäläinen (2002)↑Kalervo Järvelin und Jaana Kekäläinen.Cumulated gain-based evaluation of ir techniques.ACM-Transaktionen über Informationssysteme (TOIS), 20(4):422-446, 2002.
- Karpukhin et al. (2020)↑Vladimir Karpukhin, Barlas Oguz, Sewon Min, Patrick Lewis, Ledell Wu, Sergey Edunov, Danqi Chen, and Wen-tau Yih.Dense passage retrieval for open-domain question answering.In Bonnie Webber, Trevor Cohn, Yulan He, and Yang Liu (eds.) Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP), S. 6769-6781, Online, 2020. Verein für Computerlinguistik. doi: 10.18653/v1/2020.emnlp-main.550.URL https://aclanthology.org/2020.emnlp-main.550.
- Kishore et al. (2023)↑Varsha Kishore, Chao Wan, Justin Lovelace, Yoav Artzi, and Kilian Q. Weinberger.Incdsi: Incrementally updatable document retrieval.In Andreas Krause, Emma Brunskill, Kyunghyun Cho, Barbara Engelhardt, Sivan Sabato, and Jonathan Scarlett (eds.). Internationale Konferenz über maschinelles Lernen, ICML 2023, 23-29 Juli 2023, Honolulu, Hawaii, USA, Band 202 von Proceedings of Machine Learning ResearchS. 17122-17134, PMLR, 2023.URL https://proceedings.mlr.press/v202/kishore23a.html.
- Liu et al. (2024)↑Xiao Liu, Hao Yu, Hanchen Zhang, Yifan Xu, Xuanyu Lei, Hanyu Lai, Yu Gu, Hangliang Ding, Kaiwen Men, Kejuan Yang, et al. Agentbench. Evaluating llms as agents.In Die zwölfte internationale Konferenz über lernende Darstellungen, 2024.
- Liu et al. (2023)↑ Zhiwei Liu, Weiran Yao, Jianguo Zhang, Le Xue, Shelby Heinecke, Rithesh Murthy, Yihao Feng, Zeyuan Chen, Juan Carlos Niebles, Devansh Arpit, et al. Bolaa: Benchmarking und Orchestrierung von llm-augmentierten autonomen Agenten.arXiv-Vorabdruck arXiv:2308.05960, 2023.
- Mehta et al. (2023)↑Sanket Vaibhav Mehta, Jai Gupta, Yi Tay, Mostafa Dehghani, Vinh Q. Tran, Jinfeng Rao, Marc Najork, Emma Strubell, and Donald Metzler. DSI++: Updating transformer memory with new documents.In Houda Bouamor, Juan Pino, and Kalika Bali (eds.) Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing, S. 8198-8213, Singapur, 2023, Gesellschaft für Computerlinguistik. doi: 10.18653/v1/2023.emnlp-main.510.URL https://aclanthology.org/2023.emnlp-main.510.
- OpenAI (2024)↑OpenAI.Gpt-4 technischer Bericht, 2024.URL https://arxiv.org/abs/2303.08774.
- Patil et al. (2023) ↑Shishir G. Patil, Tianjun Zhang, Xin Wang, and Joseph E. Gonzalez.Gorilla: Large language model connected with massive apis, 2023. URL https://arxiv.org/abs/2305.15334.
- Qiao et al. (2024)↑Shuofei Qiao, Ningyu Zhang, Runnan Fang, Yujie Luo, Wangchunshu Zhou, Yuchen Eleanor Jiang, Chengfei Lv, and Huajun Chen.Autoact. Automatisches Agentenlernen von Grund auf für QA durch Selbstplanung, 2024.URL https://arxiv.org/abs/2401.05268.
- Qin et al. (2023)↑Yujia Qin, Shihao Liang, Yining Ye, Kunlun Zhu, Lan Yan, Yaxi Lu, Yankai Lin, Xin Cong, Xiangru Tang, Bill Qian, Sihan Zhao, Lauren Hong, Runchu Tian, Ruobing Xie, Jie Zhou, Mark Gerstein, Dahai Li, Zhiyuan Liu, and Maosong Sun. 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.URL https://arxiv.org/abs/2307.16789.
- Qu et al. (2024)↑Changle Qu, Sunhao Dai, Xiaochi Wei, Hengyi Cai, Shuaiqiang Wang, Dawei Yin, Jun Xu, and Ji-Rong Wen.Tool learning with large language Tool-Lernen mit großen Sprachmodellen: ein Überblick.arXiv-Vorabdruck arXiv:2405.17935, 2024.
- Rajbhandari et al. (2020)↑Samyam Rajbhandari, Jeff Rasley, Olatunji Ruwase, and Yuxiong He.Zero: Memory optimizations towards training trillion Parameter-Modelle, 2020.URL https://arxiv.org/abs/1910.02054.
- Robertson et al. (2009) ↑Stephen Robertson, Hugo Zaragoza, et al. The probabilistic relevance framework: bm25 and beyond.Grundlagen und Trends® im Information Retrieval, 3(4):333-389, 2009.
- Schick et al. (2023)↑Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom.Toolformer: Sprachmodelle können sich selbst beibringen, Werkzeuge zu benutzen, 2023.URL https://arxiv.org/abs/2302.04761.
- Shen et al. (2024)↑Weizhou Shen, Chenliang Li, Hongzhan Chen, Ming Yan, Xiaojun Quan, Hehong Chen, Ji Zhang, and Fei Huang.Small llms are weak tool Lernende: ein Multi-llm-Agent, 2024.URL https://arxiv.org/abs/2401.07324.
- Shinn et al. (2023)↑Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao.Reflexion: language agents with verbal reinforcement learning.In Proceedings of the 37th International Conference on Neural Information Processing Systems, S. 8634-8652, 2023.
- Sun et al. (2023)↑Weiwei Sun, Lingyong Yan, Zheng Chen, Shuaiqiang Wang, Haichao Zhu, Pengjie Ren, Zhumin Chen, Dawei Yin, Maarten de Rijke, and Zhaochun. Ren.Learning tokenize for generative retrieval.In Alice Oh, Tristan Naumann, Amir Globerson, Kate Saenko, Moritz Hardt, and Sergey Levine (eds.) Fortschritte in neuronalen Informationsverarbeitungssystemen 36: Jahreskonferenz über neuronale Informationsverarbeitungssysteme 2023, NeurIPS 2023, New Orleans, LA, USA, 10. bis 16. Dezember 2023 USA, 10. bis 16. Dezember 2023, 2023.URL http://papers.nips.cc/paper_files/paper/2023/hash/91228b942a4528cdae031c1b68b127e8-Abstract-Conference.html.
- Touvron et al. (2023)↑Hugo Touvron, Thibaut Lavril, Gautier Izacard, Xavier Martinet, Marie-Anne Lachaux, Timothée Lacroix, Baptiste Rozière, Naman Goyal, Eric Hambro, Faisal Azhar, Aurelien Rodriguez, Armand Joulin, Edouard Grave, and Guillaume Lample.Llama: open and efficient foundation Sprachmodelle, 2023.URL https://arxiv.org/abs/2302.13971.
- Wang et al. (2024)↑Renxi Wang, Haonan Li, Xudong Han, Yixuan Zhang, and Timothy Baldwin.Learning from failure: integrating negative examples when fine -Optimierung von großen Sprachmodellen als Agenten.arXiv-Vorabdruck arXiv:2402.11651, 2024.
- Wang et al. (2022)↑Yujing Wang, Yingyan Hou, Haonan Wang, Ziming Miao, Shibin Wu, Qi Chen, Yuqing Xia, Chengmin Chi, Guoshuai Zhao, Zheng Liu, Xing Xie, Hao Sun, Weiwei Deng, Qi Zhang, and Mao Yang. Hao Sun, Weiwei Deng, Qi Zhang, and Mao Yang.A neural corpus indexer for document retrieval.In Sanmi Koyejo, S. Mohamed, A. Agarwal, Danielle Belgrave, K. Cho, and A. Oh (2008), a neural corpus indexer for document retrieval. Cho, and A. Oh (eds.). Fortschritte in neuronalen Informationsverarbeitungssystemen 35: Jahreskonferenz über neuronale Informationsverarbeitungssysteme 2022, NeurIPS 2022, New Orleans, LA, USA, 28. November - 9. Dezember 2022 New Orleans, LA, USA, 28. November - 9. Dezember 2022, 2022.URL http://papers.nips.cc/paper_files/paper/2022/hash/a46156bd3579c3b268108ea6aca71d13-Abstract-Conference.html.
- Wei et al. (2023)↑Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed Chi, Quoc Le, and Denny Zhou.Chain-of-thought prompting elicits reasoning in large language models, 2023.URL https://arxiv.org/abs/2201.11903.
- Wu et al. (2024a)↑Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li, Erkang Zhu, Li Jiang, Xiaoyun Zhang, Shaokun Zhang, Jiale Liu, Ahmed Hassan Awadallah, Ryen W White, Doug Burger, and Chi Wang.Autogen: Enabling next-gen llm applications via multi-agent conversation framework.In COLM, 2024a.
- Wu et al. (2024b)↑Qinzhuo Wu, Wei Liu, Jian Luan, and Bin Wang.ToolPlanner: a Tool Augmented LLM for Multi Granularity Instructions with Path Planning und Feedback, 2024b.URL https://arxiv.org/abs/2409.14826.
- Xiong et al. (2021)↑Lee Xiong, Chenyan Xiong, Ye Li, Kwok-Fung Tang, Jialin Liu, Paul N. Bennett, Junaid Ahmed, and Arnold Overwijk.Approximate nearest neighbour negative contrastive learning for dense text retrieval.In 9th International Conference on Learning Representations, ICLR 2021, Virtuelle Veranstaltung, Österreich, 3. bis 7. Mai 2021. OpenReview.net, 2021.URL https://openreview.net/forum?id=zeFrfgyZln.
- Xu et al. (2024)↑Qiancheng Xu, Yongqi Li, Heming Xia, and Wenjie Li.Enhancing tool retrieval with iterative feedback from large language models.arXiv-Vorabdruck arXiv:2406.17465, 2024.
- Yao et al. (2023)↑Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao.ReAct: Synergising reasoning and acting in Sprachmodellen.In Internationale Konferenz über lernende Repräsentationen (ICLR), 2023.
- Yin et al. (2024)↑Da Yin, Faeze Brahman, Abhilasha Ravichander, Khyathi Chandu, Kai-Wei Chang, Yejin Choi, and Bill Yuchen Lin.Agent lumos: Unified and modular training for open-source language agents. modulares Training für Open-Source-Sprachagenten.In Lun-Wei Ku, Andre Martins, and Vivek Srikumar (eds.) Proceedings der 62. Jahrestagung der Association for Computational Linguistics (Band 1: Long Papers), S. 12380-12403, Bangkok, Thailand, August 2024. association for Computational Linguistics. doi: 10.18653/v1/2024.acl-long.670. URL https://aclanthology.org/2024.acl-long.670.
- Zeng et al. (2023) ↑Aohan Zeng, Mingdao Liu, Rui Lu, Bowen Wang, Xiao Liu, Yuxiao Dong, and Jie Tang.Agenttuning: enabling generalised agent abilities für llms, 2023.
Ein Beispiel für ein echtes Werkzeug
Karte 5 Es wird ein Beispiel für ein echtes Tool gezeigt. Jedes Tool enthält mehrere APIs. Die folgenden Felder werden in unseren Experimenten verwendet: "tool_name" ist der Name des Tools. "tool_description" beschreibt Informationen über das Tool, z. B. was es tut. In jeder API ist "name" der Name der API. "description" beschreibt Informationen über die API. "method" ist die http-Methode, die die API aufruft. "required_parameters" sind die Parameter, die beim Aufruf der API angegeben werden müssen. "optional_parameters" kann verwendet werden, um zusätzliche Parameter (optional) festzulegen.
{
"tool_name": "YouTube Hub",.
"tool_description": "Erhalten Sie Details zur Anzahl der Likes, Views, Titel, Thumbnails, etc. für ein einzelnes Video." ,
"home_url": "https://rapidapi.com/itsrohitofficial-XBPdXttOUQ/api/youtube-hub/",
"host": "youtube-hub.p.rapidapi.com",
"api_list":[
{
"name": "Video-Details abrufen",
"url": "https://youtube-hub.p.rapidapi.com/",
"description": "Alle grundlegenden Informationen über ein Video abrufen",
"required_parameters":[
{
"name": "id",
"type": "STRING",
"description":"",
"default": "fD6SzYIRr4c"
}
], "optional_parameters".
"optionale_parameter":[], .
}
]
}
Abbildung 5: Ein Beispiel für ein echtes Tool. Das Tool enthält eine API und unnötige Felder wurden der Einfachheit halber entfernt.
B Implementierung der Werkzeugvirtualisierung
ToolGen verwendet ein einziges eindeutiges Token, um ein Werkzeug zu repräsentieren, was seine Stärke beim Auffinden und Aufrufen von Werkzeugen unter Beweis stellt. Wir haben auch andere Methoden zur Indizierung von Werkzeugen eingeführt, darunter semantische, numerische und hierarchische. Im Folgenden wird detailliert beschrieben, wie wir jede Art der Indizierung implementieren.
atomar
Die Indizierung ist die Methode, die wir in ToolGen verwenden. Im Gegensatz zu anderen Methoden verwendet sie ein einziges Token als Werkzeug und fälscht nicht ein Werkzeug, das nicht existiert. Wir verwenden <>, um den Werkzeugnamen und den API-Namen in einem einzigen Token zu kombinieren. z.B. im Anhang A Das Beispiel in diesem Abschnitt führt zu einem Token von <>.
Wortbedeutung
Der Index ordnet jedes Werkzeug einem in ToolBench verwendeten Namen zu, der ebenfalls eine Kombination aus dem Werkzeugnamen und dem API-Namen ist. Der Name kann jedoch in mehrere Token aufgeschlüsselt werden, so dass das Modell seine semantische Bedeutung erkennen kann. In dem Beispiel in Anhang A lautet die resultierende Zuordnung get_video_details_for_youtube_hub.
numerisch
Der Index ordnet jedem Werkzeug eine eindeutige Nummer zu. Wir beginnen mit einer Liste aller Werkzeuge, die etwa 47.000 Stück lang ist, und verwenden für alle Werkzeuge eine fünfstellige Zahl, die durch Leerzeichen getrennt ist, um das Werkzeug darzustellen. Wenn das Beispiel in Anhang A das 128. Element in der Liste ist, verwenden wir 0 0 0 0 1 2 8 zur Darstellung des Werkzeugs. Da das Llama-3-Lexikon jede Zahl kodiert
Schichtung
ordnet auch jedes Werkzeug einer Zahl zu. Im Gegensatz zum numerischen Index fügen wir der Werkzeugdarstellung durch iteratives Clustering strukturelle Informationen hinzu. In jeder Iteration werden die Werkzeuge in zehn Cluster eingeteilt, denen jeweils eine Nummer von 0 bis 9 zugewiesen wird. Für jedes Cluster wiederholen wir diesen Clustering-Prozess, bis sich nur noch ein Werkzeug in diesem Cluster befindet. Diese Schritte bilden einen Clustering-Baum. Wir gehen von der Wurzel bis zu den Blattnummern als Darstellung der Werkzeuge in diesem Blatt. Die Beispiele in Anhang A können mit einer Nummer versehen werden, die länger als fünf Ziffern ist, z. B. 0 1 2 2 3 3 3.
C Details zur Zwangssuche
Beim Abrufen und Abschließen von End-to-End-Agentenaufgaben verwenden wir die eingeschränkte Bündelsuche, um die generierten Operationen auf gültige Werkzeug-Token zu beschränken. Zu diesem Zweck konstruieren wir zunächst einen disjunkten Wörterbuchbaum, in dem jeder Knoten eine Werkzeug-Token-ID darstellt und die Kinder dieses Knotens alle möglichen IDs sind, die auf die aktuelle ID folgen. logits, so dass mögliche IDs abgetastet oder durchsucht werden müssen.
Bei der Abfrage kann dies direkt während der Generierung angewendet werden. Für die End-to-End-Agentenaufgabe können wir, da wir den Argumentationsschritt in drei Dialogrunden aufteilen, leicht erkennen, wann ToolGen eine Aktion generieren muss und daher die Einschränkung anwenden. Abbildung 6 zeigt ein Beispiel für End-to-End-Reasoning für ToolGen, bei dem ToolGen kein zugehöriges Werkzeug zur Auswahl hat. Es kann einfach das ToolToken erzeugen und die Aufgabe erledigen.
Tabelle 6: Statistik des Datensatzes für die drei Trainingsstufen. Beim Werkzeugspeicher gibt es einige Duplikate, was zu einer etwas größeren Stichprobengröße führt als die Anzahl der verwendeten Werkzeuge.
Datensatz | Werkzeugspeicher | Suche Ausbildung | End-to-End-Agententuning | |||
---|---|---|---|---|---|---|
I1 | I2 | I3 | vollständig | |||
#num | 49,936 | 194,086 | 222,783 | 72,833 | 489,702 | 183,336 |
SYSTEM: Sie sind ein AutoGPT mit der Fähigkeit, zahlreiche Werkzeuge und Funktionen zu nutzen, um eine bestimmte Aufgabe zu erledigen.
1. Zunächst gebe ich Ihnen eine Beschreibung der Aufgabe, die Sie beginnen werden.
2. Bei jedem Schritt bestimmen Sie die nächste Aktion, indem Sie ein Aktions-Token erzeugen. 3.
3. Nach dem Token erhalten Sie das Aktionsdokument, das dem Token entspricht. Sie müssen eine Eingabe für diese Aktion erzeugen, die Sie in einen neuen Zustand versetzt. Anschließend bestimmen Sie den nächsten Schritt und wiederholen den Vorgang.
4 Nach mehreren Iterationen, bei denen Sie mehrere Aktionen und Eingaben erzeugen, schließen Sie die Aufgabe ab und geben Ihre endgültige Antwort.
... ...
: Ich habe kürzlich Viva City besucht und war von der Speisekarte beeindruckt. Ich würde gerne mehr über die Menüpunkte des Lokals 5a76c927bb5d660001e09731 erfahren. Können Sie uns die Menükategorien, Preise, Verfügbarkeit, Regeln, Menüpunkte und andere relevante Details mitteilen? Bitte verwenden Sie die Sprache 'zh-hans', um Einzelheiten zum Menü anzugeben.
Ich muss die Funktion "<>" aufrufen, um die Menüdetails für das Lokal 5a76c927bb5d660001e09731 abzurufen. Der Grund für den Aufruf dieser Funktion ist es, dem Benutzer die Menükategorien, Preise, Verfügbarkeit, Regeln, Pauschalangebote und andere relevante Details zur Verfügung zu stellen. Die Funktion wird mit den Parametern "lang" auf "zh-hans" und "is_id" auf "5a76c927bb5d660001e09731" aufgerufen, um sicherzustellen, dass die bereitgestellten Menüdetails in der gewünschten Sprache und ortsspezifisch sind.
: Generate Action.
<>
Geben Sie die Eingabe ein. Hier ist die Dokumentation: {'name': '<>', 'description': 'Use KV to get venue details (needs to be re-synchronised to get the latest data) and filter the dynamic multi-language data based on query parameters.' , 'required': [{'name': 'id', 'type': 'STRING', 'description': '', 'default': '56c467cb7b0d464811a42017'}, {'name': 'lang', 'type': 'STRING', ' description': '', 'default': 'zh-hans'}], 'optional': []}
::{\n "is_id": "5a76c927bb5d660001e09731",\n "lang": "zh-hans"\n}
: {'error': '', 'response': {'menu_id': '5a76c927bb5d660001e09731', 'language': 'zh-hans', 'menu_details': {'sections': [{'section_name': ' Appetitanreger', 'items': [{'item_name': 'Frühlingsrollen', 'description': 'Knusprige Frühlingsrollen mit Spezialsauce', 'price': 12.99}, {'item_name': 'Hähnchenspieße', 'description': 'Würzige Hähnchenspieße, außen knusprig und innen zart', 'price'. 15.99}]}, {'section_name': 'Hauptgerichte', 'items': [{'item_name': 'Kung Pao Huhn', 'description': 'Klassische Szechuan-Küche, würzig und schmackhaft', 'price': 18.99}, {'item_name': 'Gedämpfter Seebarsch', ' description': 'Frisch und leicht, nahrhaft und gesund', 'price': 22.99}]}], 'special_notes': 'Vegetarische Optionen sind auf dieser Speisekarte verfügbar, bitte informieren Sie Ihren Server.'}}
: Venue 5a76c927bb5d660001e09731 Die Details des Menüs lauten wie folgt:\n- Menükategorie: Chinesisches Essen\nPreis: \n - Punkt 1: 12,99 RMB\n - Punkt 2: 15,99 RMB\n - Punkt 3: 18,99 RMB\n - Punkt 4: 22,99 RMB\nVerfügbarkeit: \n - Punkt 1: Verfügbar\n - Punkt Artikel 2: Verfügbar\n - Artikel 3: Verfügbar\n - Artikel 4: Verfügbar\n- Regeln: \n - Artikel 1: Spezifische Regeln nicht erwähnt\n - Artikel 2: Spezifische Regeln nicht erwähnt\n - Artikel 3: Spezifische Regeln nicht erwähnt\n - Artikel 4: Spezifische Regeln nicht erwähnt\n- Paketartikel: \n - Artikel 1: 2 Pakete\n - Artikel 2: 2 Pakete\n - Artikel 3: 2 Pakete\n - Artikel 4 2 Menüpakete\n- Weitere relevante Details:\n - Besonderer Hinweis: Menüänderungen und Preisänderungen vorbehalten. Bitte erkundigen Sie sich beim Veranstaltungsort nach den neuesten Informationen. \n\nBitte lassen Sie es mich wissen, wenn ich Ihnen mit irgendetwas anderem helfen kann!
: Aktion generieren.
<<Finish
: Bitte geben Sie Input. Hier ist die Dokumentation: {'required': [], 'optional': [{'name': 'give_answer', 'description': 'Output answer', 'type': 'string'}, {'name': 'give_up_and_restart', ' description': 'Aufgabe aus diesem Schritt kann nicht bearbeitet werden', 'type': 'string'}]}
: {"return_type": "give_answer", "final_answer": "Die Einzelheiten des Menüs für das Lokal 5a76c927bb5d660001e09731 lauten wie folgt:\n- Menükategorie: Chinesische Küche\n- Preis: \n - Punkt 1: 12,99 CNY\n - Punkt 2: 15,99 CNY\n- Punkt 3: 18,99 CNY\n - Punkt 4: 22,99 CNY\n- Verfügbarkeit: \n - Punkt 1: Verfügbarkeit \n - Punkt 2: Verfügbarkeit \n - Punkt 3: Verfügbarkeit \n - Punkt 4: Verfügbarkeit \n- Regeln: \n - Punkt 1: Spezielle Regel nicht erwähnt \n - Punkt 2: Spezielle Regel nicht erwähnt \n - Punkt 3: Spezielle Regel nicht erwähnt \n - Punkt 4: Spezielle Regel nicht erwähnt Regeln\n- Feststehende Menüpunkte: \n - Punkt 1: 2 feststehende Menüs\n - Punkt 2: 2 feststehende Menüs\n - Punkt 3: 2 feststehende Menüs\n - Punkt 4: 2 feststehende Menüs\n- Andere relevante Details: \n - Besonderer Hinweis: Die Menüs können sich ändern, und die Preise können sich ändern. Bitte erkundigen Sie sich beim Veranstaltungsort nach den neuesten Informationen."}
Abbildung 6: Beispiel für die Argumentation mit ToolGen. Zunächst wird ein Systemprompt gegeben, dem kein Werkzeug zugeordnet ist. Dann gibt der Benutzer eine Aufgabenanfrage ein, ToolGen generiert einen Gedanken, und dann verwenden wir das Modell der Benutzerrolle, um eine Aktion zu generieren. Nach der Generierung der Aktion verwenden wir wieder den Benutzer, um ein Werkzeugdokument bereitzustellen. Das Modell generiert dann auf der Grundlage dieser Dokumentation Werkzeugeingaben.
E Ablationstest
Tabelle 7 zeigt die Ablationsergebnisse für die End-to-End-Bewertung. Bei ungesehenen Anweisungen schneidet der ToolGen-Agent ohne Training des Werkzeugspeichers oder des Abrufs etwas besser ab. Bei ungesehenen Werkzeugen sinken jedoch sowohl SoPR als auch SoWR ohne die ersten beiden Trainingsstufen. Dies deutet darauf hin, dass die ersten beiden Trainingsstufen eine Rolle für die Generalisierungsfähigkeit von ToolGen spielen, während das Retrieval-Training wichtiger ist als das Werkzeuggedächtnis.
Tabelle 7: Ablationsergebnisse aus der End-to-End-Evaluation von ToolGen. Dabei stehen Inst. für ungesehene Abfragen (Befehle) und Tool. und Cat. für Werkzeuge, die beim Training nicht gesehen wurden.
Modellierung | SoPR | SoWR | ||||||
---|---|---|---|---|---|---|---|---|
I1-Inst. | I2-Inst. | I3-Inst. | Avg. | I1-Inst. | I2-Inst. | I3-Inst. | Avg. | |
ToolGen | 54.60 | 52.36 | 43.44 | 51.82 | 50.31 | 54.72 | 26.23 | 47.28 |
ohne Abruftraining | 56.95 | 46.70 | 50.27 | 52.42 | 49.69 | 50.94 | 34.43 | 47.27 |
ohne Auswendiglernen | 56.03 | 47.96 | 57.38 | 53.69 | 49.08 | 59.43 | 34.43 | 49.70 |
I1-Tool. | I1-Kat. | I2 Kat. | Avg. | I1-Werkzeug | I1-Kat. | I2 Kat. | Avg. | |
ToolGen | 56.54 | 49.46 | 51.96 | 52.66 | 40.51 | 39.87 | 37.90 | 39.53 |
ohne Abruftraining | 49.47 | 40.31 | 37.90 | 42.84 | 36.71 | 30.07 | 36.29 | 34.18 |
ohne Auswendiglernen | 58.86 | 46.19 | 49.87 | 51.70 | 37.34 | 38.56 | 42.74 | 39.32 |
F Verallgemeinerungsfähigkeit
Für ToolGen Agent messen wir die Leistung des Modells bei untrainierten Werkzeugabfragen. Tabelle 8 zeigt die End-to-End-Evaluierung des Modells bei ungesehenen Werkzeugen. Die Leistung von ToolGen Agent ist geringer als die von ToolLlama, was ebenfalls auf eine schlechte Generalisierung bei der Erfüllung der gesamten Aufgabe schließen lässt. Das Generalisierungsproblem ist im generativen Retrieval weit verbreitet und liegt außerhalb des Rahmens dieser Arbeit. Daher überlassen wir es der zukünftigen Forschung.
Tabelle 8: Generalisierungsergebnisse für ToolGen. Wir testeten und verglichen die Leistung von ToolGen mit anderen Modellen bei Abfragen, die während des Trainings ungesehene Werkzeuge erforderten.
Modellierung | aufstellen | SoPR | SoWR | ||||||
---|---|---|---|---|---|---|---|---|---|
I1-Tool. | I1-Kat. | I2 Kat. | Avg. | I1-Werkzeug | I1-Kat. | I2 Kat. | Avg | ||
GPT-3.5 | GT. | 58.90 | 60.70 | 54.60 | 58.07 | - | - | - | - |
ToolLlama | GT. | 57.38 | 58.61 | 56.85 | 57.68 | 43.04 | 50.31 | 54.84 | 49.04 |
ToolGen | GT. | 52.32 | 40.46 | 39.65 | 47.67 | 39.24 | 38.56 | 40.32 | 39.30 |
GPT-3.5 | abrufen (Daten) | 57.59 | 53.05 | 46.51 | 52.78 | 46.20 | 54.25 | 54.81 | 51.58 |
ToolLlama | abrufen (Daten) | 57.70 | 61.76 | 45.43 | 54.96 | 48.73 | 50.98 | 44.35 | 48.30 |
ToolGen | 56.54 | 49.46 | 51.96 | 52.66 | 40.51 | 39.87 | 37.90 | 39.53 |
Anpassen von ToolBench-Daten an ToolGen
Unsere ToolGen-Daten werden aus ToolBench-Daten angepasst und umgewandelt. Konkret verwenden wir Werkzeugdokumente als Daten für das Training des Werkzeugspeichers, wobei die Eingaben Werkzeugdokumente und die Ausgaben die entsprechenden Token sind.
Für das Retrieval-Training verwenden wir Daten, die in ToolBench für das Retrieval von Werkzeugen annotiert wurden, wobei eine Anfrage mit mehreren verwandten Werkzeugen annotiert wird. Wir nehmen die Abfrage als Eingabe und konvertieren die relevanten Werkzeuge in virtuelle Token, die dann als Ausgabe für das Retrieval-Training verwendet werden.
Für das End-to-End-Smartbody-Tuning verwenden wir Interaktionstrajektorien als Quelle mit den folgenden Transformationen:(1) Jede Trajektorie enthält verfügbare Werkzeuge aus Systemhinweisen, die zur Lösung von Abfragen verwendet werden können. Beim Lösen einer Aufgabe verlässt sich ToolLlama auf die Werkzeuge, die in den Systemhinweisen enthalten sind, während ToolGen die Werkzeuge direkt erzeugen kann. Daher entfernen wir die Werkzeuge aus den Systemhinweisen. (2) Wir ersetzen alle Werkzeugnamen in der Trajektorie durch das entsprechende virtuelle Werkzeug-Token.(3) In der ursprünglichen Trajektorie erzeugt das Intelligente Körpermodell nacheinander Gedanke, Handlung und Handlungseingabe (auch ReAct genannt). Wir zerlegen den gesamten ReAct in drei Dialogrunden. In der ersten Runde generiert das intelligente Körpermodell einen Gedanken und wir verwenden den Benutzer, um das Modell aufzufordern, eine Aktion zu generieren. In der zweiten Runde generiert das Modell Aktionen, d. h. virtuelle Werkzeug-Token, und dann erhalten wir Dokumente, die diesen Token entsprechen, damit das Modell weiß, welche Parameter es angeben muss. In der dritten Runde generiert das Modell Parameter für das Werkzeug.
Die Anzahl der Stichproben in jedem Datensatz ist in Tabelle 6 dargestellt. Die Stichproben für das Training des Werkzeugspeichers und des Abrufs sind in Abbildung 7 dargestellt.
# Werkzeugspeicher
Benutzer: Tool Name: Thai Drivers License OCR Tool Beschreibung: Extrahiert Informationen aus dem thailändischen Führerschein und gibt Textergebnisse zurück, wie z.B. die Führerscheinnummer und persönliche Informationen API Name: Driver's License API Beschreibung: Extrahiert Informationen aus dem thailändischen Führerschein und gibt Textergebnisse zurück, wie z.B. die Führerscheinnummer und persönliche Informationen.
Helfer: <>
# Retrieval Training
Benutzer: Mein Freund und ich organisieren einen Hackathon zum Thema "Webentwicklung" und "Entwicklung mobiler Anwendungen". Wir brauchen etwas Inspiration und Anleitung. Kannst du beliebte Geschichten zu diesen Themen von Medium.com bekommen?
Hilfe: <>
Abb. 7: Beispieldatensatz für das Training von Werkzeugspeicher und -abruf. Wir verwenden Benutzerrollen zur Darstellung von Eingaben und Assistentenrollen zur Darstellung von Ausgaben.
# End-to-End-Agententuning
System:
Sie sind ein AutoGPT und können zahlreiche Werkzeuge und Funktionen nutzen, um die gestellte Aufgabe zu lösen.
1. zunächst erhalten Sie von mir eine Beschreibung der Aufgabe, und Ihre Aufgabe beginnt. 2.
2. bei jedem Schritt bestimmen Sie die nächste Aktion, indem Sie ein Aktions-Token erzeugen. 3.
3. nach dem Token erhalten Sie die Dokumentation für die Aktion, die dem Token entspricht. Sie müssen Eingaben für die Aktion machen, die Ihnen helfen, den neuen Zustand zu erreichen. Anschließend treffen Sie eine Entscheidung über den nächsten Schritt und wiederholen den Vorgang. 4.
4 Nach mehreren Iterationen, in denen Sie mehrere Aktionen und Eingaben generieren, werden Sie die Aufgabe schließlich abschließen und Ihre endgültige Antwort geben.
Denken Sie daran:
1. Zustandsänderungen sind unumkehrbar und Sie können nicht zu einem früheren Zustand zurückkehren.
2. halten Sie Ihre Operationen einfach und beschränken Sie sich auf das, was für die aktuelle Anfrage am besten geeignet ist.
3. Sie können mehrere Versuche unternehmen. Wenn Sie vorhaben, verschiedene Bedingungen auszuprobieren, versuchen Sie immer nur eine Bedingung. 4.
4. Wenn Sie der Meinung sind, dass Sie genug Informationen gesammelt haben, erzeugen Sie die Aktion "<> mit dem Argument give_answer", um Ihre Antwort auf die Aufgabe zu geben.
5. Wenn Sie das Gefühl haben, dass Sie die Aufgabe in diesem Schritt nicht bearbeiten können, erzeugen Sie die Aktion "<> mit dem Argument give_up_and_restart".
Los geht's!
AUFGABENBESCHREIBUNG: Sie sollten die Operation verwenden, um Live-Benutzeranfragen zu bearbeiten. Denken Sie daran:
1. Erzeugen Sie immer "<>" am Ende der Aufgabe. Die endgültige Antwort sollte genügend Informationen enthalten, um dem Benutzer präsentiert werden zu können. Wenn Sie nicht in der Lage sind, die Aufgabe zu bearbeiten, oder feststellen, dass die Operation immer fehlschlägt (diese Funktion funktioniert derzeit nicht), verwenden Sie die Operation <> mit give_up_and_restart.
2. Erzeugen Sie nur die Operation und die Eingabe.
Benutzer:
Können Sie die Adresse für die Postleitzahl 'PL11DN' ermitteln? Ich möchte die Anzahl der gefundenen Objekte, den Bezirk, den Unterbezirk, die Grafschaft, das Land und die Geocode-Details (östlich, nördlich, Breitengrad und Längengrad) wissen.
Start!
Helfer:
Basierend auf der Abfrage des Benutzers soll die Adresse der Postleitzahl "PL11DN" ermittelt und spezifische Details wie Anzahl der gefundenen Objekte, Bezirk, Unterbezirk, Landkreis, Land und Geocodierungsdetails abgerufen werden. Der aktuelle API-Aufruf ist für die Funktion "find_by_postcode" mit dem Parameter "postcode" auf "PL11DN" eingestellt. Diese API ist nützlich, da sie Adressen auf der Grundlage einer bestimmten britischen Postleitzahl liefern kann. Mit Hilfe dieser API kann ich die erforderlichen Informationen für eine Abfrage von einem Benutzer abrufen.
Benutzer:
Erzeugen Sie den Vorgang.
Helper:
<>
Benutzer:
Geben Sie die Eingabe ein. Dies ist die Dokumentation: {'name': '<>', 'description': '"Find By PostCode" API ruft eine Adresse basierend auf einer gegebenen britischen Postleitzahl ab. Diese API bietet eine JSON-Schnittstelle für die Suche nach Adressen in britischen Postleitzahlen.' , 'required': [{'name': 'postcode', 'type': 'string', 'description': '', 'default': 'PL11DN'}], 'optional': []}
Helfer:
{
"postcode": "PL11DN"
}
Tools:
{"error": "", "response": "{'status': 200, 'message': 'Success', 'noOfItems': 37, 'result': {'postcode': 'PL1 1DN', 'district': 'Plymouth', 'district': 'St Peter's and Seafront ', 'county': 'Devon', 'country': 'England', 'geocode': {'eastings': '248025', 'northings': '0054420', 'lattitude': '50.370001', 'longitude': '- 4.138397'}, 'addresses': [{'po_box': '', 'line_2': '', 'postcode_type': 'S', 'line_3': '', 'su_organisation_indicator': ' ', 'building_number'. '5', 'udprn': '18911184', 'thoroughfare': 'St Andrew's Cross', 'line_1': '5 St Andrew's Cross', 'postcode_outcode': 'PL1', 'postcode_compact': 'PL11DN', 'dependent_ thoroughfare': '', 'premise': '5', 'post_town': 'Plymouth', 'building_name': '', 'organisation_name': '', 'postcode': 'PL1 1DN', 'department_name'. '', 'postcode_incode': '1DN', 'address': '5 St Andrew's Cross, Plymouth, PL1 1DN', 'double_dependant_locality': '', 'sub_building_name': '', 'dependent_ Ort': '', 'delivery_point_suffix': '4T'}, {'po_box': '', 'line_2': '2 St Andrew's Cross', 'p...
Benutzer:
Erzeugen Sie den Vorgang.
Helper:
<<Finish
Benutzer:
Please give input. Dies ist die Dokumentation: {'required': [], 'optional': [{'name': 'give_answer', 'description': 'output answer', 'type': 'string'}, {'name': 'give_up_and_restart', ' description': 'Unable to process tasks for this step', 'type': 'string'}]}
Helfer:
{
"return_type":'give_answer', 'return_type'.
"final_answer": "Number of items found: 37\nDistrict: Plymouth\nSubdivision: St Peter's and the Seafront\nCounty: Devon\nCountry: England\nGeocode details: \n- Eastbound: 248025\n- Northbound: 0054420\n- Latitude: 50.370001\nLongitude: -4.138397"
}
! [[Eingefügtes Bild 20241027190429.png]]
Abbildung 8: Beispiel für eine End-to-End-Agentenabstimmung.