Zur Lösung dieses Problems wenden Suchmaschinen wie Elasticsearch zwei wesentliche Optimierungsstrategien an:

1. Ungefähre Suche (Hierarchical Navigable Small World [HNSW]): Anstatt jedes Dokument zu durchsuchen, erstellen wir einen Navigationsgraphen, um schnell in die wahrscheinliche Nachbarschaft der Antwort zu gelangen.

2. Quantisierung: Wir komprimieren die Vektoren (beispielsweise von 32-Bit-Gleitkommazahlen auf 8-Bit-Ganzzahlen oder sogar auf 1-Bit-Binärwerte), um den Speicherbedarf zu verringern und die Berechnungen zu beschleunigen.

Doch Optimierung hat oft ihren Preis: Genauigkeit.

Die Befürchtung ist berechtigt: „Wenn ich meine Daten komprimiere und bei der Suche Abstriche mache, verpasse ich dann die besten Ergebnisse?“ „Beeinträchtigt diese Optimierung die Relevanz meiner Suchmaschine?“

Für den Nachweis, dass die Quantisierung von Elastic die Ergebnisse nicht beeinträchtigt, haben wir einen wiederholbaren Testrahmen unter Verwendung des DBPedia-14-Datensatzes entwickelt, um präzise zu berechnen, wie viel Genauigkeit (genauer gesagt Recall) wir bei der Verwendung der Standardoptimierungen in Elasticsearch zugunsten der Geschwindigkeit einbüßen.

Kurz gesagt: Viel weniger, als Sie denken. Sehen Sie sich das Notebook hier an und testen Sie es selbst

Die Definitionen (für die Nicht-Experten)

Klären wir zunächst einige Begriffe, bevor wir uns den Code ansehen.

• Relevanz vs. Recall: Relevanz ist subjektiv (habe ich etwas Gutes gefunden?). Recall ist mathematisch. Wenn sich in der Datenbank 10 Dokumente befinden, die perfekt zu Ihrer Abfrage passen, und die Suchmaschine neun davon findet, beträgt Ihr Recall 90 % (oder 0,9).

• Exakte Suche (flach): Wird auch als „Brute-Force“-Methode bezeichnet. Die Suchmaschine scannt jedes einzelne Dokument in einem Index und berechnet die Entfernung.

  • Vorteile: 100 % perfekter Recall.

  • Nachteile: Rechenintensiv und bei großem Umfang langsam.

• Näherungssuche (HNSW): Die „Abkürzungs“-Methode. Die Suchmaschine erstellt einen HNSW-Graphen. Sie durchläuft den Graphen, um die nächsten Nachbarn zu finden.

  • Vorteile: Extrem schnell und skalierbar.

  • Nachteile: Falls das Durchlaufen des Graphen zu früh beendet wird, könnte ein Nachbar übersehen werden.

Das Experiment: Exakt vs. ungefähr

Für den Recall-Test haben wir den DBPedia-14-Datensatz verwendet, einen umfangreichen Datensatz mit Titeln und Auszügen aus 14 Ontologieklassen, der häufig zum Trainieren und Bewerten von Modellen zur Textkategorisierung genutzt wird. Konkret konzentrieren wir uns auf die Kategorie „Film“. Wir wollten die optimierten Produktionseinstellungen mit einem mathematisch perfekten Referenzwert vergleichen.

Für dieses Experiment verwenden wir das Modell jina-embeddings-v5-text-small, ein fortschrittliches mehrsprachiges Modell, das bei den Branchen-Benchmarks für Textdarstellung führend ist. Wir haben uns für dieses Modell entschieden, da es den aktuellen Standard für leistungsstarke Einbettungen setzt. Durch die Kombination der herausragenden Genauigkeit von Jina v5 mit der nativen Quantisierung von Elasticsearch können wir eine Sucharchitektur präsentieren, die sowohl rechnerisch effizient ist als auch keine Kompromisse bei der Abrufqualität eingeht.

