Was Abwärtskompatibilität für die Kibana-Dashboards API bedeutet

Während der technischen Vorschau kann sich die API-Struktur zwischen den Releases ändern.[1] Diese Zeiten sind vorbei. Allgemeine Verfügbarkeit (General Availability, GA) bedeutet:

• Vollständige Abwärtskompatibilität. Im Laufe der Zeit werden neue Felder und Paneltypen hinzugefügt, aber bestehende Felder und Verhaltensweisen bleiben unverändert. Alle zukünftigen kompatibilitätsbrechenden Änderungen würden sehr sorgfältig geprüft und nur in einer neuen Haupt-Stack-Version eingeführt.

• Produktionsbereit mit voller Unterstützung. Die API bietet die vollständigen Support-Garantien von Elastic. Sie können es bedenkenlos in Produktionsumgebungen für automatisierte Deployments, Umgebungs-Promotion und programmatisches Dashboard-Management verwenden.

Neue Kibana-API-Endpoints für die Panels „Tags“, „Markdown“ und „Links“

Elastic 9.5 führt außerdem einen neuen eigenständigen Endpoint für Tags ein, der es ermöglicht, Dashboards zu kategorisieren und zu filtern. Sie können diese nun programmatisch über dedizierte CRUD-Endpoints verwalten, was die Organisation von Dashboards in großem Umfang über verschiedene Umgebungen hinweg vereinfacht.

Neue Endpoints für die Markdown- und Links-Bedienfelder sind ab sofort in Serverless verfügbar und werden in der nächsten Stack-Version (9.6) implementiert.

Welche Panel-Typen unterstützt die Kibana-Dashboards-API?

Die Dashboards-API unterstützt alle By-Value-Panels in Version 9.5 (d. h. diejenigen, die direkt in einem Dashboard definiert wurden, im Gegensatz zu Bibliotheks-Panels, die zur Wiederverwendung gespeichert wurden). Jeder unterstützte Paneltyp verfügt über ein typisiertes, validiertes Schema.

Panel-Typ

Status

XY-Diagramme

Ja

Metriken

Ja

Kreisdiagramm

Ja

Messgerät

Ja

Heatmap

Ja

Datentabellen

Ja

Treemap

Ja

Discover Sitzungen

Ja

Steuerungen

Ja

Markdown

Ja

Links

Ja

ML-Panels

Ja

Observability-Panels

Ja

Maps

Demnächst verfügbar

Vega

Demnächst verfügbar

Wie man Kibana-Dashboards als Code verwaltet

Die Dashboards-API ermöglicht einen vollständigen „Dashboards-as-Code“-Workflow: Exportieren Sie ein Dashboard als sauberes, vergleichbares JSON, übertragen Sie es als maßgebliche Quelle in Git, überprüfen Sie Änderungen in Pull-Anfragen und stellen Sie dieselbe Definition in den Umgebungen Entwicklung, Staging und Produktion bereit. Sobald ein Dashboard als Code verwaltet wird, ist Git als einzige Quelle der Wahrheit zu behandeln: Änderungen, die direkt in der Benutzeroberfläche vorgenommen werden, werden beim nächsten Bereitstellen überschrieben.

Die größte Herausforderung beim Verschieben eines Dashboards zwischen Bereichen, Clustern oder Phasen besteht darin, dass Dashboards auf Objekte wie Datenansichten und Bibliotheksvisualisierungen anhand ihrer ID verweisen. Da diese IDs automatisch generiert werden und sich je nach Umgebung unterscheiden, kann ein aus einer Umgebung exportiertes Dashboard auf Objekte verweisen, die in einer anderen Umgebung nicht vorhanden sind. Es gibt drei Möglichkeiten, dies zu handhaben, hier aufgelistet von der am stärksten automatisierten bis zur am wenigsten automatisierten:

• Benutzen Sie Terraform. Der Elastic Stack Terraform Provider verfolgt jede Ressource und ordnet IDs pro Umgebung automatisch zu, sodass die Referenzen konsistent bleiben, wenn Sie ein Dashboard von der Entwicklung bis zur Produktion überführen.

• Nach Wert definieren Elasticsearch Abfragesprache (ES|QL)-Panels. Die portabelste Methode zum Erstellen eines Panels besteht darin, dessen Visualisierung mit ES|QL direkt im Dashboard zu definieren. Eine ES|QL-Abfrage liest aus den von Ihnen genannten Indizes, sodass das Panel keine externen Referenzen auf Data view oder Bibliotheksobjekte enthält. Das Ergebnis ist ein vollständig autarkes, portables Dashboard.

• Weisen Sie passende IDs zu. Wenn Sie auf gespeicherte Objekte wie Data View oder Bibliotheksvisualisierungen verweisen, erstellen Sie diese mit einer ausgewählten ID mittels PUT (upsert) anstatt mit POST (das automatisch eine ID generiert). Verwenden Sie für Menschen lesbare IDs, wie beispielsweise „logs-prod“, damit diese in verschiedenen Umgebungen leicht wiederverwendet und erkannt werden können.

Eine ausführliche Anleitung zu diesen Portabilitätsmustern und dem vollständigen Dashboards-as-Code-Workflow finden Sie in der Dokumentation Dashboards als Code verwalten.

Erstellen Sie ein Kibana-Dashboard mit der Dashboards-API mithilfe von PUT

Hier ein kurzes Beispiel zur Erstellung eines Dashboards mit einem Metrikbereich. Dabei wird PUT anstelle von POST verwendet, um eine benutzerdefinierte ID anhand des Dashboard-Namens (service-health-overview) zuzuweisen. Dieselbe Logik funktioniert auch für die Erstellung eigenständiger Visualisierungen, die in der Bibliothek gespeichert werden.

Kibana Dashboards API-Roadmap: Maps, Vega und eigenständige Endpoints

Wir erweitern aktiv die API-Schnittstelle. Als nächstes folgt die Unterstützung für Maps und Vega-Panels, wobei typisierte Schemas dafür hinzugefügt werden. Wir entwickeln außerdem eigenständige CRUD-Endpunkte für Discover-Sitzungen (zusätzlich zu ihrer bestehenden Unterstützung als Dashboard-Panels), Vega, Maps und Annotations, die vom Dashboard-Lebenszyklus entkoppelt sind.

Für die vollständigen Schema-Definitionen besuchen Sie die Dashboards API-Dokumentation. Für Terraform-Nutzer unterstützt der Elastic Stack Terraform-Provider die GA Dashboards API.

Anmerkung

1. Die Kern-Endpoints sind gegenüber der technischen Vorschau unverändert. Wenn Sie Integrationen für 9.4 erstellt haben, funktionieren sie in 9.5. Die einzigen kompatibilitätsbrechenden Änderungen sind zwei geringfügige, die sich auf die Formate für Dashboard-Auflistungen und Dauereinheiten auswirken und hier dokumentiert sind.

Die leistungsstärksten KI-Modelle werden auf externen Cloud-Installationen mit Zugriff über eine Web-API ausgeführt, was bedeutet, dass Sie Ihrem KI-Dienstanbieter in Bezug auf Sicherheit, Verfügbarkeit und stabile Preise vertrauen müssen. Sie können die berechtigten Anforderungen an Zuverlässigkeit, Datenschutz, überschaubare Kosten und eine gute Data Governance nicht ohne Weiteres mit dem Einsatz von KI in Einklang bringen, die immer leistungsfähiger, ausgefeilter und ressourcenintensiver wird.

Regierungsvorschriften, Gerichtsurteile und geschäftliche Erwägungen, die im Interesse Dritter getroffen wurden, haben in jüngster Zeit dazu geführt, dass der Zugang zu bestimmten Diensten eingeschränkt wurde. Und selbst wenn ein Wechsel zu anderen Diensten möglich ist, sind KI-Modelle keine Komponenten, die sich einfach nach Belieben austauschen lassen. Anwendungen, die semantische Einbettungen nutzen, sind darauf angewiesen, zum Zeitpunkt der Abfrage Zugriff auf dieselben Modelle wie zum Zeitpunkt der Daten-Ingestion zu erhalten. Den Zugriff auf das Einbettungsmodell zu verlieren bedeutet, dass Ihr Suchsystem zum Stillstand kommt.

KI-Preismodelle verstärken dieses Risiko noch. Die jüngsten Finanzberichte großer KI-Anbieter geben den Kunden guten Grund zur Sorge vor möglichen Preiserhöhungen. Die Abhängigkeit von Produkten mit unvorhersehbaren Kosten erhöht das Risiko kapitalintensiver KI-Investitionen, die möglicherweise keine eindeutigen Renditen erzielen.

Jina On-Prem ist die Antwort von Elastic auf diese Herausforderungen.

Wer benötigt On-Prem-KI?

Lokales Hosting und die direkte Kontrolle über Ihre KI-Modelle unterstützen eine Vielzahl technischer Anforderungen, Branchenvorgaben und geschäftlicher Interessen.

Durch eine lokale Installation sinken zwar die Kosten für Ihre KI-Dienstanbieter, allerdings fallen die Kosten für die Hardware und einen zuverlässigen Zugang nun zu Lasten Ihres Unternehmens. Je nach Nutzungsumfang kann es durchaus günstiger sein. Doch es gibt noch weitere dringende Gründe, die für den Betrieb einer eigenen KI sprechen. Sollte eines der unten beschriebenen Probleme auf Ihr Unternehmen zutreffen, sollten Sie eine lokale KI-Lösung wie Jina On-Prem in Betracht ziehen. Diese Liste erhebt keinen Anspruch auf Vollständigkeit.

Anwendungsfall

Warum On-Prem

Beispiel

Air-Gap/Hohe Sicherheit

Keine ausgehende Datenübertragung; vollständige Netzwerkisolierung

Verteidigung, Nachrichtendienste, geheime Forschung

Einhaltung gesetzlicher Vorschriften

Datensouveränität; keine grenzüberschreitende Übermittlung oder Weitergabe an Dritte

Gesundheitswesen (Health Insurance Portability and Accountability Act [HIPAA]), Finanzwesen, EU-Unternehmen (Datenschutz-Grundverordnung [DSGVO])

Latenzkritisch

Keine Netzwerkabhängigkeit; keine Toleranz gegenüber Verbindungsausfällen

Robotik, Edge Computing, Fahrzeuge, Schiffe

Planbarkeit der Kosten

Feste Infrastrukturkosten vs. Preise pro Token mit ungewissen zukünftigen Preisen

Kontinuierliche Inferenz-Workloads mit hohem Volumen

Haftungsbeschränkung

Keine Offenlegung von Daten Dritter; Wahrung des Anwaltsgeheimnisses und der Sorgfaltspflicht

Anwaltskanzleien, Behörden

Warum Air-Gap- und firewallgeschützte Systeme On-Prem-KI benötigen

Air-Gap- und durch eine Firewall geschützte Systeme können keine externen KI-APIs verwenden. Jina On-Prem wird vollständig innerhalb Ihrer Infrastruktur ohne ausgehende Verbindungen ausgeführt.

Für Unternehmen, die besonders sensible Daten verwalten, sind Sicherheits- und Datenschutzaspekte von größter Bedeutung. Es nützt wenig, in den Schutz Ihrer sensiblen Daten zu investieren, wenn Sie diese umgehend an einen externen Dritten weitergeben, der möglicherweise über unzureichende Sicherheitsvorkehrungen verfügt oder den Auflagen einer ausländischen Regierung unterliegt.

Mitarbeiter in Unternehmen, die mit sensiblen Daten umgehen, erhalten oft Schulungen zum sicheren Umgang mit Daten. Diese sind jedoch nicht sehr wirksam, wenn alle Mitarbeiter Webbrowser nutzen, die während der Bearbeitung dieser Daten möglicherweise auf beliebige Seiten im Internet zugreifen können. Die Isolierung ist die wirksamste verfügbare Sicherheitsmaßnahme, sei es durch ein Air Gap oder durch sehr restriktive Firewalls, doch dadurch wird die Nutzung externer Dienste jeglicher Art erschwert.

On-Prem-KI für latenzempfindliche Systeme und Systeme mit hoher Verfügbarkeit

Software as a Service und Cloud Computing stellen einen Kompromiss zwischen den Kosten für die Bereitstellung leicht zugänglicher, zuverlässiger Dienste auf den eigenen Computern und der Auslagerung dieser Problematik an Dritte dar. Allerdings sind sie mit schwankenden Latenzzeiten, Ausfällen und einem völligen Kontrollverlust verbunden, wenn etwas schiefgeht. KI-Dienste bilden da keine Ausnahme. Wenn Ihr Suchsystem offline geht, sobald Sie keinen Zugriff mehr auf Ihr Einbettungsmodell haben, scheint es möglicherweise kein guter Kompromiss mehr zu sein.

Darüber hinaus birgt der Einsatz externer KI stets Risiken, die sich nicht ohne Weiteres vorhersehen oder verwalten lassen. Der Internetzugang und die Netzwerklatenz können sich ohne Vorwarnung verschlechtern, beispielsweise aufgrund politischer Ereignisse, schlechten Wetters oder weil Schiffe mit ihren Ankern über Unterwasser-Glasfaserkabel schleifen. Regierungen können Exportverbote verhängen, um den Zugriff auf KI-Modelle schlagartig zu unterbinden – und das haben sie in jüngster Zeit auch getan. KI-Dienstanbieter nehmen Modelle gelegentlich aus dem Angebot, um Sie zu einem Wechsel auf neuere Modelle zu bewegen. Die Flexibilität und die kontrollierten Kosten externer Dienste müssen gegen die Risiken einer Abhängigkeit abgewogen werden.

On-Prem-KI für die Compliance mit der DSGVO, HIPAA und Datensouveränität

Unternehmen, die personenbezogene Daten erheben, unterliegen immer strengeren Vorschriften, die sich oft von Rechtsraum zu Rechtsraum unterscheiden und widersprüchliche Anforderungen enthalten können. Insbesondere sehen die HIPAA-Vorschriften sehr strenge Datenschutzbestimmungen für amerikanische Gesundheitsdienstleister vor. Zudem verlangen strenge allgemeine Datenschutzgesetze in Kanada, der Europäischen Union sowie vielen asiatischen Ländern von allen Unternehmen, die personenbezogene Daten verarbeiten, einen sicheren Umgang mit diesen Daten sowie eine Beschränkung der Weitergabe dieser Daten an Dritte oder in andere Länder. Diese Vorschriften könnten sogar für ausländische Unternehmen Verpflichtungen mit sich bringen, sofern sie Kunden in diesen Ländern haben. Finanzinstitute unterliegen häufig noch strengeren Vorschriften und tragen dieselbe direkte Verantwortung für die Informationssicherheit wie beim Schutz vor anderen Formen krimineller Aktivitäten.

Die Einhaltung gesetzlicher Vorschriften kann mit KI-Diensten von Drittanbietern unvereinbar sein, insbesondere wenn ihre Nutzung eine grenzüberschreitende Datenübertragung beinhaltet.

