Was ist ein Kibana-Dashboard-Builder?

Wie wäre es, wenn Sie das gewünschte Dashboard in einfachem Englisch beschreiben könnten und es dann mit interaktiven Diagrammen, einem Drag-and-Drop-Layout und einem Export nach Kibana mit einem Klick erscheinen würde?

Genau das macht example-mcp-dashbuilder. Es handelt sich um eine Open-Source-Anwendung (Modellkontextprotokoll (MCP)), die KI-Assistenten mit Elasticsearch verbindet und es Ihnen ermöglicht, vollständige Kibana-Dashboards durch Konversation zu erstellen. Kein Durchklicken durch Menüs. Kein manuelles Schreiben von Visualisierungskonfigurationen. Beschreiben Sie einfach, was Sie benötigen, und die KI untersucht Ihre Daten, schreibt die ES|QL-Abfragen (Elasticsearch Query Language), erstellt die Diagramme und liefert ein lebendiges, interaktives Dashboard – alles im Chatfenster Ihres Editors.

Vom Prompt zum Dashboard in Sekunden

So sieht das in der Praxis aus. Sie geben beispielsweise Folgendes ein:

„Erstellen Sie mir ein Web-Traffic-Dashboard aus logstash-* mit Gesamtanfragen, übertragenen Bytes im Laufe der Zeit, wichtigen geografischen Quellen und einer Aufschlüsselung der Antwortcodes.“

Die KI daraufhin:

1. Erkennt Ihre Daten: Listet Indizes auf, inspiziert Feldzuordnungen.

2. Schreibt ES|QL-Abfragen: Angepasst an Ihr Schema, mit den richtigen Aggregationen.

3. Erstellt Visualisierungen: Balkendiagramme, Liniendiagramme, Metriken mit Sparklines, Heatmaps, Kreisdiagramme.

4. Organisiert alles: Zusammenklappbare Abschnitte, aussagekräftige Titel, ordentliches Layout.

5. Rendert eine interaktive Vorschau: Direkt im Chat, mit Tooltips, einem Zeitwähler und Drag-and-Drop.

Jedes Diagramm wird bei der Erstellung inline angezeigt, sodass Sie den Fortschritt in Echtzeit verfolgen können. Dann zeigt view_dashboard das vollständige Dashboard mit allen Panels, die im 48-spaltigen Raster von Kibana angeordnet sind.

Einzelne Inline-Diagrammvorschau.

Bereitgestellt von ES|QL

Alle Datenabrufe verwenden ES|QL, die Pipe-basierte Abfragesprache von Elasticsearch. Die KI verarbeitet nicht nur rohe Abfragen, sondern nutzt auch integrierte ES|QL-Syntax zusammen mit Informationen zur Struktur Ihrer Daten, um korrekte, effiziente Abfragen für jeden Visualisierungstyp zu schreiben.

Der Server enthält eine umfassende ES|QL-Referenz als MCP-Ressource. Bevor eine Abfrage geschrieben wird, liest die KI diese Referenz, um die verfügbaren Befehle, Funktionen und Muster zu verstehen. In Kombination mit einem Dataviz-Best-Practices-Leitfaden (der auch als Ressource diente) weiß die KI nicht nur, wie sie Abfragen gestaltet, sondern auch, was eine gute Visualisierung ausmacht:

• Verwenden Sie BUCKET(@timestamp, 1 day) für Zeitreihen; gruppieren Sie immer SORT nach dem Zeitfeld.

• Beschränken Sie Kreisdiagramme mit | SORT value DESC | LIMIT 6 auf sechs Abschnitte.

• Wählen Sie Balkendiagramme für Kategorienvergleiche, Liniendiagramme für Trends und Kennzahlen für Leistungsindikatoren (KPI).

KI-gestützte Datenexploration mit ergebnisoffener Analyse

Ein Dashboard zu erstellen, das Sie bereits in Ihrem Kopf entworfen haben, ist das eine. Die Frage lautet: „Was ist an diesem Index interessant?“ und eine brauchbare Antwort zu bekommen, ist das andere. Dafür muss die KI wissen, wie man erkundet, nicht nur, wie man zeichnet.

example-mcp-dashbuilder versendet eine analysis://guidelines-Ressource, die einen strukturierten Explorationsablauf definiert: Daten profilieren, gezielte Aggregationen ausführen, Muster aufzeigen, die es wert sind, untersucht zu werden, Diagramme für die interessantesten Ergebnisse erstellen und Drilldown-Abfragen vorschlagen, die der Nutzer als Nächstes haben könnte. Triggerphrasen wie „Analysiere meine Logs“ oder „Finde Muster in diesem Index“ veranlassen die KI, das Playbook zu lesen, bevor sie irgendetwas anderes tut. So entsteht durch einen offenen Prompt eine zusammenhängende Untersuchung und nicht ein zufälliger Haufen von Diagrammen.

Das Ergebnis: Sie können der KI einen unbekannten Index übergeben und erhalten einen Ausgangspunkt zurück: ein Dashboard sowie eine kurze Liste von Prompts, wie „Das mir aufgefallen, soll ich mir das genauer ansehen?“.

Kibana-Dashboard Export und Import: Ein vollständiger Rundgang

Der Export-/Import-Rundgang ist der Punkt, an dem example-mcp-dashbuilder für Teams, die bereits mit Kibana arbeiten, wirklich nützlich wird. example-mcp-dashbuilder ist etwas Eigenständiges, eine dialogorientierte Dashboard-Oberfläche, die in Ihren Editor integriert ist, aber Ihre Arbeit nicht dort einschließt. Hier erstellte Dashboards können bei Bedarf in Kibana übertragen werden, und bestehende Kibana-Dashboards können umgekehrt zur KI-gestützten Bearbeitung importiert werden.

Nach Kibana exportieren

Wenn Sie mit Ihrem Dashboard zufrieden sind, exportieren Sie es mit einem Befehl:

„Dieses Dashboard nach Kibana exportieren“

Jedes Panel wird als echte Kibana Lens-Visualisierung dargestellt. Die Übersetzung bewahrt:

• ES|QL-Abfragen: Direkt übertragen als Lens ES|QL-Datenquellen.

• Rasterpositionen: Das gleiche 48-Spalten-System, das Kibana verwendet, Ihr Layout sieht also identisch aus.

• Benutzerdefinierte Farben: Serienpaletten, metrische Hintergründe, Heatmap-Farbrampen.

Das Ergebnis ist ein voll funktionsfähiges Kibana-Dashboard. Kein Screenshot. Keine Einbettung. Ein echtes Dashboard, das Sie teilen und in Kibana weiter bearbeiten können.

Kibana-Dashboard und Dashboard im Cursor-Chat nebeneinander.

Aus Kibana importieren

Der Rundgang funktioniert auch in die andere Richtung:

„Importieren Sie das Kibana-Dashboard mit der ID abc-123“

Hierbei wird ein bestehendes Kibana-Dashboard abgerufen, dessen Lens-Visualisierungen in bearbeitbare Diagrammkonfigurationen übersetzt, das Rasterlayout und die Abschnitte beibehalten und alles in example-mcp-dashbuilder geladen. Von dort aus können Sie es mit natürlicher Sprache ändern und erneut exportieren.

Dadurch wird die KI zu einem Mitarbeiter in Ihrem bestehenden Kibana-Workflow, nicht zu einem Ersatz.

Benutzerdefinierte Themen und Farben

Sie wünschen sich ein Dashboard mit Ihrem Branding? Stellen Sie einfach folgende Frage:

„Erstellen Sie ein Dashboard im pinken Design mit benutzerdefinierten Farben"

Jeder Visualisierungstyp unterstützt eine benutzerdefinierte Farbkonfiguration:

• Diagramme: palette akzeptiert ein Array von Hex-Farben für Serien und Segmente.

• Metriken: color legt die Hintergrundfarbe fest.

• Heatmaps: colorRamp definiert den Verlauf von niedrigen zu hohen Werten.

Die KI erkennt Themenwünsche auf natürliche Weise. Sagen Sie „maritimes Design“ und es wählt Blau- und Türkistöne aus. Sagen Sie „Unsere Markenfarben verwenden“ und geben Sie Hexadezimalwerte an, diese werden beim Export in Kibana übernommen.

Ein thematisches Dashboard mit benutzerdefinierten Farben.

Funktionsweise von example-mcp-dashbuilder: MCP-Architektur

example-mcp-dashbuilder basiert auf MCP, dem offenen Standard zur Verbindung von KI-Assistenten mit externen Werkzeugen und Daten. Hier die Architektur im Überblick:

Der MCP-Server stellt 25 Tools bereit, die die KI direkt aufrufen kann, vom Ausführen von ES|QL-Abfragen, dem Exportieren von Dashboards sowie einige interne „App-only“-Tools, die die Inline-Vorschau nutzt, um Daten abzurufen, Layoutänderungen zu speichern und Zeitfelder zu erkennen. Er dient als Ressource für drei Bereiche: Als Leitfaden mit Best Practices für die Datenvisualisierung, als ES|QL-Referenz und als Playbook für die Tiefenanalyse, das bei offenen Prompts („Analysiere meine Logs“, „Was ist in diesem Index interessant?“) zum Einsatz kommt. Er wird entweder über stdio oder HTTP ausgeführt, der HTTP-Transport unterstützt streamfähige Antworten und Sitzungsmanagement, sodass mehrere Clients mit einem Server verbunden werden können.

Die MCP-App dient als interaktive Vorschau. Sie basiert auf React, Elastic Charts und Elastic UI, gebündelt in einer einzigen, eigenständigen HTML-Datei. Wenn die KI view_dashboard aufruft oder ein Diagramm erstellt, rendert der Host dieses HTML in einem Sandbox-iframe. Die App kommuniziert vollständig über das MCP Apps-Protokoll mit dem Server und nutzt callServerTool() über postMessage, um Daten abzurufen, Layouts zu speichern und Zeitfelder zu erkennen. Es gibt keinen lokalen Server, keinen Port zum Konfigurieren, keine externe Netzwerkabhängigkeit.

Das bedeutet, dass es mit jedem MCP-kompatiblen Client funktioniert: Cursor, Claude Desktop, Claude.ai, VS Code mit Copilot und mehr.

Welche Diagrammtypen unterstützt example-mcp-dashbuilder?

Zum Zeitpunkt der Erstellung dieses Artikels werden sechs Diagrammtypen unterstützt, die die gängigsten Dashboard-Szenarien abdecken:

Typ

Am besten für

Beispiel

Balkendiagramm

Kategorien vergleichen

Anfragen nach geografischer Quelle

Liniendiagramm

Trends im Laufe der Zeit

Pro Stunde übertragene Bytes

Bereich

Volumen im Laufe der Zeit

Volumen der Anfrage im Laufe der Zeit

Kreisdiagramm

Teil des Ganzen (maximal sechs Stücke)

Verteilung von Antwortcodes

Metrik

Einzelner KPI mit Sparkline

Gesamtzahl der Anfragen mit stündlichem Trend

Heatmap

Muster in zwei Dimensionen

Anfragen nach Wochentag und Stunde

Die Dashboards unterstützen ausklappbare Abschnitte zur besseren Übersicht, eine Zeitauswahl mit automatischer Zeitfelderkennung sowie die Möglichkeit, mehrere Dashboards zu speichern und zwischen ihnen zu wechseln. Parallele Chat-Sitzungen bleiben durch einen dashboardId-Thread, der bei jedem Tool-Aufruf durchlaufen wird, voneinander isoliert.

Installation und Ausführung von example-mcp-dashbuilder

example-mcp-dashbuilder ist Open-Source und sofort einsatzbereit. Sie benötigen Node.js 22+, eine Elasticsearch-Instanz (lokal oder Elastic Cloud) und einen MCP-kompatiblen Client.

Claude Desktop: Laden Sie die neueste .mcpb von GitHub Releases herunter und klicken Sie doppelt darauf. Claude Desktop fordert Sie zur Eingabe Ihrer Elasticsearch-Zugangsdaten auf.

Cursor / Claude Code / VS Code Copilot: Richten Sie Ihre MCP-Konfiguration auf den veröffentlichten Tarball – kein Klon, kein npm install:

Legen Sie ES_NODE, ES_API_KEY (oder ES_USERNAME / ES_PASSWORD) und KIBANA_URL als Umgebungsvariablen fest. Wenn Sie lieber von der Quelle aus arbeiten möchten, klonen Sie das Repository und führen Sie npm run setup als interaktiven Assistenten aus, der Elasticsearch lokal sowie Elastic Cloud (Cloud ID + API-Schlüssel) verwaltet.

Beginnen Sie mit der Entwicklung:

„Erkunden Sie den Log-Index und erstellen Sie mir ein möglichst aussagekräftiges Dashboard.“

Die KI übernimmt dann den Rest. 😉

Roadmap: Die Zukunft von example-mcp-dashbuilder

Dies ist eine frühe Version, die wir aktiv weiter entwickeln. Dies sind einige Bereiche, auf die wir uns konzentrieren:

• Weitere Diagrammtypen: Gauge, Donut, Treemap, Datentabelle und Tag Cloud, passend zu den vollständigen Funktionen von Lens.

• Dashboards auf Git pushen: Schreiben Sie Dashboard-Konfigurationen in ein Repository für Versionskontrolle und Code-Review-Workflows.

• Verbesserte Fehlerbehandlung: Detaillierteres Feedback, wenn ES|QL-Abfragen fehlschlagen, mit Vorschlägen für allgemeine Problemlösungen.

• Effektivere Analyseströme: Erweiterung des Deep-Analysis-Playbooks, um mehr Datenformen (Logs, Metriken, Traces) abzudecken.

Wir würden uns freuen zu erfahren, was Sie damit entwickeln. Probieren Sie es aus, melden Sie Probleme und lassen Sie uns wissen, welche Visualisierungen und Workflows für Ihr Team am nützlichsten wären.

GitHub: elastic/example-mcp-dashbuilder

Danksagungen

Vielen Dank an Walter Rafelsberger und Tim Schnell für ihren Beitrag zur Umsetzung.

FAQ

Was ist example-mcp-dashbuilder? example-mcp-dashbuilder ist eine Open-Source-MCP (Model Context Protocol) Anwendung, die KI-Assistenten mit Elasticsearch verbindet. Es ermöglicht Ihnen, ein Kibana-Dashboard in einfachem Englisch zu beschreiben und generiert automatisch ES|QL-Abfragen, erstellt Visualisierungen und liefert ein interaktives Live-Dashboard direkt im Chatfenster Ihres Editors.

Welche Abfragesprache verwendet example-mcp-dashbuilder, um Daten abzurufen? Alle Datenabrufe verwenden ES|QL, die Pipe-basierte Abfragesprache von Elasticsearch. Der MCP-Server enthält eine integrierte ES|QL-Referenz, die die KI vor dem Schreiben einer Abfrage liest, um eine korrekte Syntax und effiziente Aggregationen für jeden Visualisierungstyp zu gewährleisten.

Kann ich mit example-mcp-dashbuilder erstellte Dashboards nach Kibana exportieren? Ja. Mithilfe von „Dieses Dashboard nach Kibana exportieren“ wird jedes Panel in eine echte Kibana Lens-Visualisierung übersetzt, wobei ES|QL-Abfragen, das 48-spaltige Rasterlayout, benutzerdefinierte Farben und Serienpaletten erhalten bleiben. Das Ergebnis ist ein voll funktionsfähiges Kibana-Dashboard, kein Screenshot oder Einbettung.

Kann ich ein bestehendes Kibana-Dashboard in example-mcp-dashbuilder importieren, um eine KI-unterstützte Bearbeitung durchzuführen? Ja. Durch Angabe einer Kibana-Dashboard-ID wird das vorhandene Dashboard abgerufen, dessen Lens-Visualisierungen in bearbeitbare Diagrammkonfigurationen übersetzt und in example-mcp-dashbuilder geladen. Anschließend können Sie das Dashboard mithilfe natürlicher Sprache modifizieren und wieder nach Kibana exportieren.

Welche MCP-Clients sind mit example-mcp-dashbuilder kompatibel? example-mcp-dashbuilder funktioniert mit jedem MCP-kompatiblen Client, einschließlich Cursor, Claude Desktop, Claude.ai und VS Code mit Copilot. Es unterstützt sowohl stdio- als auch HTTP-Transport, ohne dass eine lokale Server- oder Portkonfiguration erforderlich ist.

Welche Diagrammtypen werden von example-mcp-dashbuilder unterstützt? Die aktuelle Version unterstützt sechs Diagrammtypen: Balkendiagramm, Liniendiagramm, Flächendiagramm, Kreisdiagramm, Metrik (mit Sparkline) und Heatmap. Geplante Ergänzungen umfassen Gauge, Donut, Treemap, Datentabelle und Tag Cloud, um den vollen Funktionsumfang von Kibana Lens zu erreichen.

Was benötige ich, um example-mcp-dashbuilder auszuführen? Sie benötigen Node.js 22 oder höher, eine Elasticsearch-Instanz (lokal oder Elastic Cloud) und einen MCP-kompatiblen Client. Legen Sie die Umgebungsvariablen ES_NODE, ES_API_KEY (oder ES_USERNAME/ES_PASSWORD) und KIBANA_URL fest. Für Claude Desktop laden Sie die .mcpb- Datei von GitHub Releases herunter und installieren sie per Doppelklick.

Wie wir im vorherigen Beitrag gesehen haben, ist die Konstanz, die durch Funktionsaufrufe ermöglicht wird, nicht nur eine praktische Optimierung, sondern essenziell. Nachdem wir strukturelle Fehler aus dem Evaluationskreislauf entfernt hatten, verbesserten sich die Ergebnisse in Standardszenarien (wie denen im Tier-4-Datensatz) dramatisch.

Doch eine offensichtliche Frage bleibt noch zu beantworten:

Funktioniert dieser Ansatz noch, wenn es kompliziert wird?

Die Entitätsauflösung in der realen Welt schlägt selten in einfachen Fällen fehl. Sie scheitert, wenn Namen Sprach-, Kultur-, Schrift-, Zeit- und Unternehmensgrenzen überschreiten. Sie scheitert, wenn auf Menschen mit Titeln anstelle von Namen Bezug genommen wird, wenn Unternehmen Namen ändern, wenn Transliterationen nicht konstant sind und wenn Kontext (nicht die Schreibweise) das Einzige ist, was eine Erwähnung mit einer realen Entität verbindet.

Für den letzten Beitrag dieser Serie haben wir das System einer sogenannten ultimativen Herausforderung unterzogen.

Was macht dies zur ultimativen Herausforderung?

In früheren Auswertungen haben wir das System mit zunehmend komplexeren Datensätzen getestet. Als wir die im vorherigen Beitrag besprochene Stufe 4 erreichten, hatten wir es bereits mit einer Mischung aus Spitznamen, Titeln, mehrsprachigen Namen und semantischen Bezügen zu tun. Diese Tests zeigten, dass die Architektur selbst solide war, aber dass Zuverlässigkeitsprobleme, insbesondere fehlerhaftes JSON, den Rückruf unterdrückten.

Mit dem implementierten Funktionsaufruf hatten wir endlich eine stabile Grundlage. So konnten wir eine interessantere Frage stellen:

Kann eine einheitliche Pipeline viele verschiedene Arten von Entitätsauflösungsproblemen gleichzeitig bewältigen?

Der ultimative herausfordernde Datensatz wurde darauf ausgelegt, genau diese Dimension zu erreichen.

Anstatt sich auf eine einzelne Schwierigkeit (wie Spitznamen oder Transliteration) zu konzentrieren, kombiniert dieser Datensatz mehr als 50 verschiedene Herausforderungstypen, darunter:

• Kulturelle Namenskonventionen.

• Titelbasierte Referenzen.

• Geschäftliche Beziehungen und historische Namensänderungen.

• Mehrsprachige und skriptübergreifende Erwähnungen.

• Zusammengesetzte Herausforderungen, die mehrere der oben genannten Punkte kombinieren.

Entscheidend ist, dass es hier nicht um die Optimierung für einen einzigen, eng begrenzten Anwendungsfall geht. Es geht darum zu testen, ob das Entwurfsmuster Bestand hat, wenn sich die Regeln von Entität zu Entität ändern.

Der Datensatz auf einen Blick

Der ultimativ herausfordernde Datensatz besteht aus:

• 50 Entitäten, darunter Personen, Unternehmen und Institutionen.

• ~60 Artikel, mit unterschiedlicher Struktur und sprachlicher Komplexität.

• 51 verschiedene Herausforderungskategorien, grob unterteilt in:

  • Kulturelle Namenskonventionen.

  • Titel und beruflichem Kontext.

  • Geschäfts- und Unternehmensbeziehungen.

  • Mehrsprachigkeit und Transliterationsherausforderungen.

  • Kombinierten und Grenzfall-Szenarien.

Zu Beginn der Serie haben wir gesehen, dass die Verwendung von generativer KI (GenKI) zur Erstellung von Datensätzen ein zweischneidiges Schwert sein kann. Ohne sie wäre es äußerst schwierig, ausreichend große und vielfältige Testdaten zusammenzustellen. Aber wenn das Modell nicht kontrolliert wird, neigt es dazu, die Dinge zu einfach zu machen.

Bei einer frühen Generationsüberprüfung stellten wir beispielsweise fest, dass das Modell Formulierungen wie „der russische Präsident“ als expliziten Aliasnamen für Wladimir Putin enthielt. Das mag heute vernünftig erscheinen, aber es widerspricht dem Zweck der Prüfung der Kontextauflösung. Was passiert, wenn der Artikel Russland in den 1990er Jahren behandelt? Das System sollte die richtige Entität aus dem Kontext ableiten und sich nicht auf einen fest codierten Alias verlassen.

Aus diesem Grund wurde dieser Datensatz bewusst so konzipiert, dass Abkürzungen nicht funktionieren. Pseudonyme werden nicht explizit aufgeführt, wenn das System die Bedeutung erschließen soll. Beschreibende Phrasen sind nicht vorab mit Entitäten verknüpft. Korrekte Treffer hängen oft vom Kontext auf Artikelebene ab, nicht nur vom lokalen Text.

Wichtiger Hinweis: Obwohl wir die Fähigkeiten des Systems in verschiedenen Szenarien demonstrieren, ist dies dennoch ein Bildungsprototyp. Produktionssysteme, die die Überwachung von sanktionierten Entitäten in der realen Welt handhaben, würden zusätzliche Validierung, Compliance-Prüfungen, Audit-Trails und eine spezialisierte Handhabung für sensible Anwendungsfälle erfordern.

Warum diese Szenarien schwierig sind

Im ersten Beitrag dieser Reihe haben wir ein einfaches, aber mehrdeutiges Beispiel vorgestellt: „Das neue Swift-Update ist da!“ Die Herausforderung besteht darin, dass „Swift“ je nach Kontext auf mehrere reale Entitäten aufgelöst werden kann. Dieses Beispiel verdeutlicht eine grundlegendere Wahrheit: Natürliche Sprache ist von Natur aus mehrdeutig.

Die Entitätsauflösung ist daher nicht nur ein Problem des Zeichenfolgenabgleichs. Menschen verlassen sich routinemäßig auf gemeinsames Wissen, kulturelle Normen und situativen Kontext, um Referenzen zu lösen, und oft merken wir gar nicht, dass wir das tun.

Betrachten wir ein paar gängige Fälle:

• Ein Titel wie „der Präsident“ ist ohne geopolitischen und zeitlichen Kontext bedeutungslos.

• Ein Firmenname kann sich je nach Zeitpunkt der Artikelveröffentlichung auf ein Mutterunternehmen, eine Tochtergesellschaft oder eine ehemalige Marke beziehen.

• Der Name einer Person kann in verschiedenen Reihenfolgen, Schriften oder Transliterationen erscheinen, abhängig von Sprache und Kultur.

• Die gleiche Phrase kann in verschiedenen Kontexten legitimerweise auf unterschiedliche Entitäten verweisen, und das System muss in der Lage sein, Matches genauso zuversichtlich abzulehnen, wie sie zu akzeptieren.

Es gibt kein einzelnes Regelwerk, das all dies sauber abdeckt. Deshalb trennt dieser Prototyp die verschiedenen Bereiche so konsequent:

• Elasticsearch schränkt den Kandidatenraum effizient und transparent ein.

• Das LLM wird nur dort verwendet, wo ein Urteil erforderlich ist, und ist gezwungen, sich selbst zu erklären.

• Abruf und Schlussfolgerung bleiben getrennte Schritte.

Diese Trennung wird umso wichtiger, je größer die Vielfalt der Herausforderungen ist.

So geht das System mit Vielfalt ohne Spezialfälle um

Eines der interessantesten Ergebnisse dieser Bewertung ist, was sich nicht geändert hat:

• Wir haben keine spezielle Logik für japanische Namen hinzugefügt.

• Wir haben keine benutzerdefinierten Regeln für arabische Patronyme hinzugefügt.

• Wir haben keine fest codierten Mappings für historische Firmennamen hinzugefügt.

Stattdessen basierte das System auf denselben Kernzutaten, die früher in der Serie eingeführt wurden:

• Mit Kontext angereicherte Entitäten, die für semantische Suchen indexiert sind.

• Hybrider Abruf (exakt, per Alias und semantisch) in Elasticsearch.

• Eine kleine, gut definierte Gruppe von Kandidatenmatches.

• LLM-Bewertung eingeschränkt durch Funktionsaufruf und Minimalschemata.

Das deutet darauf hin, dass die Flexibilität des Systems von Repräsentation und Architektur herrührt, nicht von einer ständig wachsenden Sammlung von Regeln.

Wenn das System erfolgreich ist, liegt das daran, dass die richtigen Kandidaten ermittelt werden und das LLM ausreichend Kontext hat, um zu erklären, warum eine Referenz einer bestimmten Entität zugeordnet wird oder nicht.

Ergebnisse: Wie hat es abgeschnitten?

Im ultimativ herausfordernden Datensatz erzielte das System folgende Gesamtergebnisse:

• Präzision: ~91 %

• Rückruf: ~86 %

• F1-Score: ~89 %

• LLM-Annahmequote: ~72 %

Leistung nach Herausforderungstyp

Die Aufschlüsselung der Ergebnisse nach Herausforderungstyp zeigt Stärken und Schwächen:

Die stärkste Leistung (100 % F1-Score) wurde in folgenden Bereichen beobachtet:

• Schriftübergreifender Abgleich (kyrillische, koreanische, chinesische Unternehmen).

• Hebräische Szenarien (Patronyme, Berufstitel, religiöse Titel, Transliteration).

• Unternehmenshierarchien (Luft- und Raumfahrt, diversifizierte Fertigungsunternehmen, Konzerne mit mehreren Geschäftsbereichen).

• Berufsbezeichnungen (akademisch, militärisch, politisch, religiös).

• Kombinierte japanische Szenarien mit mehreren Schriftsystemen.

Starke Leistung (80–99 % F1-Score) umfassten:

• Internationale politische Persönlichkeiten (98 %).

• Historische Namensänderungen (90 %).

• Komplexe Unternehmenshierarchien (89 %).

• Japanische Firmennamen (93 %).

• Cross-Script-Transliteration (86 %).

• Arabische Patronyme (86 %).

Problematischere Bereiche waren:

• Erweiterte Transliteration (Chinesisch, Koreanisch): 0 % F1.

• Bestimmte japanische Szenarien (Höflichkeitsformen, Namensreihenfolge, Variationen des Schriftsystems): ~67 % F1.

• Einige arabische Szenarien (Unternehmensnamen, institutionelle Referenzen): ~40 % F1.

Wichtig ist hier, warum das System in diesen Fällen Schwierigkeiten hatte. Die Fehler waren nicht auf das Scheitern des Gesamtansatzes zurückzuführen, sondern auf Einschränkungen in bestimmten Komponenten, insbesondere dem dichten Vektormodell, das für die semantische Suche in bestimmten mehrsprachigen Szenarien verwendet wird.

Da Abruf und Beurteilung klar getrennt sind, erfordert die Leistungssteigerung keine Neuprogrammierung des Systems. Der Austausch eines leistungsfähigeren mehrsprachigen Einbettungsmodells, die Anreicherung des Entitätskontextes oder die Verfeinerung der Suchstrategien würde die Ergebnisse in diesen Kategorien verbessern, ohne die Kernarchitektur zu verändern.

Aus architektonischer Sicht ist das der eigentliche Erfolgsmaßstab.

Was uns das über das Design verrät

Beim Rückblick auf die Serie lassen sich einige Muster erkennen:

• Vorbereitung ist wichtiger als kluges Matching. Die Anreicherung von Entitäten mit Kontextinformationen im Vorfeld reduziert spätere Mehrdeutigkeiten erheblich.

• LLMs sind als Bewertungs- und nicht als Abrufsysteme am wertvollsten. Sie um eine Erklärung zu bitten, warum eine Übereinstimmung sinnvoll ist, ist weitaus wirkungsvoller als sie um eine Suche zu bitten.

• Zuverlässigkeit ermöglicht Genauigkeit. Der Funktionsaufruf hat nicht nur JSON bereinigt, sondern auch den Abruf von Informationen freigegeben, die bereits in der Abrufphase latent waren.

• Verallgemeinerung schlägt Spezialisierung. Eine kleine Anzahl gut gewählter Abstraktionen bewältigte Dutzende von Aufgabentypen ohne benutzerdefinierte Logik.

Aus diesem Grund ist der Prototyp bewusst Elasticsearch-nativ und konservativ in der Verwendung von LLMs. Das Ziel besteht nicht darin, das Suchen zu ersetzen. Es geht darum, das Suchen in Situationen erklärbar zu machen, in denen die Bedeutung wichtig ist.

Fazit

Die ultimative Herausforderung bestand nicht darin, perfekte Metriken zu verfolgen; es ging darum, eine grundlegendere Frage zu beantworten:

Kann eine transparente, suchbasierte, LLM-gestützte Architektur mit der Mehrdeutigkeit realer Entitäten umgehen, ohne in Regeln oder Blackboxes zu zerfallen?

Für diesen Bildungsprototyp lautet die Antwort ja, mit klaren Vorbehalten in Bezug auf Produktionshärtung, Compliance, Überwachung und Datenqualität. Wenn Sie Systeme erstellen, die begründen müssen, warum ein Entitätsabgleich vorgenommen wurde, ist dieses Muster eine ernsthafte Überlegung wert. Ich hoffe, diese Serie hat gezeigt, dass die Entitätsauflösung kein Mysterium sein muss. Mit der richtigen Aufteilung der Anliegen wird sie zu etwas, worüber man nachdenken, was man messen und verbessern kann.

Diese Arbeit deutet auch auf ein breiteres architektonisches Muster hin. Daraus entsteht eine leichte, aber wichtige Weiterentwicklung der klassischen Retrieval-Augmented-Generation (RAG). Anstatt die Abfrage direkt in die Generierung einfließen zu lassen, führen wir einen expliziten Bewertungsschritt ein. Das LLM wird zunächst zur Beurteilung und Plausibilitätsprüfung der abgerufenen Kandidaten verwendet, und nur die als geeignet befundenen Ergebnisse dürfen die Generierung erweitern. Sie können sich das als Generation-Augmented Retrieval-Augmented Generation with Evaluation oder GARAGE vorstellen, denn wer weiß nicht ein gutes Akronym zu schätzen?

Welche anderen Anwendungsfälle könnten von diesem Muster profitieren? Systeme, die Vertrauen, Transparenz und nachvollziehbare Argumentation erfordern, sind natürliche Kandidaten. Die künftige Arbeit in diesem Bereich sollte sich als ebenso überzeugend erweisen wie die Ergebnisse, die wir hier gesehen haben, und ich bin gespannt, wie sich die Gemeinschaft weiter entwickelt.

Nächste Schritte: Versuchen Sie es selbst

Möchten Sie die ultimative Herausforderung in Aktion sehen? Schauen Sie sich das Ultimate Challenge-Notebook für eine vollständige Anleitung mit realen Implementierungen, detaillierten Erklärungen und praktischen Beispielen an.

Die vollständige Pipeline zur Entitätsauflösung demonstriert die Kernkonzepte und die Architektur, die für den produktiven Einsatz erforderlich sind. Sie können es als Grundlage nutzen, um Systeme zu entwickeln, die Nachrichtenartikel überwachen, Erwähnungen von Entitäten verfolgen und Fragen beantworten, welche Entitäten in welchen Artikeln erscheinen – und das alles, während Transparenz und Erklärbarkeit erhalten bleiben.

1. Das neue Swift-Update ist da! Entwickler sind gespannt darauf, die neuen Features auszuprobieren.

2. Das neue Swift-Update ist da! Das neue Album erscheint nächsten Monat.

Mit diesem zusätzlichen Kontext sollten wir den Namen „Swift“ der richtigen Entität zuordnen können.

Im vorherigen Beitrag haben wir unsere Watchlist eingerichtet und die Entitäten mit zusätzlichem Kontext angereichert. Anhand unserer obigen Beispiele müssen wir mindestens die folgenden beiden Elemente in der Liste haben: Taylor Swift und Swift Programming Language. Wir haben auch besprochen, wie wir Entitätserwähnungen aus Text extrahieren. Beide Beispiele würden „Swift“ extrahieren. Mit diesen Zutaten, der angereicherten Watchlist und den extrahierten Entitäten, sind wir endlich bereit, den Star der Show vorzustellen: den Entitätsabgleich.

Denken Sie daran: Dies ist ein pädagogischer Prototyp, der entwickelt wurde, um Konzepte zum Abgleich von Entitäten zu vermitteln. Produktionssysteme könnten verschiedene große Sprachmodelle (LLMs), benutzerdefinierte Abgleichsregeln, spezialisierte Bewertungspipelines oder Ensemble-Ansätze verwenden, die mehrere Abgleichsstrategien kombinieren.

Das Problem: Warum der Abgleich schwierig ist

Die menschliche Sprache ist eine bemerkenswerte Sache. Eine ihrer interessantesten Eigenschaften ist ihre unendliche Kreativität. Wir können eine unendliche Anzahl neuer Sätze erzeugen und verstehen. Ist es dann verwunderlich, dass exakte Übereinstimmungen bei der Entitätsauflösung selten sind? Autoren bemühen sich, kreativ zu sein, wenn sie können. Es wäre ziemlich mühsam, wenn wir immer die vollständigen Namen schreiben und lesen müssten, wenn eine Entität erwähnt wird. Exakte Übereinstimmungen sind zwar einfach, aber die Realität sieht so aus, dass wir einen ausgefeilteren Ansatz zur Entitätsauflösung benötigen: einen, der robust genug ist, um zumindest einen Teil der grenzenlosen Kreativität menschlicher Autoren zu bewältigen. Deshalb unterteilen wir das Problem in zwei Schritte: Mit Elasticsearch werden plausible Kandidaten skaliert abgerufen, und anschließend wird mit einem LLM beurteilt, ob sich diese Kandidaten tatsächlich auf dieselbe reale Entität beziehen.

Die Lösung: Dreistufiger Abgleich mit transparenter LLM-Bewertung

Wir befinden uns mitten in einem Paradigmenwechsel in der Art und Weise, wie wir Computer nutzen. Genauso wie der Aufstieg des Internets uns vom lokalen Computing zu einem global vernetzten Netzwerk geführt hat, verändert die generative KI grundlegend die Art und Weise, wie Inhalte, Code und Informationen erstellt werden. Tatsächlich wurde der pädagogische Prototyp, der diese Serie begleitet, fast ausschließlich „Vibe-codiert“ unter Verwendung eines LLMs mit sorgfältiger Eingabe durch den Autor. Das soll nicht heißen, dass LLMs die Produktivität der menschlichen Sprache erreicht haben oder erreichen werden, aber es bedeutet, dass wir jetzt eine leistungsstarke Ressource haben, die uns bei der Entitätsauflösung unterstützt.

Ein häufiges Muster, das wir mit GenAI verwenden, ist Retrieval-Augmented Generation (RAG). Hier bedeutet Abrufen das Abrufen von Entitätskandidaten (nicht das Generieren von Antworten), und das LLM wird ausschließlich für die Bewertung und Erklärung von Übereinstimmungen verwendet. Obwohl wir ein LLM um Unterstützung bei der End-to-End-Lösung von Entitäten bitten könnten, ist das sowohl zeitlich als auch finanziell kostspielig. RAG hilft LLMs bei ihrer Arbeit, indem es effizientere Wege nutzt, um dem LLM Kontext bereitzustellen, und ermöglicht es dem LLM so, effizient bei der Entitätsauflösung zu helfen.

Für den Abrufteil von RAG greifen wir erneut auf Elasticsearch zurück. Zunächst ermitteln wir potenzielle Übereinstimmungen mithilfe einer Kombination aus exaktem Abgleich, Abgleich mit Aliasen und hybrider Suche, die Stichwort- und semantische Suche kombiniert. Sobald wir diese potenziellen Übereinstimmungen gefunden haben, schicken wir sie an ein LLM zur Bewertung. Das LLM fungiert als der letzte Übereinstimmungsbewerter. Wir lassen das LLM außerdem seine Argumentation erläutern, was ein wichtiges Unterscheidungsmerkmal zu anderen Entitätsauflösungssystemen darstellt. Ohne diese Erklärungen ist die Entitätsauflösung eine Blackbox; mit ihnen können wir selbst sehen, warum eine Übereinstimmung Sinn ergibt.

Schlüsselkonzepte: Drei-Schritte-Abgleich, hybride Suche und transparente LLM-Bewertung

Was ist der Drei-Schritte-Abgleich? Zu Beginn dieses Projekts haben wir die Hypothese aufgestellt, dass die semantische Suche ein entscheidender Bestandteil des Systems sein wird, aber nicht jeder Abgleich erfordert eine so ausgefeilte Suche. Um effizient Übereinstimmungen zu finden, gehen wir das Problem progressiv an. Zuerst überprüfen wir exakte Übereinstimmungen mit der Stichwortsuche. Wenn wir eine solche Übereinstimmung finden, ist unsere Arbeit getan und wir können weitermachen. Wenn der exakte Abgleich fehlschlägt, wenden wir uns dem Aliasabgleich zu. Im Prototyp wird der Einfachheit halber auch der Aliasabgleich mit Stichwörtern durchgeführt. In der Produktion können Sie diesen Schritt durch Normalisierung, Transliterationsregeln, Fuzzy Matching oder kuratierte Aliastabellen erweitern. Wenn wir in den ersten beiden Schritten immer noch keinen potenziellen Treffer gefunden haben, dann ist es an der Zeit, die semantische Suche über die hybride Suche von Elasticsearch mit Reciprocal Rank Fusion (RRF) einzuführen.

Was ist die hybride Suche? In Elasticsearch können wir die semantische Suche nutzen, um bedeutungsvolle Übereinstimmungen zu finden, die Kontext berücksichtigen. Elasticsearch wird häufig für Vektorsuche und hybride Abfrageverfahren eingesetzt. Semantische Ähnlichkeit ist sehr aussagekräftig, aber sie ist kein Ersatz für strukturiertes Filtern (z. B. nach Zeitspannen, Orten oder Identifikatoren) und ist oft unnötig, wenn eine exakte Übereinstimmung verfügbar ist. Elasticsearch hat sich mit der lexikalischen Suche einen Namen gemacht, die sich hervorragend für Aufgaben eignet, bei denen die semantische Suche nicht ausreicht. Um beide Ansätze voll auszuschöpfen, verwenden wir die lexikalische Suche neben der semantischen Suche in einer einzigen hybriden Abfrage. Anschließend führen wir die Ergebnisse zusammen, um mithilfe von RRF die wahrscheinlichsten Übereinstimmungen zu finden. Im Prototyp werden die oberen zwei Ergebnisse zu potenziellen Übereinstimmungen, die zur LLM-Bewertung gesendet werden können.

Warum die LLM-Bewertung? LLM-Bewertungen und -Erklärungen ermöglichen es unserem System, Ambiguität und Kontext transparent zu behandeln. Dies ist entscheidend für Fälle wie „der Präsident“, die sich auf mehrere Entitäten beziehen können, abhängig vom Kontext, aber es ermöglicht auch, dass Dinge wie Spitznamen und kulturelle Variationen gut im System funktionieren. Und schließlich müssen wir bei geschäftskritischen Aufgaben, wie der Identifizierung von Personen aus Sanktionslisten, wissen, warum ein Treffer akzeptiert wurde, um dem System vertrauen zu können. Entscheidend ist, dass das LLM nicht den gesamten Korpus durchsucht; es bewertet nur die kleine Anzahl von Kandidaten, die von Elasticsearch zurückgegeben werden.

Reale Ergebnisse: Übereinstimmung mit der LLM-Argumentation

Eine große Herausforderung bei jeder Aufgabe der natürlichen Sprachverarbeitung ist die Erstellung eines Referenzdokuments, eines „Lösungsschlüssels“, der uns mitteilt, was die zu erwartenden Ergebnisse sind. Ohne diese Grundlage ist es nahezu unmöglich zu beurteilen, wie gut ein System eine Aufgabe erfüllt. Doch die Erstellung eines solchen Dokuments kann ein mühsamer Prozess sein. Für den Prototyp zur Entitätsauflösung haben wir uns erneut an generative KI gewandt, um Unterstützung bei der Einrichtung von Testdaten zu erhalten.

Zunächst definierten wir mehrere Herausforderungstypen, wie Spitznamen und Transliteration, und baten dann das LLM, eine gestufte Sammlung von Datensätzen zu erstellen, die für das System zunehmend größer und anspruchsvoller werden sollte. Die Erstellung der Datensätze war weniger einfach, als man es sich erhoffen könnte. Das LLM hatte eine starke Neigung zum „Betrügen“, indem es zu einfach wurde, die richtige Antwort zu erhalten. Eine der Herausforderungen konzentrierte sich zum Beispiel auf den semantischen Kontext. Zu dieser Art gehörte beispielsweise die Auflösung von „russischer Autor“ zu „Leo Tolstoi“. Das LLM hat fälschlicherweise „russischer Autor“ als Alias für „Leo Tolstoi“ verwendet, was die Notwendigkeit einer Hybridsuche zum Finden der Übereinstimmung negierte.

Nach mehreren Refaktorierungen, um Probleme wie dieses zu beheben, hatten wir fünf Datensatzstufen, mit denen wir arbeiten konnten. Die Stufen 1–4 waren zunehmend größer und boten mehr Herausforderungstypen. Stufe 5 war der Datensatz der „ultimativen Herausforderung“, der aus den kniffligsten Beispielen aller Herausforderungstypen bestand. Sämtliche Testdaten sind im umfassenden Auswertungsverzeichnis verfügbar.

Zur Evaluierung unseres auf Eingabeaufforderungen basierenden Ansatzes zur Entitätsauflösung konzentrierten wir uns auf den Stufe-4-Datensatz. Ein wichtiger Hinweis ist, dass die Bewertung als kontrolliertes Experiment durchgeführt wurde, so dass wir uns auf die Qualität der Entitätsübereinstimmung konzentrieren konnten. Die Daten der Watchlist wurden vorab mit Kontext angereichert, und Entitäten wurden im Voraus aus dem Artikel extrahiert. Dadurch wurde sichergestellt, dass sich die Bewertung auf den Abgleich und nicht auf die Genauigkeit der Extraktion konzentrierte. Dies isoliert die Qualität der Übereinstimmungen; die Gesamtleistung hängt zusätzlich von der Trefferquote bei der Extraktion und der Qualität der Anreicherung ab.

Evaluationsdatensatz

Der Evaluierungsdatensatz der Stufe 4 bietet einen umfassenden Test der Leistungsfähigkeit des Systems:[1]

• Watchlist-Entitäten: 66 Entitäten unterschiedlichster Art (Personen, Organisationen, Standorte).

• Testartikel: 69 Artikel über reale Szenarien zur Auflösung von Entitäten.

• Erwartete Übereinstimmungen: 206 erwartete Entitätsübereinstimmungen in allen Artikeln.

• Herausforderungstypen: 15 verschiedene Herausforderungstypen, die verschiedene Aspekte der Entitätsauflösung prüfen.

Die in den Datensätzen enthaltenen Herausforderungstypen sind:

• Spitznamen: „Bob Smith“ → „Robert Smith“ (sieben Artikel).

• Titel und Ehrenbezeichnungen: „Dr. Sarah Williams“ → „Sarah Williams“ (fünf Artikel).

• Semantischer Kontext: „Russischer Autor“ → „Leo Tolstoi“ (acht Artikel).

• Mehrsprachige Namen: Umgang mit Namen in verschiedenen Skripten (sechs Artikel).

• Geschäftseinheiten: Variationen von Firmennamen (sieben Artikel).

• Referenzen von Führungskräften: „Microsoft CEO“ → „Satya Nadella“ (fünf Artikel).

• Politische Führungspersönlichkeiten: Titelbasierte Referenzen (fünf Artikel).

• Initialen: „J. Smith“ → „John Smith“ (drei Artikel).

• Varianten der Namensreihenfolge: Verschiedene Konventionen für die Namensreihenfolge (drei Artikel).

• Abgekürzte Namen: Teilweise Namensübereinstimmungen (drei Artikel).

• Namensaufteilung: Namen, die über Text verteilt sind (drei Artikel).

• Fehlende Leerzeichen/Bindestriche: Formatierungsabweichungen (zwei Artikel).

• Transliteration: Skriptübergreifender Namensabgleich (zwei Artikel).

• Kombinierte Herausforderungen: Mehrere Herausforderungen in einem Artikel (sechs Artikel).

• Komplexe Geschäftsbeziehungen: Hierarchische Geschäftsbeziehungen (fünf Artikel).

Mal sehen, wie die auf Eingabeaufforderungen basierende Entitätsauflösung funktioniert hat.

Gesamtleistung

Die Ergebnisse zeigen, dass die LLM-gestützte Übereinstimmungsbewertung vielversprechend ist, aber sie offenbaren auch ein erhebliches Zuverlässigkeitsproblem. Da jedes Kandidatenpaar vom LLM bewertet werden muss, können Fehler im strukturierten Ausgang die Akzeptanz und das Erinnern unterdrücken, selbst wenn der Abruf gut funktioniert.

Metrik

Wert

Präzision

83,8 %

Abruf

62,6 %

F1-Score

71,7 %

Gesamtanzahl der Übereinstimmungen

344

LLM-Annahmequote

44,8 %

Fehlerquote

30,2 %

Das Problem mit der Fehlerrate

Zur Erinnerung: Der erste Schritt im Prototyp besteht darin, mithilfe von Elasticsearch potenzielle Übereinstimmungspaare zu erstellen. Jede dieser potenziellen Übereinstimmungen muss vom LLM bewertet werden. Um all diese Übereinstimmungen effizient zu verarbeiten, fassen wir die LLM-Aufrufe in Batches zusammen. Dies reduziert die API-Kosten und die Latenzzeit, aber es besteht auch ein erhöhtes Risiko, dass der Ausgang fehlerhaftes JSON enthält. Mit zunehmender Batchgröße wird das JSON länger und komplexer, wodurch die Wahrscheinlichkeit steigt, dass der LLM ungültiges JSON generiert. Hier liegt der Ursprung der Fehlerquote von 30 %. In der Bewertung haben wir eine Batch-Größe von fünf Übereinstimmungen pro Anfrage verwendet. Selbst bei dieser konservativen Batchgröße beobachten wir immer noch JSON-Parsing-Fehler, welche die Auswertungsergebnisse erheblich verfälschen.

Nächstes Ziel: Optimierung der LLM-Integration

Nachdem wir nun Entitäten mithilfe semantischer Suche und LLM-Bewertung abgeglichen haben, verfügen wir über eine vollständige Entitätsauflösungspipeline. Dieser Ansatz führt jedoch einen neuen Ausfallmodus ein, wenn die Einschätzung des Modells richtig ist, sein Ausgang jedoch nicht nutzbar ist. Wir können die LLM-Integration im Hinblick auf höhere Zuverlässigkeit und Kosteneffizienz optimieren. Im nächsten Beitrag werden wir untersuchen, wie Sie Funktionsaufrufe für einen strukturierten Ausgang verwenden können, der garantierte Struktur- und Typsicherheit bietet und gleichzeitig Fehler und Kosten reduziert.

Probieren Sie es selbst aus

Möchten Sie den Entitätsabgleich in Aktion sehen? Schauen Sie sich das Entitätsabgleich-Notizbuch für eine vollständige Anleitung mit realen Implementierungen, detaillierten Erklärungen und praktischen Beispielen an. Das Notizbuch zeigt Ihnen genau, wie Sie Entitäten mithilfe der dreistufigen Suche, der hybriden Suche mit RRF und der LLM-gestützten Bewertung mit Schlussfolgerungen abgleichen.

Denken Sie daran: Dies ist ein pädagogischer Prototyp, der entwickelt wurde, um die Konzepte zu vermitteln. Bei der Entwicklung von Produktionssystemen sollten zusätzliche Faktoren wie Modellauswahl, Kostenoptimierung, Latenzanforderungen, Qualitätsvalidierung, Fehlerbehandlung und Überwachung berücksichtigt werden, die in diesem lernorientierten Prototyp nicht behandelt werden.

Anmerkungen

1. Diese Datensätze sind synthetisch und für Bildungszwecke konzipiert; sie nähern sich realen Herausforderungen an, sind aber nicht repräsentativ für eine einzelne Produktionsdomäne.

Unser Ziel war es, zu einem automatisierten, adaptiven Ansatz überzugehen, der sowohl Log-Parsing (Feldextraktion) als auch Log-Partitionierung (Quellenidentifikation) bewältigen kann. Wir vermuteten, dass Large Language Models (LLMs) mit ihrem inhärenten Verständnis von Codesyntax und semantischen Mustern diese Aufgaben mit minimalem menschlichem Eingreifen automatisieren könnten.

Wir freuen uns, Ihnen mitteilen zu können, dass dieses Feature bereits in Streams verfügbar ist!

Beschreibung des Datensatzes

Wir haben für PoC-Zwecke eine Loghub-Sammlungvon Logs gewählt. Für unsere Untersuchung wählten wir repräsentative Stichproben aus den folgenden Schlüsselbereichen aus:

• Verteilte Systeme: Wir verwendeten die HDFS- (Hadoop Distributed File System) und Spark-Datensätze. Diese enthalten eine Mischung aus Info-, Fehlerbehebungs- und Fehlermeldungen, die für Big Data-Plattformen typisch sind.

• Server- und Webanwendungen: Logs von Apache-Webservern und OpenSSH boten eine wertvolle Quelle für Zugriffs-, Fehler- und sicherheitsrelevante Ereignisse. Diese sind entscheidend für die Überwachung des Webverkehrs und die Erkennung potenzieller Bedrohungen.

• Betriebssysteme: Wir haben Protokolle von Linux und Windows aufgenommen. Diese Datensätze repräsentieren die üblichen, semistrukturierten Ereignisse auf Systemebene, denen Betriebsteams täglich begegnen.

• Mobile Systeme: Um sicherzustellen, dass unser Modell auch Logs aus mobilen Umgebungen verarbeiten kann, haben wir den Android-Datensatz mit einbezogen. Diese Logs sind oft ausführlich und erfassen eine Vielzahl von Aktivitäten auf Anwendungs- und Systemebene auf Mobilgeräten.

• Supercomputer: Um die Leistung in Hochleistungs-Computing-Umgebungen (HPC) zu testen, haben wir den BGL-Datensatz (Blue Gene/L) integriert, der hochstrukturierte Logs mit spezifischer Domänenterminologie enthält.

Ein entscheidender Vorteil der Loghub-Sammlung ist, dass die Logs größtenteils unsaniert und unbeschriftet sind, was eine geräuschvolle Live-Produktionsumgebung mit Microservice-Architektur widerspiegelt.

Log-Beispiele:

Zusätzlich haben wir einen Kubernetes-Cluster mit einer typischen Webanwendung und Datenbank erstellt, die zusätzliche Logs in der gängigsten Domäne sammelt.

Beispiel für gängige Logfelder: Zeitstempel, Log-Ebene (INFO, WARN, FEHLER), Quelle, Nachricht.

Few-Shot-Log-Parsing mit einem LLM

Unsere erste Reihe von Experimenten konzentrierte sich auf eine grundlegende Frage: Kann ein LLM zuverlässig Schlüsselfelder identifizieren und konsistente Parsing-Regeln erzeugen, um sie zu extrahieren?

Wir haben ein Modell gebeten, rohe Log-Stichproben zu analysieren und Log-Parsing-Regeln im regulären Ausdruck (Regex) und im Grok-Format zu generieren. Unsere Ergebnisse zeigten, dass dieser Ansatz großes Potenzial hat, aber auch erhebliche Herausforderungen bei der Implementierung.

Hohe Zuverlässigkeit und Kontextbewusstsein

Die ersten Ergebnisse waren vielversprechend. Das LLM zeigte eine starke Fähigkeit, Parsing-Regeln zu generieren, die mit hoher Wahrscheinlichkeit zu den bereitgestellten Beispielen passten. Neben der einfachen Mustererkennung zeigte das Modell die Fähigkeit zum Log-Verständnis – es konnte die Log-Quelle (z. B. Gesundheits-Tracking-App, Nginx-Web-App, Mongo-Datenbank) korrekt identifizieren und benennen.

Das „Goldlöckchen“-Dilemma der Eingabestichproben

Unsere Experimente zeigten schnell einen erheblichen Mangel an Robustheit aufgrund der extremen Empfindlichkeit gegenüber der Eingabestichprobe. Die Leistung des Modells schwankt stark in Abhängigkeit von den spezifischen Log-Beispielen, die im Prompt enthalten sind. Wir haben ein Log-Ähnlichkeitsproblem beobachtet, bei dem die Log-Stichprobe gerade ausreichend unterschiedliche Logs enthalten muss:

• Zu homogen (Overfitting): Wenn die Eingabe-Logs zu ähnlich sind, neigt das LLM dazu, zu überspezifizieren. Es behandelt variable Daten – wie spezifische Java-Klassennamen in einem Stack-Trace – als statische Teile der Vorlage. Das Ergebnis sind spröde Regeln, die nur einen winzigen Teil der Logs abdecken und unbrauchbare Felder extrahieren.

• Zu heterogen (Verwirrung): Umgekehrt, wenn die Stichprobe erhebliche Formatierungsunterschiede enthält – oder schlimmer noch, „Müll-Logs“ wie Fortschrittsbalken, Speichertabellen oder ASCII-Art – kämpft das Modell damit, einen gemeinsamen Nenner zu finden. Oftmals greift man dabei auf die Generierung komplexer, fehlerhafter regulärer Ausdrücke zurück oder verallgemeinert die gesamte Zeile vorschnell zu einem einzigen Nachrichten-Feld.

Die Einschränkung des Kontextfensters

Wir sind außerdem auf einen Engpass im Kontextfenster gestoßen. Wenn die Eingabe-Logs lang, heterogen oder reich an extrahierbaren Feldern waren, verschlechterte sich oft die Ausgabe des Modells und wurde „unübersichtlich“ oder zu lang, um in das Ausgabekontextfenster zu passen. Natürlich hilft Chunking in diesem Fall. Durch das Aufteilen von Protokollen mithilfe zeichenbasierter und entitätsbasierter Trennzeichen könnten wir dem Modell helfen, sich auf das Extrahieren der Hauptfelder zu konzentrieren, ohne von Rauschen überwältigt zu werden.

Die Konsistenz- und Standardisierungslücke

Selbst wenn das Modell erfolgreich Regeln generierte, stellten wir leichte Inkonsistenzen fest:

• Namensvariationen für Dienste: Das Modell schlägt unterschiedliche Namen für dieselbe Entität vor (z. B. wird die Quelle in verschiedenen Ausführungen als „Spark“, „Apache Spark“ und „Spark log Analytics“ bezeichnet).

• Variationen bei der Feldbenennung: Es fehlte an Standardisierung bei den Feldnamen (z. B. id vs. service.id vs. device.id). Wir haben Namen mithilfe einer standardisierten Elastic-Feldbenennung normalisiert.

• Auflösungsvarianz: Die Auflösung der Feldextraktion variierte je nachdem, wie ähnlich die Eingabe-Logs einander waren.

Log-Format-Fingerprint

Um die Herausforderung der Log-Ähnlichkeit anzugehen, führen wir eine leistungsstarke Heuristik ein: Log-Format-Fingerprint (LFF).

Anstatt rohe, verrauschte Logs direkt in ein LLM einzuspeisen, wenden wir zunächst eine deterministische Transformation an, um die zugrundeliegende Struktur jeder Nachricht zu enthüllen. Dieser Vorverarbeitungsschritt abstrahiert variable Daten und generiert einen vereinfachten „Fingerabdruck“, der es uns ermöglicht, verwandte Logs zu gruppieren.

Die Mapping-Logik ist einfach, um Geschwindigkeit und Konsistenz zu gewährleisten:

1. Ziffernabstraktion: Jede Ziffernfolge (0–9) wird durch eine einzelne „0“ ersetzt.

2. Textabstraktion: Jede Folge von alphabetischen Zeichen mit Leerzeichen wird durch ein einzelnes „a“ ersetzt.

3. Normalisierung von Leerzeichen: Alle Sequenzen von Leerzeichen (Leerzeichen, Tabulatoren, Zeilenumbrüche) werden zu einem einzigen Leerzeichen zusammengefasst.

4. Symbolerhaltung: Zeichensetzung und Sonderzeichen (z. B. :, [, ], /) werden beibehalten, da sie oft die stärksten Indikatoren für die Log-Struktur sind.

Wir stellen den Log-Mapping-Ansatz vor. Die grundlegenden Mapping-Muster umfassen Folgendes:

• Ziffern 0–9 von beliebiger Länge -> auf „0“.

• Text (alphabetische Zeichen mit Leerzeichen) von beliebiger Länge -> auf „a“.

• Leerzeichen, Tabulatoren und neue Zeilen -> auf ein einzelnes Leerzeichen.

Schauen wir uns ein Beispiel an, wie uns dieses Mapping die Transformation der Logs ermöglicht.

Dadurch erhalten wir folgende Log-Masken:

Beachten Sie die Fingerabdrücke der ersten beiden Logs. Trotz unterschiedlicher Zeitstempel, Quellklassen und Nachrichteninhalte sind ihre Präfixe (0/0/0 0:0:0 a a.a:) identisch. Durch diese strukturelle Ausrichtung können wir diese Logs automatisch in denselben Cluster einordnen.

Das dritte Log erzeugt jedoch einen völlig abweichenden Fingerabdruck (0-0-0...). Dies ermöglicht es uns, es algorithmisch von der ersten Gruppe zu trennen, bevor wir überhaupt ein LLM aufrufen.

Bonus: Sofortige Implementierung mit ES|QL

Es ist so einfach wie das Übergeben dieser Abfrage in Discover.

Abfrage-Aufschlüsselung:

FROM LogHub: Zielt auf unseren Index mit den Rohprotokolldaten ab.

EVAL Muster = …: Die Kern-Mapping-Logik. Wir verketten REPLACE-Funktionen, um die Abstraktion durchzuführen (z. B. Ziffern zu '0', Text zu 'a' usw.) und speichern das Ergebnis in einem „Muster“-Feld.

STATS [column1 =] expression1, … BY SUBSTRING(pattern, 0, 15):

Dies ist ein Clustering-Schritt. Wir gruppieren Protokolle, die die ersten 15 Zeichen ihres Musters gemeinsam haben, und erstellen aggregierte Felder wie die Gesamtzahl der Protokolle pro Gruppe, eine Liste der Protokoll-Datenquellen, das Musterpräfix und 3 Protokollbeispiele.

SORT total_count DESC | LIMIT 100 : Zeigt die 100 häufigsten Log-Muster an

Die Abfrageergebnisse auf LogHub werden unten angezeigt:

Wie in der Visualisierung gezeigt, partitioniert dieser „LLM-freie“ Ansatz Protokolle mit hoher Genauigkeit. Es gelang ihm, 10 von 16 Datenquellen (basierend auf LogHub-Labels) vollständig zu clustern (>90 %), und er erreichte ein Mehrheits-Clustering in 13 von 16 Quellen (>60 %) – alles ohne zusätzliche Reinigung, Vorverarbeitung oder Feinabstimmung.

Log-Format-Fingerprinting bietet eine pragmatische, wirkungsvolle Alternative und Ergänzung zu ausgefeilten ML-Lösungen wie der Log-Pattern-Analyse. Es bietet sofortige Einblicke in die Zusammenhänge der Logs und verwaltet große Log-Cluster effektiv.

• Vielseitigkeit als Grundform

Dank ES|QL-Implementierung dient LFF sowohl als eigenständiges Werkzeug für schnelle Datendiagnostik/-visualisierungen als auch als Baustein in Loganalyse-Pipelines für Anwendungsfälle mit hohem Volumen.

• Flexibilität

LFF lässt sich leicht anpassen und erweitern, um spezifische Muster zu erfassen, z. B. hexadezimale Zahlen und IP-Adressen.

• Deterministische Stabilität

Im Gegensatz zu ML-basierten Clustering-Algorithmen ist die LFF-Logik geradlinig und deterministisch. Neue eingehende Logs wirken sich nicht rückwirkend auf bestehende Log-Cluster aus.

• Leistung und mMemory

Es benötigt nur minimalen Speicher, kein Training und keine GPU und ist daher ideal für Echtzeit-Umgebungen mit hohem Durchsatz geeignet.

Kombination des Log-Format-Fingerprints mit einem LLM

Zur Validierung der vorgeschlagenen hybriden Architektur enthielt jedes Experiment eine zufällige 20%ige Teilmenge der Logs aus jeder Datenquelle. Diese Einschränkung simuliert eine reale Produktionsumgebung, in der Logs in Batches und nicht als monolithischer historischer Dump verarbeitet werden.

Das Ziel war zu demonstrieren, dass LFF als effektive Kompressionsschicht fungiert. Wir wollten beweisen, dass Parsing-Regeln mit hoher Abdeckung aus kleinen, kuratierten Stichproben generiert und erfolgreich auf den gesamten Datensatz verallgemeinert werden können.

Ausführungspipeline

Wir haben eine mehrstufige Pipeline implementiert, die die Daten filtert, gruppiert und stratifizierte Stichproben auf sie anwendet, bevor sie das LLM erreichen.

1. Zweistufiges hierarchisches Clustering

• Unterklassen (exakte Übereinstimmung): Logs werden anhand identischer Fingerabdrücke aggregiert. Alle Logs einer Unterklasse haben exakt die gleiche Formatstruktur.

• Ausreißerbereinigung. Wir verwerfen alle Unterklassen, die weniger als 5 % des gesamten Logvolumens ausmachen. Dadurch wird sichergestellt, dass sich das LLM auf das dominante Signal konzentriert und nicht durch Rauschen oder fehlerhafte Logs abgelenkt wird.

• Metaklassen (Präfixübereinstimmung): Verbleibende Unterklassen werden in Metaklassen nach den ersten N Zeichen der Format-Fingerabdruckübereinstimmung gruppiert. Wir haben N=5 für das Log-Parsing und N=15 für die Log-Partitionierung gewählt, wenn die Datenquellen unbekannt sind.

2. Stratifiziertes Sampling. Sobald der hierarchische Baum erstellt ist, erstellen wir die Log-Stichprobe für das LLM. Das strategische Ziel ist es, die Varianzabdeckung zu maximieren und gleichzeitig die Verwendung von Token zu minimieren.

• Wir wählen repräsentative Logs aus jeder gültigen Unterklasse innerhalb der breiteren Metaklasse aus.

• Um einen Randfall mit zu vielen Unterklassen zu managen, wenden wir zufälliges Downsampling an, um die Zielfenstergröße anzupassen.

3. Regelgenerierung. Abschließend fordern wir das LLM auf, eine Regex-Parsing-Regel zu generieren, die auf alle Logs in der bereitgestellten Stichprobe für jede Metaklasse zutrifft. Für unseren PoC haben wir das Modell GPT-4o Mini verwendet.

Experimentelle Ergebnisse und Beobachtungen

Wir haben auf dem Loghub-Datensätze eine Parsing-Genauigkeit von 94 % und eine Partitionierungs-Genauigkeit von 91 % erreicht.

Die obige Konfusionsmatrix veranschaulicht die Ergebnisse der Log-Partitionierung. Die vertikale Achse stellt die tatsächlichen Datenquellen dar, die horizontale Achse die vorhergesagten Datenquellen. Die Intensität der Heatmap entspricht dem Log-Volumen, wobei leichtere Kacheln auf eine höhere Anzahl hinweisen. Die diagonale Ausrichtung zeigt die hohe Genauigkeit des Modells bei der Quellenzuweisung mit minimaler Streuung.

Einblicke aus unseren Leistungsvergleichsanalysen:

• Optimale Ausgangsbasis: Ein Kontextfenster von 30 bis 40 Log-Stichproben pro Kategorie erwies sich als der „Sweet Spot“, der sowohl mit Regex- als auch mit Grok-Mustern durchweg ein robustes Parsing ermöglichte.

• Eingabeminimierung: Wir haben die Eingabegröße für Regex-Muster auf 10 Logs pro Kategorie erhöht und nur einen 2%igen Rückgang der Parsing-Leistung festgestellt, was bestätigt, dass diversitätsbasierte Stichproben kritischer sind als das rohe Volumen.

Mit dem Elastic Agent Builder können Sie ganz einfach datenverbundene KI-Agenten erstellen. Wie das geht, zeigen wir Ihnen in diesem Blogbeitrag. Lassen Sie uns alle erforderlichen Schritte durchgehen, um einen Agenten mit einem MCP-Tool zu erstellen, der auf in Elastic gespeicherte Daten zugreift. Dann verwenden wir das Strands Agents SDK und seine A2A-Funktionen (Agent2Agent), um den Agenten zu betreiben. Das Strands Agents SDK ist eine Multiagenten-KI-Entwicklungsplattform, mit der Sie agentenbasierte Anwendungen mit genau dem Code erstellen können, der erforderlich ist, um das gewünschte Ergebnis zu erzielen.

Lassen Sie uns einen KI-Agenten entwickeln, der das Spiel RPS+ spielt, eine Variante des klassischen Spiels „Schere, Stein, Papier“ mit einer zusätzlichen Wendung: Es bietet den Spieler:innen einige zusätzliche Auswahlmöglichkeiten.

Voraussetzungen

Folgendes ist erforderlich, um die Schritte in diesem Blogbeitrag zu befolgen:

• Ein Texteditor, der auf Ihrem lokalen Computer ausgeführt wird

  • Für die Beispielanleitungen in diesem Blogbeitrag verwenden wir Visual Studio Code.

• Python 3.10 oder höher, das auf Ihrem lokalen Computer ausgeführt wird

Ein Serverless-Projekt erstellen

Als Erstes benötigen wir ein Elasticsearch Serverless-Projekt, das den Elastic Agent Builder beinhaltet.

Gehen Sie zu Cloud.elastic.co/de/ und erstellen Sie ein neues Elasticsearch Serverless-Projekt.

Einen Index erstellen und Daten hinzufügen

Als Nächstes fügen wir einige Daten zu unserem Elasticsearch-Projekt hinzu. Öffnen Sie die Entwicklertools, wo wir Befehle ausführen können, um einen neuen Index zu erstellen und einige Daten darin einzufügen. Wählen Sie im Hauptmenü „Entwicklungstools“ aus.

Kopieren Sie den folgenden PUT-Befehl und fügen Sie ihn in den Anfrage-Eingangsbereich der Konsole des Entwicklungstools ein. Diese Anweisung erstellt einen Elasticsearch-Index mit dem Namen „game-docs“.

Klicken Sie auf die Schaltfläche „Anfrage senden“, die in den Entwicklungstools rechts neben der Anweisung angezeigt wird. Sie sollten eine Benachrichtigung sehen, die bestätigt, dass der Game-docs-Index im Reaktion Flächendiagramm der Entwicklungstools erstellt wurde.

Ein Index namens game-docs ist ein großartiger Ort, um die Daten für das Spiel zu speichern, das wir gerade entwickeln. Fügen wir ein Dokument namens rps+-md in diesen Index ein, das alle Daten enthält, die unser Spiel benötigt. Kopieren Sie den folgenden PUT-Befehl und fügen Sie ihn in das Entwicklungstool ein.

Klicken Sie auf die Schaltfläche „Anfrage senden“ neben der Anweisung, um sie auszuführen und das rps+-md-Dokument zum game-docs-Index hinzuzufügen.

Wir sollten jetzt einige Daten abfragen können, und mit Agent Builder ist das einfacher als je zuvor.

Wählen Sie Agenten aus dem Hauptnavigationsmenü aus.

Dann müssen Sie nur noch den standardmäßigen Elastic AI Agent fragen: „Welche Daten habe ich?“

Der Elastic AI Agent bewertet die Daten und liefert eine prägnante Erklärung der vorhandenen Daten.

Ein Tool erstellen

Okay, wir haben jetzt einige Daten in Elastic. Lassen Sie uns diese nutzen. Der Agent Builder bietet integrierte Unterstützung zur Erstellung von MCP-Tools, die Agenten helfen, auf die Daten zuzugreifen, die sie benötigen, um den richtigen Kontext für ihre Aufgabe zu haben. Lassen Sie uns ein einfaches Tool erstellen, das unsere Spieldaten abruft.

Klicken Sie auf das Aktionsmenü des Agent Builders.

Wählen Sie in den Menüoptionen Alle Werkzeuge anzeigenaus.

Klicken Sie auf + Neues Tool.

Wählen Sie im Formular Tool erstellen die Option ES|QL aus. Wählen Sie als Werkzeugtyp die gewünschte Option aus und geben Sie die folgenden Werte ein.

Für die Tool-ID:

Für die Beschreibung:

Für Konfiguration geben Sie die folgende Abfrage in das ES|QL-Abfrage-Textfeld ein:

Ihr ausgefülltes Formular Tool erstellen sollte wie folgt aussehen. Klicken Sie auf Speichern, um das Tool zu erstellen.

Wir haben ein neues Werkzeug am Werkzeugständer hängen. Werkzeuge sollten nicht einfach nur an einem Regal hängen; sie sollten sinnvoll eingesetzt werden. Lassen Sie uns einen Agenten erstellen, der unser neues benutzerdefiniertes Tool verwenden kann.

Einen Agenten erstellen und ihm ein Tool zuweisen

Mit dem Agent Builder ist das Erstellen eines Agenten erfreulich einfach. Sie müssen einfach nur die Agentenanweisungen mit ein paar Details eingeben. Lassen Sie uns jetzt einen Agenten erstellen.

Klicken Sie auf Agenten verwalten.

Klicken Sie + Neuer Agent.

Geben Sie die folgenden Informationen in das Formular Neuer Agent ein.

Geben Sie für die Agenten-ID den folgenden Text ein:

Geben Sie im Textfeld Benutzerdefinierte Anweisungen die folgenden Anweisungen ein:

Geben Sie für den Anzeigenamen den folgenden Text ein:

Für die Anzeigebeschreibung geben Sie den untenstehenden Text ein:

Geben Sie dem Agenten das benutzerdefinierte Tool, das wir zuvor erstellt haben, indem Sie auf den Tab Tools klicken.

Wählen Sie nur das Tool example.get_game_docs aus, das wir zuvor erstellt haben.

Klicken Sie auf Speichern, um den neuen Agenten zu erstellen.

Lassen Sie uns unseren neuen Agenten ausprobieren. Es gibt einen praktischen Link, um einen Chat mit einem beliebigen Agenten aus der Liste der Agenten zu starten.

Geben Sie einfach „start game“ ein und das Spiel beginnt. Es funktioniert!

Sie können sehen, dass der Agent seine Spielobjektauswahl oben in seiner Reaktion anzeigt. Dies ist nützlich, da wir die Wahl des Agenten sehen und bestätigen können, dass das Spiel wie erwartet funktioniert. Wenn man jedoch die Wahl des Gegners kennt, bevor man selbst wählt, wird das Spiel „Schere, Stein, Papier“ nicht besonders unterhaltsam. Um das Spiel zu verfeinern und seine endgültige Form zu erreichen, können wir eine Agenten-Orchestrierungsplattform verwenden, die Agenten mit Code steuern kann.

Hier kommt das Strands Agents SDK ins Spiel.

Strands Agents SDK

Wenn Sie neugierig darauf sind, neue Frameworks für die Agentenentwicklung auszuprobieren, dann ist das Strands Agents SDK einen Versuch wert. Das Strands Agents SDK wurde von AWS (Mai 2025) als Open-Source-Python-Implementierung veröffentlicht, und es gibt jetzt auch eine Typescript-Version.

Erste Schritte mit dem Strands Agents SDK in Python

Starten Sie Ihre Programmiermaschinen. Wir werden jetzt im Eiltempo den Prozess des Klonens und Ausführens einer Beispiel-App durchgehen, die Strands Agents verwendet, um den RPS+ Agent über das A2A-Protokoll zu steuern. Lassen Sie uns eine optimierte Version des RPS+ Spiels entwickeln, bei der die Wahl des Agenten erst nach Ihrer Wahl bekannt gegeben wird, denn schließlich ist es das Rätselraten und der überraschende Ausgang, der Spiele wie „Schere, Stein, Papier“ so unterhaltsam macht.

Öffnen Sie auf Ihrem lokalen Computer Visual Studio Code und öffnen Sie ein neues Terminal.

Im neu geöffneten Terminal führen Sie folgenden Befehl aus, um das Elasticsearch Labs-Repository zu klonen:

Führen Sie den folgenden cd-Befehl aus, um das Verzeichnis in das Verzeichnis „elasticsearch-labs“ zu ändern:

Führen Sie anschließend folgenden Befehl aus, um das Repository in Visual Studio Code zu öffnen:

Erweitern Sie im Visual Studio File Explorer die Ordner supporting-blog-content und agent-builder-a2a-strands-agents und öffnen Sie anschließend die Datei elastic_agent_builder_a2a_rps+.py. So sieht die Datei in Visual Studio Code aus:

Hier ist der Inhalt der Datei elastic_agent_builder_a2a_rps+.py, den Sie in Ihrem Texteditor sehen sollten:

Lassen Sie uns einen Blick darauf werfen, was in diesem Code passiert. Ausgehend von der Methode main() greift der Code zunächst auf die Umgebungsvariablen für die Agenten-URL und den API-Schlüssel zu. Dann verwenden wir diese Werte, um ein httpx client zu erstellen, mit dem wir die Agentenkarte für den Agenten abrufen können. Der Client verwendet dann die Agentenkartendaten, um eine „Spiel starten“-Anfrage an den Agenten zu senden. Interessant ist hierbei, dass wir einen random_game_object -Wert als Teil der "start game" -Anfrage einfügen. Dieser Wert ist eine Zufallszahl, die mit dem Zufallsmodul der Standardbibliothek von Python generiert wird. Der Grund dafür ist, dass sich herausgestellt hat, dass die leistungsstarken LLMs (die KI-Agenten ermöglichen) nicht besonders gut in Bezug auf Zufälligkeit sind. Kein Problem, hier kann Python helfen.

Im weiteren Verlauf des Codes wird, sobald der Agent auf die Anfrage „Spiel starten“ antwortet, die Spielobjektauswahl des Agenten extrahiert und in der Variable agent_choice gespeichert. Der Rest der Reaktion wird dem:der Nutzer:in als Text angezeigt. Anschließend wird der:die Nutzer:in zur Eingabe der eigenen Spielobjektauswahl aufgefordert. Diese Auswahl wird an den Agenten gesendet. Der Code zeigt dann die Auswahl des Spielobjekts durch den Agenten sowie dessen endgültige Entscheidung über den Spielausgang an.

Einrichten Ihrer Agenten-URL und Ihres API-Schlüssels als Umgebungsvariablen

Da die Beispiel-App auf Ihrem lokalen Computer ausgeführt wird, müssen wir dem Strands Agents SDK eine A2A-URL und einen API-Schlüssel für den Agenten bereitstellen, damit dieser mit unserem Agent Builder-Agenten kommunizieren kann. Die Beispiel-App verwendet eine Datei namens .env, um diese Werte zu speichern.

Erstellen Sie eine Kopie der Datei env.example und benennen Sie die neue Datei .env.

Wechseln Sie zurück zum Elastic Agent Builder, wo wir die beiden benötigten Werte abrufen können.

Wählen Sie im Aktionsmenü des Agent Builders oben rechts auf der Seite die Option Alle Tools anzeigen aus.

Klicken Sie oben auf der Seite „Tools“ auf das Dropdown-Menü MCP-Server und wählen Sie MCP-Server-URL kopieren.

Fügen Sie die MCP-Server-URL als Ersatz für den <YOUR-ELASTIC-AGENT-BUILDER-URL>-Platzhalterwert in die .env-Datei ein. Nun müssen wir eine Aktualisierung an der URL vornehmen, das heißt, den Endtext „mcp“ durch „a2a“ ersetzen, da das A2A-Protokoll dasjenige ist, das das Agent Strands SDK zur Kommunikation mit dem in Elastic Agent Builder ausgeführten Agenten verwenden wird.

Die bearbeitete URL sollte in etwa so aussehen:

Der andere Wert, den wir hier in Elastic Cloud brauchen, ist ein API-Schlüssel. Klicken Sie in der oberen Navigationsebene auf Elasticsearch.

Klicken Sie auf die Schaltfläche API-Schlüssel kopieren, um den API-Schlüssel zu kopieren.

Zurück in Visual Studio Code fügen Sie nun den API-Schlüssel in die .env-Datei ein, um den Platzhaltertext <YOUR-ELASTIC-API-KEY> zu ersetzen. Ihre .env-Datei sollte etwa so aussehen:

Die Beispiel-App ausführen

Öffnen Sie ein neues Terminal in Visual Studio Code.

Führen Sie zunächst den folgenden cd-Befehl im Terminal aus:

Führen Sie den folgenden Befehl aus, um eine virtuelle Python-Umgebung zu erstellen.

Führen Sie je nach Betriebssystem Ihres lokalen Computers den folgenden Befehl aus, um die virtuelle Umgebung zu aktivieren.

• macOS/Linux

• Windows

Die Beispiel-App verwendet das Strands Agents SDK, und wir sind nun an dem Punkt in dieser Anleitung angelangt, an dem wir es installieren müssen. Führen Sie folgenden Befehl aus, um das Strands Agents SDK zusammen mit allen erforderlichen Python-Bibliotheksabhängigkeiten zu installieren.

Es ist Zeit, die Startrampe freizumachen und den Countdown zu starten. Wir sind bereit, diese App zu starten. Zurücktreten. Führen wir sie mit folgendem Befehl aus:

Sie sollten mit einer Partie RPS+ herausgefordert werden. Gut gemacht und viel Erfolg!

Erstellen Sie Ihre KI-Apps mit relevantem Kontext

Die Entwicklung eines KI-Agenten gehört nun zu Ihren Kernkompetenzen. Und Sie haben gesehen, wie einfach die Verwendung von Elastic Agent Builder-Agenten über A2A in Agenten-Entwicklungs-Frameworks wie dem Strands Agents SDK ist. Testen Sie Elastic, um KI-Agenten zu erstellen, die mit dem relevanten Kontext Ihrer benutzerdefinierten Daten verknüpft sind.

Was ist LangGraph?

LangGraph ist ein Framework zum Erstellen von KI-Agenten und deren Orchestrierung in einem Workflow, um KI-unterstützte Anwendungen zu entwickeln. LangGraph verfügt über eine Knotenarchitektur, in der wir Funktionen deklarieren können, die Aufgaben darstellen, und diese als Knoten des Workflows zuweisen können. Das Ergebnis der Interaktion mehrerer Knoten ist ein Graph. LangGraph ist Teil des umfassenderen LangChain-Ökosystems, das Tools für die Erstellung modularer und zusammensetzbarer KI-Systeme bereitstellt.

Zur Veranschaulichung dessen, warum LangGraph nützlich ist, werden wir eine problematische Situation damit lösen.

Überblick über die Lösung

In einem Risikokapitalunternehmen haben Investoren Zugriff auf eine umfangreiche Datenbank mit zahlreichen Filteroptionen, aber wenn man Kriterien kombinieren möchte, wird es schwierig und langsam. Dies kann dazu führen, dass einige relevante Start-ups für Investitionen nicht entdeckt werden. Das Ergebnis: Man verbringt viele Stunden damit, die besten Kandidaten zu identifizieren, oder verpasst sogar Chancen.

Mit LangGraph und Elasticsearch können wir gefilterte Suchen in natürlicher Sprache durchführen, sodass Nutzer komplexe Anfragen mit Dutzenden von Filtern nicht manuell erstellen müssen. Um die Flexibilität zu erhöhen, entscheidet der Workflow anhand der Nutzereingaben automatisch zwischen zwei Abfragetypen.

• Investitionsorientierte Anfragen: Diese zielen auf finanzielle und finanzierungsbezogene Aspekte von Start-ups ab, wie Finanzierungsrunden, Bewertung oder Umsatz. Beispiel: „Suche Start-ups mit einer Series-A- oder Series-B-Finanzierung zwischen 8 und 25 Mio. Dollar und einem monatlichen Umsatz von über 500.000 Dollar.“

• Marktorientierte Anfragen: Diese konzentrieren sich auf Branchensegmente, geografische Märkte oder Geschäftsmodelle und helfen dabei, Chancen in bestimmten Sektoren oder Regionen zu identifizieren. Beispiel: „Suche Fintech- und Healthcare-Start-ups in San Francisco, New York oder Boston.“

Um die Abfragen robust zu halten, werden wir das LLM dazu bringen, Suchvorlagen anstelle vollständiger DSL-Abfragen zu erstellen. Auf diese Weise erhalten Sie immer die gewünschte Abfrage, und der LLM muss lediglich die Lücken ausfüllen und trägt nicht die Verantwortung, die benötigte Abfrage jedes Mal neu zu erstellen.

Was Sie brauchen, um loszulegen

• Elasticsearch API-Schlüssel

• OpenAPI-API-Schlüssel

• Node 18 oder neuer

Schritt-für-Schritt-Anweisungen

In diesem Abschnitt schauen wir uns an, wie die App aussehen wird. Dafür verwenden wir TypeScript, ein Superset von JavaScript, das statische Typen hinzufügt, um den Code zuverlässiger, leichter zu pflegen und sicherer zu machen, indem Fehler frühzeitig erkannt werden, während er vollständig kompatibel mit bestehendem JavaScript bleibt.

Der Knotenfluss sieht wie folgt aus:

Das obige Bild wird von LangGraph generiert und stellt den Workflow dar, der die Ausführungsreihenfolge und die bedingte Logik zwischen den Knoten definiert:

• decideStrategy: Verwendet ein LLM, um die Anfrage des Nutzers zu analysieren und zwischen zwei spezialisierten Suchstrategien zu entscheiden – investitionsorientiert oder marktorientiert.

• prepareInvestmentSearch: Extrahiert Filterwerte aus der Abfrage und erstellt eine vordefinierte Vorlage, die finanzielle und finanzierungsbezogene Parameter hervorhebt.

• prepareMarketSearch: Extrahiert ebenfalls Filterwerte, baut jedoch dynamisch Parameter auf, die den Markt-, Branchen- und geografischen Kontext betonen.

• executeSearch: Sendet die konstruierte Abfrage mit einer Suchvorlage an Elasticsearch und ruft die entsprechenden Start-up-Dokumente ab.

• VisualizeResults: Formatiert die Endergebnisse in einer klaren, lesbaren Zusammenfassung, die die wichtigsten Startup-Attribute wie Finanzierung, Branche und Umsatz aufzeigt.

Dieser Fluss umfasst eine bedingte Verzweigung, die als „if“-Anweisung fungiert und basierend auf der Eingabe des Nutzers bestimmt, ob der Investitions- oder Marktsuchpfad verwendet wird. Diese vom LLM gesteuerte Entscheidungslogik macht den Workflow adaptiv und kontextsensitiv – ein Mechanismus, den wir in den nächsten Abschnitten genauer untersuchen werden.

LangGraph-Status

Bevor wir jeden Knoten einzeln betrachten, müssen wir verstehen, wie die Knoten kommunizieren und Daten austauschen. Dafür ermöglicht uns LangGraph, den Workflow-Status zu definieren. Dies definiert den gemeinsamen Status, der zwischen Knoten weitergegeben wird.

Der Zustand fungiert als gemeinsamer Container, der während des gesamten Workflows Zwischendaten speichert: Er beginnt mit der natürlichsprachlichen Anfrage des Nutzers, speichert dann die ausgewählte Suchstrategie, die vorbereiteten Parameter für Elasticsearch, die abgerufenen Suchergebnisse und schließlich den formatierten Ausgang.

Diese Struktur ermöglicht es jedem Knoten, den Status zu lesen und zu aktualisieren, wodurch ein konsistenter Informationsfluss vom Nutzer-Eingang bis zur endgültigen Visualisierung gewährleistet wird.

Einrichten der Anwendung

Der gesamte Code in diesem Abschnitt ist im elasticsearch-labs-Repository zu finden.

Öffnen Sie ein Terminal in dem Ordner, in dem sich die App befindet, und initialisieren Sie eine Node.js-Anwendung mit folgendem Befehl:

Nun können wir die notwendigen Abhängigkeiten für dieses Projekt installieren:

• @elastic/elasticsearch: Hilft uns bei der Bearbeitung von Elasticsearch-Anfragen, z. B. bei der Daten-Ingestion und dem Abrufen von Daten.

• @langchain/langgraph: JS-Abhängigkeit zur Bereitstellung aller LangGraph-Tools.

• @langchain/openai: LLM-Client von OpenAI für LangChain.

• @langchain/core: Bietet die grundlegenden Bausteine für LangChain-Apps, einschließlich Prompt-Vorlagen.

• dotenv: Notwendige Abhängigkeit zur Verwendung von Umgebungsvariablen in JavaScript.

• zod: Abhängigkeit von Typdaten.

@types/node tsx typescript ermöglicht es uns, TypeScript-Code zu schreiben und auszuführen.

Erstellen Sie nun die folgenden Dateien:

• elasticsearchSetup.ts: Erstellt die Index-Mappings, lädt die Daten aus einer JSON-Datei und führt den Ingest der Daten in Elasticsearch durch.

• main.ts: Wird die LangGraph-Anwendung enthalten.

• .envDatei zum Speichern der Umgebungsvariablen

In der .env-Datei fügen wir die folgenden Umgebungsvariablen hinzu:

Der OpenAPI-APIKey wird nicht direkt im Code verwendet; stattdessen wird er intern von der Bibliothek @langchain/openai verwendet.

Die gesamte Logik bezüglich der Erstellung von Mappings, der Erstellung von Suchvorlagen und der Datensatz-Ingestion kann in der Datei elasticsearchSetup.ts gefunden werden. In den nächsten Schritten konzentrieren wir uns auf die main.ts-Datei. Sie können den Datensatz auch überprüfen, um besser zu verstehen, wie die Daten in dataset.json aussehen.

LangGraph-App

In der main.ts-Datei importieren wir einige notwendige Abhängigkeiten, um die LangGraph-Anwendung zu konsolidieren. In dieser Datei müssen Sie auch die Knotenfunktionen und die Zustandsdeklaration angeben. Die Graphdeklaration erfolgt in den nächsten Schritten anhand einermain-Methode. Die elasticsearchSetup.ts-Datei wird Elasticsearch-Helfer enthalten, die wir in den nächsten Schritten in den Knoten verwenden werden.

Wie bereits erwähnt, wird der LLM-Client verwendet, um die Elasticsearch-Suchvorlagenparameter basierend auf der Frage des Nutzers zu generieren.

Die oben dargelegte Methode erzeugt das Graphbild im PNG-Format und verwendet hinter den Kulissen die Mermaid.INK-API. Dies ist nützlich, wenn Sie sehen möchten, wie die App-Knoten mit einer gestylten Visualisierung zusammenwirken.

LangGraph-Knoten

Sehen wir uns nun die einzelnen Knoten im Detail an:

decideSearchStrategy-Knoten

Der decideSearchStrategy-Knoten analysiert die Eingabe und entscheidet, ob eine investitions- oder marktorientierte Suche durchgeführt werden soll. Er verwendet ein LLM mit einem strukturierten Ausgang (definiert mit Zod), um den Abfragetyp zu klassifizieren. Bevor die Entscheidung getroffen wird, werden mithilfe einer Aggregation die verfügbaren Filter aus dem Index abgerufen, um sicherzustellen, dass das Modell über einen aktuellen Kontext zu Branchen, Standorten und Finanzierungsdaten verfügt.

Um die möglichen Filterwerte zu extrahieren und an das LLM zu senden, verwenden wir eine Aggregation, um sie direkt aus dem Elasticsearch-Index abzurufen. Diese Logik wird in einer Methode namens getAvailableFilterszugeordnet:

Mit der obigen Aggregationsanfrage erhalten wir die folgenden Ergebnisse:

Alle Ergebnisse finden Sie hier.

Für beide Strategien verwenden wir eine hybride Suche, um sowohl den strukturierten Teil der Frage (Filter) als auch die subjektiveren Teile (Semantik) zu erkennen. Hier ist ein Beispiel für beide Abfragen unter Verwendung von Suchvorlagen:

Sehen Sie sich die Abfragen an, die in derelasticsearchSetup.ts-Datei detailliert beschrieben sind. Im folgenden Knoten wird entschieden, welche der beiden Abfragen verwendet wird:

prepareInvestmentSearch- und prepareMarketSearch-Knoten

Beide Knoten verwenden eine gemeinsame Hilfsfunktion, extractFilterValues, die das LLM nutzt, um relevante Filter zu identifizieren, die in den Nutzereingaben erwähnt werden, wie z. B. Branche, Standort, Finanzierungsphase, Geschäftsmodell usw. Wir verwenden dieses Schema, um unsere Suchvorlage zu erstellen.

Je nach erkannter Absicht wählt der Workflow einen von zwei Pfaden:

prepareInvestmentSearch: Erstellt finanzorientierte Suchparameter, einschließlich Finanzierungsphase, Finanzierungsbetrag, Investor und Erneuerungsinformationen. Die gesamte Abfragevorlage finden Sie in der elasticsearchSetup.ts-Datei:

prepareMarketSearch: erstellt marktorientierte Parameter, die sich auf Branchen, Geografien und Geschäftsmodelle konzentrieren. Die vollständige Abfrage finden Sie in der Datei elasticsearchSetup.ts:

executeSearch-Knoten

Dieser Knoten nimmt die gesuchten Parameter aus dem Zustand und sendet sie zuerst an Elasticsearch, wobei er die _render-API verwendet, um die Abfrage für Debugging-Zwecke zu visualisieren, und sendet dann eine Anfrage zur Abrufung der Ergebnisse.

visualizeResults-Knoten

Dieser Knoten zeigt schließlich die Elasticsearch-Ergebnisse an.

Programmatisch sieht der gesamte Graph so aus:

Wie Sie sehen können, haben wir eine bedingte Kante, bei der die App entscheidet, welcher „Pfad“ oder Knoten als Nächstes ausführen wird. Dieses Feature ist nützlich, wenn Workflows Verzweigungslogik benötigen, etwa die Wahl zwischen mehreren Tools oder das Einfügen eines Human-in-the-Loop-Schrittes.

Nachdem wir die Kern-Features von LangGraph verstanden haben, können wir die Anwendung einrichten, in der der Code ausgeführt werden soll:

Alles wird in einer main-Methode zusammengefasst. Hier deklarieren wir den Graphen mit allen Elementen unter der Variablen „Workflow“:

Die Abfragevariable simuliert die in einer hypothetischen Suchleiste eingegebenen Nutzereingaben:

Aus der natürlichsprachlichen Formulierung „Suche Start-ups mit Series-A- oder Series-B-Finanzierung zwischen 8 und 25 Millionen US-Dollar und einem monatlichen Umsatz von über 500.000 US-Dollar“ werden alle Filter extrahiert.

Rufen Sie abschließend die Hauptmethode auf:

Ergebnisse

Für die gesendete Eingabe wählt die Anwendung den investitionsorientierten Pfad, wodurch wir die Elasticsearch-Abfrage sehen, die vom Workflow generiert wird und die Werte und Bereiche aus dem Eingang des Nutzers extrahiert. Wir können auch die an Elasticsearch gesendete Anfrage mit den extrahierten Werten sehen, und schließlich die vom visualizeResults-Knoten formatierten Ergebnisse.

Testen wir nun den marktorientierten Knoten mit der Abfrage „Suche Fintech- und Healthcare-Start-ups in San Francisco, New York oder Boston.“:

Erkenntnisse

Während des Schreibprozesses habe ich Folgendes gelernt:

• Wir müssen dem LLM die exakten Werte der Filter zeigen, sonst sind wir darauf angewiesen, dass der Nutzer die präzisen Werte eingibt. Bei niedriger Kardinalität ist dieser Ansatz akzeptabel, aber wenn die Kardinalität hoch ist, benötigen wir einen Mechanismus zum Herausfiltern der Ergebnisse.

• Die Verwendung von Suchvorlagen führt zu deutlich konsistenteren Ergebnissen als die automatische Generierung der Elasticsearch-Abfrage durch das LLM und ist zudem schneller.

• Bedingte Kanten sind ein leistungsstarker Mechanismus, um Anwendungen mit mehreren Varianten und verzweigten Pfaden zu erstellen.

• Strukturierte Ausgaben sind bei der Informationsgenerierung mit LLMs äußerst nützlich, da sie vorhersehbare, typsichere Antworten erzwingen. Dies verbessert die Zuverlässigkeit und reduziert Fehlinterpretationen von Prompts.

Die Kombination von semantischem und strukturiertem Suchen durch hybriden Abruf führt zu besseren und relevanteren Ergebnissen, wobei Präzision und Kontextverständnis in Einklang gebracht werden.

Fazit

In diesem Beispiel kombinieren wir LangGraph.js mit Elasticsearch, um einen dynamischen Workflow zu schaffen, der natürliche Sprachanfragen interpretieren und zwischen finanz- oder marktorientierten Suchstrategien entscheiden kann. Dieser Ansatz reduziert die Komplexität manueller Abfragen und verbessert gleichzeitig die Flexibilität und Genauigkeit für Risikokapitalanalysten.

Dieser Artikel zeigt Ihnen, wie Sie mit GPT-OSS und Elastic Agent Builder einen KI-Agenten für HR erstellen. Der Agent kann Ihre Fragen beantworten, ohne Daten an OpenAI, Anthropic oder einen externen Dienst zu senden.

Wir werden LM Studio verwenden, um GPT-OSS lokal bereitzustellen und es mit dem Elastic Agent Builder zu verbinden.

Am Ende dieses Artikels verfügen Sie über einen individuell angepassten KI-Agenten, der Fragen in natürlicher Sprache zu Ihren Mitarbeiterdaten beantworten kann und gleichzeitig die volle Kontrolle über Ihre Informationen und Ihr Modell behält.

Voraussetzungen

Für diesen Artikel benötigen Sie:

• Elastic Cloud- gehostete Version 9.2, serverlose oder lokale Bereitstellung

• Empfohlen wird ein Rechner mit 32 GB RAM (mindestens 16 GB für GPT-OSS 20B).

• LM Studio installiert

• Docker Desktop installiert

Warum GPT-OSS verwenden?

Mit einem lokalen LLM haben Sie die Kontrolle, es in Ihrer eigenen Infrastruktur einzusetzen und es genau an Ihre Bedürfnisse anzupassen. All dies, während Sie die Kontrolle über die Daten behalten, die Sie mit dem Modell teilen, und natürlich müssen Sie keine Lizenzgebühr an einen externen Anbieter zahlen.

OpenAI veröffentlichte GPT-OSS am 5. August 2025 als Teil seines Engagements für das offene Ökosystem von Computermodellen.

Das Parametermodell 20B bietet:

• Werkzeugnutzungsfähigkeiten

• Effiziente Schlussfolgerung

• OpenAI SDK-kompatibel

• Kompatibel mit agentenbasierten Workflows

Vergleich der Benchmarks:

Lösungsarchitektur

Die Architektur läuft vollständig auf Ihrem lokalen Rechner. Elastic (läuft in Docker) kommuniziert direkt mit Ihrem lokalen LLM über LM Studio, und der Elastic Agent Builder nutzt diese Verbindung, um benutzerdefinierte KI-Agenten zu erstellen, die Ihre Mitarbeiterdaten abfragen können.

Weitere Einzelheiten entnehmen Sie bitte dieser Dokumentation.

Entwicklung eines KI-Agenten für die Personalabteilung: Schritte

Wir werden die Implementierung in 5 Schritte unterteilen:

1. Konfigurieren Sie LM Studio mit einem lokalen Modell

2. Lokalen Elastic-Speicher mit Docker bereitstellen

3. Erstellen Sie den OpenAI-Konnektor in Elastic

4. Mitarbeiterdaten in Elasticsearch hochladen

5. Erstellen und testen Sie Ihren KI-Agenten

Schritt 1: LM Studio mit GPT-OSS 20B konfigurieren

LM Studio ist eine benutzerfreundliche Anwendung, mit der Sie große Sprachmodelle lokal auf Ihrem Computer ausführen können. Es bietet einen OpenAI-kompatiblen API-Server, wodurch die Integration mit Tools wie Elastic ohne komplexen Einrichtungsprozess vereinfacht wird. Weitere Details finden Sie in der LM Studio-Dokumentation.

Laden Sie zunächst LM Studio von der offiziellen Website herunter und installieren Sie es. Nach der Installation öffnen Sie die Anwendung.

In der LM Studio-Oberfläche:

1. Gehen Sie zum Suchfeld und suchen Sie nach „GPT-OSS“.

2. Wählen Sie openai/gpt-oss-20b aus OpenAI aus.

3. Klicken Sie auf „Herunterladen“.

Die Größe dieses Modells sollte ungefähr 12,10 GB betragen. Der Download kann je nach Ihrer Internetverbindung einige Minuten dauern.

Sobald das Modell heruntergeladen ist:

1. Wechseln Sie zur Registerkarte „Lokaler Server“.

2. Wählen Sie openai/gpt-oss-20b aus.

3. Verwenden Sie den Standardport 1234.

4. Gehen Sie im rechten Bereich auf „Laden“und stellen Sie die Kontextlänge auf 40 KB oder höher ein.

5. Klicken Sie auf „Server starten“.

Dies sollte Ihnen angezeigt werden, wenn der Server läuft.

Schritt 2: Lokalen Elastic-Speicher mit Docker bereitstellen

Nun richten wir Elasticsearch und Kibana lokal mit Docker ein. Elastic stellt ein praktisches Skript zur Verfügung, das den gesamten Einrichtungsprozess übernimmt. Für weitere Einzelheiten verweisen wir auf die offizielle Dokumentation.

Führen Sie das Start-Lokal-Skript aus

Führen Sie folgenden Befehl in Ihrem Terminal aus:

Dieses Skript wird:

• Elasticsearch und Kibana herunterladen und konfigurieren

• Starten Sie beide Dienste mit Docker Compose.

• Automatische Aktivierung einer 30-tägigen Platinum-Testlizenz

Erwartete Ausgabe

Warten Sie einfach auf die folgende Meldung und speichern Sie das angezeigte Passwort und den API-Schlüssel; Sie benötigen diese für den Zugriff auf Kibana:

Zugriff auf Kibana

Öffnen Sie Ihren Browser und navigieren Sie zu:

Melden Sie sich mit den Anmeldeinformationen an, die Sie in der Terminalausgabe erhalten haben.

Agent Builder aktivieren

Nach dem Einloggen in Kibana navigieren Sie zu Management > AI > Agent Builder und aktivieren den Agent Builder.

Schritt 3: Erstellen Sie den OpenAI-Konnektor in Elastic

Nun konfigurieren wir Elastic so, dass es Ihr lokales LLM verwendet.

Zugangsanschlüsse

1. In Kibana

2. Gehen Sie zu Projekteinstellungen > Verwaltung

3. Unter „Warnungen und Einblicke“ wählen Sie „Konnektoren“aus.

4. Klicken Sie auf „Connector erstellen“.

Konfigurieren Sie den Anschluss

Wählen Sie OpenAI aus der Liste der Konnektoren aus. LM Studio nutzt das OpenAI SDK und ist daher kompatibel.

Füllen Sie die Felder mit diesen Werten aus:

• Anschlussname: LM Studio - GPT-OSS 20B

• Wählen Sie einen OpenAI-Anbieter: Andere (OpenAI-kompatibler Dienst)

• URL: http://host.docker.internal:1234/v1/chat/completions

• Standardmodell: openai/gpt-oss-20b

• API-Schlüssel: testkey-123 (Jeder beliebige Text funktioniert, da LM Studio Server keine Authentifizierung erfordert.)

Klicken Sie zum Abschluss der Konfiguration auf Speichern & Testen.

Wichtig: Aktivieren Sie die Option „ Native Funktionsaufrufe aktivieren“; dies ist erforderlich, damit der Agent Builder ordnungsgemäß funktioniert. Wenn Sie dies nicht aktivieren, erhalten Sie einen No tool calls found in the response -Fehler.

Testen Sie die Verbindung

Elastic sollte die Verbindung automatisch testen. Wenn alles korrekt konfiguriert ist, wird eine Erfolgsmeldung wie diese angezeigt:

Abwehr:

Schritt 4: Mitarbeiterdaten in Elasticsearch hochladen

Nun laden wir den HR-Mitarbeiterdatensatz hoch, um zu demonstrieren, wie der Agent mit sensiblen Daten arbeitet. Ich habe einen fiktiven Datensatz mit dieser Struktur generiert.

Struktur des Datensatzes

Erstellen Sie den Index mit Zuordnungen

Zuerst muss der Index mit den entsprechenden Zuordnungen erstellt werden. Beachten Sie, dass wir für einige Schlüsselfelder semantische Textfelder verwenden; dies ermöglicht semantische Suchfunktionen für unseren Index.

Indexierung mit Bulk-API

Kopieren Sie den Datensatz in Ihre Entwicklertools in Kibana und führen Sie ihn aus:

Überprüfen Sie die Daten.

Führen Sie eine Abfrage zur Überprüfung durch:

Schritt 5: KI-Agent erstellen und testen

Nachdem alles konfiguriert ist, ist es nun an der Zeit, mit dem Elastic Agent Builder einen benutzerdefinierten KI-Agenten zu erstellen. Weitere Details finden Sie in der Elastic-Dokumentation.

Fügen Sie den Verbinder hinzu.

Bevor wir unseren neuen Agenten erstellen können, müssen wir unseren Agent Builder so einstellen, dass er unseren benutzerdefinierten Konnektor mit der Bezeichnung LM Studio - GPT-OSS 20B verwendet, da der Standardkonnektor Elastic Managed LLM ist. Dazu müssen wir zu Projekteinstellungen > Verwaltung > GenAI-Einstellungen gehen; jetzt wählen wir die von uns erstellte Einstellung aus und klicken auf Speichern.

Zugriffsagenten-Generator

1. Gehen Sie zu den Agenten.

2. Klicken Sie auf „Neuen Agenten erstellen“.

Konfigurieren Sie den Agenten

Zum Anlegen eines neuen Agenten sind die Felder Agenten-ID, Anzeigename und Anzeigeanweisungen erforderlich.

Es gibt aber noch weitere Anpassungsmöglichkeiten, wie zum Beispiel die benutzerdefinierten Anweisungen, die vorgeben, wie sich Ihr Agent verhalten und mit Ihren Tools interagieren soll, ähnlich einer Systemaufforderung, aber für unseren benutzerdefinierten Agenten. Mithilfe von Labels lassen sich Agenten, Avatarfarben und Avatarsymbole organisieren.

Diejenigen, die ich anhand des Datensatzes für unseren Agenten ausgewählt habe, sind: Agenten-ID: hr_assistant

Benutzerdefinierte Anweisungen:

Labels: Human Resources und GPT-OSS

Anzeigename: HR Analytics Assistant

Anzeigebeschreibung:

Nachdem alle Daten eingegeben wurden, können wir auf „Unseren neuen Agenten speichern “ klicken.

Testen Sie den Agenten

Sie können nun Fragen in natürlicher Sprache zu Ihren Mitarbeiterdaten stellen, und GPT-OSS 20B versteht die Absicht und generiert eine angemessene Antwort.

Prompt:

Antwort:

Der Agentenprozess war wie folgt:

1. Verstehen Sie Ihre Frage mithilfe des GPT-OSS-Connectors.

2. Generieren Sie die entsprechende Elasticsearch-Abfrage (mithilfe der integrierten Tools oder einer benutzerdefinierten ES|QL- Abfrage).

3. Abrufen passender Mitarbeiterdatensätze

4. Die Ergebnisse in natürlicher Sprache und mit geeigneter Formatierung präsentieren

Im Gegensatz zur herkömmlichen lexikalischen Suche versteht der von GPT-OSS unterstützte Agent Absicht und Kontext, wodurch es einfacher wird, Informationen zu finden, ohne die genauen Feldnamen oder die Abfragesyntax kennen zu müssen. Weitere Einzelheiten zum Denkprozess des Agenten finden Sie in diesem Artikel.

Fazit

In diesem Artikel haben wir mithilfe des Agent Builders von Elastic einen benutzerdefinierten KI-Agenten erstellt, um eine Verbindung zum lokal laufenden OpenAI GPT-OSS-Modell herzustellen. Durch die Bereitstellung von Elastic und LLM auf Ihrem lokalen Rechner ermöglicht Ihnen diese Architektur die Nutzung generativer KI-Funktionen bei gleichzeitiger vollständiger Kontrolle über Ihre Daten, ohne dass Informationen an externe Dienste gesendet werden müssen.

Wir haben GPT-OSS 20B als Experiment verwendet, aber die offiziell empfohlenen Modelle für Elastic Agent Builder sind hier aufgeführt. Falls Sie fortgeschrittenere Schlussfolgerungsfähigkeiten benötigen, gibt es auch die 120B-Parametervariante , die bei komplexen Szenarien besser abschneidet, allerdings ist für die lokale Ausführung ein leistungsstärkerer Rechner erforderlich. Weitere Einzelheiten finden Sie in der offiziellen OpenAI-Dokumentation.

Neben den beeindruckenden Projekten hat uns die Erfahrung bei Cal Hacks 12.0 auch etwas ebenso Wertvolles gebracht: schnelles, unverfälschtes Feedback von Entwicklern, die zum ersten Mal mit unserem Stack in Berührung kamen. Hackathons sind einzigartige Drucktests mit engen Zeitvorgaben, keinerlei Vorkenntnissen und unvorhersehbaren Hindernissen (wie den berüchtigten WLAN-Ausfällen). Sie zeigen genau, wo die Entwicklererfahrung glänzt und wo noch Verbesserungsbedarf besteht. Dies ist heute umso wichtiger, da Entwickler auf neue Weise mit dem Elastic Stack interagieren, zunehmend über LLM-gesteuerte Workflows. In diesem Blogbeitrag werden wir genauer darauf eingehen, was die Teilnehmer mit Agent Builder erstellt haben und was wir dabei gelernt haben.

Die Gewinnerprojekte

Erster Platz: AgentOverflow

Stack Overflow neu entwickelt für die LLM- und Agentenära.

Lesen Sie hier mehr über AgentOverflow.

AgentOverflow löst ein Problem, mit dem die meisten KI-Entwickler konfrontiert sind: LLMs halluzinieren, Chatverläufe verschwinden, und Entwickler verschwenden Zeit damit, dieselben Probleme immer wieder zu lösen.

AgentOverflow erfasst, validiert und präsentiert reale Problem-Lösungs-Paare, damit Entwickler die Illusionsspirale durchbrechen und schneller Ergebnisse liefern können.

So funktioniert es:

1. JSON teilen – das „Lösungsschema“.

Ein Klick auf eine Claude-Freigabe extrahiert und erstellt eine Share Solution JSON-Datei in einem strukturierten Format, das Folgendes enthält:

• Problem

• Kontext

• Code

• Tags

• Die Lösungsschritte wurden verifiziert.

Ein Validator (LAVA) prüft und erzwingt die Struktur, der Benutzer fügt eine Zeile zusätzlichen Kontexts hinzu, dann wird das Ganze in Elasticsearch gespeichert und indiziert.

2. Lösung finden

Wenn Sie nicht weiterkommen, klicken Sie auf Find Solution AgentOverflow extrahiert dann Ihre aktuelle Konversation, erstellt daraus eine Abfrage und führt eine hybride Elasticsearch-Suche durch, um Folgendes anzuzeigen:

• Rangliste, von der Community validierte Korrekturen

• Die genauen Eingabeaufforderungen, die das Problem ursprünglich gelöst haben

Dies ermöglicht es Entwicklern, ihre aktuelle Sitzung schnell zu kopieren, einzufügen und zu entsperren.

3. MCP – Kontextinjektion für LLMs

Durch die Anbindung an die in Elasticsearch gespeicherten strukturierten Lösungen über MCP (Model Context Protocol) erhalten LLMs zur Laufzeit einen hochsignifikanten Kontext (Code, Protokolle, Konfigurationen, vorherige Korrekturen) ohne zusätzliche Störungen.

AgentOverflow verwendet Agent Builder mit Elasticsearch als strukturierte Speicherschicht, die relevanten Kontext in LLMs einfügt. Dadurch werden sie von passiven Chatbots zu kontextsensitiven Problemlösern.

Zweiter Platz: MarketMind

Eine in Echtzeit interpretierbare Darstellung der Marktenergie, ermöglicht durch sechs elastische Agenten.

Lesen Sie hier mehr über MarketMind.

MarketMind hat sich seinen Platz verdient, indem es unerfahrenen Händlern eine Plattform bietet, die fragmentierte Marktdaten in klare Echtzeitsignale umwandelt. Anstatt Kursentwicklung, Fundamentaldaten, Stimmung und Volatilität über verschiedene Tools hinweg zu jonglieren, konsolidiert MarketMind all diese Informationen auf einer einzigen Plattform und hilft Händlern so, umsetzbare Erkenntnisse zu gewinnen. Dieses Projekt verwendete beim Erstellen seiner Agenten auch einige komplexe ES|QL-Abfragen.

So funktioniert es:

1. Marktdaten in Echtzeit erfassen

MarketMind bezieht Kursdaten, Fundamentaldaten, Stimmungsanalysen, Volatilitäts- und Risikokennzahlen von Yahoo Finance. Diese Daten werden erfasst und in mehreren Elasticsearch-Indizes organisiert.

2. Sechs spezialisierte Agenten analysieren den Markt.

Jeder mit Agent Builder erstellte Agent konzentriert sich auf eine andere Marktebene. Sie lesen Daten aus einem Elasticsearch-Index, berechnen ihre eigenen domänenspezifischen Metriken und generieren eine standardisierte JSON-Ausgabe mit Bewertungen und Begründungen.

3. Signale in einem einheitlichen „Marktenergie“-Modell aggregieren

Die kombinierten Ergebnisse erscheinen als leuchtende Impulse um jede Aktie herum und veranschaulichen, ob sich die Dynamik verstärkt, das Risiko steigt oder sich die Stimmung ändert.

4. Erkenntnisse visualisieren

Das Frontend wurde mit React und Next.js unter Verwendung von TypeScript, SVG-basierten physikbasierten Visualisierungen und Chart.js für Live-Candlestick-Charts erstellt. Dadurch wird die Rohanalyse in direkt umsetzbares Feedback in Echtzeit umgewandelt.

Weitere interessante Projekte:

Hier sind einige weitere starke Konkurrenten, die Elastic in verschiedenen Teilen ihres Technologie-Stacks eingesetzt haben:

Die vollständige Liste der Projekte, die in unserem Wettbewerb eingereicht wurden, finden Sie hier.

Was wir von Entwicklern gelernt haben

• Agent Builder ist benutzerfreundlich:

Die meisten Teams hatten Elastic noch nie zuvor benutzt und waren dennoch in der Lage, mit wenig Unterstützung schnell Agenten zu erstellen. Wir haben einen Workshop für diejenigen veranstaltet, die mehr Unterstützung benötigten, aber die meisten waren in der Lage, ihre Daten zu erfassen und einen Agenten zu erstellen, der Aktionen auf diesen Daten durchführt.

• LLMs sind hervorragend in kNN -Abfragen, benötigen aber dennoch Unterstützung bei der Generierung von ES|QL:

Die Aufforderung an ChatGPT-5, ES|QL-Abfragen zu generieren, lieferte falsche Informationen, wobei häufig ES|QL und SQL vermischt wurden. Die Bereitstellung der Dokumente in einer Markdown-Datei für das LLM schien eine praktikable Lösung zu sein.

• Nur für Snapshots verfügbare ES|QL-Funktionen in die Dokumentation gelangten:

Die kommenden Aggregationsfunktionen FIRST und LAST sind versehentlich in unsere ES|QL-Dokumentation eingeschlichen. Da wir diese Dokumente an ChatGPT übermittelt haben, nutzte das Modell diese Funktionen pflichtgemäß, obwohl sie in Serverless noch nicht verfügbar sind. Dank des Feedbacks der Gruppe hat das Entwicklungsteam schnell einen Fix erstellt und zusammengeführt, um die Funktionen aus der veröffentlichten Dokumentation zu entfernen (PR #137341).

• Fehlende Serverless-spezifische Anleitung:

Ein Team versuchte, LOOKUP JOIN für einen Index zu aktivieren, der nicht im Lookup-Modus erstellt wurde. Die Fehlermeldung veranlasste sie, Befehle zu verfolgen, die auf Serverless nicht existieren. Wir haben dies dem Produktteam mitgeteilt, das umgehend einen Fix für eine Serverless-spezifische, umsetzbare Fehlermeldung erstellt hat. Längerfristig besteht die Vision darin, die Komplexität der Neuindizierung vollständig zu verbergen (Problem #4838).

• Wert von Präsenzveranstaltungen:

Online-Hackathons sind toll, aber nichts kommt an den schnellen Feedback-Loop heran, den man erhält, wenn man Seite an Seite mit Entwicklern Fehler behebt. Wir haben beobachtet, wie Teams Agent Builder in verschiedenen Anwendungsfällen integriert haben, festgestellt, wo die Entwicklererfahrung mit ES|QL verbessert werden konnte, und Probleme viel schneller behoben, als dies über asynchrone Kanäle zu versuchen.

Fazit

Cal Hacks 12.0 bot uns mehr als ein Wochenende voller cooler Demos; es gab uns auch Einblick in die Art und Weise, wie neue Entwickler mit dem Elastic Stack interagieren. Innerhalb von nur 36 Stunden sahen wir, wie Teams Agent Builder einsetzten, Daten in Elasticsearch einspielten, Multiagentensysteme entwarfen und unsere Funktionen auf vielfältige Weise testeten. Die Veranstaltung erinnerte uns auch daran, warum Präsenzveranstaltungen so wichtig sind. Die schnellen Feedbackschleifen, die echten Gespräche und das praktische Debugging halfen uns, die aktuellen Bedürfnisse der Entwickler zu verstehen. Wir freuen uns darauf, das Gelernte an das Ingenieurteam weiterzugeben. Wir sehen uns beim nächsten Hackathon.

Dies ist der Begleitartikel zum Artikel „Erstellung eines LLM-Agent-Newsrooms mit A2A-Protokoll und MCP in Elasticsearch!“, in dem die Vorteile der Implementierung von A2A- und MCP-Architekturen innerhalb desselben Agenten erläutert wurden, um die einzigartigen Vorteile beider Frameworks voll auszuschöpfen. Ein Repository steht zur Verfügung, falls Sie die Demo selbst ausführen möchten.

Lassen Sie uns gemeinsam durchgehen, wie unsere Redakteure mithilfe von A2A und MCP zusammenarbeiten, um einen Nachrichtenartikel zu erstellen. Das zugehörige Repository, um die Agenten in Aktion zu sehen, finden Sie hier.

Schritt 1: Aufgabenstellung für die Geschichte

Der Nachrichtenchef (in der Rolle des Auftraggebers) vergibt eine Story:

Schritt 2: Der Reporter bittet um Recherche

Der Reporteragent erkennt, dass er Hintergrundinformationen benötigt und delegiert diese über A2A an den Rechercheagenten :

Schritt 3: Der Reporter bittet den Archivar um historischen Kontext.

Der Reporteragent erkennt, dass ein historischer Kontext die Geschichte stärken würde. Es delegiert über A2A an den Archivagenten (basierend auf dem A2A-Agenten von Elastic), um das Elasticsearch-basierte Artikelarchiv des Newsrooms zu durchsuchen:

Schritt 4: Der Archivierungsagent verwendet den Elastic A2A-Agenten mit MCP.

Der Archive Agent verwendet den A2A Agent von Elastic, der wiederum MCP nutzt, um auf die Elasticsearch-Tools zuzugreifen. Dies veranschaulicht die Hybridarchitektur, bei der A2A die Zusammenarbeit von Agenten ermöglicht, während MCP den Zugriff auf Werkzeuge bereitstellt:

Der Archivagent empfängt umfassende historische Daten vom A2A-Agenten von Elastic und sendet sie an den Reporter zurück:

Dieser Schritt demonstriert, wie sich der A2A-Agent von Elastic in den Workflow der Nachrichtenredaktion integriert. Der Archive Agent (ein speziell für Redaktionen entwickelter Agent) koordiniert sich mit dem A2A Agent von Elastic (einem Drittanbieter-Spezialisten), um die leistungsstarken Such- und Analysefunktionen von Elasticsearch optimal zu nutzen. Der Elastic-Agent nutzt intern MCP für den Zugriff auf Elasticsearch-Tools, was die klare Trennung zwischen Agentenkoordination (A2A) und Toolzugriff (MCP) verdeutlicht.

Schritt 5: Der Forscher nutzt MCP-Server

Der Forschungsagent greift auf mehrere MCP-Server zu, um Informationen zu sammeln:

Schritt 6: Der Forscher übermittelt die Daten an den Reporter.

Der Rechercheagent sendet die umfassenden Rechercheergebnisse über A2A zurück:

Schritt 7: Der Reporter schreibt einen Artikel

Der Reporteragent nutzt die Forschungsdaten und seine eigenen LLM-Fähigkeiten, um den Artikel zu schreiben. Beim Schreiben nutzt der Reporter die MCP-Server für Stil und Vorlagen:

Schritt 8: Geringes Vertrauen löst erneute Recherche aus

Der Reporteragent prüft den Entwurf und stellt fest, dass eine Behauptung nur geringes Vertrauen genießt. Es sendet eine weitere Anfrage an den Forschungsagenten:

Der Forscher überprüft die Behauptung mithilfe von Faktencheck-Servern von MCP und liefert aktualisierte Informationen zurück:

Schritt 9: Der Reporter überarbeitet den Text und reicht ihn beim Redakteur ein.

Der Reporter integriert die verifizierten Fakten und sendet den fertigen Entwurf per A2A an den Redaktionsagenten :

Schritt 10: Redaktionelle Überprüfungen mithilfe von MCP-Tools

Der Redaktionsagent nutzt mehrere MCP-Server zur Überprüfung des Artikels:

Der Redakteur genehmigt den Artikel und leitet ihn weiter:

Schritt 11: Der Herausgeber veröffentlicht über CI/CD

Schließlich veröffentlicht der Druckeragent den genehmigten Artikel mithilfe der MCP-Server für die CMS- und CI/CD-Pipeline:

Der Verlag bestätigt die Veröffentlichung via A2A:

Hier ist die vollständige Abfolge des A2A-Workflows im zugehörigen Repository unter Verwendung der oben beschriebenen Agenten.

#

Aus

Zu

Aktion

Protokoll

Beschreibung

1

Benutzer

Nachrichtenchef

Geschichte zuweisen

HTTP POST

Der Nutzer gibt Thema und Blickwinkel der Geschichte vor.

2

Nachrichtenchef

Intern

Geschichte erstellen

-

Erstellt einen Story-Datensatz mit eindeutiger ID

3

Nachrichtenchef

Reporter

Delegiertenzuweisung

A2A

Sendet die Story-Aufgabe über das A2A-Protokoll.

4

Reporter

Intern

Auftrag annehmen

-

Interne Zuordnung der Lagerbestände

5

Reporter

MCP-Server

Gliederung erstellen

MCP/HTTP

Erstellt Gliederungen für Artikel und Forschungsfragen

6a

Reporter

Forscher

Forschungsanfrage

A2A

Sendet Fragen (parallel zu 6b)

6b

Reporter

Archivar

Archiv durchsuchen

A2A JSONRPC

Durchsucht historische Artikel (parallel zu 6a)

7

Forscher

MCP-Server

Forschungsfragen

MCP/HTTP

Nutzt Anthropic über MCP, um Fragen zu beantworten

8

Forscher

Reporter

Forschung zurückgeben

A2A

Antworten zur Renditeforschung

9

Archivar

Elasticsearch

Suchindex

ES REST-API

Abfragen zum Nachrichtenarchivindex

10

Archivar

Reporter

Zurück zum Archiv

A2A JSONRPC

Gibt historische Suchergebnisse zurück

11

Reporter

MCP-Server

Artikel generieren

MCP/HTTP

Erstellt einen Artikel mit Recherche-/Archivkontext

12

Reporter

Intern

Entwurf speichern

-

Speichert den Entwurf intern.

13

Reporter

Nachrichtenchef

Entwurf einreichen

A2A

Reicht den fertigen Entwurf ein

14

Nachrichtenchef

Intern

Update zur Geschichte

-

Speichert den Entwurf, aktualisiert den Status auf "draft_submitted"

15

Nachrichtenchef

Editor

Entwurf prüfen

A2A

Automatische Weiterleitung an den Redakteur zur Überprüfung

16

Editor

MCP-Server

Rezensionsartikel

MCP/HTTP

Analysiert Inhalte mithilfe von Anthropic über MCP

17

Editor

Nachrichtenchef

Rückgabeprüfung

A2A

Sendet redaktionelles Feedback und Vorschläge

18

Nachrichtenchef

Intern

Ladenbewertung

-

Feedback der Ladenredaktion

19

Nachrichtenchef

Reporter

Änderungen anwenden

A2A

Feedback zur Routenbewertung an den Reporter

20

Reporter

MCP-Server

Änderungen anwenden

MCP/HTTP

Überarbeitet den Artikel basierend auf dem Feedback

21

Reporter

Intern

Entwurf aktualisieren

-

Aktualisiert den Entwurf mit den Überarbeitungen

22

Reporter

Nachrichtenchef

Rückgabe überarbeitet

A2A

Artikel über die Rückgabe überarbeitet

23

Nachrichtenchef

Intern

Update zur Geschichte

-

Die Geschäfte haben den Entwurf überarbeitet, der Status lautet nun „überarbeitet“.

24

Nachrichtenchef

Herausgeber

Artikel veröffentlichen

A2A

Automatische Weiterleitung zum Herausgeber

25

Herausgeber

MCP-Server

Tags generieren

MCP/HTTP

Erstellt Tags und Kategorien

26

Herausgeber

Elasticsearch

Indexartikel

ES REST-API

Indexiert Artikel im Nachrichtenarchivindex

27

Herausgeber

Dateisystem

Markdown speichern

Datei-E/A

Speichert den Artikel als .md-Datei Datei in /articles

28

Herausgeber

Nachrichtenchef

Veröffentlichung bestätigen

A2A

Rückgabestatus: Erfolgreich

29

Nachrichtenchef

Intern

Update zur Geschichte

-

Aktualisiert den Status der Story auf „veröffentlicht“.

Fazit

Sowohl A2A als auch MCP spielen eine wichtige Rolle im modernen erweiterten LLM-Infrastrukturparadigma. A2A bietet Flexibilität für komplexe Multiagentensysteme, jedoch potenziell geringere Portabilität und höhere operative Komplexität. MCP bietet einen standardisierten Ansatz für die Tool-Integration, der einfacher zu implementieren und zu warten ist, ist jedoch nicht für die Orchestrierung mehrerer Agenten ausgelegt.

Die Wahl ist nicht binär. Wie unser Beispiel aus der Redaktion zeigt, kombinieren die anspruchsvollsten und effektivsten LLM-gestützten Systeme oft beide Ansätze: Agenten koordinieren und spezialisieren sich über A2A-Protokolle, während sie über MCP-Server auf ihre Tools und Ressourcen zugreifen. Diese Hybridarchitektur bietet die organisatorischen Vorteile von Multiagentensystemen sowie die Standardisierungs- und Ökosystemvorteile von MCP. Dies deutet darauf hin, dass möglicherweise gar keine Wahlmöglichkeit besteht: Man könnte einfach beide als Standardansatz verwenden.

Es liegt an Ihnen als Entwickler oder Architekt, die beste Mischung beider Lösungen zu testen und zu ermitteln, um das richtige Ergebnis für Ihren spezifischen Anwendungsfall zu erzielen. Das Verständnis der Stärken, Grenzen und geeigneten Anwendungsbereiche der einzelnen Ansätze ermöglicht es Ihnen, effektivere, wartungsfreundlichere und skalierbare KI-Systeme zu entwickeln.

Egal, ob Sie eine digitale Nachrichtenredaktion, eine Kundenserviceplattform, einen Forschungsassistenten oder eine andere LLM-gestützte Anwendung entwickeln – die sorgfältige Berücksichtigung Ihrer Koordinierungsbedürfnisse (A2A) und Ihrer Anforderungen an den Werkzeugzugriff (MCP) wird Sie auf den Weg zum Erfolg führen.

Weitere Ressourcen

• Elasticsearch Agent Builder: https://www.elastic.co/docs/solutions/search/elastic-agent-builder

• A2A-Spezifikation: https://a2a-protocol.org/latest/specification/

• A2A- und MCP-Integration: https://a2a-protocol.org/latest/topics/a2a-and-mcp/

• Model Context Protocol: https://modelcontextprotocol.io

Eine neue Art der Interaktion mit Daten

Generative KI (genAI) und agentenbasierte KI gehen anders vor als die traditionelle Suche. Während wir früher mit der Informationssuche durch eine Suche begannen („Lass mich das mal googeln…“), erfolgt die erste Aktion sowohl bei generischer KI als auch bei Agenten in der Regel durch die Eingabe von natürlicher Sprache in eine Chat-Oberfläche. Die Chat-Oberfläche ist eine Diskussion mit einem LLM, der sein semantisches Verständnis nutzt, um unsere Frage in eine destillierte Antwort umzuwandeln, eine zusammenfassende Antwort, die scheinbar von einem Orakel stammt, das über ein breites Wissen über alle Arten von Informationen verfügt. Was den LLM wirklich auszeichnet, ist seine Fähigkeit, kohärente, durchdachte Sätze zu formulieren, die die einzelnen Wissensfragmente miteinander verknüpfen – selbst wenn diese ungenau oder völlig realitätsfern sind, steckt doch ein Körnchen Wahrheit darin.

Die alte Suchleiste, mit der wir so vertraut geworden sind, kann man sich als die Ampelmaschine vorstellen, die wir benutzt haben, als wir selbst der denkende Agent waren. Inzwischen wandeln sogar Internet-Suchmaschinen unsere altbekannte, mühsame Suche nach Wörtern in KI-gesteuerte Übersichten um, die die Anfrage mit einer Zusammenfassung der Ergebnisse beantworten und den Nutzern so die Notwendigkeit ersparen, sich durch die einzelnen Ergebnisse zu klicken und diese selbst zu bewerten.

Generative KI & RAG

Generative KI versucht, mithilfe ihres semantischen Verständnisses der Welt die in einer Chatanfrage geäußerte subjektive Absicht zu analysieren und anschließend mithilfe ihrer Schlussfolgerungsfähigkeiten spontan eine Expertenantwort zu erstellen. Eine generative KI-Interaktion besteht aus mehreren Teilen: Sie beginnt mit der Eingabe/Anfrage des Benutzers, frühere Konversationen in der Chat-Sitzung können als zusätzlicher Kontext verwendet werden, und die Anweisung gibt dem LLM vor, wie er argumentieren und welche Verfahren er bei der Erstellung der Antwort befolgen soll. Die Hilfestellungen haben sich von einfachen Erklärungen im Stil von „Erkläre es mir so, als wäre ich fünf Jahre alt“ zu vollständigen Anleitungen für die Bearbeitung von Anfragen weiterentwickelt. Diese Aufschlüsselungen enthalten oft separate Abschnitte, die Details zur Persona/Rolle der KI, zum vor der Generierung stattfindenden Denkprozess/internen Denkprozess, zu objektiven Kriterien, Einschränkungen, zum Ausgabeformat, zur Zielgruppe sowie Beispiele zur Veranschaulichung der zu erwartenden Ergebnisse beschreiben.

Zusätzlich zur Benutzeranfrage und der Systemaufforderung liefert Retrieval Augmented Generation (RAG) weitere Kontextinformationen in einem sogenannten „Kontextfenster“. RAG war eine entscheidende Ergänzung der Architektur; wir nutzen es, um das LLM über die fehlenden Puzzleteile in seinem semantischen Verständnis der Welt zu informieren.

Kontextfenster können ziemlich pingelig sein, wenn es darum geht, was, wo und wie viel man ihnen gibt. Welcher Kontext ausgewählt wird, ist natürlich sehr wichtig, aber auch das Signal-Rausch-Verhältnis des bereitgestellten Kontexts sowie die Länge des Fensters spielen eine Rolle.

Zu wenige Informationen

Werden in einer Abfrage, einer Eingabeaufforderung oder einem Kontextfenster zu wenige Informationen angegeben, kann dies zu Halluzinationen führen, da das LLM den korrekten semantischen Kontext für die Generierung einer Antwort nicht genau bestimmen kann. Es gibt auch Probleme mit der Vektorähnlichkeit der Dokumentabschnittsgrößen – eine kurze, einfache Frage passt möglicherweise nicht semantisch zu den umfangreichen, detaillierten Dokumenten in unseren vektorisierten Wissensdatenbanken. Es wurden Techniken zur Erweiterung von Anfragen entwickelt, wie zum Beispiel Hypothetical Document Embeddings (HyDE) , die LLMs verwenden, um eine hypothetische Antwort zu generieren, die reichhaltiger und ausdrucksstärker ist als die kurze Anfrage. Die Gefahr hierbei ist natürlich, dass das hypothetische Dokument selbst eine Halluzination ist, die den LLM noch weiter vom richtigen Kontext entfernt.

Zu viele Informationen

Genau wie bei uns Menschen kann eine zu große Informationsmenge in einem Kontextfenster auch einen LLM überfordern und verwirren, sodass er nicht mehr weiß, was die wichtigen Teile sein sollen. Kontextüberlauf (oder „ Kontextverfall“) beeinträchtigt die Qualität und Leistung generativer KI-Operationen; er wirkt sich stark auf das „Aufmerksamkeitsbudget“ (das Arbeitsgedächtnis) des LLM aus und verwässert die Relevanz über viele konkurrierende Token hinweg. Zum Konzept der „Kontextverrottung“ gehört auch die Beobachtung, dass LLMs tendenziell eine Positionsverzerrung aufweisen – sie bevorzugen den Inhalt am Anfang oder Ende eines Kontextfensters gegenüber dem Inhalt im mittleren Abschnitt.

Ablenkende oder widersprüchliche Informationen

Je größer das Kontextfenster wird, desto größer ist die Wahrscheinlichkeit, dass es überflüssige oder widersprüchliche Informationen enthält, die das LLM davon ablenken können, den richtigen Kontext auszuwählen und zu verarbeiten. In gewisser Hinsicht wird es zu einem Problem von Müll rein/Müll raus: Wenn man einfach eine Reihe von Dokumentenergebnissen in ein Kontextfenster einfügt, erhält das LLM eine Menge Informationen zum Verarbeiten (möglicherweise zu viele), aber je nachdem, wie der Kontext ausgewählt wurde, besteht eine größere Wahrscheinlichkeit, dass widersprüchliche oder irrelevante Informationen einfließen.

Agentische KI

Ich hatte es Ihnen ja gesagt, es gäbe noch viel zu besprechen, aber wir haben es geschafft – wir sprechen jetzt endlich über agentenbasierte KI-Themen! Agentic AI ist eine sehr spannende neue Anwendung von LLM-Chat-Schnittstellen, die die Fähigkeit generativer KI (können wir sie schon als „Legacy“ bezeichnen?) erweitert, Antworten auf der Grundlage ihres eigenen Wissens und der von Ihnen bereitgestellten Kontextinformationen zu synthetisieren. Mit zunehmender Reife der generativen KI wurde uns bewusst, dass es ein gewisses Maß an Aufgaben und Automatisierung gibt, die LLMs übernehmen können, zunächst beschränkt auf mühsame, risikoarme Tätigkeiten, die leicht von einem Menschen überprüft/validiert werden können. Innerhalb kurzer Zeit erweiterte sich dieser anfängliche Umfang: Ein LLM-Chatfenster kann nun der Funke sein, der einen KI-Agenten dazu veranlasst, autonom zu planen, auszuführen und iterativ zu evaluieren und anzupassen, um sein festgelegtes Ziel zu erreichen. Die Agenten haben Zugriff auf die Schlussfolgerungen ihrer LLMs, den Chatverlauf und das Denkvermögen (sofern vorhanden) und verfügen außerdem über spezielle Werkzeuge, die sie zu diesem Zweck einsetzen können. Wir sehen jetzt auch Architekturen, die es einem übergeordneten Agenten ermöglichen, als Orchestrator mehrerer Unteragenten zu fungieren, von denen jeder über eigene Logikketten, Befehlssätze, Kontext und Werkzeuge verfügt.

Die Agenten sind der Einstiegspunkt in einen weitgehend automatisierten Arbeitsablauf: Sie arbeiten selbstständig, indem sie mit einem Benutzer chatten und dann mithilfe von „Logik“ ermitteln, welche Tools zur Beantwortung der Frage des Benutzers zur Verfügung stehen. Werkzeuge gelten im Vergleich zu Agenten üblicherweise als passiv und sind darauf ausgelegt, nur eine bestimmte Art von Aufgabe zu erfüllen. Die Aufgaben , die ein Tool ausführen kann, sind quasi unbegrenzt (was wirklich spannend ist!), aber eine Hauptaufgabe von Tools besteht darin, Kontextinformationen zu sammeln, die ein Agent bei der Ausführung seines Arbeitsablaufs berücksichtigen kann.

Als Technologie steckt agentenbasierte KI noch in den Kinderschuhen und ist anfällig für das LLM-Äquivalent einer Aufmerksamkeitsdefizitstörung – sie vergisst leicht, was sie tun sollte, und macht oft andere Dinge, die überhaupt nicht Teil der Aufgabenstellung waren. Hinter der scheinbaren Magie verbergen sich die „logischen“ Fähigkeiten von LLMs, die darauf beruhen, das nächste wahrscheinlichste Token in einer Sequenz vorherzusagen. Damit logisches Denken (oder eines Tages künstliche allgemeine Intelligenz (AGI)) zuverlässig und vertrauenswürdig wird, müssen wir überprüfen können, ob es bei der Bereitstellung korrekter und aktueller Informationen so argumentiert, wie wir es erwarten (und uns vielleicht noch das kleine Quäntchen mehr liefert, an das wir selbst nicht gedacht hätten). Damit dies gelingt, benötigen agentenbasierte Architekturen die Fähigkeit, klar zu kommunizieren (Protokolle), sich an die von uns vorgegebenen Arbeitsabläufe und Einschränkungen zu halten (Leitplanken), sich zu merken, wo sie sich in einer Aufgabe befinden (Zustand), ihren verfügbaren Speicherplatz zu verwalten und zu überprüfen, ob ihre Antworten korrekt sind und die Aufgabenkriterien erfüllen.

Sprich mit mir in einer Sprache, die ich verstehen kann.

Wie es in neuen Entwicklungsbereichen üblich ist (insbesondere in der Welt der LLMs), gab es anfänglich eine ganze Reihe von Ansätzen für die Kommunikation zwischen Agent und Werkzeug, aber sie einigten sich schnell auf das Model Context Protocol (MCP) als De-facto-Standard. Die Definition des Model Context Protocol steckt bereits im Namen – es ist das Protokoll, das ein Modell verwendet, um Kontextinformationen anzufordern und zu empfangen. MCP fungiert als universeller Adapter für LLM-Agenten, um Verbindungen zu externen Tools und Datenquellen herzustellen; es vereinfacht und standardisiert die APIs, sodass verschiedene LLM-Frameworks und -Tools problemlos interoperabel sind. Das macht MCP zu einer Art Dreh- und Angelpunkt zwischen der Orchestrierungslogik und den Systemaufforderungen, die einem Agenten zur autonomen Ausführung im Dienste seiner Ziele gegeben werden, und den Operationen, die an Werkzeuge gesendet werden, um sie isolierter auszuführen (zumindest isoliert in Bezug auf den initiierenden Agenten).

Dieses Ökosystem ist so neu, dass sich jede Expansionsrichtung wie ein neues Terrain anfühlt. Wir verfügen über ähnliche Protokolle für Agent-zu-Agent-Interaktionen (Agent2Agent (A2A) natürlich!) sowie über andere Projekte zur Verbesserung des Agenten-Schlussfolgerungsgedächtnisses (ReasoningBank), zur Auswahl des besten MCP-Servers für die jeweilige Aufgabe (RAG-MCP) und zur Verwendung semantischer Analysen wie Zero-Shot-Klassifizierung und Mustererkennung bei Ein- und Ausgaben als Leitplanken , um zu steuern, worauf ein Agent zugreifen darf.

Möglicherweise ist Ihnen aufgefallen, dass das zugrundeliegende Ziel jedes dieser Projekte darin besteht, die Qualität und Kontrolle der Informationen zu verbessern, die an ein Agenten-/genAI-Kontextfenster zurückgegeben werden? Während das agentenbasierte KI-Ökosystem seine Fähigkeit zur besseren Verarbeitung dieser Kontextinformationen stetig weiterentwickelt (um sie zu kontrollieren, zu verwalten und darauf zu reagieren), wird es immer notwendig sein, die relevantesten Kontextinformationen als Grundlage für die Aktionen des Agenten abzurufen.

Willkommen im Kontext-Engineering!

Wer mit Begriffen aus dem Bereich der generativen KI vertraut ist, hat wahrscheinlich schon von „Prompt Engineering“ gehört – mittlerweile ist es fast schon eine eigene Pseudowissenschaft. Prompt Engineering wird eingesetzt, um die besten und effizientesten Wege zu finden, die Verhaltensweisen, die das LLM bei der Generierung seiner Antwort verwenden soll, proaktiv zu beschreiben. „Context Engineering “ erweitert die Techniken des „Prompt Engineering“ über die Agentenseite hinaus und umfasst auch verfügbare Kontextquellen und -systeme auf der Werkzeugseite des MCP-Protokolls sowie die umfassenden Themen Kontextmanagement, -verarbeitung und -generierung:

• Kontextmanagement – Bezieht sich auf die Aufrechterhaltung der Zustands- und Kontexteffizienz in langlaufenden und/oder komplexeren agentenbasierten Arbeitsabläufen. Iterative Planung, Nachverfolgung und Orchestrierung von Aufgaben und Werkzeugaufrufen zur Erreichung der Ziele des Agenten. Da Agenten nur über ein begrenztes „Aufmerksamkeitsbudget“ verfügen, befasst sich das Kontextmanagement hauptsächlich mit Techniken, die dazu beitragen, das Kontextfenster so zu verfeinern, dass sowohl der größtmögliche Umfang als auch die wichtigsten Kontextinformationen erfasst werden (Präzision versus Trefferquote!). Zu den Techniken gehören Komprimierung, Zusammenfassung und Beibehaltung des Kontextes aus vorherigen Schritten oder Werkzeugaufrufen, um im Arbeitsspeicher Platz für zusätzlichen Kontext in nachfolgenden Schritten zu schaffen.

• Kontextverarbeitung – Die logischen und hoffentlich größtenteils programmatischen Schritte zur Integration, Normalisierung oder Verfeinerung des aus unterschiedlichen Quellen gewonnenen Kontextes, damit der Agent den gesamten Kontext auf eine einigermaßen einheitliche Weise verarbeiten kann. Die grundlegende Aufgabe besteht darin, Kontext aus allen Quellen (Eingabeaufforderungen, RAG-System, Speicher usw.) so aufzubereiten, dass er vom Agenten möglichst effizient genutzt werden kann.

• Kontextgenerierung – Wenn es bei der Kontextverarbeitung darum geht, den abgerufenen Kontext für den Agenten nutzbar zu machen, dann gibt die Kontextgenerierung dem Agenten die Möglichkeit, diese zusätzlichen Kontextinformationen nach Belieben, aber auch unter bestimmten Einschränkungen, anzufordern und zu empfangen.

Die verschiedenen Elemente von LLM-Chatanwendungen lassen sich direkt (und manchmal auch überlappend) auf jene übergeordneten Funktionen des Kontextmanagements abbilden:

• Anweisungen / Systemaufforderung - Die Aufforderungen dienen als Gerüst dafür, wie die generative (oder agentenbasierte) KI-Aktivität ihr Denken auf die Erreichung des Ziels des Benutzers ausrichtet. Eingabeaufforderungen stellen einen eigenen Kontext dar; sie sind nicht nur tonale Anweisungen – sie beinhalten häufig auch Logik zur Aufgabenausführung und Regeln für Dinge wie „Schritt für Schritt nachdenken“ oder „tief durchatmen“, bevor man antwortet, um sicherzustellen, dass die Antwort die Anfrage des Benutzers vollständig erfüllt. Jüngste Tests haben gezeigt, dass Auszeichnungssprachen sehr effektiv sind, um die verschiedenen Teile einer Aufgabenstellung zu strukturieren. Es sollte jedoch darauf geachtet werden, die Anweisungen so zu formulieren, dass sie weder zu vage noch zu spezifisch sind; wir wollen dem LLM genügend Anweisungen geben, um den richtigen Kontext zu finden, aber nicht so präskriptiv sein, dass es unerwartete Erkenntnisse verpasst.

• Kurzzeitgedächtnis (Zustand/Verlauf) - Das Kurzzeitgedächtnis umfasst im Wesentlichen die Interaktionen der Chat-Sitzung zwischen dem Benutzer und dem LLM. Diese sind nützlich, um den Kontext in Live-Sitzungen zu verfeinern, und können zur späteren Verwendung und Fortsetzung gespeichert werden.

• Langzeitgedächtnis – Das Langzeitgedächtnis sollte Informationen enthalten, die über mehrere Sitzungen hinweg nützlich sind. Und es geht nicht nur um domänenspezifische Wissensdatenbanken, auf die über RAG zugegriffen wird; neuere Forschungen nutzen die Ergebnisse vorheriger agentischer/generativer KI-Anfragen, um innerhalb aktueller agentischer Interaktionen zu lernen und darauf zu verweisen. Zu den interessantesten Innovationen im Bereich des Langzeitgedächtnisses gehören solche, die die Art und Weise der Speicherung und Verknüpfung von Zuständen so anpassen, dass Agenten dort weitermachen können, wo sie aufgehört haben.

• Strukturierte Ausgabe - Kognition erfordert Anstrengung, daher ist es wohl keine Überraschung, dass LLMs (genau wie Menschen) selbst mit Denkfähigkeiten beim Denken weniger Anstrengung aufwenden wollen, und in Ermangelung einer definierten API oder eines Protokolls ist eine Karte (ein Schema) für das Lesen der von einem Toolaufruf zurückgegebenen Daten äußerst hilfreich. Die Einbeziehung strukturierter Ausgaben in das agentenbasierte Framework trägt dazu bei, diese Interaktionen zwischen Maschinen schneller und zuverlässiger zu gestalten, wodurch weniger gedankengesteuertes Parsen erforderlich wird.

• Verfügbare Tools – Tools können die unterschiedlichsten Aufgaben übernehmen, von der Erfassung zusätzlicher Informationen (z. B. durch Abfragen von Unternehmensdatenbanken mittels RAG-Code oder über Online-APIs) bis hin zur Durchführung automatisierter Aktionen im Auftrag des Agenten (z. B. durch Buchung eines Hotelzimmers auf Basis der Kriterien der Anfrage des Agenten). Werkzeuge könnten auch Unteragenten mit eigenen agentenbasierten Verarbeitungsketten sein.

• Retrieval Augmented Generation (RAG) – Mir gefällt die Beschreibung von RAG als „dynamische Wissensintegration“ sehr gut. Wie bereits erwähnt, ist RAG die Technik, um die zusätzlichen Informationen bereitzustellen, auf die das LLM beim Training keinen Zugriff hatte, oder es ist eine Wiederholung der Ideen, die wir für am wichtigsten halten, um die richtige Antwort zu erhalten – diejenige, die am relevantesten für unsere subjektive Anfrage ist.

Phänomenale kosmische Energie, winziger Wohnraum!

Agentic AI bietet so viele faszinierende und aufregende neue Welten zum Erkunden! Es gibt zwar noch viele der alten, traditionellen Probleme der Datenbeschaffung und -verarbeitung zu lösen, aber auch ganz neue Herausforderungen, die erst jetzt im neuen Zeitalter der LLMs ans Licht der Öffentlichkeit treten. Viele der aktuellen Probleme, mit denen wir uns heute auseinandersetzen, hängen mit Kontextgestaltung zusammen, also damit, wie man Lernlern die zusätzlichen Kontextinformationen bereitstellt, die sie benötigen, ohne ihren begrenzten Arbeitsgedächtnisraum zu überlasten.

Die Flexibilität von halbautonomen Agenten, die Zugriff auf eine Reihe von Werkzeugen (und andere Agenten) haben, führt zu so vielen neuen Ideen für die Implementierung von KI, dass es schwer ist, sich die verschiedenen Möglichkeiten vorzustellen, wie wir die einzelnen Teile zusammensetzen könnten. Der Großteil der aktuellen Forschung fällt in den Bereich des Kontext-Engineerings und konzentriert sich auf den Aufbau von Speichermanagementstrukturen, die größere Mengen an Kontext verarbeiten und verfolgen können – denn die tiefgründigen Denkprobleme, die wir mit LLMs lösen wollen, weisen eine erhöhte Komplexität und länger andauernde, mehrphasige Denkprozesse auf, bei denen das Erinnern von extrem großer Bedeutung ist.

Viele der laufenden Experimente auf diesem Gebiet versuchen, die optimale Aufgabenverwaltung und Werkzeugkonfigurationen zu finden, um den agentenbasierten Schlund zu füttern. Jeder Werkzeugaufruf in der Argumentationskette eines Agenten verursacht kumulative Kosten, sowohl hinsichtlich des Rechenaufwands zur Ausführung der Funktion dieses Werkzeugs als auch der Auswirkungen auf das begrenzte Kontextfenster. Einige der neuesten Techniken zur Kontextverwaltung für LLM-Agenten haben unbeabsichtigte Ketteneffekte wie den „ Kontextkollaps“ verursacht, bei dem die Komprimierung/Zusammenfassung des akkumulierten Kontexts für langlaufende Aufgaben zu verlustbehaftet wird. Das angestrebte Ergebnis sind Werkzeuge, die einen prägnanten und genauen Kontext liefern, ohne dass überflüssige Informationen in den wertvollen Speicherplatz des Kontextfensters eindringen.

So viele/zu viele Möglichkeiten

Wir wollen eine klare Aufgabentrennung mit der Flexibilität, Werkzeuge/Komponenten wiederzuverwenden. Daher ist es absolut sinnvoll, dedizierte Agentenwerkzeuge für die Verbindung mit bestimmten Datenquellen zu entwickeln – jedes Werkzeug kann sich auf die Abfrage eines bestimmten Repository-Typs, eines bestimmten Datenstroms oder sogar eines bestimmten Anwendungsfalls spezialisieren. Aber Vorsicht: Im Bestreben, Zeit/Geld zu sparen/zu beweisen, dass etwas möglich ist, wird die Versuchung groß sein, LLMs als Instrument der Föderation zu nutzen… Versuchen Sie, das zu vermeiden, wir haben das schon einmal erlebt ! Die föderierte Abfrage fungiert als „universeller Übersetzer“, der eine eingehende Abfrage in die Syntax umwandelt, die das entfernte Repository versteht, und anschließend die Ergebnisse aus mehreren Quellen zu einer kohärenten Antwort zusammenführen muss. Die Federation als Technik funktioniert im kleinen Maßstab ganz gut , aber im großen Maßstab und insbesondere bei multimodalen Daten versucht die Federation, Lücken zu schließen, die einfach zu groß sind.

In der agentenbasierten Welt wäre der Agent der Föderator und die Werkzeuge (über MCP) wären die manuell definierten Verbindungen zu unterschiedlichen Ressourcen. Der Einsatz spezieller Tools zur Erfassung unverbundener Datenquellen mag zwar ein vielversprechender neuer Ansatz sein, um verschiedene Datenströme dynamisch pro Abfrage zu vereinen, doch die Verwendung von Tools, um dieselbe Frage an mehrere Quellen zu stellen, wird wahrscheinlich mehr Probleme verursachen als lösen. Bei jeder dieser Datenquellen handelt es sich wahrscheinlich um einen anderen Typ von Datenspeicher, der jeweils über eigene Funktionen zum Abrufen, Sortieren und Sichern der darin enthaltenen Daten verfügt. Diese Abweichungen oder „Impedanzfehlanpassungen“ zwischen den Repositories erhöhen natürlich die Verarbeitungslast. Außerdem können sie widersprüchliche Informationen oder Signale einbringen, wobei etwas so scheinbar Harmloses wie eine Fehlausrichtung der Bewertung die Bedeutung, die einem Teil des zurückgegebenen Kontextes beigemessen wird, stark beeinträchtigen und letztendlich die Relevanz der generierten Antwort beeinflussen kann.

Auch für Computer ist der Kontextwechsel schwierig.

Wenn man einen Agenten auf eine Mission schickt, besteht seine erste Aufgabe oft darin, alle relevanten Daten zu finden, auf die er Zugriff hat. Genau wie bei Menschen entsteht auch bei uns eine kognitive Belastung, wenn jede Datenquelle, mit der der Agent eine Verbindung herstellt, unterschiedliche und disaggregierte Antworten liefert. Diese Belastung entsteht durch das Herausfiltern der relevanten Kontextinformationen aus den abgerufenen Inhalten. Das braucht Zeit/Rechenleistung, und jedes kleine bisschen summiert sich in der agentenbasierten Logikkette. Daraus lässt sich schließen, dass, ähnlich wie bei MCP, die meisten agentenbasierten Werkzeuge sich eher wie APIs verhalten sollten – isolierte Funktionen mit bekannten Ein- und Ausgaben, die auf die Bedürfnisse verschiedener Agententypen abgestimmt sind. Wir stellen sogar fest, dass LLMs Kontext für Kontext benötigen – sie sind viel besser darin, die semantischen Punkte zu verbinden, insbesondere wenn es um eine Aufgabe wie die Übersetzung von natürlicher Sprache in strukturierte Syntax geht, wenn sie ein Schema haben, auf das sie sich beziehen können (RTFM in der Tat!).

Pause im 7. Inning!

Wir haben nun die Auswirkungen von LLMs auf das Abrufen und Abfragen von Daten sowie die Entwicklung des Chatfensters hin zu einer agentenbasierten KI-Erfahrung behandelt. Lasst uns die beiden Themen miteinander verknüpfen und sehen, wie wir unsere neuartigen Such- und Abruffunktionen nutzen können, um unsere Ergebnisse im Bereich Context Engineering zu verbessern. Weiter zu Teil III: Die Leistungsfähigkeit der hybriden Suche im Kontext-Engineering!

Die derzeitigen LLM-gestützten Systeme entwickeln sich rasant über Einzelmodellanwendungen hinaus zu komplexen Netzwerken, in denen spezialisierte Agenten zusammenarbeiten, um Aufgaben zu bewältigen, die mit modernen Computern bisher für unmöglich gehalten wurden. Mit zunehmender Komplexität dieser Systeme rückt die Infrastruktur, die die Kommunikation der Agenten und den Zugriff auf Werkzeuge ermöglicht, in den Mittelpunkt der Entwicklung. Zur Erfüllung dieser Anforderungen haben sich zwei komplementäre Ansätze herausgebildet: Agent2Agent (A2A) -Protokolle für die Koordination mehrerer Agenten und das Model Context Protocol (MCP) für den standardisierten Zugriff auf Werkzeuge und Ressourcen.

Das Verständnis dafür, wann man die einzelnen Elemente harmonisch miteinander und wann man sie ohne die anderen einsetzt, kann die Skalierbarkeit, Wartbarkeit und Effektivität Ihrer Anwendungen erheblich beeinflussen. Dieser Artikel untersucht die Konzepte und Implementierungen von A2A am praktischen Beispiel einer digitalen Nachrichtenredaktion, in der spezialisierte LLM-Agenten zusammenarbeiten, um Nachrichtenartikel zu recherchieren, zu schreiben, zu bearbeiten und zu veröffentlichen.

Ein zugehöriges Repository finden Sie hier, und konkrete Beispiele für A2A in der Praxis werden wir gegen Ende des Artikels in Abschnitt 5 untersuchen.

Voraussetzungen

Das Repository besteht aus Python-basierten Implementierungen der A2A-Agenten. Flask stellt einen API-Server sowie einen benutzerdefinierten Python-Messaging-Dienst namens Event Hub bereit, der Nachrichten für die Protokollierung und UI-Aktualisierungen weiterleitet. Schließlich wird eine React-Benutzeroberfläche für die eigenständige Nutzung der Newsroom-Funktionen bereitgestellt. Alles ist zur einfacheren Implementierung in einem Docker-Image enthalten. Wenn Sie die Dienste direkt auf Ihrem Rechner ausführen möchten, sollten Sie sicherstellen, dass die folgenden Technologien installiert sind:

Sprachen und Laufzeiten

• Python 13.12 – Kern-Backend-Sprache

• Node.js 18+ - Optionale React-Benutzeroberfläche

Kern-Frameworks und SDKs:

• A2A SDK 0.3.8 – Agentenkoordination und -kommunikation

• Anthropic SDK - Claude-Integration für die KI-Generierung

• Uvicorn – ASGI-Server zum Ausführen von Agenten

• FastMCP 2.12.5+ - MCP-Server-Implementierung

• React 18.2 – Frontend-UI-Framework

Daten & Suche

• Elasticsearch 9.1.1+ - Artikelindexierung und -suche

Docker-Bereitstellung (optional, aber empfohlen)

• Docker 28.5.1+

Abschnitt 1: Was ist Agent2Agent (A2A)?

Definition und Kernkonzepte

Agent2Agent (A2A) ist ein standardisiertes Protokoll für die Interaktion zwischen unabhängigen LLM-Agenten. Anstatt eines einzigen monolithischen Systems, das alle Aufgaben übernimmt, ermöglicht A2A mehreren spezialisierten Agenten die Kommunikation, Koordination und Zusammenarbeit, um komplexe Arbeitsabläufe zu bewältigen, die für einen einzelnen Agenten schwierig, langsam oder gar unmöglich effizient zu handhaben wären.

Offizielle Spezifikation: https://a2a-protocol.org/latest/specification/

Ursprung und Evolution

Das Konzept der Agent2Agent-Kommunikation bzw. von Multiagentensystemen hat seine Wurzeln in der Forschung zu verteilten Systemen, Microservices und Multiagentensystemen, die Jahrzehnte zurückreicht. Frühe Arbeiten im Bereich der verteilten künstlichen Intelligenz legten den Grundstein für Agenten, die verhandeln, koordinieren und zusammenarbeiten können. Diese frühen Systeme dienten der Durchführung groß angelegter sozialer Simulationen, der akademischen Forschung und dem Management von Stromnetzen.

Mit der Verfügbarkeit von LLM und den gesunkenen Betriebskosten wurden Multiagentensysteme auch für den „Prosumer“-Markt zugänglich, unterstützt von Google und der breiteren KI-Forschungsgemeinschaft. Die Einführung des A2A-Protokolls, die heute als Agent2Agent-Systeme bekannt ist, hat sich zu einem modernen Standard entwickelt, der speziell für das Zeitalter mehrerer großer Sprachmodelle konzipiert wurde, die ihre Bemühungen und Aufgaben koordinieren.

Das A2A-Protokoll gewährleistet eine reibungslose Kommunikation und Koordination zwischen den Agenten, indem es einheitliche Standards und Prinzipien an den Interaktionspunkten anwendet, an denen LLMs sich verbinden und kommunizieren. Diese Standardisierung ermöglicht es Agenten verschiedener Entwickler – die unterschiedliche zugrunde liegende Modelle verwenden – effektiv zusammenzuarbeiten.

Kommunikationsprotokolle sind nicht neu und haben sich in nahezu jeder digitalen Transaktion im Internet fest etabliert. Wenn Sie https://www.elastic.co/search-labs eingegeben haben Wenn Sie einen Browser verwenden, um diesen Artikel zu erreichen, ist die Wahrscheinlichkeit hoch, dass alle TCP/IP-, HTTP-Transport- und DNS-Lookup-Protokolle ausgeführt wurden, um ein konsistentes Browsererlebnis für uns zu gewährleisten.

Hauptmerkmale

A2A-Systeme basieren auf mehreren grundlegenden Prinzipien, um eine reibungslose Kommunikation zu gewährleisten. Aufbauend auf diesen Prinzipien wird sichergestellt, dass verschiedene Agenten, die auf unterschiedlichen LLMs, Frameworks und Programmiersprachen basieren, nahtlos miteinander interagieren.

Hier sind die vier Hauptprinzipien:

• Nachrichtenübermittlung: Agenten kommunizieren über strukturierte Nachrichten mit klar definierten Eigenschaften und Formaten.

• Koordination: Agenten orchestrieren komplexe Arbeitsabläufe, indem sie Aufgaben untereinander delegieren und Abhängigkeiten verwalten, ohne andere Agenten zu blockieren.

• Spezialisierung: Jeder Agent konzentriert sich auf einen bestimmten Bereich oder eine bestimmte Fähigkeit, wird Experte auf seinem Gebiet und bietet Aufgabenerledigung basierend auf diesen Fähigkeiten an.

• Verteilter Zustand: Zustand und Wissen sind auf mehrere Agenten verteilt und nicht zentralisiert. Die Agenten können sich gegenseitig über den Fortschritt des Aufgabenstatus und Teilergebnisse (Artefakte) informieren.

Die Redaktion: Ein laufendes Beispiel

Stellen Sie sich eine digitale Nachrichtenredaktion vor, die von KI-Agenten gesteuert wird, von denen jeder auf einen anderen Aspekt des Journalismus spezialisiert ist:

• Nachrichtenchef (Koordinator/Kunde): Vergibt Artikel und überwacht den Arbeitsablauf.

• Reporteragent: Verfasst Artikel auf Grundlage von Recherchen und Interviews.

• Rechercheagent: Sammelt Fakten, Statistiken und Hintergrundinformationen.

• Archivagent: Durchsucht historische Artikel und identifiziert Trends mithilfe von Elasticsearch.

• Redaktionsassistent: Überprüft Artikel auf Qualität, Stil und Suchmaschinenoptimierung.

• Verlagsagent: Veröffentlicht freigegebene Artikel über CI/CD auf der Blog-Plattform.

Diese Akteure arbeiten nicht isoliert; wenn der Nachrichtenchef einen Artikel über die Einführung erneuerbarer Energien in Auftrag gibt, benötigt der Reporter den Rechercheur, um Statistiken zu sammeln, den Redakteur, um den Entwurf zu überprüfen, und den Verleger, um den endgültigen Artikel zu veröffentlichen. Diese Koordination erfolgt über A2A-Protokolle.

Abschnitt 2: A2A-Architektur verstehen

Kundenbetreuer- und Fernbetreuerrollen

In der A2A-Architektur übernehmen Agenten zwei Hauptrollen. Der Kundenbetreuer ist dafür verantwortlich, Aufgaben zu formulieren und an andere Betreuer im System zu kommunizieren. Es identifiziert Remote-Agenten und deren Fähigkeiten und nutzt diese Informationen, um fundierte Entscheidungen über die Aufgabenverteilung zu treffen. Der Kundenbetreuer koordiniert den gesamten Arbeitsablauf und sorgt dafür, dass die Aufgaben ordnungsgemäß verteilt werden und das System seine Ziele erreicht.

Der Remote Agent hingegen erledigt Aufgaben, die ihm von Clients übertragen werden. Es stellt Informationen bereit oder ergreift konkrete Maßnahmen als Reaktion auf Anfragen, initiiert aber keine Aktionen selbstständig. Remote-Agenten können bei Bedarf auch mit anderen Remote-Agenten kommunizieren, um ihre zugewiesenen Aufgaben zu erfüllen, wodurch ein kollaboratives Netzwerk spezialisierter Kompetenzen entsteht.

In unserer Redaktion fungiert der Nachrichtenchef als Ansprechpartner für den Kunden, während Reporter, Rechercheur, Redakteur und Verleger als externe Mitarbeiter Anfragen bearbeiten und sich untereinander abstimmen.

Kernfunktionen für A2A

A2A-Protokolle definieren verschiedene Funktionen, die die Zusammenarbeit mehrerer Agenten ermöglichen:

1. Entdeckung

A2A-Server müssen ihre Fähigkeiten bekanntgeben, damit Clients wissen, wann und wie sie diese für bestimmte Aufgaben nutzen können. Dies geschieht mithilfe von Agentenkarten – JSON-Dokumenten, die die Fähigkeiten, Eingaben und Ausgaben eines Agenten beschreiben. Agentenkarten werden über einheitliche, bekannte Endpunkte (wie den empfohlenen /.well-known/agent-card.json -Endpunkt) bereitgestellt, sodass Clients die Fähigkeiten eines Agenten ermitteln und abfragen können, bevor sie die Zusammenarbeit initiieren.

Nachfolgend sehen Sie eine Beispiel-Agentenkarte für den benutzerdefinierten Archivagenten von Elastic, „Archie Archivist“. Beachten Sie, dass Softwareanbieter wie Elastic ihre A2A-Agenten hosten und eine URL für den Zugriff bereitstellen:

Diese Agentenkarte offenbart mehrere wichtige Aspekte des Archivagenten von Elastic. Der Agent stellt sich als „Archie Archivist“ vor und gibt seinen Zweck klar an: die Suche nach historischen Nachrichtendokumenten in einem Elasticsearch-Index. Die Karte gibt den Anbieter (Elastic) und die Protokollversion (0.3.0) an und gewährleistet so die Kompatibilität mit anderen A2A-kompatiblen Agenten. Am wichtigsten ist jedoch, dass das skills -Array die spezifischen Fähigkeiten auflistet, die dieser Agent bietet, darunter leistungsstarke Suchfunktionen und intelligente Indexerkundung. Jede Fähigkeit definiert, welche Eingabe- und Ausgabemodi sie unterstützt, sodass Clients genau verstehen, wie sie mit diesem Agenten kommunizieren können. Dieser Agent basiert auf dem Agent Builder-Service von Elastic, der eine Reihe nativer, LLM-gestützter Tools und API-Endpunkte bereitstellt, um mit Ihrem Datenspeicher zu kommunizieren und nicht nur Daten daraus abzurufen. Zugriff auf A2A-Agenten in Elasticsearch finden Sie hier.

2. Verhandlung

Kunden und Agenten müssen sich auf Kommunikationsmethoden einigen – egal ob die Interaktion per Text, Formular, iFrames oder sogar Audio/Video erfolgt –, um eine ordnungsgemäße Benutzerinteraktion und einen reibungslosen Datenaustausch zu gewährleisten. Diese Aushandlung findet zu Beginn der Zusammenarbeit der Agenten statt und legt die Protokolle fest, die ihre Interaktion während des gesamten Arbeitsablaufs regeln. Ein Mitarbeiter im telefonischen Kundenservice könnte beispielsweise die Kommunikation über Audiostreams aushandeln, während ein Mitarbeiter im Datenanalyse-Bereich strukturiertes JSON bevorzugen könnte. Der Verhandlungsprozess stellt sicher, dass beide Parteien Informationen effektiv in einem Format austauschen können, das ihren Fähigkeiten und den Anforderungen der jeweiligen Aufgabe entspricht.

Die im obigen JSON-Ausschnitt aufgeführten Funktionen verfügen alle über Eingabe- und Ausgabeschemata; diese legen fest, wie andere Agenten mit diesem Agenten interagieren sollen.

3. Aufgaben- und Zustandsmanagement

Kunden und Agenten benötigen Mechanismen, um während der gesamten Aufgabenausführung über Aufgabenstatus, Änderungen und Abhängigkeiten zu kommunizieren. Dies umfasst die Verwaltung des gesamten Lebenszyklus einer Aufgabe von der Erstellung und Zuweisung bis hin zu Fortschrittsaktualisierungen und Statusänderungen. Typische Status sind: ausstehend, in Bearbeitung, abgeschlossen oder fehlgeschlagen. Das System muss außerdem Abhängigkeiten zwischen Aufgaben verfolgen, um sicherzustellen, dass die erforderlichen Vorarbeiten abgeschlossen sind, bevor die abhängigen Aufgaben beginnen. Fehlerbehandlung und Wiederholungslogik sind ebenfalls wesentliche Bestandteile, die es dem System ermöglichen, sich nach Fehlern reibungslos zu erholen und weiterhin Fortschritte in Richtung des Hauptziels zu erzielen.

Beispiel einer Aufgabenmeldung:

Diese Beispiel-Aufgabennachricht veranschaulicht mehrere wichtige Aspekte der A2A-Kommunikation.

• Die Nachrichtenstruktur umfasst Metadaten wie eine eindeutige Nachrichtenkennung, die Art der gesendeten Nachricht, die Kennung von Absender und Empfänger sowie einen Zeitstempel zur Nachverfolgung und Fehlerbehebung.

• Die Nutzlast enthält die eigentlichen Aufgabeninformationen, in denen angegeben wird, welche Funktion auf dem Remote-Agenten aufgerufen wird, und die notwendigen Parameter zur Ausführung dieser Funktion bereitgestellt werden.

• Der Abschnitt „Kontext“ liefert zusätzliche Informationen, die dem empfangenden Agenten helfen, den übergeordneten Arbeitsablauf zu verstehen, einschließlich Fristen und Prioritätsstufen, die Aufschluss darüber geben, wie der Agent seine Ressourcen einsetzen und seine Arbeit planen sollte.

4. Zusammenarbeit

Kunden und Agenten müssen eine dynamische, aber dennoch strukturierte Interaktion unterstützen, die es den Agenten ermöglicht, Klärungen, Informationen oder Teilaktionen vom Kunden, anderen Agenten oder Benutzern anzufordern. Dadurch entsteht eine kollaborative Umgebung, in der Agenten bei unklaren Anfangsanweisungen Nachfragen stellen, zusätzlichen Kontext anfordern können, um bessere Entscheidungen zu treffen, Teilaufgaben an andere Agenten mit besser geeigneter Expertise delegieren und Zwischenergebnisse zur Rückmeldung liefern können, bevor sie mit der Gesamtaufgabe fortfahren. Diese multidirektionale Kommunikation stellt sicher, dass die Agenten nicht isoliert arbeiten, sondern in einen fortlaufenden Dialog eingebunden sind, der zu besseren Ergebnissen führt.

Verteilte Peer-to-Peer-Kommunikation

A2A ermöglicht verteilte Kommunikation, bei der Agenten von verschiedenen Organisationen gehostet werden können, wobei einige Agenten intern verwaltet werden, während andere von Drittanbietern bereitgestellt werden. Diese Agenten können auf verschiedenen Infrastrukturen ausgeführt werden – potenziell über mehrere Cloud-Anbieter oder lokale Rechenzentren hinweg. Sie verwenden möglicherweise unterschiedliche zugrunde liegende LLMs, wobei einige Agenten auf GPT-Modellen, andere auf Claude und wieder andere auf Open-Source-Alternativen basieren. Agenten könnten sogar über verschiedene geografische Regionen hinweg operieren, um den Anforderungen der Datensouveränität nachzukommen oder die Latenz zu reduzieren. Trotz dieser Vielfalt stimmen alle Agenten einem gemeinsamen Kommunikationsprotokoll für den Informationsaustausch zu, wodurch die Interoperabilität unabhängig von Implementierungsdetails gewährleistet wird. Diese verteilte Architektur bietet Flexibilität beim Aufbau und der Bereitstellung von Systemen und ermöglicht es Organisationen, die besten Agenten und Infrastrukturen für ihre spezifischen Bedürfnisse zu kombinieren.

Dies ist die endgültige Architektur der Newsroom-Anwendung:

Abschnitt 3: Modellkontextprotokoll (MCP)

Definition und Zweck

Das Model Context Protocol (MCP) ist ein von Anthropic entwickeltes standardisiertes Protokoll, das dazu dient, ein einzelnes LLM mit benutzerdefinierten Werkzeugen, Ressourcen und Eingabeaufforderungen sowie anderen ergänzenden Codebasiserweiterungen zu erweitern und zu stärken. MCP bietet eine universelle Schnittstelle zwischen Sprachmodellen und den externen Ressourcen, die sie benötigen, um Aufgaben effektiv zu erledigen. Dieser Artikel beschreibt den aktuellen Stand von MCP anhand von Anwendungsbeispielen, aufkommenden Trends und der Implementierung von Elastic.

Kernkonzepte des MCP

MCP arbeitet mit einer Client-Server-Architektur und besteht aus drei Hauptkomponenten:

• Clients: Anwendungen (wie Claude Desktop oder kundenspezifische KI-Anwendungen), die sich mit MCP-Servern verbinden, um auf deren Funktionen zuzugreifen.

• Server: Anwendungen, die Ressourcen, Werkzeuge und Eingabeaufforderungen für Sprachmodelle bereitstellen. Jeder Server ist darauf spezialisiert, Zugriff auf bestimmte Funktionen oder Datenquellen zu bieten.

  • Tools: Benutzerdefinierte Funktionen, die Modelle aufrufen können, um Aktionen auszuführen, wie z. B. Datenbanken zu durchsuchen, externe APIs aufzurufen oder Datentransformationen durchzuführen.

  • Ressourcen: Datenquellen, aus denen Modelle lesen können, die dynamische oder statische Daten liefern und über URI-Muster aufgerufen werden (ähnlich wie REST-Routen).

  • Eingabeaufforderungen: Wiederverwendbare Eingabeaufforderungsvorlagen mit Variablen, die das Modell bei der Erfüllung spezifischer Aufgaben unterstützen.

Anfrage-Antwort-Muster

MCP folgt einem bekannten Anfrage-Antwort-Interaktionsmuster, ähnlich wie REST-APIs. Der Client (LLM) fordert eine Ressource an oder ruft ein Tool auf. Anschließend verarbeitet der MCP-Server die Anfrage und gibt das Ergebnis zurück, das der LLM zur Fortsetzung seiner Aufgabe verwendet. Dieses zentralisierte Modell mit peripheren Servern bietet im Vergleich zur Peer-to-Peer-Agentenkommunikation ein einfacheres Integrationsmuster.

MCP im Newsroom

In unserem Beispiel aus der Nachrichtenredaktion nutzen einzelne Mitarbeiter MCP-Server, um auf die benötigten Tools und Daten zuzugreifen:

• Der Forscheragent verwendet:

  • News API MCP Server (Zugriff auf Nachrichtendatenbanken)

  • Faktencheck-Server von MCP (Überprüfung von Behauptungen anhand vertrauenswürdiger Quellen)

  • Akademische Datenbank MCP-Server (wissenschaftliche Artikel und Forschungsergebnisse)

• Reporteragent verwendet:

  • Styleguide MCP Server (Schreibstandards für Redaktionen)

  • Template MCP Server (Artikelvorlagen und -formate)

  • Bildbibliothek MCP-Server (Stockfotos und Grafiken)

• Redaktionsagenten verwenden:

  • Grammatikprüfung MCP-Server (Tools zur Sprachqualitätsprüfung)

  • Plagiatserkennungsserver MCP (Originalitätsprüfung)

  • SEO-Analyse MCP-Server (Überschriften- und Keyword-Optimierung)

• Verlagsagenten verwenden:

  • CMS MCP Server (API für Content-Management-Systeme)

  • CI/CD MCP-Server (Bereitstellungspipeline)

  • Analytics MCP Server (Tracking und Monitoring)

Abschnitt 4: Architekturvergleich

Wann sollte man A2A verwenden?

Die A2A-Architektur ist besonders geeignet für Szenarien, die eine echte Zusammenarbeit mehrerer Agenten erfordern. Mehrstufige Arbeitsabläufe, die eine Koordination erfordern, profitieren stark von A2A, insbesondere wenn Aufgaben mehrere sequentielle oder parallele Schritte umfassen, Arbeitsabläufe Iteration und Verfeinerung erfordern und Prozesse Kontrollpunkte und Validierungsanforderungen haben. In unserem Beispiel aus der Nachrichtenredaktion sieht der Arbeitsablauf vor, dass der Reporter den Artikel schreibt, ihn aber gegebenenfalls an den Rechercheur zurückgeben muss, wenn das Vertrauen in bestimmte Fakten gering ist, bevor er ihn an den Redakteur und schließlich an den Verleger weiterleitet.

Domänenspezifische Spezialisierung über mehrere Bereiche hinweg ist ein weiterer wichtiger Anwendungsfall für A2A. Wenn mehrere Experten aus verschiedenen Bereichen benötigt werden, um eine größere Aufgabe zu bewältigen, wobei jeder Experte über fundiertes Fachwissen und spezialisierte Denkfähigkeiten für unterschiedliche Aspekte verfügt, bietet A2A den Koordinierungsrahmen, der für die Herstellung dieser Verbindungen erforderlich ist. Die Redaktion ist dafür ein perfektes Beispiel: Der Rechercheur ist auf die Informationsbeschaffung spezialisiert, der Reporter auf das Schreiben und der Redakteur auf die Qualitätskontrolle – jeder mit einem besonderen Fachgebiet.

Die Notwendigkeit eines autonomen Agentenverhaltens macht A2A besonders wertvoll. Agenten, die selbstständig Entscheidungen treffen können, proaktives Verhalten auf der Grundlage sich ändernder Bedingungen zeigen und sich dynamisch an die Workflow-Anforderungen anpassen können, sind in einer A2A-Architektur besonders erfolgreich. Die horizontale Skalierung spezialisierter Funktionen ist ein weiterer entscheidender Vorteil – anstatt eines einzigen Alleskönners arbeiten mehrere spezialisierte Agenten koordiniert zusammen, und mehrere Instanzen desselben Agenten können Teilaufgaben asynchron bearbeiten. Bei Eilmeldungen in unserer Redaktion arbeiten beispielsweise mehrere Reporter gleichzeitig an verschiedenen Aspekten derselben Geschichte.

Schließlich eignen sich Aufgaben, die eine echte Zusammenarbeit mehrerer Agenten erfordern, ideal für A2A. Dies umfasst LLM-als-Jury-Bewertungsmechanismen , Konsensfindungs- und Abstimmungssysteme sowie kollaborative Problemlösungsansätze, bei denen mehrere Perspektiven erforderlich sind, um das beste Ergebnis zu erzielen.

Wann sollte MCP verwendet werden?

Das Model Context Protocol eignet sich ideal zur Erweiterung der Fähigkeiten eines einzelnen KI-Modells. Wenn ein einzelnes KI-Modell Zugriff auf mehrere Tools und Datenquellen benötigt, bietet MCP die perfekte Lösung mit zentralisierter Datenverarbeitung in Verbindung mit verteilten Tools und unkomplizierter Tool-Integration. In unserem Beispiel aus der Nachrichtenredaktion benötigt der Rechercheagent (ein Modell) Zugriff auf mehrere Datenquellen, darunter die News-API, Faktencheck-Dienste und akademische Datenbanken – der Zugriff erfolgt über standardisierte MCP-Server.

Die Integration standardisierter Werkzeuge gewinnt dann an Bedeutung, wenn die breite Weitergabe und Wiederverwendbarkeit von Werkzeugintegrationen wichtig ist. MCP glänzt hier mit seinem Ökosystem aus vorkonfigurierten MCP-Servern, die die Entwicklungszeit für gängige Integrationen erheblich reduzieren. Wenn Einfachheit und Wartbarkeit gefordert sind, sind die Anfrage-Antwort-Muster von MCP den Entwicklern vertraut, leichter zu verstehen und zu debuggen als verteilte Systeme und weisen eine geringere betriebliche Komplexität auf.

Schließlich wird MCP häufig von Softwareanbietern angeboten, um die Fernkommunikation mit ihren Systemen zu vereinfachen. Diese vom Anbieter bereitgestellten MCP-Server reduzieren die Einarbeitungs- und Entwicklungszeit erheblich und bieten gleichzeitig eine standardisierte Schnittstelle zu proprietären Systemen, wodurch die Integration wesentlich einfacher wird als die Entwicklung kundenspezifischer APIs.

Wann man beides verwendet (A2A ❤️'s MCP)

Viele hochentwickelte Systeme profitieren von der Kombination von A2A und MCP, wie in der A2A-Dokumentation zur MCP-Integration beschrieben. Systeme, die sowohl Koordination als auch Standardisierung erfordern, sind ideale Kandidaten für einen hybriden Ansatz. A2A übernimmt die Agentenkoordination und Workflow-Orchestrierung, während MCP den einzelnen Agenten Zugriff auf die Tools ermöglicht. In unserem Beispiel aus der Redaktion koordinieren sich die Mitarbeiter über A2A; der Arbeitsablauf verläuft dabei vom Reporter über den Rechercheur zum Redakteur und schließlich zum Verleger. Allerdings nutzt jeder Agent MCP-Server für seine spezialisierten Tools, wodurch eine klare architektonische Trennung entsteht.

Mehrere spezialisierte Agenten, die jeweils MCP für den Werkzeugzugriff nutzen, stellen ein gängiges Muster dar, bei dem es eine Agentenkoordinierungsschicht gibt, die von A2A verwaltet wird, und eine Werkzeugzugriffsschicht, die von MCP verwaltet wird. Durch diese klare Trennung der Zuständigkeiten werden die Systeme leichter verständlich und wartungsfreundlicher.

Die Vorteile der Kombination beider Ansätze sind beträchtlich. Sie profitieren von den organisatorischen Vorteilen von Multiagentensystemen, einschließlich Spezialisierung, Autonomie und Parallelverarbeitung, und genießen gleichzeitig die Vorteile von MCP in Bezug auf Standardisierung und Ökosystem, wie z. B. Werkzeugintegration und Ressourcenzugriff. Zwischen Agentenkoordination (A2A) und Ressourcenzugriff (MCP) besteht eine klare Trennung, und vor allem ist A2A für kleinere Aufgaben wie den API-Zugriff allein nicht erforderlich – MCP erledigt diese effizient ohne den Aufwand einer Multi-Agenten-Orchestrierung.

Häufig gestellte Fragen: A2A vs. MCP – Anwendungsfälle

Feature

Agent2Agent (A2A)

Model Context Protocol (MCP)

Hybrid (A2A + MCP)

Hauptziel

Multi-Agent-Koordination: Ermöglicht es einem Team spezialisierter Agenten, gemeinsam an komplexen, mehrstufigen Arbeitsabläufen zu arbeiten.

Erweiterung für einzelne Agenten: Erweitert die Funktionalität eines einzelnen LLM/Agenten um externe Tools, Ressourcen und Daten.

Gemeinsame Stärke: A2A kümmert sich um den Workflow des Teams, während MCP jedem Teammitglied die nötigen Werkzeuge zur Verfügung stellt.

Beispiel eines Redaktionsteams

Der Arbeitsablauf: Nachrichtenchef → Reporter → Rechercheur → Redakteur → Verleger. Dies ist die Koordinationsebene.

Tools für den einzelnen Agenten: Der Reporter-Agent greift über MCP auf den Styleguide-Server und den Vorlagenserver zu. Dies ist die Werkzeugzugriffsschicht.

Das vollständige System: Der Reporter stimmt sich mit dem Redakteur ab (A2A) und nutzt den Image Library MCP Server, um ein Bild für den Artikel zu finden.

Wann welches Werkzeug verwenden?

Wenn Sie echte Zusammenarbeit, Iteration und Verfeinerung benötigen oder spezialisiertes Fachwissen auf mehrere Mitarbeiter verteilt ist.

Wenn ein einzelner Agent Zugriff auf mehrere Tools und Datenquellen benötigt oder eine standardisierte Integration mit proprietären Systemen erfordert.

Wenn Sie die organisatorischen Vorteile von Multiagentensystemen und die Standardisierungs- und Ökosystemvorteile von MCP benötigen.

Kernnutzen

Autonomie und Skalierbarkeit: Agenten können unabhängige Entscheidungen treffen, und das System ermöglicht die horizontale Skalierung spezialisierter Funktionen.

Einfachheit und Standardisierung: Durch die zentrale Logik ist die Fehlersuche und Wartung einfacher, und es wird eine universelle Schnittstelle für Ressourcen bereitgestellt.

Klare Trennung der Zuständigkeiten: Macht das System verständlicher: A2A = Teamarbeit, MCP = Werkzeugzugriff.

Fazit

Dies ist der erste von zwei Teilen, die die Implementierung von A2A-basierten Agenten behandeln, die durch MCP-Server unterstützt werden, um Support und externen Zugriff auf Daten und Tools zu ermöglichen. Im nächsten Abschnitt wird der konkrete Code untersucht, um zu demonstrieren, wie die einzelnen Elemente zusammenarbeiten, um die Abläufe in einer Online-Nachrichtenredaktion nachzubilden. Obwohl beide Frameworks für sich genommen äußerst leistungsfähig und flexibel sind, werden Sie erst im Zusammenspiel sehen, wie sehr sie sich ergänzen.

Was ist rekursives Chunking?

Bei der rekursiven Segmentierung wird eine Liste von vorgegebenen Abschnittstrennungsmustern durchlaufen, um ein Dokument schrittweise in kleinere Segmente zu unterteilen, bis eine gewünschte maximale Segmentgröße erreicht ist.

Wie konfiguriere ich rekursives Chunking?

Folgende Werte können vom Benutzer für die rekursive Segmentierung konfiguriert werden:

• (erforderlich) max_chunk_size: Die maximale Anzahl von Wörtern in einem Chunk.

• Entweder eines von beiden:

  • separatorsEine Liste von regulären Ausdrücken, die verwendet werden, um das Dokument in Abschnitte zu unterteilen.

  • separator_groupEine Zeichenkette, die einer von Elastic definierten Standardliste von Trennzeichen zugeordnet wird, die für bestimmte Dokumenttypen verwendet werden. Aktuell sind markdown und plaintext verfügbar.

Wie funktioniert rekursives Chunking?

Der Prozess des rekursiven Chunkings bei gegebenem Eingabedokument, einem max_chunk_size (gemessen in Wörtern) und einer Liste von Trennzeichenketten verläuft wie folgt:

1. Wenn das Eingabedokument bereits innerhalb der maximalen Chunk-Größe liegt, wird ein einzelner Chunk zurückgegeben, der die gesamte Eingabe umfasst.

2. Teile den Text anhand des Vorkommens des Trennzeichens in mögliche Abschnitte auf. Für jeden potenziellen Teil:

   1. Wenn der potenzielle Datenblock innerhalb der maximalen Datenblockgröße liegt, fügen Sie ihn der Liste der an den Benutzer zurückzugebenden Datenblöcke hinzu.

   2. Andernfalls wiederholen Sie ab Schritt 2, wobei Sie nur den Text aus dem potenziellen Chunk verwenden und diesen anhand des nächsten Trennzeichens in der Liste aufteilen. Wenn keine weiteren Trennzeichen mehr übrig sind, sollte man auf satzbasierte Segmentierung zurückgreifen.

Beispiele für die Konfiguration von rekursivem Chunking

Abgesehen von der Chunk-Größe besteht die wichtigste Konfiguration für rekursives Chunking in der Auswahl der Trennzeichen, die zum Aufteilen der Dokumente verwendet werden sollen. Wenn Sie nicht sicher sind, wo Sie anfangen sollen, bietet Elasticsearch einige Standardtrennzeichengruppen an, die für gängige Anwendungsfälle verwendet werden können.

Verwendung von Trenngruppen

Um eine Trenngruppe zu verwenden, geben Sie einfach den Namen der Gruppe an, die Sie bei der Konfiguration der Chunking-Einstellungen verwenden möchten. Zum Beispiel:

Dies führt zu einer rekursiven Chunking-Strategie, die die Trennzeichenliste ["(?<!\\n)\\n\\n(?!\\n)", "(?<!\\n)\\n(?!\\n)")] verwendet. Dies funktioniert gut für allgemeine Klartextanwendungen, wobei der Text an zwei Zeilenumbruchzeichen, gefolgt von einem weiteren Zeilenumbruchzeichen, geteilt wird.

Wir bieten außerdem eine Trennzeichengruppe markdown an, die die Trennzeichenliste verwendet:

Diese Trennzeichenliste eignet sich gut für allgemeine Markdown-Anwendungsfälle, da sie an jeder der 6 Überschriftenebenen und den Abschnittsumbruchzeichen aufteilt.

Beim Erstellen einer Ressource (Inferenzendpunkt/semantisches Textfeld) wird die Liste der Trennzeichen, die der Trennzeichengruppe zu diesem Zeitpunkt entsprechen, in Ihren Konfigurationen gespeichert. Wenn die Trenngruppe zu einem späteren Zeitpunkt aktualisiert wird, ändert sich dadurch das Verhalten Ihrer bereits erstellten Ressourcen nicht.

Verwendung einer benutzerdefinierten Trennliste

Falls eine der vordefinierten Trennzeichengruppen für Ihren Anwendungsfall nicht geeignet ist, können Sie eine benutzerdefinierte Liste von Trennzeichen definieren, die Ihren Anforderungen entspricht. Beachten Sie, dass reguläre Ausdrücke innerhalb der Trennzeichenliste angegeben werden können. Nachfolgend ein Beispiel für Chunking-Einstellungen mit benutzerdefinierten Trennzeichen:

Die oben beschriebene Chunking-Strategie teilt an zwei Zeilenumbruchzeichen, gefolgt von einem Zeilenumbruchzeichen und schließlich an der Zeichenkette “<my-custom-separator>” auf.

Ein Beispiel für rekursives Chunking in der Praxis

Schauen wir uns ein Beispiel für rekursives Chunking in der Praxis an. In diesem Beispiel verwenden wir die folgenden Chunking-Einstellungen mit einer benutzerdefinierten Liste von Trennzeichen, die ein Markdown-Dokument anhand der beiden obersten Header-Ebenen aufteilen:

Werfen wir einen Blick auf ein einfaches, unstrukturiertes Markdown-Dokument:

Nun verwenden wir die oben definierten Chunking-Einstellungen, um das Dokument in Chunking-Elemente zu unterteilen:

Hinweis: Der Zeilenumbruch am Ende jedes Abschnitts (außer Abschnitt 3) ist nicht hervorgehoben, befindet sich aber innerhalb der eigentlichen Abschnittsgrenzen.

Legen Sie noch heute mit rekursivem Chunking los!

Weitere Informationen zur Nutzung dieser Funktion finden Sie in der Dokumentation zur Konfiguration der Chunking-Einstellungen.

Um dies zu erreichen, verwenden wir Googles SigLIP-2, um Vektoreinbettungen sowohl für Bilder als auch für Texte zu generieren und diese in der Elasticsearch-Vektordatenbank zu speichern. Zum Zeitpunkt der Abfrage wandeln wir die Sucheingabe, Text oder Bild, in Einbettungen um und führen schnelle kNN-Vektorsuchen durch, um Ergebnisse abzurufen. Diese Konfiguration ermöglicht eine effiziente Text-zu-Bild- und Bild-zu-Bild-Suche. Eine Streamlit-Benutzeroberfläche erweckt dieses Projekt zum Leben, indem sie uns ein Frontend zur Verfügung stellt, mit dem wir nicht nur textbasiert nach passenden Fotos aus dem Album suchen und diese anzeigen können, sondern auch den Berggipfel auf dem hochgeladenen Bild identifizieren und weitere Fotos dieses Berges im Fotoalbum anzeigen können. Wir beschreiben außerdem die Schritte, die wir zur Verbesserung der Suchgenauigkeit unternommen haben, und geben praktische Tipps und Tricks. Zur weiteren Erkundung stellen wir ein GitHub-Repository und ein Colab-Notebook zur Verfügung.

Wie alles begann

Dieser Blogbeitrag entstand auf Anregung eines 10-Jährigen, der mich bat, ihm alle Bilder des Mount Ama Dablam von meiner Everest-Basislager-Trekkingtour zu zeigen. Während wir das Fotoalbum durchsahen, wurde ich auch gebeten, mehrere andere Berggipfel zu identifizieren, von denen ich einige nicht benennen konnte.

Das brachte mich auf die Idee, dass dies ein unterhaltsames Computer-Vision-Projekt werden könnte. Was wir erreichen wollten:

• Finde Bilder eines Berggipfels anhand seines Namens

• Errate den Namen des Berggipfels anhand eines Bildes und finde ähnliche Gipfel im Fotoalbum.

• Konzeptabfragen zum Laufen bringen (Person, Fluss, Gebetsfahnen usw.)

Zusammenstellung des Dreamteams: SigLIP-2, Elasticsearch & Streamlit

Es wurde schnell klar, dass wir, um dies zu ermöglichen, sowohl den Text („Ama Dablam“) als auch die Bilder (Fotos aus meinem Album) in Vektoren umwandeln müssten, die sinnvoll verglichen werden können, d. h. im selben Vektorraum. Sobald wir das getan haben, besteht die Suche nur noch darin, „die nächstgelegenen Nachbarn zu finden“.

Um Bildeinbettungen zu generieren, verwenden wir einen mehrsprachigen Bild-Sprach-Encoder, sodass ein Foto eines Berges und ein Ausdruck wie „Ama Dablam“ im selben Vektorraum landen.

SigLIP-2, das kürzlich von Google veröffentlicht wurde, passt hier gut hinein. Es kann Einbettungen ohne aufgabenspezifisches Training generieren (eine Zero-Shot -Einstellung) und eignet sich hervorragend für unseren Anwendungsfall: unbeschriftete Fotos und Gipfel mit unterschiedlichen Namen und Sprachen. Da es für die Zuordnung von Text zu Bild trainiert wurde, werden ein Bergbild von der Wanderung und eine kurze Texteingabeaufforderung als Einbettungen sehr ähnlich dargestellt, selbst wenn die Abfragesprache oder die Rechtschreibung variiert.

SigLIP-2 bietet ein gutes Verhältnis von Qualität zu Geschwindigkeit, unterstützt mehrere Eingangsauflösungen und läuft sowohl auf der CPU als auch auf der GPU. Der SigLIP-2 ist im Vergleich zu Vorgängermodellen wie dem ursprünglichen CLIP robuster für Außenaufnahmen. Während unserer Tests lieferte SigLIP-2 durchweg zuverlässige Ergebnisse. Es wird zudem sehr gut unterstützt, was es zur naheliegenden Wahl für dieses Projekt macht.

Als nächstes benötigen wir eine Vektordatenbank zum Speichern der Einbettungen und zur Durchführung der Power-Suche. Es sollte nicht nur die Cosinus-kNN-Suche über Bildeinbettungen unterstützen, sondern auch Geofencing und Textfilter in einer einzigen Abfrage anwenden. Elasticsearch passt hier gut: Es verarbeitet Vektoren (HNSW kNN auf dense_vector-Feldern) sehr gut, unterstützt die hybride Suche, die Text-, Vektor- und Geo-Abfragen kombiniert, und bietet standardmäßig Filter- und Sortierfunktionen. Es ist außerdem horizontal skalierbar, sodass man problemlos von einer Handvoll Fotos auf Tausende wachsen kann. Der offizielle Elasticsearch Python-Client hält die Infrastruktur einfach und lässt sich nahtlos in das Projekt integrieren. Schließlich benötigen wir noch ein schlankes Frontend, in dem wir Suchanfragen eingeben und Ergebnisse anzeigen können. Für eine schnelle, Python-basierte Demo ist Streamlit hervorragend geeignet. Es bietet die grundlegenden Funktionen, die wir benötigen – Datei-Upload, ein responsives Bildraster und Dropdown-Menüs zum Sortieren und Geofencing. Es lässt sich leicht klonen und lokal ausführen und funktioniert auch in einem Colab-Notebook.

Implementierung

Elasticsearch-Indexierungsdesign und Indexierungsstrategie

Für dieses Projekt verwenden wir zwei Indizes: peaks_catalog und photos.

Peaks_Katalogindex

Dieser Index dient als kompakter Katalog markanter Berggipfel, die während der Everest-Basislager-Trekkingtour sichtbar sind. Jedes Dokument in diesem Index entspricht einem einzelnen Berggipfel, wie zum Beispiel dem Mount Everest. Für jedes Berggipfeldokument speichern wir Namen/Aliasse, optionale Breiten- und Längengradkoordinaten sowie einen einzelnen Prototypvektor, der durch die Kombination von SigLIP-2-Texteingabeaufforderungen (+ optionalen Referenzbildern) erstellt wird.

Indexzuordnung:

Feld

Typ

Beispiel

Zweck/Anmerkungen

Vektor-/Indexierung

Ausweis

Stichwort

ama-dablam

Stabiler Slug/ID

—

Namen

Text + Stichwort-Unterfeld

["Ama Dablam","Amadablam"]

Aliase / mehrsprachige Namen; names.raw für genaue Filter

—

Breitengrad

Geopunkt

{"lat":27.8617,"lon":86.8614}

GPS-Koordinaten des Gipfels als Kombination aus Breitengrad und Längengrad (optional)

—

elev_m

ganze Zahl

6812

Höhenangabe (optional)

—

text_embed

dense_vector

768

Kombinierter Prototyp (Aufforderungen und optional 1–3 Referenzbilder) für diesen Peak

index:true, similarity:"cosine", index_options:{type:"hnsw", m:16, ef_construction:128}

Dieser Index wird vor allem für Bild-zu-Bild-Suchen verwendet, beispielsweise zur Identifizierung von Berggipfeln anhand von Bildern. Wir verwenden diesen Index auch, um die Ergebnisse der Text-zu-Bild-Suche zu verbessern.

Zusammenfassend lässt sich sagen, dass die peaks_catalog die Frage „Welcher Berg ist das?“ in ein fokussiertes Nächste-Nachbar-Problem umwandelt und so das konzeptionelle Verständnis effektiv von der Komplexität der Bilddaten trennt.

Indexierungsstrategie für den peaks_catalog-Index: Wir beginnen mit der Erstellung einer Liste der markantesten Gipfel, die während der EBC-Trekkingtour sichtbar sind. Für jeden Gipfel speichern wir seine geografische Position, seinen Namen, Synonyme und seine Höhe in einer YAML-Datei. Im nächsten Schritt wird für jeden Peak die Einbettung generiert und im Feld text_embed gespeichert. Um robuste Einbettungen zu erzeugen, verwenden wir die folgende Technik:

• Erstellen Sie einen Textprototyp mit folgendem Werkzeug:

  • Namen der Gipfel

  • Prompt-Ensemble (Verwendung mehrerer unterschiedlicher Prompts, um dieselbe Frage zu beantworten), zum Beispiel:

    • „Ein Naturfoto des Berggipfels {name} im Himalaya, Nepal“

    • „ {name} markanter Gipfel in der Khumbu-Region, alpine Landschaft“

    • „ {name} Berggipfel, Schnee, felsiger Grat“

  • optionales Anti-Konzept (sagt SigLIP-2, wonach nicht gematcht werden soll): einen kleinen Vektor für „Gemälde, Illustration, Poster, Karte, Logo“ abziehen, um eine Bevorzugung von echten Fotos zu erreichen.

• Optional kann ein Bildprototyp erstellt werden, falls Referenzbilder des Gipfels vorhanden sind.

Anschließend verschmelzen wir den Text- und Bildprototyp , um die endgültige Einbettung zu erzeugen. Abschließend wird das Dokument mit allen erforderlichen Feldern indexiert :

Beispieldokument aus dem Index peaks_catalog :

Fotoindex

Dieser Hauptindex speichert detaillierte Informationen über alle Fotos im Album. Jedes Dokument stellt ein einzelnes Foto dar und enthält folgende Informationen:

• Relativer Pfad zum Foto im Fotoalbum. Dies kann verwendet werden, um das passende Bild anzuzeigen oder das Bild in die Suchoberfläche zu laden.

• GPS- und Zeitinformationen des Bildes.

• Dichter Vektor für die Bildkodierung, generiert durch SigLIP-2.

• predicted_peaks Das ermöglicht es uns, nach Gipfelnamen zu filtern. Indexzuordnung

Feld

Typ

Beispiel

Zweck/Anmerkungen

Vektor-/Indexierung

Weg

Stichwort

data/images/IMG_1234.HEIC

Wie die Benutzeroberfläche das Miniaturbild/Vollbild öffnet

—

Bildausschnitt

dense_vector

768

SigLIP-2 Bildeinbettung

index:true, similarity:"cosine", index_options:{type:"hnsw", m:16, ef_construction:128}

vorhergesagte_Spitzen

Stichwort

["ama-dablam","pumori"]

Top-K-Vorhersagen zur Indexierungszeit (kostengünstiger UX-Filter / Facette)

—

GPS

Geopunkt

{"lat":27.96,"lon":86.83}

Aktiviert Geofilter

—

Schusszeit

date

2023-10-18T09:41:00Z

Aufnahmezeit: Sortieren/Filtern

—

Indexierungsstrategie für den Fotoindex: Für jedes Foto im Album gehen wir wie folgt vor: Extrahieren Sie die Bildinformationen shot_time und gps aus den Bildmetadaten.

• SigLIP-2 Bildeinbettung: Das Bild wird durch das Modell geleitet und der Vektor anschließend L2-normalisiert. Speichere die Einbettung im Feld clip_image .

• Die Peaks werden vorhergesagt und im Feld predicted_peaks gespeichert. Dazu nehmen wir zunächst den im vorherigen Schritt erzeugten Bildvektor des Fotos und führen dann eine schnelle kNN-Suche im Feld text_embed im Index peaks_catalog durch. Wir behalten die obersten 3-4 Spitzen bei und ignorieren den Rest.

• Wir berechnen das Feld _id , indem wir einen Hashwert aus Bildname und Pfad erstellen. Dadurch wird sichergestellt, dass nach mehreren Durchläufen keine Duplikate entstehen.

Sobald alle Felder für das Foto ermittelt wurden, werden die Fotodokumente mithilfe der Massenindizierung stapelweise indexiert:

Beispieldokument aus dem Fotoindex:

Zusammenfassend lässt sich sagen, dass der Fotoindex ein schneller, filterbarer und kNN-fähiger Speicher aller Fotos im Album ist. Die Kartierung ist bewusst minimalistisch gehalten – gerade so strukturiert, dass die Ergebnisse schnell abgerufen, übersichtlich dargestellt und nach Raum und Zeit unterteilt werden können. Dieser Index dient beiden Suchanwendungsfällen. Das Python-Skript zur Erstellung beider Indizes finden Sie hier.

Die untenstehende Visualisierung der Kibana-Karten zeigt Dokumente aus dem Fotoalbum als grüne Punkte und Berggipfel ab dem Index peaks_catalog als rote Dreiecke an, wobei die grünen Punkte gut mit dem Wanderweg zum Everest-Basislager übereinstimmen.

Suchanwendungsfälle

Namenssuche (Text-zu-Bild): Mit dieser Funktion können Benutzer mithilfe von Textanfragen Fotos von Berggipfeln (und sogar abstrakten Konzepten wie „Gebetsfahnen“) finden. Um dies zu erreichen, wird die Texteingabe mithilfe von SigLIP-2 in einen Textvektor umgewandelt . Für eine robuste Textvektorgenerierung verwenden wir die gleiche Strategie wie für die Erstellung von Text-Embeddings im peaks_catalog -Index: Kombination der Texteingabe mit einem kleinen Prompt-Ensemble, Subtraktion eines minor Anti-Concept-Vektors und Anwendung der L2-Normalisierung zur Erzeugung des endgültigen Abfragevektors. Anschließend wird eine kNN- Abfrage auf dem Feld photos.clip_image ausgeführt, um die am besten übereinstimmenden Peaks auf Basis der Kosinusähnlichkeit zu ermitteln und so die ähnlichsten Bilder zu finden. Optional können die Suchergebnisse relevanter gestaltet werden, indem Geo- und Datumsfilter und/oder ein photos.predicted_peaks -Termfilter als Teil der Abfrage angewendet werden (siehe Abfragebeispiele unten). Dadurch werden ähnlich aussehende Gipfel ausgeschlossen, die auf der Wanderung gar nicht sichtbar sind.

Elasticsearch-Abfrage mit Geofilter:

Bildsuche (Bild-zu-Bild): Mit dieser Funktion können wir einen Berg auf einem Bild identifizieren und weitere Bilder desselben Berges innerhalb des Fotoalbums finden. Beim Hochladen eines Bildes wird dieses vom SigLIP-2-Bildcodierer verarbeitet, um einen Bildvektor zu erzeugen. Anschließend wird eine kNN-Suche im Feld peaks_catalog.text_embed durchgeführt, um die am besten passenden Peaknamen zu identifizieren. Anschließend wird aus diesen übereinstimmenden Peaknamen ein Textvektor generiert und eine weitere kNN-Suche im Fotoindex durchgeführt, um entsprechende Bilder zu finden.

Elasticsearch-Abfrage:

Schritt 1: Finde die passenden Peaknamen

Schritt 2: Führen Sie eine Suche im Index photos durch, um die passenden Bilder zu finden (dieselbe Abfrage wie im Anwendungsfall der Text-zu-Bild-Suche):

Streamlit-Benutzeroberfläche

Um alles zusammenzuführen, haben wir eine einfache Streamlit-Benutzeroberfläche entwickelt, die es uns ermöglicht, beide Suchanwendungsfälle durchzuführen. In der linken Spalte wird eine scrollbare Liste von Gipfeln (aggregiert aus photos.predicted_peaks) mit Kontrollkästchen und einem Mini-Karten-/Geofilter angezeigt. Ganz oben befinden sich ein Suchfeld für den Namen und eine Schaltfläche zum Hochladen eines Fotos zur Identifizierung . Im mittleren Bereich befindet sich ein responsives Miniaturraster mit kNN-Werten, vorhergesagten Spitzenwerten und Erfassungszeiten. Jedes Bild enthält eine Schaltfläche „Bild anzeigen“ für Vorschauen in voller Auflösung.

Suche durch Hochladen eines Bildes: Wir prognostizieren den Peak und finden übereinstimmende Peaks aus dem Fotoalbum.

Suche nach Text: Finde die passenden Höhepunkte im Album anhand des Textes

Fazit

Was mit der Frage begann: Können wir bitte die Bildervon Ama Dablamsehen? entwickelte sich zu einem kleinen, funktionierenden multimodalen Suchsystem . Wir haben Rohdaten von Trekkingfotos aufgenommen, diese in SigLIP-2-Einbettungen umgewandelt und Elasticsearch verwendet, um ein schnelles kNN über Vektoren durchzuführen, sowie einfache Geo-/Zeitfilter, um die richtigen Bilder anhand ihrer Bedeutung anzuzeigen. Dabei haben wir die Belange mithilfe zweier Indizes getrennt: einem winzigen peaks_catalog Index von kombinierten Prototypen (zur Identifizierung) und einem skalierbaren photos Index von Bildvektoren und EXIF-Daten (zum Abruf). Es ist praktisch, reproduzierbar und leicht erweiterbar.

Falls Sie es feinabstimmen möchten, gibt es einige Einstellungen, mit denen Sie experimentieren können:

• Einstellungen für die Abfragezeit: k (wie viele Nachbarn Sie zurückbekommen möchten) und num_candidates (wie breit die Suche vor der endgültigen Bewertung sein soll). Diese Einstellungen werden hier im Blog besprochen.

• Indexzeiteinstellungen: m (Graphkonnektivität) und ef_construction (Genauigkeit der Build-Zeit vs. Speicher). Experimentieren Sie bei Abfragen auch mit ef_search – ein höherer Wert bedeutet in der Regel eine bessere Trefferquote, allerdings mit einem gewissen Nachteil bei der Latenz. Weitere Einzelheiten zu diesen Einstellungen finden Sie in diesem Blog .

Zukünftig werden native Modelle/Reranker für multimodale und mehrsprachige Suche in Kürze im Elastic-Ökosystem verfügbar sein. Dies dürfte die Bild-/Textsuche und das hybride Ranking von Haus aus noch weiter verbessern. ir.elastic.co+1

Wenn Sie das selbst ausprobieren möchten:

• GitHub-Repository: https://github.com/navneet83/multimodal-mountain-peak-search

• Colab-Schnellstartanleitung: https://github.com/navneet83/multimodal-mountain-peak-search/blob/main/notebooks/multimodal_mountain_peak_search.ipynb

Damit ist unsere Reise zu Ende, und es ist Zeit, zurückzufliegen. Ich hoffe, das war hilfreich, und falls etwas kaputtgeht (oder verbessert wird), würde ich gerne erfahren, was Sie geändert haben.

Die wahre Magie entfaltet sich jedoch erst, wenn Sie diese maßgeschneiderten, datenorientierten Tools in die Umgebungen integrieren können, in denen Sie die meiste Zeit verbringen. Was wäre, wenn Ihr Code-Editor-Agent sicher auf die private Wissensdatenbank Ihres Unternehmens zugreifen könnte?

Hier kommt das Model Context Protocol (MCP) ins Spiel. Elastic Agent Builder wird mit einem integrierten MCP-Server ausgeliefert, der Zugriff auf die Tools der Plattform ermöglicht.

Warum sollte man den Elastic Agent Builder MCP-Server verwenden?

KI-Agenten sind unglaublich leistungsstark, aber ihr Wissen beschränkt sich typischerweise auf die Daten, mit denen sie trainiert wurden, und auf Informationen, die sie aktiv im öffentlichen Internet suchen können. Sie kennen weder die internen Designdokumente Ihres Unternehmens noch die spezifischen Bereitstellungs-Runbooks Ihres Teams oder die einzigartige Struktur Ihrer Anwendungsprotokolle.

Die Herausforderung besteht darin, Ihrem KI-Assistenten den benötigten spezialisierten Kontext zu liefern. Genau dieses Problem soll MCP lösen. MCP ist ein offener Standard, der es einem KI-Modell oder -Agenten ermöglicht, externe Tools zu erkennen und zu nutzen.

Um dies zu ermöglichen, stellt der Elastic Agent Builder Ihre benutzerdefinierten Tools nativ über einen integrierten MCP-Server zur Verfügung. Das bedeutet, dass Sie jeden MCP-kompatiblen Client, wie Cursor, VS Code oder Claude Desktop, problemlos mit den spezialisierten, datenorientierten Tools verbinden können, die Sie mit Elastic Agent Builder erstellt haben.

Wann sollte man MCP verwenden (und wann nicht)?

Elastic Agent Builder beinhaltet mehrere Protokolle zur Unterstützung verschiedener Integrationsmuster. Die Wahl der richtigen Lösung ist der Schlüssel zum Aufbau effektiver KI-Workflows.

• Verwenden Sie MCP , um Ihren KI-Agenten (wie in Cursor oder VS Code) mit spezialisierten Werkzeugen zu erweitern. Es ist der Ansatz „Bring your own tools“, der den bereits verwendeten Assistenten um einen sicheren Zugriff auf Ihre privaten Daten erweitert. Lediglich die Tools werden über den MCP-Server bereitgestellt – die Agenten von Elastic sind davon getrennt.

• Mit dem A2A-Protokoll können Sie Ihren vollständig benutzerdefinierten Elastic Agent mit anderen autonomen Agenten (wie in Googles Gemini Enterprise) zusammenarbeiten lassen. Dies dient der Agenten-zu-Agenten-Delegierung, bei der jeder Agent als gleichberechtigter Partner an der Lösung eines Problems arbeitet.

• Nutzen Sie die Agent Builder APIs für die vollständige programmatische Kontrolle beim Erstellen einer benutzerdefinierten Anwendung von Grund auf.

Für Entwickler, die Antworten aus ihrer internen Dokumentation erhalten möchten, ohne ihre IDE zu verlassen, ist MCP die perfekte Lösung.

Beispiel: Ihre benutzerdefinierten Tools in Cursor mit Agent Builder MCP-Server

Lassen Sie uns ein praktisches Beispiel durchgehen, das ich täglich verwende. Zuerst habe ich unsere interne technische Dokumentation gecrawlt und in einen Elasticsearch-Index namens elastic-dev-docs indexiert. Obwohl wir die im Agent Builder verfügbaren generischen, integrierten Tools verwenden könnten, werden wir unser eigenes, benutzerdefiniertes Tool erstellen, um diese spezielle Wissensdatenbank abzufragen.

Der Grund für die Entwicklung eines maßgeschneiderten Werkzeugs ist einfach: Kontrolle und Präzision. Dieser Ansatz gibt uns die Möglichkeit, eine schnelle semantische Abfrage direkt gegen unseren elastic-dev-docs -Index auszuführen. Wir haben die volle Kontrolle darüber, welcher Index genau anvisiert wird und wie die Daten abgerufen werden.

Und so können wir diese benutzerdefinierte Wissensdatenbank in einem KI-gestützten Code-Editor wie Cursor verwenden.

Schritt 1: Erstellen Sie ein benutzerdefiniertes Wissensdatenbank-Tool im Agent Builder.

Zuerst erstellen Sie ein neues Tool im Agent Builder. Eine klare und präzise Werkzeugbeschreibung ist wichtig, denn sie ist die Grundlage dafür, wie jeder KI-Agent, sei es der interne Elastic Agent oder ein externes Werkzeug wie Cursor, das über MCP verbunden ist, Ihr Werkzeug für die richtige Aufgabe erkennt und auswählt.

Eine aussagekräftige Beschreibung sollte explizit sein. Zum Beispiel: „Führt eine semantische Suche im elastic-dev-docs-Index durch, um interne Entwicklungsdokumentationen, Runbooks und Release-Prozeduren zu finden.“

Damit ist das Tool so konfiguriert, dass es eine semantische Suche in unserem spezifischen Index durchführt. Nach dem Speichern steht es sofort zum Servieren bereit.

Bevor Sie es mit der Außenwelt verbinden, können Sie es direkt in der Benutzeroberfläche testen. Klicken Sie einfach auf die Schaltfläche „Testen“ , um die Parameter manuell einzugeben und so das Verhalten des LLM zu simulieren. Überprüfen Sie anschließend die Ergebnisse, um sicherzustellen, dass alles ordnungsgemäß funktioniert.

Schritt 2: Cursor mit dem Elastic MCP-Server verbinden

Elastic Agent Builder stellt automatisch alle verfügbaren Tools über einen sicheren MCP-Endpunkt bereit. Ihre individuelle Server-URL finden Sie in der Tools-Benutzeroberfläche von Kibana.

Um eine Verbindung zu Cursor herzustellen, fügen wir einfach diese URL zusammen mit einem Elastic API Key zur Authentifizierung in die Konfigurationsdatei ein (hier erfahren Sie, wie Sie einen ES API Key erstellen). Wir verwenden einen API-Schlüssel zur Autorisierung, da dieser sicherstellt, dass die Tools nur mit den von Ihnen erteilten Berechtigungen ausgeführt werden und alle Ihre Zugriffskontrollregeln eingehalten werden.

Die MCP-Konfiguration in Cursors ~/.cursor/mcp.json sieht folgendermaßen aus:

Sobald die Konfiguration gespeichert ist, sollte das Elastic Agent Builder MCP-Servertool in Cursor verfügbar sein.

Schritt 3: Fragen Sie einfach drauflos!

Nachdem die Verbindung hergestellt wurde, können Cursor-Agenten nun Ihre benutzerdefinierten Tools aufrufen, um Ihre Fragen zu beantworten oder den Codegenerierungsprozess zu steuern.

Stellen wir eine konkrete Frage:

„Schritte zur Freigabe des Crawler-Dienstes in der internen Entwicklungsdokumentation der Elasticsearch-Organisation nachschlagen“

Hinter den Kulissen geschieht die Magie:

1. Der Cursor-Agent entscheidet, wie Ihre Frage am besten beantwortet werden kann, und beschließt, den/die/das … anzurufen. engineering_documentation_internal_search

2. Es ruft das Tool mit einer natürlichsprachlichen Anfrage auf.

3. Das Tool führt eine semantische Suche im Index elastic-dev-docs durch und gibt die relevantesten und aktuellsten Prozeduren zurück.

Wir erhalten eine präzise und verlässliche Antwort auf Basis unserer internen Dokumentation, ohne jemals den Code-Editor verlassen zu müssen. Das Erlebnis ist nahtlos und beeindruckend.

Jetzt bist du an der Reihe zu bauen

Sie haben nun gesehen, wie Sie den integrierten MCP-Server im Elastic Agent Builder verwenden können, um Ihre KI-Assistenten um einen sicheren Zugriff auf Ihre privaten Daten zu erweitern. Die Modelle auf eigenen Informationen zu basieren, ist der Schlüssel zu ihrer tatsächlichen Nützlichkeit.

Zusammenfassend haben wir die wichtigsten Schritte behandelt:

• Die Wahl des richtigen Protokolls für Ihre Bedürfnisse (MCP).

• Entwicklung eines maßgeschneiderten Wissensdatenbank-Tools.

• Verbindung dieses Tools mit einem IDE-Assistenten wie Cursor.

Ihre Agenten und Tools müssen nicht länger von ihrem wichtigsten Kontext getrennt werden. Wir hoffen, dass Ihnen dieser Leitfaden dabei hilft, effektivere, datenbasierte Arbeitsabläufe zu erstellen. Viel Spaß beim Bauen!

Im Elastic Stack gibt es viele LLM-gestützte agentenbasierte Anwendungen, wie zum Beispiel den kommenden Elastic AI Agent im Agent Builder (derzeit in der technischen Vorschau) und Attack Discovery (GA in 8.18 und 9.0+), und weitere sind in Arbeit. Während der Entwicklung und auch nach der Bereitstellung ist es wichtig, diese Fragen zu beantworten:

• Wie schätzen wir die Qualität der Antworten dieser KI-Anwendungen ein?

• Wenn wir eine Änderung vornehmen, wie können wir garantieren, dass diese Änderung tatsächlich eine Verbesserung darstellt und keine Verschlechterung der Benutzererfahrung zur Folge hat?

• Wie können wir diese Ergebnisse auf einfache und reproduzierbare Weise testen?

Im Gegensatz zu herkömmlichen Softwaretests erfordert die Evaluierung von generativen KI-Anwendungen statistische Methoden, eine differenzierte qualitative Überprüfung und ein tiefes Verständnis der Ziele der Nutzer.

Dieser Artikel beschreibt detailliert den Prozess, den das Elastic-Entwicklerteam anwendet, um Evaluierungen durchzuführen, die Qualität der Änderungen vor der Bereitstellung sicherzustellen und die Systemleistung zu überwachen. Unser Ziel ist es, sicherzustellen, dass jede Änderung durch Beweise untermauert wird, was zu verlässlichen und nachvollziehbaren Ergebnissen führt. Ein Teil dieses Prozesses ist direkt in Kibana integriert und spiegelt damit unser Bekenntnis zu Transparenz als Teil unseres Open-Source-Ethos wider. Durch die offene Weitergabe von Teilen unserer Evaluierungsdaten und Kennzahlen wollen wir das Vertrauen der Community stärken und einen klaren Rahmen für alle bieten, die KI-Agenten entwickeln oder unsere Produkte nutzen.

Produktbeispiele

Die in diesem Dokument verwendeten Methoden bildeten die Grundlage für unsere iterative Weiterentwicklung und Verbesserung von Lösungen wie Attack Discovery und Elastic AI Agent. Eine kurze Vorstellung der beiden:

Angriffserkennung von Elastic Security

Attack Discovery verwendet LLMs, um Angriffssequenzen in Elastic zu identifizieren und zusammenzufassen. Anhand der Elastic Security-Warnmeldungen in einem bestimmten Zeitraum (standardmäßig 24 Stunden) ermittelt der agentenbasierte Workflow von Attack Discovery automatisch, ob ein oder mehrere Angriffe stattgefunden haben, sowie wichtige Informationen darüber, welcher Host oder welche Benutzer kompromittiert wurden und welche Warnmeldungen zu dieser Schlussfolgerung beigetragen haben.

Ziel ist es, dass die LLM-basierte Lösung ein Ergebnis liefert, das mindestens so gut ist wie das eines Menschen.

Elastischer KI-Agent

Der Elastic Agent Builder ist unsere neue Plattform zum Erstellen kontextsensitiver KI-Agenten, die alle unsere Suchfunktionen nutzen. Es beinhaltet den Elastic AI Agent, einen vorkonfigurierten, universell einsetzbaren Agenten, der Benutzern dabei hilft, ihre Daten durch dialogbasierte Interaktion zu verstehen und Antworten darauf zu erhalten.

Der Agent erreicht dies, indem er automatisch relevante Informationen innerhalb von Elasticsearch oder verbundenen Wissensdatenbanken identifiziert und eine Reihe vorgefertigter Tools nutzt, um mit diesen zu interagieren. Dies versetzt den Elastic AI Agent in die Lage, auf ein breites Spektrum von Benutzeranfragen zu reagieren, von einfachen Fragen und Antworten zu einem einzelnen Dokument bis hin zu komplexen Anfragen, die eine Aggregation und ein- oder mehrstufige Suchvorgänge über mehrere Indizes hinweg erfordern.

Verbesserungen durch Experimente messen

Im Kontext von KI-Agenten ist ein Experiment eine strukturierte, testbare Änderung des Systems, die darauf abzielt, die Leistung in genau definierten Dimensionen (z. B. Hilfreichkeit, Korrektheit, Latenz) zu verbessern. Ziel ist es, die folgende Frage endgültig zu beantworten: „Wenn wir diese Änderung umsetzen, können wir dann garantieren, dass es sich um eine echte Verbesserung handelt und die Benutzererfahrung nicht verschlechtert wird?“

Die meisten unserer Experimente umfassen im Allgemeinen Folgendes:

• Eine Hypothese: Eine spezifische und widerlegbare Behauptung. Beispiel: „Das Hinzufügen des Zugriffs auf ein Tool zur Angriffserkennung verbessert die Korrektheit sicherheitsrelevanter Abfragen.“

• Erfolgskriterien: Klare Schwellenwerte, die definieren, was „Erfolg“ bedeutet. Beispiel: „+5 % Verbesserung der Korrektheitsbewertung im Sicherheitsdatensatz, keine Verschlechterung in anderen Bereichen.“

• Evaluierungsplan: Wie wir den Erfolg messen (Kennzahlen, Datensätze, Vergleichsmethode)

Ein erfolgreiches Experiment ist ein systematischer Forschungsprozess. Jede Änderung, von einer kleinen, spontanen Anpassung bis hin zu einer grundlegenden architektonischen Umgestaltung, durchläuft diese sieben Schritte, um sicherzustellen, dass die Ergebnisse aussagekräftig und umsetzbar sind:

• Schritt 1: Identifizieren Sie das Problem

• Schritt 2: Kennzahlen definieren

• Schritt 3: Formulieren Sie eine klare Hypothese

• Schritt 4: Vorbereitung des Auswertungsdatensatzes

• Schritt 5: Führen Sie das Experiment durch.

• Schritt 6: Ergebnisse analysieren + wiederholen

• Schritt 7: Treffen Sie eine Entscheidung und dokumentieren Sie diese.

Ein Beispiel für diese Schritte ist in Abbildung 1 dargestellt. In den folgenden Unterabschnitten werden die einzelnen Schritte erläutert, und die technischen Details der einzelnen Schritte werden wir in den folgenden Dokumenten genauer ausführen.

Schrittweise Anleitung mit echten Elastic-Beispielen

Schritt 1: Identifizieren Sie das Problem

Welches Problem soll durch diese Änderung genau gelöst werden?

Beispiel für die Angriffserkennung: Die Zusammenfassungen sind gelegentlich unvollständig, oder harmlose Aktivitäten werden fälschlicherweise als Angriff eingestuft (falsch positive Ergebnisse).

Beispiel für einen Elastic AI Agent: Die Werkzeugauswahl des Agenten, insbesondere bei analytischen Abfragen, ist suboptimal und inkonsistent, was häufig dazu führt, dass das falsche Werkzeug ausgewählt wird. Dies wiederum erhöht die Tokenkosten und die Latenz.

Schritt 2: Kennzahlen definieren

Das Problem muss messbar gemacht werden, damit wir eine Veränderung mit dem aktuellen Zustand vergleichen können.

Gängige Metriken sind Präzision und Trefferquote, semantische Ähnlichkeit, Faktentreue usw. Je nach Anwendungsfall verwenden wir Code-Checks, um die Metriken zu berechnen, wie z. B. übereinstimmende Alarm-IDs oder korrekt abgerufene URLs, oder wir verwenden Techniken wie LLM-as-judge für freiere Antworten.

Nachfolgend sind einige (nicht vollständige) Beispielmetriken aufgeführt, die in den Experimenten verwendet wurden:

Angriffserkennung

Metrisch

Beschreibung

Präzision und Rückruf

Vergleichen Sie die Alarm-IDs zwischen tatsächlichen und erwarteten Ausgaben, um die Erkennungsgenauigkeit zu messen.

Ähnlichkeit

Verwenden Sie BERTScore, um die semantische Ähnlichkeit des Antworttextes zu vergleichen.

Faktentreue

Sind wichtige IOCs (Indikatoren für eine Kompromittierung) vorhanden? Werden die MITRE-Taktiken (Branchenklassifizierung von Angriffen) korrekt abgebildet?

Konsistenz der Angriffskette

Vergleichen Sie die Anzahl der Entdeckungen, um festzustellen, ob der Angriff über- oder untererfasst gemeldet wurde.

Elastischer KI-Agent

Metrisch

Beschreibung

Präzision und Rückruf

Um die Genauigkeit des Informationsabrufs zu messen, werden die vom Agenten abgerufenen Dokumente/Informationen mit den tatsächlich benötigten Informationen oder Dokumenten abgeglichen, die zur Beantwortung der Anfrage erforderlich sind.

Faktentreue

Sind die zur Beantwortung der Benutzeranfrage erforderlichen Schlüsselinformationen vorhanden? Sind die Fakten in der richtigen Reihenfolge für verfahrenstechnische Anfragen?

Relevanz der Antwort

Enthält die Antwort Informationen, die für die Benutzeranfrage nebensächlich oder nicht relevant sind?

Vollständigkeit der Antwort

Beantwortet die Antwort alle Teile der Benutzeranfrage? Enthält die Antwort alle Informationen, die auch in den Referenzdaten vorhanden sind?

ES|QL-Validierung

Ist der generierte ES|QL-Code syntaktisch korrekt? Ist es funktional identisch mit dem tatsächlichen ES|QL-Standard?

Schritt 3: Formulieren Sie eine klare Hypothese

Legen Sie anhand des Problems und der oben definierten Kennzahlen klare Erfolgskriterien fest.

Beispiel für einen elastischen KI-Agenten:

1. Nehmen Sie Änderungen an den Beschreibungen der Tools relevance_search und nl_search vor, um deren spezifische Funktionen und Anwendungsfälle klar zu definieren.

2. Wir gehen davon aus, dass wir die Genauigkeit unserer Tool-Aufrufe um 25 % verbessern werden.

3. Wir werden überprüfen, ob dies insgesamt positiv ist, indem wir sicherstellen, dass es keine negativen Auswirkungen auf andere Kennzahlen gibt, z. B. Faktentreue und Vollständigkeit.

4. Wir glauben, dass dies funktionieren wird, da präzise Werkzeugbeschreibungen dem Agenten helfen, das am besten geeignete Suchwerkzeug für verschiedene Anfragetypen genauer auszuwählen und anzuwenden, wodurch Fehlanwendungen reduziert und die Gesamteffektivität der Suche verbessert wird.

Schritt 4: Vorbereitung des Auswertungsdatensatzes

Um die Leistungsfähigkeit des Systems zu messen, verwenden wir Datensätze, die realweltliche Szenarien abbilden.

Je nach Art der durchgeführten Evaluierung benötigen wir möglicherweise unterschiedliche Datenformate, wie z. B. Rohdaten, die einem LLM zugeführt werden (z. B. Angriffsszenarien für die Angriffserkennung) und erwartete Ergebnisse. Wenn es sich bei der Anwendung um einen Chatbot handelt, dann können die Eingaben Benutzeranfragen sein und die Ausgaben korrekte Chatbot-Antworten, korrekte Links, die er hätte abrufen sollen, und so weiter.

Beispiel für Angriffserkennung:

10 neuartige Angriffsszenarien

8 Folgen von Oh My Malware (ohmymalware.com)

4 Szenarien mit mehreren Angriffen (entstanden durch die Kombination von Angriffen aus den ersten beiden Kategorien)

3 harmlose Szenarien

Beispiel eines Evaluierungsdatensatzes für Elastic AI-Agenten (Kibana-Datensatzlink):

14 Indizes, die Open-Source-Datensätze verwenden, um mehrere Quellen in KB zu simulieren.

5 Abfragetypen (analytisch, Textabfrage, hybrid…)

7 Arten von Abfrageabsichten (prozedural, faktisch - Klassifizierung, investigativ; …)

Schritt 5: Führen Sie das Experiment durch.

Führen Sie das Experiment durch, indem Sie Antworten sowohl vom bestehenden Agenten als auch von der modifizierten Version gegen den Evaluierungsdatensatz generieren. Berechnen Sie Kennzahlen wie Faktentreue (siehe Schritt 2).

Wir kombinieren verschiedene Auswertungen auf Basis der in Schritt 2 geforderten Kennzahlen:

• Regelbasierte Auswertung (z. B. (mit Python/TypeScript prüfen, ob die .json-Datei gültig ist)

• LLM als Richter (Befragung eines anderen LLM, ob eine Antwort sachlich mit einem Quelldokument übereinstimmt)

• Menschliche Beteiligung an der Qualitätsprüfung zur Feinabstimmung

Schritt 6: Ergebnisse analysieren + wiederholen

Nachdem wir nun die Kennzahlen haben, analysieren wir die Ergebnisse. Auch wenn die Ergebnisse die in Schritt 3 definierten Erfolgskriterien erfüllen, werden wir vor der Übernahme der Änderung in die Produktionsumgebung noch eine manuelle Überprüfung durchführen; wenn die Ergebnisse die Kriterien nicht erfüllen, werden die Probleme behoben und anschließend die Auswertungen der neuen Änderung durchgeführt.

Wir gehen davon aus, dass einige Iterationen nötig sein werden, um die beste Änderung vor dem Zusammenführen zu finden. Ähnlich wie bei der Durchführung lokaler Softwaretests vor dem Pushen eines Commits können Offline-Evaluierungen mit lokalen Änderungen oder mehreren vorgeschlagenen Änderungen durchgeführt werden. Es ist hilfreich, das Speichern von Experimentergebnissen, Gesamtergebnissen und Visualisierungen zu automatisieren, um die Analyse zu optimieren.

Schritt 7: Treffen Sie eine Entscheidung und dokumentieren Sie diese.

Auf Basis eines Entscheidungsrahmens und Akzeptanzkriterien wird über die Übernahme der Änderung entschieden und das Experiment dokumentiert. Die Entscheidungsfindung ist vielschichtig und kann Faktoren berücksichtigen, die über den Auswertungsdatensatz hinausgehen, wie z. B. die Prüfung auf Regressionsszenarien in anderen Datensätzen oder die Abwägung des Kosten-Nutzen-Verhältnisses einer vorgeschlagenen Änderung.

Beispiel: Nach dem Testen und Vergleichen einiger Iterationen wählen Sie die Änderung mit der höchsten Punktzahl aus und senden sie zur Genehmigung an Produktmanager und andere relevante Stakeholder. Fügen Sie die Ergebnisse der vorherigen Schritte bei, um die Entscheidungsfindung zu erleichtern. Weitere Beispiele zum Thema Angriffserkennung finden Sie unter Hinter den Kulissen der generativen KI-Funktionen von Elastic Security.

Fazit

In diesem Blog haben wir den gesamten Ablauf eines Experiment-Workflows durchlaufen und veranschaulicht, wie wir Änderungen an einem agentenbasierten System bewerten und testen, bevor wir sie für Elastic-Benutzer freigeben. Wir haben auch einige Beispiele für die Verbesserung agentenbasierter Arbeitsabläufe in Elastic vorgestellt. In nachfolgenden Blogbeiträgen werden wir die Details verschiedener Schritte genauer erläutern, beispielsweise wie man einen guten Datensatz erstellt, wie man zuverlässige Metriken entwirft und wie man Entscheidungen trifft, wenn mehrere Metriken involviert sind.

Was aber, wenn Sie Ihre benutzerdefinierten Agenten mit den Anwendungen und Produktivitätstools verwenden möchten, auf die Sie bereits angewiesen sind?

Hier kommt das Agent-to-Agent (A2A)-Protokoll ins Spiel. A2A ist ein offener Standard für Interoperabilität, der es Agenten verschiedener Plattformen ermöglicht, miteinander zu kommunizieren und zusammenzuarbeiten. Und wir haben es direkt in den Elastic Agent Builder integriert.

Heute zeigen wir Ihnen, wie Sie einen von Ihnen erstellten benutzerdefinierten Agenten anderen Diensten, insbesondere Gemini Enterprise (ehemals Agentspace), zugänglich machen können.

Die Macht offener Standards: Warum A2A wichtig ist

Im Blogbeitrag „Ihr erster Elastic Agent“ haben wir gezeigt, wie man benutzerdefinierte Agenten erstellt, zum Beispiel einen Finanzassistenten -Agenten mit sicherem Zugriff auf Ihre Marktdaten. Sein Nutzen ist jedoch begrenzt, wenn Sie die gewonnenen Erkenntnisse nicht auch in anderen Umgebungen wie Gemini Enterprise nutzen können, ohne Ihre Arbeit neu aufbauen zu müssen.

Diese Herausforderung der Interoperabilität ist es, die agentenbasierte KI zurückhält. Agenten benötigen eine gemeinsame Sprache, um plattformübergreifend zu kommunizieren. Genau diese Rolle übernimmt das A2A-Protokoll. Es bietet eine standardisierte Kommunikationsschicht, die es Ihnen nicht nur ermöglicht, direkt mit Ihrem Agenten zu interagieren, sondern auch eine Zukunft eröffnet, in der spezialisierte Agenten in Ihrem gesamten Unternehmen zusammenarbeiten und Erkenntnisse austauschen können.

Um dies zu ermöglichen, unterstützt der Elastic Agent Builder das A2A-Protokoll nativ über zwei Standardendpunkte für alle Ihre Agenten:

1. Der Agent Card-Endpunkt (GET {your-kibana-url}/api/agent_builder/a2a/{agentId}.json) - Dieser dient als Visitenkarte Ihres individuellen Agenten. Es stellt Metadaten über Ihren Agenten (Name, Beschreibung, Fähigkeiten usw.) für jeden A2A-kompatiblen Dienst bereit.

2. Der A2A-Protokollendpunkt (POST {your-kibana-url}/api/agent_builder/a2a/{agentId}) - Dies ist der Kommunikationskanal. Andere Agenten senden ihre Anfragen hierher, Ihr Agent verarbeitet sie und sendet eine Antwort zurück, alles gemäß der A2A-Protokollspezifikation.

Testen Sie Ihren Makler mit dem A2A-Inspektor.

Bevor wir unseren Agenten mit einem Produktionssystem verbinden, sollten wir überprüfen, ob die Kommunikation korrekt funktioniert. Am einfachsten geht das mit dem A2A Inspector, einem Tool, das speziell für das Testen und Debuggen von A2A-Integrationen entwickelt wurde.

Die Inbetriebnahme des Inspektors ist unkompliziert. Sie können das a2a-inspector- Repository klonen und den Anweisungen in der README-Datei folgen, um die Anwendung auszuführen. Nach dem Start ist die Benutzeroberfläche standardmäßig unter http://localhost:5001/ verfügbar.

Um den A2A-Inspektor mit Ihrem Makler zu verbinden, müssen Sie zwei wichtige Informationen angeben:

• Agentenkarten-URL: Dies ist der Endpunkt, der Ihren Agenten beschreibt. Für den Finanzassistenten-Agenten aus unserem vorherigen Beitrag lautet diese URL {your-kibana-url}/api/agent_builder/a2a/financial_assistant.json.

• Authentifizierungsheader: Wir verwenden einen Standard-API-Schlüssel zur Authentifizierung.

Sobald Sie diese Angaben in der Benutzeroberfläche des Inspektors eingegeben haben, können Sie sich mit Ihrem Agenten verbinden und sofort mit ihm chatten.

Diese einfache Validierung gibt uns die Gewissheit, dass unser Agent korrekt konfiguriert ist und für den nächsten Schritt bereit ist.

Geh live! Ihr persönlicher Kundenbetreuer in Gemini Enterprise

Und nun zum spannenden Teil: die Umsetzung unseres maßgeschneiderten Finanzberateragenten in Gemini Enterprise (ehemals Agentspace). Diese Integration wird durch den Elastic AI Agent ermöglicht, der auf dem Google Cloud Marketplace verfügbar ist.

Nach der Verbindungsherstellung nutzt Gemini Enterprise das A2A-Protokoll, um direkt mit Ihrem Agenten zu kommunizieren. Hier zeigt sich die wahre Stärke der Interoperabilität: Benutzer können nun auf die tiefgreifenden, datengestützten Erkenntnisse Ihres benutzerdefinierten Elasticsearch-Agenten zugreifen, ohne jemals ihre gewohnte Umgebung verlassen zu müssen. Sie können Ihren benutzerdefinierten Elastic Agent in der Agentenliste sehen:

Stellen Sie sich einen Benutzer in Gemini Enterprise vor, der Folgendes fragt:

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

Im Hintergrund leitet Gemini Enterprise diese Anfrage über das A2A-Protokoll an Ihren benutzerdefinierten Elastic Agent weiter. Ihr Agent verwendet dann seine spezialisierten Tools, um Ihre Daten abzufragen, eine Antwort zu formulieren und diese zurückzusenden. Für den Endnutzer ist das Erlebnis nahtlos.

Und das ist noch nicht alles! Die mit dem Elastic-Agenten erhaltene Antwort kann nun als Kontext für Ihre nächsten Fragen verwendet werden, die möglicherweise einen anderen spezialisierten Agenten auslösen (z. B. (Ihr Investmentplattform-Agent passt das Engagement in börsennotierten Unternehmen an.) Alles, ohne die Suchleiste zu verlassen.

Mit Ihren Elastic-Agenten, die auf Gemini Enterprise mit A2A bereitgestellt werden, können Sie Zugriff, Orchestrierung und Workflows vereinheitlichen und Reibungsverluste zwischen KI-, Such- und Unternehmenssystemen beseitigen, indem Sie eine einzige Benutzeroberfläche anbieten, über die Benutzer mit ihren Daten und Tools interagieren können – alles im Kontext. Für die Anwender bedeutet das weniger Werkzeugwechsel und intuitivere, leistungsfähigere KI-Assistenten. Für Organisationen bedeutet dies eine integrierte, kohärente Governance, Skalierbarkeit und Interoperabilität.

Jetzt sind Sie am Zug.

Sie verfügen nun über die Werkzeuge, um Ihre Elastic Agents überall verfügbar zu machen. Durch die Nutzung des offenen A2A-Protokolls können Sie die Reichweite Ihrer benutzerdefinierten, datenorientierten Agenten erweitern.

In diesem Beitrag haben wir Ihnen die wichtigsten Schritte erläutert:

• Bereitstellung Ihres Agenten über die A2A Agent Card und Protocol Endpunkte.

• Testen der Verbindung mit dem A2A Inspector.

• Integration Ihres Agenten live in einen externen Dienst wie Googles Gemini Enterprise.

Ihre Agenten müssen nicht länger isoliert werden. Wir freuen uns schon sehr auf die leistungsstarken, vernetzten Systeme, die Sie entwickeln werden. Viel Spaß beim Bauen!

Am einfachsten gelingt der Einstieg mit Ihrer kostenlosen Elastic Cloud-Testversion auf dem Google Cloud Marketplace.

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!

Agent Builder: Eine Grundlage für die Entwicklung datengesteuerter KI-Agenten

Das Versprechen eines KI-Agenten ist einfach: Man gibt ihm ein Ziel, und er erledigt die Aufgabe. Für Entwickler sieht die Realität jedoch anders aus: Sie steht vor einer Reihe komplexer Herausforderungen. Erstens ist ein Agent nur so gut wie seine Wahrnehmung seiner Umgebung und der ihm zur Verfügung stehenden Werkzeuge, um die Ziele des Benutzers zu erreichen. Dann stellt es eine enorme Herausforderung dar, aus einer Flut von unterschiedlichen Unternehmensdaten den richtigen Kontext herauszufiltern. Schließlich muss all dies von einer zuverlässigen Denkschleife orchestriert werden, die planen, ausführen und lernen kann.

Um dieses Problem zu lösen, müssen die Entwickler einen komplexen und fehleranfälligen Stack von Grund auf neu aufbauen. Die heutige Agentenarchitektur erfordert das Zusammenfügen mehrerer, voneinander unabhängiger Komponenten: ein LLM, eine Vektordatenbank, ein Metadatenspeicher, separate Systeme für Protokollierung und Tracing sowie eine Möglichkeit zur Überprüfung, ob das Ganze überhaupt funktioniert. Das ist nicht nur komplex, sondern auch kostspielig, fehleranfällig und erschwert den Aufbau der hochwertigen, vertrauenswürdigen KI-Systeme, die Ihre Nutzer fordern.

Wir wollen es also vereinfachen. Unser Ansatz hierfür besteht darin, die wesentlichen Bestandteile eines effektiven kontextgesteuerten Agenten zu nehmen und sie mit einer neuen Reihe von Funktionen namens Elastic AI Agent Builder direkt in den Kern von Elasticsearch zu integrieren. Diese neue Schicht bietet ein Framework mit allen wesentlichen Bausteinen für die Erstellung von KI-Agenten auf Basis von Elasticsearch: ein offenes Set an Primitiven, standardbasierte Protokolle und sicherer Datenzugriff – damit Sie agentenbasierte Systeme entwickeln können, die auf reale Daten und Anforderungen zugeschnitten sind:

KI-Erlebnisse bereitstellen: Das ist das ultimative Ziel. Mit unserer Search AI Platform und Ihren Daten als Grundlage können Sie jede Art von generativer KI-Anwendung erstellen: von benutzerdefinierten Chat-Oberflächen bis hin zu Integrationen mit agentenbasierten Frameworks wie LangChain oder Geschäftsanwendungen wie Salesforce.

Unterstützt von Agenten und Tools: Auf der Plattform selbst stellen wir eine saubere, einfache Abstraktionsschicht bereit. Sie interagieren direkt mit Agenten und Tools, die Sie an Ihre spezifischen Bedürfnisse anpassen können. Sie können die Funktionen der Plattform auch über robuste APIs und offene Standards wie MCP und A2A nutzen.

Ermöglicht durch die Search AI Platform: Dies ist die Kern-Engine, in die wir die Komponenten integriert haben. Die hochentwickelte Vektordatenbank, die Agentenlogik, die Abfragekonstruktion, Sicherheitsfunktionen, das Tracing zur Auswertung – all das befindet sich hier und wird von Elastic verwaltet und optimiert.

Das Potenzial Ihrer Daten freisetzen: Die Grundlage jedes erfolgreichen Agenten sind hervorragende Daten. Unsere Plattform beginnt mit der Fähigkeit, den Zugriff auf alle Ihre Unternehmensdaten zu erfassen oder zu föderieren.

Agentenaufbau in der Plattform

Der in die Search AI Platform integrierte Agent Builder bietet ein komplettes Framework für die Agentenentwicklung. Es basiert auf fünf zentralen Säulen, von denen jede einen kritischen Aspekt beim Aufbau und Einsatz produktionsreifer KI-Systeme adressiert. Lassen Sie uns aufschlüsseln, wie Agenten das Ziel definieren, Tools die Fähigkeiten bereitstellen, offene Standards Interoperabilität gewährleisten, Evaluierung Transparenz schafft und Sicherheit das Vertrauen schafft.

Agenten

Agenten sind die obersten Bausteine dieser neuen Ebene von Elasticsearch. Ein Agent definiert das zu erreichende Ziel, die zur Ausführung verfügbaren Werkzeuge und die Datenquellen, mit denen er arbeiten kann. Agenten sind nicht auf dialogbasierte Interaktionen beschränkt; sie können komplette Arbeitsabläufe, Aufgabenautomatisierung oder benutzerorientierte Erlebnisse ermöglichen.

Wenn eine Anfrage an einen Agenten gerichtet wird, durchläuft sie einen strukturierten Zyklus:

1. Interpretieren Sie Ihre Eingabe und Ihr Ziel.

2. Wählen Sie das richtige Werkzeug und die richtigen Argumente für die Ausführung aus.

3. Begründen Sie die Antwort des Tools.

4. Entscheiden Sie, ob ein Ergebnis zurückgegeben oder mit weiteren Toolaufrufen fortgefahren werden soll.

Elastic übernimmt die Orchestrierung, den Kontext und die Ausführung dieses Zyklus. Die Entwickler konzentrieren sich darauf, festzulegen, was der Agent tun soll: Ziele, Werkzeuge und Daten, während das System die Durchführung der Schlussfolgerungen und Arbeitsabläufe steuert.

Der Standardagent

Unser erster Agent, der auf dieser Plattform basiert, ist ein nativer Dialogagent in Kibana, der Ihnen die Möglichkeit gibt, sofort mit Ihren Daten zu interagieren. Es bietet eine sofort einsatzbereite Benutzererfahrung und bleibt gleichzeitig vollständig erweiterbar, sodass Sie ohne zusätzliche Konfiguration sofort mit Ihren Daten interagieren können.

Sie können mit dieser Funktion direkt in Kibana über eine neue Chat-Benutzeroberfläche oder über eine API interagieren.

Die Abfrage des Standardagenten über die API erfordert nur einen einzigen Aufruf:

Da Konversationen zustandsbehaftet sind, können Sie die Interaktion mit einem Agenten mithilfe einer conversation_id fortsetzen oder den vollständigen Konversationsverlauf abrufen:

Zollagenten

Entwickler können über einfache APIs auch ihre eigenen benutzerdefinierten Agenten erstellen. Agenten kapseln Anweisungen, Werkzeuge und Datenzugriff und erstellen so maßgeschneiderte Schlussfolgerungsmaschinen.

Die Erstellung eines benutzerdefinierten Agenten ist so einfach wie ein einziger API-Aufruf. Das folgende Beispiel zeigt, dass das Feld „Konfiguration“ alle wichtigen Details enthält, wie z. B. Anweisungen oder verfügbare Tools:

Sobald der Agent erstellt ist, kann er direkt abgefragt werden:

Dieser Ansatz wandelt den Agenten von einem komplexen, von Grund auf neu zu entwickelnden System in eine einfache, deklarative Einheit der Geschäftslogik um, wodurch Sie intelligente Automatisierung schneller realisieren können.

Eine detaillierte Anleitung zum Erstellen eines spezialisierten Agenten von Grund auf finden Sie in unserem ausführlichen Schritt-für-Schritt-Leitfaden: Ihr erster elastischer Agent: Von einer einzelnen Abfrage zu einem KI-gestützten Chat.

Tools

Wenn Agenten definieren, was erreicht werden soll, definieren Werkzeuge, wie.

Die Tools stellen Agenten spezifische Elastic-Kernfunktionen zur Verfügung, um Informationen abzurufen und auszuführen oder Aktionen durchzuführen. Tools können Kernfunktionen wie das Abrufen von Indizes oder Zuordnungen umfassen, aber auch fortgeschrittenere Funktionen wie die Verarbeitung natürlicher Sprache zu ES|QL.

Elasticsearch wird mit einer Reihe von Standardwerkzeugen ausgeliefert, die für gängige Anwendungsfälle optimiert sind. Die wahre Flexibilität ergibt sich jedoch daraus, eigene Lösungen zu entwickeln. Durch die Definition von Tools legen Sie genau fest, welche Abfragen, Indizes und Felder einem Agenten mit ES|QL zugänglich gemacht werden, und erhalten so eine präzise Kontrolle über Geschwindigkeit, Genauigkeit und Sicherheit.

Die Registrierung eines neuen Tools ist ebenfalls so einfach wie ein einziger API-Aufruf. Sie könnten ein Tool erstellen, das unsere ES|QL (Elasticsearch Query Language) nutzt, um Neuigkeiten über ein bestimmtes Finanzinstrument zu finden:

Nach der Registrierung können Sie das neue Tool Ihren benutzerdefinierten Agenten zuweisen und ihnen so eine kuratierte Auswahl an Funktionen zur Verfügung stellen, die sie bei Bedarf nutzen können.

Wir bieten eine Plattform zur Erstellung von maßgeschneiderten Tools für Ihre spezifischen Bedürfnisse, z. B. mit ES|QL, die den Agenten von einem Allzweckagenten in einen domänenspezifischen Experten verwandelt, der auf Ihren einzigartigen Daten und Ihrer Geschäftsdomäne basiert.

Offene Standards und Interoperabilität

Elasticsearch Agents und Tools werden über offene Standard-APIs bereitgestellt, wodurch sie sich leicht als grundlegende Bausteine in das breitere Ökosystem agentenbasierter Frameworks integrieren lassen. Unser Ansatz ist einfach: keine Blackboxes. Wir möchten, dass Sie die Kernkompetenz von Elastic im Bereich der Suche nutzen und sie mit komplementären Fähigkeiten und anderen agentenbasierten Systemen kombinieren können.

Um dies zu ermöglichen, stellen wir unsere Fähigkeiten über APIs, neue Protokolle und offene Standards zur Verfügung.

Model Context Protocol (MCP)

Das Model Context Protocol (MCP) entwickelt sich schnell zum offenen Standard für die systemübergreifende Vernetzung von Tools. Durch die Unterstützung von MCP kann Elasticsearch dialogbasierte KI mit Ihren Datenbanken, Indizes und externen APIs verbinden. Da im Elastic Stack ein Remote-MCP-Server integriert ist, kann jeder MCP-kompatible Client auf die Tools von Elastic zugreifen und sie als Bausteine in seinen umfassenderen agentenbasierten Workflows verwenden.

Das ist keine Einbahnstraße. Sie können außerdem Tools von externen MCP-Servern importieren und diese in Elasticsearch verfügbar machen. Schon bald werden MCP-Server wahrscheinlich für nahezu alles verfügbar sein und weitaus umfassender sein als alles, was wir selbst entwickeln könnten. Elastic bietet Such- und Abruffunktionen in großem Umfang, und Sie können dies mit spezialisierten Funktionen anderer Plattformen kombinieren, um effektive Agenten zu erstellen.

Agent-to-Agent (A2A)

Wir arbeiten außerdem an der Unterstützung von Agent zu Agent (A2A). Bei MCP geht es um die Vernetzung von Tools, bei A2A hingegen um die Vernetzung von Agenten. Mit einem A2A-Server können die von Ihnen erstellten Elastic-Agenten direkt mit Agenten aus anderen Systemen kommunizieren: Kontext austauschen, Aufgaben delegieren und Arbeitsabläufe koordinieren.

Man kann es sich als Interoperabilität auf der Ebene der Argumentation vorstellen. Ihr Elastic-Agent könnte die Suche und den Abruf übernehmen, dann eine Aufgabe an einen spezialisierten Support- oder IT-Agenten weitergeben und das Ergebnis nahtlos zurückerhalten. Das Ergebnis ist ein Ökosystem kooperierender Akteure, von denen jeder das tut, was er am besten kann.

Die Einführung von MCP und A2A unterstreicht letztlich unser Bekenntnis zu Elasticsearch als vollwertigem Bestandteil und gewährleistet die offene Integration innerhalb des gesamten agentenbasierten Ökosystems.

Rückverfolgung und Bewertung

Mit der Integration von Suchfunktionen in Agenten wird die Herausforderung einer effektiven Evaluierung entscheidend. Um Agenten in realen Unternehmensumgebungen bedenkenlos einsetzen zu können, benötigen Sie die Gewissheit, dass sie nicht nur präzise, sondern auch effizient und zuverlässig sind. Wie misst man die Leistung, diagnostiziert eine schlechte Reaktion oder verbessert die Ausgangslage? Alles beginnt mit Transparenz.

Aus diesem Grund haben wir unsere Agenten-APIs von Grund auf auf Transparenz ausgelegt. Betrachten wir folgende einfache Agenteninteraktion:

Die Antwort enthält nicht nur das Endergebnis, sondern auch den vollständigen Ausführungsablauf, aus dem hervorgeht, welche Werkzeuge der Agent ausgewählt hat, welche Parameter er verwendet hat und welche Ergebnisse jeder Schritt erbracht hat.

Eine umfassende Ablaufverfolgung und Protokollierung sind für einen kontinuierlichen Verbesserungsprozess unerlässlich, und schon bald können Sie diese Agenten-Traces direkt in Elasticsearch speichern und anzeigen. Noch besser: Diese Traces basieren auf dem OpenTelemetry-Protokoll, wodurch sichergestellt wird, dass sie standardisiert und portabel sind und sich in die Observability-Plattform Ihrer Wahl integrieren lassen.

Dieser Detaillierungsgrad ist die Grundlage für einen echten kontinuierlichen Verbesserungsprozess. Es ermöglicht Ihnen, eine umfassende Suite von Tests zu erstellen, Fehler zu beheben, Fehlermodi zu identifizieren, um Regressionen zu verhindern, und erfolgreiche Muster zu erfassen, um die Leistung feinabzustimmen. Letztendlich ist dieser datengetriebene Ansatz der Schlüssel zur Umwandlung eines vielversprechenden Prototyps in ein produktionsreifes, vertrauenswürdiges KI-System.

Security

Da Agenten und Tools immer leistungsfähiger werden, ist Sicherheit nicht mehr optional – sie ist grundlegend. Die Bereitstellung von APIs, die Automatisierung von Aufgaben und Arbeitsabläufen erfordert, dass Unternehmenssysteme vertrauenswürdig sind. Gerade weil Agenten immer mehr Arbeitsabläufe automatisieren, ist die Fähigkeit, diese zu sichern und sicherzustellen, dass sie den Unternehmensanforderungen entsprechen, von entscheidender Bedeutung.

Die genannten Funktionen übernehmen alle die in Elastic bereits heute verfügbaren Steuerelemente, einschließlich rollenbasierter Zugriffskontrolle (RBAC) für API-Aufrufe und API-Schlüsselverwaltung. Wir dehnen die gleichen Kontrollen auch auf neue Protokolle wie MCP aus. Das bedeutet Unterstützung für Standards wie OAuth sowie die Möglichkeit, benutzerdefinierte Authentifizierungsmechanismen einzubinden.

Unser Ziel ist es, Ihnen die Flexibilität zu geben, mit Agenten und Tools zu experimentieren und gleichzeitig das von Ihrer Organisation geforderte Maß an Sicherheit, Compliance und Governance aufrechtzuerhalten.

Was kommt als Nächstes?

Wir fügen nicht nur Funktionen hinzu; wir erweitern Elasticsearch für agentenbasierte Kontextentwicklung. Wir planen, unsere zukünftige Entwicklung auf diesen Prinzipien aufzubauen:

1. Bekenntnis zu Open Source und Standards

Unser Bekenntnis zu Open Source und offenen Standards gewährleistet, dass diese Funktionen mit externen Agenten-Frameworks interoperabel bleiben. Sie können jederzeit Agenten in Ihrem gesamten Ökosystem verbinden, erweitern und zusammenstellen und behalten dabei die Kontrolle über Ihre Daten und Arbeitsabläufe.

2. Wert des Kontextes

Der Kontext ist das größte Kapital eines KI-Agenten. Die Verwaltung des Kontextes während der Suchvorgänge und Workflow-Operationen der Agenten kann eine anspruchsvolle Aufgabe sein. Wir nutzen die Kernkompetenzen von Elastic, um Kontext-Engineering zu realisieren und sicherzustellen, dass Ihrem Agenten stets die relevantesten Informationen zur Verfügung stehen.

3. Fokus auf agentenbasierte Datenströme

Zukünftig werden Agenten eine immer größere Datenquelle darstellen, einschließlich der Ergebnisse von Agenten (generierte Dokumente, Berichte, Visualisierungen) und der Ausführungsspur von Agenten (ihr Denken, Werkzeugaufrufe, Speicher/Kontext). Elastic eignet sich hervorragend für die Verarbeitung dieser Art von Daten, und wir arbeiten an Forschungsprojekten zur Durchführung von Analysen, Auswertungen und automatisierten Verbesserungen mithilfe dieser Daten.

4. Sicherheit durch Design

KI-Agenten bringen eine ganze Reihe neuer Sicherheitsherausforderungen mit sich. Elastic war schon immer ein Vorreiter für sichere Lösungen und wir bauen auch weiterhin auf Enterprise-Niveau Schutzmechanismen, Zugriffskontrollen und "Zero-Trust"-Prinzipien.

5. In die Plattform integriert

Die Funktionen zum Erstellen von KI-Agenten sind in die Elasticsearch-Plattform integriert. Dies bedeutet, dass Funktionen auf Plattformebene wie Tracing, Evaluation, Visualisierung und Analyse auch für Agenten anwendbar sind. Sie möchten Dashboards auf Basis von Agentenausführungen entwickeln? Das ist bereits integriert. Sie möchten die Leistung des KI-Agenten mithilfe von Stimmungsanalysen bewerten? Die Plattform ermöglicht das. Dies ermöglicht es, einen kompletten Lebenszyklus rund um Ihre KI-Erlebnisse aufzubauen.

Elastic hat sich zum Ziel gesetzt, Ihnen Schnittstellen zur Verfügung zu stellen, mit denen Sie dialogbasierte KI und automatisierte Arbeitsabläufe entwickeln können, die vollständig integriert, erweiterbar und auf Ihren Daten basieren. Weitere technische Details und Fortschritte werden in Kürze bekannt gegeben.

Agent Builder ist ab sofort als private Vorschau verfügbar. Nehmen Sie Kontakt mit uns auf , um Zugang anzufordern. Haben Sie Fragen oder Feedback? Tauschen Sie sich mit unserer Entwickler-Community in unserem Slack-Workspace oder in unserem Diskussionsforum aus.

In diesem Artikel werden wir genau das tun. Wir werden eine Anwendung erstellen, die ein Bild eines Dashboards aufnimmt, unsere Mappings analysiert und anschließend ein Dashboard generiert, ohne dass wir Kibana überhaupt berühren müssen!

Schritte:

1. Hintergrund und Anwendungsablauf

2. Daten vorbereiten

3. LLM-Konfiguration

4. Anwendungsfunktionen

Hintergrund und Anwendungsablauf

Mein erster Gedanke war, den LLM das gesamte NDJSON-Format der in Kibana gespeicherten Objekte generieren zu lassen und sie dann in Kibana zu importieren.

Wir haben eine Handvoll Modelle ausprobiert:

• Gemini 2.5 Pro

• GPT o3 / o4-mini-hoch / 4.1

• Claude 4 Sonett

• Grok 3

• Deepseek (Deepthink R1)

Und als Anregungen begannen wir mit ganz einfachen Dingen:

Trotz der Durchsicht einiger weniger Beispiele und detaillierter Erklärungen zum Aufbau der einzelnen Visualisierungen hatten wir keinen Erfolg. Wenn Sie an diesem Experiment interessiert sind, finden Sie hier weitere Informationen.

Das Ergebnis dieser Vorgehensweise war, dass beim Versuch, die vom LLM erzeugten Dateien in Kibana hochzuladen, diese Meldungen angezeigt wurden:

Das bedeutet, dass das generierte JSON ungültig oder schlecht formatiert ist. Die häufigsten Probleme waren, dass der LLM unvollständiges NDJSON erzeugte, Parameter falsch interpretierte oder normales JSON anstelle von NDJSON zurückgab, egal wie sehr wir uns bemühten, das Gegenteil zu erzwingen.

Inspiriert von diesem Artikel – in dem Suchvorlagen besser funktionierten als LLM Freestyle – entschieden wir uns, dem LLM Vorlagen zu übergeben, anstatt die vollständige NDJSON-Datei generieren zu lassen und anschließend im Code die vom LLM bereitgestellten Parameter zur Erstellung der Visualisierungen zu verwenden. Dieser Ansatz hat sich bewährt und ist vorhersehbar und erweiterbar, da nun der Code und nicht mehr das LLM die Hauptarbeit übernimmt.

Der Bewerbungsprozess wird wie folgt ablaufen:

Der Einfachheit halber lassen wir einige Codeabschnitte weg, aber den vollständigen, lauffähigen Code der Anwendung finden Sie in diesem Notebook.

Voraussetzungen

Bevor Sie mit der Entwicklung beginnen, benötigen Sie Folgendes:

1. Python 3.8 oder höher

2. Eine Venv Python-Umgebung

3. Eine laufende Elasticsearch-Instanz, zusammen mit ihrem Endpunkt und API-Schlüssel

4. Ein OpenAI-API-Schlüssel, der unter dem Umgebungsvariablennamen OPENAI_API_KEY gespeichert ist:

Daten vorbereiten

Für die Daten halten wir es einfach und verwenden Elastic-Beispiel-Weblogs. Hier erfahren Sie, wie Sie diese Daten in Ihren Cluster importieren.

Jedes Dokument enthält Angaben zum Host, der die Anfragen an die Anwendung gestellt hat, sowie Informationen zur Anfrage selbst und deren Antwortstatus. Nachfolgend finden Sie ein Beispieldokument:

Nun holen wir uns die Zuordnungen des soeben geladenen Index, kibana_sample_data_logs:

Wir werden die Zuordnungen zusammen mit dem Bild übergeben, das wir später laden werden.

LLM-Konfiguration

Konfigurieren wir das LLM so, dass es strukturierte Ausgabe verwendet, um ein Bild einzugeben und ein JSON mit den Informationen zu erhalten, die wir an unsere Funktion übergeben müssen, um die JSON-Objekte zu erzeugen.

Wir installieren die Abhängigkeiten:

Elasticsearch wird uns dabei helfen, die Indexzuordnungen abzurufen. Pydantic ermöglicht es uns, Schemata in Python zu definieren, denen der LLM dann folgen soll, und LangChain ist das Framework, das den Aufruf von LLMs und KI-Tools vereinfacht.

Wir werden ein Pydantic-Schema erstellen, um die gewünschte Ausgabe des LLM zu definieren. Aus dem Bild müssen wir den Diagrammtyp, das Feld, den Visualisierungstitel und den Dashboard-Titel ablesen:

Als Bildeingabe senden wir ein Dashboard, das ich gerade gezeichnet habe:

Nun deklarieren wir den LLM-Modellaufruf und das Laden des Bildes. Diese Funktion erhält die Zuordnungen des Elasticsearch-Index und ein Bild des Dashboards, das wir generieren möchten.

Mit with_structured_output können wir unser Pydantic Dashboard Schema als Antwortobjekt verwenden, das der LLM erzeugen wird. Mit Pydantic können wir Datenmodelle mit Validierung definieren, wodurch sichergestellt wird, dass die LLM-Ausgabe der erwarteten Struktur entspricht.

Um das Bild in Base64 zu konvertieren und als Eingabe zu senden, können Sie einen Online-Konverter verwenden oder dies im Code erledigen.

Der LLM verfügt bereits über Kontextinformationen zu Kibana-Dashboards, daher müssen wir nicht alles in der Eingabeaufforderung erklären, sondern nur einige Details, um sicherzustellen, dass er nicht vergisst, dass er mit Elasticsearch und Kibana arbeitet.

Lassen Sie uns die Aufgabenstellung aufschlüsseln:

Abschnitt

Grund

Sie sind Experte in der Analyse von Kibana-Dashboards anhand von Images für die Version 9.0.0 von Kibana.

Durch die Verstärkung dieser Funktion wird Elasticsearch und die Verwendung der Elasticsearch-Version unterstützt, wodurch die Wahrscheinlichkeit verringert wird, dass das LLM alte/ungültige Parameter fälschlicherweise annimmt.

Sie erhalten ein Dashboard-Bild und eine Elasticsearch-Indexzuordnung.

Wir erklären, dass es sich bei dem Bild um Dashboards handelt, um Fehlinterpretationen seitens des LLM zu vermeiden.

Nachfolgend finden Sie die Indexzuordnungen für den Index, auf dem das Dashboard basiert. Nutzen Sie diese, um die Daten und die verfügbaren Felder besser zu verstehen. Indexzuordnungen: {index_mappings}

Es ist entscheidend, die Zuordnungen bereitzustellen, damit das LLM dynamisch gültige Felder auswählen kann. Andernfalls könnten wir die Zuordnungen hier fest codieren, was zu starr wäre, oder uns darauf verlassen, dass das Bild die richtigen Feldnamen enthält, was nicht zuverlässig ist.

Beschränken Sie sich auf die Felder, die für die jeweilige Visualisierung relevant sind, basierend auf dem, was im Bild sichtbar ist.

Wir mussten diese Verstärkung hinzufügen, weil manchmal versucht wird, Felder hinzuzufügen, die nicht zum Bild gehören.

Dies gibt ein Objekt mit einem Array von anzuzeigenden Visualisierungen zurück:

Verarbeitung der LLM-Antwort

WirWir haben ein Beispiel-Dashboard mit 2x2-Panels erstellt und es dann mithilfe der Get a dashboard API im JSON-Format exportiert. Anschließend haben wir die Panels als Visualisierungsvorlagen (Kreisdiagramm, Balkendiagramm, Metrikdiagramm) gespeichert, in denen wir einige der Parameter ersetzen können, um je nach Fragestellung neue Visualisierungen mit anderen Feldern zu erstellen.

Die JSON-Vorlagedateien können Sie hier einsehen. Beachten Sie, wie wir die Objektwerte, die wir später ersetzen möchten, durch {variable_name}ersetzt haben.

Anhand der von LLM bereitgestellten Informationen können wir entscheiden, welche Vorlage wir verwenden und welche Werte wir ersetzen.

fill_template_with_analysis empfängt die Parameter für ein einzelnes Panel, einschließlich der JSON-Vorlage der Visualisierung, eines Titels, eines Feldes und der Koordinaten der Visualisierung im Raster.

Anschließend werden die Werte der Vorlage ersetzt und die endgültige JSON-Visualisierung zurückgegeben.

Um es einfach zu halten, verwenden wir statische Koordinaten, die wir den vom LLM erstellten Panels zuweisen, und erzeugen so ein 2x2-Raster-Dashboard wie in der obigen Abbildung dargestellt.

Je nach dem vom LLM festgelegten Visualisierungstyp wählen wir eine JSON-Dateivorlage aus und ersetzen die relevanten Informationen durch fill_template_with_analysis . Anschließend fügen wir das neue Panel einem Array hinzu, das wir später zum Erstellen des Dashboards verwenden.

Sobald das Dashboard fertig ist, verwenden wir die „Create a dashboard“-API , um die neue JSON-Datei an Kibana zu übertragen und das Dashboard zu generieren:

Um das Skript auszuführen und das Dashboard zu generieren, führen Sie folgenden Befehl in der Konsole aus:

Das Endergebnis wird folgendermaßen aussehen:

Fazit

LLMs zeigen ihre ausgeprägten visuellen Fähigkeiten bei der Umwandlung von Text in Code oder der Umwandlung von Bildern in Code. Die Dashboards-API ermöglicht es auch, JSON-Dateien in Dashboards umzuwandeln, und mit einem LLM und etwas Code können wir Bilder in ein Kibana-Dashboard umwandeln.

Der nächste Schritt besteht darin, die Flexibilität der Dashboard-Visualisierungen durch die Verwendung unterschiedlicher Rastereinstellungen, Dashboard-Größen und -Positionen zu verbessern. Darüber hinaus wäre die Unterstützung komplexerer Visualisierungen und Visualisierungstypen eine sinnvolle Ergänzung dieser Anwendung.

In diesem Beitrag zeigen wir Ihnen, wie Sie mit Mastra einen agentenbasierten RAG-Assistenten und eine leichtgewichtige JavaScript-Webanwendung zur Interaktion mit diesem erstellen. Durch die Anbindung dieses Agenten an Elasticsearch erhalten Sie Zugriff auf strukturierte Spielerdaten und die Möglichkeit, statistische Aggregationen in Echtzeit durchzuführen, um Ihnen auf Spielerstatistiken basierende Empfehlungen geben zu können. Besuchen Sie das GitHub- Repository , um die Schritte nachzuvollziehen; die README-Datei enthält Anweisungen zum Klonen und Ausführen der Anwendung.

So sollte es aussehen, wenn alles zusammengebaut ist:

Hinweis: Dieser Blogbeitrag baut auf „ Entwicklung von KI-Agenten mit AI SDK und Elastic“ auf. Wenn Sie sich mit KI-Agenten im Allgemeinen noch nicht auskennen und nicht wissen, wofür sie eingesetzt werden könnten, fangen Sie dort an.

Architekturübersicht

Kernstück des Systems ist ein großes Sprachmodell (LLM), das als Denkmaschine (das Gehirn) des Agenten fungiert. Es interpretiert die Benutzereingaben, entscheidet, welche Tools aufgerufen werden sollen, und koordiniert die notwendigen Schritte, um eine relevante Antwort zu generieren.

Der Agent selbst wird von Mastra, einem Agenten-Framework im JavaScript-Ökosystem, bereitgestellt. Mastra umschließt das LLM mit einer Backend-Infrastruktur, stellt es als API-Endpunkt bereit und bietet eine Schnittstelle zur Definition von Tools, Systemaufforderungen und Agentenverhalten.

Im Frontend verwenden wir Vite , um schnell eine React-Webanwendung zu erstellen, die eine Chat-Oberfläche zum Senden von Anfragen an den Agenten und zum Empfangen seiner Antworten bereitstellt.

Schließlich gibt es noch Elasticsearch, das Spielerstatistiken und Matchup-Daten speichert, die der Agent abfragen und aggregieren kann.

Hintergrund

Lassen Sie uns einige grundlegende Konzepte durchgehen:

Was ist agentic RAG?

KI-Agenten können mit anderen Systemen interagieren, unabhängig agieren und Aktionen auf Basis ihrer definierten Parameter ausführen. Agentic RAG kombiniert die Autonomie eines KI-Agenten mit den Prinzipien der abrufverstärkten Generierung und ermöglicht es einem LLM, auszuwählen, welche Werkzeuge aufgerufen und welche Daten als Kontext verwendet werden sollen, um eine Antwort zu generieren. Lesen Sie hier mehr über RAG.

Warum sollte man bei der Wahl eines Frameworks über das AI-SDK hinausgehen?

Es gibt viele KI-Agenten-Frameworks, und Sie haben wahrscheinlich schon von den bekannteren wie CrewAI, AutoGen und LangGraph gehört. Die meisten dieser Frameworks verfügen über eine gemeinsame Funktionspalette, darunter die Unterstützung verschiedener Modelle, die Verwendung von Werkzeugen und das Speichermanagement.

Hier finden Sie eine Vergleichstabelle der verschiedenen Frameworks von Harrison Chase (CEO von LangChain).

Was mich an Mastra besonders interessiert hat, ist, dass es sich um ein JavaScript-basiertes Framework handelt, das für Full-Stack-Entwickler entwickelt wurde, um Agenten einfach in ihr Ökosystem zu integrieren. Das AI-SDK von Vercel kann das meiste davon auch, aber Mastra glänzt vor allem dann, wenn Ihre Projekte komplexere Agenten-Workflows beinhalten. Mastra erweitert die vom AI-SDK festgelegten Basismuster, und in diesem Projekt werden wir sie gemeinsam verwenden.

Rahmenwerke und Überlegungen zur Modellwahl

Diese Frameworks können zwar dabei helfen, schnell KI-Agenten zu entwickeln, es gibt jedoch einige Nachteile zu beachten. Wenn man beispielsweise andere Frameworks als KI-Agenten oder Abstraktionsschichten im Allgemeinen verwendet, verliert man ein Stück weit die Kontrolle. Wenn das LLM die Werkzeuge nicht korrekt verwendet oder etwas tut, was Sie nicht möchten, erschwert die Abstraktion die Fehlersuche. Dennoch ist dieser Kompromiss meiner Meinung nach den Komfort und die Geschwindigkeit wert, die man beim Erstellen von Projekten erhält, insbesondere weil diese Frameworks immer beliebter werden und ständig weiterentwickelt werden.

Auch diese Frameworks sind modellagnostisch, das heißt, Sie können verschiedene Modelle einsetzen und verwenden. Bedenken Sie jedoch, dass sich die Modelle in den Datensätzen unterscheiden, mit denen sie trainiert wurden, und dass sich dadurch auch die Ergebnisse unterscheiden. Manche Modelle unterstützen nicht einmal den Aufruf von Tools. Es ist also möglich, zwischen verschiedenen Modellen zu wechseln und diese auszuprobieren, um zu sehen, welches die besten Ergebnisse liefert. Bedenken Sie jedoch, dass Sie höchstwahrscheinlich für jedes Modell die Systemabfrage neu schreiben müssen. Zum Beispiel mit Llama3.3 Im Vergleich zu GPT-4o sind deutlich mehr Aufforderungen und spezifische Anweisungen erforderlich, um die gewünschte Antwort zu erhalten.

NBA Fantasy Basketball

Beim Fantasy-Basketball geht es darum, mit einer Gruppe von Freunden eine Liga zu gründen (Achtung: Je nachdem, wie wettbewerbsorientiert eure Gruppe ist, könnte dies den Status eurer Freundschaften beeinträchtigen), wobei in der Regel auch Geld auf dem Spiel steht. Jeder von euch stellt dann ein Team aus 10 Spielern zusammen, die abwechselnd wöchentlich gegen die 10 Spieler eines anderen Freundes antreten. Die Punkte, die zu Ihrer Gesamtpunktzahl beitragen, ergeben sich aus der Leistung jedes Ihrer Spieler gegen seine Gegner in einer bestimmten Woche.

Wenn ein Spieler Ihres Teams verletzt, gesperrt usw. wird, steht Ihnen eine Liste von Free Agents zur Verfügung, die Sie Ihrem Team hinzufügen können. Hier findet ein Großteil des schwierigen Denkens im Fantasy-Sport statt, denn man hat nur eine begrenzte Anzahl an Spielern zur Auswahl und jeder ist ständig auf der Suche nach dem besten Spieler.

Hier wird unser NBA-KI-Assistent seine Stärken ausspielen, insbesondere in Situationen, in denen Sie schnell entscheiden müssen, welchen Spieler Sie auswählen. Anstatt manuell nachschlagen zu müssen, wie ein Spieler gegen einen bestimmten Gegner abschneidet, kann der Assistent diese Daten schnell finden und Durchschnittswerte vergleichen, um Ihnen eine fundierte Empfehlung zu geben.

Nachdem Sie nun einige Grundlagen zu Agentic RAG und NBA Fantasy Basketball kennengelernt haben, sehen wir uns das Ganze mal in der Praxis an.

Aufbau des Projekts

Falls Sie an irgendeiner Stelle nicht weiterkommen oder es nicht von Grund auf neu erstellen möchten, schauen Sie bitte im Repository nach.

Was wir behandeln werden

1. Gerüstbau für das Projekt:

   1. Backend (Mastra): Verwenden Sie npx create mastra@latest, um das Backend zu erstellen und die Agentenlogik zu definieren.

   2. Frontend (Vite + React): Verwenden Sie npm create vite@latest, um die Frontend-Chat-Oberfläche für die Interaktion mit dem Agenten zu erstellen.

2. Einrichten von Umgebungsvariablen

   1. Installieren Sie dotenv, um Umgebungsvariablen zu verwalten.

   2. Erstellen Sie eine .env-Datei Datei und geben Sie die erforderlichen Variablen an.

3. Elasticsearch einrichten

   1. Erstellen Sie einen Elasticsearch-Cluster (entweder lokal oder in der Cloud).

   2. Installieren Sie den offiziellen Elasticsearch-Client.

   3. Stellen Sie sicher, dass Umgebungsvariablen zugänglich sind.

   4. Verbindung zum Client herstellen.

4. Massenhaftes Einlesen von NBA-Daten in Elasticsearch

   1. Erstellen Sie einen Index mit den entsprechenden Zuordnungen, um Aggregationen zu ermöglichen.

   2. Spielerstatistiken aus einer CSV-Datei massenhaft in einen Elasticsearch-Index importieren.

5. Elasticsearch-Aggregationen definieren

   1. Abfrage zur Berechnung historischer Durchschnittswerte gegen einen bestimmten Gegner.

   2. Abfrage zur Berechnung der Saison-Durchschnittswerte gegen einen bestimmten Gegner.

6. Datei zum Spielervergleich

   1. Konsolidiert Hilfsfunktionen und Elasticsearch-Aggregationen.

7. Agentenaufbau

   1. Fügen Sie die Agentendefinition und die Systemeingabeaufforderung hinzu.

   2. Installieren Sie zod und definieren Sie Tools.

   3. Fügen Sie eine Middleware-Konfiguration zur Behandlung von CORS hinzu.

8. Integration des Frontends

   1. Die Interaktion mit dem Agenten erfolgt über die useChat-Funktion des AI-SDK.

   2. Erstellen Sie eine Benutzeroberfläche, die ordnungsgemäß formatierte Konversationen ermöglicht.

9. Die Anwendung ausführen

   1. Starten Sie sowohl das Backend (Mastra-Server) als auch das Frontend (React-App).

   2. Beispielabfragen und Anwendungsbeispiele.

10. Was kommt als Nächstes: Den Agenten intelligenter machen.

    1. Durch die Integration semantischer Suchfunktionen können aussagekräftigere Empfehlungen ermöglicht werden.

    2. Aktivieren Sie dynamische Abfragen, indem Sie die Suchlogik auf den Elasticsearch MCP (Model Context Protocol)-Server verlagern.

Voraussetzungen

• Node.js und npm: Sowohl das Backend als auch das Frontend laufen auf Node.js. Stellen Sie sicher, dass Sie Node 18+ und npm v9+ installiert haben (das in Node 18+ standardmäßig enthalten ist).

• Elasticsearch-Cluster: Ein aktiver Elasticsearch-Cluster, entweder lokal oder in der Cloud.

• OpenAI API-Schlüssel: Generieren Sie einen auf der Seite „API-Schlüssel“ im Entwicklerportal von OpenAI.

Projektstruktur

Schritt 1: Das Projektgerüst erstellen

1. Erstellen Sie zunächst das Verzeichnis nba-ai-assistant-js und navigieren Sie darin mit folgendem Befehl:

Backend:

1. Verwenden Sie das Mastra-Erstellungstool mit folgendem Befehl:

2. Sie sollten nun einige Eingabeaufforderungen in Ihrem Terminal erhalten. Bei der ersten nennen wir das Projekt-Backend:

3. Als nächstes behalten wir die Standardstruktur für die Speicherung der Mastra-Dateien bei, also Eingabe src/.

4. Dann wählen wir OpenAI als unseren Standard-LLM-Anbieter.

5. Abschließend werden Sie nach Ihrem OpenAI-API-Schlüssel gefragt. Fürs Erste wählen wir die Option, dies zu überspringen und es später in einer .env -Datei bereitzustellen.

Frontend:

1. Wechseln Sie zurück in das Stammverzeichnis und führen Sie das Vite-Erstellungstool mit folgendem Befehl aus: npm create vite@latest frontend -- --template react

Dadurch sollte eine leichtgewichtige React-App mit dem Namen frontend und einer spezifischen Vorlage für React erstellt werden.

Wenn alles gut geht, sollten Sie in Ihrem Projektverzeichnis ein Backend-Verzeichnis sehen, das den Mastra-Code enthält, und ein frontend -Verzeichnis mit Ihrer React-App.

Schritt 2: Umgebungsvariablen einrichten

1. Zur Verwaltung sensibler Schlüssel verwenden wir das Paket dotenv , um unsere Umgebungsvariablen aus der .env-Datei zu laden. Datei. Navigieren Sie zum Backend-Verzeichnis und installieren Sie dotenv:

2. Im Backend-Verzeichnis befindet sich eine example.env-Datei mit den entsprechenden Variablen zum Ausfüllen. Wenn Sie Ihre eigene Version erstellen, achten Sie darauf, die folgenden Variablen einzubeziehen:

Hinweis: Stellen Sie sicher, dass diese Datei von Ihrer Versionskontrolle ausgeschlossen wird, indem Sie .env zu .gitignore hinzufügen.

Schritt 3: Elasticsearch einrichten

Als Erstes benötigen Sie einen aktiven Elasticsearch-Cluster. Es gibt zwei Möglichkeiten:

• Option A: Elasticsearch Cloud verwenden

  • Registrieren Sie sich für Elastic Cloud

  • Erstellen Sie eine neue Bereitstellung

  • Rufen Sie Ihre Endpunkt-URL und Ihren API-Schlüssel (kodiert) ab.

• Option B: Elasticsearch lokal ausführen

  • Elasticsearch lokal installieren und ausführen

  • Verwenden Sie http://localhost:9200 als Endpunkt.

  • API-Schlüssel generieren

Installation des Elasticsearch-Clients auf dem Backend:

1. Installieren Sie zunächst den offiziellen Elasticsearch-Client in Ihrem Backend-Verzeichnis:

2. Erstellen Sie anschließend ein Verzeichnis „lib“, um wiederverwendbare Funktionen zu speichern, und wechseln Sie in dieses Verzeichnis:

3. Erstellen Sie darin eine neue Datei namens elasticClient.js. Diese Datei initialisiert den Elasticsearch-Client und stellt ihn für die Verwendung in Ihrem gesamten Projekt zur Verfügung.

4. Da wir ECMAScript-Module (ESM) verwenden, sind __dirname and __-Dateinamen nicht verfügbar. Um sicherzustellen, dass Ihre Umgebungsvariablen korrekt aus der .env-Datei geladen werden Fügen Sie diese Konfiguration am Anfang der Datei im Backend-Ordner hinzu:

5. Initialisieren Sie nun den Elasticsearch-Client mithilfe Ihrer Umgebungsvariablen und überprüfen Sie die Verbindung:

Nun können wir diese Clientinstanz in jede Datei importieren, die mit Ihrem Elasticsearch-Cluster interagieren muss.

Schritt 4: Massenhaftes Einlesen von NBA-Daten in Elasticsearch

Datensatz:

Für dieses Projekt werden wir auf die Datensätze im Verzeichnis backend/data des Repos zurückgreifen. Unser NBA-Assistent wird diese Daten als Wissensbasis für statistische Vergleiche und die Generierung von Empfehlungen nutzen.

• sample_player_game_stats.csv - Beispielhafte Spielstatistiken eines Spielers (z. B. Punkte, Rebounds, Steals usw.) pro Spiel und Spieler während seiner gesamten NBA-Karriere. Wir werden diesen Datensatz für Aggregationen verwenden. (Hinweis: Dies sind Beispieldaten, die zu Demonstrationszwecken generiert wurden und nicht aus offiziellen NBA-Quellen stammen.)

• playerAndTeamInfo.js - Ersetzt die Spieler- und Team-Metadaten, die normalerweise über einen API-Aufruf bereitgestellt werden, damit der Agent Spieler- und Teamnamen IDs zuordnen kann. Da wir Beispieldaten verwenden, möchten wir den Aufwand des Abrufens von einer externen API vermeiden. Daher haben wir einige Werte fest codiert, auf die der Agent zugreifen kann.

Durchführung:

1. Erstellen Sie im Verzeichnis backend/lib eine Datei mit dem Namen playerDataIngestion.js.

2. Importe einrichten, den CSV-Dateipfad auflösen und das Parsen einrichten. Da wir ESM verwenden, müssen wir __dirname rekonstruieren, um den Pfad zur Beispiel-CSV-Datei aufzulösen. Außerdem importieren wir Node.js. eingebaute Module fs und readline, um die gegebene CSV-Datei Zeile für Zeile zu analysieren.

Damit sind Sie bestens gerüstet, um die CSV-Datei effizient zu lesen und zu analysieren, wenn wir zum Schritt der Massenverarbeitung übergehen.

3. Erstellen Sie einen Index mit der entsprechenden Zuordnung. Obwohl Elasticsearch Feldtypen mithilfe von Dynamic Mapping automatisch ableiten kann, möchten wir hier explizit vorgehen, damit jede Statistik als numerisches Feld behandelt wird. Dies ist wichtig, da wir diese Felder später für Aggregationen verwenden werden. Wir möchten außerdem den Typ float für Statistiken wie Punkte, Rebounds usw. verwenden, um sicherzustellen, dass wir Dezimalwerte einbeziehen. Zum Schluss möchten wir die Mapping-Eigenschaft dynamic: 'strict' hinzufügen, damit Elasticsearch nicht dynamisch nicht erkannte Felder zuordnet. 

4. Fügen Sie die Funktion hinzu, um die CSV-Daten in Ihren Elasticsearch-Index zu importieren. Innerhalb des Codeblocks überspringen wir die Kopfzeile. Anschließend werden die einzelnen Zeilen durch Kommas getrennt und in das Dokumentobjekt eingefügt. Dieser Schritt reinigt sie außerdem und stellt sicher, dass es sich um den richtigen Typ handelt. Als nächstes fügen wir die Dokumente zusammen mit den Indexinformationen in das bulkBody-Array ein, welches als Nutzlast für die Massenaufnahme in Elasticsearch dient.

5. Anschließend können wir die Bulk-API von Elasticsearch mit elasticClient.bulk() verwenden, um mehrere Dokumente in einer einzigen Anfrage zu erfassen. Die unten beschriebene Fehlerbehandlung ist so aufgebaut, dass sie Ihnen eine Übersicht darüber gibt, wie viele Dokumente nicht eingelesen werden konnten und wie viele erfolgreich eingelesen wurden.

6. Führen Sie die unten stehende Funktion main() aus, um die Funktionen createIndex() und bulkIngestCsv() nacheinander auszuführen.

Wenn in der Konsole eine Meldung erscheint, dass die Massenaufnahme erfolgreich war, überprüfen Sie kurz Ihren Elasticsearch-Index, um festzustellen, ob die Dokumente tatsächlich erfolgreich aufgenommen wurden.

Schritt 5: Elasticsearch-Aggregationen definieren und konsolidieren

Dies sind die Hauptfunktionen, die wir verwenden werden, wenn wir die Werkzeuge für den KI-Agenten definieren, um die Statistiken der Spieler miteinander zu vergleichen.

1. Navigieren Sie zum Verzeichnis backend/lib und erstellen Sie eine Datei namens elasticAggs.js.

2. Fügen Sie die unten stehende Abfrage hinzu, um historische Durchschnittswerte für einen Spieler gegen einen bestimmten Gegner zu berechnen. Diese Abfrage verwendet einen bool -Filter mit 2 Bedingungen: eine, die player_id entspricht, und eine weitere, die opponent_team_id entspricht, um nur die relevanten Spiele abzurufen. Wir müssen keine Dokumente zurückgeben, uns geht es nur um die Aggregationen, deshalb setzen wir size:0. Im Block aggs führen wir mehrere Metrikaggregationen parallel auf Feldern wie points, rebounds, assists, steals, blocks und fg_percentage durch, um deren Durchschnittswerte zu berechnen. LLMs können bei Berechnungen ungenau sein, und dies lagert diesen Prozess an Elasticsearch aus, um sicherzustellen, dass unser NBA-KI-Assistent Zugriff auf genaue Daten hat.

3. Um die Saisondurchschnittswerte eines Spielers gegen einen bestimmten Gegner zu berechnen, verwenden wir praktisch die gleiche Abfrage wie für die historischen Ergebnisse. Der einzige Unterschied bei dieser Abfrage besteht darin, dass der bool -Filter eine zusätzliche Bedingung für game_date enthält. Das Feld game_date muss innerhalb des Bereichs der aktuellen NBA-Saison liegen. In diesem Fall liegt der Bereich zwischen 2024-10-01 und 2025-06-30. Die unten stehende zusätzliche Bedingung stellt sicher, dass die nachfolgenden Aggregationen nur die Spiele dieser Saison berücksichtigen.

Schritt 6: Spielervergleichstool

Um unseren Code modular und wartbar zu halten, erstellen wir eine Hilfsdatei, die Metadaten-Hilfsfunktionen und Elasticsearch-Aggregationen zusammenfasst. Dies wird das Hauptwerkzeug des Agenten mit Strom versorgen. Mehr dazu später:

1. Erstellen Sie eine neue Datei comparePlayers.js im Verzeichnis backend/lib .

2. Fügen Sie die unten stehende Funktion hinzu, um Metadaten-Helfer und Elasticsearch-Aggregationslogik in einer einzigen Funktion zu konsolidieren, die das Hauptwerkzeug des Agenten antreibt.

Schritt 7: Erstellung des Agenten

Nachdem Sie nun das Frontend- und Backend-Gerüst erstellt, NBA-Spieldaten eingespielt und eine Verbindung zu Elasticsearch hergestellt haben, können wir damit beginnen, alle Teile zusammenzufügen, um den Agenten zu entwickeln.

Definition des Agenten

1. Navigieren Sie zur Datei index.ts im Verzeichnis backend/src/mastra/agents und fügen Sie die Agentendefinition hinzu. Sie können Felder wie die folgenden angeben:

• Name: Geben Sie Ihrem Agenten einen Namen, der als Referenz verwendet wird, wenn er im Frontend aufgerufen wird.

• Anweisungen/Systemaufforderung: Eine Systemaufforderung gibt dem LLM den anfänglichen Kontext und die Regeln vor, die während der Interaktion zu befolgen sind. Es ähnelt der Aufforderung, die Benutzer über das Chatfenster senden, diese wird jedoch vor jeglicher Benutzereingabe angezeigt. Auch dies hängt vom gewählten Modell ab.

• Modell: Welches LLM soll verwendet werden (Mastra unterstützt OpenAI, Anthropic, lokale Modelle usw.)?

• Tools: Eine Liste der Tool-Funktionen, die der Agent aufrufen kann.

• Speicher: (Optional) Wenn der Agent sich den Gesprächsverlauf usw. merken soll. Der Einfachheit halber können wir ohne persistenten Speicher beginnen, obwohl Mastra diesen unterstützt.

Werkzeuge definieren

1. Navigieren Sie zur Datei index.ts im Verzeichnis backend/src/mastra/tools .

2. Installieren Sie Zod mit folgendem Befehl:

3. Werkzeugdefinitionen hinzufügen. Beachten Sie, dass wir die Funktion innerhalb der Datei comparePlayers.js als Hauptfunktion importieren, die der Agent beim Aufruf dieses Tools verwenden wird. Mit der Funktion createTool() von Mastra registrieren wir unser playerComparisonTool. Zu den Feldern gehören:

• idDies ist eine Beschreibung in natürlicher Sprache, die dem Agenten hilft zu verstehen, was das Tool leistet.

• input schemaUm die Form der Eingabe für das Tool zu definieren, verwendet Mastra das Zod -Schema, eine TypeScript-Bibliothek zur Schema-Validierung. Zod hilft dabei, indem es sicherstellt, dass der Agent korrekt strukturierte Eingaben vornimmt und die Ausführung des Tools verhindert, wenn die Eingabestruktur nicht übereinstimmt.

• descriptionDies ist eine Beschreibung in natürlicher Sprache, die dem Agenten helfen soll zu verstehen, wann er anrufen und das Tool verwenden soll.

• executeDie Logik, die beim Aufruf des Tools ausgeführt wird. In unserem Fall verwenden wir eine importierte Hilfsfunktion, um Leistungsstatistiken zurückzugeben.

Hinzufügen von Middleware zur Behandlung von CORS

Fügen Sie Middleware auf dem Mastra-Server hinzu, um CORS zu behandeln. Man sagt, es gäbe drei Dinge im Leben, denen man nicht entkommen kann: den Tod, die Steuern und für Webentwickler zusätzlich CORS. Kurz gesagt, Cross-Origin Resource Sharing ist eine Browser-Sicherheitsfunktion, die verhindert, dass das Frontend Anfragen an ein Backend sendet, das auf einer anderen Domain oder einem anderen Port läuft. Obwohl wir sowohl das Backend als auch das Frontend auf localhost betreiben, verwenden sie unterschiedliche Ports, wodurch die CORS-Richtlinie ausgelöst wird. Wir müssen die in der Mastra-Dokumentation beschriebene Middleware hinzufügen, damit unser Backend diese Anfragen vom Frontend zulässt.

1. Navigieren Sie zur Datei index.ts im Verzeichnis backend/src/mastra und fügen Sie die Konfiguration für CORS hinzu:

• origin: ['http://localhost:5173']

  • Erlaubt Anfragen nur von dieser Adresse (Vite-Standardadresse)

• allowMethods: ["GET", "POST"]

  • Zulässige HTTP-Methoden. In den meisten Fällen wird POST verwendet.

• allowHeaders: ["Content-Type", "Authorization", "x-mastra-client-type, "x-highlight-request", "traceparent"],

  • Diese legen fest, welche benutzerdefinierten Header in Anfragen verwendet werden können.

Schritt 8: Integration des Frontends

Diese React-Komponente stellt eine einfache Chat-Oberfläche bereit, die über den useChat() -Hook aus @ai-sdk/react eine Verbindung zum Mastra AI-Agenten herstellt. Wir werden diesen Hook auch verwenden, um die Tokenverwendung und Toolaufrufe anzuzeigen sowie die Konversation darzustellen. In der obigen Systemabfrage bitten wir den Agenten außerdem, die Antwort im Markdown-Format auszugeben. Daher verwenden wir react-markdown , um die Antwort korrekt zu formatieren.

1. Installieren Sie im Frontend-Verzeichnis das Paket @ai-sdk/react, um den useChat()-Hook verwenden zu können.

2. Installieren Sie im selben Verzeichnis React Markdown, damit wir die vom Agenten generierte Antwort richtig formatieren können.

3. Implementiere useChat(). Dieser Hook steuert die Interaktion zwischen Ihrem Frontend und Ihrem KI-Agenten-Backend. Es verarbeitet Nachrichtenstatus, Benutzereingaben und Statusinformationen und bietet Lebenszyklus-Hooks zur Überwachung. Zu den Optionen, die wir übergeben, gehören:

• api: Dies definiert den Endpunkt Ihres Mastra AI-Agenten. Standardmäßig wird Port 4111 verwendet, und wir möchten außerdem die Route hinzufügen, die Streaming-Antworten unterstützt.

• onToolCallDies wird immer dann ausgeführt, wenn der Agent ein Tool aufruft; wir verwenden es, um zu verfolgen, welche Tools unser Agent aufruft.

• onFinishDies wird ausgeführt, nachdem der Agent eine vollständige Antwort abgegeben hat. Auch wenn wir Streaming aktiviert haben, wird onFinish erst ausgeführt, nachdem die gesamte Nachricht empfangen wurde, und nicht nach jedem einzelnen Datenblock. Hier verwenden wir es, um unsere Token-Nutzung zu verfolgen. Dies kann hilfreich sein, um die LLM-Kosten zu überwachen und zu optimieren.

4. Zum Schluss gehen Sie zur Komponente ChatUI.jsx im Verzeichnis frontend/components , um die Benutzeroberfläche für unsere Konversation zu erstellen. Als Nächstes muss die Antwort in eine ReactMarkdown -Komponente eingeschlossen werden, um die Antwort des Agenten korrekt zu formatieren.

Schritt 9: Ausführen der Anwendung

Glückwunsch! Sie können die Anwendung nun ausführen. Folgen Sie diesen Schritten, um sowohl das Backend als auch das Frontend zu starten.

1. Öffnen Sie ein Terminalfenster, beginnend im Stammverzeichnis, und navigieren Sie zum Backend-Verzeichnis. Starten Sie dort den Mastra-Server:

2. Öffnen Sie ein weiteres Terminalfenster, beginnend mit dem Stammverzeichnis, und navigieren Sie zum Frontend-Verzeichnis. Starten Sie dort die React-App:

3. Öffnen Sie Ihren Browser und navigieren Sie zu:

http://localhost:5173

Sie sollten die Chat-Oberfläche sehen können. Probieren Sie diese Beispielaufforderungen aus:

• „Vergleiche LeBron James und Stephen Curry“

• "Wen soll ich wählen, Jayson Tatum oder Luka Doncic?"

Was kommt als Nächstes: Den Agenten intelligenter machen.

Um den Assistenten handlungsfähiger und die Empfehlungen aussagekräftiger zu gestalten, werde ich in der nächsten Version einige wichtige Verbesserungen vornehmen.

Semantische Suche nach NBA-Nachrichten

Es gibt unzählige Faktoren, die die Leistung eines Spielers beeinflussen können, viele davon spiegeln sich nicht in den reinen Statistiken wider. Dinge wie Verletzungsberichte, Aufstellungsänderungen oder auch eine Spielanalyse nach dem Spiel findet man nur in Nachrichtenartikeln. Um diesen zusätzlichen Kontext zu erfassen, werde ich semantische Suchfunktionen hinzufügen, damit der Agent relevante NBA-Artikel abrufen und diese Erzählung in seine Empfehlungen einbeziehen kann.

Dynamische Suche mit dem Elasticsearch MCP-Server

MCP (Model Context Protocol) entwickelt sich schnell zum Standard für die Art und Weise, wie Agenten Verbindungen zu Datenquellen herstellen. Ich werde die Suchlogik auf den Elasticsearch MCP-Server migrieren, wodurch der Agent Abfragen dynamisch erstellen kann, anstatt sich auf vordefinierte Suchfunktionen zu verlassen, die wir bereitstellen. Dies ermöglicht uns die Nutzung von Workflows in natürlicher Sprache und reduziert den Aufwand, jede einzelne Suchanfrage manuell zu formulieren. Erfahren Sie hier mehr über den Elasticsearch MCP-Server und den aktuellen Stand des Ökosystems.

Diese Änderungen sind bereits im Gange, bleiben Sie gespannt!

Fazit

In diesem Blog haben wir einen agentenbasierten RAG-Assistenten entwickelt, der mithilfe von JavaScript, Mastra und Elasticsearch maßgeschneiderte Empfehlungen für Ihr Fantasy-Basketballteam liefert. Wir behandelten Folgendes:

• Grundlagen von Agentic RAG und wie die Kombination der Autonomie eines KI-Agenten mit den Werkzeugen zur effektiven Nutzung von RAG zu differenzierteren und dynamischeren Agenten führen kann.

• Elasticsearch und wie seine Datenspeicherfunktionen und leistungsstarken nativen Aggregationen es zu einem großartigen Partner als Wissensbasis für ein LLM machen.

• Das Mastra- Framework und wie es die Entwicklung dieser Agenten für Entwickler im JavaScript-Ökosystem vereinfacht.

Egal, ob Sie ein Basketballfanatiker sind, sich damit beschäftigen, wie man KI-Agenten entwickelt, oder beides wie ich, ich hoffe, dieser Blog hat Ihnen einige Bausteine für den Einstieg geliefert. Das vollständige Repository ist auf GitHub verfügbar, Sie können es gerne klonen und damit experimentieren. Jetzt hol dir den Sieg in der Fantasy-Liga!

In diesem Blogbeitrag wird die Verwendung von Elasticsearch und Azure Open AI zum Erstellen einer Beispiel-App beschrieben, die zeigt, wie bei der Suche nach sehr spezifischen Immobilienobjekten genaue Ergebnisse erzielt werden und gleichzeitig relevante Ergebnisse bereitgestellt werden, wenn keine spezifische Übereinstimmung verfügbar ist. Wir gehen alle erforderlichen Schritte durch, um einen Elasticsearch-Index zusammen mit einer Suchvorlage zu erstellen. Anschließend erläutern wir den gesamten Prozess der Erstellung einer App, die Azure OpenAI verwendet, um Benutzerabfragen entgegenzunehmen und in Elasticsearch-Suchvorlagenabfragen umzuwandeln, die erstaunlich benutzerdefinierte Ergebnisse liefern können.

Hier ist eine Liste aller Ressourcen, die wir zum Erstellen unserer Beispiel-App zur Immobiliensuche verwenden werden:

• Elasticsearch-Index und Suchvorlage

• Azure OpenAI

• Azure Maps-API

• Codespaces Jupyter Notebook

• Semantischer Kernel

• C#-App mit Blazor-Frontend

Intelligenter Abfrage-Workflow

Dieser Workflow kombiniert LLM, LLM-Tools und Suche, um Abfragen in natürlicher Sprache in strukturierte, relevante Suchergebnisse umzuwandeln:

• LLM (Large Language Model) – Interpretiert komplexe Benutzerabfragen und orchestriert Tools, um die Suchabsicht zu extrahieren und den Kontext anzureichern.

• LLM-Tools – Jedes LLM-Tool ist ein C#-Programm, das wir für diesen Beitrag erstellt haben. Es gibt drei Werkzeuge:

  • Tool zur Parameterextraktion: zieht wichtige Attribute wie Schlafzimmer, Badezimmer, Ausstattung und Preis aus der Abfrage.

  • GeoCode-Tool: Konvertiert Ortsnamen in Breiten-/Längengrade zur räumlichen Filterung.

  • Suchtool: füllt eine Elasticsearch-Suchvorlage mit Abfrageparametern und führt eine Suche aus. Hybridsuche – Führt eine Hybridsuche (Volltext + dichter Vektor) mit integrierter ML-Inferenz aus. Dieser mehrschichtige Ansatz gewährleistet intelligentere, kontextbezogene Abfrageerlebnisse für den Endbenutzer.

Anwendungsarchitektur

Hier ist ein Systemarchitekturdiagramm der Beispiel-App. Wir werden ein Codespaces Jupyter Notebook verwenden, um mit Elastic Cloud zu interagieren.

Voraussetzungen

Sie benötigen nur Ihren Browser, da wir GitHub Codespaces verwenden, um die Beispiel-App zu klonen, zu konfigurieren und auszuführen. Für den Elastic-Teil der Lösung verwenden wir Elastic Cloud , um ein Elasticsearch Serverless-Projekt zu erstellen. Wir verwenden das Azure-Portal für die Arbeit mit Azure-Ressourcen.

Klonen Sie das Beispiel-App-Repository in Codespaces

Beginnen Sie mit dem Klonen des Codes für die Beispielanwendung. Sie können dies in GitHub Codespaces tun, das eine Möglichkeit zum Klonen und Ausführen von Anwendungen bietet. Klicken Sie auf „Neuer Codespace“.

Wählen Sie dann das Repository jwilliams-elastic/msbuild-intelligent-query-demo im Dropdown-Menü „Repository“ aus und klicken Sie auf „Codespace erstellen“.

Erstellen Sie .env Datei

Wir verwenden ein Python Jupyter Notebook, um auf Elastic Cloud zuzugreifen und mit ihr zu interagieren. Dabei werden die Konfigurationseinstellungen verwendet, die in einer Konfigurationsdatei gespeichert sind. Die Konfigurationsdatei für das Notebook sollte den Dateinamen .env haben und Sie werden es jetzt erstellen.

1. Klicken Sie in GitHub Codespaces auf die Schaltfläche „Neue Datei“und fügen Sie eine Datei mit dem Namen .envhinzu.

2. Fügen Sie der neu erstellten .env -Datei den folgenden Inhalt hinzu Datei

Wie Sie sehen, fehlen uns einige Werte, ELASTIC_URL und ELASTIC_API_KEY, die der .env hinzugefügt werden müssen. Datei. Lassen Sie uns diese jetzt erhalten, indem wir ein serverloses Elasticsearch-Projekt erstellen, das als Backend dient und die Suchfunktion für unsere Beispiel-App bereitstellt.

Erstellen eines Elastic Serverless-Projekts

1. Gehen Sie zu cloud.elastic.co und klicken Sie auf „Neues serverloses Projekt erstellen“

2. Klicken Sie auf „Weiter“ , um zur Elasticsearch- Lösung zu gelangen.

3. Wählen Sie „Optimiert für Vektoren“

4. Legen Sie Azure als Cloud-Anbieter fest

5. Klicken Sie auf „Serverloses Projekt erstellen“

6. Klicken Sie im Hauptnavigationsmenü auf Erste Schritte und scrollen Sie nach unten, um die Verbindungsdetailszu kopieren

7. Klicken Sie auf die Schaltfläche „Kopieren“ , um den Elasticsearch-Endpunkt aus den Verbindungsdetailszu kopieren

8. Aktualisieren Sie .env Datei, um die ELASTIC_URL als kopierten Elasticsearch-Endpunktfestzulegen

Erstellen eines Elastic-API-Schlüssels

1. Öffnen Sie die Seite „Erste Schritte“ von Elasticsearch und klicken Sie im Abschnitt „API-Schlüssel hinzufügen“ auf „Neu“ .

2. Geben Sie einen Schlüsselnamenein

3. Klicken Sie auf API-Schlüssel erstellen

4. Klicken Sie auf die Schaltfläche „Kopieren“, um den API-Schlüsselwert zu kopieren

5. Zurück in Codespaces, wo wir die .envhabenÖffnen Sie die Datei zum Bearbeiten und fügen Sie den kopierten Wert ein, um den ELASTIC_API_KEYfestzulegen.

Öffnen Sie das Codespaces-Notebook und installieren Sie die Bibliotheksabhängigkeiten

Wählen Sie im Datei-Explorer die Datei VectorDBSetup.ipynb aus, um das Notebook zu öffnen. Suchen Sie nach dem Laden des Notebooks den Notebook -Abschnitt mit dem Titel „Bibliotheken installieren“. Klicken Sie auf die Schaltfläche „Abspielen“ des Abschnitts.

Wenn Sie zum ersten Mal ein Notebook in GitHub Codespaces ausführen, werden Sie aufgefordert, einen Codespaces-Kernel auszuwählen und die Python-Umgebung zu konfigurieren.

Definieren Sie Importe und laden Sie Umgebungsvariablen mit Codespaces Notebook

Gehen Sie zum nächsten Abschnitt im Notebook mit dem Titel „Importe definieren und Umgebungsvariablen laden“. Klicken Sie auf die Schaltfläche „Abspielen“ des Abschnitts.

Dieser Code importiert die vom Notebook verwendeten Python-Bibliotheken und lädt die Umgebungsvariablen aus der .env die Sie zuvor erstellt haben.

Erstellen Sie einen Elastic ML-Inferenzendpunkt mit dem Codespaces-Notebook

Gehen Sie zum nächsten Notebook -Abschnitt mit dem Titel „ML-Inferenz-Endpunkt erstellen“. Klicken Sie auf die Schaltfläche „Abspielen“ des Abschnitts.

Dadurch wird ein neuer ML-Inferenz-Endpunkt im Elasticsearch-Projekt erstellt, den wir zum Generieren von Text-Embeddings aus unseren Daten verwenden. Text-Embeddings sind Vektordarstellungen von Text, die in Elasticsearch gespeichert werden, um die semantische Suche zu unterstützen.

Erstellen Sie einen Elasticsearch-Index mit Codespaces Notebook

Gehen Sie zum nächsten Notebook -Abschnitt mit dem Titel „Elasticsearch-Index erstellen“. Klicken Sie auf die Schaltfläche „Abspielen“ des Abschnitts.

Dadurch wird der Elasticsearch-Index erstellt, in dem unsere Beispieldaten und alle zugehörigen Vektordaten gespeichert werden, die über den ML-Inferenz-Endpunkt generiert werden.

Erstellen Sie eine Elasticsearch-Suchvorlage mit Codespaces Notebook

Fahren Sie mit dem nächsten Notebook -Abschnitt mit dem Titel „Suchvorlage“ fort. Klicken Sie auf die Schaltfläche „Abspielen“ des Abschnitts.

Dadurch wird eine Suchvorlage erstellt, die unsere Beispiel-App als Vorlage verwendet und mit den Wörtern gefüllt, die aus der Suchanfrage eines Benutzers analysiert wurden. Dadurch können wir konfigurieren und steuern, wie spezifisch wir beim Abfragen von Daten im Elasticsearch-Index sind.

Daten mithilfe des Codespaces Notebooks in den Elasticsearch-Index aufnehmen

Gehen Sie zum nächsten Abschnitt des Notebooks mit dem Titel „ Eigenschaftsdaten aufnehmen“. Klicken Sie auf die Schaltfläche „Abschnitt ausführen“.

Durch Ausführen dieses Codeabschnitts werden die in der Datei „properties.jsonl“enthaltenen Beispieldaten in großen Mengen geladen. Nach einigen Minuten sollten Sie eine Bestätigung sehen, dass der Vorgang erfolgreich abgeschlossen wurde. Sie können bestätigen, dass der Index den erwarteten Datensatz enthält, indem Sie in Elastic Cloud zum Abschnitt Indexverwaltung gehen.

Erstellen Sie appsetting.json, um die C#-App zu konfigurieren

Nachdem unser Elasticsearch-Index erstellt und mit Daten gefüllt wurde, können wir nun die Beispiel-App für die Arbeit mit Elastic und Azure Cloud konfigurieren. Die C#-Beispiel-App verwendet eine Datei namens appsettings.json , um ihre Zugriffsinformationen wie API-Schlüssel zu speichern und zu laden. Sie erstellen die Datei appsettings.json jetzt mit dem Editor in Codespaces.

1. Erstellen Sie appsettings.json im HomeFinderApp -Ordner

2. Fügen Sie den folgenden Code in die Datei appsettings.json ein

3. Suchen Sie im Abschnitt „ElasticSettings“ nach den URL- und API -Schlüsselwerten. Legen Sie sie auf die gleichen Werte fest, die Sie in der .env-Datei festgelegt haben Datei in einem früheren Schritt.

Erstellen des Azure OpenAI-Diensts

Unsere Beispiel-App verwendet Azure OpenAI, um die Abfrage des App-Benutzers zu analysieren und dann eine Anfrage an Elasticsearch zu senden, indem sie die Suchvorlage ausfüllt, um zu versuchen, flexibel mitzuteilen, wonach der Benutzer sucht.

1. Öffnen Sie einen neuen Browser-Tab und gehen Sie im Azure-Portal zu AI Foundry | Azure OpenAI . Klicken Sie auf +Erstellen

2. Wählen Sie im Erstellungsformular eine Ressourcengruppe aus.

3. Geben Sie einen Namenein

4. Wählen Sie eine Preisstufe

5. Klicken Sie auf Weiter

6. Klicken Sie auf der Registerkarte „Netzwerk“ auf „Weiter“

7. Klicken Sie auf der Registerkarte Tags auf Weiter

8. Klicken Sie auf der Registerkarte „Überprüfen und senden“ auf „Erstellen“ .

9. Sobald die Erstellung abgeschlossen ist, klicken Sie auf „Zur Ressource gehen“.

10. Wählen Sie im linken Navigationsmenü „Schlüssel und Endpunkt“ aus.

11. Kopieren Sie den Endpunkt und fügen Sie ihn in die von Ihnen erstellte Datei appsettings.json in Ihrem Browser-Tab mit dem geöffneten Codespaces-Editor ein.

12. Kehren Sie dann zu Ihrem Browser-Tab zurück, der den Azure OpenAI -Schlüssel und die Endpunktseite enthält. Klicken Sie auf die Schaltfläche „Kopieren“ für Schlüssel 1 und fügen Sie den kopierten Wert in die Datei „appsettings.json“ ein, zurück in Ihrem Browser-Tab, in dem der Codespaces-Editor geöffnet ist.

Fügen Sie dem Azure Open AI-Dienst die Bereitstellung des GPT-4O-Modells hinzu

Großartig, wir haben jetzt einen laufenden Azure OpenAI-Dienst, aber es ist noch eine Modellbereitstellung erforderlich, um uns die LLM-Funktionen bereitzustellen, die unsere Beispiel-App benötigt. Es stehen unzählige Modelle zur Auswahl. Lassen Sie uns gpt-4o bereitstellen, da es bereits in der von Ihnen erstellten Datei appsettings.json angegeben ist.

1. Gehen Sie zu Azure AI Foundry und klicken Sie auf „Bereitstellung erstellen“

2. Suchen Sie nach gpt-4o und wählen Sie es aus den Ergebnissen aus

3. Klicken Sie auf „Bestätigen“ , um es auszuwählen

4. Klicken Sie auf „Bereitstellen“ , um das Modell bereitzustellen

Nachdem Sie das gpt-4o- Modell erfolgreich bereitgestellt haben, können Sie im linken Navigationsmenü „ Bereitstellungen “ auswählen und bestätigen, dass die gpt-4o- Bereitstellung mit dem Status „Erfolgreich“ aufgeführt ist.

Erstellen eines Azure Maps-Kontos

Wir möchten, dass die Nutzer unserer Beispiel-App in bestimmten Gebieten nach Immobilien suchen können, ohne dabei zu spezifisch sein zu müssen. Wenn jemand nach einem Grundstück in der Nähe des örtlichen Bauernmarkts suchen möchte, ist Azure Maps ein Dienst, mit dem das OpenAI LLM die Breiten- und Längengradkoordinaten für den Markt abrufen kann. Die Koordinaten können dann in die auf Suchvorlagen basierenden Anfragen aufgenommen werden, die für Benutzerabfragen, die bestimmte Standorte und geografische Entfernungen berücksichtigen, an Elasticsearch gesendet werden.

1. Klicken Sie in Azure Maps-Konten auf Erstellen

2. Auswählen einer Ressourcengruppe

3. Geben Sie einen Namenein

4. Stimmen Sie der Lizenz- und Datenschutzerklärung zu

5. Klicken Sie auf „Überprüfen und erstellen“

6. Klicken Sie auf Erstellen

7. Sobald die Kontoerstellung abgeschlossen ist, klicken Sie auf „Zur Ressource gehen“.

8. Klicken Sie im linken Navigationsmenü auf „Authentifizierung“

9. Kopieren Sie den Primärschlüsselwert und fügen Sie ihn als Wert des API-Schlüssels im Abschnitt „AzureMapsSettings“ der Datei „appsettings.json“ ein, zurück auf der Registerkarte Ihres Browsers mit dem Codespaces-Editor.

Probieren Sie die Beispiel-App aus

Jetzt kommt der spaßige Teil. Es ist Zeit, die Beispiel-App auszuführen. Wir verfügen über alle Konfigurationsdetails sowie die Elastic Cloud- und Azure Cloud-Ressourcen, die wir zum Betrieb der App benötigen.

1. Öffnen Sie ein Terminalfenster im Codespaces-Editor.

2. Verwenden Sie den folgenden Befehl, um das aktive Verzeichnis in den Beispiel-App-Ordner zu ändern.

3. Verwenden Sie den folgenden Dotnet -Befehl, um die App auszuführen.

4. Klicken Sie auf die Schaltfläche „Im Browser öffnen“,wenn sie angezeigt wird.

5. Testen Sie die Standardsuche und probieren Sie dann einige Ihrer eigenen benutzerdefinierten Suchen aus. Wenn Sie weitere Details dazu sehen möchten, was im Backend zur Generierung der Suchergebnisse ausgeführt wird, können Sie auf den Link „Anzeigen“neben „Toolaufrufe“ klicken.

Bonus: Wenn Sie GPT-4o wirklich testen möchten, versuchen Sie die folgende Suche: Ich suche nach einer Immobilie in der Nähe von Disney World, Florida, mit über 30 Schlafzimmern und über 20 Badezimmern, einem Pool und einer Garage und in Strandnähe für weniger als 200.000. Diese Abfrage gibt nach mehreren Aufrufen des Suchtools Ergebnisse zurück.

Elastic ist Ihre Lösung für Search AI

Die laufende App ist ein Beispiel für die geführte Suche von Gen AI LLM unter Verwendung von Elasticsearch über Suchvorlagen als grundlegende Datenquelle. Experimentieren Sie ruhig und passen Sie die Beispiel-App an, um ein präzises und dennoch flexibles Sucherlebnis zu schaffen, das Ihren Benutzern hilft, das zu finden, wonach sie suchen.

Vielen Dank fürs Lesen. Probieren Sie Elastic Cloud aus.

Was ist das Model Context Protocol (MCP)?

Für diejenigen, die es nicht kennen: Model Context Protocol ist ein offener Standard, der eine strukturierte, bidirektionale Möglichkeit bietet, KI-Modelle mit verschiedenen Datenquellen und Tools zu verbinden, sodass sie relevantere und fundiertere Antworten generieren können. Er wird allgemein als „ USB-C-Anschluss für KI-Anwendungen“ bezeichnet.

Hier ist ein Architekturdiagramm, das seine bidirektionale Natur hervorhebt:

Dies stellt für KI-Praktiker eine bedeutende Veränderung dar, da eine der größten Herausforderungen bei der Skalierung von KI-Anwendungen darin besteht, für jede neue Datenquelle benutzerdefinierte Integrationen erstellen zu müssen. MCP bietet eine nachhaltige, wiederverwendbare Architektur zum Verwalten und Bereitstellen von Kontext für Modelle. Es ist modellunabhängig, serverunabhängig und vollständig Open Source.

MCP ist die neueste Version einer Reihe von API-Spezifikationen, die die Integration zwischen Anwendungen standardisieren sollen. In der Vergangenheit hatten wir OpenAPI für RESTful-Dienste, GraphQL für Datenabfragen und gRPC für die Mikrodienstkommunikation. MCP teilt nicht nur die strukturierte Genauigkeit dieser älteren Spezifikationen, sondern bringt sie auch in eine generative KI-Umgebung ein, wodurch es einfacher wird, Agenten ohne benutzerdefinierte Konnektoren in verschiedene Systeme einzubinden. In vielerlei Hinsicht zielt MCP darauf ab, für KI-Agenten das zu tun, was HTTP für das Web getan hat. So wie HTTP die Kommunikation zwischen Browsern und Websites standardisiert, versucht MCP, die Art und Weise zu standardisieren, wie KI-Agenten mit der sie umgebenden Datenwelt interagieren.

MCP im Vergleich zu anderen Agentenprotokollen

Die Landschaft der Agentenprotokolle wächst rasant, und über ein Dutzend neuer Standards konkurrieren darum, die Interaktion der Agenten zu definieren. Laurie Voss von LlamaIndex beschreibt, dass die meisten in zwei Typen eingeteilt werden können: Inter-Agent-Protokolle, bei denen der Schwerpunkt auf der Kommunikation der Agenten untereinander liegt, und kontextorientierte Protokolle wie MCP, bei denen der Schwerpunkt auf der Bereitstellung eines strukturierten Kontexts für LLMs liegt.

Andere beliebte Protokolle wie A2A (Agent to Agent) von Google, ACP (Agent Communication Protocol) von Cisco und IBM sowie Agora zielen darauf ab, Verhandlungen zwischen Agenten, den Aufbau von Koalitionen und sogar dezentrale Identitätssysteme zu ermöglichen. MCP verfolgt dabei einen etwas pragmatischeren Ansatz, da es sich darauf konzentriert, wie Agenten auf Tools und Daten zugreifen und nicht unbedingt darauf, wie sie miteinander kommunizieren (obwohl MCP dies in Zukunft auch auf andere Weise ermöglichen könnte).

Was MCP derzeit auszeichnet, ist seine Zugkraft und Dynamik. Wie React in den Anfängen der Frontend-Frameworks begann MCP mit einem Nischenproblem und ist heute in der Praxis eines der am häufigsten verwendeten und erweiterbarsten Agentenprotokolle.

Gipfel-Rückblick: Neue Prioritäten für MCP

Auf dem Gipfel sprachen Redner von Mitwirkenden bei Anthropic, Okta, OpenAI, AWS, GitHub und vielen anderen. Die Gespräche reichten von Verbesserungen des Kernprotokolls bis hin zu Implementierungen in der realen Welt und skizzierten sowohl unmittelbare als auch langfristige Prioritäten. Diese Gespräche spiegelten eine Abkehr von frühen Experimenten und einfachen Tool-Aufrufen hin zum Aufbau vertrauenswürdiger, skalierbarer und modularer KI-Systeme auf der Grundlage von MCP wider.

Mehrere Redner deuteten eine Zukunft an, in der MCP mehr als nur eine Protokoll-Infrastruktur ist und die Grundlage eines KI-nativen Webs werden kann. So wie JavaScript es Benutzern ermöglicht, auf Webseiten zu klicken und mit ihnen zu interagieren, könnte MCP es Agenten ermöglichen, dieselben Aktionen in unserem Namen auszuführen. Im E-Commerce beispielsweise könnten Benutzer, anstatt manuell zu einer Website zu navigieren, um einzukaufen, einfach einen Agenten anweisen, sich anzumelden, ein bestimmtes Produkt zu suchen, es in den Einkaufswagen zu legen und zur Kasse zu gehen.

Und das ist nicht bloß reine Spekulation und Hype; PayPal hat auf dem Gipfel sein neues Agenten-Toolkit und seinen MCP-Server vorgestellt, die genau dieses Agenten-Commerce-Erlebnis ermöglichen. Da MCP einen sicheren und zuverlässigen Zugriff auf Tools und Datenquellen bietet, können Agenten das Web nicht nur lesen, sondern auch darauf reagieren. MCP ist heute bereits ein leistungsstarker Standard mit großer Dynamik und könnte sich in Zukunft zum Standard für KI-gestützte Benutzerinteraktionen im gesamten Web entwickeln.

MCP-Projekt-Updates: Transport, Erhebung und strukturierte Werkzeuge

Jerome Swannack, ein Hauptbeitragender zu MCP, hat einige Aktualisierungen der Protokollspezifikation der letzten 6 Monate mitgeteilt. Die Hauptziele dieser Änderungen sind:

1. So aktivieren Sie Remote-MCP durch Hinzufügen von Streamable HTTP

2. Um umfangreichere Agenteninteraktionsmodelle durch die Ergänzung von Elicitation- und Tool-Output-Schemata zu ermöglichen

Da MCP Open Source ist, stehen Änderungen wie Streamable HTTP den Entwicklern bereits zur Implementierung zur Verfügung. Die Schemata zur Ermittlung und Tool-Ausgabe sind derzeit noch nicht veröffentlicht. Sie befinden sich im Entwurfsstadium und können sich weiterentwickeln.

Streamable HTTP (veröffentlicht am 26.03.2025): Ein wirkungsvolles technisches Update war die Einführung von Streamable HTTP als neuer Transportmechanismus. Dadurch werden serverseitig gesendete Ereignisse (SSE) durch ein skalierbareres, bidirektionales Modell ersetzt, das Chunked-Transfer-Encoding und progressive Nachrichtenübermittlung über eine einzelne HTTP-Verbindung unterstützt. Dadurch können Sie MCP-Server auf Cloud-Infrastrukturen wie AWS Lambda bereitstellen und Unternehmensnetzwerkbeschränkungen ohne langlebige Verbindungen oder die Notwendigkeit von Polling unterstützen.

Elicitation (veröffentlicht am 18.06.2025): Elicitation ermöglicht es Servern, ein Schema für die gewünschte Kontextstruktur eines Clients zu definieren. Im Wesentlichen kann der Server beschreiben, was er benötigt und welche Art von Eingabe er erwartet. Dies hat einige Auswirkungen: Server-Builder können komplexere Agenteninteraktionen erstellen. Client-Builder können dynamische Benutzeroberflächen implementieren, die sich an diese Schemata anpassen. Die Erhebung von Daten sollte jedoch nicht dazu verwendet werden, vertrauliche oder persönlich identifizierbare Informationen von Benutzern zu erhalten. Entwickler sollten bewährte Methoden befolgen, um sicherzustellen, dass die Abfrageaufforderungen sicher und angemessen bleiben, insbesondere wenn MCP weiterentwickelt wird. Dies hängt mit allgemeineren Sicherheitsbedenken zusammen, die wir später in diesem Beitrag erörtern werden.

Tool-Ausgabeschemata (veröffentlicht am 18.06.2025): Dieses Konzept ermöglicht es dem Client und dem LLM, die Formen der Tool-Ausgabe im Voraus zu kennen. Mithilfe von Tool-Ausgabeschemata können Entwickler beschreiben, was ein Tool voraussichtlich zurückgeben wird. Diese Schemata beheben eine der Haupteinschränkungen des direkten Toolaufrufs, nämlich die ineffiziente Verwendung des Kontextfensters. Das Kontextfenster gilt als eine der wichtigsten Ressourcen bei der Arbeit mit LLMs. Wenn Sie ein Tool direkt aufrufen, gibt es Rohinhalte zurück, die vollständig in den Kontext des LLMs verschoben werden. Mithilfe von Tool-Ausgabeschemata können Sie Ihre Token und das Kontextfenster besser nutzen, indem Sie dem MCP-Server die Bereitstellung strukturierter Daten ermöglichen. Hier sind einige Best Practices zu Tools im Allgemeinen.

Zusammen werden diese neuen Updates und zukünftigen Ergänzungen dazu beitragen, dass MCP zu einem modulareren, typisierteren und produktionsbereiteren Agentenprotokoll wird.

Untergenutzte Power-Funktionen: Sampling und Wurzeln

Obwohl die MCP-Spezifikation nichts Neues ist, wurden in der Keynote sowohl Sampling als auch Roots hervorgehoben. Diese beiden Grundelemente werden derzeit übersehen und sind noch nicht ausreichend erforscht, können jedoch erheblich zu umfassenderen und sichereren Interaktionen zwischen Agenten beitragen.

Sampling – Server können Vervollständigungen vom Client anfordern: Durch Sampling können MCP-Server Vervollständigungen vom clientseitigen LLM anfordern. Dies trägt zur bidirektionalen Natur des Protokolls bei, bei dem der Server nicht nur auf Anfragen antwortet, sondern das Modell des Clients auffordern und bitten kann, eine Antwort zu generieren. Dadurch behält der Kunde die volle Kontrolle über die Kosten, die Sicherheit und das vom MCP-Server verwendete Modell. Wenn Sie also einen externen MCP-Server mit einem vorkonfigurierten Modell verwenden, müssen Sie weder Ihre eigenen API-Schlüssel angeben noch Ihr eigenes Abonnement für dieses Modell konfigurieren, da der Server einfach das bereits mit dem Client verbundene Modell aufrufen kann. Dies ermöglicht komplexere und interaktivere Agentenverhalten.

Roots – eingeschränkter Zugriff auf Ressourcen: Roots wurden entwickelt, um Clients die Möglichkeit zu bieten, Server über relevante Ressourcen und Arbeitsbereiche zu informieren, auf die sie sich konzentrieren sollen. Dies ist leistungsstark, um den Umfang festzulegen, in dem Server arbeiten. Es ist wichtig zu beachten, dass Roots „ informativ und nicht strikt erzwingend“ sind, d. h., sie definieren keine Berechtigungen oder Berechtigungen für MCP-Server oder -Agenten. Mit anderen Worten: Sie können sich nicht allein auf Roots verlassen, um einen Server oder Agenten daran zu hindern, bestimmte Tools auszuführen oder Schreibaktionen durchzuführen. Bei Roots sollten Berechtigungen weiterhin clientseitig mit Mechanismen für Benutzergenehmigungen gehandhabt werden. Darüber hinaus sollten Entwickler weiterhin darauf achten, Server zu verwenden, die so konzipiert sind, dass sie die von den Roots gesetzten Grenzen respektieren und bewährte Methoden verwenden.

Authentifizierung für Agenten: OAuth 2.1 und geschützte Metadaten

Dieser Abschnitt konzentriert sich auf OAuth 2.1, die neueste Version von OAuth 2.0, die unsichere Abläufe beseitigt und bewährte Methoden konsolidiert.

Die OAuth-Unterstützung war ein mit Spannung erwartetes Thema, insbesondere da Sicherheit und Skalierbarkeit als die größten Hindernisse gelten, die verhindern, dass MCP zum Standard für die Verbindung von Agenten mit Tools wird. Aaron Parecki (OAuth 2.1-Redakteur und Experte für Identitätsstandards bei Okta) erläuterte, wie MCP einen sauberen, skalierbaren OAuth-Flow übernehmen kann, der den Serverentwicklern den Großteil der Komplexität abnimmt. Die offizielle Autorisierungsspezifikation OAuth 2.1 wurde kürzlich am 18.06.2025 in der neuesten Protokollrevision veröffentlicht.

In dieser Implementierung können die OAuth-Verantwortlichkeiten zwischen dem MCP-Client und dem Server aufgeteilt werden. Der Großteil des Authentifizierungsflusses wird vom MCP-Client initiiert und verarbeitet. Der Server ist nur am Ende beteiligt, um das sichere Token zu empfangen und zu überprüfen. Diese Aufteilung hilft bei der Lösung eines kritischen Skalierungsproblems bei der Authentifizierung über viele Tools hinweg, ohne dass Entwickler jede einzelne Verbindung konfigurieren müssen, und stellt sicher, dass MCP-Serverentwickler keine OAuth-Experten werden müssen.

Zwei wichtige Highlights aus dem Vortrag:

1. Metadaten geschützter Ressourcen: MCP-Server können eine JSON-Datei veröffentlichen, die ihren Zweck, ihre Endpunkte und ihre Authentifizierungsmethoden beschreibt. Dadurch können Clients OAuth-Flows nur mit der Server-URL starten, was den Verbindungsprozess vereinfacht. Mehr erfahren: OAuth in MCP reparieren

2. Unterstützung für IDPs und SSO: Unternehmen können Identitätsanbieter integrieren, um den Zugriff zentral zu verwalten. Dies ist sowohl für das Benutzererlebnis als auch für die Sicherheit ein Gewinn. Benutzer müssten nicht durch zehn verschiedene Zustimmungsbildschirme klicken und Sicherheitsteams könnten jede Verbindung beobachten.

Indem die OAuth-Logik an den Client übertragen wird und auf Metadaten von Servern zurückgegriffen wird, vermeidet das MCP-Ökosystem einen großen Engpass. Dadurch wird MCP besser an die Art und Weise angepasst, wie moderne APIs in heutigen Produktionsumgebungen gesichert werden.

Zusätzliche Lektüre: OAuth 2 Simplified.

Sicherheitsherausforderungen in einem zusammensetzbaren Ökosystem

Neue Entwicklungen bringen auch neue Angriffsflächen mit sich. Arjun Sambamoorthy von Cisco listet mehrere wichtige Bedrohungen in der MCP-Landschaft auf, darunter:

Bedrohung

Beschreibung

Abhilfemaßnahmen und bewährte Methoden

Sofortige Injektion & Werkzeugvergiftung

Eine Möglichkeit, eine bösartige Eingabeaufforderung in den LLM-Systemkontext oder die Toolbeschreibung einzufügen, wodurch das LLM unbeabsichtigte Aktionen wie das Lesen von Dateien oder das Durchsickern von Daten ausführt.

Verwenden Sie Tools wie MCP Scan, um Überprüfungen der Tool-Metadaten durchzuführen. Überprüfen Sie Beschreibungen und Parameter, bevor Sie sie in Eingabeaufforderungen aufnehmen. Erwägen Sie abschließend die Implementierung von Benutzergenehmigungen für Hochrisikotools. Weitere Einzelheiten finden Sie im OWASP Prompt Injection-Handbuch in der zusätzlichen Leseliste unter der Tabelle.

Sampling-Angriffe

Im Kontext von MCP öffnet das Sampling dem MCP-Server die Tür für sofortige Injektionsangriffe auf das LLM.

Deaktivieren Sie die Stichprobenentnahme für nicht vertrauenswürdige Server und ziehen Sie in Erwägung, menschliche Genehmigungen für Stichprobenanfragen hinzuzufügen.

Bösartige MCP-Server

Bei den aktuellen Sammlungen von MCP-Servern ist es schwierig, jeden einzelnen zu überprüfen, um die Sicherheit zu gewährleisten. Betrügerische Server können Ihre Daten unbemerkt sammeln und böswilligen Akteuren preisgeben.

Stellen Sie nur Verbindungen zu MCP-Servern aus vertrauenswürdigen Registern oder internen Listen her. Führen Sie Server von Drittanbietern in Containern mit Sandboxing aus.

Schädliche MCP-Installationstools

Befehlszeileninstallationsprogramme und -skripte sind praktisch, um MCP-Server oder -Tools schnell zu implementieren, aber Sie könnten am Ende ungeprüften, kompromittierten Code installieren.

Installieren Sie es in Sandbox-Umgebungen und validieren Sie Paketsignaturen. Führen Sie niemals automatische Updates aus nicht verifizierten Quellen durch.

Um dem noch weiter entgegenzuwirken, schlägt Arjun ein vertrauenswürdiges MCP-Register vor, das alle Überprüfungen übernimmt (ein Thema, das im Mittelpunkt stand – weitere Einzelheiten finden Sie in den ersten beiden Punkten der Leseliste unten) und außerdem die Verwendung dieser Sicherheitscheckliste.

Weiterführende Literatur:

• Offizielle Best Practices für MCP-Sicherheit

• OWASP LLM-Bewerbung Top 10

• HiddenLayer-Bedrohungsforschung

• MCP-Scan

• OWASP Prompt Injection-Leitfaden

Was kommt als Nächstes: Register, Governance und Ökosystem

Ein zentrales MCP-Register ist in der Entwicklung und war eines der am häufigsten diskutierten Themen auf dem Gipfel. Das aktuelle Server-Ökosystem leidet unter Fragmentierung, geringem Vertrauen und mangelnder Auffindbarkeit. Für Entwickler ist es schwierig, MCP-Server zu finden, ihre Funktion zu überprüfen und sie sicher zu installieren, insbesondere in einem dezentralen Ökosystem, in dem Metadaten unvollständig oder gefälscht sein können.

Ein zentrales Register behebt diese Schwachstellen direkt, indem es als vertrauenswürdige Quelle der Wahrheit fungiert, die Auffindbarkeit verbessert, die Integrität der Servermetadaten sicherstellt und das Risiko der Installation bösartiger Tools verringert.

Die Ziele des MCP-Registers sind:

• Bereitstellung einer einzigen zuverlässigen Quelle für Servermetadaten (was ein Server tut, wie er authentifiziert, installiert und aufgerufen wird)

• Beseitigung unvollständiger Registrierungen von Drittanbietern und Fragmentierung, sodass ein Server bei der Registrierung nicht jede einzelne andere Registrierung im Internet aktualisieren muss.

• Bereitstellung eines Serverregistrierungsflusses, der ein CLI-Tool und eine server.json-Datei umfasst, die die zuvor erwähnten Metadaten enthält.

Die allgemeinere Hoffnung besteht darin, dass ein vertrauenswürdiges Register dabei hilft, das Ökosystem sicher zu skalieren und es Entwicklern ermöglicht, neue Tools selbstbewusst zu erstellen und zu teilen.

Ein weiteres wichtiges Thema für Anthropic war die Regierungsführung. Sie machten deutlich, dass MCP offen und von der Community gesteuert bleiben sollte, die Skalierung dieses Governance-Modells jedoch noch in Arbeit ist. Sie suchen derzeit in diesem Bereich nach Unterstützung und bitten jeden, der Erfahrung mit der Governance in Open-Source-Protokollen hat, sich zu melden. Dies führt zu dem anderen Thema, das ich erwähnen wollte. Während der gesamten Veranstaltung betonten die Redner, dass das Ökosystem nur durch die Beiträge der Entwickler wachsen kann. Es bedarf konzentrierter Anstrengungen, um MCP zum neuen Webstandard zu machen und es von den anderen gängigen Agentenprotokollen abzuheben.

MCP in der Praxis: Fallstudien und Demos

Mehrere Organisationen berichteten, wie MCP bereits in praktischen Anwendungen eingesetzt wird:

• PayPal – MCP-Server für Agentic Commerce: PayPal stellte sein neues Agent-Toolkit und seinen MCP-Server vor, die das Einkaufserlebnis eines Benutzers grundlegend verändern können. Anstatt soziale Medien nach Artikeln zu durchsuchen, Preise zu vergleichen und zur Kasse zu gehen, können Benutzer mit einem Agenten chatten, der eine Verbindung zum PayPal-MCP-Server herstellt und alle diese Aktionen abwickelt.

• EpicAI.pro – Jarvis: Die Entwicklungen in MCP bringen uns einem echten Assistenten vom Typ Jarvis immer näher. Für diejenigen, die die Iron Man-Filme nicht kennen: Jarvis ist ein KI-Assistent, der natürliche Sprache verwendet, auf multimodale Eingaben reagiert, beim Antworten keine Latenz aufweist, die Bedürfnisse des Benutzers proaktiv antizipiert, Integrationen automatisch verwaltet und zwischen Geräten und Standorten im Kontext wechseln kann. Wenn wir uns Jarvis als physischen Roboterassistenten vorstellen, verleiht MCP Jarvis „Hände“ oder die Fähigkeit, komplexe Aufgaben zu bewältigen.

• Postman – MCP-Server-Generator: Bietet eine Warenkorb-Erfahrung für API-Anfragen, bei der Sie verschiedene API-Anfragen auswählen, in einen Korb legen und den gesamten Korb als MCP-Server herunterladen können.

• Bloomberg – Bloomberg hat einen wichtigen Engpass bei der GenAI-Entwicklung für Unternehmen gelöst. Mit fast 10.000 Ingenieuren benötigten sie eine standardisierte Möglichkeit, Tools und Agenten teamübergreifend zu integrieren. Mit MCP haben sie ihre internen Tools in modulare Remote-First-Komponenten umgewandelt, die Agenten problemlos über eine einheitliche Schnittstelle aufrufen können. Dadurch konnten ihre Ingenieure Tools für die gesamte Organisation bereitstellen, während sich die KI-Teams auf die Erstellung von Agenten statt auf benutzerdefinierte Integrationen konzentrierten. Bloomberg unterstützt jetzt skalierbare, sichere Agenten-Workflows, die die vollständige Interoperabilität mit dem MCP-Ökosystem ermöglichen. Bloomberg hat keine öffentlichen Quellen verlinkt, aber dies ist, was sie auf dem Gipfel öffentlich präsentiert haben.

• Block – Block verwendet MCP, um Goose zu betreiben, einen internen KI-Agenten, der es Mitarbeitern ermöglicht, Aufgaben in den Bereichen Technik, Vertrieb, Marketing und mehr zu automatisieren. Sie haben über 60 MCP-Server für Tools wie Git, Snowflake, Jira und Google Workspace erstellt, um die Interaktion in natürlicher Sprache mit den Systemen zu ermöglichen, die sie täglich verwenden. Die Mitarbeiter von Block verwenden Goose jetzt, um Daten abzufragen, Betrug zu erkennen, Vorfälle zu verwalten, interne Prozesse zu steuern und vieles mehr – und das alles, ohne Code schreiben zu müssen. MCP hat Block dabei geholfen, die Einführung von KI in vielen Berufsfunktionen in nur zwei Monaten zu skalieren.

• AWS – AWS MCP-Server: AWS hat einen unterhaltsamen MCP-Server mit Dungeons-and-Dragons-Thema vorgestellt, der das Würfeln simuliert, vergangene Würfe verfolgt und Ergebnisse über Streamable HTTP zurückgibt. Dieses einfache Beispiel verdeutlicht, wie einfach es ist, MCP-Server mit AWS-Tools und -Infrastrukturen wie Lambda und Fargate zu erstellen und bereitzustellen. Sie stellten außerdem Strands SDK vor, ein Open-Source-Toolkit zum Erstellen multimodaler Agenten, die mit MCP-Servern interagieren.

MCP-Unterstützung im Elastic Agent Builder

Sie können noch heute mit MCP experimentieren und dabei den Elastic Agent Builder verwenden. Dies ist die einfachste Möglichkeit, Agenten direkt auf Basis Ihrer Daten zu erstellen. Mit Agent Builder können Sie Elasticsearch-basierte Tools für MCP-kompatible Agenten bereitstellen. Es enthält bereits einige leistungsstarke integrierte Tools, darunter:

• platform.core.search - Führt Suchvorgänge unter Verwendung der vollständigen Elasticsearch Query DSL aus.

• platform.core.list_indices - Listet alle verfügbaren Indizes in Elasticsearch auf (hilft Agenten, die vorhandenen Daten zu ermitteln)

• platform.core.get_index_mapping - Ruft Feldzuordnungen für einen bestimmten Index ab (hilft Agenten, die Struktur und die Typen Ihrer Daten zu verstehen)

• platform.core.get_document_by_id - Ruft ein bestimmtes Dokument anhand seiner ID ab (für präzisen Abruf)

Mit diesen Tools allein können Sie Ihren Agenten mit Such- und Relevanzfunktionen auf Unternehmensebene ausstatten, was für die Entwicklung zuverlässiger KI-Agenten unerlässlich ist.

Was Agent Builder noch leistungsfähiger macht, ist die Möglichkeit, eigene, auf die Bedürfnisse Ihrer Anwendung zugeschnittene Tools zu definieren und bereitzustellen. Dies ist besonders nützlich für vordefinierte oder wiederholbare Arbeitsabläufe, bei denen der Agent eine bestimmte Art von Suche in einem bestimmten Index durchführen soll, ohne dass diese Logik jedes Mal neu ermittelt werden muss. Anstatt Tokens für Planung und Schlussfolgerung auszugeben, um zum selben Ergebnis zu gelangen, können Sie diese Absicht direkt in ein Tool einprogrammieren, wodurch Ihre Agenten schneller, zuverlässiger und kosteneffizienter werden.

Innerhalb der Agent Builder-Benutzeroberfläche finden Sie hier ein Beispiel für eine benutzerdefinierte Tool-Definition, die ES|QL verwendet:

Sobald Sie Ihre benutzerdefinierten Tools definiert haben, können Sie diese (sowie die integrierten nativen Tools) mithilfe von MCP verfügbar machen, indem Sie auf das Dropdown-Menü für Manage MCP klicken und die MCP-Server-URL kopieren.

Sie können diesen MCP-Endpunkt nun in jeden Client importieren, der MCP verwendet, um ihn mit Agent Builder zu verbinden und ihm Zugriff auf alle verfügbaren Tools zu gewähren. Weitere Informationen finden Sie in dieser Einführung zu Agent Builder.

Fazit

Der MCP Dev Summit machte deutlich, dass MCP die Art und Weise prägt, wie diese KI-Agenten miteinander und mit der sie umgebenden Datenwelt interagieren. Unabhängig davon, ob Sie einen Agenten mit Unternehmensdaten verbinden oder vollständig autonome Agenten entwerfen, bietet MCP eine standardisierte, zusammensetzbare Möglichkeit zur Integration, die im großen Maßstab schnell nützlich wird. Von Transportprotokollen und Sicherheitsmustern bis hin zu Registern und Governance reift das MCP-Ökosystem schnell. MCP wird weiterhin offen und von der Community gesteuert sein, sodass Entwickler heute die Möglichkeit haben, seine Entwicklung mitzugestalten.

Was ist Spring AI?

Spring AI 1.0, eine umfassende Lösung für KI-Engineering in Java, ist nach einer langen Entwicklungsphase, die von rasanten Fortschritten im Bereich der KI geprägt war, nun verfügbar. Die Version enthält zahlreiche wichtige neue Funktionen für KI-Ingenieure.

Java und Spring sind bestens positioniert, um auf diesen KI-Zug aufzuspringen. Unzählige Unternehmen setzen auf Spring Boot, um ihre Systeme zu betreiben. Dadurch ist es extrem einfach, KI in ihre bestehenden Prozesse zu integrieren. Sie können Ihre Geschäftslogik und Daten im Prinzip ohne großen Aufwand direkt mit diesen KI-Modellen verknüpfen.

Spring AI bietet Unterstützung für verschiedene KI-Modelle und -Technologien, wie zum Beispiel:

• Bildmodelle: Generieren von Bildern anhand von Textvorgaben.

• Transkriptionsmodelle: Sie nehmen Audioquellen und wandeln sie in Text um.

• Einbettungsmodelle: Beliebige Daten werden in Vektoren umgewandelt, die für die semantische Ähnlichkeitssuche optimiert sind.

• Chat-Modelle: dieseSollte bekannt sein! Sie haben zweifellos schon einmal ein kurzes Gespräch mit einem geführt.

Chatmodelle stehen im Bereich der KI derzeit im Mittelpunkt des Interesses, und das völlig zu Recht – sie sind fantastisch! Sie können sie bitten, Ihnen bei der Korrektur eines Dokuments zu helfen oder ein Gedicht zu schreiben. (Bitten Sie sie nur noch nicht, einen Witz zu erzählen.) Sie sind großartig, aber sie haben auch einige Schwächen.

Spring AI-Lösungen für KI-Herausforderungen

Lassen Sie uns einige dieser Probleme und ihre Lösungen in Spring AI durchgehen.

Problem

Lösung

Konsistenz

Chat-Models sind aufgeschlossen und lassen sich leicht ablenken.

Sie können ihnen eine Systemvorgabe geben, um ihre Gesamtform und Struktur zu steuern.

Erinnerung

KI-Modelle haben kein Gedächtnis, daher können sie keine Nachrichten von verschiedenen Nutzern miteinander verknüpfen.

Sie können ihnen ein Speichersystem zur Verfügung stellen, um die relevanten Teile des Gesprächs zu speichern.

Isolierung

KI-Modelle leben in isolierten kleinen Umgebungen, aber sie können wirklich Erstaunliches leisten, wenn man ihnen Zugriff auf Werkzeuge gibt – Funktionen, die sie bei Bedarf aufrufen können.

Spring AI unterstützt Tool Calling, wodurch Sie dem KI-Modell Tools in seiner Umgebung mitteilen können, die es dann aufrufen soll. Diese mehrstufige Interaktion wird vollständig transparent für Sie abgewickelt.

Private Daten

KI-Modelle sind intelligent, aber nicht allwissend! Sie wissen nicht, was sich in Ihren firmeneigenen Datenbanken befindet – und wir glauben auch nicht, dass Sie das möchten!

Sie müssen die Antworten der Nutzer durch das Einfügen von Eingabeaufforderungen beeinflussen – im Grunde genommen verwenden Sie den allmächtigen String-Verkettungsoperator, um Text in die Anfrage einzufügen, bevor das Modell die gestellte Frage analysiert. Hintergrundinformationen, wenn Sie möchten. Wie entscheidet man, was verschickt werden soll und was nicht? Verwenden Sie einen Vektorspeicher, um nur die relevanten Daten auszuwählen und diese weiterzuleiten. Dies wird als Retrieval Augmented Generation oder RAG bezeichnet.

Halluzination

KI-Chatmodelle unterhalten sich gerne! Und manchmal tun sie das so selbstsicher, dass sie sich Dinge ausdenken können.

Sie müssen eine Evaluierung durchführen – also ein Modell verwenden, um die Ausgabe eines anderen zu validieren –, um plausible Ergebnisse zu bestätigen.

Und natürlich ist keine KI-Anwendung eine Insel. Moderne KI-Systeme und -Dienste funktionieren heutzutage am besten, wenn sie mit anderen Systemen und Diensten integriert sind. Modellkontextprotokoll(MCP) ermöglicht es, Ihre KI-Anwendungen mit anderen MCP-basierten Diensten zu verbinden, unabhängig davon, in welcher Sprache sie geschrieben sind. All dies lässt sich in agentenbasierten Arbeitsabläufen zusammenfassen, die auf ein übergeordnetes Ziel hinarbeiten.

Das Beste daran? All dies gelingt Ihnen, indem Sie auf die vertrauten Idiome und Abstraktionen zurückgreifen, die jeder Spring Boot-Entwickler erwartet: Praktische Starter-Abhängigkeiten für praktisch alles sind auf Spring Initializrverfügbar.

Spring AI bietet komfortable Spring Boot-Autokonfigurationen, die Ihnen das von Ihnen bekannte und erwartete Konvention-vor-Konfigurations-Setup bieten. Und Spring AI unterstützt Observability mit Spring Boot's Actuator und dem Micrometer-Projekt. Es harmoniert auch hervorragend mit GraalVM und virtuellen Threads, sodass Sie superschnelle und effiziente KI-Anwendungen erstellen können, die skalierbar sind.

Warum Elasticsearch?

Elasticsearch ist eine Volltextsuchmaschine, das wissen Sie wahrscheinlich schon. Warum verwenden wir es also für dieses Projekt? Nun ja, es ist auch ein Vektorshop! Und zwar eine ziemlich gute, bei der die Daten direkt neben dem vollständigen Text stehen. Weitere bemerkenswerte Vorteile:

• Super einfach einzurichten

• Opensource

• Horizontal skalierbar

• Die meisten Freitextdaten Ihrer Organisation befinden sich wahrscheinlich bereits in einem Elasticsearch-Cluster.

• Vollständige Suchmaschinenfunktion

• Vollständig in Spring AI integriert!

Alles in allem erfüllt Elasticsearch alle Anforderungen an einen hervorragenden Vektorspeicher. Also lasst uns ihn einrichten und mit der Entwicklung unserer Anwendung beginnen!

Erste Schritte mit Elasticsearch

Wir benötigen sowohl Elasticsearch als auch Kibana, die Benutzeroberfläche, mit der Sie mit den in der Datenbank gespeicherten Daten interagieren werden.

Dank der praktischen Docker-Images und der Elastic.co-Homepage können Sie alles auf Ihrem lokalen Rechner ausprobieren. Gehe dorthin, scrolle nach unten, um den Befehl curl zu finden, führe ihn aus und leite ihn direkt in deine Shell weiter:

Dadurch werden einfach Docker-Images für Elasticsearch und Kibana heruntergeladen und konfiguriert, und nach wenigen Minuten sind sie auf Ihrem lokalen Rechner einsatzbereit, inklusive der Zugangsdaten.

Außerdem stehen Ihnen zwei verschiedene URLs zur Verfügung, über die Sie mit Ihrer Elasticsearch-Instanz interagieren können. Folgen Sie den Anweisungen und rufen Sie in Ihrem Browser http://localhost:5601 auf.

Beachten Sie auch den Benutzernamen elastic und das Passwort, die in der Konsole ausgegeben werden: Sie benötigen diese zum Anmelden (in der obigen Beispielausgabe sind dies elastic bzw. w1GB15uQ).

Die App zusammenführen

Rufen Sie die Spring Initializr- Seite auf und generieren Sie ein neues Spring AI-Projekt mit den folgenden Abhängigkeiten:

• Elasticsearch Vector Store

• Spring Boot Actuator

• GraalVM

• OpenAI

• Web

Achten Sie darauf, die neueste und beste Version von Java zu wählen (idealerweise Java 24 – zum Zeitpunkt der Erstellung dieses Dokuments – oder höher) und das Build-Tool Ihrer Wahl. In diesem Beispiel verwenden wir Apache Maven.

Klicken Sie auf Generate und entpacken Sie anschließend das Projekt und importieren Sie es in Ihre bevorzugte IDE. (Wir verwenden IntelliJ IDEA.)

Das Wichtigste zuerst: Legen wir die Verbindungsdetails für Ihre Spring Boot-Anwendung fest. Schreiben Sie in application.properties, Folgendes:

Wir werden außerdem die Vektorspeicherfunktion von Spring AI nutzen, um alle benötigten Datenstrukturen auf der Elasticsearch-Seite zu initialisieren. Geben Sie dazu Folgendes an:

In dieser Demo verwenden wir OpenAI , genauer gesagt das Embedding Model und das Chat Model (Sie können gerne den Dienst Ihrer Wahl verwenden, solange Spring AI ihn unterstützt).

Das Embedding-Modell wird benötigt, um Einbettungen der Daten zu erstellen, bevor wir sie in Elasticsearch speichern. Damit OpenAI funktioniert, müssen wir API key angeben:

Sie können sie als Umgebungsvariable wie SPRING_AI_OPENAI_API_KEY definieren, um zu vermeiden, dass die Anmeldeinformationen in Ihrem Quellcode gespeichert werden.

Wir werden Dateien hochladen. Stellen Sie daher sicher, dass Sie anpassen, wie viele Daten in den Servlet-Container hochgeladen werden können:

Wir haben es fast geschafft! Bevor wir uns ans Programmieren machen, werfen wir einen Blick darauf, wie das Ganze funktionieren wird.

Auf unserem Rechner haben wir die folgende Datei heruntergeladen (eine Liste der Regeln für ein Brettspiel), sie in test.pdf umbenannt und in ~/Downloads/test.pdf abgelegt.

Die Datei wird an den Endpunkt /rag/ingest gesendet (ersetzen Sie den Pfad entsprechend Ihrer lokalen Konfiguration):

Das könnte ein paar Sekunden dauern…

Im Hintergrund werden die Daten an OpenAI gesendet, das daraus Einbettungen erstellt; diese Daten werden dann in Elasticsearch geschrieben, sowohl die Vektoren als auch der Originaltext.

In diesen Daten und allen darin enthaltenen Einbettungen geschieht die Magie. Anschließend können wir Elasticsearch über die VectorStore -Schnittstelle abfragen.

Der vollständige Ablauf sieht folgendermaßen aus:

• Der HTTP-Client lädt Ihre ausgewählte PDF-Datei in die Spring-Anwendung hoch.

• Spring AI übernimmt die Textextraktion aus unserem PDF und unterteilt jede Seite in 800 Zeichen lange Abschnitte.

• OpenAI generiert die Vektordarstellung für jeden Chunk.

• Sowohl der segmentierte Text als auch die Einbettung werden anschließend in Elasticsearch gespeichert.

Zum Schluss stellen wir eine Anfrage:

Und wir erhalten eine relevante Antwort:

Toll! Wie funktioniert das alles?

• Der HTTP-Client übermittelt die Frage an die Spring-Anwendung.

• Spring AI erhält die Vektordarstellung der Frage von OpenAI.

• Durch diese Einbettung sucht es in den gespeicherten Elasticsearch-Chunks nach ähnlichen Dokumenten und ruft die ähnlichsten Dokumente ab.

• Spring AI sendet dann die Frage und den abgerufenen Kontext an OpenAI, um eine LLM-Antwort zu generieren.

• Schließlich gibt es die generierte Antwort und einen Verweis auf den abgerufenen Kontext zurück.

Lasst uns einen Blick in den Java-Code werfen, um zu sehen, wie er wirklich funktioniert.

Zunächst einmal zur Main- Klasse: Es handelt sich um eine standardmäßige Hauptklasse für jede beliebige Spring Boot-Anwendung.

Dort gibt es nichts zu sehen. Weiter geht’s…

Als nächstes ein einfacher HTTP-Controller:

Der Controller ruft lediglich einen von uns entwickelten Dienst auf, der Dateien aufnimmt und in den Elasticsearch-Vektorspeicher schreibt und anschließend Abfragen gegen denselben Vektorspeicher ermöglicht.

Schauen wir uns den Service an:

Dieser Code übernimmt die gesamte Datenaufnahme: Ausgehend von einem Spring Framework Resource, das ein Container um Bytes ist, lesen wir die PDF-Daten (vermutlich eine .PDF -Datei - stellen Sie sicher, dass Sie dies überprüfen, bevor Sie beliebige Eingaben akzeptieren!) mit Spring AIs PagePdfDocumentReader und tokenisieren sie dann mit Spring AIs TokenTextSplitter. Schließlich fügen wir die resultierenden List<Document>-Objekte der VectorStore -Implementierung ElasticsearchVectorStore hinzu.

Sie können dies mit Kibana bestätigen: Nachdem Sie eine Datei an den Endpunkt /rag/ingest gesendet haben, öffnen Sie Ihren Browser unter localhost:5601 und navigieren Sie im Seitenmenü auf der linken Seite zu Dev Tools. Dort können Sie Abfragen stellen, um mit den Daten in der Elasticsearch-Instanz zu interagieren.

Stellen Sie eine Anfrage wie diese:

Und nun zum spannenden Teil: Wie erhalten wir diese Daten wieder als Antwort auf Benutzeranfragen?

Hier ist ein erster Entwurf für die Implementierung der Abfrage in einer Methode namens directRag.

Der Code ist recht einfach, aber wir werden ihn in mehrere Schritte unterteilen:

1. Verwenden Sie VectorStore , um eine Ähnlichkeitssuche durchzuführen.

2. Ausgehend von allen Ergebnissen werden die zugrunde liegenden Spring AI Documents ermittelt und deren Text extrahiert, der anschließend zu einem einzigen Ergebnis zusammengefügt wird.

3. Sende die Ergebnisse von VectorStore an das Modell, zusammen mit einer Aufforderung, die dem Modell erklärt, was damit zu tun ist, und der Frage des Benutzers. Warten Sie die Antwort ab und senden Sie sie zurück.

Dies ist RAG – Retrieval Augmented Generation. Es geht um die Idee, dass wir Daten aus einem Vektorspeicher verwenden, um die vom Modell durchgeführte Verarbeitung und Analyse zu unterstützen. Jetzt, wo Sie wissen, wie es geht, hoffen wir, dass Sie es nie tun müssen! So jedenfalls nicht: Die Berater von Spring AI sind dazu da, diesen Prozess noch weiter zu vereinfachen.

Advisors ermöglicht die Vor- und Nachbearbeitung einer Anfrage an ein bestimmtes Modell und stellt darüber hinaus eine Abstraktionsschicht zwischen Ihrer Anwendung und dem Vektorspeicher bereit. Fügen Sie Ihrem Build die folgende Abhängigkeit hinzu:

Füge der Klasse eine weitere Methode namens advisedRag(String question) hinzu:

Die gesamte RAG-Musterlogik ist in QuestionAnswerAdvisor gekapselt. Alles andere ist genau so, wie jede andere Anfrage an ChatModel wäre! Hübsch!

Den vollständigen Code finden Sie auf GitHub.

Fazit

In dieser Demo verwendeten wir Docker-Images und führten alles auf unserem lokalen Rechner durch, das Ziel hier ist jedoch die Entwicklung produktionsreifer KI-Systeme und -Dienste. Es gibt verschiedene Möglichkeiten, dies zu verwirklichen.

Zunächst können Sie den Spring Boot Actuator hinzufügen, um den Tokenverbrauch zu überwachen. Tokens dienen als Stellvertreter für die Komplexität (und manchmal auch die Kosten in Dollar und Cent) einer bestimmten Anfrage an das Modell.

Der Spring Boot Actuator befindet sich bereits im Klassenpfad. Geben Sie daher einfach die folgenden Eigenschaften an, um alle Metriken anzuzeigen (die vom großartigen Projekt Micrometer.io erfasst werden):

Starten Sie Ihre Anwendung neu. Führe eine Abfrage durch und gehe dann zu: http://localhost:8080/actuator/metrics. Suchen Sie nach „ token“ und Sie erhalten Informationen über die von der Anwendung verwendeten Token. Behalten Sie das bitte im Auge. Sie können natürlich auch die Micrometer- Integration für Elasticsearch nutzen, um diese Metriken zu übertragen und Elasticsearch als Ihre bevorzugte Zeitreihendatenbank zu verwenden!

Man sollte dann bedenken, dass wir jedes Mal, wenn wir eine Anfrage an einen Datenspeicher wie Elasticsearch, an OpenAI oder an andere Netzwerkdienste stellen, E/A-Operationen durchführen und dass diese E/A-Operationen häufig die Threads blockieren, auf denen sie ausgeführt werden. Java 21 und spätere Versionen werden mit nicht-blockierenden virtuellen Threads ausgeliefert, die die Skalierbarkeit deutlich verbessern. Aktivieren Sie es mit:

Und schließlich sollten Sie Ihre Anwendung und Ihre Daten an einem Ort hosten, an dem sie optimal funktionieren und skalieren können. Sie haben sich sicher schon Gedanken darüber gemacht, wo Sie Ihre Anwendung ausführen möchten, aber wo werden Sie Ihre Daten hosten? Dürfen wir Ihnen die Elastic Cloud empfehlen? Es ist sicher, privat, skalierbar und voller Funktionen. Unser Lieblingsteil? Wenn Sie möchten, können Sie die Serverless-Edition wählen, bei der Elastic den Pager trägt, nicht Sie!

In diesem Blog geht es um das Ausführen und Anpassen der LangChain Retrieval Agent-Vorlage mit LangGraph Studio und LangGraph CLI. Die Vorlage bietet ein Framework zum Erstellen von Retrieval-Augmented Generation (RAG)-Anwendungen und nutzt verschiedene Retrieval-Backends wie Elasticsearch.

Wir führen Sie durch die Einrichtung, Konfiguration der Umgebung und effiziente Ausführung der Vorlage mit Elastic, während wir den Agentenfluss anpassen.

Voraussetzungen

Bevor Sie fortfahren, stellen Sie sicher, dass Folgendes installiert ist:

• Elasticsearch Cloud-Bereitstellung oder lokale Elasticsearch-Bereitstellung (oder erstellen Sie eine 14-tägige kostenlose Testversion auf Elastic Cloud) – Version 8.0.0 oder höher

• Python 3.9+

• Zugriff auf einen LLM-Anbieter wie Cohere (in diesem Handbuch verwendet), OpenAI oder Anthropic/Claude

Erstellen der LangGraph-App

1. Installieren Sie die LangGraph CLI

2. Erstellen Sie eine LangGraph-App aus der Retrieval-Agent-Vorlage

Ihnen wird ein interaktives Menü angezeigt, in dem Sie aus einer Liste verfügbarer Vorlagen auswählen können. Wählen Sie 4 für Retrieval Agent und 1 für Python, wie unten gezeigt:

• Fehlerbehebung: Wenn der Fehler „urllib.error.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1000)>“ auftritt, „

Führen Sie den Python-Befehl „Zertifikat installieren“ aus, um das Problem wie unten gezeigt zu beheben.

3. Abhängigkeiten installieren

Erstellen Sie im Stammverzeichnis Ihrer neuen LangGraph-App eine virtuelle Umgebung und installieren Sie die Abhängigkeiten im Modus edit , damit Ihre lokalen Änderungen vom Server verwendet werden:

Einrichten der Umgebung

1. Erstellen Sie eine .environment-Umgebung Datei

Die Datei .env enthält API-Schlüssel und Konfigurationen, damit die App eine Verbindung mit dem von Ihnen gewählten LLM- und Abrufanbieter herstellen kann. Generieren Sie eine neue .env -Datei, indem Sie die Beispielkonfiguration duplizieren:

2. Konfigurieren Sie die .env-Datei. Datei

Die Datei .env enthält eine Reihe von Standardkonfigurationen. Sie können es aktualisieren, indem Sie basierend auf Ihrem Setup die erforderlichen API-Schlüssel und -Werte hinzufügen. Alle Schlüssel, die für Ihren Anwendungsfall nicht relevant sind, können unverändert bleiben oder entfernt werden.

• Beispieldatei .env (unter Verwendung von Elastic Cloud und Cohere)

Nachfolgend finden Sie eine Beispielkonfiguration .env für die Verwendung von Elastic Cloud als Abrufanbieter und Cohere als LLM, wie in diesem Blog gezeigt:

Hinweis: In dieser Anleitung wird Cohere sowohl für die Antwortgenerierung als auch für die Einbettung verwendet. Sie können je nach Anwendungsfall jedoch auch andere LLM-Anbieter wie OpenAI,Claude oder sogar ein lokales LLM-Modell verwenden. Stellen Sie sicher, dass alle .env Schlüssel, die Sie verwenden möchten, in der Datei vorhanden und korrekt festgelegt sind.

3. Aktualisieren Sie die Konfigurationsdatei -configuration.py

Nachdem Sie Ihre .env -Datei mit den entsprechenden API-Schlüsseln eingerichtet haben, besteht der nächste Schritt darin, die Standardmodellkonfiguration Ihrer Anwendung zu aktualisieren. Durch die Aktualisierung der Konfiguration wird sichergestellt, dass das System die Dienste und Modelle verwendet, die Sie in Ihrer .env -Datei angegeben haben.

Navigieren Sie zur Konfigurationsdatei:

Die Datei configuration.py enthält die Standardmodelleinstellungen, die vom Abrufagenten für drei Hauptaufgaben verwendet werden:

• Einbettungsmodell – konvertiert Dokumente in Vektordarstellungen

• Abfragemodell – verarbeitet die Abfrage des Benutzers in einen Vektor

• Antwortmodell – generiert die endgültige Antwort

Standardmäßig verwendet der Code Modelle von OpenAI (z. B. openai/text-embedding-3-small) und Anthropic (z. anthropic/claude-3-5-sonnet-20240620 and anthropic/claude-3-haiku-20240307). In diesem Blog wechseln wir zur Verwendung von Cohere-Modellen. Wenn Sie bereits OpenAI oder Anthropic verwenden, sind keine Änderungen erforderlich.

Beispieländerungen (mit Cohere):

Öffnen Sie configuration.py und ändern Sie die Modellstandards wie unten gezeigt:

Ausführen des Abrufagenten mit der LangGraph-Befehlszeilenschnittstelle

1. Starten Sie den LangGraph-Server

Dadurch wird der LangGraph-API-Server lokal gestartet. Wenn dies erfolgreich ausgeführt wird, sollten Sie etwa Folgendes sehen:

Öffnen Sie die URL der Studio-Benutzeroberfläche.

Es stehen zwei Diagramme zur Verfügung:

• Retrieval-Graph: Ruft Daten aus Elasticsearch ab und beantwortet die Anfrage mithilfe eines LLM.

• Indexer-Graph: Indiziert Dokumente in Elasticsearch und generiert Einbettungen mithilfe eines LLM.

2. Konfigurieren des Indexergraphen

• Öffnen Sie den Indexergraphen.

• Klicken Sie auf „Assistenten verwalten“.

  • Klicken Sie auf „Neuen Assistenten hinzufügen“, geben Sie die Benutzerdaten wie angegeben ein und schließen Sie anschließend das Fenster.

3. Beispieldokumente indexieren

• Indizieren Sie die folgenden Beispieldokumente, die einen hypothetischen Quartalsbericht für die Organisation NoveTech darstellen:

Sobald die Dokumente indiziert sind, wird im Thread eine Löschmeldung angezeigt, wie unten dargestellt.

4. Ausführen des Abrufgraphen

• Wechseln Sie zum Abrufgraphen.

• Geben Sie die folgende Suchanfrage ein:

Das System gibt relevante Dokumente zurück und liefert eine genaue Antwort basierend auf den indizierten Daten.

Passen Sie den Abrufagenten an.

Um das Benutzererlebnis zu verbessern, führen wir einen Anpassungsschritt im Abrufgraphen ein, um die nächsten drei Fragen vorherzusagen, die ein Benutzer stellen könnte. Diese Vorhersage basiert auf Folgendem:

• Kontext aus den abgerufenen Dokumenten

• Vorherige Benutzerinteraktionen

• Letzte Benutzerabfrage

Zur Implementierung der Abfragevorhersagefunktion sind die folgenden Codeänderungen erforderlich:

1. Aktualisiere graph.py

• Funktion predict_query hinzufügen:

• Ändern Sie die Funktion respond , um das Objekt response anstelle der Nachricht zurückzugeben:

• Aktualisieren Sie die Graphstruktur, um einen neuen Knoten und eine neue Kante für predict_query hinzuzufügen:

2. Aktualisiere prompts.py

• Erstelle eine Eingabeaufforderung für eine Vorhersage in prompts.py:

3. Aktualisieren Sie die Datei configuration.py

• Fügen Sie predict_next_question_prompt hinzu:

4. Aktualisiere state.py

• Fügen Sie die folgenden Attribute hinzu:

5. Führen Sie den Abrufgraphen erneut aus.

• Geben Sie die folgende Suchanfrage erneut ein:

Das System verarbeitet die Eingabe und sagt drei verwandte Fragen voraus, die Benutzer stellen könnten, wie unten gezeigt.

Fazit

Die Integration der Retrieval Agent-Vorlage in LangGraph Studio und CLI bietet mehrere wichtige Vorteile:

• Beschleunigte Entwicklung: Die Vorlagen- und Visualisierungstools optimieren die Erstellung und das Debuggen von Abruf-Workflows und verkürzen so die Entwicklungszeit.

• Nahtlose Bereitstellung: Integrierte Unterstützung für APIs und automatische Skalierung gewährleistet eine reibungslose Bereitstellung in allen Umgebungen.

• Einfache Updates: Das Ändern von Arbeitsabläufen, das Hinzufügen neuer Funktionen und die Integration zusätzlicher Knoten ist einfach, wodurch der Abrufprozess leichter skaliert und verbessert werden kann.

• Permanenter Speicher: Das System behält Agentenzustände und -wissen bei und verbessert so Konsistenz und Zuverlässigkeit.

• Flexible Workflow-Modellierung: Entwickler können Abruflogik und Kommunikationsregeln für bestimmte Anwendungsfälle anpassen.

• Interaktion und Debugging in Echtzeit: Die Möglichkeit zur Interaktion mit laufenden Agenten ermöglicht effizientes Testen und Problemlösen.

Durch die Nutzung dieser Funktionen können Unternehmen leistungsstarke, effiziente und skalierbare Abrufsysteme erstellen, die die Datenzugänglichkeit und das Benutzererlebnis verbessern.

Der vollständige Quellcode für dieses Projekt ist auf GitHub verfügbar.

Über Amazon Nova

Amazon Nova ist eine Familie von künstlichen Intelligenzmodellen von Amazon, die auf Amazon Bedrock verfügbar sind und auf hohe Leistung und Kosteneffizienz ausgelegt sind. Diese Modelle arbeiten mit Text-, Bild- und Videoeingaben, erzeugen Textausgaben und sind für unterschiedliche Anforderungen an Genauigkeit, Geschwindigkeit und Kosten optimiert.

Amazon Nova Hauptmodelle

• Amazon Nova Micro: Dieses Modell konzentriert sich ausschließlich auf Textverarbeitung und ist schnell und kostengünstig. Es eignet sich ideal für Übersetzungen, logisches Schlussfolgern, Codevervollständigung und die Lösung mathematischer Probleme. Mit einer Generierungsrate von über 200 Token pro Sekunde eignet es sich ideal für Anwendungen, die sofortige Reaktionen erfordern.

• Amazon Nova Lite: Ein kostengünstiges multimodales Modell, das Bilder, Videos und Text schnell verarbeiten kann. Es zeichnet sich durch seine Schnelligkeit und Genauigkeit aus und ist für interaktive und hochvolumige Anwendungen geeignet, bei denen Kosten ein wichtiger Faktor sind.

• Amazon Nova Pro: Die fortschrittlichste Option, die hohe Genauigkeit, Geschwindigkeit und Kosteneffizienz vereint. Ideal für komplexe Aufgaben wie Videozusammenfassung, Frage-Antwort-Systeme, Softwareentwicklung und KI-Agenten. Expertenrezensionen bestätigen seine hervorragende Text- und Bildverarbeitungsfähigkeit sowie seine Fähigkeit, Anweisungen zu befolgen und automatisierte Arbeitsabläufe auszuführen.

Die Amazon Nova-Modelle eignen sich für eine Vielzahl von Anwendungen, von der Content-Erstellung und Datenanalyse bis hin zur Softwareentwicklung und KI-gestützten Prozessautomatisierung.

Im Folgenden zeigen wir Ihnen, wie Sie Amazon Nova-Modelle in Verbindung mit Elasticsearch für die automatisierte Analyse von Produktbewertungen verwenden können.

Was wir tun werden:

1. Erstellen Sie einen Endpunkt über die Inference API, der Amazon Bedrock mit Elasticsearch integriert.

2. Erstellen Sie eine Pipeline mithilfe des Inference Processors, die Aufrufe an den Inference API-Endpunkt durchführt.

3. Indexieren Sie Produktbewertungen und generieren Sie mithilfe der Pipeline automatisch eine Analyse der Bewertungen.

4. Analysieren Sie die Ergebnisse der Integration.

Erstellung eines Endpoint in der Inference API mit Amazon Nova Lite

Zunächst konfigurieren wir die Inference API, um Amazon Bedrock mit Elasticsearch zu integrieren. Wir definieren Amazon Nova Lite, ID amazon.nova-lite-v1:0, als das zu verwendende Modell, da es ein ausgewogenes Verhältnis zwischen Geschwindigkeit, Genauigkeit und Kosten bietet.

Hinweis: Sie benötigen gültige Zugangsdaten, um Amazon Bedrock nutzen zu können. Die Dokumentation zum Erhalt von Zugriffsschlüsseln finden Sie hier:

Erstellung der Pipeline für die Bewertungsanalyse

Nun erstellen wir eine Verarbeitungspipeline, die den Inferenzprozessor verwendet, um eine Überprüfungsanalyseaufforderung auszuführen. Diese Aufforderung sendet die Bewertungsdaten an Amazon Nova Lite, das Folgendes ausführt:

• Sentimentklassifizierung (positiv, negativ oder neutral).

• Zusammenfassung der Rezension.

• Schlüsselwortgenerierung.

• Authentizitätsmessung (authentisch | verdächtig | generisch).

Indexierungsrezensionen

Wir indexieren Produktbewertungen nun mithilfe der Bulk-API. Die zuvor erstellte Pipeline wird automatisch angewendet und fügt die vom Nova-Modell generierte Analyse den indizierten Dokumenten hinzu.

Abfragen und Analysieren der Ergebnisse

Zum Schluss führen wir eine Abfrage durch, um zu sehen, wie das Amazon Nova Lite-Modell die Rezensionen analysiert und klassifiziert. Durch Ausführen von GET products/_search erhalten wir die Dokumente, die bereits mit den aus dem Rezensionsinhalt generierten Feldern angereichert sind.

Das Modell ermittelt die vorherrschende Stimmung (positiv, neutral oder negativ), generiert prägnante Zusammenfassungen, extrahiert relevante Schlüsselwörter und schätzt die Authentizität jeder Rezension ein. Diese Felder helfen dabei, die Meinung des Kunden zu verstehen, ohne den gesamten Text lesen zu müssen.

Zur Interpretation der Ergebnisse betrachten wir Folgendes:

• Sentiment, das die allgemeine Wahrnehmung des Produkts durch den Konsumenten widerspiegelt.

• Die Zusammenfassung, in der die wichtigsten Punkte hervorgehoben werden.

• Schlüsselwörter, die verwendet werden können, um ähnliche Rezensionen zu gruppieren oder Feedbackmuster zu identifizieren.

• Authentizität, die ein Indikator dafür ist, ob die Rezension vertrauenswürdig erscheint. Dies ist nützlich für die Kuratierung oder Moderation.

Fazit

Die Integration von Amazon Nova Lite und Elasticsearch demonstrierte, wie Sprachmodelle Rohrezensionen in strukturierte und wertvolle Informationen umwandeln können. Durch die Verarbeitung der Rezensionen mittels einer Pipeline konnten wir Stimmungsanalyse, Authentizität, Zusammenfassungen und Schlüsselwörter automatisch und konsistent extrahieren.

Die Ergebnisse zeigen, dass das Modell den Kontext der Rezensionen verstehen, Nutzermeinungen klassifizieren und die relevantesten Punkte jeder Erfahrung hervorheben kann. Dadurch entsteht ein wesentlich umfangreicherer Datensatz, der zur Verbesserung der Suchfunktionen genutzt werden kann.

Das Model Context Protocol (MCP) macht dies möglich. Es verbindet die Konversations-KI nahtlos mit Ihren Datenbanken und externen APIs und wandelt komplexe Anfragen in natürliche Konversationen um. Moderne LLMs verfügen zwar über hervorragende Sprachkenntnisse, ihr wahres Potenzial entfaltet sich jedoch erst bei der Integration in reale Systeme. MCP schließt die Lücke zwischen ihnen und macht die Dateninteraktion intuitiver und effizienter.

In diesem Beitrag untersuchen wir:

• MCP-Architektur – So funktioniert es unter der Haube

• Vorteile eines mit Elasticsearch verbundenen MCP-Servers

• Erstellen eines Elasticsearch-basierten MCP-Servers

Es stehen spannende Zeiten bevor! Die Integration von MCP in Ihren Elastic-Stack verändert die Art und Weise, wie Sie mit Informationen interagieren, und macht komplexe Abfragen so intuitiv wie alltägliche Gespräche.

Modellkontextprotokoll

Das von Anthropic entwickelte Model Context Protocol (MCP) ist ein offener Standard, der KI-Modelle über sichere, bidirektionale Kanäle mit externen Datenquellen verbindet. Es löst eine große KI-Einschränkung: Echtzeitzugriff auf externe Systeme unter Beibehaltung des Gesprächskontexts.

MCP-Architektur

Die Architektur des Model Context Protocol besteht aus zwei Hauptkomponenten:

• MCP-Clients – KI-Assistenten und Chatbots, die im Namen der Benutzer Informationen anfordern oder Aufgaben ausführen.

• MCP-Server – Datenspeicher, Suchmaschinen und APIs, die relevante Informationen abrufen oder angeforderte Aktionen ausführen (z. B. Aufrufen externer APIs).

MCP-Server bieten Clients vier Hauptfunktionen:

• Ressourcen – Strukturierte Daten, Dokumente und Inhalte, die abgerufen und als Kontext für LLM-Interaktionen verwendet werden können. Dadurch können KI-Assistenten auf relevante Informationen aus Datenbanken, Suchindizes oder anderen Quellen zugreifen.

• Tools – Ausführbare Funktionen, die es LLMs ermöglichen, mit externen Systemen zu interagieren, Berechnungen durchzuführen oder Aktionen in der realen Welt auszuführen. Diese Tools erweitern die KI-Funktionen über die Textgenerierung hinaus und ermöglichen es Assistenten, Workflows auszulösen, APIs aufzurufen oder Daten dynamisch zu bearbeiten.

• Eingabeaufforderungen – Wiederverwendbare Eingabeaufforderungsvorlagen und Arbeitsabläufe zum Standardisieren und Teilen gängiger LLM-Interaktionen.

• Sampling – Fordern Sie LLM-Vervollständigungen über den Client an, um anspruchsvolles Agentenverhalten zu ermöglichen und gleichzeitig Sicherheit und Datenschutz zu gewährleisten.

MCP-Server + Elasticsearch

Herkömmliche Retrieval-Augmented Generation (RAG)-Systeme rufen Dokumente basierend auf Benutzerabfragen ab, aber MCP geht noch einen Schritt weiter: Es ermöglicht KI-Agenten, Aufgaben dynamisch zu erstellen und in Echtzeit auszuführen. Dadurch können Benutzer Fragen in natürlicher Sprache stellen, wie zum Beispiel:

• „Zeigen Sie mir alle Bestellungen über 500 $ vom letzten Monat.“

• „Welche Produkte haben die meisten 5-Sterne-Bewertungen erhalten?“

Und erhalten Sie sofort präzise Antworten, ohne eine einzige Anfrage zu schreiben.

MCP erreicht dies durch:

• Dynamische Toolauswahl – Agenten wählen auf intelligente Weise die richtigen Tools aus, die über MCP-Server basierend auf der Benutzerabsicht bereitgestellt werden. „Intelligentere“ LLMs sind im Allgemeinen besser darin, die richtigen Werkzeuge mit den entsprechenden Argumenten basierend auf dem Kontext auszuwählen.

• Bidirektionale Kommunikation – Agenten und Datenquellen tauschen Informationen reibungslos aus und verfeinern Abfragen nach Bedarf (z. B. Suchen Sie zuerst nach einer Indexzuordnung und erstellen Sie erst dann die ES-Abfrage.

• Multi-Tool-Orchestrierung – Workflows können Tools von mehreren MCP-Servern gleichzeitig nutzen.

• Permanenter Kontext – Agenten erinnern sich an vorherige Interaktionen und sorgen so für Kontinuität über Gespräche hinweg.

Ein mit Elasticsearch verbundener MCP-Server ermöglicht eine leistungsstarke Echtzeit-Abrufarchitektur. KI-Agenten können Elasticsearch-Daten bei Bedarf erkunden, abfragen und analysieren. Ihre Daten können über eine einfache Chat-Schnittstelle durchsucht werden.

MCP dient nicht nur dem Abrufen von Daten, sondern ermöglicht auch Aktionen. Es lässt sich in andere Tools integrieren, um Workflows auszulösen, Prozesse zu automatisieren und Erkenntnisse in Analysesysteme einzuspeisen. Durch die Trennung von Suche und Ausführung sorgt MCP dafür, dass KI-gestützte Anwendungen flexibel und aktuell bleiben und nahtlos in Agenten-Workflows integriert werden.

Praxisnah: MCP-Server zum Chatten mit Ihren Elasticsearch-Daten

Um über einen MCP-Server mit Elasticsearch zu interagieren, benötigen wir mindestens folgende Funktionen:

• Indizes abrufen

• Zuordnungen abrufen

• Führen Sie Suchvorgänge mit der Query DSL von Elasticsearch durch

Unser Server ist in TypeScript geschrieben und wir werden das offizielle MCP TypeScript SDK verwenden. Zur Einrichtung empfehlen wir die Installation der Claude Desktop App (die kostenlose Version ist ausreichend), da diese einen integrierten MCP-Client enthält. Unser MCP-Server stellt im Wesentlichen den offiziellen JavaScript Elasticsearch-Client über MCP-Tools bereit.

Beginnen wir mit der Definition des Elasticsearch-Clients und des MCP-Servers:

Wir werden die folgenden MCP-Servertools verwenden, die mit Elasticsearch interagieren können:

• Indizes auflisten (list_indices): Dieses Tool ruft alle verfügbaren Elasticsearch-Indizes ab und liefert Details wie Indexname, Integritätsstatus und Dokumentanzahl.

• Zuordnungen abrufen (get_mappings): Dieses Tool ruft die Feldzuordnungen für einen angegebenen Elasticsearch-Index ab und hilft Benutzern, die Struktur und Datentypen gespeicherter Dokumente zu verstehen.

• Suche (Suche): Dieses Tool führt eine Elasticsearch-Suche mithilfe einer bereitgestellten Abfrage-DSL aus. Es aktiviert automatisch Hervorhebungen für Textfelder und erleichtert so die Identifizierung relevanter Suchergebnisse.

Die vollständige Elasticsearch MCP-Serverimplementierung ist im Repository elastic/mcp-server-elasticsearch verfügbar.

Chatten Sie mit Ihrem Index

Sehen wir uns an, wie Sie den Elasticsearch MCP-Server einrichten, damit Sie Fragen zu Ihren Daten in natürlicher Sprache stellen können, z. B. „Finden Sie alle Bestellungen über 500 $ vom letzten Monat.“

Konfigurieren Sie Ihre Claude Desktop App

• Öffnen Sie die Claude Desktop App

• Navigieren Sie zu Einstellungen > Entwickler > MCP-Server

• Klicken Sie auf „Konfiguration bearbeiten“ und fügen Sie diese Konfiguration zu Ihrem claude_desktop_config.json hinzu:

Hinweis: Dieses Setup verwendet das von Elastic veröffentlichte npm-Paket @elastic/mcp-server-elasticsearch . Wenn Sie lokal entwickeln möchten, finden Sie hier weitere Informationen zum Hochfahren des Elasticsearch MCP-Servers.

Füllen Sie Ihren Elasticsearch-Index

• Sie können unsere Beispieldaten verwenden, um den Index "Bestellungen" für diese Demo zu füllen

• Auf diese Weise können Sie Abfragen wie „Alle Bestellungen über 500 $ vom letzten Monat suchen“ ausprobieren.

Beginnen Sie mit der Nutzung

• Öffnen Sie eine neue Konversation in der Claude Desktop App

• Der MCP-Server verbindet sich automatisch

• Stellen Sie Fragen zu Ihren Elasticsearch-Daten!

Sehen Sie sich diese Demo an, um zu sehen, wie einfach es ist, Ihre Elasticsearch-Daten mithilfe natürlicher Sprache abzufragen:

Wie funktionieren diese Abfragen?

Bei der Aufforderung „Alle Bestellungen über 500 $ vom letzten Monat suchen“ erkennt das LLM die Absicht, den Elasticsearch-Index mit angegebenen Einschränkungen zu durchsuchen. Um eine effektive Suche durchzuführen, muss der Agent:

• Ermitteln Sie den Indexnamen: orders

• Verstehen Sie die Zuordnungen des orders -Index

• Erstellen Sie die Query-DSL kompatibel mit Index-Mappings und führen Sie anschließend die Suchanfrage aus

Diese Interaktion kann wie folgt dargestellt werden:

Fazit

Das Model Context Protocol verbessert Ihre Interaktion mit Elasticsearch-Daten und ermöglicht Konversationen in natürlicher Sprache anstelle komplexer Abfragen. Durch die Verbindung von KI-Funktionen mit Ihren Daten erstellt MCP einen intuitiveren und effizienteren Workflow, der den Kontext während Ihrer Interaktionen aufrechterhält.

Der Elasticsearch MCP-Server ist als öffentliches npm-Paket (@elastic/mcp-server-elasticsearch) verfügbar, was die Integration für Entwickler unkompliziert macht. Mit minimalem Einrichtungsaufwand kann Ihr Team beginnen, Daten zu untersuchen, Workflows auszulösen und durch einfache Gespräche Erkenntnisse zu gewinnen.

Bereit, es selbst zu erleben? Testen Sie noch heute den Elasticsearch MCP-Server und beginnen Sie mit dem Chatten mit Ihren Daten.

Wie funktioniert die multimodale RAG-Pipeline?

1. Hinweise sammeln → Bilder, Audio, Texte und Tiefenkarten vom Tatort in Gotham.

2. Einbettungen generieren → Jede Datei wird mithilfe des multimodalen Modells ImageBind in einen Vektor konvertiert.

3. Indizierung in Elasticsearch → Die Vektoren werden für einen effizienten Abruf gespeichert.

4. Suche nach Ähnlichkeit → Bei einem neuen Hinweis werden die ähnlichsten Vektoren abgerufen.

5. Das LLM analysiert die Beweise → Ein GPT-4-Modell synthetisiert die Antwort und identifiziert den Verdächtigen!

Eingesetzte Technologien

• ImageBind → Generiert einheitliche Einbettungen für verschiedene Modalitäten.

• Elasticsearch → Ermöglicht eine schnelle und effiziente Vektorsuche.

• LLM (GPT-4, OpenAI) → Analysiert die Beweise und erstellt einen Abschlussbericht.

Für wen ist dieser Blog?

• Elastic-Benutzer, die an der multimodalen Vektorsuche interessiert sind.

• Entwickler, die multimodales RAG in der Praxis verstehen möchten.

• Jeder, der nach skalierbaren Lösungen zur Analyse von Daten aus mehreren Quellen sucht.

Voraussetzungen für multimodale RAG: Aufbau der Umgebung

Um das Verbrechen in Gotham City aufzuklären, müssen Sie Ihre Technologieumgebung einrichten. Folgen Sie dieser Schritt-für-Schritt-Anleitung:

1. Technische Voraussetzungen

Komponente

Spezifikation

Betriebssystem

Linux, macOS oder Windows

Python

3.10 oder höher

RAM

Mindestens 8 GB (16 GB empfohlen)

Grafikkarte

Optional, aber für ImageBind empfohlen

2. Einrichten des Projekts

Alle Ermittlungsmaterialien sind auf GitHub verfügbar und wir werden für dieses interaktive Erlebnis zur Aufklärung von Verbrechen Jupyter Notebook (Google Colab) verwenden. Befolgen Sie diese Schritte, um zu beginnen:

Einrichten mit Jupyter Notebook (Google Colab)

1. Zugriff auf das Notebook

• Öffnen Sie unser gebrauchsfertiges Google Colab-Notizbuch: Multimodales RAG mit Elasticsearch.

• Dieses Notizbuch enthält den gesamten Code und alle Erklärungen, die Sie zum Mitmachen benötigen.

2. Klonen Sie das Repository

3. Abhängigkeiten installieren

4. Anmeldeinformationen konfigurieren

Hinweis: Das ImageBind-Modell (~2 GB) wird beim ersten Ausführen automatisch heruntergeladen.

Nachdem nun alles eingerichtet ist, können wir in die Details eintauchen und das Verbrechen aufklären!

Einleitung: Die Kriminalität in Gotham City

In einer regnerischen Nacht erschüttert ein schockierendes Verbrechen die Stadt Gotham City. Commissioner Gordon braucht Ihre Hilfe, um das Geheimnis zu lüften. Hinweise sind über verschiedene Formate verstreut: verschwommene Bilder, mysteriöse Audiodaten, verschlüsselte Texte und sogar Tiefenkarten. Sind Sie bereit, die fortschrittlichste KI-Technologie zur Lösung des Falls einzusetzen?

In diesem Blog werden Sie Schritt für Schritt durch den Aufbau eines multimodalen RAG-Systems (Retrieval-Augmented Generation) geführt, das verschiedene Datentypen (Bilder, Audio, Texte und Tiefenkarten) in einem einzigen Suchraum vereint. Wir werden ImageBind verwenden, um multimodale Einbettungen zu generieren, Elasticsearch , um diese Einbettungen zu speichern und abzurufen, und ein Large Language Model (LLM), um die Beweise zu analysieren und einen Abschlussbericht zu erstellen.

Grundlagen: Multimodale RAG-Architektur

Was ist ein multimodaler RAG?

Der Aufstieg von Retrieval-Augmented Generation (RAG) Multimodal revolutioniert die Art und Weise, wie wir mit KI-Modellen interagieren. Traditionell arbeiten RAG-Systeme ausschließlich mit Text und rufen relevante Informationen aus Datenbanken ab, bevor sie Antworten generieren. Die Welt beschränkt sich jedoch nicht nur auf Text– auch Bilder, Videos und Audiodateien enthalten wertvolles Wissen. Aus diesem Grund gewinnen multimodale Architekturen an Bedeutung, die es KI-Systemen ermöglichen, Informationen aus verschiedenen Formaten zu kombinieren, um umfassendere und präzisere Antworten zu erhalten.

Drei Hauptansätze für multimodale RAG

Zur Implementierung eines multimodalen RAG werden üblicherweise drei Strategien verwendet. Jeder Ansatz hat seine eigenen Vorteile und Einschränkungen, abhängig vom Anwendungsfall:

1. Gemeinsamer Vektorraum

Daten aus verschiedenen Modalitäten werden mithilfe multimodaler Modelle wie ImageBind in einen gemeinsamen Vektorraum abgebildet. Dadurch können Textabfragen Bilder, Videos und Audiodateien ohne explizite Formatkonvertierung abrufen.

Vorteile:

• Ermöglicht modalübergreifenden Abruf ohne explizite Formatkonvertierung.

• Bietet eine reibungslose Integration zwischen verschiedenen Modalitäten und ermöglicht den direkten Abruf von Text, Bild, Audio und Video.

• Skalierbar für verschiedene Datentypen, daher nützlich für groß angelegte Abrufanwendungen.

Nachteile:

• Für das Training sind große multimodale Datensätze erforderlich, die möglicherweise nicht immer verfügbar sind.

• Der gemeinsame Einbettungsraum kann zu einer semantischen Drift führen, bei der die Beziehungen zwischen Modalitäten nicht perfekt erhalten bleiben.

• Je nach Datensatzverteilung kann eine Verzerrung in multimodalen Modellen die Abrufgenauigkeit beeinträchtigen.

2. Einzelne geerdete Modalität

Alle Modalitäten werden vor dem Abruf in ein einziges Format, normalerweise Text, konvertiert. Beispielsweise werden Bilder durch automatisch generierte Bildunterschriften beschrieben und Audiodaten in Text transkribiert.

Vorteile:

• Vereinfacht das Auffinden, da alles in eine einheitliche Textdarstellung umgewandelt wird.

• Funktioniert gut mit vorhandenen textbasierten Suchmaschinen, sodass keine spezielle multimodale Infrastruktur erforderlich ist.

• Kann die Interpretierbarkeit verbessern, da die abgerufenen Ergebnisse in einem für Menschen lesbaren Format vorliegen.

Nachteile:

• Informationsverlust: Bestimmte Details (z. B. räumliche Beziehungen in Bildern, Ton in Audio) werden in Textbeschreibungen möglicherweise nicht vollständig erfasst.

• Abhängig von der Untertitel-/Transkriptionsqualität: Fehler in automatischen Anmerkungen können die Abrufeffektivität verringern.

• Nicht optimal für rein visuelle oder akustische Abfragen, da beim Konvertierungsprozess möglicherweise wichtiger Kontext entfernt wird.

3. Getrennte Abholung

Behält für jede Modalität unterschiedliche Modelle bei. Das System führt für jeden Datentyp eine separate Suche durch und führt die Ergebnisse später zusammen.

Vorteile:

• Ermöglicht eine benutzerdefinierte Optimierung pro Modalität und verbessert so die Abrufgenauigkeit für jeden Datentyp.

• Geringere Abhängigkeit von komplexen multimodalen Modellen, wodurch die Integration vorhandener Abrufsysteme erleichtert wird.

• Bietet eine detaillierte Kontrolle über die Rangfolge und Neubewertung, da Ergebnisse aus verschiedenen Modalitäten dynamisch kombiniert werden können.

Nachteile:

• Erfordert eine Zusammenführung der Ergebnisse, wodurch der Abruf- und Rankingprozess komplexer wird.

• Kann zu inkonsistenten Antworten führen, wenn unterschiedliche Modalitäten widersprüchliche Informationen zurückgeben.

• Höherer Rechenaufwand , da für jede Modalität unabhängige Suchvorgänge durchgeführt werden, was die Verarbeitungszeit verlängert.

Unsere Wahl: Gemeinsamer Vektorraum mit ImageBind

Unter diesen Ansätzen haben wir uns für den Shared Vector Space entschieden, eine Strategie, die perfekt auf die Anforderungen effizienter multimodaler Suchen abgestimmt ist. Unsere Implementierung basiert auf ImageBind, einem Modell, das mehrere Modalitäten (Text, Bild, Audio und Video) in einem gemeinsamen Vektorraum darstellen kann. Dies ermöglicht uns:

• Führen Sie modalübergreifende Suchen zwischen verschiedenen Medienformaten durch, ohne alles in Text konvertieren zu müssen.

• Verwenden Sie ausdrucksstarke Einbettungen , um Beziehungen zwischen verschiedenen Modalitäten zu erfassen.

• Sorgen Sie für Skalierbarkeit und Effizienz, indem Sie optimierte Einbettungen für einen schnellen Abruf in Elasticsearch speichern.

Durch die Übernahme dieses Ansatzes haben wir eine robuste multimodale Suchpipeline erstellt, bei der eine Textabfrage ohne zusätzliche Vorverarbeitung direkt Bilder oder Audio abrufen kann. Diese Methode erweitert die praktischen Anwendungen von der intelligenten Suche in großen Repositorien bis hin zu fortschrittlichen multimodalen Empfehlungssystemen.

Die folgende Abbildung veranschaulicht den Datenfluss innerhalb der multimodalen RAG-Pipeline und hebt den Indexierungs-, Abruf- und Antwortgenerierungsprozess basierend auf multimodalen Daten hervor:

Wie funktioniert der Einbettungsraum?

Traditionell stammen Texteinbettungen aus Sprachmodellen (z. B. BERT, GPT). Mit nativen multimodalen Modellen wie ImageBind von Meta AI verfügen wir nun über ein Grundgerüst, das Vektoren für mehrere Modalitäten generiert:

• Text: Sätze und Absätze werden in Vektoren derselben Dimension umgewandelt.

• Bilder (Sehen): Pixel werden in denselben dimensionalen Raum abgebildet, der für Text verwendet wird.

• Audio: Tonsignale werden in Einbettungen umgewandelt, die mit Bildern und Text vergleichbar sind.

• Tiefenkarten: Tiefendaten werden verarbeitet und führen ebenfalls zu Vektoren.

Somit kann jeder Hinweis (Text, Bild, Audio, Tiefe) mithilfe von Vektorähnlichkeitsmetriken wie der Kosinusähnlichkeit mit jedem anderen verglichen werden. Wenn eine lachende Audioprobe und ein Bild des Gesichts eines Verdächtigen in diesem Raum „nahe beieinander“ liegen, können wir auf eine gewisse Korrelation schließen (z. B. dieselbe Identität).

Phase 1 – Hinweise am Tatort sammeln

Bevor wir die Beweise analysieren, müssen wir sie sammeln. Das Verbrechen in Gotham hat Spuren hinterlassen, die in Bildern, Audiodateien, Texten und sogar Tiefendaten verborgen sein könnten. Lassen Sie uns diese Hinweise organisieren, um sie in unser System einzuspeisen.

Was haben wir?

Commissioner Gordon hat uns die folgenden Akten mit Beweismaterial geschickt, das in vier verschiedenen Modalitäten am Tatort gesammelt wurde:

Streckenbeschreibung und Modalität

a) Bilder (2 Fotos)

• crime_scene1.jpg, crime_scene2.jpg → Fotos vom Tatort. Zeigt verdächtige Spuren auf dem Boden.

• suspect_spotted.jpg → Bild einer Überwachungskamera, das eine Silhouette zeigt, die vom Tatort wegläuft.

b) Audio (1 Aufnahme)

• joker_laugh.wav → Ein Mikrofon in der Nähe des Tatorts fing ein unheimliches Lachen ein.

c) Text (1 Nachricht)

• Riddle.txt, note2.txt → Am Tatort wurden einige mysteriöse Notizen gefunden, die möglicherweise vom Verbrecher hinterlassen wurden.

d) Tiefe (1 Tiefenkarte)

• depth_suspect.png → Eine Überwachungskamera mit Tiefensensor hat einen Verdächtigen in einer nahegelegenen Gasse erfasst.

• jdancing-depth.png → Eine Überwachungskamera mit Tiefensensor hat einen Verdächtigen aufgenommen, der die U-Bahn-Station entlangging.

Diese Beweisstücke liegen in unterschiedlichen Formaten vor und können nicht direkt auf die gleiche Weise analysiert werden. Wir müssen sie in Einbettungen umwandeln – numerische Vektoren, die einen kreuzmodalen Vergleich ermöglichen.

Dateiorganisation

Bevor wir mit der Verarbeitung beginnen, müssen wir sicherstellen, dass alle Hinweise im Datenverzeichnis ordnungsgemäß organisiert sind, damit die Pipeline reibungslos läuft.

Erwartete Verzeichnisstruktur:

Code zur Überprüfung der Hinweisorganisation

Bevor wir fortfahren, stellen wir sicher, dass sich alle erforderlichen Dateien am richtigen Speicherort befinden.

Ausführen der Datei

Erwartete Ausgabe (wenn alle Dateien korrekt sind):

Erwartete Ausgabe (falls eine Datei fehlt):

Dieses Skript hilft, Fehler zu vermeiden, bevor wir mit der Generierung von Einbettungen und deren Indizierung in Elasticsearch beginnen.

Phase 2 – Organisieren der Beweise

Einbettungen mit ImageBind generieren

Um die Hinweise zu vereinheitlichen, müssen wir sie in Einbettungen umwandeln – Vektordarstellungen, die die Bedeutung jeder Modalität erfassen. Wir verwenden ImageBind, ein Modell von Meta AI, das Einbettungen für verschiedene Datentypen (Bilder, Audio, Text und Tiefenkarten) innerhalb eines gemeinsamen Vektorraums generiert.

Wie funktioniert ImageBind?

Um verschiedene Arten von Beweisen (Bilder, Audio, Text und Tiefenkarten) zu vergleichen, müssen wir sie mithilfe von ImageBind in numerische Vektoren umwandeln. Dieses Modell ermöglicht die Konvertierung aller Eingabetypen in dasselbe Einbettungsformat und ermöglicht so modalitätsübergreifende Suchen .

Nachfolgend finden Sie einen optimierten Code (src/embedding_generator.py), um Einbettungen für alle Eingabetypen unter Verwendung der entsprechenden Prozessoren für jede Modalität zu generieren:

Ein Tensor ist eine grundlegende Datenstruktur im maschinellen Lernen und Deep Learning, insbesondere bei der Arbeit mit Modellen wie ImageBind. In unserem Kontext:

Hier stellt der Tensor die Eingabedaten (Bild, Audio oder Text) dar, die in ein mathematisches Format konvertiert werden, das das Modell verarbeiten kann. Speziell:

• Für Bilder: Der Tensor stellt das Bild als mehrdimensionale Matrix numerischer Werte dar (Pixel, organisiert nach Höhe, Breite und Farbkanälen).

• Für Audio: Der Tensor stellt Schallwellen als eine Abfolge von Amplituden über die Zeit dar.

• Für Text: Der Tensor stellt Wörter oder Token als numerische Vektoren dar.

Testen der Einbettungsgenerierung:

Testen wir unsere Einbettungsgenerierung mit dem folgenden Code. Speichern Sie es in 02-stage/test_embedding_generation.py und führen Sie es mit diesem Befehl aus:

Erwartete Ausgabe:

Nun wurde das Bild in einen 1024-dimensionalen Vektor umgewandelt.

Phase 3 – Speicherung und Suche in Elasticsearch

Nachdem wir nun die Einbettungen für die Beweise generiert haben, müssen wir sie in einer Vektordatenbank speichern, um effiziente Suchvorgänge zu ermöglichen. Hierzu verwenden wir Elasticsearch, das dichte Vektoren (dense_vector) unterstützt und Ähnlichkeitssuchen ermöglicht.

Dieser Schritt besteht aus zwei Hauptprozessen:

• Indizierung der Einbettungen → Speichert die generierten Vektoren in Elasticsearch.

• Ähnlichkeitssuche → Ruft die ähnlichsten Datensätze zu einem neuen Beweisstück ab.

Indizierung der Beweise in Elasticsearch

Jedes von ImageBind verarbeitete Beweisstück (Bild, Audio, Text oder Tiefe) wird in einen 1024-dimensionalen Vektor umgewandelt. Wir müssen diese Vektoren in Elasticsearch speichern, um zukünftige Suchen zu ermöglichen.

Der folgende Code (src/elastic_manager.py) erstellt einen Index in Elasticsearch und konfiguriert die Zuordnung zum Speichern der Einbettungen.

Ausführen der Indizierung

Lassen Sie uns nun ein Beweisstück indizieren, um den Prozess zu testen.

Erwartete Ausgabe in Elasticsearch (Zusammenfassung des indizierten Dokuments):

Um alle multimodalen Beweise zu indizieren, führen Sie bitte den folgenden Python-Befehl aus:

Jetzt werden die Beweise in Elasticsearch gespeichert und können bei Bedarf abgerufen werden.

Überprüfen des Indizierungsprozesses

Nachdem wir das Indexierungsskript ausgeführt haben, überprüfen wir, ob alle unsere Beweise korrekt in Elasticsearch gespeichert wurden. Sie können die Dev Tools von Kibana verwenden, um einige Überprüfungsabfragen auszuführen:

1. Überprüfen Sie zunächst, ob der Index erstellt wurde:

2. Überprüfen Sie dann die Anzahl der Dokumente pro Modalität:

3. Untersuchen Sie abschließend die indizierte Dokumentstruktur:

Erwartete Ergebnisse:

• Ein Index mit dem Namen „multimodal_content“ sollte vorhanden sein.

• Etwa 7 Dokumente, verteilt auf verschiedene Modalitäten (Bild, Audio, Text, Tiefe).

• Jedes Dokument sollte die Felder „Einbettung“, „Modalität“, „Beschreibung“, „Metadaten“ und „content_path“ enthalten.

Dieser Überprüfungsschritt stellt sicher, dass unsere Beweisdatenbank ordnungsgemäß eingerichtet ist, bevor wir mit der Ähnlichkeitssuche fortfahren.

Suche nach ähnlichen Beweisen in Elasticsearch

Nachdem die Beweise nun indiziert wurden, können wir Suchen durchführen, um die Datensätze zu finden, die einem neuen Hinweis am ähnlichsten sind. Diese Suche verwendet Vektorähnlichkeit , um die ähnlichsten Datensätze im Einbettungsraum zurückzugeben.

Der folgende Code führt diese Suche durch.

Testen der Suche – Verwenden von Audio als Abfrage für multimodale Ergebnisse

Testen wir nun die Beweissuche anhand einer verdächtigen Audiodatei. Wir müssen auf die gleiche Weise eine Einbettung für die Datei generieren und nach ähnlichen Einbettungen suchen:

Erwartete Ausgabe im Terminal:

Jetzt können wir die gefundenen Beweise analysieren und ihre Relevanz für den Fall bestimmen.

Mehr als Audio – Multimodale Suchen erkunden

Rollentausch: Jede Modalität kann eine „Frage“ sein

In unserem multimodalen RAG- System ist jede Modalität eine potenzielle Suchanfrage. Lassen Sie uns über das Audiobeispiel hinausgehen und untersuchen, wie andere Datentypen Untersuchungen einleiten können.

1. Suche nach Text (Entzifferung der Notiz des Täters)

Szenario: Sie haben eine verschlüsselte Textnachricht gefunden und möchten entsprechende Beweise finden.

Erwartete Ergebnisse:

2. Bildersuche (Verfolgung des verdächtigen Tatorts)

Szenario: Ein neuer Tatort (crime_scene2.jpg) muss mit anderen Beweisen verglichen werden.

Ausgabe:

3. Tiefenkartensuche (3D-Verfolgung)

Szenario: Eine Tiefenkarte (jdancing-depth.png) deckt Bildfluchtmuster auf.

Ausgabe

Warum ist das wichtig?

Jede Modalität weist einzigartige Verbindungen auf:

• Text → Sprachliche Muster des Verdächtigen.

• Bilder → Erkennung von Orten und Objekten.

• Tiefe → 3D- Szenenrekonstruktion.

Jetzt verfügen wir in Elasticsearch über eine strukturierte Beweisdatenbank, die es uns ermöglicht,multimodale Beweise effizient zu speichern und abzurufen.

Zusammenfassung unserer Aktivitäten:

• Gespeicherte multimodale Einbettungen in Elasticsearch.

• Führte Ähnlichkeitssuchen durch und fand Beweise im Zusammenhang mit neuen Hinweisen.

• Die Suche wurde mit einer verdächtigen Audiodatei getestet, um sicherzustellen, dass das System ordnungsgemäß funktioniert.

Nächster Schritt: Wir werden ein LLM (Large Language Model) verwenden, um die abgerufenen Beweise zu analysieren und einen Abschlussbericht zu erstellen.

Stufe 4 – Die Punkte mit dem LLM verbinden

Nachdem die Beweise nun in Elasticsearch indiziert wurden und anhand der Ähnlichkeit abgerufen werden können, benötigen wir ein LLM (Large Language Model), um sie zu analysieren und einen Abschlussbericht zu erstellen, den wir an Kommissar Gordon senden können. Der LLM ist dafür verantwortlich , Muster zu erkennen, Hinweise zu verknüpfen und auf Grundlage der gefundenen Beweise einen möglichen Verdächtigen vorzuschlagen .

Für diese Aufgabe verwenden wir GPT-4 Turbo und formulieren eine detaillierte Eingabeaufforderung , damit das Modell die Ergebnisse effizient interpretieren kann.

LLM-Integration

Um das LLM in unser System zu integrieren, haben wir die LLMAnalyzer- Klasse (src/llm_analyzer.py) erstellt, die die abgerufenen Beweise von Elasticsearch empfängt und einen forensischen Bericht erstellt, der diese Beweise als Eingabekontext verwendet.

Temperatureinstellung in der LLM-Analyse:

Für unser forensisches Analysesystem verwenden wir eine moderate Temperatur von 0,5. Diese ausgewogene Einstellung wurde gewählt, weil:

• Es stellt einen Mittelweg zwischen deterministischen (zu starren) und stark zufälligen Ergebnissen dar;

• Bei 0,5 behält das Modell genügend Struktur bei, um logische und vertretbare forensische Schlussfolgerungen zu liefern;

• Diese Einstellung ermöglicht es dem Modell, Muster zu erkennen und Verbindungen herzustellen, während es gleichzeitig innerhalb angemessener forensischer Analyseparameter bleibt.

• Es gleicht den Bedarf an konsistenten, zuverlässigen Ergebnissen mit der Fähigkeit aus, aufschlussreiche Analysen zu erstellen.

Diese moderate Temperatureinstellung trägt dazu bei, dass unsere forensische Analyse sowohl zuverlässig als auch aufschlussreich ist und sowohl zu starre als auch zu spekulative Schlussfolgerungen vermieden werden.

Ausführen der Beweisanalyse

Nachdem wir nun über die LLM-Integration verfügen, benötigen wir ein Skript , das alle Systemkomponenten verbindet. Dieses Skript wird:

• Suchen Sie in Elasticsearch nach ähnlichen Beweisen .

• Analysieren Sie die abgerufenen Beweise mithilfe des LLM , um einen Abschlussbericht zu erstellen.

Code: Skript zur Beweisanalyse

Erwartete LLM-Ausgabe

Fazit: Fall gelöst

Nachdem alle Hinweise gesammelt und analysiert wurden, hat das multimodale RAG-System einen Verdächtigen identifiziert: den Joker.

Durch die Kombination von Bildern, Audio, Text und Tiefenkarten in einem gemeinsamen Vektorraum mithilfe von ImageBind konnte das System Verbindungen erkennen , die manuell nicht hätten identifiziert werden können. Elasticsearch sorgte für schnelle und effiziente Suchvorgänge, während LLM die Beweise in einem klaren und schlüssigen Bericht zusammenfasste.

Die wahre Macht dieses Systems geht jedoch über Gotham City hinaus. Die multimodale RAG-Architektur öffnet Türen zu zahlreichen realen Anwendungen:

• Urbane Überwachung: Identifizierung von Verdächtigen anhand von Bild-, Audio- und Sensordaten.

• Forensische Analyse: Korrelieren von Beweisen aus mehreren Quellen zur Aufklärung komplexer Verbrechen.

• Multimedia-Empfehlung: Erstellen von Empfehlungssystemen , die multimodale Kontexte verstehen (z. B. Musikvorschläge basierend auf Bildern oder Text).

• Social-Media-Trends: Erkennen von Trendthemen in verschiedenen Datenformaten.

Nachdem Sie nun gelernt haben, wie man ein multimodales RAG-System erstellt, warum testen Sie es nicht mit Ihren eigenen Hinweisen?

Teilen Sie Ihre Entdeckungen mit uns und helfen Sie der Community , im Bereich der multimodalen KI voranzukommen!

Besonderer Dank

Ich möchte Adrian Cole für seinen wertvollen Beitrag und seine Überprüfung während des Prozesses der Definition der Bereitstellungsarchitektur dieses Codes danken.

Referenzen

• Erstellen Sie ein multimodales Bildabrufsystem mithilfe der KNN-Suche und CLIP-Einbettungen

• k-Nearest-Neighbor (kNN)-Suche

• Offizielle PyTorch-Dokumentation zu Tensoren

• ImageBind: eine neue Möglichkeit, KI über alle Sinne hinweg zu „vernetzen“

Elasticsearch ermöglicht Benutzern die Verbindung mit LLMs über die Open Inference API und unterstützt Anbieter wie Amazon Bedrock, Cohere, Google AI, Azure AI Studio, HuggingFace – als Service und andere.

Ollama ist ein Tool, mit dem Sie LLM-Modelle mithilfe Ihrer eigenen Infrastruktur (Ihrem lokalen Computer/Server) herunterladen und ausführen können. Hier finden Sie eine Liste der verfügbaren Modelle, die mit Ollama kompatibel sind.

Ollama ist eine großartige Option, wenn Sie verschiedene Open-Source-Modelle hosten und testen möchten, ohne sich Gedanken über die unterschiedlichen Einrichtungsmöglichkeiten der einzelnen Modelle oder über die Erstellung einer API für den Zugriff auf die Modellfunktionen machen zu müssen, da Ollama sich um alles kümmert.

Da die Ollama-API mit der OpenAI-API kompatibel ist, können wir das Inferenzmodell problemlos integrieren und mit Playground eine RAG-Anwendung erstellen.

Voraussetzungen

1. Elasticsearch 8.17

2. Kibana 8.17

3. Python

Schritte

1. Einrichten des Ollama LLM-Servers

2. Erstellen von Zuordnungen

3. Indizierung von Daten

4. Fragen stellen mit Playground

Einrichten des Ollama LLM-Servers

Wir werden einen LLM-Server einrichten, um ihn mithilfe von Ollama mit unserer Playground-Instanz zu verbinden. Wir müssen:

• Laden Sie Ollama herunter und führen Sie es aus.

• Verwenden Sie ngrok, um über das Internet auf Ihren lokalen Webserver zuzugreifen, der Ollama hostet

Laden Sie Ollama herunter und führen Sie es aus

Um Ollama zu verwenden, müssen wir es zuerst herunterladen. Ollama bietet Unterstützung für Linux, Windows und macOS. Laden Sie hier einfach die mit Ihrem Betriebssystem kompatible Ollama-Version herunter. Sobald Ollama installiert ist, können wir aus dieser Liste unterstützter LLMs ein Modell auswählen. In diesem Beispiel verwenden wir das Modell llama3.2, ein allgemeines mehrsprachiges Modell. Im Setup-Prozess aktivieren Sie das Befehlszeilentool für Ollama. Sobald das heruntergeladen ist, können Sie die folgende Zeile ausführen:

Das Ergebnis lautet:

Nach der Installation können Sie es mit diesem Befehl testen:

Stellen wir eine Frage:

Wenn das Modell ausgeführt wird, aktiviert Ollama eine API, die standardmäßig auf Port „11434“ ausgeführt wird. Lassen Sie uns eine Anfrage an diese API stellen und dabei der offiziellen Dokumentation folgen:

Dies ist die Antwort, die wir erhalten haben:

Beachten Sie, dass die spezifische Antwort für diesen Endpunkt ein Streaming ist.

Endpunkt mit ngrok dem Internet aussetzen

Da unser Endpunkt in einer lokalen Umgebung arbeitet, kann von einem anderen Punkt – wie unserer Elastic Cloud-Instanz – nicht über das Internet darauf zugegriffen werden. ngrok ermöglicht es uns, einen Port mit einer öffentlichen IP freizugeben. Erstellen Sie ein Konto in ngrok und folgen Sie der offiziellen Einrichtungsanleitung.

Sobald der ngrok-Agent installiert und konfiguriert wurde, können wir den von Ollama verwendeten Port verfügbar machen:

Hinweis: Der Header --host-header="localhost:11434" garantiert, dass der Header „Host“ in den Anfragen mit „localhost:11434“ übereinstimmt.

Durch Ausführen dieses Befehls wird ein öffentlicher Link zurückgegeben, der funktioniert, solange ngrok und der Ollama-Server lokal ausgeführt werden.

Unter „Weiterleitung“ können wir sehen, dass ngrok eine URL generiert hat. Speichern Sie es für später.

Versuchen wir erneut, eine HTTP-Anfrage an den Endpunkt zu senden, diesmal unter Verwendung der von ngrok generierten URL:

Die Antwort sollte der vorherigen ähnlich sein.

Erstellen von Zuordnungen

ELSER-Endpunkt

Für dieses Beispiel erstellen wir einen Inferenzendpunkt mithilfe der Elasticsearch-Inferenz-API. Zusätzlich verwenden wir ELSER , um die Einbettungen zu generieren.

Stellen wir uns für dieses Beispiel vor, Sie haben eine Apotheke, die zwei Arten von Medikamenten verkauft:

• Medikamente, für die ein Rezept erforderlich ist.

• Medikamente, für die KEIN Rezept erforderlich ist.

Diese Informationen würden in das Beschreibungsfeld jedes Medikaments aufgenommen.

Das LLM muss dieses Feld interpretieren, daher verwenden wir folgende Datenzuordnungen:

Das Feld text_description speichert den Klartext der Beschreibungen, während semantic_field, ein Feldtyp vom Typ „semantic_text“ , die von ELSER generierten Einbettungen speichert.

Die Eigenschaft copy_to kopiert den Inhalt aus den Feldern name und text_description in das semantische Feld, sodass die Einbettungen für diese Felder generiert werden.

Indizierung von Daten

Lassen Sie uns nun die Daten mithilfe der _bulk-API indizieren.

Abwehr:

Fragen stellen mit Playground

Playground ist ein Kibana-Tool, mit dem Sie mithilfe von Elasticsearch-Indizes und einem LLM-Anbieter schnell ein RAG-System erstellen können. Sie können diesen Artikel lesen, um mehr darüber zu erfahren.

Verbinden des lokalen LLM mit Playground

Wir müssen zunächst einen Connector erstellen, der die soeben erstellte öffentliche URL verwendet. Gehen Sie in Kibana zu „Suchen > Playground“ und klicken Sie dann auf „Mit einem LLM verbinden“.

Durch diese Aktion wird auf der linken Seite der Kibana-Oberfläche ein Menü angezeigt. Klicken Sie dort auf „OpenAI“.

Wir können jetzt mit der Konfiguration des OpenAI-Connectors beginnen.

Gehen Sie zu „Connector-Einstellungen“ und wählen Sie für den OpenAI-Anbieter „Andere (OpenAI-kompatible Dienste)“ aus:

Nun konfigurieren wir die übrigen Felder. In diesem Beispiel nennen wir unser Modell "medicines-llm". Verwenden Sie im URL-Feld die von ngrok generierte URL (/v1/chat/completions). Wählen Sie im Feld „Standardmodell“ die Option „llama3.2“ aus. Wir benötigen keinen API-Schlüssel, geben Sie einfach einen beliebigen Text ein, um fortzufahren:

Klicken Sie auf „Speichern“ und fügen Sie die Indexmedikamente hinzu, indem Sie auf „Datenquellen hinzufügen“ klicken:

Großartig! Wir haben jetzt Zugriff auf Playground mithilfe des LLM, das wir lokal als RAG-Engine ausführen.

Bevor wir es testen, fügen wir dem Agenten spezifischere Anweisungen hinzu und erhöhen die Anzahl der an das Modell gesendeten Dokumente auf 10, damit die Antwort möglichst viele Dokumente enthält. Das Kontextfeld ist semantic_field und enthält dank der Eigenschaft „copy_to“ den Namen und die Beschreibung der Medikamente.

Stellen wir nun die Frage: Kann ich Clonazepam ohne Rezept kaufen? und sehen Sie, was passiert:

Wie erwartet haben wir die richtige Antwort erhalten.

Wie geht es weiter?

Der nächste Schritt besteht darin, Ihre eigene Anwendung zu erstellen! Playground bietet ein Code-Skript in Python, das Sie auf Ihrem Computer ausführen und an Ihre Anforderungen anpassen können. Beispielsweise indem Sie es hinter einen FastAPI -Server stellen, um einen QA-Medizin-Chatbot zu erstellen, der von Ihrer Benutzeroberfläche genutzt wird.

Sie finden diesen Code, indem Sie oben rechts im Playground auf die Schaltfläche „Code anzeigen“ klicken:

Und Sie verwenden die Endpunkte und API-Schlüssel, um die im Code erforderliche Umgebungsvariable ES_API_KEY zu generieren.

Für dieses spezielle Beispiel lautet der Code wie folgt:

Damit es mit Ollama funktioniert, müssen Sie den OpenAI-Client so ändern, dass er eine Verbindung zum Ollama-Server statt zum OpenAI-Server herstellt. Die vollständige Liste der OpenAI-Beispiele und kompatiblen Endpunkte finden Sie hier.

Und ändern Sie das Modell auch in llama3.2, wenn Sie die Vervollständigungsmethode aufrufen:

Fügen wir unsere Frage hinzu: Kann ich Clonazepam ohne Rezept kaufen? Zur Elasticsearch-Abfrage:

Und auch zum Abschlussaufruf mit einigen Ausdrucken, damit wir bestätigen können, dass wir die Elasticsearch-Ergebnisse als Teil des Fragenkontexts senden:

Lassen Sie uns nun den Befehl ausführen

pip install -qU elasticsearch openai

python main.py

Sie sollten ungefähr Folgendes sehen:

Fazit

In diesem Artikel können wir die Leistungsfähigkeit und Vielseitigkeit von Tools wie Ollama sehen, wenn wir sie zusammen mit der Elasticsearch-Inferenz-API und Playground verwenden.

Nach einigen einfachen Schritten hatten wir eine funktionierende RAG-Anwendung mit einem Chat, der ein LLM verwendete, das kostenlos in unserer eigenen Infrastruktur lief. Dies ermöglicht uns außerdem eine bessere Kontrolle über Ressourcen und vertrauliche Informationen und gibt uns außerdem Zugriff auf eine Vielzahl von Modellen für unterschiedliche Aufgaben.

Hier ist ein Diagramm, das zeigt, was wir in diesem Tutorial konfigurieren werden:

Einrichten der lokalen Inferenz mit Ollama

Ollama ist eine hervorragende Möglichkeit, schnell eine kuratierte Auswahl an Open-Source-Modellen für lokale Inferenztests auszuprobieren, und ein beliebtes Werkzeug für KI-Entwickler.

Ausführen von Ollama bare metal

Eine lokale Installation auf Mac, Linux oder Windows ist der einfachste Weg, um lokale GPU-Funktionen zu nutzen, insbesondere für Nutzer mit Apple-Chips der M-Serie. Sobald Sie Ollama installiert haben, können Sie DeepSeek R1 mit dem folgenden Befehl herunterladen und ausführen.

Vielleicht möchten Sie die Parametergröße an Ihre Hardware anpassen. Verfügbare Größen finden Sie hier.

Sie können im Terminal mit dem Modell chatten, aber das Modell läuft auch dann weiter, wenn Sie den Befehl mit Strg+d verlassen oder „/bye“ eingeben. Um zu sehen, ob das Modell noch läuft, geben Sie Folgendes ein:

Ollama in einem Container ausführen

Der schnellste alternative Weg zum Ausführen von Ollama ist die Nutzung einer Container-Engine wie Docker. Die Nutzung der GPU Ihres lokalen Rechners ist je nach Umgebung nicht immer einfach, aber eine schnelle Testeinrichtung ist nicht schwer, solange Ihr Container über genügend RAM und Speicherplatz für die Multi-GB-Modelle verfügt.

Das Einrichten und Ausführen von Ollama in Docker ist so einfach wie der Befehl:

Dies erstellt ein Verzeichnis namens „Ollama“ im aktuellen Verzeichnis und verankert es im Container, um die Ollama-Konfiguration sowie die Modelle zu speichern. Je nach Anzahl der verwendeten Parameter können diese eine Größe von einigen GB bis zu Dutzenden von GB haben, daher sollten Sie ein Laufwerk mit ausreichend freiem Speicherplatz wählen.

Hinweis: Wenn Sie eine Nvidia-GPU in Ihrem Computer haben, installieren Sie unbedingt das Nvidia Container-Toolkit und fügen Sie dem obigen Befehl zum Ausführen von Docker „--gpus=all“ hinzu.

Sobald der Ollama-Container auf Ihrem Rechner läuft, können Sie ein Modell wie DeepSeek R1 mit folgendem Befehl abrufen:

Ähnlich wie beim Bare-Metal-Ansatz möchten Sie möglicherweise die Parametergröße ändern, um sie an Ihre Hardware anzupassen. Verfügbare Größen finden Sie unter https://ollama.com/library/deepseek-r1.

Sobald das Herunterladen des Modells abgeschlossen ist, können Sie „/bye“ eingeben, um die Eingabeaufforderung zu beenden. So überprüfen Sie, ob das Modell noch ausgeführt wird:

Testen unserer lokalen Inferenz mit einem Curl

Um die lokale Inferenz mit cURL zu testen, können Sie den folgenden Befehl ausführen. Wir verwenden stream:false, damit wir die narrative JSON-Reaktion leicht lesen können:

Testen von „OpenAI-kompatiblem“ Ollama und einer RAG-Eingabeaufforderung

Praktischerweise bietet Ollama auch einen REST-Endpoint, der das Verhalten von OpenAI nachahmt, um die Kompatibilität mit einer Vielzahl von Tools, einschließlich Kibana, zu gewährleisten.

Das Testen dieser komplexeren Eingabeaufforderung führt zu Inhalten, die einen <think>-Abschnitt enthalten, in dem das Modell darauf trainiert wurde, das Problem zu durchdenken.

Ollama mit Kibana verbinden

Eine großartige Möglichkeit, Elasticsearch zu nutzen, ist das „start-local“-Entwicklungsskript.

Stellen Sie sicher, dass Kibana und Elasticsearch Ihr Ollama im Netzwerk erreichen können. Wenn Sie ein lokales Container-Setup des Elastic Stack verwenden, bedeutet dies möglicherweise, dass Sie „localhost“ durch „host.docker.internal“ oder „host.containers.internal“ ersetzen müssen, um einen Netzwerkpfad zum gehosteten Computer zu erhalten.

Navigieren Sie in Kibana zu Stack Management > Alerts and Insights > Connectors.

Was tun, wenn Sie diese allgemeine Setup-Warnung sehen?

Sie müssen sicherstellen, dass der xpack.encryptedSavedObjects.encryptionKey korrekt eingestellt ist. Dies ist ein häufig übersehener Schritt bei der lokalen Docker-Installation von Kibana, daher liste ich die Schritte zur Behebung in der Docker-Syntax auf.

Stellen Sie sicher, dass Sie Ihr Kibana/Konfig-Verzeichnis dauerhaft speichern, damit Änderungen erhalten bleiben, wenn der Container heruntergefahren wird. Meine Kibana-Container-Laufwerke sehen in der docker-compose.yml folgendermaßen aus:

Jetzt können Sie den Keystore erstellen und einen Wert eingeben, damit die Verbindungsschlüssel nicht im Klartext gespeichert werden.

Starten Sie Ihren gesamten Cluster vollständig neu, um sicherzustellen, dass die Änderungen wirksam werden.

Erstellen des Connectors

Erstellen Sie auf dem Connector-Konfigurationsbildschirm (navigieren Sie in Kibana zu Stack Management > Alerts and Insights > Connectors) einen Connector und wählen Sie den Typ „OpenAI“ aus.

Konfigurieren Sie den Connector mit den folgenden Einstellungen:

• Name des Connectors: Deepseek (Ollama)

• Wählen Sie einen OpenAI-Anbieter aus: andere (OpenAI-kompatibler Dienst)

• URL: http://localhost:11434/v1/chat/completions

  • Passen Sie den richtigen Pfad zu Ihrem Ollama an. Denken Sie daran, host.docker.internal oder ein Äquivalent zu ersetzen, wenn Sie aus einem Container heraus aufrufen.

• Standardmodell: deepseek-r1:7b

• API-Schlüssel: Denken Sie sich etwas aus, ein Eintrag ist erforderlich, aber der Wert spielt keine Rolle

Beachten Sie, dass das Testen eines benutzerdefinierten Connectors zu Ollama im Connector-Setup derzeit in 8.17 nicht funktioniert, aber in der nachfolgenden Kibana-Version 8.18 behoben wurde.

Unser Connector sieht so aus:

Vektoreingebettete Daten in Elasticsearch einlesen

Wenn Sie bereits mit Playground vertraut sind und Daten eingerichtet haben, können Sie zum nächsten Playground-Schritt übergehen. Wenn Sie jedoch einige schnelle Testdaten benötigen, müssen wir sicherstellen, dass unsere _inference-APIs eingerichtet sind. Ab Version 8.17 sind die Zuweisungen für Machine Learning dynamisch, sodass wir zum Herunterladen und Aktivieren des mehrsprachigen e5-Vektors nur Folgendes in den Kibana Dev-Tools ausführen müssen.

Wenn Sie dies noch nicht getan haben, wird das Herunterladen des e5-Modells aus den Modell-Repositorys von Elastic ausgelöst.

Als Nächstes laden wir ein gemeinfreies Buch als unseren RAG-Kontext hoch. Hier können Sie „Alice im Wunderland“ von Project Gutenberg herunterladen: Link. Speichern Sie es als .txt-Datei.

Navigieren Sie zu Elasticsearch > Home > Datei hochladen

Wählen Sie Ihre Textdatei aus oder ziehen Sie sie per Drag & Drop und klicken Sie dann auf die Schaltfläche „Importieren“.

Wählen Sie auf dem Bildschirm „Daten importieren“ die Registerkarte „Erweitert“ und setzen Sie den Indexnamen auf „book_alice“.

Wählen Sie die Option „Zusätzliches Feld hinzufügen“, sie befindet sich klein direkt unter „Automatisch erstellte Felder“. Wählen Sie „Semantisches Textfeld hinzufügen“ und ändern Sie den Inferenz-Endpoint in „.multilingual-e5-small-elasticsearch“. Wählen Sie „Hinzufügen“ und dann „Importieren“.

Wenn das Laden und die Inferenz abgeschlossen sind, können wir zu Playground gehen.

RAG im Playground testen

Navigieren Sie in Kibana zu Elasticsearch > Playground.

Auf dem Playground-Bildschirm sollten Sie ein grünes Häkchen und „LLM Connected“ sehen, das anzeigt, dass ein Connector vorhanden ist. Dies ist der Ollama-Connector, den wir gerade oben erstellt haben. Eine ausführlichere Anleitung für Playground finden Sie hier.

Klicken Sie auf das blaue Symbol „Datenquellen hinzufügen“ und wählen Sie den „book_alice“-Index aus, den wir zuvor erstellt haben, oder einen anderen Index, den Sie zuvor konfiguriert haben und der Inferenz-APIs für Einbettungen verwendet.

DeepSeek ist ein Gedankenkettenmodell mit starken Ausrichtungsmerkmalen. Aus der RAG-Perspektive heraus ist dies sowohl gut als auch schlecht. Das Gedankenkettentraining kann DeepSeek dabei helfen, scheinbar widersprüchliche Aussagen in Zitaten zu rationalisieren, aber die starke Ausrichtung auf Trainingswissen kann auch dazu führen, dass es seine eigene Version der Weltfakten unserer Kontextgrundlage vorzieht. Diese starke Ausrichtung ist zwar gut gemeint, erschwert jedoch bekanntermaßen die Unterweisung von LLMs bei der Erörterung von Themen, bei denen unser privates Wissen im Trainingsdatensatz eingeschränkt oder nicht gut repräsentiert ist.

In unserem Playground-Setup haben wir folgende Systemvorgabe eingetragen: „Sie sind ein Assistent für Frage-Antwort-Aufgaben anhand relevanter Textstellen aus dem Buch „Alice im Wunderland““ und die anderen Vorgaben übernommen.

Auf die Frage „Wer war bei der Teeparty?“ erhalten wir die Antwort: „Der Märzhase, der Hutmacher und die Haselmaus waren bei der Teeparty. [Zitat: Position 1 und 2]“, was korrekt ist.

Anhand der <think>-Tags können wir erkennen, dass DeepSeek bei der Beantwortung der Fragen definitiv über den Inhalt der Zitate nachgedacht hat.

Testen von Ausrichtungsbeschränkungen

Lassen Sie uns als Test ein intellektuell anspruchsvolles Szenario für DeepSeek erstellen. Wir erstellen einen Index von Verschwörungstheorien, von denen die Trainingsdaten von DeepSeek wissen, dass sie nicht wahr sind.

In den Kibana-Entwicklungstools erstellen wir den folgenden Index und die folgenden Daten:

Diese Verschwörungstheorien werden die Grundlage für unser LLM bilden. Trotz einer aggressiven Systemaufforderung akzeptiert DeepSeek unsere Version der Fakten nicht. Wären wir in einer Situation, in der wir wüssten, dass unsere privaten Daten vertrauenswürdiger, fundierter oder auf die Bedürfnisse unserer Organisation abgestimmt sind, wäre dies nicht akzeptabel:

Zur Testfrage „Sind Vögel echt?“ (Erklärung kenne dein Meme) erhalten wir die Antwort: „Im angegebenen Kontext werden Vögel nicht als real angesehen, aber in Wirklichkeit sind sie echte Tiere. [Kontext: Position 1]“. Dieser Test beweist, dass DeepSeek R1 auch auf der 7B-Parameterebene leistungsstark ist … je nach unserem Datensatz ist es jedoch möglicherweise nicht die beste Wahl für RAG.

Was haben wir also gelernt?

Zusammenfassend:

• Das lokale Ausführen von Modellen in Tools wie Ollama ist eine großartige Möglichkeit, einen Blick auf das Modellverhalten zu werfen.

• DeepSeek R1 ist ein Schlussfolgerungsmodell, was bedeutet, dass es für Anwendungsfälle wie RAG Vor- und Nachteile hat.

• Playground ist in der Lage, sich über eine OpenAI-ähnliche REST-API mit Inferenz-Hosting-Frameworks wie Ollama zu verbinden, was in dieser frühen Ära des KI-Hostings zu einem De-facto-Standard wird.

Insgesamt sind wir beeindruckt, wie weit die lokale, „air-gapped“-RAG gekommen ist. Die Tools in Elasticsearch, Kibana und die verfügbaren Open-Weight-Modelle haben sich erheblich weiterentwickelt, seit wir 2023 zum ersten Mal über die datenschutzfreundliche KI-Suche geschrieben haben.

Die Facettensuche ist ein leistungsstarkes Werkzeug in E-Commerce-Plattformen. Es hilft dabei, Suchergebnisse anhand der Eigenschaften der angezeigten Elemente zu organisieren und zu verfeinern. Facetten werden zwar oft mit Filtern verwechselt, funktionieren aber anders. Filter sind feste Attribute, die durch Informationen definiert werden, die immer im Index vorhanden sind, wie zum Beispiel die Kategorie oder das Format eines Produkts. Facetten hingegen sind dynamisch und werden aus den Ergebnissen der ausgeführten Suche generiert.

Stellen Sie sich einen Bekleidungskatalog vor: Felder wie „Kategorie“ (z. B. T-Shirts, Hosen) oder „Geschlecht“ (z. B. männlich, weiblich) sind Filter, die dabei helfen, die Ergebnisse einzugrenzen. Die Facetten spiegeln jedoch spezifische Eigenschaften der in den Ergebnissen angezeigten Produkte wider, wie z. B. gängige Farben, verfügbare Größen oder Materialien. Dies ermöglicht ein anpassungsfähigeres und kontextbezogeneres Sucherlebnis.

Unten sehen Sie ein Bild, auf dem wir mit einem Filter interagieren und die danach gefilterten Suchergebnisse sehen können.

Wie KI die Facettengenerierung verbessern kann

Künstliche Intelligenz wird oft mit semantischer Suche und Einbettungen in Verbindung gebracht, aber was ist mit Facetten? Wie kann KI genutzt werden, um Facetten für jede Suche nützlicher und kontextspezifischer zu gestalten?

Eine interessante Möglichkeit besteht darin, mithilfe von KI neue Kategorisierungen zu erstellen, die über die traditionellen Klassifizierungen im Index hinausgehen. Durch die Analyse spezifischer Merkmale des Inhalts können diese neuen Kategorien eine reichhaltigere und präzisere Kontextualisierung ermöglichen, wodurch die einzelnen Aspekte relevanter und besser auf die Bedürfnisse der Nutzer abgestimmt werden. Dies ermöglicht eine aussagekräftigere Verfeinerung der Ergebnisse im Vergleich zu den ursprünglichen Dokumentenkategorien.

Wie KI die Filmklassifizierung für bessere Suchergebnisse verfeinern kann

Lassen Sie uns die folgenden Filme analysieren, die alle aktuell dem Genre Drama zugeordnet sind:

• Requiem für einen Traum Zusammenfassung: Die drogeninduzierten Utopien von vier Bewohnern von Coney Island zerbrechen, als ihre Sucht immer tiefer wird.

• Amerikanische Schönheit Zusammenfassung: Ein sexuell frustrierter Vorstadtvater gerät in eine Midlife-Crisis, nachdem er sich in die beste Freundin seiner Tochter verliebt hat.

• Good Will Hunting Kurzfassung: Will Hunting, ein Hausmeister am MIT, hat ein Talent für Mathematik, braucht aber die Hilfe eines Psychologen, um in seinem Leben eine Richtung zu finden.

Diese Genreklassifizierung erfasst weder die subtilen Unterschiede noch die einzigartigen Kontexte der einzelnen Filme. Durch den Einsatz von KI zur Analyse von Inhaltsangaben und zentralen Themen können wir neue Kategorien erstellen, die den wahren Kontext jedes Films besser widerspiegeln. Zum Beispiel:

• Requiem für einen Traum – Neue Kategorie: „Sucht und Abhängigkeit“

• American Beauty – Neue Kategorie: „Midlife-Crisis“

• Good Will Hunting – Neue Kategorie: „Intellektueller Kampf“

Durch diese neuen Kategorien werden die Suchergebnisse wesentlich präziser und bieten den Nutzern gleichzeitig aussagekräftigere Filter zur Verfeinerung ihrer Ergebnisse. Dieser Ansatz ist besonders effektiv, wenn die ursprünglichen Kategorien zu allgemein gehalten sind, da er es den Nutzern ermöglicht, leichter genau das zu finden, wonach sie suchen.

Erstellen neuer Kategorien mit GPT-4: Beispiel für die Facettensuche

In diesem Beispiel zeigen wir, wie ein KI-Modell verwendet werden kann, um neue Filmkategorien zu erstellen, die präziser sind und besser auf den Kontext des jeweiligen Werkes abgestimmt sind. Um diesen Prozess zu demonstrieren, werden wir die Elastic-Simulationspipeline zusammen mit dem OpenAI-Inferenzdienst verwenden. Es wird eine Pipeline mit mehreren Prozessoren erstellt, darunter der Skriptprozessor, der für die Erstellung der Eingabeaufforderung zuständig ist, die im Inferenzprozessor ausgeführt werden soll und die neuen Kategorien bestimmen kann. Die anderen Prozessoren werden verwendet, um die während der Pipeline-Ausführung erzeugten Daten und Hilfsfelder zu bearbeiten. Erwähnenswert ist, dass diese Logik auch auf andere ähnliche Werkzeuge oder Modelle angewendet werden kann.

Als erstes müssen wir den Inferenz-Endpunkt erstellen, in dem wir den Dienst als OpenAI, das für den Zugriff auf den Dienst erforderliche Token und das Modell definieren. In diesem Beispiel verwende ich gpt-4o-mini. Für weitere Details zum OpenAI-Inferenzdienst klicken Sie hier.

Nachdem der Endpunkt erstellt wurde, können wir ihn nun verwenden, um die neuen Kategorien zu erstellen. Nachfolgend finden Sie eine Pipeline, die den gesamten Prozess der Dokumentendatenmanipulation und der Generierung von Eingabeaufforderungen übernimmt. Ich werde die Funktion jedes Prozessors im Detail erläutern.

Der erste Prozessor ist für die Erstellung der Eingabeaufforderung zuständig. Es ist sehr wichtig, die Anweisungen klar und detailliert zu formulieren, damit die KI die Themen korrekt analysieren und identifizieren kann. In dieser Aufgabenstellung bitte ich um zwei Themen, die auf der Analyse von Titel, Beschreibung und Genre der Filme basieren.

Die nächste Pipeline ist die Inferenzpipeline. Sie empfängt die Eingabeaufforderung und sendet sie an unseren generate_topics_ia- Endpunkt. Die vom Modell generierte Antwort wird im Ergebnisfeld gespeichert.

Als Nächstes werden 3 Prozessoren verwendet, um die Antwort zu bearbeiten und sie im Themenfeld festzulegen, zusätzlich zum Entfernen temporärer Felder, die ich erstellt habe.

Bei der Ausführung dieser Pipeline erhalten wir die folgenden Ergebnisse:

Beachten Sie, dass wir neue Kategorien haben, die stärker mit dem Kontext der Filme zusammenhängen, auch wenn einige ursprünglich aus demselben Genre stammen.

Wir können diese neuen Kategorien nun verwenden und sie zusammen mit dem Dokument indexieren. Auf diese Weise erhalten wir bei der Erstellung der Facetten neben der Hauptkategorie auch spezifischere Unterkategorien, die auf den Kontext der Filme abgestimmt sind.

Darüber hinaus ist es möglich, diese neuen Kategorien zu vektorisieren und sie in Vektorsuchen zu verwenden. Dies bedeutet, dass die neuen Kategorien nicht nur als Filter dienen, sondern auch zur Berechnung semantischer Ähnlichkeiten mit den Suchbegriffen verwendet werden können, wodurch die Relevanz der präsentierten Ergebnisse weiter erhöht wird.

Vollständige Pipeline:

Fazit

Der Einsatz von KI zur Verbesserung der Suchergebnisse kann das Sucherlebnis grundlegend verändern, indem die Ergebnisse spezifischer und kontextbezogener werden. Im Gegensatz zu festen Kategorien, die oft sehr allgemein gehalten sind, können KI-generierte Kategorien den Kontext besser widerspiegeln. Wenn wir beispielsweise Filme neu klassifizieren, können wir Kontextinformationen erfassen, die in den primären Kategorien fehlen, und so viel relevantere Gruppierungen vornehmen.

Diese neuen Kategorien können dem Index hinzugefügt werden, um nicht nur die Facettierung zu verbessern, sondern auch Vektorsuchen zu ermöglichen. Das Ergebnis ist ein effizienteres Sucherlebnis mit Filtern, die besser auf den Kontext abgestimmt sind.

Referenzen

https://www.elastic.co/guide/en/elasticsearch/reference/current/infer-service-openai.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/simulate-pipeline-api.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/script-processor.html

Der sofort einsatzbereite Semantic Kernel Elasticsearch Vector Store Connector unterstützt die Abstraktionen des Semantic Kernel Vector Stores , was es Entwicklern sehr einfach macht, Elasticsearch als Vector Store beim Erstellen von KI-Agenten einzubinden.

Elasticsearch hat eine starke Verankerung in der Open-Source-Community und hat vor Kurzem die AGPL-Lizenz übernommen. In Kombination mit dem Open-Source-Microsoft Semantic Kernel bieten diese Tools eine leistungsstarke, unternehmensgerechte Lösung. Sie können lokal beginnen, indem Sie Elasticsearch in wenigen Minuten mit diesem Befehl curl -fsSL https://elastic.co/start-local | sh starten (siehe start-local für Details) und dann auf Cloud-gehostete oder selbstgehostete Versionen umsteigen, während Sie Ihre KI-Agenten produktiv einsetzen.

In diesem Blogbeitrag zeigen wir Ihnen, wie Sie den Semantic Kernel Elasticsearch Vector Store Connector in Verbindung mit Semantic Kernel verwenden. Eine Python-Version des Konnektors wird zu einem späteren Zeitpunkt verfügbar sein.

Szenario auf hoher Ebene: Entwicklung einer RAG-Anwendung mit Semantic Kernel und Elasticsearch

Im folgenden Abschnitt gehen wir ein Beispiel durch. Im Wesentlichen entwickeln wir eine RAG-Anwendung (Retrieval Augmented Generation), die eine Frage des Benutzers als Eingabe entgegennimmt und eine Antwort zurückgibt. Wir verwenden Azure OpenAI (ein lokales LLM kann ebenfalls verwendet werden) als LLM, Elasticsearch als Vektorspeicher und Semantic Kernel (.net) als Framework, um alle Komponenten miteinander zu verbinden.

Falls Sie mit RAG-Architekturen nicht vertraut sind, können Sie sich mit diesem Artikel eine kurze Einführung verschaffen: https://www.elastic.co/search-labs/blog/retrieval-augmented-generation-rag.

Die Antwort wird vom LLM generiert, der mit Kontextinformationen gespeist wird, die für die Frage relevant sind und aus dem Elasticsearch-Vektorspeicher abgerufen werden. Die Antwort enthält auch die Quelle, die vom LLM als Kontext verwendet wurde.

RAG-Beispiel

In diesem konkreten Beispiel entwickeln wir eine Anwendung, die es Benutzern ermöglicht, Fragen zu Hotels zu stellen, die in einer internen Hoteldatenbank gespeichert sind. Der Benutzer könnte z.B. Suchen Sie nach einem bestimmten Hotel anhand verschiedener Kriterien oder fordern Sie eine Liste von Hotels an.

Für die Beispieldatenbank haben wir eine Liste von Hotels mit 100 Einträgen generiert. Die Stichprobengröße ist bewusst klein gehalten, damit Sie die Konnektordemo so einfach wie möglich ausprobieren können. In einer realen Anwendung würde der Elasticsearch-Connector seine Vorteile gegenüber anderen Optionen, wie der `InMemory`-Vektorspeicherimplementierung, insbesondere bei der Arbeit mit extrem großen Datenmengen zeigen.

Die vollständige Demo-Anwendung finden Sie im Elasticsearch Vector Store Connector- Repository.

Beginnen wir damit, die erforderlichen NuGet-Pakete und die verwendeten Direktiven zu unserem Projekt hinzuzufügen:

Wir können nun unser Datenmodell erstellen und es mit semantischen Kernel-spezifischen Attributen ausstatten, um das Speichermodellschema und einige Hinweise für die Textsuche zu definieren:

Die Attribute des Speichermodellschemas (`VectorStore*`) sind für die tatsächliche Verwendung des Elasticsearch Vector Store Connectors am relevantesten, nämlich:

• VectorStoreRecordKey Eine Eigenschaft einer Datensatzklasse als Schlüssel zu kennzeichnen, unter dem der Datensatz in einem Vektorspeicher abgelegt wird.

• VectorStoreRecordData Eine Eigenschaft einer Datensatzklasse als 'Daten' kennzeichnen.

• VectorStoreRecordVector Eine Eigenschaft einer Datensatzklasse als Vektor kennzeichnen.

Alle diese Attribute akzeptieren verschiedene optionale Parameter, mit denen das Speichermodell weiter angepasst werden kann. Im Fall von VectorStoreRecordKey ist es beispielsweise möglich, eine andere Distanzfunktion oder einen anderen Indextyp anzugeben.

Die Textsuchattribute (TextSearch*) werden im letzten Schritt dieses Beispiels wichtig sein. Wir werden später auf sie zurückkommen.

Im nächsten Schritt initialisieren wir die Semantic Kernel Engine und erhalten Referenzen zu den Kerndiensten. In einer realen Anwendung sollte Dependency Injection anstelle des direkten Zugriffs auf die Service-Collection verwendet werden. Dasselbe gilt für die fest codierte Konfiguration und die Geheimnisse, die stattdessen mithilfe eines Konfigurationsanbieters gelesen werden sollten:

Der Dienst vectorStoreCollection kann nun verwendet werden, um die Sammlung zu erstellen und einige Demodatensätze einzulesen:

Dies zeigt, wie Semantic Kernel die Verwendung eines Vektorspeichers mit all seiner Komplexität auf wenige einfache Methodenaufrufe reduziert.

Im Hintergrund wird in Elasticsearch ein neuer Index erstellt und alle notwendigen Eigenschaftszuordnungen werden angelegt. Unser Datensatz wird dann vollständig transparent in das Speichermodell abgebildet und schließlich im Index gespeichert. Nachfolgend sehen Sie, wie die Zuordnungen in Elasticsearch aussehen.

Die embeddings.GenerateEmbeddingsAsync() -Aufrufe riefen transparent den konfigurierten Azure AI Embeddings Generation-Dienst auf.

Noch mehr Magie lässt sich im letzten Schritt dieser Demonstration beobachten.

Mit nur einem einzigen Aufruf von InvokePromptAsync werden alle folgenden Operationen ausgeführt, wenn der Benutzer eine Frage zu den Daten stellt:

1. Es wird eine Einbettung für die Frage des Benutzers generiert.

2. Der Vektorspeicher wird nach relevanten Einträgen durchsucht.

3. Die Ergebnisse der Abfrage werden in eine Eingabeaufforderungsvorlage eingefügt.

4. Die eigentliche Anfrage in Form der finalen Eingabeaufforderung wird an den KI-Chatvervollständigungsdienst gesendet.

Erinnern Sie sich an die TextSearch* -Attribute, die wir zuvor in unserem Datenmodell definiert haben? Mithilfe dieser Attribute können wir in unserer Eingabeaufforderungsvorlage entsprechende Platzhalter verwenden, die automatisch mit den Informationen aus unseren Einträgen im Vektorspeicher befüllt werden.

Die endgültige Antwort auf unsere Frage „Bitte zeigen Sie mir alle Hotels mit einer Dachterrassenbar“ lautet wie folgt:

Die Antwort bezieht sich korrekt auf den folgenden Eintrag in unserer hotels.csv-Datei.

Dieses Beispiel zeigt sehr gut, wie die Verwendung des Microsoft Semantic Kernel durch seine durchdachten Abstraktionen eine signifikante Reduzierung der Komplexität ermöglicht und gleichzeitig ein sehr hohes Maß an Flexibilität gewährleistet. Durch die Änderung einer einzigen Codezeile können beispielsweise der Vektorspeicher oder die verwendeten KI-Dienste ersetzt werden, ohne dass ein anderer Teil des Codes umstrukturiert werden muss.

Gleichzeitig bietet das Framework eine enorme Menge an High-Level-Funktionalität, wie zum Beispiel die Funktion `InvokePrompt` oder das Template- oder Such-Plugin-System.

Die vollständige Demo-Anwendung finden Sie im Elasticsearch Vector Store Connector-Repository.

Was ist sonst noch mit Elasticsearch möglich?

• Elasticsearch: Neues semantisches Textmapping: Vereinfachung der semantischen Suche

• Semantisches Reranking in Elasticsearch mit Retrievern

• Erweiterte RAG-Techniken Teil 1: Datenverarbeitung

• Fortgeschrittene RAG-Techniken Teil 2: Abfragen und Testen

• RAG mit Llama 3 Open-Source und Elastic erstellen

• Eine Anleitung zum Erstellen eines lokalen Agenten mit LangGraph, LLaMA3 und dem Elasticsearch-Vektorspeicher von Grund auf

Elasticsearch & Semantic Kernel: Was kommt als Nächstes?

• Wir haben gezeigt, wie der Elasticsearch-Vektorspeicher beim Erstellen von GenAI-Anwendungen in .NET einfach in den Semantic Kernel eingebunden werden kann. Seien Sie gespannt auf die nächste Python-Integration.

• Da Semantic Kernel Abstraktionen für fortgeschrittene Suchfunktionen wie die Hybridsuche erstellt, ermöglicht Elasticsearch Connect .NET-Entwicklern die einfache Implementierung dieser Funktionen bei der Verwendung von Semantic Kernel.

• Führen Sie eine Diskussion mit LLMs, indem Sie ein ChatLanguageModel und ein ChatMemory

• Die Chat-Historie wird im Speicher gehalten, um den Kontext einer früheren Diskussion mit einem LLM wieder abrufen zu können.

Dieser Blogbeitrag erklärt, wie man:

• Vektor-Einbettungen aus Textbeispielen erstellen

• Vektoreinbettungen im Elasticsearch-Einbettungsspeicher speichern

• Suche nach ähnlichen Vektoren

Einbettungen erstellen

Um Einbettungen zu erstellen, müssen wir ein EmbeddingModel definieren, das verwendet werden soll. Wir können beispielsweise dasselbe Mistral-Modell verwenden, das wir im vorherigen Beitrag verwendet haben. Es lief mit ollama:

Ein Modell ist in der Lage, aus Text Vektoren zu generieren. Hier können wir die Anzahl der vom Modell generierten Dimensionen überprüfen:

Um Vektoren aus einem Text zu generieren, können wir Folgendes verwenden:

Oder wenn wir auch Metadaten bereitstellen möchten, um nach Dingen wie Text, Preis, Veröffentlichungsdatum oder Ähnlichem filtern zu können, können wir Metadata.from() verwenden. Zum Beispiel fügen wir hier den Spielnamen als Metadatenfeld hinzu:

Wenn Sie diesen Code ausführen möchten, sehen Sie sich bitte die Klasse Step5EmbedddingsTest.java an.

Elasticsearch hinzufügen, um unsere Vektoren zu speichern

LangChain4j bietet einen In-Memory-Embedding-Speicher. Dies ist nützlich, um einfache Tests durchzuführen:

Bei deutlich größeren Datensätzen funktioniert das natürlich nicht, da dieser Datenspeicher alles im Arbeitsspeicher ablegt und wir auf unseren Servern nicht über unbegrenzten Speicherplatz verfügen. Wir könnten unsere Einbettungen also stattdessen in Elasticsearch speichern, das per Definition "elastisch" ist und mit Ihren Daten skalieren kann. Dazu fügen wir Elasticsearch zu unserem Projekt hinzu:

Wie Sie bemerkt haben, haben wir dem Projekt auch das Elasticsearch TestContainers-Modul hinzugefügt, sodass wir eine Elasticsearch-Instanz aus unseren Tests heraus starten können:

Um Elasticsearch als Einbettungsspeicher zu verwenden, müssen Sie „nur“ vom LangChain4j-In-Memory-Datenspeicher zum Elasticsearch-Datenspeicher wechseln:

Dadurch werden Ihre Vektoren in Elasticsearch in einem default -Index gespeichert. Sie können den Indexnamen auch in einen aussagekräftigeren Namen ändern:

Wenn Sie diesen Code ausführen möchten, sehen Sie sich bitte die Klasse Step6ElasticsearchEmbedddingsTest.java an.

Suche nach ähnlichen Vektoren

Um nach ähnlichen Vektoren zu suchen, müssen wir zunächst unsere Frage mithilfe des gleichen Modells, das wir zuvor verwendet haben, in eine Vektordarstellung umwandeln. Das haben wir schon gemacht, also ist es nicht schwer, das noch einmal zu tun. Beachten Sie, dass wir in diesem Fall die Metadaten nicht benötigen:

Wir können mit dieser Repräsentation unserer Frage eine Suchanfrage erstellen und den Embedding-Speicher bitten, die ersten Top-Vektoren zu finden:

Wir können die Ergebnisse nun durchlaufen und einige Informationen ausgeben, wie zum Beispiel den Spielnamen, der aus den Metadaten stammt, und die Punktzahl:

Wie zu erwarten, ist „Out Run“ der erste Treffer:

Wenn Sie diesen Code ausführen möchten, sehen Sie sich bitte die Klasse Step7SearchForVectorsTest.java an.

Hinter den Kulissen

Die Standardkonfiguration für den Elasticsearch Embedding Store verwendet im Hintergrund die approximative kNN-Abfrage .

Dies könnte jedoch geändert werden, indem dem Embedding-Speicher eine andere Konfiguration (ElasticsearchConfigurationScript) als die Standardkonfiguration (ElasticsearchConfigurationKnn) bereitgestellt wird:

Die ElasticsearchConfigurationScript -Implementierung führt im Hintergrund eine script_score -Abfrage mit einer cosineSimilarity -Funktion aus.

Grundsätzlich gilt beim Aufruf:

Dies nennt man nun:

In diesem Fall ändert sich das Ergebnis hinsichtlich der "Ordnung" nicht, sondern nur die Punktzahl wird angepasst, da der cosineSimilarity -Aufruf keine Näherung verwendet, sondern den Kosinus für jeden der übereinstimmenden Vektoren berechnet:

Wenn Sie diesen Code ausführen möchten, sehen Sie sich bitte die Klasse Step7SearchForVectorsTest.java an.

Fazit

Wir haben behandelt, wie einfach Sie Einbettungen aus Ihrem Text generieren können und wie Sie die nächsten Nachbarn in Elasticsearch speichern und suchen können, und zwar mit zwei verschiedenen Ansätzen:

• Verwendung der approximativen und schnellen knn -Abfrage mit der Standardoption ElasticsearchConfigurationKnn

• Verwendung der exakten, aber langsameren script_score -Abfrage mit der ElasticsearchConfigurationScript -Option

Im nächsten Schritt geht es darum, eine vollständige RAG-Anwendung zu entwickeln, basierend auf dem, was wir hier gelernt haben.

LangChain4j bietet eine standardisierte Methode, um:

• Einbettungen (Vektoren) aus einem gegebenen Inhalt erstellen, beispielsweise aus einem Text

• Einbettungen in einem Einbettungsspeicher speichern

• Suche nach ähnlichen Vektoren im Einbettungsspeicher

• mit LLMs sprechen

• Nutzen Sie die Chat-Speicherfunktion, um sich an den Kontext einer Diskussion mit einem LLM zu erinnern.

Diese Liste ist nicht vollständig, und die LangChain4j-Community implementiert ständig neue Funktionen.

Dieser Beitrag behandelt die ersten Hauptbestandteile des Frameworks.

Hinzufügen von LangChain4j OpenAI zu unserem Projekt

Wie bei allen Java-Projekten ist es einfach eine Frage der Abhängigkeiten. Hier verwenden wir Maven, aber das gleiche Ergebnis ließe sich auch mit jedem anderen Abhängigkeitsmanager erzielen.

Als ersten Schritt für das Projekt, das wir hier aufbauen wollen, werden wir OpenAI verwenden, daher müssen wir lediglich das langchain4j-open-ai -Artefakt hinzufügen:

Für den restlichen Code verwenden wir entweder unseren eigenen API-Schlüssel, den Sie durch die Registrierung eines Kontos bei OpenAI erhalten, oder den vom LangChain4j-Projekt bereitgestellten Schlüssel, der jedoch nur zu Demonstrationszwecken dient:

Wir können nun eine Instanz unseres ChatLanguageModel erstellen:

Und schließlich können wir eine einfache Frage stellen und die Antwort erhalten:

Die gegebene Antwort könnte etwa so lauten:

Wenn Sie diesen Code ausführen möchten, sehen Sie sich bitte die Klasse Step1AiChatTest.java an.

Mehr Kontext mit langchain4j

Fügen wir das langchain4j -Artefakt hinzu:

Dieses Tool bietet uns einen Werkzeugkasten, der uns dabei helfen kann, eine fortgeschrittenere LLM-Integration für unseren Assistenten zu entwickeln. Hier erstellen wir einfach eine Assistant -Schnittstelle, die die chat -Methode bereitstellt, welche automatisch die zuvor definierte ChatLanguageModel aufruft:

Wir müssen lediglich die Klasse LangChain4j AiServices bitten, eine Instanz für uns zu erstellen:

Und rufen Sie dann die Methode chat(String) auf:

Das System verhält sich genauso wie zuvor. Warum also haben wir den Code geändert? Erstens ist es eleganter, aber darüber hinaus können Sie dem LLM nun mithilfe einfacher Annotationen Anweisungen geben:

Dies ergibt nun Folgendes:

Wenn Sie diesen Code ausführen möchten, sehen Sie sich bitte die Klasse Step2AssistantTest.java an.

Wechsel zu einem anderen LLM: langchain4j-ollama

Wir können das großartige Ollama-Projekt nutzen. Es ist hilfreich, einen LLM lokal auf Ihrem Rechner auszuführen.

Fügen wir das langchain4j-ollama -Artefakt hinzu:

Da wir den Beispielcode mithilfe von Tests ausführen, fügen wir unserem Projekt Testcontainers hinzu:

Wir können jetzt Docker-Container starten/stoppen:

Wir müssen lediglich das model -Objekt in ein OllamaChatModel ändern, anstatt des zuvor verwendeten OpenAiChatModel :

Beachten Sie, dass das Abrufen des Bildes mit dem zugehörigen Modell einige Zeit in Anspruch nehmen kann, aber nach einer Weile erhalten Sie die Antwort:

Besser mit Speicher

Wenn wir mehrere Fragen stellen, merkt sich das System standardmäßig nicht die vorherigen Fragen und Antworten. Wenn wir also nach der ersten Frage „Wann wurde er geboren?“ fragen, Unsere Anwendung wird folgende Fragen beantworten:

Das ist Unsinn. Stattdessen sollten wir Chat Memory verwenden:

Die erneute Beantwortung derselben Fragen liefert nun ein aussagekräftiges Ergebnis:

Fazit

Im nächsten Beitrag werden wir herausfinden, wie wir mithilfe von Elasticsearch als Einbettungsspeicher Fragen an unseren privaten Datensatz stellen können. Das wird uns die Möglichkeit geben, unsere Anwendungssuche auf die nächste Stufe zu heben.

Willkommen zu Teil 2 unseres Artikels über fortgeschrittene RAG-Techniken! Im ersten Teil dieser Serie haben wir die Datenverarbeitungskomponenten der erweiterten RAG-Pipeline eingerichtet, besprochen und implementiert:

In diesem Teil werden wir mit dem Abfragen und Testen unserer Implementierung fortfahren. Kommen wir gleich zur Sache!

Inhaltsverzeichnis

• Suchen und Abrufen, Generieren von Antworten

  • Anreicherung von Suchanfragen mit Synonymen

  • HyDE (Hypothetische Dokumenteneinbettung)

  • Hybrid Search

• Experimente

  • Zusammenfassung der Ergebnisse

  • Test 1: Wer prüft Elastic?

    • AdvancedRAG

    • SimpleRAG

  • Test 2: Gesamtumsatz 2023

    • AdvancedRAG

    • SimpleRAG

  • Test 3: Von welchem Produkt hängt das Wachstum primär ab? Wie viel?

    • AdvancedRAG

    • SimpleRAG

  • Test 4: Beschreiben Sie den Mitarbeitervergütungsplan

    • AdvancedRAG

    • SimpleRAG

  • Test 5: Welche Unternehmen hat Elastic übernommen?

    • AdvancedRAG

    • SimpleRAG

• Fazit

• Anhang

  • Eingabeaufforderungen

    • RAG-Frage-Antwort-Aufforderung

    • Eingabeaufforderung für den Elastic-Abfragegenerator

    • Mögliche Fragen zur Generierung von Anregungen

    • HyDE-Generator-Eingabeaufforderung

  • Beispiel einer hybriden Suchanfrage

Suchen und Abrufen, Generieren von Antworten

Beginnen wir mit unserer ersten Frage, idealerweise einer Information, die hauptsächlich im Jahresbericht zu finden ist. Wie wäre es mit:

Nun wenden wir einige unserer Techniken an, um die Abfrage zu verbessern.

Anreicherung von Suchanfragen mit Synonymen

Zunächst sollten wir die Vielfalt der Abfrageformulierungen erhöhen und sie in eine Form bringen, die sich leicht in eine Elasticsearch-Abfrage verarbeiten lässt. Wir werden GPT-4o zur Hilfe nehmen, um die Abfrage in eine Liste von OR-Klauseln umzuwandeln. Schreiben wir diese Aufgabenstellung auf:

Bei Anwendung auf unsere Anfrage generiert GPT-4o Synonyme der Basisanfrage und verwandtes Vokabular.

In der Klasse ESQueryMaker habe ich eine Funktion definiert, um die Abfrage aufzuteilen:

Seine Aufgabe besteht darin, diese Kette von ODER-Klauseln in eine Liste von Begriffen aufzuteilen, um uns eine Mehrfachübereinstimmung unserer wichtigsten Dokumentfelder zu ermöglichen:

Schließlich komme ich zu folgender Anfrage:

Dies deckt wesentlich mehr Aspekte ab als die ursprüngliche Anfrage und verringert hoffentlich das Risiko, ein Suchergebnis zu verpassen, weil wir ein Synonym vergessen haben. Aber wir können mehr tun.

Zurück nach oben

HyDE (Hypothetische Dokumenteneinbettung)

Lassen Sie uns GPT-4o erneut einsetzen, diesmal zur Implementierung von HyDE.

Die Grundidee von HyDE besteht darin, ein hypothetisches Dokument zu generieren – also ein Dokument, das wahrscheinlich die Antwort auf die ursprüngliche Anfrage enthält. Die sachliche Richtigkeit oder Genauigkeit des Dokuments ist nicht von Belang. Vor diesem Hintergrund formulieren wir nun die folgende Aufgabenstellung:

Da die Vektorsuche typischerweise mit der Kosinusvektorähnlichkeit arbeitet, besteht die Prämisse von HyDE darin, dass wir bessere Ergebnisse erzielen können, indem wir Dokumente mit Dokumenten abgleichen, anstatt Anfragen mit Dokumenten abzugleichen.

Uns geht es um Struktur, Ablauf und Terminologie. Nicht so sehr die Fakten. GPT-4o erzeugt ein HyDE-Dokument wie dieses:

Es sieht ziemlich glaubwürdig aus, wie der ideale Kandidat für die Art von Dokumenten, die wir indexieren möchten. Wir werden dies einbetten und für die hybride Suche verwenden.

Zurück nach oben

Hybrid Search

Dies ist der Kern unserer Suchlogik. Unsere lexikalische Suchkomponente besteht aus den generierten OR-Klauselzeichenketten. Unsere dichte Vektorkomponente wird das eingebettete HyDE-Dokument (auch Suchvektor genannt) sein. Wir verwenden KNN, um effizient mehrere Kandidatendokumente zu identifizieren, die unserem Suchvektor am nächsten liegen. Unsere lexikalische Suchkomponente nennen wir standardmäßig Scoring mit TF-IDF und BM25 . Schließlich werden die lexikalischen und dichten Vektorwerte unter Verwendung des von Wang et al. empfohlenen Verhältnisses von 30/70 kombiniert.

Schließlich können wir eine RAG-Funktion zusammensetzen. Unser Ampelsystem, von der Anfrage bis zur Antwort, folgt diesem Ablauf:

1. Konvertiere die Abfrage in OR-Klauseln.

2. Generieren Sie ein HyDE-Dokument und betten Sie es ein.

3. Übergeben Sie beide Werte als Eingaben an die Hybridsuche.

4. Die Top-n-Ergebnisse abrufen und umkehren, sodass die relevanteste Bewertung im Kontextspeicher des LLM als „aktuellste“ angezeigt wird (Reverse Packing). Beispiel für Reverse Packing: Anfrage: „Elasticsearch-Abfrageoptimierungstechniken“. Abgerufene Dokumente (sortiert nach Relevanz): Umgekehrte Reihenfolge für den LLM-Kontext: Durch die Umkehrung der Reihenfolge erscheint die relevanteste Information (1) zuletzt im Kontext und erhält potenziell mehr Aufmerksamkeit vom LLM bei der Antwortgenerierung.

   1. „Verwenden Sie Boolesche Abfragen, um mehrere Suchkriterien effizient zu kombinieren.“

   2. „Implementieren Sie Caching-Strategien, um die Antwortzeiten von Abfragen zu verbessern.“

   3. „Indexzuordnungen für schnellere Suchleistung optimieren.“

   4. „Indexzuordnungen für schnellere Suchleistung optimieren.“

   5. „Implementieren Sie Caching-Strategien, um die Antwortzeiten von Abfragen zu verbessern.“

   6. „Verwenden Sie Boolesche Abfragen, um mehrere Suchkriterien effizient zu kombinieren.“

5. Übergeben Sie den Kontext zur Generierung an das LLM.

Führen wir unsere Abfrage aus und erhalten wir die Antwort:

Hübsch. Das ist richtig.

Zurück nach oben

Experimente

Jetzt gilt es, eine wichtige Frage zu beantworten. Was hat uns der immense Aufwand und die zusätzliche Komplexität dieser Implementierungen gebracht?

Lasst uns einen kleinen Vergleich anstellen. Die von uns implementierte RAG-Pipeline im Vergleich zur hybriden Basissuche, ohne die von uns vorgenommenen Verbesserungen. Wir werden eine kleine Testreihe durchführen und sehen, ob wir wesentliche Unterschiede feststellen. Wir werden das soeben implementierte RAG-Schema als AdvancedRAG und die Basispipeline als SimpleRAG bezeichnen.

Zusammenfassung der Ergebnisse

Diese Tabelle fasst die Ergebnisse von fünf Tests beider RAG-Pipelines zusammen. Ich habe die relative Überlegenheit der einzelnen Methoden anhand der Detailtiefe und Qualität der Antworten beurteilt, aber dies ist eine rein subjektive Einschätzung. Die tatsächlichen Antworten sind unterhalb dieser Tabelle zu Ihrer Information aufgeführt. Nach dieser Vorrede schauen wir uns nun an, wie sie abgeschnitten haben!

SimpleRAG konnte die Fragen 1 und 5 nicht beantworten. AdvancedRAG ging bei den Fragen 2, 3 und 4 wesentlich detaillierter vor. Aufgrund der detaillierteren Antworten beurteilte ich die Qualität der Antworten von AdvancedRAG als besser.

Prüfen

Frage

AdvancedRAG-Leistung

SimpleRAG Performance

Erweiterte RAG-Latenz

SimpleRAG-Latenz

Gewinner

1

Wer prüft Elastic?

PwC wurde korrekt als Wirtschaftsprüfer identifiziert.

Der Prüfer konnte nicht identifiziert werden.

11,6 Sekunden

4,4 Sekunden

AdvancedRAG

2

Wie hoch waren die Gesamteinnahmen im Jahr 2023?

Die korrekte Umsatzzahl wurde angegeben. Zusätzliche Kontextinformationen wurden mit Umsatzzahlen aus den Vorjahren hinzugefügt.

Die korrekte Umsatzzahl wurde angegeben.

13,3 Sekunden

2,8 Sekunden

AdvancedRAG

3

Von welchem Produkt hängt das Wachstum primär ab? Wie viel?

Elastic Cloud wurde korrekt als Haupttreiber identifiziert. Beinhaltete den Gesamtkontext der Einnahmen und detailliertere Informationen.

Elastic Cloud wurde korrekt als Haupttreiber identifiziert.

14,1 Sekunden

12,8 Sekunden

AdvancedRAG

4

Beschreibung des Mitarbeitervergütungsprogramms

Gab eine umfassende Beschreibung der Altersvorsorgepläne, Gesundheitsprogramme und sonstigen Leistungen. Enthält spezifische Beitragsbeträge für verschiedene Jahre.

Es wurde ein guter Überblick über die Leistungen gegeben, einschließlich Vergütung, Altersvorsorgepläne, Arbeitsumfeld und das Elastic Cares-Programm.

26,6 Sekunden

11,6 Sekunden

AdvancedRAG

5

Welche Unternehmen hat Elastic übernommen?

Die im Bericht erwähnten kürzlich erfolgten Akquisitionen (CmdWatch, Build Security, Optimyze) wurden korrekt aufgeführt. Es wurden einige Anschaffungsdaten und Kaufpreise angegeben.

Es konnten keine relevanten Informationen aus dem bereitgestellten Kontext abgerufen werden.

11,9 Sekunden

2,7 Sekunden

AdvancedRAG

Test 1: Wer prüft Elastic?

AdvancedRAG

SimpleRAG

Zusammenfassung: SimpleRAG hat PwC nicht als Wirtschaftsprüfer identifiziert.

Okay, das ist tatsächlich ziemlich überraschend. Das sieht nach einem Suchfehler seitens SimpleRAG aus. Es wurden keine Dokumente im Zusammenhang mit der Wirtschaftsprüfung gefunden. Lasst uns den Schwierigkeitsgrad beim nächsten Test etwas reduzieren.

Test 2: Gesamtumsatz 2023

AdvancedRAG

SimpleRAG

Zusammenfassung: Beide RAGs haben die richtige Antwort gegeben: 1.068.989.000 US-Dollar Gesamtumsatz im Jahr 2023

Beide waren genau hier. Es scheint, als ob AdvancedRAG ein breiteres Spektrum an Dokumenten erworben hat. Die Antwort ist sicherlich detaillierter und berücksichtigt auch Informationen aus den Vorjahren. Das war angesichts der von uns vorgenommenen Verbesserungen zu erwarten, aber es ist viel zu früh, um das zu beurteilen.

Erhöhen wir den Schwierigkeitsgrad.

Test 3: Von welchem Produkt hängt das Wachstum primär ab? Wie viel?

AdvancedRAG

SimpleRAG

Zusammenfassung: Beide RAG-Modelle haben Elastic Cloud korrekt als wichtigsten Wachstumstreiber identifiziert. AdvancedRAG hingegen enthält mehr Details, berücksichtigt Abonnementumsätze und Kundenwachstum und erwähnt explizit andere Elastic-Angebote.

Test 4: Beschreiben Sie den Mitarbeitervergütungsplan

AdvancedRAG

SimpleRAG

Zusammenfassung: AdvancedRAG geht wesentlich tiefer und detaillierter darauf ein und erwähnt den 401K-Plan für in den USA ansässige Mitarbeiter sowie die Beitragspläne außerhalb der USA. Es werden auch Gesundheits- und Wohlbefindenspläne erwähnt, das Programm Elastic Cares, das SimpleRAG erwähnt, wird jedoch nicht aufgeführt.

Test 5: Welche Unternehmen hat Elastic übernommen?

AdvancedRAG

SimpleRAG

Zusammenfassung: SimpleRAG liefert keine relevanten Informationen zu Akquisitionen, was zu einer fehlerhaften Antwort führt. AdvancedRAG listet CmdWatch, Build Security und Optimyze korrekt auf; dies waren die im Bericht genannten wichtigsten Akquisitionen.

Zurück nach oben

Fazit

Unsere Tests ergaben, dass unsere fortschrittlichen Techniken den Umfang und die Tiefe der präsentierten Informationen erhöhen und dadurch potenziell die Qualität der RAG-Antworten verbessern.

Darüber hinaus könnten Verbesserungen bei der Zuverlässigkeit erzielt werden, da mehrdeutig formulierte Fragen wie Which companies did Elastic acquire? und Who audits Elastic von AdvancedRAG korrekt beantwortet wurden, nicht aber von SimpleRAG.

Allerdings sollte man bedenken, dass in 3 von 5 Fällen die grundlegende RAG-Pipeline, die die Hybridsuche, aber keine anderen Techniken einbezog, Antworten lieferte, die den Großteil der wichtigsten Informationen erfassten.

Es ist zu beachten, dass die Latenz von AdvancedRAG aufgrund der Einbeziehung von LLMs in den Phasen der Datenaufbereitung und -abfrage im Allgemeinen 2- bis 5-mal größer ist als die von SimpleRAG. Dies stellt einen erheblichen Kostenfaktor dar, der AdvancedRAG möglicherweise nur für Situationen geeignet macht, in denen die Antwortqualität Vorrang vor der Latenz hat.

Die erheblichen Latenzkosten können durch den Einsatz eines kleineren und kostengünstigeren LLM wie Claude Haiku oder GPT-4o-mini in der Datenaufbereitungsphase verringert werden. Die fortgeschrittenen Modelle werden für die Antwortgenerierung verwendet.

Dies steht im Einklang mit den Ergebnissen von Wang et al. Wie ihre Ergebnisse zeigen, sind alle erzielten Verbesserungen relativ geringfügig. Kurz gesagt, mit einer einfachen RAG-Basislinie kommt man schon fast zu einem brauchbaren Endprodukt und ist dabei auch noch günstiger und schneller. Für mich ist das ein interessantes Ergebnis. Für Anwendungsfälle, in denen Geschwindigkeit und Effizienz im Vordergrund stehen, ist SimpleRAG die vernünftige Wahl. Für Anwendungsfälle, in denen jedes letzte Quäntchen Leistung herausgeholt werden muss, könnten die in AdvancedRAG integrierten Techniken einen vielversprechenden Ansatz bieten.

Zurück nach oben

Anhang

Eingabeaufforderungen

RAG-Frage-Antwort-Aufforderung

Aufforderung an das LLM, Antworten basierend auf Anfrage und Kontext zu generieren.

Eingabeaufforderung für den Elastic-Abfragegenerator

Aufforderung zur Anreicherung von Abfragen mit Synonymen und deren Umwandlung in das OR-Format.

Mögliche Fragen zur Generierung von Anregungen

Anregung zur Generierung potenzieller Fragen, Anreicherung der Dokumentmetadaten.

HyDE-Generator-Eingabeaufforderung

Aufforderung zur Generierung hypothetischer Dokumente mit HyDE

Beispiel einer hybriden Suchanfrage

Die kürzlich erschienene Arbeit „Searching for Best Practices in Retrieval-Augmented Generation“ bewertet empirisch die Wirksamkeit verschiedener RAG-Verbesserungstechniken mit dem Ziel, eine Reihe von Best Practices für RAG zu ermitteln.

Wir werden einige dieser vorgeschlagenen Best Practices umsetzen, nämlich diejenigen, die darauf abzielen, die Qualität der Suche zu verbessern (Sentence Chunking, HyDE, Reverse Packing).

Aus Gründen der Kürze lassen wir die Techniken zur Effizienzsteigerung (Abfrageklassifizierung und Zusammenfassung) aus.

Wir werden auch einige Techniken anwenden, die nicht behandelt wurden, die ich persönlich aber für nützlich und interessant halte (Metadateneinbindung, zusammengesetzte Multi-Field-Einbettungen, Abfrageanreicherung).

Zum Schluss führen wir einen kurzen Test durch, um zu sehen, ob sich die Qualität unserer Suchergebnisse und generierten Antworten im Vergleich zur Ausgangslage verbessert hat. Los geht's!

RAG-Übersicht

RAG zielt darauf ab, LLMs zu verbessern, indem Informationen aus externen Wissensdatenbanken abgerufen werden, um die generierten Antworten anzureichern. Durch die Bereitstellung domänenspezifischer Informationen können LLMs schnell an Anwendungsfälle außerhalb des Umfangs ihrer Trainingsdaten angepasst werden; dies ist wesentlich kostengünstiger als eine Feinabstimmung und einfacher, sie auf dem neuesten Stand zu halten.

Maßnahmen zur Verbesserung der Qualität von Ampelbewertungen konzentrieren sich typischerweise auf zwei Bereiche:

1. Verbesserung der Qualität und Klarheit der Wissensbasis.

2. Verbesserung der Abdeckung und Spezifität von Suchanfragen.

Diese beiden Maßnahmen sollen das Ziel erreichen, die Wahrscheinlichkeit zu erhöhen, dass der LLM Zugang zu relevanten Fakten und Informationen hat und somit weniger wahrscheinlich Halluzinationen hat oder auf sein eigenes Wissen zurückgreift, das möglicherweise veraltet oder irrelevant ist.

Die Vielfalt der Methoden lässt sich in wenigen Sätzen nur schwer verdeutlichen. Um die Dinge verständlicher zu machen, gehen wir direkt zur Umsetzung über.

Inhaltsverzeichnis

• Überblick

  • Inhaltsverzeichnis

• Aufstellen

• Einlesen, Verarbeiten und Einbetten von Dokumenten

  • Dateningestion

  • Chunking auf Satzebene, tokenweise

  • Metadateneinbindung und -generierung

    • Von TextRank extrahierte Schlüsselphrasen

    • Mögliche Fragen, die von GPT-4o generiert wurden

    • Von Spacy extrahierte Entitäten

  • Zusammengesetzte Mehrfeldeinbettungen

    • Indexierung zu Elastic

• Katzenbruch

• Anhang

  • Definitionen

Aufstellen

Der gesamte Code ist im Searchlabs-Repository zu finden.

Das Wichtigste zuerst. Sie benötigen Folgendes:

1. Eine elastische Cloud-Bereitstellung

2. Eine LLM-API – In diesem Notebook verwenden wir eine GPT-4o-Bereitstellung auf Azure OpenAI.

3. Python Version 3.12.4 oder höher

Wir werden den gesamten Code aus dem main.ipynb-Notebook ausführen.

Klonen Sie nun das Repository mit git, navigieren Sie zu supporting-blog-content/advanced-rag-techniques und führen Sie anschließend die folgenden Befehle aus:

Sobald das erledigt ist, erstellen Sie eine .env-Datei. Datei öffnen und die folgenden Felder ausfüllen (Referenz in .env.example). Ein Dank geht an meinen Co-Autor Claude-3.5 für die hilfreichen Kommentare.

Als Nächstes wählen wir das zu importierende Dokument aus und legen es im Dokumentenordner ab. Für diesen Artikel verwenden wir den Elastic NV Jahresbericht 2023. Es handelt sich um ein ziemlich anspruchsvolles und komplexes Dokument, perfekt geeignet, um unsere RAG-Techniken einem Stresstest zu unterziehen.

Jetzt sind wir bereit, lasst uns mit der Einnahme beginnen. Öffnen Sie main.ipynb und führen Sie die ersten beiden Zellen aus, um alle Pakete zu importieren und alle Dienste zu initialisieren.

Zurück nach oben

Einlesen, Verarbeiten und Einbetten von Dokumenten

Dateningestion

• Persönliche Anmerkung: Ich bin von der Benutzerfreundlichkeit von LlamaIndex begeistert. In den alten Zeiten vor LLMs und LlamaIndex war das Einlesen von Dokumenten in verschiedenen Formaten ein mühsamer Prozess, bei dem man esoterische Pakete aus allen möglichen Quellen zusammentragen musste. Jetzt ist es auf einen einzigen Funktionsaufruf reduziert. Wild.

Die SimpleDirectoryReader lädt alle Dokumente in den directory_path. -Dateien. Für .pdf -Dateien gibt sie eine Liste von Dokumentobjekten zurück, die ich in Python-Dictionaries umwandle, da ich diese einfacher zu handhaben finde.

Jedes Wörterbuch enthält den Schlüsselinhalt im Feld text . Es enthält außerdem nützliche Metadaten wie Seitenzahl, Dateiname, Dateigröße und Dateityp.

Zurück nach oben

Chunking auf Satzebene, tokenweise

Als Erstes sollten wir unsere Dokumente in Abschnitte von einheitlicher Länge unterteilen (um Konsistenz und Verwaltbarkeit zu gewährleisten). Einbettungsmodelle haben individuelle Token-Limits (maximale Eingabegröße, die sie verarbeiten können). Tokens sind die grundlegenden Einheiten des Textes, die Prozesse modellieren. Um Informationsverluste (Abschneidung oder Auslassung von Inhalten) zu vermeiden, sollten wir Texte bereitstellen, die diese Grenzen nicht überschreiten (indem wir längere Texte in kleinere Abschnitte aufteilen).

Das Chunking hat einen erheblichen Einfluss auf die Leistung. Im Idealfall stellt jeder Abschnitt eine in sich abgeschlossene Informationseinheit dar, die Kontextinformationen zu einem einzelnen Thema erfasst. Zu den Chunking-Methoden gehören das Chunking auf Wortebene, bei dem Dokumente anhand der Wortanzahl aufgeteilt werden, und das semantische Chunking, das ein LLM verwendet, um logische Trennpunkte zu identifizieren.

Die Segmentierung auf Wortebene ist zwar günstig, schnell und einfach, birgt aber das Risiko, Sätze zu trennen und dadurch den Kontext zu zerstören. Die semantische Segmentierung wird langsam und teuer, insbesondere bei Dokumenten wie dem 116-seitigen Elastic Annual Report.

Lasst uns einen Mittelweg wählen. Die Segmentierung auf Satzebene ist zwar immer noch einfach, kann aber den Kontext besser erhalten als die Segmentierung auf Wortebene und ist dabei deutlich günstiger und schneller. Zusätzlich werden wir ein gleitendes Fenster implementieren, um einen Teil des umgebenden Kontextes zu erfassen und die Auswirkungen der Absatzteilung zu verringern.

Die Klasse Chunker verwendet den Tokenizer des Einbettungsmodells zum Kodieren und Dekodieren von Text. Wir werden nun Blöcke von jeweils 512 Token erstellen, mit einer Überlappung von 20 Token. Dazu teilen wir den Text in Sätze auf, tokenisieren diese Sätze und fügen die tokenisierten Sätze dann unserem aktuellen Chunk hinzu, bis wir keine weiteren mehr hinzufügen können, ohne unser Token-Limit zu überschreiten.

Zum Schluss werden die Sätze wieder in den Originaltext dekodiert, um sie einzubetten. Dieser wird in einem Feld namens original_text gespeichert. Die Chunks werden in einem Feld namens chunk gespeichert. Um unnötige Dokumente (auch: überflüssige Dokumente) zu reduzieren, werden wir alle Dokumente verwerfen, die kürzer als 50 Token sind.

Lassen Sie uns das anhand unserer Dokumente prüfen:

Und Sie erhalten Textabschnitte zurück, die etwa so aussehen:

Zurück nach oben

Metadateneinbindung und -generierung

Wir haben unsere Dokumente in Abschnitte unterteilt. Nun ist es an der Zeit, die Daten anzureichern. Ich möchte zusätzliche Metadaten generieren oder extrahieren. Diese zusätzlichen Metadaten können genutzt werden, um die Suchleistung zu beeinflussen und zu verbessern.

Wir definieren eine DocumentEnricher -Klasse, deren Aufgabe es ist, eine Liste von Dokumenten (Python-Dictionaries) und eine Liste von Prozessorfunktionen entgegenzunehmen. Diese Funktionen werden auf die Spalte original_text der Dokumente angewendet und ihre Ergebnisse in neuen Feldern gespeichert.

Zuerst extrahieren wir mithilfe von TextRank Schlüsselphrasen. TextRank ist ein graphenbasierter Algorithmus, der Schlüsselphrasen und -sätze aus Texten extrahiert, indem er ihre Wichtigkeit anhand der Beziehungen zwischen den Wörtern ordnet.

Als nächstes generieren wir potenzielle_Fragen mithilfe von GPT-4o.

Zum Schluss extrahieren wir Entitäten mithilfe von Spacy.

Da der Code für jeden dieser Punkte recht umfangreich und komplex ist, verzichte ich darauf, ihn hier wiederzugeben. Bei Interesse sind die Dateien in den unten stehenden Codebeispielen gekennzeichnet.

Starten wir die Datenanreicherung:

Und sehen Sie sich die Ergebnisse an:

Von TextRank extrahierte Schlüsselphrasen

Diese Schlüsselbegriffe stehen stellvertretend für die Kernthemen des jeweiligen Abschnitts. Wenn eine Anfrage mit Cybersicherheit zu tun hat, wird die Punktzahl dieses Abschnitts erhöht.

Mögliche Fragen, die von GPT-4o generiert wurden

Diese potenziellen Fragen könnten direkt mit den Suchanfragen der Nutzer übereinstimmen und so zu einer Verbesserung der Punktzahl führen. Wir fordern GPT-4o auf, Fragen zu generieren, die mithilfe der im aktuellen Chunk enthaltenen Informationen beantwortet werden können.

Von Spacy extrahierte Entitäten

Diese Entitäten dienen einem ähnlichen Zweck wie die Schlüsselphrasen, erfassen aber die Namen von Organisationen und Einzelpersonen, die bei der Extraktion von Schlüsselphrasen möglicherweise nicht erfasst werden.

Zurück nach oben

Zusammengesetzte Mehrfeldeinbettungen

Nachdem wir unsere Dokumente nun mit zusätzlichen Metadaten angereichert haben, können wir diese Informationen nutzen, um robustere und kontextsensitive Einbettungen zu erstellen.

Lassen Sie uns den aktuellen Stand des Prozesses noch einmal betrachten. Wir haben in jedem Dokument vier Interessensgebiete.

Jedes Feld repräsentiert eine andere Perspektive auf den Kontext des Dokuments und hebt möglicherweise einen wichtigen Bereich hervor, auf den sich das LLM konzentrieren sollte.

Der Plan besteht darin, jedes dieser Felder einzubetten und dann eine gewichtete Summe der Einbettungen zu erstellen, die als zusammengesetzte Einbettung bezeichnet wird.

Mit etwas Glück wird dieses Composite Embedding dem System ermöglichen, kontextsensitiver zu werden, und zusätzlich einen weiteren einstellbaren Hyperparameter zur Steuerung des Suchverhaltens einführen.

Zunächst betten wir jedes Feld ein und aktualisieren jedes Dokument direkt, indem wir unser lokal definiertes Einbettungsmodell verwenden, das wir zu Beginn des Notebooks main.ipynb importiert haben.

Jede Einbettungsfunktion gibt das Feld der Einbettung zurück, welches einfach das ursprüngliche Eingabefeld mit einem Suffix _embedding ist.

Definieren wir nun die Gewichtungen unserer zusammengesetzten Einbettung:

Mithilfe der Gewichtungen können Sie den einzelnen Komponenten Prioritäten zuweisen, basierend auf Ihrem Anwendungsfall und der Qualität Ihrer Daten. Intuitiv betrachtet hängt die Größe dieser Gewichtungen vom semantischen Wert jeder Komponente ab. Da der Chunk-Text selbst mit Abstand den größten Informationsgehalt aufweist, weise ich ihm eine Gewichtung von 70 % zu. Da es sich bei den Entitäten um die kleinsten handelt, nämlich lediglich um eine Liste von Organisations- oder Personennamen, weise ich ihnen eine Gewichtung von 5 % zu. Die genaue Festlegung dieser Werte muss empirisch, also für jeden Anwendungsfall einzeln, erfolgen.

Zum Schluss schreiben wir eine Funktion, um die Gewichtungen anzuwenden und unser zusammengesetztes Embedding zu erstellen. Um Speicherplatz zu sparen, löschen wir auch alle Komponenteneinbettungen.

Hiermit ist unsere Dokumentenbearbeitung abgeschlossen. Wir haben nun eine Liste von Dokumentobjekten, die folgendermaßen aussehen:

Indexierung zu Elastic

Lasst uns unsere Dokumente per Massen-Upload in Elastic Search hochladen. Zu diesem Zweck habe ich vor langer Zeit eine Reihe von Elastic-Helper-Funktionen in elastic_helpers.py definiert. Es handelt sich um einen sehr langen Codeabschnitt, daher konzentrieren wir uns auf die Funktionsaufrufe.

es_bulk_indexer.bulk_upload_documents Funktioniert mit beliebigen Listen von Wörterbuchobjekten und nutzt dabei die praktischen dynamischen Zuordnungen von Elasticsearch.

Gehe zu Kibana und überprüfe, ob alle Dokumente indexiert wurden. Es sollten 224 sein. Nicht schlecht für ein so umfangreiches Dokument!

Zurück nach oben

Katzenbruch

Lasst uns eine Pause machen, der Artikel ist etwas anspruchsvoll, ich weiß. Schaut euch meine Katze an:

Liebenswert. Der Hut ist verschwunden und ich vermute fast, dass sie ihn gestohlen und irgendwo versteckt hat :(

Herzlichen Glückwunsch, dass du es so weit geschafft hast :)

Seien Sie in Teil 2 wieder dabei, wenn wir unsere RAG-Pipeline testen und bewerten!

Anhang

Definitionen

1. Satzgliederung

• Eine Vorverarbeitungstechnik, die in RAG-Systemen verwendet wird, um Text in kleinere, sinnvolle Einheiten zu unterteilen.

• Prozess:

  1. Eingabe: Großer Textblock (z. B. Dokument, Absatz)

  2. Ausgabe: Kleinere Textsegmente (typischerweise Sätze oder kleine Satzgruppen)

• Zweck:

  • Erzeugt detaillierte, kontextspezifische Textsegmente

  • Ermöglicht eine präzisere Indizierung und einen schnelleren Abruf.

  • Verbessert die Relevanz der abgerufenen Informationen in RAG-Systemen

• Eigenschaften:

  • Segmente sind semantisch aussagekräftig.

  • Kann unabhängig indexiert und abgerufen werden.

  • Oft wird etwas Kontext beibehalten, um die Verständlichkeit für sich allein zu gewährleisten.

• Vorteile:

  • Verbessert die Abrufgenauigkeit

  • Ermöglicht eine gezieltere Erweiterung in RAG-Pipelines.

2. HyDE (Hypothetisches Dokumenteneinbetten)

• Eine Technik, die ein LLM verwendet, um ein hypothetisches Dokument zur Abfrageerweiterung in RAG-Systemen zu generieren.

• Prozess:

  1. Eingabeanfrage an einen LLM

  2. LLM generiert ein hypothetisches Dokument, das die Anfrage beantwortet.

  3. Das generierte Dokument einbetten

  4. Verwenden Sie die Einbettung für die Vektorsuche

• Hauptunterschied:

  • Traditionelles RAG: Gleicht Suchanfragen mit Dokumenten ab

  • HyDE: Ordnet Dokumente einander zu

• Zweck:

  • Verbesserung der Abfrageleistung, insbesondere bei komplexen oder mehrdeutigen Anfragen

  • Erfasst einen reichhaltigeren semantischen Kontext als eine kurze Anfrage

• Vorteile:

  • Nutzt das Wissen des LLM, um Anfragen zu erweitern

  • Kann potenziell die Relevanz der abgerufenen Dokumente verbessern

• Herausforderungen:

  • Erfordert zusätzliche LLM-Inferenz, was die Latenz und die Kosten erhöht.

  • Die Leistung hängt von der Qualität des generierten hypothetischen Dokuments ab.

3. Rückwärtsverpackung

• Eine in RAG-Systemen verwendete Technik, um Suchergebnisse neu zu ordnen, bevor sie an den LLM weitergeleitet werden.

• Prozess:

  1. Die Suchmaschine (z. B. Elasticsearch) gibt Dokumente in absteigender Reihenfolge ihrer Relevanz zurück.

  2. Die Reihenfolge ist umgekehrt, das wichtigste Dokument steht nun an letzter Stelle.

• Zweck:

  • Nutzt den Aktualitätsbias von LLMs aus, die sich tendenziell stärker auf die neuesten Informationen in ihrem Kontext konzentrieren.

  • Gewährleistet, dass im Kontextfenster des LLM die relevantesten Informationen stets aktuell sind.

• Beispiel: Ursprüngliche Reihenfolge: [Relevantester, Zweitwichtigster, Drittwichtigster, ...] Umgekehrte Reihenfolge: [..., Drittwichtigster, Zweitwichtigster, Relevantester]

4. Abfrageklassifizierung

• Eine Technik zur Optimierung der Effizienz von RAG-Systemen durch die Bestimmung, ob eine Anfrage RAG erfordert oder direkt vom LLM beantwortet werden kann.

• Prozess:

  1. Entwickeln Sie einen benutzerdefinierten Datensatz, der speziell auf den verwendeten LLM zugeschnitten ist.

  2. Trainieren Sie ein spezialisiertes Klassifizierungsmodell

  3. Nutzen Sie das Modell, um eingehende Anfragen zu kategorisieren.

• Zweck:

  • Verbessern Sie die Systemeffizienz, indem Sie unnötige RAG-Verarbeitung vermeiden.

  • Direkte Anfragen an den am besten geeigneten Antwortmechanismus

• Anforderungen:

  • LLM-spezifischer Datensatz und Modell

  • Kontinuierliche Optimierung zur Aufrechterhaltung der Genauigkeit

• Vorteile:

  • Reduziert den Rechenaufwand für einfache Abfragen

  • Verbessert möglicherweise die Antwortzeit für Nicht-RAG-Anfragen

5. Zusammenfassung

• Eine Technik zur Komprimierung abgerufener Dokumente in RAG-Systemen.

• Prozess:

  1. Relevante Dokumente abrufen

  2. Erstellen Sie prägnante Zusammenfassungen jedes Dokuments.

  3. Verwenden Sie in der RAG-Pipeline Zusammenfassungen anstelle vollständiger Dokumente.

• Zweck:

  • Verbessern Sie die RAG-Performance, indem Sie sich auf wesentliche Informationen konzentrieren.

  • Rauschen und Störungen durch weniger relevante Inhalte reduzieren

• Vorteile:

  • Verbessert möglicherweise die Relevanz der LLM-Antworten

  • Ermöglicht die Einbeziehung weiterer Dokumente innerhalb der Kontextgrenzen.

• Herausforderungen:

  • Gefahr, wichtige Details in der Zusammenfassung zu verlieren

  • Zusätzlicher Rechenaufwand für die Zusammenfassungserstellung

6. Einbeziehung von Metadaten

• Eine Technik zur Anreicherung von Dokumenten mit zusätzlichen Kontextinformationen.

• Metadatentypen:

  • Schlüsselwörter

  • Titel

  • Termine

  • Angaben zur Autorschaft

  • Klappentexte

• Zweck:

  • Erweitern Sie die dem Ampelsystem zur Verfügung stehenden Kontextinformationen.

  • LLM-Studierenden ein klareres Verständnis des Dokumentinhalts und dessen Relevanz vermitteln

• Vorteile:

  • Verbessert möglicherweise die Abrufgenauigkeit

  • Verbessert die Fähigkeit des LLM-Programms, den Nutzen von Dokumenten zu beurteilen

• Durchführung:

  • Kann während der Dokumentenvorverarbeitung erfolgen.

  • Möglicherweise sind zusätzliche Datenextraktions- oder -generierungsschritte erforderlich.

7. Zusammengesetzte Mehrfeld-Einbettungen

• Eine fortschrittliche Einbettungstechnik für RAG-Systeme, die separate Einbettungen für verschiedene Dokumentkomponenten erstellt.

• Prozess:

  1. Relevante Felder identifizieren (z. B. Titel, Schlüsselwörter, Klappentext, Hauptinhalt)

  2. Erzeugen Sie separate Einbettungen für jedes Feld.

  3. Diese Einbettungen können kombiniert oder gespeichert werden, um sie beim Abruf zu verwenden.

• Unterschied zum Standardverfahren:

  • Traditionell: Einmaliges Einbetten für das gesamte Dokument

  • Komposit: Mehrere Einbettungen für verschiedene Dokumentaspekte

• Zweck:

  • Erstellen Sie differenziertere und kontextbezogene Dokumentendarstellungen

  • Informationen aus einer größeren Vielfalt von Quellen innerhalb eines Dokuments erfassen

• Vorteile:

  • Verbessert möglicherweise die Leistung bei mehrdeutigen oder vielschichtigen Anfragen.

  • Ermöglicht eine flexiblere Gewichtung verschiedener Dokumentaspekte bei der Recherche.

• Herausforderungen:

  • Erhöhte Komplexität bei der Einbettung von Speicher- und Abrufprozessen

  • Möglicherweise sind komplexere Matching-Algorithmen erforderlich.

8. Abfrageanreicherung

• Eine Technik zur Erweiterung der ursprünglichen Suchanfrage um verwandte Begriffe, um die Suchabdeckung zu verbessern.

• Prozess:

  1. Analysieren Sie die ursprüngliche Anfrage

  2. Generieren Sie Synonyme und semantisch verwandte Phrasen

  3. Erweitern Sie die Abfrage um diese zusätzlichen Begriffe

• Zweck:

  • Erhöhen Sie den Bereich potenzieller Übereinstimmungen im Dokumentenkorpus.

  • Verbesserung der Abfrageleistung für Anfragen mit spezifischer oder technischer Sprache

• Vorteile:

  • Ruft möglicherweise relevante Dokumente ab, die nicht exakt den ursprünglichen Suchbegriffen entsprechen.

  • Kann dazu beitragen, Vokabeldiskrepanz zwischen Anfragen und Dokumenten zu überwinden.

• Herausforderungen:

  • Gefahr der Abfrageabweichung bei unsachgemäßer Implementierung

  • Kann den Rechenaufwand im Abrufprozess erhöhen

Zurück nach oben

In diesem Beitrag werden wir uns mit Möglichkeiten zum Schutz personenbezogener Daten (PII) und sensibler Daten bei der Verwendung öffentlicher LLMs in einem RAG-Ablauf (Retrieval Augmented Generation) befassen. Wir werden untersuchen, wie man personenbezogene Daten und sensible Daten mithilfe von Open-Source-Bibliotheken und regulären Ausdrücken maskieren kann, sowie wie man lokale LLMs verwendet, um Daten zu maskieren, bevor man einen öffentlichen LLM aufruft.

Bevor wir beginnen, wollen wir einige Begriffe wiederholen, die wir in diesem Beitrag verwenden.

Terminologie

LlamaIndex ist ein führendes Datenframework für die Entwicklung von LLM-Anwendungen (Large Language Model). LlamaIndex bietet Abstraktionen für verschiedene Phasen der Entwicklung einer RAG-Anwendung (Retrieval Augmented Generation). Frameworks wie LlamaIndex und LangChain bieten Abstraktionen, damit Anwendungen nicht eng an die APIs eines bestimmten LLM gekoppelt werden.

Elasticsearch wird von Elastic angeboten. Elastic ist ein Branchenführer hinter Elasticsearch, einem skalierbaren Datenspeicher und einer Vektordatenbank, die Volltextsuche für Präzision, Vektorsuche für semantisches Verständnis und Hybridsuche für das Beste aus beiden Welten unterstützt. Elasticsearch ist eine verteilte, RESTful-basierte Such- und Analyse-Engine, ein skalierbarer Datenspeicher und eine Vektordatenbank. Die in diesem Blog verwendeten Elasticsearch-Funktionen sind in der kostenlosen Open-Source-Version von Elasticsearch verfügbar.

Retrieval-Augmented Generation (RAG) ist eine KI-Technik bzw. ein KI-Muster, bei dem LLMs mit externem Wissen versorgt werden, um Antworten auf Benutzeranfragen zu generieren. Dadurch können die Antworten des LLM auf einen spezifischen Kontext zugeschnitten und weniger allgemein gehalten werden.

Einbettungen sind numerische Repräsentationen der Bedeutung von Texten/Medien. Es handelt sich um niedrigdimensionale Darstellungen hochdimensionaler Informationen.

RAG und Datenschutz

Im Allgemeinen sind große Sprachmodelle (LLMs) gut darin, Antworten auf der Grundlage von im Modell verfügbaren Informationen zu generieren, die mit Internetdaten trainiert werden können. Für Anfragen, bei denen die im Modell nicht verfügbaren Informationen vorliegen, müssen die LLMs jedoch externes Wissen oder spezifische Details erhalten, die nicht im Modell enthalten sind. Solche Informationen könnten sich in Ihrer Datenbank oder Ihrem internen Wissenssystem befinden. Retrieval-Augmented Generation (RAG) ist eine Technik, bei der für eine gegebene Benutzeranfrage zunächst relevante Kontextinformationen aus externen Systemen (z. B. Ihrer Datenbank) abgerufen und diese Kontextinformationen zusammen mit der Benutzeranfrage an das LLM gesendet werden, um eine spezifischere und relevantere Antwort zu generieren.

Dadurch eignet sich die RAG-Technik hervorragend für Anwendungen in der Fragebeantwortung, der Inhaltserstellung und überall dort, wo ein tiefes Verständnis von Kontext und Details von Vorteil ist.

Daher besteht bei einer RAG-Pipeline die Gefahr, dass interne Informationen wie PII (personenbezogene Daten) und sensible Informationen (z. B. Namen, Geburtsdaten, Kontonummern usw.) öffentlichen LLMs zugänglich gemacht werden.

Obwohl Ihre Daten bei der Verwendung einer Vektordatenbank wie Elasticsearch (durch verschiedene Mechanismen wie rollenbasierte Zugriffskontrolle, Dokumentensicherheit usw.) sicher sind, ist Vorsicht geboten, wenn Sie Daten an ein öffentliches LLM senden.

Der Schutz personenbezogener Daten (PII) und sensibler Daten ist bei der Verwendung großer Sprachmodelle (LLMs) aus mehreren Gründen von entscheidender Bedeutung:

• Datenschutzkonformität: Viele Regionen verfügen über strenge Vorschriften, wie beispielsweise die Datenschutz-Grundverordnung (DSGVO) in Europa oder den California Consumer Privacy Act (CCPA) in den Vereinigten Staaten, die den Schutz personenbezogener Daten vorschreiben. Die Einhaltung dieser Gesetze ist notwendig, um rechtliche Konsequenzen und Geldstrafen zu vermeiden.

• Nutzervertrauen: Die Gewährleistung der Vertraulichkeit und Integrität sensibler Informationen schafft Nutzervertrauen. Nutzer werden Systeme, von denen sie glauben, dass sie ihre Privatsphäre schützen, eher nutzen und mit ihnen interagieren.

• Datensicherheit: Der Schutz vor Datenlecks ist unerlässlich. Werden sensible Daten LLMs ohne angemessene Sicherheitsvorkehrungen zugänglich gemacht, können sie gestohlen oder missbraucht werden, was zu potenziellen Schäden wie Identitätsdiebstahl oder Finanzbetrug führen kann.

• Ethische Überlegungen: Aus ethischer Sicht ist es wichtig, die Privatsphäre der Nutzer zu respektieren und verantwortungsvoll mit ihren Daten umzugehen. Der unsachgemäße Umgang mit personenbezogenen Daten kann zu Diskriminierung, Stigmatisierung oder anderen negativen gesellschaftlichen Auswirkungen führen.

• Unternehmensreputation: Unternehmen, die sensible Daten nicht schützen, können einen Reputationsschaden erleiden, der langfristige negative Auswirkungen auf ihr Geschäft haben kann, einschließlich Kunden- und Umsatzverlusten.

• Reduzierung des Missbrauchsrisikos: Der sichere Umgang mit sensiblen Daten trägt dazu bei, einen missbräuchlichen Einsatz der Daten oder des Modells zu verhindern, wie beispielsweise das Trainieren der Modelle mit verzerrten Daten oder die Verwendung der Daten zur Manipulation oder Schädigung von Einzelpersonen.

Zusammenfassend lässt sich sagen, dass ein umfassender Schutz personenbezogener Daten und sensibler Daten notwendig ist, um die Einhaltung gesetzlicher Bestimmungen zu gewährleisten, das Vertrauen der Nutzer zu erhalten, die Datensicherheit sicherzustellen, ethische Standards einzuhalten, den Ruf des Unternehmens zu schützen und das Missbrauchsrisiko zu verringern.

Kurze Zusammenfassung

Im vorherigen Beitrag haben wir besprochen, wie man ein Q&A-Erlebnis mit einer RAG-Technik und Elasticsearch als Vektordatenbank unter Verwendung von LlamaIndex und einem lokal laufenden Mistral LLM implementiert. Hier bauen wir darauf auf.

Das Lesen des vorherigen Beitrags ist optional, da wir nun kurz besprechen/zusammenfassen werden, was wir im vorherigen Beitrag behandelt haben.

Wir verfügten über einen Beispieldatensatz mit Callcenter-Gesprächen zwischen Agenten und Kunden eines fiktiven Hausratversicherungsunternehmens. Wir haben eine einfache RAG-Anwendung entwickelt, die Fragen wie „Für welche Art von wasserbezogenen Problemen reichen Kunden Schadensmeldungen ein?“ beantwortet.

Im Großen und Ganzen sah der Ablauf so aus.

Während der Indexierungsphase haben wir Dokumente mithilfe der LlamaIndex-Pipeline geladen und indexiert. Die Dokumente wurden in Abschnitte unterteilt und zusammen mit ihren Einbettungen in der Elasticsearch-Vektordatenbank gespeichert.

Während der Abfragephase, als der Benutzer eine Frage stellte, ermittelte LlamaIndex die K ähnlichsten Dokumente, die für die Abfrage relevant waren. Diese Top-K relevanten Dokumente wurden zusammen mit der Anfrage an das lokal laufende Mistral LLM gesendet, das dann die Antwort generierte, die an den Benutzer zurückgesendet wurde. Sie können sich gerne den vorherigen Beitrag durchlesen oder den Code erkunden.

Im vorherigen Beitrag hatten wir LLM lokal am Laufen. Im Produktionsbetrieb kann es jedoch sinnvoll sein, ein externes LLM von verschiedenen Anbietern wie OpenAI, Mistral, Anthropic usw. zu verwenden. Es könnte daran liegen, dass Ihr Anwendungsfall ein größeres Basismodell erfordert oder dass eine lokale Ausführung aufgrund von Anforderungen der Unternehmensproduktion wie Skalierbarkeit, Verfügbarkeit, Leistung usw. nicht möglich ist.

Die Einbindung eines externen LLM in Ihre RAG-Pipeline birgt das Risiko, dass sensible Daten und personenbezogene Daten unbeabsichtigt an die LLMs gelangen. In diesem Beitrag werden wir Möglichkeiten zur Maskierung personenbezogener Daten im Rahmen Ihres RAG-Prozesses untersuchen, bevor Sie Dokumente an einen externen LLM senden.

RAG mit einem öffentlichen LLM

Bevor wir darauf eingehen, wie Sie Ihre personenbezogenen Daten und sensiblen Informationen in einer RAG-Pipeline schützen können, werden wir zunächst eine einfache RAG-Anwendung mit LlamaIndex, der Elasticsearch Vector-Datenbank und OpenAI LLM erstellen.

Voraussetzungen

Wir benötigen Folgendes.

• Elasticsearch ist als Vektordatenbank zum Speichern der Einbettungen eingerichtet und betriebsbereit. Folgen Sie den Anweisungen aus dem vorherigen Beitrag zur Installation von Elasticsearch.

• OpenAI-API-Schlüssel.

Einfache RAG-Anwendung

Zur Information: Der vollständige Code befindet sich in diesem GitHub-Repository(Branch:protecting-pii). Das Klonen des Repositorys ist optional, da wir den Code im Folgenden genauer betrachten werden.

Erstellen Sie in Ihrer bevorzugten IDE eine neue Python-Anwendung mit den folgenden 3 Dateien.

• index.py Hierhin wird der Code für die Indizierung von Daten eingefügt.

• query.py Hier wird der Code für Abfragen und die Interaktion mit LLM eingefügt.

• .env dort, wo Konfigurationseigenschaften wie API-Schlüssel gespeichert werden.

Wir müssen einige Pakete installieren. Wir beginnen damit, eine neue virtuelle Python-Umgebung im Stammverzeichnis Ihrer Anwendung zu erstellen.

Aktivieren Sie die virtuelle Umgebung und installieren Sie die unten aufgeführten erforderlichen Pakete.

Konfigurieren Sie die Verbindungseigenschaften von OpenAI und Elasticsearch in der .env-Datei. Datei.

Indexierungsdaten

Laden Sie die Datei conversations.json herunter, die Konversationen zwischen Kunden und Callcenter-Mitarbeitern unseres fiktiven Hausversicherungsunternehmens enthält. Platzieren Sie die Datei im Stammverzeichnis der Anwendung zusammen mit den beiden Python-Dateien und der .env-Datei. die Datei, die Sie zuvor erstellt haben. Nachfolgend ein Beispiel für den Inhalt der Datei.

Fügen Sie den unten stehenden Code in index.py ein, der sich um die Indizierung der Daten kümmert.

Wenn Sie den obigen Code ausführen, wird ein Index in Elasticsearch erstellt und die Einbettungen werden im Elasticsearch-Index mit dem Namen convo_index gespeichert.

Falls Sie eine Erläuterung zur LlamaIndex IngestionPipeline benötigen, lesen Sie bitte den vorherigen Beitrag im Abschnitt "IngestionPipeline erstellen".

Abfrage

Im vorherigen Beitrag haben wir ein lokales LLM für Abfragen verwendet.

In diesem Beitrag verwenden wir das öffentliche LLM OpenAI, wie unten dargestellt.

Der obige Code gibt die Antwort von OpenAI wie folgt aus.

Kunden haben verschiedene Ansprüche im Zusammenhang mit Wasser geltend gemacht, darunter Probleme wie Wasserschäden in Kellern, geplatzte Rohre, Hagelschäden an Dächern sowie die Ablehnung von Ansprüchen aufgrund von Gründen wie mangelnder rechtzeitiger Meldung, Wartungsmängeln, allmählichem Verschleiß und bereits bestehenden Schäden. In allen Fällen äußerten die Kunden ihre Frustration über die Ablehnung ihrer Ansprüche und forderten eine faire Bewertung und Entscheidung in Bezug auf ihre Ansprüche.

Maskierung von PII in RAG

Was wir bisher behandelt haben, beinhaltet das Senden von Dokumenten unverändert zusammen mit der Benutzeranfrage an OpenAI.

In der RAG-Pipeline haben wir, nachdem der relevante Kontext aus einem Vektorspeicher abgerufen wurde, die Möglichkeit, personenbezogene Daten und sensible Informationen zu maskieren, bevor wir die Anfrage und den Kontext an das LLM senden.

Es gibt verschiedene Möglichkeiten, personenbezogene Daten zu maskieren, bevor man sie an ein externes LLM sendet, wobei jede ihre eigenen Vorzüge hat. Wir betrachten einige der folgenden Optionen.

1. Verwendung von NLP-Bibliotheken wie spacy.io oder Presidio (Open-Source-Bibliothek, die von Microsoft gepflegt wird).

2. Verwendung von LlamaIndex direkt aus der Verpackung NERPIINodePostprocessor.

3. Nutzung lokaler LLMs über PIINodePostprocessor

Sobald Sie die Maskierungslogik mithilfe einer der oben genannten Methoden implementiert haben, können Sie die LlamaIndex IngestionPipeline mit einem PostProcessor konfigurieren (entweder mit einem eigenen benutzerdefinierten PostProcessor oder mit einem der standardmäßig verfügbaren PostProcessors von LlamaIndex).

Verwendung von NLP-Bibliotheken

Im Rahmen der RAG-Pipeline könnten wir sensible Daten mithilfe von NLP-Bibliotheken maskieren. In dieser Demo verwenden wir das spacy.io-Paket.

Erstellen Sie eine neue Datei query_masking_nlp.py und fügen Sie den unten stehenden Code ein.

Die Antwort des LLM ist unten dargestellt.

Im obigen Code geben wir beim Erstellen der Llama Index QueryEngine einen CustomPostProcessor an.

Die Logik, die von der QueryEngine aufgerufen wird, ist in der Methode _postprocess_nodes von CustomPostProcessor definiert. Wir verwenden die SpaCy.io-Bibliothek, um benannte Entitäten in unseren Daten zu erkennen, und verwenden dann einige reguläre Ausdrücke, um diese Namen sowie sensible Informationen zu ersetzen, bevor wir die Dokumente an das LLM senden.

Nachfolgend finden Sie beispielhaft Ausschnitte aus den Originalkonversationen und der vom CustomPostProcessor erstellten maskierten Konversation.

Originaltext:

Maskierter Text durch den CustomPostProcessor.

Notiz:

Das Identifizieren und Maskieren von personenbezogenen Daten und sensiblen Informationen ist keine einfache Aufgabe. Die Berücksichtigung verschiedener Formate und Semantiken sensibler Informationen erfordert ein gutes Verständnis Ihres Fachgebiets und Ihrer Daten. Auch wenn der oben dargestellte Code für einige Anwendungsfälle funktionieren mag, müssen Sie ihn möglicherweise an Ihre Bedürfnisse und Tests anpassen.

Verwendung des LlamaIndex direkt aus der Verpackung NERPIINodePostprocessor

LlamaIndex hat den Schutz personenbezogener Daten in einer RAG-Pipeline durch die Einführung vereinfacht. NERPIINodePostprocessor.

Die Antwort sieht wie folgt aus:

Nutzung lokaler LLMs über PIINodePostprocessor

Alternativ könnten wir auch ein lokal oder in Ihrem privaten Netzwerk laufendes LLM nutzen, um die Maskierung durchzuführen, bevor die Daten an ein öffentliches LLM gesendet werden.

Wir werden Mistral, das auf Ollama auf Ihrem lokalen Rechner läuft, für die Maskierung verwenden.

Mistral lokal ausführen

Laden Sie Ollama herunter und installieren Sie es. Nach der Installation von Ollama führen Sie diesen Befehl aus, um Mistralherunterzuladen und auszuführen.

Das Herunterladen und erstmalige lokale Ausführen des Modells kann einige Minuten dauern. Prüfen Sie, ob Mistral weht, indem Sie eine Frage wie die folgende stellen: „Schreibe ein Gedicht über Wolken“ und prüfen Sie, ob Ihnen das Gedicht gefällt. Bitte lassen Sie ollama laufen, da wir später über Code mit dem Mistral-Modell interagieren müssen.

Erstellen Sie eine neue Datei namens query_masking_local_LLM.py und fügen Sie den unten stehenden Code ein.

Die Antwort sieht in etwa so aus wie unten dargestellt.

Fazit

In diesem Beitrag haben wir gezeigt, wie Sie personenbezogene Daten und sensible Daten beim Einsatz öffentlicher LLMs in einem RAG-Flow schützen können. Wir haben verschiedene Wege aufgezeigt, wie dies erreicht werden kann. Es wird dringend empfohlen, diese Ansätze anhand Ihres Anwendungsfalls und Ihrer Bedürfnisse zu testen, bevor Sie sie übernehmen.

Bevor wir anfangen, werden wir uns einige Fachbegriffe ansehen.

Terminologie

LlamaIndex ist ein führendes Datenframework für die Entwicklung von LLM-Anwendungen (Large Language Model). LlamaIndex bietet Abstraktionen für verschiedene Phasen der Entwicklung einer RAG-Anwendung (Retrieval Augmented Generation). Frameworks wie LlamaIndex und LangChain bieten Abstraktionen, damit Anwendungen nicht eng an die APIs eines bestimmten LLM gekoppelt werden.

Elasticsearch wird von Elastic angeboten. Elastic ist ein Branchenführer hinter Elasticsearch, einer Such- und Analyse-Engine, die Volltextsuche für Präzision, Vektorsuche für semantisches Verständnis und Hybridsuche für das Beste aus beiden Welten unterstützt. Elasticsearch ist ein skalierbarer Datenspeicher und eine Vektordatenbank. Die in diesem Blog verwendeten Elasticsearch-Funktionen sind in der kostenlosen Open-Source-Version von Elasticsearch verfügbar.

Retrieval Augment Generation (RAG) ist eine KI-Technik bzw. ein KI-Muster, bei dem LLMs mit externem Wissen ausgestattet werden, um Antworten auf Benutzeranfragen zu generieren. Dadurch können die LLM-Antworten auf den jeweiligen Kontext zugeschnitten werden und sind spezifischer.

Mistral bietet sowohl Open-Source- als auch optimierte LLM-Modelle für Unternehmen an. In diesem Tutorial verwenden wir deren Open-Source-Modell Mistral-7b , das auf Ihrem Laptop läuft. Falls Sie das Modell nicht auf Ihrem Laptop ausführen möchten, können Sie alternativ die Cloud-Version nutzen. In diesem Fall müssen Sie den Code in diesem Blog anpassen, um die richtigen API-Schlüssel und Pakete zu verwenden.

Ollama hilft dabei, LLMs lokal auf Ihrem Laptop auszuführen. Wir werden Ollama verwenden, um das Open-Source-Modell Mistral-7b lokal auszuführen.

Einbettungen sind numerische Repräsentationen der Bedeutung von Texten/Medien. Es handelt sich um niedrigdimensionale Darstellungen hochdimensionaler Informationen.

Erstellung einer RAG-Anwendung mit LlamaIndex, Elasticsearch und Mistral: Szenarioübersicht

Szenario:

Wir verfügen über einen Beispieldatensatz (als JSON-Datei) mit Callcenter-Gesprächen zwischen Agenten und Kunden eines fiktiven Hausratversicherungsunternehmens. Wir werden eine einfache RAG-Anwendung entwickeln, die Fragen wie diese beantworten kann:

Give me summary of water related issues.

Hoher Durchfluss

Wir betreiben Mistral LLM lokal mit Ollama.

Als nächstes laden wir Konversationen aus der JSON-Datei als Documents in den ElasticsearchStore (einen VectorStore, der von Elasticsearch unterstützt wird). Beim Laden der Dokumente erstellen wir Einbettungen mithilfe des lokal laufenden Mistral-Modells. Wir speichern diese Einbettungen zusammen mit den Konversationen im LlamaIndex Elasticsearch Vector Store (ElasticsearchStore).

Wir konfigurieren eine LlamaIndex IngestionPipeline und stellen ihr den lokal verwendeten LLM zur Verfügung, in diesem Fall Mistral, das über Ollama läuft.

Wenn wir eine Frage stellen wie „Geben Sie mir eine Zusammenfassung der wichtigsten wasserbezogenen Probleme.“ Elasticsearch führt eine semantische Suche durch und liefert Konversationen zum Thema Wasser. Diese Konversationen werden zusammen mit der ursprünglichen Frage an das lokal laufende LLM gesendet, um eine Antwort zu generieren.

Schritte zum Erstellen der RAG-Anwendung

Mistral lokal ausführen

Laden Sie Ollama herunter und installieren Sie es. Nach der Installation von Ollama führen Sie diesen Befehl aus, um Mistralherunterzuladen und auszuführen.

Das Herunterladen und erstmalige lokale Ausführen des Modells kann einige Minuten dauern. Prüfen Sie, ob Mistral weht, indem Sie eine Frage wie die folgende stellen: „Schreibe ein Gedicht über Wolken“ und prüfen Sie, ob Ihnen das Gedicht gefällt. Bitte lassen Sie ollama laufen, da wir später über Code mit dem Mistral-Modell interagieren müssen.

Elasticsearch installieren

Elasticsearch lässt sich entweder durch Erstellen einer Cloud-Bereitstellung (Anleitung hier) oder durch Ausführen in Docker (Anleitung hier) in Betrieb nehmen. Sie können auch eine produktionsreife, selbstgehostete Elasticsearch-Bereitstellung erstellen, indem Sie hier beginnen.

Sofern Sie die Cloud-Bereitstellung nutzen, besorgen Sie sich den API-Schlüssel und die Cloud-ID für die Bereitstellung, wie in der Anleitung beschrieben. Wir werden sie später verwenden.

RAG-Anwendung

Der vollständige Code ist als Referenz in diesem GitHub-Repository zu finden. Das Klonen des Repos ist optional, da wir den Code im Folgenden durchgehen werden.

Erstellen Sie in Ihrer bevorzugten IDE eine neue Python-Anwendung mit den folgenden 3 Dateien.

• index.py Hierhin wird der Code für die Indizierung von Daten eingefügt.

• query.py Hier wird der Code für Abfragen und die Interaktion mit LLM eingefügt.

• .env dort, wo Konfigurationseigenschaften wie API-Schlüssel gespeichert werden.

Wir müssen einige Pakete installieren. Wir beginnen damit, eine neue virtuelle Python-Umgebung im Stammverzeichnis Ihrer Anwendung zu erstellen.

Aktivieren Sie die virtuelle Umgebung und installieren Sie die unten aufgeführten erforderlichen Pakete.

Indexierungsdaten

Laden Sie die Datei conversations.json herunter, die Konversationen zwischen Kunden und Callcenter-Mitarbeitern unseres fiktiven Hausversicherungsunternehmens enthält. Platzieren Sie die Datei im Stammverzeichnis der Anwendung zusammen mit den beiden Python-Dateien und der .env-Datei. die Datei, die Sie zuvor erstellt haben. Nachfolgend ein Beispiel für den Inhalt der Datei.

Wir definieren eine Funktion namens get_documents_from_file in index.py , die die JSON-Datei liest und eine Liste von Dokumenten erstellt. Dokumentobjekte sind die grundlegende Informationseinheit, mit der LlamaIndex arbeitet.

IngestionPipeline erstellen

Fügen Sie zunächst die Elasticsearch CloudID und die API-Schlüssel, die Sie im Abschnitt Install Elasticsearch erhalten haben, in die Datei .env ein. Ihre .env -Datei sollte wie folgt aussehen (mit realen Werten).

Mit LlamaIndex IngestionPipeline können Sie eine Pipeline aus mehreren Komponenten zusammensetzen. Fügen Sie den unten stehenden Code in die Datei index.py ein.

Wie bereits erwähnt, kann die LlamaIndex IngestPipeline aus mehreren Komponenten zusammengesetzt sein. Wir fügen der Pipeline in Zeile pipeline = IngestionPipeline(... 3 Komponenten hinzu.

• SentenceSplitter: Wie aus der Definition von get_documents_from_file() hervorgeht, verfügt jedes Dokument über ein Textfeld, das die in der JSON-Datei gefundene Konversation enthält. Dieses Textfeld enthält einen langen Text. Damit die semantische Suche gut funktioniert, muss der Text in kleinere Abschnitte unterteilt werden. Die Klasse SentenceSplitter erledigt das für uns. Diese Abschnitte werden in der LlamaIndex-Terminologie als Knoten bezeichnet. Die Knoten enthalten Metadaten, die auf das Dokument verweisen, zu dem sie gehören. Alternativ können Sie auch Elasticsearch Ingestpipeline für das Chunking verwenden, wie in diesem Blog gezeigt.

• OllamaEmbedding: Embedding-Modelle wandeln einen Textabschnitt in Zahlen (auch Vektoren genannt) um. Die numerische Darstellung ermöglicht uns die semantische Suche, bei der die Suchergebnisse der Bedeutung des Wortes entsprechen, anstatt nur eine Textsuche durchzuführen. Wir stellen der IngestionPipeline OllamaEmbedding("mistral") zur Verfügung. Die mit SentenceSplitter aufgeteilten Chunks werden über Ollama an das auf Ihrem lokalen Rechner laufende Mistral-Modell gesendet. Mistral erstellt dann Einbettungen für die Chunks.

• ElasticsearchStore: Der LlamaIndex ElasticsearchStore-Vektorspeicher sichert die in einen Elasticsearch-Index erstellten Einbettungen. ElasticsearchStore kümmert sich um das Erstellen und Befüllen des angegebenen Elasticsearch-Index mit Inhalten. Beim Erstellen des ElasticsearchStore (referenziert durch es_vector_store) geben wir den Namen des Elasticsearch-Index an, den wir erstellen möchten (calls in unserem Fall ), das Feld im Index, in dem die Einbettungen gespeichert werden sollen (conversation_vector in unserem Fall ) und das Feld, in dem der Text gespeichert werden soll (conversation in unserem Fall ). Zusammenfassend lässt sich sagen, dass auf Basis unserer Konfiguration ElasticsearchStore ein neuer Index in Elasticsearch mit conversation_vector und conversation als Feldern (neben anderen automatisch erstellten Feldern) erstellt wird.

Um das Ganze zusammenzuführen, starten wir die Pipeline durch den Aufruf von pipeline.run(documents=documents).

Führen Sie das Skript index.py aus, um die Ingest-Pipeline zu starten:

Sobald der Pipeline-Lauf abgeschlossen ist, sollte in Elasticsearch ein neuer Index mit dem Namen calls angezeigt werden. Wenn Sie eine einfache Elasticsearch-Abfrage über die Entwicklerkonsole ausführen, sollten Sie die geladenen Daten zusammen mit den Einbettungen sehen können.

Zusammenfassend lässt sich sagen, dass wir bisher Dokumente aus einer JSON-Datei erstellt, diese in Abschnitte unterteilt, Einbettungen für diese Abschnitte erstellt und die Einbettungen (sowie die Textkonversation) in einem Vektorspeicher (ElasticsearchStore) gespeichert haben.

Abfrage

Mit dem llamaIndex VectorStoreIndex können Sie relevante Dokumente abrufen und Daten abfragen. Standardmäßig speichert VectorStoreIndex Einbettungen im Arbeitsspeicher in einem SimpleVectorStore. Alternativ können jedoch externe Vektorspeicher (wie ElasticsearchStore) verwendet werden, um die Einbettungen persistent zu machen.

Öffnen Sie query.py und fügen Sie den folgenden Code ein.

Wir definieren ein lokales LLM (local_llm), das auf das Mistral-Modell verweist, das auf Ollama läuft. Als nächstes erstellen wir einen VectorStoreIndex (index) aus dem zuvor erstellten ElasticsearchStore-Vektorspeicher und erhalten dann eine Abfrage-Engine aus dem Index. Beim Erstellen der Abfrage-Engine verweisen wir auf das lokale LLM, das zur Beantwortung verwendet werden soll. Wir geben außerdem (similarity_top_k=10) an, um die Anzahl der Dokumente zu konfigurieren, die aus dem Vektorspeicher abgerufen und an das LLM gesendet werden sollen, um eine Antwort zu erhalten.

Führen Sie das Skript query.py aus, um den RAG-Ablauf auszuführen:

Wir senden die Anfrage Give me summary of water related issues (Sie können query gerne anpassen) und die Antwort des LLM, die mit zugehörigen Dokumenten geliefert wird, sollte in etwa wie folgt aussehen.

Einige Einschränkungen:

Dieser Blogbeitrag ist eine Einführung für Anfänger in die RAG-Technik mit Elasticsearch und lässt daher die Konfiguration von Funktionen aus, die es Ihnen ermöglichen, diesen Ausgangspunkt in die Produktion zu überführen. Bei der Entwicklung für Produktionsanwendungen sollten Sie komplexere Aspekte berücksichtigen, wie z. B. die Möglichkeit, Ihre Daten mit Document Level Security zu schützen, Ihre Daten im Rahmen einer Elasticsearch Ingest-Pipeline in Chunking-Aufteilung aufzuteilen oder sogar andere ML-Jobs auf denselben Daten auszuführen, die für GenAI/Chat/Q&A-Anwendungsfälle verwendet werden.

Sie könnten auch in Erwägung ziehen, Daten aus verschiedenen externen Quellen (z. B. Azure Blob Storage, Dropbox, Gmail usw.) zu beziehen und Einbettungen mithilfe von Elastic Connectors zu erstellen.

Elastic macht all das und noch viel mehr möglich und bietet eine umfassende Lösung auf Unternehmensebene für GenAI-Anwendungsfälle und darüber hinaus.

Was kommt als Nächstes?

• Möglicherweise ist Ihnen aufgefallen, dass wir 10 thematisch zusammenhängende Konversationen zusammen mit der Benutzerfrage an das LLM senden, damit dieses eine Antwort formulieren kann. Diese Gespräche können personenbezogene Daten (PII) wie Name, Geburtsdatum, Adresse usw. enthalten. In unserem Fall ist das LLM lokal, daher ist ein Datenleck kein Problem. Wenn Sie jedoch ein LLM in der Cloud (z. B. OpenAI) verwenden möchten, ist es nicht wünschenswert, Texte zu senden, die personenbezogene Daten enthalten. In einem Folgeblogbeitrag werden wir sehen, wie man personenbezogene Daten maskiert, bevor man sie im RAG-Flow an externe LLMs sendet.

• In diesem Beitrag haben wir ein lokales LLM verwendet. Im kommenden Beitrag über die Maskierung personenbezogener Daten in RAG werden wir uns ansehen, wie man einfach von einem lokalen LLM zu einem öffentlichen LLM wechseln kann.