Wir haben einen Index mit doppeltem Mapping eingerichtet. Wir haben denselben Text gleichzeitig in zwei verschiedene Felder aufgenommen:

1. content.rawmit Typ: flat. Dadurch wird Elasticsearch gezwungen, einen Brute-Force-Scan der gesamten Float32-Vektoren durchzuführen. Hierdurch werden exakte Übereinstimmungen geliefert, die als Ausgangsbasis dienen.

2. contentmit Typ semantic_text. Standardmäßig werden HNSW und „Better Binary Quantization“ (BBQ) verwendet. Hierbei handelt es sich um die standardmäßige, optimierte Produktionseinstellung für die ungefähre Übereinstimmung.

Der Recall @10-Test

Als Metrik verwendeten wir Recall@10.

Wir haben 50 zufällige Filme ausgewählt und dieselbe Abfrage für beide Felder durchgeführt.

• Wenn die exakte (flache) Suche ergibt, dass die ersten 10 Nachbarn IDs [1, 2, 3 ... 10] sind.

• Und die ungefähre (HNSW) Suche liefert die IDs [1, 2, 3 ... 9, 99].

• Wir haben neun der Top 10 korrekt gefunden. Der Score liegt bei 0,9.

Hier ist das von uns verwendete Mapping:

Das Ergebnis: Die „flache Kurve“ des Erfolgs

Wir haben einen Skalierungstest durchgeführt, bei dem wir den gesamten Datensatz neu geladen und mit Indexgrößen von 1.000 bis 40.000 Dokumenten getestet haben.

So hat sich der Recall-Score entwickelt:

Dokumente

Recall@10-Wert

1.000

1.000 (100 %)

5.000

0,998 (100 %)

10.000

0,992 (99,4 %)

20.000

0,999 (99,0 %)

40.000

0,992 (98,8 %)

Die Ergebnisse waren erstaunlich stabil. Selbst als wir die Skalierung erhöhten, stimmte die ungefähre Suche in >99 % der Fälle mit der exakten Brute-Force-Suche überein.

Warum hat es so gut funktioniert?

Sie könnten erwarten, dass die Komprimierung von Vektoren zu Binärwerten die Genauigkeit stärker beeinträchtigen würde. Der Grund dafür liegt in der Art und Weise, wie Elasticsearch den Abruf handhabt.

Die meisten Einbettungsmodelle liefern heutzutage Float32-Vektoren als Ausgabe, die sehr groß sind. Für eine effiziente Suche nutzt Elasticsearch die Quantisierung für hochdimensionale Vektoren. Genauer gesagt wird seit Version 9.2 standardmäßig BBQ verwendet.

BBQ verwendet einen Rescoring-Mechanismus:

1. Durchlaufen: Die Suchmaschine verwendet die komprimierten (quantisierten) Vektoren, um den HNSW-Graphen schnell zu durchlaufen. Da die Vektoren klein sind, kann das System effizient überabtasten und so eine größere Liste von Kandidaten (zum Beispiel die 100 am ehesten passenden Dokumente) ohne Leistungseinbußen zusammenstellen.

2. Rescore: Sobald diese Kandidaten vorliegen, ruft das System die Werte in voller Genauigkeit nur für diese wenigen Dokumente ab, um das endgültige, genaue Ranking zu berechnen.

So erhalten Sie das Beste aus beiden Welten: die Geschwindigkeit der Quantisierung für die rechenintensiven Aufgaben und die Präzision von Gleitkommazahlen für die abschließende Sortierung.

Können wir das besser machen?

An dieser Stelle ist anzumerken, dass die hier gezeigten Ergebnisse auf den Standardeinstellungen und einer zufälligen Stichprobe von Daten basieren. Betrachten Sie das als einen leistungsstarken Ausgangspunkt. Auch wenn Jina v5 ein wahres Kraftpaket ist, sind diese Recall-Werte keine allgemeingültige Garantie für jeden Datensatz. Jede Datenerhebung hat ihre Eigenheiten, und obwohl es durchaus möglich ist, die Leistung durch weitere Optimierungen weiter zu steigern, sollten Sie stets einen Vergleichstest mit Ihren eigenen spezifischen Daten durchführen, um Ihre Leistungsgrenze zu ermitteln.