Zudem zeigen die jüngsten Ereignisse, dass Vorschriften, die den physischen Standort von Datenspeichern einschränken, nicht unbedingt einen verlässlichen Schutz bieten, wenn internationale Cloud-Anbieter dem Druck ausländischer Regierungen ausgesetzt sind. Lokale Gesetze können sich je nach Rechtsraum widersprechen, was eine lokale Datenspeicherung und -verarbeitung erforderlich und die Nutzung von Diensten Dritter unmöglich macht. In einigen Fällen ist die einzige Lösung eine vollständige interne Abwicklung aller Prozesse, einschließlich Ihrer KI-Systeme.

KI-Haftungsrisiken durch die Datenübertragung von Drittanbietern

Datenschutzgesetze und anerkannte Sorgfaltspflichten im Umgang mit sensiblen Daten haben regelmäßig haftungsrechtliche Konsequenzen, die mitunter sehr schwerwiegend sein können. Sie können für den Umgang mit Ihren Daten durch Drittanbieter haftbar gemacht werden. Zwar bieten Gerichte und rechtliche Verfahren unter Umständen einen gewissen nachträglichen Schutz vor unsicheren Dienstanbietern, doch stehen diese Rechtsmittel gegenüber Akteuren der nationalen Sicherheit, Strafverfolgungsbehörden oder kriminellen Hackern weder zur Verfügung noch sind sie im Allgemeinen wirksam.

Bei Regierungen gab es bereits Fälle, in denen grenzüberschreitend tätige Cloud-Dienstanbieter sensible staatliche Informationen an ausländische Akteure weitergegeben haben.

Aber selbst wenn Sie sich keine Sorgen um ausländische Regierungen oder Hacker machen und Ihre externen KI-Dienstanbieter selbst sicher sind, kann allein die Tatsache, dass sie extern sind, Haftungsrisiken mit sich bringen.

So genießen beispielsweise in den meisten Ländern die Kommunikation zwischen Rechtsanwälten und ihren Mandanten einen besonderen rechtlichen Schutz, und Anwaltskanzleien unterliegen strengen Haftungsvorschriften bei der Aufzeichnung oder Speicherung dieser Informationen. In den Vereinigten Staaten ist dieses „Anwaltsgeheimnis“ so bekannt, dass es sogar eine zentrale Rolle in Film- und Fernsehhandlungen spielt. Eine Möglichkeit, diese Privilegien zu verlieren, besteht jedoch darin, Informationen an jemanden weiterzugeben, der diese Privilegien nicht besitzt, und die jüngsten Entwicklungen deuten darauf hin, dass externe KI-Dienstanbieter unter diese Kategorie fallen könnten.

Zumindest in den Vereinigten Staaten ist es möglich, dass bereits die bloße Nutzung von KI-Diensten von Drittanbietern über eine Internet-API – wie beispielsweise die Einbindung von Modellen, die Indizierungsdienste bereitstellen – gegen wichtige Vertraulichkeitsvorschriften verstoßen könnte. Eine Anwaltskanzlei könnte allein aufgrund der Nutzung extern gehosteter Software verklagt, disziplinarisch belangt oder aus der Anwaltskammer ausgeschlossen werden, selbst wenn keine Sicherheitsverletzung vorliegt.

On-Prem-KI für Offline-, Edge- und physisch isolierte Systeme

Computersysteme werden nicht nur aus Sicherheitsgründen isoliert. Beispielsweise dürfen sich fahrende Fahrzeuge bei keiner ihrer wesentlichen Funktionen auf einen Internetzugang verlassen. Schiffe und Flugzeuge verfügen über sehr umfangreiche Bordcomputersysteme, die ohne Internetverbindung funktionieren müssen und daher keine externen KI-Dienste nutzen können. Offshore-Plattformen, abgelegene Anlagen in unberührten Naturgebieten, Computerdienste in der Arktis, der Antarktis und auf kleinen Inseln ohne ausreichende physische Anbindung an globale Netzwerke sind allesamt Beispiele für Einrichtungen, die davon profitieren, alle benötigten Dienste lokal zu hosten. Da die Bedeutung der KI in der Unternehmens-IT zunimmt, wird es immer wichtiger, diese Einschränkungen anzugehen.

Neue Anwendungen der KI in physischen Systemen (Robotik und andere Anwendungsfälle, die räumlich begrenzt sind oder auf die Außenwelt ausgerichtet sind, wie Logistikmanagementsysteme oder sogar Supermarktkassen) sind zwar möglicherweise mit dem globalen Internet verbunden, tolerieren jedoch weder Verbindungsausfälle noch plötzliche Latenzspitzen. Wenn sie für ihren Betrieb auf ein KI-System angewiesen sind, muss dieses KI-System so lokal und zuverlässig wie möglich sein.

Wer braucht keine On-Prem-KI?

Remote-Softwaredienste und externe KI bieten durchaus Vorteile. Für den Betrieb von KI-Modellen sind unter Umständen teure, stromfressende Prozessoren erforderlich, die bekanntermaßen nur eine kurze Lebensdauer haben. Der Zugang zu hochwertiger Hardware ist derzeit aufgrund von Marktfaktoren und externen wirtschaftlichen Schocks besonders schwierig. Unter diesen Umständen kann es sinnvoll sein, für die Nutzung einer externen API pro Token zu bezahlen, anstatt die hohen Investitionskosten für eine lokale KI zu tragen.

Externe APIs sind für gelegentliche Nutzer am sinnvollsten. Wenn Sie KI-Modelle in erster Linie zur Batch-Verarbeitung von Daten für Analysezwecke nutzen und nicht zum Betreiben eines Suchsystems, das ständig online sein muss, macht es wenig Sinn, in kapitalintensive Hardware und lokale Installationen zu investieren.

Darüber hinaus kann die Nutzung von KI-Diensten, die sich in derselben Cloud-Infrastruktur befinden, ein besseres Preis-Leistungs-Verhältnis bieten als das Deployment eines eigenen lizenzierten KI-Modells, wenn Ihre Datenverarbeitung bereits cloudbasiert ist, beispielsweise bei einer E-Commerce-Website, die aus Gründen der Zuverlässigkeit und Erreichbarkeit in der Cloud gehostet wird. Sie sind ohnehin schon von Ihrem Cloud-Dienstanbieter abhängig, daher stellt die Abhängigkeit von seinen KI-Diensten kein großes zusätzliches Risiko dar.

Wenn Ihr Anwendungsfall dieser Beschreibung entspricht, stehen Ihnen Jina AI-Modelle auf EIS, im AWS Marketplace und auf der Google Cloud Platform speziell für Ihre Anforderungen zur Verfügung.

Die folgende Tabelle fasst die wichtigsten Faktoren zusammen. Ihre Antwort hängt von Ihren Daten, Ihrer Infrastruktur und Ihrem Nutzungsmuster ab.

Faktor

On-Prem bevorzugt

Cloud-API bevorzugt

Nutzungsmuster

Kontinuierliche oder Inferenz mit hohem Volumen

Intermittierende oder Batch-Verarbeitung

Datensensibilität

Reguliert, souverän oder klassifiziert

Keine grenzüberschreitenden oder durch Dritte auferlegten Einschränkungen

Netzwerkumgebung

Air-Gap, durch Firewall geschützt oder unzuverlässig

Stabiles, stets verfügbares Internet

Bestehende Infrastruktur

Im Besitz von GPU-Hardware oder Möglichkeit zur Beschaffung

Bereits in der Cloud mit KI-Colocation gehostet

Kostenmodell

Feste Hardware + Lizenz; vorhersehbare Kosten beim Skalieren

Pro Token; geringere Vorabkosten, variable langfristige Kosten

Latenztoleranz

Keine (Robotik, Edge, Echtzeit)

Netzwerkvariabilität ist akzeptabel

Operative Verantwortung

Ihr Team verwaltet die Hardware und Verfügbarkeit

Der Anbieter verwaltet die Hardware und die Updates; Sie verwalten die Integration

Sie müssen die Kosten und den Nutzen unter Berücksichtigung Ihrer individuellen Umstände und Anwendungsfälle abwägen und dabei die im vorigen Abschnitt hervorgehobenen Punkte berücksichtigen, die auf Sie zutreffen. Die Kosten-Nutzen-Analyse wird sich im Laufe der Zeit zweifellos ändern. Wir können die Zukunft der KI-Branche oder die Hardwarepreise nicht einmal kurzfristig vorhersagen.

Einführung von Jina On-Prem

Für Nutzer, die von lokalen KI-Diensten profitieren können, führen wir Jina On-Prem ein, ein vollständig eigenständiges Installationspaket für die leistungsstarken Modelle von Jina AI.

Die Modelle von Jina AI erreichen die gleiche Genauigkeit wie Einbettungsmodelle, die ein Vielfaches ihrer Größe haben, und senken dabei die Rechenkosten, den Speicherbedarf und die Hardwareanforderungen. Dadurch sind sie eine ideale Wahl für Nutzer, die ihre KI On-Prem betreiben möchten oder müssen. Kommerzielle Lizenzen sind mit skalierbaren, preislich gestaffelten Lösungen für Anwendungsfälle aller Größen verfügbar.

Welche API-Schemata unterstützt Jina On-Prem?

• Erhältlich als vollständige Sammlung von Abhängigkeiten für die lokale Installation oder als Docker-Container, den Sie innerhalb weniger Minuten installieren und ausführen können.

• Jina-On-Prem-Installationen rufen keine externen Systeme auf.

  • Es erfolgt kein Aufruf des Hugging Face Hub oder einer Modellregistrierung (HF_HUB_OFFLINE=1 und TRANSFORMERS_OFFLINE=1 sind fest integriert).

  • Es gibt keinen Lizenzserver.

  • Es gibt keine Telemetrie- oder Logging-Endpoints.

• Unterstützt sowohl CPU- als auch GPU-Hardware mit automatischer GPU-Erkennung.

• Alle 28 verfügbaren Jina-AI-Modelle, einschließlich der neuesten multimodalen Einbettungsmodelle jina-embeddings-v5-omni und jina-reranker-v3.

• Zugriff über gängige KI-API-Schemata: Jina API, OpenAI, Cohere, Voyage AI und Gemini. Jina On-Prem ist eine sofort einsatzbereite Lösung für Anwendungen, die auf diesen Schemata basieren.

• Drop-in-Ersatz für Modelle, die über den EIS bereitgestellt werden. Jina On-Prem lässt sich direkt in Elastic-Deployments mit Air-Gap integrieren.

Hardwareanforderungen für Jina AI-On-Prem-Modelle

Die Hardwareanforderungen variieren je nach Jina-Modell. Die folgende Tabelle zeigt die Empfehlungen für die neuesten Modelle unter Verwendung von GPU-Einstellungen. Sie benötigen keine leistungsstärkere GPU als eine NVIDIA L4, allerdings wird für die v5-Einbettungsmodelle eine A100 empfohlen. Unser neuestes Einbettungsmodell erfordert derzeit mindestens 8 GB VRAM.

Modell

Mindest-VRAM

Empfohlene GPU

jina-embeddings-v5-text-nano

2 GB

T4 / L4

jina-embeddings-v5-text-small

3 GB

L4 / A10G

jina-embeddings-v5-omni-small

8 GB

L4 / A10G / A100

jina-reranker-v3

3 GB

L4

jina-clip-v2

4 GB

L4

jina-code-embeddings-1.5b

4 GB

L4

ReaderLM-v2

4 GB

L4

Wenn Sie mehr als ein Modell gleichzeitig verwenden, steigen die VRAM-Anforderungen. Weitere Informationen finden Sie auf der Seite Größen und Hardware.

So installieren Sie Jina On-Prem mit Docker

Der schnellste Weg für den Einstieg ist die Installation von Docker (sofern noch nicht geschehen) und das Befolgen der Anweisungen auf der Seite Jina On-Prem Quick Start.

Für alle 28 Jina-Modelle stehen vorkonfigurierte Docker-Container zur Verfügung. Laden Sie ein Modell herunter und übertragen Sie es auf Ihr Installationsziel – schon können Sie Jina-AI-Modelle in weniger als fünf Minuten ausführen.

Für multimodale oder benutzerdefinierte Builds oder zum Herunterladen des vollständigen Abhängigkeitssatzes für die Installation außerhalb eines Containers befolgen Sie bitte die Schritte, die in der Bundling-Anleitung beschrieben sind.

Ihre Jina-On-Prem-Installation unterstützt alle Jina-API- und EIS-Funktionen sowie die Generierung von Einbettungen über die APIs von OpenAI, Cohere, Voyage AI und Gemini, sodass sie sich über Standardschnittstellen in bereits vorhandene Anwendungen integrieren lässt. Weitere Informationen finden Sie in der API-Dokumentation.

Jina-Modelle, einschließlich der mit Jina On-Prem installierten Modelle, sind unter verschiedenen Lizenzbedingungen erhältlich, wobei die neuesten Modelle für die nichtkommerzielle Nutzung unter einer CC BY-NC 4.0-Lizenz kostenlos zur Verfügung stehen. Für die Lizenzierung von Jina On-Prem für die kommerzielle Nutzung wenden Sie sich bitte an Elastic Sales.

Dieser Beitrag erklärt, wie die Abfrage-, Discovery- und Metadaten-Endpunkte auf der früheren Ingest- und Abfragearbeit aufbauen, um diese API-Oberfläche zu formen. In Begleitbeiträgen werden einzelne Aspekte näher beleuchtet:

• Native PromQL-Unterstützung in ES|QL beschreibt, wie PromQL-Abfragen in ES|QL-Ausführungspläne übersetzt werden.

• Prometheus-Metriken mit Remote Write an Elasticsearch versenden behandelt die Einrichtung der Ingestion.

• So funktioniert die Prometheus Remote Write Ingestion in Elasticsearch behandelt die internen Abläufe von Remote Write.

Dieses Projekt läuft noch. In den folgenden Abschnitten wird aufgeführt, was derzeit unterstützt wird und welche Teile sich noch in der Entwicklung befinden.

Die API-Oberfläche

Heute fällt die Prometheus-kompatible API-Oberfläche in drei Gruppen.

Abfrage-Endpoints

Die Abfrage-Endpoints ermöglichen Prometheus-kompatiblen Clients die Auswertung von PromQL-Ausdrücken:

• GET /_prometheus/api/v1/query_range wertet einen PromQL-Ausdruck über ein Zeitfenster aus (Matrix-Ergebnisse).

• GET /_prometheus/api/v1/query wertet zu einem einzelnen Zeitpunkt aus (Vektor-Ergebnisse). Derzeit als Kurzbereichsabfrage implementiert, die die letzte Stichprobe zurückgibt.

Aktuell wird nur GET als Abfrage-Endpoint unterstützt. Einige Clients verwenden standardmäßig POST, so dass Sie sie möglicherweise auf GET umstellen müssen. Die Prometheus POST-Konvention verwendet application/x-www-form-urlencoded-Bodies, die von der HTTP-Schicht von Elasticsearch als CSRF-Schutzmaßnahme abgelehnt werden, bevor die Anfrage überhaupt den Handler erreicht.

Den vollständigen PromQL-Abdeckungsstatus finden Sie im Begleitbeitrag zu PromQL in ES|QL.

Metadaten-Endpoints

Die Metadaten-Endpoints liefern die Discovery-Informationen, die Kunden für Autovervollständigung, Variablen-Dropdowns und das Durchsuchen von Metriken benötigen.

