AI Dev 25 | Bilge Yücel: Building and Deploying Agentic Workflows with Haystack

Hallo, vielen Dank an alle und danke, dass Sie an diesem Vortrag über Agenten teilgenommen haben. Heute werden wir Agenten Workflows mit hastack erstellen und bereitstellen. Zuerst möchte ich mich vorstellen. Mein Name ist Fen, Ich arbeite als Developer Relations Engineer bei deepset. Können Sie mich alle hören? Na gut, super. Ich arbeite als Developer Relations Engineer bei deepset. Deepset ist das Unternehmen hinter dem Open Source LM Orchestrierungsframework hasstec und ich komme ursprünglich aus Istanbul, Türkei. Ich bin wegen der Konferenz hierhergekommen. Ich freue mich sehr, dass Sie heute alle hier sind. Hier ist die Tagesordnung für heute. Zuerst stelle ich Sie vor, dann steigen wir direkt ins Thema ein. Wir starten unseren Agenten und stellen ihn anschließend bereit, wenn Sie Zeit haben. Ich habe ein paar Fragen. Sie haben heute sicher schon viel über Agenten gehört, aber ich wollte es kurz erwähnen. Ich denke, es fasst gut zusammen, was ein Agent ist. Ein Agent ist im Grunde ein LLM basiertes autonomes System, das Zugriff auf Sie und Ihren Speicher sowie einige Tools hat. Der entscheidende Punkt ist jedoch, dass er Aktionen planen und ausführen kann, um ein Ziel zu erreichen. Behalten wir das im Hinterkopf, wenn wir den Agenten entwickeln und über die Agenten nachdenken. Nun kurz zu haststack. Wie bereits erwähnt, ist Hust Stack das Open Source LM Orchestrierungsframework von deepsets. Es bietet die Tools, die Python Entwickler benötigen, um reale agentenbasierte Key Systeme zu entwickeln. Hijack bezieht seine Leistung aus seinen Bausteinen. Komponenten und Pipelines. Komponenten in hastacks sind kleinere Einheiten. Sie erfüllen jeweils nur eine Funktion. Dies kann beispielsweise das Erstellen einer Einbettung, das Generieren von Text, das Abrufen relevanter Informationen aus Ihrer Datenbank, das Bereinigen von Dokumenten oder das Konvertieren von Dateien sein. Indem Sie diese Komponenten miteinander verbinden, bilden Sie Pipelines. Aber Pipelines in hassteck sind Graphen und um genau zu sein, ups, genau genauer gesagt, handelt es sich um gerichtete, zyklische Graphen. Die Idee, dass Pipelines gerichtete Graphen sind, bietet Ihnen also viel Flexibilität. Mit dieser Flexibilität können Sie den Datenfluss in Ihrer Anwendung mit Verzweigungen, Schleifen und so weiter steuern. Das hilft Ihnen auch sehr beim agentenbasierten Verhalten. Wir haben über die Komponenten gesprochen. Wie ich bereits sagte, haben sie nur eine Funktion. Was Ihnen viel Modularität bietet. So können Sie beispielsweise einen Empfänger durch einen anderen Abrufer ersetzen, um verschiedene Methoden auszuprobieren, oder einen Generator durch einen anderen, um verschiedene Modelle auszuprobieren. Hassteck bietet viele integrierte Komponenten und Integrationen. Wenn Sie jedoch einen sehr spezifischen Anwendungsfall haben, eine sehr individuelle Logik in Ihre Anwendung integrieren möchten oder ein sehr spezifisches Tool verwenden, können Sie problemlos eine benutzerdefinierte Komponente in haststack erstellen und in Ihre Pipeline einbinden. Und so sieht eine benutzerdefinierte Komponente in haststack tatsächlich aus. Im Grunde ist es wie eine Python Klasse. Sie benötigen lediglich diesen Komponenten Dekorator und diese run Methode. Die run Methode akzeptiert beliebig viele Eingaben. Denken Sie daran, dass diese Komponente ein Knoten in unserem Graphen ist. Stellen Sie sich also vor, die Knoten kommen zu diesem Knoten. Stellen Sie sich vor, die Eingaben kommen zu diesem knoten. Es ist zum Beispiel Eingabe 1, Eingabe 2 und es hat die Stringtypen, die ich in meiner Randfunktion definiere. Als Ausgabe gibt es ein Wörterbuch zurück und für dieses hier hat es den Ausgabeschlüssel wieder in einem Stringtyp. Gut, nachdem wir nun wissen, wie man Hacks erstellt, können wir mit der Erstellung unseres Agenten beginnen. Wir haben also gesagt, dass LLM Agenten LLM basierte Systeme sind. Das stimmt, aber ich denke, es braucht etwas mehr als nur große Sprachmodelle. Und das ist ein Zitat eines unserer Community Mitglieder. Er sagt, dass Agenten viel mehr Arbeit erfordern als erwartet und zu 90 Prozent reine Entwicklungsarbeit sind. Das hat zwar nichts mit LLM zu tun, aber es ist schwierig, LLM in einen agentenbasierten Workflow zu integrieren. Das ist verständlich und ich stimme ihm zu. Letztendlich braucht man zwar ein leistungsstarkes Large Language Model, aber man kann nicht einfach einen Agenten mit diesem LLM erstellen. Man muss verstehen, wie man diesen Agenten strukturieren möchte und man braucht auch die Tools, die einen bei der Erstellung unterstützen. Sehen wir uns das an einem Beispiel an. Heute erstellen wir einen GitHub Issue Resolver Agenten. Dieser Agent nimmt eine GitHub Issue URL und stellt sich Open Source Projekte wie HSTAG haben offene Issues auf GitHub. Von diesem Agenten erwarte ich, dass er diese Issue URL erhält, die Kommentare dazu liest und einen Plan und eine Anleitung zur Lösung des Problems entwickelt. N Natürlich muss er dafür durch das Repository navigieren und die Codebasis verstehen. Wie stellen Sie sich ein solches System vor? Ist es ein Agent, der Zugriff auf mehrere Tools hat oder ein Multiagentensystem? Vielleicht denken Sie, dass man das Problem in einem sehr linearen Ablauf lösen kann. Wenn wir hier 100 Leute sind, können wir 100 verschiedene Ansätze entwickeln, je nachdem, wie wir denken und wie wir diese Anwendung strukturieren wollen. Aber so stelle ich mir dieses System vor. Im Grunde ist es wieder eine Haseline, aber eine lineare, also nicht so kompliziert, wie es scheint. Es nimmt also diese Problem URL und meine erste Komponente ist der GitHub ProblemViewer. Diese Komponente ruft die Problembeschreibung und die Kommentare von der Problem URL ab. Ziemlich einfach, sehr deterministisch. Als zweite Komponente habe ich den GitHub Problembilder. Diese Komponente ruft die Problembefehle ab und rendert sie in einem Format, das ich an meinen LLM weitergeben kann. Ich und Sie werden im Beispiel sehen, wie ich die Darstellung dieser Eingabeaufforderung strukturiere. Als dritte Komponente in meiner Pipeline verwende ich die Agentenkomponente aus haststack. Diese Agentenkomponente ist ein Tool, das den Agenten aufruft, Sie akzeptiert Tools kann Funktionen aufrufen, Ergebnisse abrufen und zurückgeben. Im Grunde ist es also ein Tool, das den Agenten aufruft. ER nutzt das Cloud Set Modell von Antropix 3.7 und hat Zugriff auf zwei Tools. Das erste ist der GitHub Repository Viewer. Mein Agent iteriert damit das Repository, liest die Dateien und findet die relevanten Informationen aus der Codebasis. Natürlich geschieht dies iterativ und rekursiv. Das zweite Tool ist der GitHub Comment Reiter. Dieser ist allerdings sehr einfach. Sobald mein Agent bereit ist, Den Kommentar an GitHub zu senden, nutzt er dieses Tool, um ihn über die GitHub API in das Issue einzufügen. Am Ende habe ich mit einem Issue begonnen. Ich habe vieles gemacht, aber am Ende erhalte ich einen neuen GitHub Befehl für das jeweilige Problem. OK. Bevor wir zum nächsten Schritt übergehen, versuchen wir es live. Hier ist das Repository. Sie finden den Link am Ende der Präsentation, damit Sie den gesamten Code replizieren können. Was ich hier gemacht habe, ohne es Ihnen zu zeigen, ist das IPIP die erforderlichen Abhängigkeiten installiert und meine API Schlüssel für Entropic und GitHub eingegeben hat, also nichts Besonderes. Schauen wir uns also die Komponenten an, die ich für diesen Agenten benötige. Ich habe drei Komponenten. Die erste ist der Problembetrachter. Wie bereits erwähnt, handelt es sich um eine benutzerdefinierte Hack Komponente. Sie hat einen Pi, der als Python Klasse startet, aber diesen Komponenten Dekorator benötigt. Wie das funktioniert, erfahren Sie im Folgenden. Lassen Sie mich zur Ausführungsfunktion scrollen, um die Details anzuzeigen. Es ruft die URL als String ab und gibt eine Liste von Dokumenten zurück, wobei jedes Dokument die Problembeschreibung oder den Kommentar zu diesem Problem enthält. Es ist also ziemlich einfach. Die zweite Komponente, die ich Ihnen zeigen möchte, ist der Repo Viewer. Diese Komponente verwende ich als Tool für meinen Agenten. Es handelt sich um eine Python Klasse mit dem Komponenten Dekorator. Wenn ich nach unten zu ihrer Run Methode scrolle, sehe ich sie. Sie akzeptiert die Pfade Repo und Branch. Repo und Branch sind optionale Parameter. Auch hier gibt sie eine Liste von Dokumenten zurück. Diese Komponente funktioniert folgendermass Wenn sie einen Pfad in meiner GitHub Codebasis abruft und dieser zu einem Verzeichnis führt, gibt sie alle Elemente in diesem Verzeichnis als Liste von Dokumenten zurück. Die Elemente in diesem Verzeichnis können Dateien oder auch Unterverzeichnisse sein. Sie enthält also alle Informationen dieser Dokumentenliste, sodass sie später iterieren kann, um die Codebasis weiter zu erkunden. Wenn dieses Pad eine Datei anzeigt, erhalte ich als Liste der Dokumente den Dateiinhalt. Die letzte Komponente, die ich Ihnen zeigen möchte, ist die Komponente für Issue Kommentare. Wie bereits erwähnt, ist dies eine Komponente zum Posten von Kommentaren zu GitHub Issues. Sehen wir uns die Ausführungsmethode an. Ich zeige Ihnen nur die Ausführungsmethode, da die anderen Methoden nur Hilfsfunktionen sind, damit diese Komponenten funktionieren. Hier erhält sie die URL, die Haupt URL und die Kommentare, die mein Agent generiert hat. Im Gegenzug erhalte ich einen Erfolgsstatus und den Kommentar selbst. Gut, so jetzt haben wir die Komponenten. Schauen Sie sich diese Grafik noch einmal an. Ich habe Ihnen den Issue Viewer, den GitHub Repository Viewer und den GitHub Comment Reiter gezeigt. Jetzt können wir unsere Haststack Pipeline mit diesen Komponenten erstellen also ich initialisiere meine GitHub Visual Viewer Komponente. Um die Eingabeaufforderung mit den Kommentaren dieser Komponente zu erstellen, verwende ich diese Vorlage. Bei genauerem Hinsehen fällt auf, dass es der Ginger To Syntax folgt. Das bedeutet, dass es Variablen enthalten kann. Es kann verschleifen und if Anweisungen enthalten, was Ihnen viel Flexibilität bei der Erstellung Ihrer Eingabeaufforderung in Ihrer Anwendung bietet. Diese Eingabeaufforderung gebe ich meinem Chat Prompt Bilder als Benutzernachricht. Die Systemnachricht werde ich später hinzufügen. Anschließend kann ich mit der Erstellung der Agentenkomponente beginnen. Ich benötige den Chat Generator. Dieser fungiert als Gehirn meines Agenten. Dazu definiere ich den Entropic Chat Generator mit dem Claw Z Modell und erstelle im nächsten Schritt meine Tools. Ich habe bereits Komponenten dafür erstellt und um diese Komponenten in Tools umzuwandeln, verwende ich diese Tool Klasse. Diese Klasse macht Wenn Sie sich an die vorherige Präsentation erinnern oder schon einmal Funktionsaufrufe durchgeführt haben, müssen Sie für Funktionsaufrufe mit großen Sprachmodellen die Funktion, aber auch die Beschreibung, den Namen und das Parameterschema angeben. Dieses Komponenten Tool übernimmt im Wesentlichen die gesamte Komplexität für mich. Es generiert die Beschreibung aus dem DocString meiner Komponente und das Parameterschema wiederum aus den Parametern meiner Komponente. Ich muss mich also nicht um all das kümmern, wenn ich meine Komponente klar definiere. Ich muss hier nicht einmal den Namen definieren, er steht einfach da. Ich definiere meine GitHub Repository Viewer Komponente in ein Tool, um sie meinem Agenten bereitzustellen. Dasselbe mache ich auch mit meinem GitHub Issue Kommentator Tool. Ich verwende das Komponenten Tool, um es in ein Tool für meinen Agenten umzuwandeln. Meine Agentenkomponente übergebe ich nun an den Chat Generator, das Gehirn des Agenten. Ich stelle meinem Agenten meine Systemeingabeaufforderung zur Verfügung. Die Systemeingabeaufforderung selbst befindet sich ebenfalls in diesem Repository, aber es ist sehr lang. Es enthält viele Anweisungen zur Verwendung der Tools und zur Erstellung der Eingabeaufforderung bzw. Des Kommentars, da dieser Kommentar wie der Resolver Befehl im Markdown Format vorliegen soll. Sie können es sich also später ansehen und als Tools stelle ich die Tools zur Verfügung, die ich hier definiere. Es gibt auch eine sehr praktische Parameter Exit Bedingung für meinen Agenten, da mein Agent natürlich selbst entscheiden kann, wann er stoppt. Aber ich kann auch sagen, dass jedes Mal, wenn Sie dieses tool verwenden, dass GitHub Befehle schreibt, das Tool, mit dem ich diese Befehle auf GitHub hochlade, einfach dort stoppt. Sie müssen nicht immer wieder iterieren. Ihre Entscheidung, dieses Tool zu verwenden, reicht mir, damit Sie aufhören. Und ja, jetzt habe ich alles, was ich brauche. Ich initialisiere einfach meine Pipeline. Ich füge alle Komponenten einzeln meiner Pipeline hinzu. Stellen Sie sich Ich habe alle Knoten, aber sie sind nicht miteinander verbunden. Ich verbinde beispielsweise die Ausgabe der Issue Viewer Dokumente mit der Eingabe der Issue Bilder Dokumente und die Eingabeaufforderung meines Issue Bilders mit den Nachrichten der Issue Builder Agenten. Ich erstelle die Kanten zwischen meinen Knoten und hier können Sie sich austoben. Wie Sie sich erinnern, ist das hier sehr linear. Wenn Sie Schleifen und Verzweigungen wünschen, können Sie diese Verbindungen hier definieren, wenn Sie Komponenten miteinander verbinden. Gut, testen wir also diese Pipeline. In diesem Skript initialisiere ich im Wesentlichen die Protokollierung und definiere die URL meines Issues. Dazu habe ich das hassteck Repository geforkt und eines der Issues, die wir hier haben, kopiert und eingefügt und wir werden es mit diesem Agenten versuchen. Wie ich diesen Agenten ausführe, wie ich diese ganze komplexe Pipeline ausführe, ist im Grunde, dass ich Pipeline R ausführe und die URL angebe, um die Eingaben bereitzustellen, die ich zum Ausführen dieser Pipeline benötige. Also versuchen wir es. Alles klar. Hier sehen Sie, dass es mir zeigt, welche Komponente es in Echtzeit ausführt. Es wird einige Zeit dauern, also versuchen wir es. Ja, es macht eine Menge. Es iteriert wahrscheinlich über das Repo, um das Problem zu lösen. Hoffentlich klappt es. Live Demos sind immer OK. Komm schon. Ja, es ist gestoppt, Also drucken Sie mir einfach die Ausgabe aus. Mein Agent. Komm schon. Da ist sie. Alles klar. Also alles klar. Aber kommen wir zum Problem selbst. Lassen Sie es mich Ihnen näher erläutern. Also das war eigentlich das Problem. Also habe ich meinem Agenten gesagt, er soll die 3.9 Unterstützung bei der Serialisierung einstellen und ich habe nur gesagt, dass er größere oder gleich Python 3.9 Prüfungen im Typ Serialisierung einstellen soll, also nicht viele Anweisungen. Mein Agent hat also das gesamte Has Repository durchsucht und versucht, die relevanten Dateien zu finden, indem er Ordner um Ordner durchsucht hat. Er hat genau die richtige Datei gefunden, die geändert werden muss, und zwei Ansätze für die Änderungen vorgeschlagen. Und tatsächlich war das ein ursprüngliches Problem. Mal sehen, wo es ist. Ja, das war ein ursprüngliches Problem, das von einem meiner Kollegen gemeldet wurde. Und er schlug auch vor, Änderungen an derselben Datei vorzunehmen. Er weiß also im Großen und Ganzen, wie diese Codebasis funktioniert. Also gut, zurück zu den Folien. Dieser Agent. Wir haben also den Prototyp funktioniert. Vielleicht können wir noch ein paar Anpassungen vornehmen. Vielleicht können wir eine kürzere Eingabeaufforderung einführen. Natürlich können wir viele Iterationen dieser ersten Implementierung durchführen. Aber um diesen Prototyp in die Produktion zu bringen, benötigen wir einen weiteren das Deployment. Und dafür haben wir in haststack eine Lösung namens Hooks. Hooks ist ein Tool zum Bereitstellen und bedienen von Haststack Pipelines Zeilen als Rest APIs. Im Grunde vereinfacht es das Umschließen von Pipelines mit benutzerdefinierter Logik und deren Bereitstellung als HTTP Endpunkte. Unter diesen Endpunkten finden Sie auch OpenAI kompatible Chat Abschlussendpunkte, die sehr praktisch sind, wenn Sie Ihre Anwendung mit einer Benutzeroberfläche wie OpenWeb UI verbinden möchten. Außerdem ist die schnellere API Dokumentation enthalten. Diese werden wir also auch verwenden. Kehren wir also zu unserer Demo zurück und stellen diesen Agenten bereit. OK OK. Ich lege zunächst in diesem Bereitstellungsordner meinen Pipeline Wrapper an. Dieser Pipeline Wrapper fungiert als Händler zwischen meiner Pipeline und dem HTTP Endpunkt. Und hier führe ich einfach dieselbe Pipeline aus. Ich rufe die Ausführungsmethode meiner Pipeline in diesem Pipeline Wrapper auf und hier definiere ich, dass dieser Endpunkt eine URL im Stringformat akzeptieren und auch einen String ausgeben soll. Und so implementiere ich auch meine Run API Methode. Das ist alles, was ich brauche, um diese Agent Pipeline bereitzustellen. Jetzt muss ich meinen Hook Server starten. Ich rufe also Hey Hooks run auf. OK. Es zeigt mir an, dass mein Server auf meinem lokalen Host 1416 läuft. Jetzt gehe ich zu einem anderen Terminal und stelle das bereit. Um das bereitzustellen, rufe ich Hey Hooks Pipeline Files auf. Dann lege ich das Verzeichnis fest, in dem mein Pipeline Wrapper liegt und dann gebe ich einen Namen ein, meinen Endpunkt, also stellen wir es bereit. OK, jetzt wird angezeigt, dass es erfolgreich bereitgestellt wurde. Gehen wir also zurück und suchen das. Suchen Sie meinen Swagger. Ja, er ist hier. Sie sehen also alle Endpunkte, die ich gerade habe. Aber was mich mehr interessiert, ist dieser hier, dieser GitHub Agent Run. Das wird mein Endpunkt für meinen Agenten. Ich werde mir hier ein weiteres Problem suchen, ein echtes. Es geht darum, die Funktionalität der Dokumentenbereinigungskomponente in hassteck zu erweitern. Sie hat diese Beschreibung von einem anderen Kollegen und einen weiteren Kommentar. Ich habe also eine Replikation desselben Problems unter meinem Hashtag Fork erstellt, nur um die Diskussion im Hauptrepository nicht zu beeinträchtigen, da ich direkt im GitHub Repo kommentiere. Also gut, kopieren wir die URL, gehen wir zu unserem Swagger und fügen sie hier ein und dann führen wir es aus. Und was ich hier mache ist, dass es eine Uhr ist, eine Art Benutzeroberfläche für mich, aber ich hätte es auch nur mit der Curl Anfrage machen können. Da ich jetzt einen Webserver auf meinem Laptop habe, kann ich mich ganz einfach mit meinem Agenten verbinden und ihn außerhalb meiner IDE, beispielsweise außerhalb meines Python Notebooks ausführen. Alles klar, hier wird es wieder geladen. Wenn ich aber zu meinem Server gehe, wo ich Hooks Run gestartet habe, sehe ich wieder die Protokolle. Im Moment sehe ich nur die laufenden Komponenten. Das ging zwar sehr schnell, aber ich gehe die Protokolle noch einmal durch. Hier sehe ich also alle laufenden Komponenten. Ich hätte aber noch ein paar Änderungen an meiner Pipeline vornehmen und die ein und Ausgaben für jede Komponente in meiner Pipeline sehen können. Das ist sehr praktisch beim Debuggen oder wenn man diese Pipeline an einen Tracer Wheelreis anschließt. Man sieht die Ein und Ausgaben, was sehr hilfreich ist, wenn man beispielsweise versucht, einen Fehler zu überwachen oder zu debuggen. OK, gehen wir zurück. Hier in Swagger Dogs sehe ich wieder einen Erfolg und den Kommentar, wenn ich hier zum Problem gehe, nicht zu diesem oder vielleicht muss ich aktualisieren. Ja, hier werden also im Grunde wieder einige Schritte zur Lösung des Problems bereitgestellt. Ja, wir haben nicht viel Zeit, um zu testen, ob diese Kommentare oder Code Snippets korrekt funktionieren. Aber wenn Sie Interesse haben, können wir uns nach dem Vortrag am Stand Tisch 9 treffen und testen, ob die agentengenerierten Code Snippets wirklich funktionieren. OK, es ging also um die Bereitstellung des Agenten und dessen Erstellung mit haststack. Und es gibt noch eine weitere Möglichkeit, die ich Ihnen zeigen möchte. Ein weiteres Tool in unserer haststack Umgebung ist deepset Studio. Es ist kostenlos und für alle zugänglich. Wir nennen es eine Entwicklungsumgebung für huststack. Im Grunde hätte ich alles, was wir in dieser Präsentation gezeigt haben, auch visuell umsetzen können. Es ist eine Art Plattform, auf der ich meine Pipeline definiere und visuell per Drag und Drop erstelle. Sobald ich mit meiner Pipeline fertig bin, sehen Sie, dass sie aufgrund der Verbindungen und Komponenten sehr komplex werden kann. Ich muss nur auf die Schaltfläche Deploy klicken und meine Pipeline wird auf der Plattform bereitgestellt. Anschließend kann ich im Playground die Abfrage direkt ausführen. Mit Daumen hoch, Daumen runter kann ich Feedback sammeln. Ich kann es auch mit anderen Stakeholdern teilen und Feedback sammeln. Basierend auf diesem Feedback kann ich meine Pipeline möglicherweise iterieren. Sobald die gesamte Implementierung abgeschlossen ist, kann ich den Code einfach im Y oder Python Format exportieren und ihn mit Hilfe von Hooks an anderer Stelle bereitstellen. Ich muss nicht an diese Plattform gebunden sein. Ich muss nicht alles auf dieser Plattform speichern. Ich kann diese Plattform nutzen, um meine Anwendung zu entwickeln, ohne den vollständigen Python-Code schreiben zu müssen. Und ihn dann exportieren, um ihn an anderer Stelle zu verwenden. Sie sehen, der erste QR Code auf der linken Seite führt Sie zur haststack Website. Dort finden Sie Links zu unseren Tutorials, Beispielen und auch den Link zur Anmeldung für Deep Set Studio. Der andere ist für die Demo, die ich Ihnen gerade gezeigt habe. Der gesamte code ist auf GitHub verfügbar. Sie können es ausprobieren und auch offene Probleme oder vielleicht auch versuchen, diese mit dem Agenten zu lösen, den wir hier haben. Danke, dass Sie wieder an dieser Sitzung teilnehmen. Ich weiß nicht, ob Sie Zeit haben oder fragen, aber ich denke, wir können diese Zeit auch nutzen. Danke, Wir haben Zeit für eine Frage. Wer ist dran? Bitte. So haben Sie also gesehen, wie einfach es das Problem automatisch löst, Richtig. Ich denke, der komplexe Teil bestand darin, wie das Modell die gesamte Komplexität des Repositories erfasst hat. Wenn das Repository Millionen von Codezeilen umfasst.

Ja, wie sieht es mit diesem Teil aus? Dann sollten Sie versuchen, es in Module aufzuteilen und Ihren LLM entsprechend anzuweisen. Klassifizieren Sie das Problem, sodass Sie sagen kö OK, wenn es bei diesem Problem um die Generierung von Einbettungen geht, sehen Sie sich nur diesen Teil des Repositories an. Das kann ein Ansatz sein, aber genau das kann der Engpass dieser Anwendung sein. Wenn Ihr Repository, Ihre Codebasis sehr groß ist und Ihre Datei möglicherweise sehr tief in Ihrer Codebasis liegt, wird Ihr Agent eine umfangreiche Suche durchführen, um das zu durchsuchen und das wird sehr zeitaufwendig sein. Ja, vielen Dank, Pilk. Falls Sie mehr erfahren möchten.