Fazit

Es handelt sich hierbei um einen sehr kleinen Test. Der Zweck dieser Übung besteht jedoch nicht speziell in der Messung des Einbettungsmodells oder von BBQ, sondern vielmehr in der Veranschaulichung, wie Sie mit minimalem Aufwand den Recall Ihres Datensatzes messen können.

Wenn Sie diesen Test mit Ihren eigenen Daten durchführen möchten, können Sie sich das Notebook hier ansehen und es selbst testen.

Stellen Sie sich einen Finanzmanager vor, der sich vor einem Kundengespräch schnell einarbeiten muss. Statt manuell Newsfeeds zu durchforsten und Portfolio-Dashboards abzugleichen, können sie ihrem individuell entwickelten Agenten jetzt einfach eine direkte Frage stellen. Das ist der Vorteil eines „Chat-First“-Ansatzes. Der Manager hat einen direkten, dialogorientierten Draht zu seinen Daten und fragt beispielsweise: „Was gibt es Neues zu ACME Corp und wie wirkt sich das auf die Anlagen meines Kunden aus?“ und innerhalb von Sekunden eine zusammengefasste Expertenantwort zu erhalten.

Während wir heute einen Finanzexperten aufbauen, sind die Anwendungsbereiche so vielfältig wie Ihre Daten. Mit der gleichen Macht kann ein Cybersicherheitsanalyst zur Suche nach Bedrohungen, ein Site Reliability Engineer zur Diagnose eines Ausfalls oder ein Marketingmanager zur Optimierung einer Kampagne geschaffen werden. Unabhängig vom Fachgebiet bleibt die Kernmission dieselbe: Ihre Daten in einen Spezialisten zu verwandeln, mit dem Sie sich unterhalten können.

Schritt 0: Unser Datensatz

Unser heutiger Datensatz ist ein synthetischer, auf Finanzdaten basierender Datensatz, der aus Finanzkonten, Vermögenspositionen, Nachrichten und Finanzberichten besteht. Er ist zwar synthetisch, repliziert aber eine vereinfachte Version eines realen Finanzdatensatzes.

financial_accountsKundenportfolios mit Risikoprofilen

financial_holdings: Aktien-/ETF-/Anleihenpositionen mit Kaufhistorie

financial_asset_detailsDetails zur Aktie/zum ETF/zur Anleihe

financial_news: KI-generierte Marktartikel mit Stimmungsanalyse

financial_reportsUnternehmensgewinne und Analystennotizen

Sie können diesen Datensatz selbst laden, indem Sie der beigefügten Anleitung in diesem Notebook folgen.

Schritt 1: Die Grundlage – Ihre Geschäftslogik als ES|QL

Jede KI-Fähigkeit beginnt mit einer soliden Logik. Unserem Financial Manager-Agenten müssen wir beibringen, wie er eine häufig gestellte Frage beantworten kann: „Ich bin besorgt über die Marktstimmung.“ Können Sie mir zeigen, welche unserer Kunden am stärksten von schlechten Nachrichten bedroht sind? Diese Frage geht über eine einfache Suche hinaus. Dies erfordert von uns, die Marktstimmung mit den Kundenportfolios in Zusammenhang zu bringen.

Wir müssen die in den negativen Artikeln erwähnten Vermögenswerte finden, jeden Kunden identifizieren, der diese Vermögenswerte hält, den aktuellen Marktwert seines Engagements berechnen und dann die Ergebnisse nach dem höchsten Risiko ordnen. Diese komplexe Analyse mit mehreren Verknüpfungen ist die perfekte Aufgabe für unser hochentwickeltes ES|QL-Tool.

Hier ist die vollständige Abfrage, die wir verwenden werden. Es sieht beeindruckend aus, aber die Konzepte sind einfach.