Die Endpunkte für Serien, Labels und Labelwerte akzeptieren alle match[]-Selektoren und einen Zeitbereich (start/end). Der Parameter match[] nimmt einen Prometheus-Serienselektor wie http_requests_total{job="api"} entgegen und beschränkt die Reaktion auf passende Zeitreihen. Dadurch bleiben die Reaktionen auf Clustern mit einer großen Anzahl von Metriken schnell und relevant. Zum Beispiel:

Die erste gibt alle Serien für http_requests_total zurück, wobei job="api" gilt, zusammen mit ihren vollständigen Label-Sets. Die zweite gibt nur die Label-Namen zurück, die in der http_requests_total-Serie existieren. Die dritte gibt nur die instance Werte zurück, die in übereinstimmenden Reihen vorkommen.

GET /_prometheus/api/v1/metadata ist anders: Pro Metrik werden nur Typ und Einheit zurückgegeben, optional gefiltert nach Namen über einen metric-Parameter.

match[]-Selektoren oder ein Zeitbereich werden nicht akzeptiert. In Prometheus werden Metadaten von aktiven Scrape-Zielen gesammelt (die Zeilen HELP, TYPE und UNIT, die sie anzeigen), sodass die Reaktion keinen Datenscan beinhaltet. Elasticsearch verfügt über keinen dedizierten Metadatenspeicher dieser Art, daher ermittelt die aktuelle Implementierung Metrik-Metadaten, indem sie Zeitreihendaten der letzten 24 Stunden durchsucht. Dadurch bleibt die Abfrage schnell, ohne dass ein vollständiger Indexscan erforderlich ist. Diese 24-Stunden-Rückschau ist derzeit fest vorgegeben: Die Prometheus-Metadaten-API stellt keine start- oder end-Parameter zur Verfügung, die Elasticsearch verwenden könnte, um sie für den Nutzer anpassbar zu machen.

Wie die Metadaten-Endpunkte im Hintergrund funktionieren, einschließlich der Befehle TS_INFO und METRICS_INFO, auf denen sie basieren, wird im Folgenden erläutert.

Index-Vorfilterung

Alle Abfrage- und Metadaten-Endpoints akzeptieren ein optionales {index}-Pfadsegment nach /_prometheus/:

Dies schränkt ein, gegen welche Elasticsearch-Indizes die Abfrage ausgeführt wird, bevor mit der Auswertung des Ausdrucks begonnen wird. In Clustern mit vielen Datenströmen, die sich über Teams oder Umgebungen erstrecken, verhindert dies das Durchsuchen irrelevanter Indizes und kann die Latenz bei Abfragen erheblich verringern. Sie können pro Indexmuster separate Datenquellen konfigurieren, um Teams gezielten Zugriff auf ihre eigenen Metriken zu gewähren.

Eine Anmerkung zum Remote Write

Für die Ingestion stellt Elasticsearch auch den standardmäßigen Prometheus Remote Write-Endpoint bereit:

• POST /_prometheus/api/v1/write nimmt Zeitreihen über das Prometheus Remote Write v1-Protokoll auf. v2 wird noch nicht unterstützt.

Remote Write schreibt in die bestehenden Zeitreihendatenströme (TSDS) von Elasticsearch und nicht in eine separate, Prometheus-spezifische Speicherschicht. Prometheus-Labels werden zu TSDS-Dimensionen, und Metriknamen werden zu Feldern im Index-Mapping. Der Beitrag zur Architektur von Remote Write behandelt das vollständige Mapping im Detail, einschließlich der Ableitung von Metriktypen und der Speicherung von Labels mit einem labels.-Präfix.

So funktionierts

Im Hintergrund funktionieren alle Endpoints auf die gleiche Weise: Sie parsen die eingehenden HTTP-Parameter, erstellen einen ES|QL-Abfrageplan, führen ihn für Zeitreihendatenströme aus und konvertieren das spaltenorientierte Ergebnis zurück in das von Prometheus-Clients erwartete JSON-Format.

TS_INFO und METRICS_INFO

Die Metadaten-Endppoints müssen Fragen beantworten wie „Welche Labels existieren?“ oder „Welche Metriktypen sind definiert?“, und das über potenziell Millionen von Zeitreihen hinweg, ohne jeden einzelnen Datenpunkt zu prüfen.

Intern beantworten die Prometheus-Metadaten-Endpoints diese Fragen, indem sie ES|QL-Pläne um zwei neue Verarbeitungsbefehle erstellen: METRICS_INFO und TS_INFO. Sie müssen diese Befehle nicht direkt verwenden, um die Prometheus-API zu nutzen, doch sie bilden die Kernausführungsprimitive hinter den Metadatenantworten. Beide funktionieren, indem sie nur ein Dokument pro Zeitreihe aufrufen, um dessen Metadaten zu extrahieren, anstatt alle Stichproben zu scannen. Das bedeutet, dass sich ihre Kosten proportional zur Anzahl der einzelnen Zeitreihen und nicht zur Anzahl der Datenpunkte verhalten.

METRICS_INFO gibt eine Zeile pro eindeutiger Metrik mit ihrem Namen, Typ, Einheit und zugehörigen Dimensionsfeldern zurück. TS_INFO ist detaillierter: eine Zeile pro Kombination aus Metrik und Zeitreihe, einschließlich der tatsächlichen Dimensionswerte als JSON-Objekt.

Ein eigener Blogbeitrag zu TS_INFO und METRICS_INFO folgt in Kürze. Er behandelt das zweiphasige Ausführungsmodell, wie sie skaliert werden und wie sie direkt in ES|QL-Abfragen außerhalb der Prometheus-API verwendet werden können.

So werden sie von den Metadaten-Endpoints verwendet

Jeder Metadaten-Endpoint konstruiert einen ES|QL-Plan mit einem dieser Befehle im Kern.

/api/v1/labels und /api/v1/series verwenden TS_INFO, da sie detaillierte Daten pro Zeitreihe benötigen (welche Labels existieren, welche Dimensionswerte jede Reihe identifizieren). /api/v1/metadata und /api/v1/label/__name__/values verwenden METRICS_INFO, da sie nur Informationen pro Metrik benötigen (Metriknamen, Typen, Einheiten).

/api/v1/label/{name}/values Für reguläre Labels (alles außer __name__) wird keiner der beiden Befehle verwendet. Reguläre Labels wie job oder instance sind tatsächliche Dimensionsfelder im Index, sodass der Endpoint sie direkt mit einer Gruppenaggregation abfragen kann. Wenn match[] Selektoren bereitgestellt werden, werden sie in eine WHERE-Klausel übersetzt, die die Zeitreihen filtert, bevor die Aggregation ausgeführt wird.

Das __name__-Label erfordert eine andere Strategie, da es nicht immer als Dimensionsfeld vorhanden ist. Prometheus Remote Write speichert labels.__name__, aber Metriken, die über andere Pfade (OpenTelemetry, die Bulk-API) aufgenommen werden, enthalten es nicht. Der metrische Name ist im Feldnamen selbst kodiert (z. B. metrics.http_requests_total). Sie könnten sich die Index-Mappings ansehen, um die Feldnamen aufzulisten, aber Mappings allein geben keinen Aufschluss darüber, welche Metrik welche Dimensionen aufweist, und sie lassen sich nicht nach Labelwerten aus einem match[]-Selektor filtern. METRICS_INFO kann beides: Es zählt Metriknamen über Indizes auf, während es Upstream-Filter WHERE berücksichtigt.

In allen Fällen übernimmt die API-Ebene die Rückübersetzung in die Prometheus-Konventionen: indem sie die Speicherpräfixe labels. und metrics. entfernt und __name__ für Nicht-Prometheus-Metriken ergänzt, denen ein solches Präfix fehlt.

Fazit

Das Ergebnis: Jeder Prometheus-kompatible Client kann Elasticsearch-Metriken über bereits verstehende Endpunkte abfragen und erkunden. Remote Write-Metriken, OpenTelemetry-Metriken und Metriken, die über andere Pfade indiziert werden, werden alle über dieselbe API angezeigt, die von denselben TSDS-Indizes unterstützt wird.

Alle hier erwähnten Prometheus-APIs sind heute als technische Vorschau in Elasticsearch Serverless verfügbar. Für selbstverwaltete Cluster und Elastic Cloud Hosted Deployments, verfügbar als technische Vorschau in Elasticsearch 9.4, mit Ausnahme von GET /_prometheus/api/v1/metadata. Um lokal zu experimentieren, verwenden Sie start-local.

In diesem Artikel untersuchen wir die Vorteile der Entwicklung eines benutzerdefinierten Elasticsearch MCP-Servers und zeigen, wie man einen in TypeScript erstellt, der Elasticsearch mit LLM-gestützten Anwendungen verbindet.

Warum einen benutzerdefinierten Elasticsearch MCP-Server entwickeln?

Elastic bietet einige Alternativen für MCP-Server:

• Elastic Agent Builder MCP-Server für Elasticsearch 9.2+

• Elasticsearch MCP-Server für ältere Versionen (Python)

Wenn Sie mehr Kontrolle darüber benötigen, wie Ihr MCP-Server mit Elasticsearch interagiert, bietet Ihnen die Entwicklung eines eigenen benutzerdefinierten Servers die nötige Flexibilität, um ihn genau an Ihre Bedürfnisse anzupassen. Zum Beispiel ist der MCP-Endpoint von Agent Builder auf Elasticsearch Query Language (ES|QL) Abfragen beschränkt, während ein benutzerdefinierter Server die Verwendung des vollständigen Abfrage-DSL ermöglicht. Sie erhalten außerdem die Kontrolle über die Formatierung der Ergebnisse, bevor sie an das LLM weitergeleitet werden, und können zusätzliche Verarbeitungsschritte integrieren, wie die OpenAI-gestützte Zusammenfassung, die wir in dieses Tutorial implementieren.

Am Ende dieses Artikels verfügen Sie über einen MCP-Server in TypeScript, der in einem Elasticsearch-Index gespeicherte Informationen durchsucht, zusammenfasst und Zitate bereitstellt. Wir verwenden Elasticsearch für den Abruf, das gpt-4o-mini-Modell von OpenAI zur Zusammenfassung und Erzeugung von Zitaten sowie Claude Desktop als MCP-Client und Benutzeroberfläche, um Nutzeranfragen zu empfangen und darauf zu reagieren. Das Endergebnis ist ein interner Wissensassistent, der Entwicklern dabei hilft, Best Practices in der technischen Dokumentation ihres Unternehmens zu entdecken und zu synthetisieren.

Voraussetzungen:

• Node.js 20+

• Elasticsearch

• OpenAI-API-Schlüssel

• Claude Desktop

Was ist MCP?

MCP ist ein offener Standard, der von Anthropic entwickelt wurde und sichere, bidirektionale Verbindungen zwischen LLMs und externen Systemen wie Elasticsearch ermöglicht. Mehr über den aktuellen Stand von MCP können Sie in diesem Artikel lesen.

Die MCP-Landschaft entwickelt sich täglich weiter, wobei Server für eine Vielzahl von Anwendungsfällen zur Verfügung stehen. In diesem Artikel zeigen wir Ihnen außerdem, wie einfach es ist, Ihren eigenen benutzerdefinierten MCP-Server zu entwickeln.

MCP-Clients

Es gibt eine lange Liste verfügbarer MCP-Clients, von denen jeder seine eigenen Eigenschaften und Einschränkungen hat. Aufgrund seiner Einfachheit und Beliebtheit verwenden wir Claude Desktop als unseren MCP-Client. Er dient als Chat-Schnittstelle, auf der Nutzer Fragen in natürlicher Sprache stellen können, und ruft automatisch die von unserem MCP-Server bereitgestellten Tools auf, um Dokumente zu durchsuchen und Zusammenfassungen zu erstellen.

Erstellen eines Elasticsearch MCP-Servers

Mit dem TypeScript SDK können wir einfach einen Server erstellen, der versteht, wie er unsere Elasticsearch-Daten basierend auf einer Nutzereingabe abfragt.

In diesem Artikel werden die folgenden Schritte zur Integration des Elasticsearch MCP-Servers mit dem Claude Desktop-Client beschrieben:

1. MCP-Server für Elasticsearch konfigurieren.

2. MCP-Server in Claude Desktop laden.

3. Probieren Sie es aus.

MCP-Server für Elasticsearch konfigurieren

Zunächst initialisieren wir eine Node-Anwendung:

Dadurch wird eine package.json-Datei erstellt, wodurch wir damit beginnen können, die notwendigen Abhängigkeiten für diese Anwendung zu installieren.

• @elastic/elasticsearch verschafft Ihnen Zugriff auf die Node.js-Bibliothek von Elasticsearch.

• @modelcontextprotocol/SDK stellt die Kerntools bereit, um einen MCP-Server zu erstellen und zu verwalten, Tools zu registrieren und die Kommunikation mit MCP-Clients zu übernehmen.

• OpenAI ermöglicht die Interaktion mit OpenAI-Modellen, um Zusammenfassungen oder Antworten in natürlicher Sprache zu generieren.

• ZODsorgt dafür, strukturierte Schemata für Eingangs- und Ausgangsdaten in jedem Tool zu definieren und zu validieren.

ts-nodeWährend der Entwicklung werden @types/node und typescript verwendet, um den Code zu schreiben und die Skripte zu kompilieren.

Datensatz einrichten

Um die Daten bereitzustellen, die Claude Desktop über unseren MCP-Server abfragen kann, verwenden wir einen simulierten internen Wissensdatenbank-Datensatz. So sieht ein Dokument aus diesem Datensatz aus:

Für die Aufnahme der Daten haben wir ein Skript vorbereitet, das einen Index in Elasticsearch erstellt und den Datensatz darin lädt. Sie finden es hier.

MCP-Server

Erstellen Sie eine Datei mit dem Namen index.ts und fügen Sie den folgenden Code hinzu, um die Abhängigkeiten zu importieren und Umgebungsvariablen zu verarbeiten:

Außerdem initialisieren wir die Clients, um Elasticsearch- und OpenAI-Aufrufe zu bewältigen:

Um unsere Implementierung robuster zu machen und einen strukturierten Eingang und Ausgang zu gewährleisten, definieren wir Schemata mit zod. Dadurch können wir Daten zur Laufzeit validieren, Fehler frühzeitig abfangen und die Tool-Reaktionen einfacher programmatisch verarbeiten.

Erfahren Sie hier mehr über strukturierte Ausgänge.

Nun initialisieren wir den MCP-Server:

Definition der MCP-Tools

Wenn alles konfiguriert ist, können wir mit dem Schreiben der Tools beginnen, die von unserem MCP-Server bereitgestellt werden. Dieser Server stellt zwei Tools bereit:

• search_docs: Sucht nach Dokumenten in Elasticsearch mittels Volltextsuche.

• summarize_and_cite: Fasst Informationen aus zuvor abgerufenen Dokumenten zusammen und synthetisiert sie, um eine Nutzerfrage zu beantworten. Dieses Tool fügt außerdem Zitate hinzu, die auf die Quelldokumente verweisen.

Zusammen bilden diese Tools einen einfachen Workflow zum Abrufen und Zusammenfassen, bei dem ein Tool relevante Dokumente abruft und das andere diese Dokumente verwendet, um eine zusammengefasste, zitierte Reaktion zu generieren.

Reaktionsformat des Tools

