Die herkömmliche „Tool‑Search“-Strategie bei LLM‑Agents reicht nicht aus; stattdessen sollte ein Mechanismus für die Selbst‑Entdeckung und effiziente Ladung von Tool‑Definitionen entwickelt werden, um Speicherbudget und Kontext‑Erreichbarkeit zu optimieren. Die Analyse umfasst, wie APIs zu jeder Anfrage ein System‑Prompt und eine Liste von Tool‑Definitionen senden, und wie große, komplexe Tools bis zu 1.000 Tokens benötigen. 20 Tools summieren sich auf 20.000 Tokens bei einem 200.000‑Token‑Kontext. Externe Plattformen wie GitHub, Notion, Linear, Postgres tragen zusätzlich große Mengen an Tool‑Definitionen (bis zu 20.000 Tokens). Im Detail umfasst die Analyse, wie APIs zu jeder Anfrage ein System‑Prompt und eine Liste von Tool‑Definitionen senden. Im Detail umfasst die Analyse, wie APIs zu jeder Anfrage ein System‑Prompt und eine Liste von Tool‑Definitionen senden.
Herausforderungen und offene Fragen: Wie kann ein Modell selbstständig verfügbare Tools entdecken, wenn es keine prägnante Beschreibung hat? Wie werden Overlap‑Situationen (Tools mit ähnlichen Aufgaben) effizient geregelt, um Modellverwirrung zu vermeiden? Welcher Ansatz minimiert gleichzeitig Latenz, Speicherverbrauch und Fehlbedeutungen der Tool‑Nutzung?
Related queries
Wie können LLM‑Agenten Tool‑Definitionen effizient selbst entdecken und laden?
Was sind effektive Möglichkeiten, Tool‑Überlappungen (z. B. grep vs. finder) zu handhaben?
Wie kann man kurze Tool‑Preambles für ein Sprachmodell generieren, um Kontextkosten zu senken?
Quelle: https://nicolaygerold.com/posts/tool-search-should-not-be-just-search-but-discovery