Aufschlüsselung: Verbindungen und Leitplanken

Bei dieser Abfrage spielen zwei wichtige Konzepte eine Rolle, die den Agent Builder ausmachen.

1. Die LOOKUP JOIN-Funktion

Seit Jahren gehört die Möglichkeit, Daten aus verschiedenen Indizes anhand eines gemeinsamen Schlüssels zu verknüpfen, zu den am häufigsten nachgefragten Funktionen von Elasticsearch. Mit ES|QL ist das jetzt mit LOOKUP JOIN möglich.

In unserer neuen Abfrage führen wir eine Kette von drei LOOKUP JOIN durch: Zuerst verbinden wir negative Nachrichten mit Vermögensdetails, dann verknüpfen wir diese Vermögenswerte mit den Kundenbeständen und schließlich fügen wir sie zu den Kontoinformationen des Kunden hinzu. Dadurch wird mit einer einzigen, effizienten Abfrage ein unglaublich reichhaltiges Ergebnis aus vier verschiedenen Indizes erzeugt. Das bedeutet, dass wir unterschiedliche Datensätze kombinieren können, um eine einzige, aussagekräftige Antwort zu erhalten, ohne vorher alle unsere Daten in einen einzigen riesigen Index denormalisieren zu müssen.

2. Parameter als LLM-Leitplanken

Sie werden feststellen, dass die Abfrage ?time_duration verwendet. Das ist nicht nur eine Variable; es ist eine Leitplanke für die KI. Während große Sprachmodelle (LLMs) hervorragend darin sind, Abfragen zu generieren, kann es zu ineffizienten oder sogar falschen Abfragen führen, wenn man ihnen freie Hand bei der Daten lässt.

Durch die Erstellung einer parametrisierten Abfrage zwingen wir das LLM dazu, innerhalb der getesteten, effizienten und korrekten Geschäftslogik zu arbeiten, die ein menschlicher Experte bereits definiert hat. Das ist vergleichbar damit, wie Entwickler seit Jahren Suchvorlagen verwenden, um Abfragefunktionen sicher für Anwendungen bereitzustellen. Der Agent kann eine Benutzeranfrage wie "diese Woche" interpretieren, um den Parameter time_duration zu füllen, muss aber unsere Abfragestruktur verwenden, um die Antwort zu erhalten. Dadurch erhalten wir die perfekte Balance zwischen Flexibilität und Kontrolle.

Letztendlich ermöglicht diese Abfrage einem Experten, der die Daten versteht, sein Wissen in einem Werkzeug zu kapseln. Andere Personen – und KI-Agenten – können dieses Werkzeug dann nutzen, um korrelierte Ergebnisse zu erhalten, indem sie einfach einen einzigen Parameter angeben, ohne etwas über die zugrunde liegende Komplexität wissen zu müssen.

Schritt 2: Die Fertigkeit – Eine Abfrage in ein wiederverwendbares Werkzeug umwandeln

Eine ES|QL-Abfrage ist nur Text, bis wir sie als Werkzeug registrieren. Im Agent Builder ist ein Tool mehr als nur eine gespeicherte Abfrage; es ist eine „Fähigkeit“, die ein KI-Agent verstehen und einsetzen kann. Der Zauber liegt in der von uns bereitgestellten Beschreibung in natürlicher Sprache . Diese Beschreibung bildet die Brücke zwischen der Frage eines Benutzers und der zugrunde liegenden Abfragelogik. Registrieren wir nun die soeben erstellte Abfrage.

Der UI-Pfad

Das Erstellen eines Tools in Kibana ist ein unkomplizierter Prozess.

1. Navigieren Sie zu Agenten

• Klicken Sie auf „Tools“oder „Tools verwalten“ und klicken Sie dann auf die Schaltfläche „Neues Tool“ .

2. Füllen Sie das Formular mit folgenden Angaben aus:

• Werkzeug-ID: find_client_exposure_to_negative_news