Jedes Tool kann beliebige Eingangsparameter akzeptieren, muss aber mit folgender Struktur antworten:

• Inhalt: Dies ist die Reaktion des Tools im unstrukturierten Format. Dieses Feld wird in der Regel verwendet, um Text, Bilder, Audio, Links oder Einbettungen zurückzugeben. In dieser Anwendung dient es dazu, formatierten Text mit den Informationen zurückzugeben, die von den Tools generiert wurden.

• structuredContent: Dies ist eine optionale Rückgabe, die verwendet wird, um die Ergebnisse der einzelnen Tools in einem strukturierten Format bereitzustellen. Dies ist für programmatische Zwecke nützlich. Zwar wird es in diesem MCP-Server nicht verwendet, es kann jedoch von Nutzen sein, wenn Sie andere Tools entwickeln oder die Ergebnisse programmatisch verarbeiten möchten.

Vor diesem Hintergrund betrachten wir nun jedes Tool im Detail.

Tool „Search_docs“

Dieses Tool führt eine Volltextsuche im Elasticsearch-Index durch, um die relevantesten Dokumente basierend auf der Nutzeranfrage abzurufen. Es hebt die wichtigsten Treffer hervor und bietet einen schnellen Überblick mit Relevanzbewertungen.

Wir konfigurieren fuzziness: “AUTO” so, dass eine variable Tippfehlertoleranz basierend auf der Länge des analysierten Tokens besteht. Wir legen außerdem title^2 fest, um die Bewertung der Dokumente zu erhöhen, bei denen die Übereinstimmung im Feld „Titel“ erfolgt.

Tool „summarize_and_cite“

Dieses Tool erstellt eine Zusammenfassung auf Basis von Dokumenten, die bei der vorherigen Suche ermittelt wurden. Es verwendet das gpt-4o-mini-Modell von OpenAI, um die relevantesten Informationen zur Beantwortung der Nutzerfragen zu synthetisieren und Antworten zu liefern, die direkt aus den Suchergebnissen abgeleitet werden. Neben der Zusammenfassung werden auch Metadaten für Zitate zu den verwendeten Quelldokumenten zurückgegeben.

Zu guter Letzt starten wir den Server mithilfe von stdio. Das bedeutet, dass der MCP-Client mit unserem Server kommuniziert, indem er seine standardmäßigen Eingangs- und Ausgangsstreams liest und schreibt. stdio ist die einfachste Transportoption und funktioniert gut für lokale MCP-Server, die vom Client als Unterprozesse gestartet werden. Fügen Sie den folgenden Code am Ende der Datei hinzu:

Kompilieren Sie das Projekt jetzt mit folgendem Befehl:

Dadurch wird ein Ordner dist erstellt und darin eine Datei index.js.

Laden Sie den MCP-Server in Claude Desktop

Folgen Sie dieser Anleitung, um den MCP-Server mit Claude Desktop zu konfigurieren. In der Konfigurationsdatei von Claude müssen die folgenden Werte festgelegt werden:

Der Wert args sollte auf die kompilierte Datei im Ordner dist verweisen. Außerdem müssen Sie die Umgebungsvariablen in der Konfigurationsdatei mit genau den gleichen Namen festlegen, die im Code definiert sind.

Probieren Sie es aus

Klicken Sie vor der Ausführung jedes Tools auf Search and Tools, um sicherzustellen, dass die Tools aktiviert sind. Hier können Sie außerdem alle Funktionen aktivieren oder deaktivieren:

Zum Schluss testen wir den MCP-Server über den Claude Desktop-Chat und beginnen, Fragen zu stellen:

Für die Frage „Suche nach Dokumenten zu Authentifizierungsmethoden und RBAC“ wird das search_docs-Tool ausgeführt und liefert folgende Ergebnisse:

Die Reaktion lautet: „Großartig! Ich habe 5 relevante Dokumente über Authentifizierungsmethoden und RBAC gefunden. Folgendes wurde gefunden:“

Der Toolaufruf gibt die Quelldokumente als Teil seiner Reaktionnutzlast zurück, die später zur Erstellung von Zitaten verwendet werden.

Es ist auch möglich, mehrere Tools in einer einzigen Interaktion zu verketten. In diesem Fall analysiert Claude Desktop die Frage des Nutzers und stellt fest, dass zunächst search_docs aufgerufen werden muss, um relevante Dokumente abzurufen, und dass diese Ergebnisse anschließend an summarize_and_cite übergeben werden müssen, um die endgültige Antwort zu generieren, ohne dass dafür separate Prompts vom Nutzer erforderlich sind:

In diesem Fall haben wir für die Abfrage „Was sind die wichtigsten Empfehlungen zur Verbesserung der Authentifizierung und Zugriffssteuerung in unseren Systemen? Referenzen einbeziehen.“ folgende Ergebnisse erzielt:

Wie im vorherigen Schritt können wir die Reaktion jedes Tools auf diese Frage einsehen:

Hinweis: Wenn ein Untermenü erscheint, in dem gefragt wird, ob Sie die Nutzung jedes Tools genehmigen möchten, wählen Sie Immer erlauben oder Einmal erlauben.

Fazit

MCP-Server stellen einen bedeutenden Schritt zur Standardisierung von LLM-Tools für lokale und entfernte Anwendungen dar. Die vollständige Kompatibilität ist zwar noch in Bearbeitung, wir verzeichnen jedoch große Fortschritte in diese Richtung.

In diesem Artikel haben wir gelernt, wie man einen benutzerdefinierten MCP-Server in TypeScript entwickelt, der Elasticsearch mit LLM-gestützten Anwendungen verbindet. Unser Server stellt zwei Tools bereit: search_docs zum Abrufen relevanter Dokumente mittels Abfrage-DSL und summarize_and_cite zur Erstellung von Zusammenfassungen mit Zitaten über OpenAI-Modelle und Claude Desktop als Client-Benutzeroberfläche.

Die Zukunft der Kompatibilität zwischen verschiedenen Client- und Server-Anbietern sieht vielversprechend aus. Zu den nächsten Schritten gehört die Erweiterung des Funktionsumfangs und die Erhöhung der Flexibilität Ihres Agenten. Es gibt einen praktischen Artikel dazu, wie Sie Ihre Abfragen mithilfe von Suchvorlagen für mehr Präzision und Flexibilität parametrisieren können.

Voraussetzungen

• Elasticsearch 9.3 oder Elastic Cloud Serverless: Sie können ein Cloud-Deployment erstellen, indem Sie diese Anweisungen befolgen, oder stattdessen den start-local Quickstart verwenden.

• Python 3.12: Laden Sie Python hier herunter.

• Hugging Face Zugriffstoken.

Chat-Abschlüsse unter Verwendung eines Inferenz-Endpoints von Hugging Face

Zuerst erstellen wir ein praktisches Beispiel, das Elasticsearch mit einem Hugging Face Inferenz-Endpoint verbindet, um KI-gestützte Empfehlungen aus einer Reihe von Blogbeiträgen zu generieren. Für die Wissensdatenbank der App verwenden wir einen Datensatz mit Blogartikeln des Unternehmens, der wertvolle, aber oft schwer zugängliche Informationen enthält.

Bei diesem Endpoint ruft die semantische Suche die relevantesten Artikel für eine gegebene Abfrage ab, und ein Hugging Face LLM generiert kurze, kontextuelle Empfehlungen basierend auf diesen Ergebnissen.

Verschaffen wir uns einen groben Überblick über den Informationsfluss, den wir entwickeln werden:

In diesem Artikel testen wir die Fähigkeit von SmolLM3-3B undkombinieren seine kompakte Größe mit einer starken mehrsprachigen Argumentations- und Tool-Aufruffunktion. Basierend auf einer Suchabfrage senden wir alle passenden Inhalte (auf Englisch und Spanisch) an das LLM, um eine Liste empfohlener Artikel mit einer individuell erstellten Beschreibung basierend auf der Suchanfrage und den Ergebnissen zu erstellen.

So könnte die Benutzeroberfläche einer Artikelseite mit einem System zur Generierung von KI-Empfehlungen aussehen.

Sie können die vollständige Implementierung dieser Anwendung im verlinkten Notizbuch finden.

Konfiguration der Elasticsearch Inferenz-Endpoints

Um den Elasticsearch Hugging Face Inferenz-Endpoint zu verwenden, benötigen wir zwei wichtige Elemente: einen Hugging Face API-Schlüssel und eine ausgeführte Hugging Face Endpoint-URL. Dies sollte so aussehen:

Der Hugging Face Inferenz-Endpoint in Elasticsearch unterstützt verschiedene Aufgabentypen: text_embedding, completion, chat_completion und rerank. In diesem Blogbeitrag verwenden wir chat_completion, weil das Modell Gesprächsempfehlungen basierend auf den Suchergebnissen und einem Systemprompt generieren kann. Dieser Endpoint ermöglicht es uns, Chatabschlüsse direkt von Elasticsearch aus auf einfache Weise mit der Elasticsearch-API durchzuführen:

Dies dient als Kern der Anwendung, der den Prompt und die Suchergebnisse empfängt, die durch das Modell laufen werden. Nachdem die Theorie geklärt ist, können wir mit der Implementierung der Anwendung beginnen.

Einrichten des ​​Inferenz-Endpoints auf Hugging Face

Um das Hugging Face Modell bereitzustellen, werden wir Hugging Face One-Click-Deployments verwenden, einen einfachen und schnellen Service für die Bereitstellung von Modell-Endpoints. Beachten Sie bitte, dass es sich um einen kostenpflichtigen Service handelt, durch dessen Nutzung zusätzliche Kosten entstehen können. In diesem Schritt wird die Modellinstanz erstellt, die zur Generierung der Empfehlungen für die Artikel verwendet wird.

Sie können ein Modell aus dem Ein-Klick-Katalog aussuchen:

Wählen Sie das SmolLM3-3B Modell:

Hier können Sie die URL des Hugging Face Endpoints abrufen:

Wie in der Dokumentation zu den Hugging Face Inferenz-Endpunkten von Elasticsearch erwähnt, erfordert die Textgenerierung ein Modell, das mit der OpenAI-API kompatibel ist. Aus diesem Grund müssen wir den /v1/chat/completions-Subpfad an die Hugging Face Endpoint-URL anhängen. Das Ergebnis sieht wie folgt aus:

Mit dieser Voraussetzung können wir mit dem Codieren in einem Python-Notebook beginnen.

API-Schlüssel für Hugging Face generieren

Erstellen Sie ein Hugging Face Konto und erhalten Sie ein API-Token, indem Sie diesen Anweisungen folgen. Man kann zwischen drei Token-Typen wählen: detailliert (empfohlen für die Produktion, da es nur Zugriff auf bestimmte Ressourcen bietet); Lesezugriff (schreibgeschützt); oder Schreibzugriff (für Lese- und Schreibzugriff). Für dieses Tutorial ist ein Lesezugriffstoken ausreichend, da wir nur den Inferenz-Endpoint aufrufen müssen. Speichern Sie diesen Code für den nächsten Schritt.

Einrichten des Elasticsearch Inferenz-Endpoints

Zunächst legen wir einen Elasticsearch-Python-Client fest:

Danach erstellen wir einen Elasticsearch Inferenz-Endpoint, der das Hugging Face Modell verwendet. Dieser Endpoint ermöglicht es uns, Reaktionen zu generieren, die auf den Blogbeiträgen und dem an das Modell übergebenen Prompt basieren.

Datensatz

Der Datensatz enthält die Blogbeiträge, die abgefragt werden, und repräsentiert einen mehrsprachigen Inhaltssatz, der im gesamten Workflow verwendet wird:

Elasticsearch-Mappings

Mit dem definierten Datensatz müssen wir ein Datenschema erstellen, das der Struktur des Blogbeitrags entspricht. Die folgenden Index-Mappings werden verwendet, um die Daten in Elasticsearch zu speichern:

Hier können wir klar erkennen, wie die Daten strukturiert sind. Wir werden die semantische Suche verwenden, um Ergebnisse basierend auf natürlicher Sprache abzurufen, zusammen mit der copy_to-Eigenschaft, um den Feldinhalt in das semantic_text-Feld zu kopieren. Zusätzlich enthält das title-Feld zwei Unterfelder: Das original-Unterfeld speichert den Titel entweder auf Englisch oder Spanisch, abhängig von der Originalsprache des Artikels, und das translated_title-Unterfeld ist nur für spanische Artikel vorhanden und enthält die englische Übersetzung des Originaltitels.

Ingestieren von Daten

Der folgende Code-Schnipsel überträgt den Datensatz des Blogbeitrags in Elasticsearch mithilfe der Bulk-API:

Nun, da wir die Artikel in Elasticsearch aufgenommen haben, müssen wir eine Funktion erstellen, die nach dem Feld semantic_text sucht:

Wir benötigen außerdem eine Funktion, die den Endpoint aufruft. In diesem Fall rufen wir den Endpoint mit dem chat_completionAufgabentyp auf, um Streaming-Antworten zu erhalten:

Nun können wir eine Funktion schreiben, die die semantische Suchfunktion, den chat_completions Inferenz-Endpoint und den Empfehlungs-Endoint aufruft, um die Daten zu generieren, die in den Karten angezeigt werden:

Abschließend müssen wir die Informationen extrahieren und formatieren, um sie zu drucken:

Wir führen einen Test durch, indem wir eine Frage zu den Sicherheitsblogbeiträgen stellen:

Hier sehen wir die vom Workflow in der Konsole generierten Karten:

Die vollständigen Ergebnisse, einschließlich aller Treffer und der LLM-Reaktion, können Sie in dieser Datei sehen.

Wir bitten um Artikel zum Thema: „Sicherheit und Schwachstellen“. Diese Frage wird als Suchabfrage gegen die in Elasticsearch gespeicherten Dokumente verwendet. Die abgerufenen Ergebnisse werden dann an das Modell weitergegeben, das basierend auf ihrem Inhalt Empfehlungen generiert. Wie wir sehen können, hat das Modell gute Arbeit geleistet und einen ansprechenden kurzen Text erstellt, der den Leser zum Anklicken motivieren kann.

Fazit

Dieses Beispiel zeigt, wie Elasticsearch und Hugging Face kombiniert werden können, um ein schnelles und effizientes zentrales System für KI-Anwendungen zu schaffen. Dieser Ansatz reduziert den manuellen Aufwand und bietet dank des umfangreichen Modellkatalogs von Hugging Face mehr Flexibilität. Insbesondere die Verwendung von SmolLM3-3B zeigt, wie kompakte, mehrsprachige Modelle in Kombination mit semantischer Suche weiterhin sinnvolles Schlussfolgern und Content-Generierung liefern können. Zusammen bieten diese Tools eine skalierbare und effektive Grundlage für die Entwicklung intelligenter Inhaltsanalysen und mehrsprachiger Anwendungen.

Die Erweiterung ist hier als Open-Source-Projekt verfügbar.

Was ist Gemini CLI, und wie installieren Sie sie?

Gemini CLI ist ein Open-Source-KI-Agent, der Googles Gemini-Modelle direkt in die Befehlszeile bringt. Er ermöglicht Entwicklern, über das Terminal mit KI zu interagieren, um Aufgaben wie das Generieren von Code, das Bearbeiten von Dateien, das Ausführen von Shell-Befehlen und das Abrufen von Informationen aus dem Web durchzuführen.