ich. Dies ist die eindeutige ID des Tools.

• Beschreibung: "Ermittelt das Risiko negativer Nachrichten im Kundenportfolio." Dieses Tool durchsucht aktuelle Nachrichten und Berichte nach negativen Stimmungen, identifiziert den zugehörigen Vermögenswert und findet alle Kunden, die diesen Vermögenswert halten. Es liefert eine nach dem aktuellen Marktwert der Position sortierte Liste zurück, um das höchste potenzielle Risiko hervorzuheben.“

ich. Dies ist das, was der LLM liest, um zu entscheiden, ob dieses Werkzeug das richtige für die Aufgabe ist.

• Labels: retrieval and risk-analysis

Etiketten dienen dazu, mehrere Werkzeuge zu gruppieren.

• Konfiguration: Fügen Sie die vollständige ES|QL-Abfrage aus Schritt 1 ein.

ich. Dies ist die Suche, die der Agent verwenden wird.

3. Klicken Sie auf „Parameter aus Abfrage ableiten“. Die Benutzeroberfläche wird ?time_duration automatisch finden und unten auflisten. Fügen Sie für jedes Element eine kurze Beschreibung hinzu, damit der Agent (und andere Benutzer) dessen Zweck verstehen können.

• time_durationDer Zeitraum, in dem nach negativen Nachrichten gesucht wird. Format ist "X Stunden", Standardwert: 8760 Stunden

4. Probier es aus!

• Klicken Sie auf Speichern & Testen.

• Es wird ein neues Flyout angezeigt, in dem Sie die Abfrage testen können, um sicherzustellen, dass sie wie erwartet funktioniert.

ich. Geben Sie in time_duration den gewünschten Bereich ein, hier verwenden wir „8760 Stunden“.

• Klicken Sie auf „Absenden“, und wenn alles gut geht, erhalten Sie eine JSON-Antwort. Um sicherzustellen, dass es wie erwartet funktioniert, scrollen Sie nach unten und sehen Sie sich das Objekt values an. Dort werden die eigentlichen übereinstimmenden Dokumente zurückgegeben.

5. Klicken Sie auf das „X“ oben rechts, um das Testfenster zu schließen. Ihr neues Tool wird nun in der Liste angezeigt und kann einem Agenten zugewiesen werden.

Der API-Pfad

Für Entwickler, die Automatisierung bevorzugen oder Tools programmatisch verwalten müssen, lässt sich dasselbe Ergebnis mit einem einzigen API-Aufruf erzielen. Senden Sie einfach eine POST -Anfrage an den /api/agent_builder/tools -Endpunkt mit der Definition des Tools.

Schritt 3: Das Gehirn – Ihren individuellen Agenten erstellen

Wir haben eine wiederverwendbare Fähigkeit entwickelt (das Tool). Nun müssen wir den Agenten erstellen, die Persona, die es tatsächlich benutzen wird. Ein Agent ist die Kombination aus einem LLM, einem bestimmten Satz von Werkzeugen, zu denen Sie ihm Zugriff gewähren, und vor allem einer Reihe von benutzerdefinierten Anweisungen , die als seine Verfassung fungieren und seine Persönlichkeit, Regeln und seinen Zweck definieren.

Die Kunst des Prompts

Der wichtigste Aspekt bei der Schaffung eines zuverlässigen, spezialisierten Agenten ist die Pünktlichkeit. Eine gut ausgearbeitete Anleitung macht den Unterschied zwischen einem generischen Chatbot und einem zielgerichteten, professionellen Assistenten aus. Hier legen Sie die Leitplanken fest, definieren die Ausgabe und geben dem Agenten seine Mission.

Für unseren Financial Manager -Agenten verwenden wir die folgende Eingabeaufforderung.

Lassen Sie uns genauer betrachten, warum diese Aufforderung so effektiv ist:

• Es definiert eine anspruchsvolle Persönlichkeit: Schon die erste Zeile stellt den Agenten als „spezialisierten Data Intelligence Assistant“ dar und vermittelt so einen professionellen und kompetenten Eindruck.

• Es bietet einen Denkrahmen: Indem wir dem Agenten sagen, er solle "Verstehen, Planen, Ausführen und Synthetisieren", geben wir ihm eine Standardarbeitsanweisung. Dadurch wird seine Fähigkeit verbessert, komplexe, mehrstufige Fragen zu beantworten.

• Es fördert den interaktiven Dialog: Die Anweisung, „klärende Fragen zu stellen“, macht den Agenten widerstandsfähiger. Dadurch werden Fehlinterpretationen bei mehrdeutigen Anfragen minimiert, was zu genaueren Antworten führt.

Der UI-Pfad

1. Navigieren Sie zu Agenten.

• Klicken Sie auf „Tools“oder „Tools verwalten“ und klicken Sie dann auf die Schaltfläche „Neues Tool“ .

2. Füllen Sie die grundlegenden Angaben aus:

• Agenten-ID: financial_assistant.

• Anleitung: Kopieren Sie die obige Eingabeaufforderung.

• Labels: Finance.

• Anzeigename: Financial Assistant.

• Anzeigebeschreibung: An assistant for analyzing and understanding your financial data.

3. Klicken Sie oben auf „Tools“.

• Setzen Sie ein Häkchen neben unserem find_client_exposure_to_negative_news -Tool.

4. Klicken Sie auf Speichern.

Der API-Pfad

Sie können denselben Agenten mit einer POST -Anfrage an den /api/agent_builder/agents -Endpunkt erstellen. Der Anfragetext enthält dieselben Informationen: die ID, den Namen, die Beschreibung, die vollständigen Anweisungen und eine Liste der Tools, die der Agent verwenden darf.

Schritt 4: Der Lohn – Ein Gespräch führen

Unsere Geschäftslogik ist in einem Tool gekapselt und ein "Gehirn" ist bereit, es in unserem Agenten zu verwenden. Jetzt wird es Zeit, dass alles zusammenkommt. Wir können nun mithilfe eines spezialisierten Agenten mit unseren Daten kommunizieren.

Der UI-Pfad

1. Navigieren Sie in Kibana zu „Agenten“ .

2. Wechseln Sie mithilfe des Dropdown-Menüs unten rechts im Chatfenster vom standardmäßigen Elastic AI Agent zu unserem neu erstellten Financial Assistant Agent.

3. Stellen Sie eine Frage, die es dem Agenten ermöglicht, unser Spezialtool zu nutzen:

   1. Ich bin besorgt über die Marktstimmung. Können Sie mir zeigen, welche unserer Kunden am stärksten von schlechten Nachrichten betroffen sein könnten?

Nach kurzer Zeit liefert der Agent eine perfekt formatierte, vollständige Antwort. Aufgrund der Beschaffenheit von LLMs kann Ihre Antwort etwas anders formatiert sein, aber für diesen Durchlauf hat der Agent Folgendes zurückgegeben:

Was ist gerade passiert? Die Argumentation des Agenten

Der Agent kannte die Antwort nicht einfach nur. Es wurde ein mehrstufiger Plan umgesetzt, dessen Mittelpunkt die Auswahl des besten Werkzeugs für die jeweilige Aufgabe bildete. Hier ein Einblick in den Denkprozess:

• Identifizierte Absicht: Es wurden Schlüsselwörter aus Ihrer Frage, wie „Risiko“ und „negative Nachrichten“, mit der Beschreibung des find_client_exposure_to_negative_news -Tools abgeglichen.

• Plan ausgeführt: Es hat den Zeitrahmen aus Ihrer Anfrage extrahiert und einen einzigen Aufruf an dieses spezialisierte Tool durchgeführt.

• Die Arbeit wurde delegiert: Das Tool übernahm dann die gesamte schwere Arbeit: die verketteten Joins, die Wertberechnungen und die Sortierung.