Im Gegensatz zu typischen Chat-Schnittstellen integriert sich die Gemini CLI in Ihre lokale Entwicklungsumgebung. Das bedeutet, dass sie den Projektkontext versteht, Dateien ändert, Builds oder Tests ausführt und Workflows direkt im Terminal automatisiert. Dies macht sie besonders nützlich für Entwickler, Site Reliability Engineers (SREs) und Engineers, die KI-gestütztes Codieren und Automatisierung wünschen, ohne ihren Befehlszeilen-Workflow zu verlassen.

Gemini CLI kann mit mehreren Paketmanagern installiert werden. Die gängigste Methode ist die Installation über npm:

Wenn Sie sich über alternative Installationsmöglichkeiten informieren möchten, lesen Sie die offizielle Installationsseite.

Starten Sie die CLI nach der Installation durch Ausführen des folgenden Befehls:

Sie sehen einen Bildschirm, wie in Abbildung 1 dargestellt:

Elasticsearch konfigurieren

Wir benötigen eine laufende Elasticsearch-Instanz. Wenn Sie den Model Context Protocol (MCP)-Server verwenden möchten, benötigen Sie zudem Kibana 9.3+. Für die Nutzung der unten beschriebenen Elasticsearch Query Language (ES|QL)-Fähigkeit (esql) ist Kibana nicht erforderlich.

Sie können eine kostenlose Testversion auf Elastic Cloud aktivieren oder es lokal mit dem start-local-Skript installieren:

Dadurch werden Elasticsearch und Kibana auf Ihrem Computer installiert und ein API-Schlüssel generiert, den Sie für die Konfiguration von Gemini CLI verwenden können.

Der API-Schlüssel wird als Ausgabe des vorherigen Befehls angezeigt und in einer .env-Datei im Ordner elastic-start-local gespeichert.

Wenn Sie Elasticsearch lokal (zum Beispiel start-local), und Elastic Agent Builder mit MCP verwenden möchten, müssen Sie auch ein Large Language Model (LLM) verbinden. Lesen Sie diese Dokumentationsseite, um sich über die verschiedenen Optionen zu informieren.

Wenn Sie Elastic Cloud (oder serverless) verwenden, verfügen Sie bereits über eine vorgefertigte LLM-Verbindung.

Installieren Sie die Elasticsearch-Erweiterung

Sie können die Elasticsearch-Erweiterung für Gemini CLI mit folgendem Befehl installieren:

Sie können überprüfen, ob die Erweiterungen erfolgreich installiert wurden, indem Sie Gemini öffnen und den folgenden Befehl ausführen:

Die Elasticsearch-Erweiterung sollte verfügbar sein.

Wenn Sie die MCP-Integration verwenden möchten, müssen Sie die Elasticsearch-Version 9.3 oder höher installiert haben. Sie benötigen die URL Ihres MCP-Servers aus Kibana:

• Sie erhalten Ihre MCP-Server-URL unter Agenten > Alle Tools anzeigen > MCP verwalten > MCP-Server-URL kopieren.

• Die URL wird so aussehen: https://your-kibana-instance/api/agent_builder/mcp

Sie benötigen die URL des Elasticsearch-Endpoints. Dies wird üblicherweise oben auf der Kibana Elasticsearch-Seite angezeigt. Wenn Sie Elasticsearch mit start-local ausführen, ist der Endpoint bereits im Schlüssel ES_LOCAL_URL in der .env-Datei start-local hinterlegt.

Sie benötigen auch einen API-Schlüssel. Wenn Sie Elasticsearch mit start-local ausführen, ist der ES_LOCAL_API_KEY in der .env-Datei start-local hinterlegt. Andernfalls können Sie einen API-Schlüssel über die Kibana-Schnittstelle erstellen, wie hier beschrieben:

• In Kibana: Stack Management > Sicherheit > API-Schlüssel > API-Schlüssel erstellen.

• Wir empfehlen, nur die Leserechte für den API-Schlüssel festzulegen und so die hier beschriebene Berechtigung feature_agentBuilder.read zu aktivieren.

• Kopieren Sie den codierten API-Schlüsselwert.

Stellen Sie die erforderlichen Umgebungsvariablen in Ihrer Shell ein:

Installieren Sie den Beispieldatensatz

Sie können den Datensatz für E-Commerce-Bestellungen , der von Kibana verfügbar ist, installieren. Sie enthält einen einzigen Index mit dem Namen kibana_sample_data_ecommerce, der Informationen für 4.675 Bestellungen von einer E-Commerce-Website enthält. Für jede Bestellung haben wir folgende Informationen:

• Kundeninformationen (Name, Ausweis, Geburtsdatum, E-Mail-Adresse und mehr)

• Bestelldatum

• Bestell-ID

• Produkte (Liste aller Produkte mit Preis, Menge, ID, Kategorie, Rabatt und weiteren Details)

• SKU

• Gesamtpreis (ohne Steuern, mit Steuern)

• Gesamtmenge

• Geoinformationen (Stadt, Land, Kontinent, Ort, Region)