• Ergebnis zusammengefasst: Abschließend formatierte der Agent die Rohdaten des Tools gemäß den Vorgaben in eine klare, für Menschen lesbare Zusammenfassung.

Und wir müssen nicht nur raten, wenn wir unser Denken erweitern und mehr Details betrachten.

Der API-Pfad

Sie können diese Konversation auch programmatisch starten. Senden Sie einfach die Eingabefrage an den converse API-Endpunkt und achten Sie darauf, die agent_id unseres financial_manager anzugeben.

Für Entwickler: Integration mit der API

Während die Kibana-Benutzeroberfläche ein fantastisches und intuitives Erlebnis beim Erstellen und Verwalten Ihrer Agenten bietet, kann alles, was Sie heute gesehen haben, auch programmatisch erreicht werden. Der Agent Builder basiert auf einer Reihe von APIs, die es Ihnen ermöglichen, diese Funktionalität direkt in Ihre eigenen Anwendungen, CI/CD-Pipelines oder Automatisierungsskripte zu integrieren.

Die drei wichtigsten Endpunkte, mit denen Sie arbeiten werden, sind:

• /api/agent_builder/tools: Der Endpunkt zum Erstellen, Auflisten und Verwalten der wiederverwendbaren Fähigkeiten, die Ihre Agenten nutzen können.

• /api/agent_builder/agentsDer Endpunkt zur Definition Ihrer Agenten-Personas, einschließlich ihrer wichtigen Anweisungen und Tool-Zuweisungen.

• /api/agent_builder/converse: Der Endpunkt für die Interaktion mit Ihren Agenten, den Start von Gesprächen und das Erhalten von Antworten.

Eine vollständige, praktische Anleitung zur Verwendung dieser APIs für jeden Schritt dieses Tutorials finden Sie im zugehörigen Jupyter Notebook , das hier in unserem GitHub-Repository verfügbar ist.

Fazit: Jetzt sind Sie am Bauen

Wir begannen damit, eine ES|QL-Abfrage zu nehmen und sie in eine wiederverwendbare Fähigkeit umzuwandeln. Anschließend entwickelten wir einen spezialisierten KI-Agenten, gaben ihm eine klare Mission und klare Regeln und statteten ihn mit diesen Fähigkeiten aus. Das Ergebnis ist ein hochentwickelter Assistent, der eine komplexe Frage verstehen und eine mehrstufige Analyse durchführen kann, um eine präzise, datengestützte Antwort zu liefern.

Dieser Workflow ist das Herzstück des neuen Agent Builders in Elastic. Es ist so konzipiert, dass es einfach genug ist, damit auch technisch nicht versierte Benutzer Agenten über die Benutzeroberfläche erstellen können, gleichzeitig aber differenziert genug, damit Entwickler auf Basis unserer APIs maßgeschneiderte KI-gestützte Anwendungen entwickeln können. Am wichtigsten ist jedoch, dass Sie LLMs sicher und geschützt mit Ihren eigenen Daten verbinden können, die von der von Ihnen definierten Expertenlogik gesteuert werden, und mit Ihren Daten kommunizieren können.

Sind Sie bereit, Agenten für die Kommunikation mit Ihren Daten einzusetzen?

Am besten festigt man das Gelernte, indem man selbst Hand anlegt. Probieren Sie alles, was wir heute besprochen haben, in unserem kostenlosen, interaktiven Praxisworkshop aus. Sie werden diesen gesamten Ablauf und mehr in einer speziellen Sandbox-Umgebung durchlaufen.

In einem zukünftigen Blogbeitrag zeigen wir Ihnen, wie Sie eine eigenständige Anwendung verwenden, die mit unserem Financial Assistant -Agenten interagiert, und gehen näher auf das Model Context Protocol (MCP) ein, das dies alles ermöglicht. In einem separaten Blogbeitrag werden wir die Unterstützung des Agent Builders für das sich entwickelnde Agent2Agent- oder A2A-Protokoll besprechen.

Bleibt dran und viel Spaß beim Bauen!