Um die Beispieldaten zu installieren, öffnen Sie die Seite Integrationen in Kibana (suchen Sie in der Suchleiste oben nach „Integration") und installieren Sie die Beispieldaten. Weitere Einzelheiten finden Sie in der Dokumentation hier.

Ziel dieses Artikels ist es, zu zeigen, wie einfach es ist, die Gemini CLI so zu konfigurieren, dass sie mit Elasticsearch verbunden ist und mit dem Index kibana_sample_data_ecommerce interagiert.

Verwendung des Elasticsearch MCP

Sie können die Verbindung mit folgendem Befehl in Gemini überprüfen:

Sie sollten sehen, dass elastic-agent-builder aktiviert ist, wie in Abbildung 2 dargestellt:

Elasticsearch bietet eine Reihe von Standardtools. Sehen Sie sich die Beschreibung hier an.

Mithilfe dieser Tools können Sie mit Elasticsearch interagieren und Fragen stellen wie:

• Give me the list of all the indexes available in Elasticsearch.

• How many customers are based in the USA in the kibana_sample_data_ecommerce index of Elasticsearch?

Je nach Frage wird Gemini eines oder mehrere der verfügbaren Tools verwenden, um sie zu beantworten.

Die /elastic-Befehle

In der Elasticsearch-Erweiterung für Gemini CLI haben wir auch/elastic-Befehlehinzugefügt.

Wenn Sie den Befehl /help ausführen, werden Ihnen alle verfügbaren /elastic-Optionen angezeigt (Abbildung 3):

Diese Befehle können nützlich sein, wenn Sie ein bestimmtes Tool des elastic-agent-builder-MCP-Servers direkt ausführen möchten. Beispielsweise können Sie mit dem folgenden Befehl das Mapping von kibana_sample_data_ecommerce abrufen:

Diese Befehle sind im Wesentlichen Abkürzungen für das Ausführen spezifischer Tools, anstatt sich auf das Gemini-Modell zu verlassen, um zu bestimmen, welches Tool aufgerufen werden sollte.

Verwendung der Elasticsearch-Fähigkeiten

Diese Erweiterung beinhaltet außerdem eine agentische Fähigkeit für ES|QL, die in Elasticsearch verfügbare Elasticsearch Query Language. Agentische Fähigkeiten stellen ein offenes Format dar, das KI-Coding-Agenten wie Gemini CLI individuelle Anweisungen für bestimmte Aufgaben gibt. Sie verwenden ein Konzept namens Progressive Disclosure (progressive Offenlegung), was bedeutet, dass der anfänglichen Systemaufforderung nur eine kurze Beschreibung der Fähigkeit hinzugefügt wird. Wenn Sie den Agenten bitten, eine Aufgabe auszuführen, wie etwa eine Abfrage an Elasticsearch, passt er die Anfrage an die relevante Fähigkeit an und lädt dynamisch die detaillierten Anweisungen. Dies ist eine effiziente Methode, um Token-Budgets zu verwalten und der KI genau den Kontext bereitzustellen, den sie benötigt.

Die esql-Fähigkeit ist so konzipiert, dass Gemini CLI ES|QL-Abfragen direkt in Ihrem Cluster schreiben und ausführen kann. ES|QL ist eine leistungsstarke Abfragesprache, die die Datenexploration, die Log-Analyse und die Aggregationen sehr intuitiv macht. Wenn diese Fähigkeit aktiviert ist, müssen Sie nicht nach der ES|QL-Syntax suchen; Sie können der Gemini CLI einfach Fragen zu Ihren Daten in natürlicher Sprache stellen, und der Agent kümmert sich um den Rest.

Die Ausführung erfolgt mit einfachen curl-Befehlen, die in einem Terminal ausgeführt werden. Dies ist möglich, da Elasticsearch eine umfangreiche Sammlung von REST APIs bereitstellt, die sich problemlos in jede beliebige Architektur integrieren lassen.

Was die esql Fähigkeit bietet:

• Erkennung von Indizes und Schemata: Der Agent kann die integrierten Tools der Fähigkeit nutzen, um verfügbare Indizes aufzulisten und Feld-Mappings abzurufen. Bevor der Agent beispielsweise eine Abfrage für die E-Commerce-Datensätze schreibt, kann er eine Schema-Prüfung für kibana_sample_data_ecommerce ausführen, um die verfügbaren Felder wie taxful_total_price oder category zu ermitteln.

• Nahtlose Übersetzung natürlicher Sprache: Diese Fähigkeit bietet dem Agenten mehr als nur ein einfaches Nachschlagewerk; sie liefert eine konkrete Anleitung zur Interpretation der Nutzerabsicht. Wenn Sie Anfragen in natürlicher Sprache eingeben, wie „Zeige durchschnittliche Reaktionszeit gruppiert nach Service“, nutzt der Agent die in der Fähigkeit integrierte Mustererkennung, um Ihre Worte sofort in die richtigen ES|QL-Aggregationen, Filter und Befehle umzuwandeln.

• Selbstkorrektur: Wenn eine Abfrage fehlschlägt (zum Beispiel wegen eines Typfehlers oder eines Syntaxfehlers), gibt die Fähigkeit die generierte Abfrage zusammen mit der genauen Elasticsearch-Fehlermeldung zurück, sodass der Agent die Abfrage sofort beheben und erneut ausführen kann, ohne dass Sie eingreifen müssen.

Da die esql-Fähigkeit auch als Tool auf dem elastic-agent-builder-MCP-Server verfügbar ist, müssen wir diesen Server vorübergehend deaktivieren. Sie können sie mit dem folgendem Befehl deaktivieren:

Dann können Sie einfach einen Befehl wie diesen in Ihre Gemini CLI eingeben:

Der Agent wird:

• Die Notwendigkeit der esql-Fähigkeit erkennen

• Überprüfen Sie das Schema von kibana_sample_data_ecommerce.

• Eine ES|QL-Abfrage erstellen wie: FROM kibana_sample_data_ecommerce | STATS total_revenue = SUM(taxful_total_price) BY category.keyword | SORT total_revenue DESC | LIMIT 5

• Die Abfrage über die Elasticsearch-API ausführen

• Das Ergebnis Ihnen direkt im Terminal anzeigen

Hier haben wir ein Beispiel für die Antwort von Gemini auf die vorherige Eingabe aufgeführt:

Es ist interessant festzustellen, wie das Gemini-Modell die endgültige Antwort generiert, indem es alle Schritte zeigt, die es dabei durchläuft. Hier können Sie deutlich den Einfluss der Fähigkeit auf den Denkprozess des Modells erkennen. Wenn das Modell zum ersten Mal erkennt, dass es eine Fähigkeit verwenden oder einen Shell-Befehl ausführen muss, erfragt es die Genehmigung mithilfe des Human-in-the-Loop-Ansatzes.

Durch die Übernahme der aufwendigen Aufgaben der Schemaerkennung, Abfragegenerierung und -ausführung ermöglicht Ihnen die esql-Fähigkeit, sich voll und ganz auf die Antworten zu konzentrieren, anstatt auf die Mechanismen ihrer Ermittlung. Sie erhalten die Daten, die Sie benötigen, richtig formatiert und direkt in Ihrem Terminal, ohne jemals eine einzige Zeile Syntax zu schreiben oder zu einer anderen Anwendung zu wechseln.

Fazit

In diesem Artikel haben wir die kürzlich veröffentlichte Elasticsearch-Erweiterung für die Gemini CLI vorgestellt. Mit dieser Erweiterung können Sie über Gemini und den von Elastic Agent Builder bereitgestellten Elasticsearch-MCP-Server, der ab Version 9.3.0 verfügbar ist, sowie über den Befehl /elastic mit Ihrer Elasticsearch-Instanz interagieren.

Darüber hinaus enthält die Erweiterung auch eine esql-Fähigkeit, die die Anfrage eines Nutzers von der natürlichen Sprache in eine ES|QL-Abfrage umwandelt. Diese Fähigkeit kann besonders nützlich sein, wenn der MCP-Server nicht genutzt werden kann, da die zugrundeliegende Kommunikation durch einfache Curl-Befehle in einem Terminal gesteuert wird. Elasticsearch bietet eine umfangreiche Auswahl an REST APIs, die leicht in jedes Projekt integriert werden können. Dies ist besonders nützlich bei der Entwicklung von agentischen KI-Anwendungen.

Weitere Informationen zu unserer Gemini CLI-Erweiterung finden Sie hier im Projekt-Repository.

Jina-Modelle lassen sich in drei Hauptkategorien einteilen, die zur Unterstützung der Informationsverarbeitung, Organisation und den Informationsabruf entwickelt wurden:

• Semantische Einbettungsmodelle

• Reranking-Modelle

• Kleine generative Sprachmodelle

Semantische Einbettungsmodelle

Die Idee hinter semantischen Einbettungen ist, dass ein KI-Modell lernen kann, Aspekte der Bedeutung seiner Eingaben in Bezug auf die Geometrie hochdimensionaler Räume darzustellen.

Sie können sich eine semantische Einbettung als einen Punkt (technisch gesehen einen Vektor) in einem hochdimensionalen Raum vorstellen. Ein Einbettungsmodell ist ein neuronales Netz, das digitale Daten als Eingabe aufnimmt (potenziell alles, aber meist Text oder Bild) und die Position eines entsprechenden hochdimensionalen Punktes als numerische Koordinaten ausgibt. Wenn das Modell seine Aufgabe gut erfüllt, ist der Abstand zwischen zwei semantischen Einbettungen proportional dazu, wie sehr ihre entsprechenden digitalen Objekte dieselbe Bedeutung haben.

Um zu verstehen, wie wichtig das für Suchanwendungen ist, stellen Sie sich eine Einbettung für das Wort „dog“ und eine für das Wort „cat“ als Punkte im Raum vor:

Ein gutes Einbettungsmodell sollte eine Einbettung für das Wort „feline“ generieren, die viel näher an „cat“ als an „dog“ liegt, und „canine“ sollte eine Einbettung haben, die viel näher an „dog“ als an „cat“ liegt, weil diese Wörter fast dasselbe bedeuten:

Wenn ein Modell mehrsprachig ist, würden wir dasselbe für Übersetzungen von „cat“ und „dog“ erwarten:

Einbettungsmodelle übersetzen Ähnlichkeiten oder Unterschiede in der Bedeutung zwischen Dingen in räumliche Beziehungen zwischen Einbettungen. Die Bilder oben haben nur zwei Dimensionen, sodass Sie sie auf einem Bildschirm sehen können, aber das Einbetten von Modellen erzeugt Vektoren mit Dutzenden bis Tausenden von Dimensionen. Dies ermöglicht es ihnen, die Feinheiten der Bedeutung ganzer Texte zu kodieren, indem sie einen Punkt in einem Raum mit Hunderten oder Tausenden von Dimensionen für Dokumente mit Tausenden von Wörtern oder mehr zuweisen.

Multimodale Einbettungen

Multimodale Modelle erweitern das Konzept der semantischen Einbettung auf andere Dinge als Texte, insbesondere auf Bilder. Wir würden erwarten, dass eine Einbettung für ein Bild nahe an einer Einbettung einer getreuen Beschreibung des Bildes liegt:

Semantische Einbettungen haben viele Einsatzmöglichkeiten. Unter anderem können Sie sie verwenden, um effiziente Klassifikatoren zu erstellen, Clustering durchzuführen und eine Vielzahl von Aufgaben zu erledigen, wie z. B. die Deduplizierung von Daten und die Untersuchung der Datendiversität. Beides ist wichtig für Big-Data-Anwendungen, bei denen mit zu vielen Daten gearbeitet wird, um sie manuell zu verwalten.

Die größte direkte Anwendung von Einbettungen ist der Informationsabruf. Elasticsearch kann Abrufobjekte mit Einbettungen als Schlüssel speichern. Abfragen werden in Einbettungsvektoren umgewandelt, und eine Suche gibt die gespeicherten Objekte zurück, deren Schlüssel den Abfrage-Einbettungen am nächsten sind.

Bei der traditionellen vektorbasierten Suche (manchmal auch als Sparse Vector Retrieval bezeichnet) werden Vektoren verwendet, die auf Wörtern oder Metadaten in Dokumenten und Anfragen basieren. Die einbettungsbasierte Suche (auch bekannt als Dense Vector Retrieval) verwendet hingegen KI-bewertete Bedeutungen anstelle von Wörtern. Dadurch sind sie im Allgemeinen wesentlich flexibler und genauer als herkömmliche Suchmethoden.

Matryoshka-Darstellungslernen

Die Anzahl der Dimensionen, die eine Einbettung hat, und die Präzision der darin enthaltenen Zahlen haben erhebliche Auswirkungen auf die Leistung. Äußerst hochdimensionale Räume und extrem hochpräzise Zahlen können sehr detaillierte und komplexe Informationen darstellen, erfordern aber größere KI-Modelle, deren Training und Nutzung teurer sind. Die erzeugten Vektoren benötigen mehr Speicherplatz, und es braucht mehr Rechenzyklen, um die Abstände zwischen ihnen zu berechnen. Bei der Verwendung semantischer Einbettungsmodelle müssen wichtige Kompromisse zwischen Präzision und Ressourcenverbrauch eingegangen werden.

Um die Flexibilität für die Nutzer zu maximieren, werden Jina-Modelle mit einer Technik namens Matryoshka Representation Learning trainiert. Dies führt dazu, dass die Modelle die wichtigsten semantischen Unterscheidungen in die ersten Dimensionen des Einbettungsvektors vorladen, sodass man die höheren Dimensionen einfach abschneiden und trotzdem eine gute Leistung erzielen kann.

In der Praxis bedeutet das, dass Nutzer von Jina-Modellen wählen können, wie viele Dimensionen ihre Einbettungen haben sollen. Die Wahl von weniger Dimensionen verringert die Präzision, der Leistungsverlust ist jedoch gering. Bei den meisten Aufgaben sinken die Leistungskennzahlen für Jina-Modelle um 1 bis 2 %, wenn man die Einbettungsgröße um 50 % reduziert, bis hin zu einer Reduzierung um etwa 95 %.

Asymmetrischer Informationsabruf

Semantische Ähnlichkeit wird normalerweise symmetrisch gemessen. Der Wert, den man beim Vergleich von „cat“ mit „dog“ erhält, ist derselbe wie der Wert, den man beim Vergleich von „dog“ mit „cat“ erhält. Bei der Verwendung von Einbettungen für den Informationsabruf funktionieren diese jedoch besser, wenn man die Symmetrie aufhebt und Anfragen anders kodiert als die zu kodierenden Objekte.

Das liegt an der Art, wie wir Einbettungsmodelle trainieren. Die Trainingsdaten enthalten Instanzen der gleichen Elemente, wie z. B. Wörter, in vielen verschiedenen Kontexten. Die Modelle lernen die Semantik, indem sie die kontextuellen Ähnlichkeiten und Unterschiede zwischen den Elementen vergleichen.

So könnten wir beispielsweise feststellen, dass das Wort „animal“ nicht in sehr vielen der gleichen Kontexte wie „cat“ oder „dog“ vorkommt, und daher ist die Einbettung für „animal“ möglicherweise nicht besonders nahe an der von „cat“ oder „dog“:

Dies macht es unwahrscheinlicher, dass eine Abfrage nach „animal“ Dokumente über Katzen und Hunde zurückgibt – das Gegenteil unseres Ziels. Deshalb kodieren wir „Tier“ anders, wenn es sich um eine Suchanfrage handelt, als wenn es ein Ziel für den Informationsabruf ist:

Asymmetrischer Informationsabruf bedeutet, ein anderes Modell für Abfragen zu verwenden oder ein Einbettungsmodell speziell zu trainieren, um Dinge auf eine bestimmte Weise zu kodieren, wenn sie für den Abruf gespeichert sind, und Abfragen auf eine andere Weise zu kodieren.

Multivektor-Einbettungen

Einzelne Einbettungen sind gut für die Informationsabfrage, da sie in das grundlegende Framework einer indizierten Datenbank passen: Wir speichern Objekte für die Abfrage mit einem einzelnen Einbettungsvektor als deren Abfrageschlüssel. Wenn Nutzer den Dokumentenspeicher abfragen, werden ihre Abfragen in Einbettungsvektoren übersetzt und die Dokumente, deren Schlüssel der Abfrage-Einbettung am nächsten sind (im hochdimensionalen Einbettungsraum), werden als Kandidatenmatches abgerufen.

Multivektor-Einbettungen funktionieren etwas anders. Anstatt einen Vektor mit fester Länge zu erzeugen, um eine Abfrage und ein ganzes gespeichertes Objekt darzustellen, erzeugen sie eine Folge von Einbettungen, die kleinere Teile davon repräsentieren. Die einzelnen Teile sind typischerweise Tokens oder Wörter für Texte und Bildkacheln für visuelle Daten. Diese Einbettungen spiegeln die Bedeutung des Teils in seinem Kontext wider.

Betrachten wir zum Beispiel die folgenden Sätze:

• Sie hatte ein Herz aus Gold.

• Sie hatte einen Herzenswandel.

• Sie hatte einen Herzinfarkt.

Oberflächlich betrachtet sehen sie sehr ähnlich aus, aber ein Multivektor-Modell würde wahrscheinlich sehr unterschiedliche Einbettungen für jede Instanz von „Herz“ generieren, was darstellt, wie jede im Kontext des gesamten Satzes etwas anderes bedeutet:

Der Vergleich zweier Objekte anhand ihrer Multivektor-Einbettungen beinhaltet oft die Messung ihres Chamfer-Abstands: der Vergleich jedes Teils einer Multivektor-Einbettung mit jedem Teil einer anderen und die Summierung der minimalen Abstände zwischen ihnen. Andere Systeme, einschließlich des unten beschriebenen Jina Rerankers, geben sie in ein KI-Modell ein, das speziell für die Bewertung ihrer Ähnlichkeit trainiert wurde. Beide Ansätze haben in der Regel eine höhere Präzision als der Vergleich von Einzeleinbettungen, da Einbettungen mit mehreren Vektoren viel detailliertere Informationen enthalten als solche mit einem Vektor.

Allerdings eignen sich Multivektor-Einbettungen nicht gut zum Indexieren. Sie werden häufig bei Neubewertungsaufgaben verwendet, wie im nächsten Abschnitt für das Modell jina-colbert-v2 beschrieben.

Jina-Einbettungsmodelle

Jina-Einbettungen – v4

jina-embeddings-v4 ist ein 3,8 Milliarden (3,8x10⁹) Parameter umfassendes mehrsprachiges und multimodales Einbettungsmodell, das Bilder und Texte in einer Vielzahl weit verbreiteter Sprachen unterstützt. Es verwendet eine neuartige Architektur, um visuelle Kenntnisse und Sprachkenntnisse zu nutzen, um die Leistung bei beiden Aufgaben zu verbessern, sodass es beim Abrufen von Bildern und insbesondere beim visuellen Abrufen von Dokumenten hervorragende Leistungen erbringt. Das bedeutet, dass es Bilder wie Diagramme, Dias, Karten, Screenshots, Seitenscans und Diagramme verarbeitet – gängige Bildtypen, oft mit wichtigem eingebettetem Text, die außerhalb des Bereichs von Computer-Vision-Modellen fallen, die auf Bildern realer Szenen trainiert sind.

Wir haben dieses Modell mithilfe kompakter Low-Rank Adaptation (LoRA)-Adapter für verschiedene Aufgaben optimiert. Dadurch können wir ein einzelnes Modell trainieren, um sich auf mehrere Aufgaben zu spezialisieren, ohne bei einer davon die Leistung zu beeinträchtigen – mit minimalen zusätzlichen Kosten für Speicher oder Verarbeitung.

Zu den wichtigsten Funktionen gehören:

• Spitzenleistung beim visuellen Dokumentenabruf sowie eine mehrsprachige Text- und Bildverarbeitungsleistung, die deutlich größere Modelle übertrifft.

• Unterstützung für große Eingabekontextgrößen: 32.768 Tokens entsprechen ungefähr 80 Seiten doppeltzeiligem englischen Text, und 20 Megapixel entsprechen einem Bild von 4.500 x 4.500 Pixeln.

• Vom Nutzer ausgewählte Einbettungsgrößen, von maximal 2048 Dimensionen bis zu 128 Dimensionen. Wir haben empirisch festgestellt, dass die Leistung unterhalb dieser Schwelle dramatisch abnimmt.

• Unterstützung für sowohl einzelne Einbettungen als auch Multivektor-Einbettungen. Für Texte besteht die Multivektor-Ausgabe aus einer 128-dimensionalen Einbettung für jedes Eingabetoken. Für Bilder erzeugt es eine 128-dimensionale Einbettung für jede 28x28 Pixel große Kachel, die zur Abdeckung des Bildes benötigt wird.

• Optimierung für asymmetrischen Datenabruf mittels eines Paares von LoRA-Adaptern, die speziell für diesen Zweck trainiert wurden.

• Ein LoRA-Adapter, optimiert für die Berechnung semantischer Ähnlichkeit.

• Spezielle Unterstützung für Programmiersprachen und IT-Frameworks, ebenfalls über einen LoRA-Adapter.

Wir haben jina-embeddings-v4 als allgemeines Mehrzweckwerkzeug für eine breite Palette gängiger Such-, Sprachverarbeitungs- und KI-Analyseaufgaben entwickelt. Es handelt sich im Verhältnis zu seinen Fähigkeiten um ein relativ kleines Modell, dessen Bereitstellung jedoch erhebliche Ressourcen erfordert und das sich am besten für die Nutzung über eine Cloud-API oder in einer Umgebung mit hohem Datenaufkommen eignet.

Jina-Einbettungen – v3

jina-embeddings-v3 ist ein kompaktes, leistungsstarkes, mehrsprachiges, ausschließlich textbasiertes Einbettungsmodell mit weniger als 600 Millionen Parametern. Es unterstützt bis zu 8192 Texteingabetoken und liefert Einzelvektor-Einbettungen mit vom Nutzer gewählten Größen von einem Standard von 1024 Dimensionen bis zu 64 als Ausgabe.

Wir haben jina-embeddings-v3 für eine Vielzahl von Textaufgaben trainiert – nicht nur für den Informationsabruf und die semantische Ähnlichkeit, sondern auch für Klassifikationsaufgaben wie die Sentiment-Analyse und Inhaltsmoderation sowie für Clustering-Aufgaben wie die Nachrichtenaggregation und -empfehlung. Wie jina-embeddings-v4 bietet auch dieses Modell LoRA-Adapter, die auf die folgenden Nutzungskategorien spezialisiert sind:

• Asymmetrischer Informationsabruf

• Semantische Ähnlichkeit

• Klassifizierung

• Clustering

jina-embeddings-v3 ist ein deutlich kleineres Modell als jina-embeddings-v4 mit einer deutlich reduzierten Eingabekontextgröße, aber es ist günstiger in der Nutzung. Dennoch bietet es eine sehr wettbewerbsfähige Leistung, wenn auch nur für Texte, und ist für viele Anwendungsfälle eine bessere Wahl.

Jina Code-Einbettungen

Die spezialisierten Code-Einbettungsmodelle von Jina – jina-code-embeddings (0.5b und 1.5b) – unterstützen 15 Programmierschemata und Frameworks sowie englischsprachige Texte aus dem Bereich Informatik und Informationstechnologie. Es handelt sich um kompakte Modelle mit einer halben Milliarde (0,5x10⁹) bzw. eineinhalb Milliarden (1,5x10⁹) Parametern. Beide Modelle unterstützen Eingabekontextgrößen von bis zu 32.768 Token und ermöglichen es den Nutzern, ihre Ausgabe-Einbettungsgrößen auszuwählen, von 896 bis 64 Dimensionen für das kleinere Modell und 1536 bis 128 für das größere.

Diese Modelle unterstützen asymmetrische Abrufe für fünf aufgabenspezifische Spezialisierungen, wobei Präfixabstimmung statt LoRA-Adapter verwendet wird:

• Code zu Code. Ähnlichen Code in verschiedenen Programmiersprachen abrufen. Dies wird für die Code-Ausrichtung, Code-Deduplizierung sowie die Unterstützung von Portierung und Refactoring verwendet.

• Natürliche Sprache zu Code. Abrufen von Code, um Abfragen, Kommentare, Beschreibungen und Dokumentation in natürlicher Sprache abzugleichen.

• Code zu natürlicher Sprache. Vergleichen des Codes mit der Dokumentation oder anderen Texten in natürlicher Sprache.

• Code-zu-Code-Vervollständigung. Vorschlag von relevantem Code, um bestehenden Code zu ergänzen oder zu verbessern.

• Technische Fragen und Antworten. Identifizierung von Antworten in natürlicher Sprache auf Fragen zu Informationstechnologien, ideal geeignet für Anwendungsfälle im technischen Support.

Diese Modelle bieten eine überlegene Leistung für Aufgaben, die Computerdokumentation und Programmiermaterialien erfordern, bei relativ geringen Rechenkosten. Sie eignen sich hervorragend für die Integration in Entwicklungsumgebungen und Code-Assistenten.

Jina ColBERT v2

jina-colbert-v2 ist ein Multivektor-Texteinbettungsmodell mit 560 Millionen Parametern. Es ist mehrsprachig, mit Materialien in 89 Sprachen trainiert und unterstützt variable Einbettungsgrößen sowie asymmetrischen Informationsabruf.

Wie bereits erwähnt, sind Multivektor-Einbettungen schlecht für das Indexieren geeignet, aber sehr nützlich, um die Genauigkeit von Ergebnissen anderer Suchstrategien zu erhöhen. Mit jina-colbert-v2können Sie Multivektor-Einbettungen im Voraus berechnen und sie dann verwenden, um Abrufkandidaten zur Abfragezeit neu zu ordnen. Dieser Ansatz ist weniger präzise als die Verwendung eines der Reranking-Modelle im nächsten Abschnitt, aber viel effizienter, da er nur den Vergleich gespeicherter Multivektor-Einbettungen beinhaltet, anstatt das gesamte KI-Modell für jede Abfrage und jedes Kandidatenmatch aufzurufen. Es eignet sich ideal für Anwendungsfälle, in denen die Latenz und der Rechenaufwand durch die Nutzung von Reranking-Modellen zu groß sind oder die Anzahl der Kandidaten zum Vergleich zu groß für das Reranking von Modellen ist.

Dieses Modell gibt eine Folge von Einbettungen aus – eine pro Eingabetoken – und Nutzer können Token-Einbettungen aus 128-, 96- oder 64-dimensionalen Einbettungen auswählen. Kandidaten-Textmatches sind auf 8.192 Token begrenzt. Abfragen werden asymmetrisch kodiert, daher müssen Nutzer angeben, ob ein Text eine Abfrage oder ein Kandidatenmatch ist, und die Abfragen auf 32 Token begrenzen.

Jina CLIP v2

jina-clip-v2 ist ein multimodales Einbettungsmodell mit 900 Millionen Parametern, das so trainiert wurde, dass Texte und Bilder Einbettungen erzeugen, die nahe beieinander liegen, wenn der Text den Inhalt des Bildes beschreibt. Es dient in erster Linie zum Abrufen von Bildern auf der Grundlage von Textabfragen, ist aber auch ein leistungsstarkes reines Textmodell, das die Nutzerkosten senkt, da Sie keine separaten Modelle für Text-zu-Text- und Text-zu-Bild-Abfragen benötigen.

Dieses Modell unterstützt einen Texteingabekontext von 8.192 Tokens, und Bilder werden vor der Einbettung auf 512x512 Pixel skaliert.

CLIP-Architekturen („Contrastive Language-Image Pretraining“) sind einfach zu trainieren und zu bedienen und können sehr kompakte Modelle erzeugen, aber sie haben einige grundlegende Einschränkungen. Sie können ihr Wissen aus einem Medium nicht nutzen, um ihre Leistung in einem anderen zu verbessern. Sie können nicht ein Medium nutzen, um ihre Leistung in einem anderen zu verbessern. Obwohl das System also wissen mag, dass die Wörter „dog“ und „cat“ in ihrer Bedeutung näher beieinander liegen als jedes von ihnen bei „car“, weiß es nicht unbedingt, dass ein Bild von einem Hund und ein Bild von einer Katze enger miteinander verwandt sind als jedes von ihnen bei einem Bild von einem Auto.

Sie leiden auch unter der sogenannten Modalitätslücke: Die Einbettung eines Textes über Hunde ist wahrscheinlich näher an der Einbettung eines Textes über Katzen als an der Einbettung eines Bildes von Hunden. Aufgrund dieser Einschränkung empfehlen wir, CLIP entweder als Text-zu-Bild-Abfragemodell oder als reines Textmodell zu verwenden, jedoch nicht beide in einer einzigen Abfrage zu vermischen.

Reranking-Modelle

Reranking-Modelle nehmen ein oder mehrere Kandidatenmatches zusammen mit einer Abfrage als Eingabe für das Modell und vergleichen sie direkt, wodurch deutlich präzisere Übereinstimmungen entstehen.

Grundsätzlich könnte man einen Reranker direkt für die Informationsabfrage verwenden, indem man jede Abfrage mit jedem gespeicherten Dokument vergleicht, dies wäre jedoch sehr rechenintensiv und für alle außer den kleinsten Sammlungen unpraktisch. Daher werden Reranker tendenziell zur Bewertung relativ kurzer Listen von Kandidatenmatches verwendet, die mit anderen Mitteln gefunden wurden, wie z. B. durch einbettungsbasierte Suche oder andere Algorithmen für den Informationsabruf. Reranking-Modelle eignen sich ideal für hybride und föderierte Suchverfahren, bei denen eine Suche bedeuten kann, dass Anfragen an separate Suchsysteme mit unterschiedlichen Datensätzen gesendet werden, die jeweils unterschiedliche Ergebnisse liefern. Sie sind sehr gut darin, vielfältige Ergebnisse zu einem einzigen, hochwertigen Ergebnis zu vereinen.

Die auf Einbettungen basierende Suche kann eine große Herausforderung darstellen, da sie eine Neuindizierung aller gespeicherten Daten erfordert und die Erwartungen der Nutzer an die Ergebnisse verändert. Wenn Sie einen Reranker zu einem bestehenden Suchschema hinzufügen, können Sie viele der Vorteile von KI nutzen, ohne Ihre gesamte Suchlösung neu zu entwickeln.

Jina-Reranker-Modelle

Jina Reranker m0

jina-reranker-m0 ist ein multimodaler Reranker mit 2,4 Milliarden (2,4x10⁹) Parametern, der Textanfragen und Kandidatenmatches aus Texten und/oder Bildern unterstützt. Es ist das führende Modell für die visuelle Dokumentensuche und somit eine ideale Lösung für Sammlungen von PDFs, Scans von Texten, Screenshots und anderen computergenerierten oder modifizierten Bildern, die Text oder andere semistrukturierte Informationen enthalten, sowie für gemischte Daten, die aus Textdokumenten und Bildern bestehen.

Dieses Modell nimmt eine einzelne Abfrage und einen Kandidatenmatch entgegen und gibt einen Score zurück. Wenn dieselbe Abfrage mit verschiedenen Kandidaten verwendet wird, sind die Scores vergleichbar und können zur Rangfolge herangezogen werden. Es unterstützt eine gesamte Eingabegröße von bis zu 10.240 Tokens, einschließlich des Anfragetextes und des Kandidatentextes oder -bildes. Jede 28x28 Pixel große Kachel, die zum Abdecken eines Bildes benötigt wird, zählt als Token zur Berechnung der Eingabegröße.

Jina Reranker v3

jina-reranker-v3 ist ein Text-Reranker mit 600 Millionen Parametern und modernster Leistung für Modelle vergleichbarer Größe. Im Gegensatz zu jina-reranker-m0 nimmt er eine einzelne Abfrage und eine Liste von bis zu 64 Kandidatenübereinstimmungen und gibt die Rangfolge zurück. Es hat einen Eingabekontext von 131.000 Token, einschließlich der Abfrage und aller Textkandidaten.

Jina Reranker v2

jina-reranker-v2-base-multilingual ist ein äußerst kompakter, universeller Reranker mit zusätzlichen Features, die Funktionsaufrufe und SQL-Abfragen unterstützen. Mit weniger als 300 Millionen Parametern bietet er ein schnelles, effizientes und genaues mehrsprachiges Text-Reranking mit zusätzlicher Unterstützung für die Auswahl von SQL-Tabellen und externen Funktionen, die Textabfragen entsprechen, wodurch es sich für agentenbasierte Anwendungsfälle eignet.

Kleine generative Sprachmodelle

Generative Sprachmodelle sind Modelle wie ChatGPT von OpenAI, Google Gemini und Claude von Anthropic, die Text- oder Multimedia-Eingaben aufnehmen und mit Textausgaben antworten. Es gibt keine klar definierte Grenze, die große Sprachmodelle (LLMs) von kleinen Sprachmodellen (SLMs) unterscheidet, aber die praktischen Probleme bei der Entwicklung, dem Betrieb und der Nutzung von Top-LLMs sind wohlbekannt. Die bekanntesten werden nicht öffentlich verbreitet, daher können wir ihre Größe nur schätzen, aber es wird erwartet, dass ChatGPT, Gemini und Claude im Bereich von 1 bis 3 Billionen (1–3x10¹²) Parametern liegen.

Das Ausführen dieser Modelle – selbst wenn sie öffentlich verfügbar sind – geht weit über den Umfang herkömmlicher Hardware hinaus und erfordert die fortschrittlichsten Chips, die in riesigen parallelen Arrays angeordnet sind. Der Zugriff auf LLMs ist über kostenpflichtige APIs möglich, dies verursacht jedoch erhebliche Kosten, führt zu einer hohen Latenz und lässt sich nur schwer mit den Anforderungen an Datenschutz, digitale Souveränität und Cloud-Repatriierung vereinbaren. Außerdem können die Kosten für das Training und die Anpassung von Modellen dieser Größe beträchtlich sein.

Aus diesem Grund wurde viel Forschung in die Entwicklung kleinerer Modelle gesteckt, die vielleicht nicht alle Fähigkeiten der größten LLMs haben, aber bestimmte Aufgaben genauso gut erledigen können, und das zu geringeren Kosten. Unternehmen setzen Software in der Regel ein, um spezifische Probleme zu lösen, und KI-Software bildet da keine Ausnahme. Daher sind SLM-basierte Lösungen oft LLM-basierten Lösungen vorzuziehen. Sie können üblicherweise auf Standardhardware laufen, sind schneller, verbrauchen weniger Energie und lassen sich viel leichter anpassen.

Das SLM-Angebot von Jina wächst, da wir uns darauf konzentrieren, wie wir KI am besten in praktische Suchlösungen integrieren können.

Jina SLMs

ReaderLM v2

ReaderLM-v2 ist ein generatives Sprachmodell, das HTML gemäß benutzerdefinierten JSON-Schemata und natürlichen Sprachanweisungen in Markdown oder JSON umwandelt.

Datenvorverarbeitung und -normalisierung sind ein wesentlicher Bestandteil der Entwicklung guter Suchlösungen für digitale Daten, aber reale Daten, insbesondere webbasierte Informationen, sind oft chaotisch, und einfache Umwandlungsstrategien erweisen sich häufig als sehr zerbrechlich. Stattdessen bietet ReaderLM-v2 eine intelligente KI-Modelllösung, die das Chaos eines DOM-Tree-Dumps einer Webseite verstehen und nützliche Elemente robust identifizieren kann.

Mit 1,5 Milliarden (1,5x10⁹) Parametern ist es drei Größenordnungen kompakter als modernste LLMs, leistet aber bei dieser einen engen Aufgabe auf Augenhöhe.

Jina VLM

jina-vlm ist ein generatives Sprachmodell mit 2,4 Milliarden (2,4x10⁹) Parametern, das darauf trainiert wurde, natürlichsprachliche Fragen zu Bildern zu beantworten. Es bietet eine sehr starke Unterstützung für die visuelle Dokumentenanalyse, d. h. für die Beantwortung von Fragen zu Scans, Screenshots, Folien, Diagrammen und ähnlichen nicht natürlichen Bilddaten.

Zum Beispiel:

Es ist auch sehr gut darin, Text in Bildern zu lesen:

Die wahre Stärke von jina-vlm liegt jedoch im Verständnis des Inhalts von informativen und von Menschen erstellten Bildern:

Oder:

jina-vlm ist gut geeignet für die automatische Generierung von Bildunterschriften, Produktbeschreibungen, Alternativtexten für Bilder und Barrierefreiheitsanwendungen für Sehbehinderte. Es schafft zudem Möglichkeiten für RAG-Systeme („Retrieval-Augmented-Generation“), visuelle Informationen zu verwenden, und für KI-Agenten, Bilder ohne menschliche Unterstützung zu verarbeiten.

In diesem Blogbeitrag verwenden wir Mastra , um einen Wissensagenten zu entwickeln, der sich merkt, was Benutzer sagen, und relevante Informationen später abrufen kann. Als Speicher- und Abruf-Backend nutzen wir Elasticsearch. Dieses Konzept lässt sich problemlos auf reale Anwendungsfälle übertragen. Man denke beispielsweise an Supportmitarbeiter, die sich an frühere Gespräche und Lösungen erinnern können, sodass sie ihre Antworten auf bestimmte Benutzer zuschneiden oder Lösungen schneller auf Basis des vorherigen Kontextes präsentieren können.

Folgen Sie dieser Anleitung, um zu sehen, wie Sie es Schritt für Schritt bauen können. Falls Sie nicht weiterkommen oder einfach nur ein fertiges Beispiel ausführen möchten, schauen Sie sich das Repository hier an.

Was ist Mastra?

Mastra ist ein Open-Source-TypeScript-Framework zum Erstellen von KI-Agenten mit austauschbaren Teilen für Schlussfolgerungen, Speicher und Werkzeuge. Die semantische Abruffunktion ermöglicht es Agenten, vergangene Interaktionen zu erinnern und abzurufen, indem Nachrichten als Einbettungen in einer Vektordatenbank gespeichert werden. Dies ermöglicht es den Agenten, den Gesprächskontext und die Kontinuität langfristig aufrechtzuerhalten. Elasticsearch ist ein hervorragender Vektorspeicher, um diese Funktion zu ermöglichen, da er eine effiziente dichte Vektorsuche unterstützt. Wenn der semantische Abruf ausgelöst wird, ruft der Agent relevante vergangene Nachrichten in das Kontextfenster des Modells ab, sodass das Modell diesen abgerufenen Kontext als Grundlage für seine Schlussfolgerungen und Antworten nutzen kann.

Was Sie für den Einstieg benötigen

• Node v18+

• Elasticsearch (Version 8.15 oder neuer)

• Elasticsearch API-Schlüssel

• OpenAI API-Schlüssel

Hinweis: Sie benötigen dies, da die Demo den OpenAI-Provider verwendet. Mastra unterstützt jedoch auch andere KI-SDKs und Community-Modell-Provider, sodass Sie ihn je nach Ihrer Konfiguration problemlos austauschen können.

Aufbau eines Mastra-Projekts

Wir werden die integrierte CLI von Mastra verwenden, um das Grundgerüst für unser Projekt bereitzustellen. Führen Sie folgenden Befehl aus:

Sie erhalten eine Reihe von Eingabeaufforderungen, beginnend mit:

1. Gib deinem Projekt einen Namen.

2. Wir können diese Standardeinstellung beibehalten; Sie können dieses Feld gerne leer lassen.

3. Für dieses Projekt verwenden wir ein von OpenAI bereitgestelltes Modell.

4. Wählen Sie die Option „Jetzt überspringen“, da wir alle unsere Umgebungsvariablen in einer `.env`-Datei speichern, die wir in einem späteren Schritt konfigurieren werden.

5. Diese Option können wir auch überspringen.

Sobald dieser Initialisierungsprozess abgeschlossen ist, können wir zum nächsten Schritt übergehen.

Abhängigkeiten installieren

Als Nächstes müssen wir einige Abhängigkeiten installieren:

• ai - Core AI SDK-Paket, das Werkzeuge zur Verwaltung von KI-Modellen, Eingabeaufforderungen und Arbeitsabläufen in JavaScript/TypeScript bereitstellt. Mastra basiert auf dem AI SDK von Vercel, daher benötigen wir diese Abhängigkeit, um Modellinteraktionen mit Ihrem Agenten zu ermöglichen.

• @ai-sdk/openai - Plugin, das das AI SDK mit OpenAI-Modellen (wie GPT-4, GPT-4o usw.) verbindet und API-Aufrufe mit Ihrem OpenAI-API-Schlüssel ermöglicht.

• @elastic/elasticsearch - Offizieller Elasticsearch-Client für Node.js, Wird verwendet, um eine Verbindung zu Ihrer Elastic Cloud oder Ihrem lokalen Cluster für Indizierungs-, Such- und Vektoroperationen herzustellen.

• dotenv Lädt Umgebungsvariablen aus einer .env-Datei Datei in process.env, ermöglicht das sichere Einfügen von Anmeldeinformationen wie API-Schlüsseln und Elasticsearch-Endpunkten.

Konfiguration von Umgebungsvariablen

Erstellen Sie eine .env -Datei in Ihrem Projektstammverzeichnis, falls dort noch keine vorhanden ist. Alternativ können Sie das von mir im Repository bereitgestellte Beispiel .env kopieren und umbenennen. In dieser Datei können wir die folgenden Variablen hinzufügen:

Damit ist die grundlegende Einrichtung abgeschlossen. Von hier aus können Sie bereits mit dem Erstellen und Orchestrieren von Agenten beginnen. Wir gehen noch einen Schritt weiter und fügen Elasticsearch als Speicher- und Vektorsuchschicht hinzu.

Elasticsearch als Vektorspeicher hinzufügen

Erstellen Sie einen neuen Ordner namens stores und fügen Sie darin diese Datei ein. Bevor Mastra und Elastic eine offizielle Elasticsearch-Vektorspeicherintegration veröffentlichten, teilte Abhi Aiyer(CTO von Mastra) diese frühe Prototypklasse mit dem Namen ElasticVector. Vereinfacht gesagt verbindet es die Speicherabstraktion von Mastra mit den dichten Vektorfunktionen von Elasticsearch, sodass Entwickler Elasticsearch als Vektordatenbank für ihre Agenten verwenden können.

Werfen wir einen genaueren Blick auf die wichtigen Aspekte der Integration:

Aufnahme des Elasticsearch-Clients

Dieser Abschnitt definiert die Klasse ElasticVector und richtet die Elasticsearch-Clientverbindung mit Unterstützung für Standard- und serverlose Bereitstellungen ein.

• ElasticVectorConfig extends ClientOptionsDadurch wird eine neue Konfigurationsschnittstelle erstellt, die alle Elasticsearch-Clientoptionen (wie node, auth, requestTimeout) erbt und unsere benutzerdefinierten Eigenschaften hinzufügt. Das bedeutet, dass Benutzer jede gültige Elasticsearch-Konfiguration zusammen mit unseren serverlosen Optionen übergeben können.

• extends MastraVectorDies ermöglicht es ElasticVector von Mastras Basisklasse MastraVector zu erben, die eine gemeinsame Schnittstelle darstellt, der alle Vektorspeicherintegrationen entsprechen. Dadurch wird sichergestellt, dass sich Elasticsearch aus Sicht des Agenten wie jedes andere Mastra-Vektor-Backend verhält.

• private client: ClientDies ist eine private Eigenschaft, die eine Instanz des Elasticsearch JavaScript-Clients enthält. Dadurch kann die Klasse direkt mit Ihrem Cluster kommunizieren.

• isServerless und deploymentChecked: Diese Eigenschaften arbeiten zusammen, um zu erkennen und zwischenzuspeichern, ob wir mit einer serverlosen oder einer Standard-Elasticsearch-Bereitstellung verbunden sind. Diese Erkennung erfolgt automatisch bei der ersten Nutzung oder kann explizit konfiguriert werden.

• constructor(config: ClientOptions)Dieser Konstruktor nimmt ein Konfigurationsobjekt entgegen (das Ihre Elasticsearch-Zugangsdaten und optionale Serverless-Einstellungen enthält) und verwendet es, um den Client in der Zeile this.client = new Client(config) zu initialisieren.

• super(): Dadurch wird der Basiskonstruktor von Mastra aufgerufen, sodass Logging, Validierungshilfsmechanismen und andere interne Hooks geerbt werden.

Zu diesem Zeitpunkt weiß Mastra, dass es einen neuen Vektor-Shop namens gibt. ElasticVector

Erkennung des Bereitstellungstyps

Vor dem Erstellen von Indizes erkennt der Adapter automatisch, ob Sie Elasticsearch Standard oder Elasticsearch Serverless verwenden. Dies ist wichtig, da serverlose Bereitstellungen keine manuelle Shard-Konfiguration zulassen.

Was passiert:

• Zuerst wird geprüft, ob Sie isServerless explizit in der Konfiguration festgelegt haben (überspringt die automatische Erkennung).

• Ruft die info() -API von Elasticsearch auf, um Clusterinformationen zu erhalten.

• Prüft den Wert build_flavor field (serverlose Bereitstellungen geben serverless zurück)

• Falls die Build-Variante nicht verfügbar ist, wird auf die Überprüfung des Slogans zurückgegriffen.

• Speichert das Ergebnis im Cache, um wiederholte API-Aufrufe zu vermeiden.

• Wird standardmäßig die Bereitstellung durchgeführt, wenn die Erkennung fehlschlägt.

Anwendungsbeispiel:

Erstellen des „Speichers“ in Elasticsearch

Die folgende Funktion richtet einen Elasticsearch-Index zum Speichern von Einbettungen ein. Es wird geprüft, ob der Index bereits existiert. Andernfalls wird eine solche mit der unten stehenden Zuordnung erstellt, die ein dense_vector -Feld zum Speichern von Einbettungen und benutzerdefinierten Ähnlichkeitsmetriken enthält.

Einige Dinge sind zu beachten:

• Der Parameter dimension gibt die Länge des jeweiligen Einbettungsvektors an und hängt davon ab, welches Einbettungsmodell Sie verwenden. In unserem Fall generieren wir Einbettungen mithilfe des text-embedding-3-small -Modells von OpenAI, das Vektoren der Größe 1536 ausgibt. Dies werden wir als Standardwert verwenden.

• Die in der folgenden Zuordnung verwendete Variable similarity wird durch die Hilfsfunktion const similarity = this.mapMetricToSimilarity(metric) definiert, welche den Wert für den Parameter metric entgegennimmt und ihn in ein Elasticsearch-kompatibles Schlüsselwort für die gewählte Distanzmetrik umwandelt.

  • Zum Beispiel: Mastra verwendet allgemeine Begriffe für Vektorähnlichkeit wie cosine, euclidean, und dotproduct. Würden wir die Metrik euclidean direkt in das Elasticsearch-Mapping einfügen, würde dies einen Fehler auslösen, da Elasticsearch erwartet, dass das Schlüsselwort l2_norm die euklidische Distanz repräsentiert.

• Serverless-Kompatibilität: Der Code lässt Shard- und Replikateinstellungen für serverlose Bereitstellungen automatisch aus, da diese von Elasticsearch Serverless automatisch verwaltet werden.

Speichern einer neuen Erinnerung oder Notiz nach einer Interaktion

Diese Funktion nimmt die nach jeder Interaktion neu generierten Einbettungen zusammen mit den Metadaten entgegen und fügt sie anschließend mithilfe der bulk -API von Elastic in den Index ein oder aktualisiert sie. Die bulk API bündelt mehrere Schreibvorgänge in einer einzigen Anfrage; diese Verbesserung unserer Indexierungsleistung stellt sicher, dass Aktualisierungen effizient bleiben, während der Speicher unseres Agenten immer größer wird.

Abfrage ähnlicher Vektoren für semantische Wiedererkennung

Diese Funktion ist der Kern des semantischen Recall-Features. Der Agent verwendet eine Vektorsuche, um ähnliche gespeicherte Einbettungen in unserem Index zu finden.

Unter der Haube:

• Führt eine kNN- Abfrage (k-nächste Nachbarn) mit Hilfe der knn -API in Elasticsearch aus.

• Gibt die K ähnlichsten Vektoren zum Eingabeabfragevektor zurück.

• Optional können Metadatenfilter angewendet werden, um die Ergebnisse einzugrenzen (z. B. nur innerhalb einer bestimmten Kategorie oder eines bestimmten Zeitraums zu suchen).

• Gibt strukturierte Ergebnisse zurück, einschließlich der Dokument-ID, des Ähnlichkeitswerts und der gespeicherten Metadaten.

Erstellung des Wissensagenten

Nachdem wir nun die Verbindung zwischen Mastra und Elasticsearch durch die ElasticVector -Integration kennengelernt haben, erstellen wir den Knowledge Agent selbst.

Erstellen Sie im Ordner agents eine Datei namens knowledge-agent.ts. Wir können damit beginnen, unsere Umgebungsvariablen zu verbinden und den Elasticsearch-Client zu initialisieren.

Hier, wir:

• Verwenden Sie dotenv um unsere Variablen aus unserer .env -Datei zu laden.

• Prüfen Sie, ob die Elasticsearch-Zugangsdaten korrekt eingefügt werden, dann können wir eine erfolgreiche Verbindung zum Client herstellen.

• Übergeben Sie den Elasticsearch-Endpunkt und den API-Schlüssel an den ElasticVector -Konstruktor, um eine Instanz unseres zuvor definierten Vektorspeichers zu erstellen.

• Optional können Sie isServerless: true angeben, wenn Sie Elasticsearch Serverless verwenden. Dadurch wird der automatische Erkennungsschritt übersprungen und die Startzeit verkürzt. Wird dieser Parameter weggelassen, erkennt der Adapter Ihren Bereitstellungstyp bei der ersten Verwendung automatisch.

Als nächstes können wir den Agenten mithilfe der Klasse Agent von Mastra definieren.

Folgende Felder können wir definieren:

• name und instructions: Gib ihr eine Identität und eine primäre Funktion.

• modelWir verwenden OpenAIs gpt-4o über das @ai-sdk/openai -Paket.

• memory:

  • vector: Verweist auf unseren Elasticsearch-Speicher, sodass Einbettungen dort gespeichert und abgerufen werden.

  • embedderWelches Modell soll zur Generierung von Einbettungen verwendet werden?

  • semanticRecall Die Optionen bestimmen, wie der Rückruf funktioniert:

    • topK: Wie viele semantisch ähnliche Nachrichten sollen abgerufen werden?

    • messageRange: Wie viel vom Gespräch soll bei jedem Spielzug einbezogen werden?

    • scope: Definiert die Speichergrenze.

Fast fertig. Wir müssen diesen neu erstellten Agenten lediglich zu unserer Mastra-Konfiguration hinzufügen. Importieren Sie in der Datei mit dem Namen index.ts den Wissensagenten und fügen Sie ihn in das Feld agents ein.

Zu den weiteren Bereichen gehören:

• storageDies ist Mastras interner Datenspeicher für Laufzeitverlauf, Observability-Metriken, Scores und Caches. Weitere Informationen zu Mastra-Speicherlösungen finden Sie hier.

• loggerMastra verwendet Pino, einen leichtgewichtigen, strukturierten JSON-Logger. Es erfasst Ereignisse wie Agentenstart und -stopp, Toolaufrufe und -ergebnisse, Fehler und LLM-Reaktionszeiten.

• observability: Steuert die KI-Verfolgung und die Sichtbarkeit der Ausführung von Agenten. Es verfolgt:

  • Beginn/Ende jedes Denkschritts.

  • Welches Modell oder Werkzeug wurde verwendet?

  • Ein- und Ausgänge.

  • Bewertungen und Beurteilungen

Testen des Agenten mit Mastra Studio

Glückwunsch! Wenn Sie es bis hierher geschafft haben, sind Sie bereit, diesen Agenten auszuführen und seine semantischen Erinnerungsfähigkeiten zu testen. Zum Glück bietet Mastra eine integrierte Chat-Benutzeroberfläche, sodass wir keine eigene entwickeln müssen.

Um den Mastra-Entwicklungsserver zu starten, öffnen Sie ein Terminal und führen Sie folgenden Befehl aus:

Nach der ersten Bündelung und dem Start des Servers sollte Ihnen eine Adresse für den Playground bereitgestellt werden.

Fügen Sie diese Adresse in Ihren Browser ein, und Sie gelangen zum Mastra Studio.

Wählen Sie die Option für knowledgeAgent und legen Sie los.

Um schnell zu prüfen, ob alles richtig verkabelt ist, geben Sie ihm beispielsweise folgende Information: „Das Team gab bekannt, dass die Umsatzentwicklung im Oktober um 12 % gestiegen ist, hauptsächlich aufgrund von Vertragsverlängerungen im Unternehmensbereich.“ Der nächste Schritt besteht darin, die Kundenansprache auf mittelständische Unternehmen auszuweiten.“ Starten Sie anschließend einen neuen Chat und stellen Sie eine Frage wie: „Auf welches Kundensegment sollten wir uns als Nächstes konzentrieren?“ Der Wissensagent sollte in der Lage sein, die Informationen aus dem ersten Chat abzurufen. Sie sollten eine Antwort wie diese sehen:

Eine solche Antwort bedeutet, dass der Agent unsere vorherige Nachricht erfolgreich als Einbettungen in Elasticsearch gespeichert und später mithilfe der Vektorsuche abgerufen hat.

Überprüfung des Langzeitspeichers des Agenten

Wechseln Sie im Mastra Studio zur Registerkarte memory in der Konfiguration Ihres Agenten. So können Sie sehen, was Ihr Agent im Laufe der Zeit gelernt hat. Jede Nachricht, Antwort und Interaktion, die in Elasticsearch eingebettet und gespeichert wird, wird Teil dieses Langzeitgedächtnisses. Sie können vergangene Interaktionen semantisch durchsuchen, um schnell erinnerte Informationen oder Kontexte wiederzufinden, die der Agent zuvor gelernt hat. Dies ist im Wesentlichen derselbe Mechanismus, den der Agent beim semantischen Abruf verwendet, aber hier können Sie ihn direkt untersuchen. In unserem unten stehenden Beispiel suchen wir nach dem Begriff „Vertrieb“ und erhalten jede Interaktion zurück, die etwas mit Vertrieb zu tun hat.

Fazit

Durch die Verbindung von Mastra und Elasticsearch können wir unseren Agenten Speicher zur Verfügung stellen, was eine wichtige Ebene im Kontext-Engineering darstellt. Mithilfe des semantischen Abrufs können Agenten im Laufe der Zeit Kontext aufbauen und ihre Antworten auf dem basieren, was sie gelernt haben. Das bedeutet genauere, zuverlässigere und natürlichere Interaktionen.

Diese frühe Integration ist nur der Ausgangspunkt. Das gleiche Prinzip kann hier Support-Mitarbeitern ermöglichen, die sich an frühere Tickets erinnern, internen Bots, die relevante Dokumente abrufen, oder KI-Assistenten, die sich mitten im Gespräch an Kundendetails erinnern können. Wir arbeiten außerdem an einer offiziellen Mastra-Integration, wodurch diese Verbindung in naher Zukunft noch nahtloser wird.

Wir sind gespannt, was Sie als Nächstes entwickeln werden. Probieren Sie es aus, erkunden Sie Mastra und seine Speicherfunktionen und teilen Sie Ihre Entdeckungen gerne mit der Community.