Die Suche ist nicht tot, sie hat sich nur verlagert.

Wir haben also einen Wandel erlebt: von der primären Suche nach Kontext über ein Textfeld und der Verwendung der zurückgegebenen Informationen (des Kontexts), um die Antworten selbst zu konstruieren, hin zur Verwendung natürlicher Sprache, um einem Agenten mitzuteilen, was wir wollen, und lassen ihn die Antwort automatisch für uns recherchieren und zusammenstellen. Viele in der Tech-Welt verweisen auf diesen Wandel und verkünden, dass „Suche tot ist“ (nun ja, die SEO- und AdWords-Welt verändert sich definitiv: GEO, irgendjemand?), aber die Suche ist für operative Abläufe immer noch absolut entscheidend – sie wird nur heute größtenteils im Verborgenen mithilfe von Tools durchgeführt.

Bisher waren Menschen die Hauptverantwortlichen für die Beurteilung der subjektiven Relevanz: Jeder Nutzer hatte seine eigenen Gründe für die Durchführung der Suche, und seine persönlichen Erfahrungen prägten die relative Genauigkeit der Ergebnisse. Wenn wir darauf vertrauen sollen, dass Agenten zu demselben (oder einem besseren) Schluss kommen können, zu dem wir gekommen wären, müssen wir sicherstellen, dass die Kontextinformationen, auf die sie Zugriff haben, so nah wie möglich an unserer subjektiven Absicht liegen. Wir müssen den Kontext, den wir LLMs bieten, auf dieses Ziel ausrichten!

Kontextgenerierung mit hybrider Suchabfrage

Zur Erinnerung an Teil I: Die Hybridsuche von Elastic kombiniert die Stärken der traditionellen schlüsselwortbasierten Suche (Syntaxflexibilität, Schlüsselwortgenauigkeit und Relevanzbewertung) mit dem semantischen Verständnis der Vektorähnlichkeitssuche und bietet mehrere Reranking-Techniken. Diese Synergie (eine treffendere Verwendung dieses Wortes wurde noch nie gefunden!) ermöglicht hochrelevante Ergebnisse mit Suchanfragen, die wesentlich differenzierter auf die Inhalte abzielen. Es geht nicht nur darum, dass man die subjektive Relevanz als eine der Abrufphasen anwenden kann; es geht vielmehr darum, dass der Abruf in der ersten Phase die Relevanzbewertung zusammen mit all diesen anderen Modi gleichzeitig beinhalten kann.

Überragende Genauigkeit und Effizienz

Die Verwendung einer Datenplattform, die verteilte Suche, Abfrage und Neubewertung als primäre Kontextabfrage-Engine ermöglicht, ist sehr sinnvoll. Sie können eine erweiterte Abfragesyntax verwenden, um die fehlende Komponente der subjektiven Absicht hinzuzufügen und Inhalte herauszufiltern, die vom Wert der zurückgegebenen Kontextinformationen ablenken oder diesen verfälschen könnten. Sie können aus den verfügbaren Syntaxoptionen auswählen oder Modalitäten zu einer einzigen Suche kombinieren, die auf jeden Datentyp auf die für ihn beste Weise abzielt, und diese dann mit Reranking kombinieren/neu anordnen. Sie können die Antwort so filtern, dass sie nur die gewünschten Felder/Werte enthält und überflüssige Daten fernhält. Im Dienste der Agenten ermöglicht diese Targeting-Flexibilität die Entwicklung von Tools, die äußerst präzise beim Abrufen von Kontextinformationen sind.

Kontextverfeinerung (Aggregationen und nicht-inhaltliche Signale)

Aggregationen können besonders nützlich sein, um den Inhalt zu gestalten, den ein Tool im Kontextfenster anzeigt. Aggregationen liefern naturgemäß numerisch basierte Fakten über die Struktur der zurückgegebenen Kontextdaten, was es LLMs erleichtert und genauer macht, darüber zu argumentieren. Da Aggregationen hierarchisch verschachtelt werden können, ist dies eine einfache Möglichkeit, dem LLM mehrstufige Details hinzuzufügen, um ein differenzierteres Verständnis zu erzeugen. Aggregationen können auch bei der Verwaltung der Kontextfenstergröße helfen – Sie können ein Abfrageergebnis von 100.000 Dokumenten leicht auf einige hundert Tokens aggregierter Erkenntnisse reduzieren.

Nicht-inhaltliche Signale sind die in Ihren Daten enthaltenen Indikatoren, die Ihnen ein umfassenderes Bild dessen vermitteln, was Sie betrachten; es handelt sich um zusätzliche Merkmale der Ergebnisse, wie beispielsweise Popularität, Aktualität, geografische Lage, Kategorien, Vielfalt der Anbieter oder Preisklassen. Diese Informationsschnipsel können für den Agenten hilfreich sein, um die Bedeutung des empfangenen Kontextes einzuschätzen. Einige einfache Beispiele veranschaulichen dies am besten:

• Hervorhebung kürzlich veröffentlichter und beliebter Inhalte – Stellen Sie sich vor, Sie verfügen über eine Wissensdatenbank mit Artikeln. Sie möchten Artikel finden, die für die Suchanfrage eines Nutzers relevant sind, aber Sie möchten auch Artikel hervorheben, die sowohl aktuell sind als auch von anderen Nutzern als hilfreich empfunden wurden (z. B. eine hohe Anzahl von „Gefällt mir“-Angaben haben). In diesem Szenario können wir eine Hybridsuche verwenden, um relevante Artikel zu finden und sie dann anhand einer Kombination aus Veröffentlichungsdatum und Popularität neu zu ordnen.

• E-Commerce-Suche mit Umsatz- und Lagerbestandsanpassung – Im E-Commerce-Umfeld möchten Sie Ihren Kunden Produkte anzeigen, die zu ihrem Suchbegriff passen, aber Sie möchten auch Produkte bewerben, die sich gut verkaufen und auf Lager sind. Um Frustration bei den Kunden zu vermeiden, sollten Sie Produkte mit geringem Lagerbestand möglicherweise in der Rangfolge herabstufen.

• Priorisierung von schwerwiegenden Problemen in einem Bugtracker - Für ein Softwareentwicklungsteam ist es bei der Suche nach Problemen entscheidend, dass schwerwiegende, prioritäre und kürzlich aktualisierte Probleme zuerst angezeigt werden. Sie können nicht-signalgebende Kriterien wie „Kritikalität“ und „meistdiskutiert“ verwenden, um verschiedene Faktoren unabhängig voneinander zu gewichten und so sicherzustellen, dass die wichtigsten und am aktivsten diskutierten Themen ganz oben stehen.

Diese und weitere Beispielabfragen finden Sie auf der zugehörigen Inhaltsseite von Elasticsearch Labs.

Sicherheitsdurchsetzung

Ein entscheidender Vorteil der Nutzung einer suchbasierten Geschwindigkeitsschicht wie Elastic für Context Engineering ist ihr integriertes Sicherheitsframework. Die Plattform von Elastic stellt sicher, dass der Kontext, der an agentenbasierte und generative KI-Operationen geliefert wird, sensible, privat gehaltene Informationen durch granulare rollenbasierte Zugriffskontrolle (RBAC) und attributbasierte Zugriffskontrolle (ABAC) respektiert und schützt. Dies bedeutet, dass Anfragen nicht nur effizient bearbeitet werden, sondern dass die Ergebnisse auch nach den spezifischen Berechtigungen des Agenten oder des Benutzers, der die Anfrage initiiert, gefiltert werden.

Die Agenten werden als authentifizierter Benutzer ausgeführt, sodass die Sicherheit implizit durch die in die Plattform integrierten Sicherheitsfunktionen gewährleistet ist:

• Feingranulare Berechtigungen: Definieren Sie den Zugriff auf Dokument-, Feld- oder sogar Begriffsebene und stellen Sie so sicher, dass KI-Agenten nur Daten erhalten, zu deren Einsicht sie berechtigt sind.

• Rollenbasierte Zugriffskontrolle (RBAC): Agenten oder Benutzern werden Rollen zugewiesen, wodurch ihnen basierend auf ihren definierten Verantwortlichkeiten Zugriff auf bestimmte Datensätze oder Funktionalitäten gewährt wird.

• Attributbasierte Zugriffskontrolle (ABAC): Implementieren Sie dynamische Zugriffsrichtlinien basierend auf Attributen der Daten, des Benutzers oder der Umgebung, wodurch eine hochgradig anpassungsfähige und kontextsensitive Sicherheit ermöglicht wird.

• Dokumentenebene-Sicherheit (DLS) und Feldebene-Sicherheit (FLS): Diese Funktionen gewährleisten, dass auch innerhalb eines abgerufenen Dokuments nur autorisierte Abschnitte sichtbar sind, wodurch die Offenlegung sensibler Informationen verhindert wird.

• Integration mit der Unternehmenssicherheit: Nahtlose Integration mit bestehenden Identitätsmanagementsystemen (wie LDAP, SAML, OIDC), um einheitliche Sicherheitsrichtlinien im gesamten Unternehmen durchzusetzen.

Durch die direkte Integration dieser Sicherheitsmaßnahmen in den Kontextabrufmechanismus fungiert Elastic als sicherer Wächter, der sicherstellt, dass KI-Agenten innerhalb definierter Datengrenzen arbeiten, eine unbefugte Datenoffenlegung verhindert und die Einhaltung der Datenschutzbestimmungen gewährleistet. Dies ist von entscheidender Bedeutung für den Aufbau von Vertrauen in agentenbasierte KI-Systeme, die vertrauliche oder geschützte Informationen verarbeiten.

Als zusätzlichen Vorteil verringern Sie durch die Verwendung einer einheitlichen Datengeschwindigkeitsschicht über Ihren Unternehmensdatenquellen die unerwarteten Ad-hoc-Abfragelasten auf diese Repositories, die agentenbasierte Tools erzeugen würden. Sie erhalten einen zentralen Ort, um alles nahezu in Echtzeit zu durchsuchen, und einen Ort, um Sicherheits- und Governance-Kontrollen anzuwenden.

Hybride suchbasierte Tools

Es gibt einige Kernfunktionen (und ständig kommen neue hinzu) der Elastic-Plattform, die das Streben nach Kontextentwicklung enorm beschleunigen. Das Wichtigste hierbei ist, dass die Plattform eine Vielzahl von Möglichkeiten bietet, um Ziele zu erreichen, und die Flexibilität besitzt, Methoden anzupassen, zu verändern und zu erweitern, wenn sich das KI-Ökosystem weiterentwickelt.

Wir stellen Ihnen Agent Builder vor

Elastic Agent Builder ist unser erster Ausflug in die Welt der agentenbasierten KI-Tools, die entwickelt wurden, um mit den Daten zu kommunizieren, die Sie bereits in Elastic speichern. Agent Builder bietet eine Chat-Oberfläche, mit der Benutzer ihre eigenen Agenten und Tools innerhalb von Kibana erstellen und verwalten können. Es verfügt über integrierte MCP- und A2A-Server, programmatische APIs und eine Reihe vorkonfigurierter Systemtools zum Abfragen und Erkunden von Elasticsearch-Indizes sowie zum Generieren von ES|QL-Abfragen aus natürlicher Sprache. Mit Agent Builder können Sie benutzerdefinierte Tools erstellen, die die an den Agenten zurückgegebenen Kontextdaten mithilfe einer ausdrucksstarken ES|QL- Abfragesyntax gezielt ansprechen und formen.

Wie funktioniert die hybride Suche in ES|QL, fragen Sie? Die Kernfunktionalität wird durch die Kombination des Feldtyps semantic_text und der Befehle FORK/FUSE erreicht (FUSE verwendet standardmäßig RRF , um die Ergebnisse der einzelnen Forks zusammenzuführen). Hier ein einfaches Beispiel für eine fiktive Produktsuche:

Die EVAL- Klausel, die in jedem der FORK-Zweige im obigen Beispiel enthalten ist, ist nicht unbedingt notwendig; sie dient lediglich dazu, zu veranschaulichen, wie Sie nachverfolgen können, aus welcher Suchmodalität ein bestimmtes Ergebnis zurückgegeben wurde.

Suchvorlagen

Angenommen, Sie möchten Ihre eigenen externen Agenten-Tools auf Ihre Elastic-Bereitstellung verweisen. Anstelle von ES|QL möchten Sie mehrstufige Retriever verwenden oder eine bereits entwickelte DSL-Syntax wiederverwenden und außerdem die Eingaben, die die Abfrage akzeptiert, die Syntax, die zur Ausführung der Suche verwendet wird, und die in der Ausgabe zurückgegebenen Felder steuern können. Suchvorlagen ermöglichen es Benutzern, vordefinierte Strukturen für häufige Suchmuster festzulegen, wodurch die Effizienz und Konsistenz beim Abrufen von Daten verbessert wird. Dies ist besonders vorteilhaft für agentenbasierte Tools, die mit Such-APIs interagieren, da sie dazu beitragen, Boilerplate-Code zu standardisieren und eine schnellere Iteration der Suchlogik zu ermöglichen. Und falls Sie jemals einen dieser Faktoren anpassen müssen, aktualisieren Sie einfach die Suchvorlage und voilà, die Änderungen werden übernommen. Wenn Sie ein Beispiel für die Verwendung von Suchvorlagen mit agentenbasierten Tools suchen, schauen Sie sich den Blog von Elasticsearch Labs an: „MCP für intelligente Suche “. Dort wird eine Suchvorlage hinter einem Tool-Aufruf von einem externen MCP-Server verwendet.

Integrierte Arbeitsabläufe (FTW!)

Eine der größten Herausforderungen in unserer neuen Welt der agentenbasierten KI ist die nicht-deterministische Natur von semi-autonomen, selbstgesteuerten „denkenden“ Agenten. Kontextgestaltung ist eine entscheidende Disziplin für agentenbasierte KI: Es handelt sich um Techniken, die dazu beitragen, die möglichen Schlussfolgerungen, die unser Agent generieren kann, auf das einzugrenzen, was wir als Wahrheit kennen. Selbst bei einem hochpräzisen und relevanten Kontextfenster (wenn wir den Bereich numerischer Fakten verlassen) fehlt uns immer noch die Gewissheit, dass die Reaktion des Agenten vollständig wiederholbar und verlässlich ist.

Wenn Sie dieselbe Anfrage mehrmals an einen Agenten senden, können die Antworten im Wesentlichen gleich sein, wobei sich lediglich die Antwort geringfügig unterscheidet. Das ist in der Regel für einfache Abfragen ausreichend, vielleicht kaum wahrnehmbar, und wir können versuchen, die Ausgabe mithilfe von Kontextmanipulationstechniken zu gestalten. Doch je komplexer die Aufgaben werden, die wir unseren Agenten stellen, desto größer ist die Wahrscheinlichkeit, dass eine oder mehrere Teilaufgaben eine Abweichung hervorrufen, die das Endergebnis geringfügig verändert. Es wird wahrscheinlich noch schlimmer werden, wenn wir uns stärker auf die Kommunikation zwischen den Agenten verlassen, und diese Abweichungen werden sich summieren. Dies unterstreicht erneut die Notwendigkeit, dass die Werkzeuge, mit denen unsere Agenten interagieren, sehr flexibel und genau auf die jeweiligen Kontextdaten abstimmbar sein müssen und dass sie in einem erwarteten Ausgabeformat reagieren sollten. Dies deutet auch darauf hin, dass wir für viele Anwendungsfälle die Interaktion zwischen Agenten und Werkzeugen steuern müssen – hier kommen Workflows ins Spiel!

Elastic wird schon bald vollständig anpassbare Workflows in den Kern der Plattform integrieren. Diese Workflows werden in der Lage sein, bidirektional mit Agenten und Tools zu interagieren, sodass Workflows Agenten und Tools aufrufen können und Agenten und Tools Workflows aufrufen können. Die vollständige Integration dieser Funktionen in dieselbe Such-KI-Plattform, auf der sich all Ihre Daten befinden, wird einen grundlegenden Wandel bewirken; das Potenzial der Arbeitsabläufe ist äußerst spannend! Bald, schon sehr bald!

Elastisch wie die einheitliche Speicherbank

Da Elastic eine verteilte Datenplattform ist, die für die Suche in nahezu Echtzeit konzipiert wurde, übernimmt sie auf natürliche Weise die Langzeitgedächtnisfunktionen für agentenbasierte KI-Systeme. Mit der integrierten Chat-Funktion des Agent Builders bieten wir auch die Möglichkeit, das Kurzzeitgedächtnis und den Chatverlauf zu verfolgen und zu verwalten. Und weil die gesamte Plattform API-first ist, ist es extrem einfach, Elastic als Plattform zu nutzen, um die Kontextausgabe eines Tools zu speichern (und später darauf zurückgreifen zu können), die das Kontextfenster des Agenten überfordern könnte; diese Technik wird in Kontext-Engineering-Kreisen manchmal als „ Notizen-Making“ bezeichnet.

Die Kombination von Kurzzeit- und Langzeitgedächtnis auf derselben Suchplattform bietet viele Vorteile: Stellen Sie sich vor, Sie könnten Chatverläufe und gespeicherte Kontextantworten als semantische Einflussfaktoren für zukünftige Chatinteraktionen nutzen, Bedrohungsanalysen durchführen oder persistente Datenprodukte erstellen, die automatisch aus häufig wiederholten Toolaufrufen generiert werden… Die Möglichkeiten sind endlos!

Fazit

Das Aufkommen großer Sprachmodelle hat die Art und Weise verändert, wie wir Inhalte abgleichen und wie wir unsere Daten analysieren. Wir bewegen uns rasant weg von unserer gegenwärtigen Welt, in der Menschen Recherche, Kontextbetrachtung und logisches Denken betreiben, um ihre eigenen Fragen zu beantworten, hin zu einer Welt, in der diese Schritte weitgehend durch agentenbasierte KI automatisiert werden. Damit wir den generierten Antworten vertrauen können, benötigen wir die Gewissheit, dass der Agent bei der Generierung seiner Antwort alle relevanten Informationen (einschließlich des Faktors der subjektiven Relevanz) berücksichtigt hat. Unsere primäre Methode, um agentenbasierte KI vertrauenswürdig zu machen, besteht darin, die Werkzeuge, die zusätzlichen Kontext abrufen, durch RAG- und Kontext-Engineering-Techniken zu verankern. Die Art und Weise, wie diese Werkzeuge den anfänglichen Abruf durchführen, kann jedoch entscheidend für die Genauigkeit der Antwort sein.

Die Elastic Search AI-Plattform bietet die Flexibilität und Vorteile der hybriden Suche sowie zahlreiche integrierte Funktionen, die agentenbasierte KI in Bezug auf Genauigkeit, Leistung und Skalierbarkeit unterstützen; mit anderen Worten: Elastic ist eine fantastische Plattform für verschiedene Aspekte des Kontext-Engineerings! Durch die Standardisierung des Kontextabrufs über eine Suchplattform vereinfachen wir die Funktionsweise von agentenbasierten Werkzeugen in vielerlei Hinsicht – und ähnlich dem Widerspruch „langsamer werden, um schneller zu werden“ bedeutet Einfachheit auf der Ebene der Kontextgenerierung eine schnellere und vertrauenswürdigere agentenbasierte KI.

Eine neue Art der Interaktion mit Daten

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

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

Generative KI & RAG

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

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

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

Zu wenige Informationen

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

Zu viele Informationen

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

Ablenkende oder widersprüchliche Informationen

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

Agentische KI

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

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

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

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

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

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

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

Willkommen im Kontext-Engineering!

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

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

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

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

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

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

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

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

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

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

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

Phänomenale kosmische Energie, winziger Wohnraum!

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

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

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

So viele/zu viele Möglichkeiten

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

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

Auch für Computer ist der Kontextwechsel schwierig.

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

Pause im 7. Inning!

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

Wie viele von uns bin auch ich gleichermaßen begeistert und erstaunt über das Tempo, mit dem sich die Fähigkeiten der KI weiterentwickeln. Wir erlebten zum ersten Mal, wie große Sprachmodelle (LLMs) und die Vektorsuche uns in die semantische Revolution katapultierten, bei der wir nicht mehr mühsam mit Schlüsselwörtern herumsuchen mussten, um Dinge zu finden. Dann zeigten uns die LLMs neue Wege der Interaktion mit unseren Daten auf, indem sie Chat-Schnittstellen nutzten, um Anfragen in natürlicher Sprache in Antworten umzuwandeln, die riesige Wissensdatenbanken in leicht verständliche Zusammenfassungen destillierten. Wir jetzt (schon!) haben die Anfänge einer automatisierten LLM-gesteuerten Logik in Form von „agentischen KI“-Workflows, die eine eingehende Anfrage semantisch verstehen, über die zu unternehmenden Schritte nachdenken und dann aus den verfügbaren Werkzeugen auswählen können, um iterativ Aktionen auszuführen, um diese Ziele zu erreichen.

Das Versprechen agentenbasierter KI zwingt uns, uns von der primären Verwendung von „Prompt Engineering“ zur Gestaltung unserer generativen KI-Interaktionen hin zu einem Fokus darauf zu entwickeln, wie wir agentenbasierte Werkzeuge dabei unterstützen können, die relevantesten und effizientesten Zusatzinformationen zu erhalten, die das LLM bei der Generierung seiner Antworten berücksichtigen muss – „Context Engineering“ ist die nächste Herausforderung. Die hybride Suche ist mit Abstand das leistungsstärkste und flexibelste Mittel, um relevante Kontextinformationen zu finden, und die Search AI-Plattform von Elastic eröffnet völlig neue Möglichkeiten, Daten im Dienste des Context Engineering zu nutzen. In diesem Artikel werden wir aus zwei Blickwinkeln erörtern, wie LLMs die Welt der Informationswiedergewinnung verändert haben, und anschließend darauf eingehen, wie sie für bessere Ergebnisse zusammenarbeiten können. Es gibt noch viel zu besprechen…

Teil I: Wie LLMs die Suche verändert haben

Beginnen wir mit der Frage, wie LLMs die Art und Weise verändert haben, wie wir auf Informationen zugreifen und sie abrufen.

Unser lexikalisches Erbe

Wir alle leben schon seit langer Zeit in der etwas eingeschränkten Welt der lexikalischen Suche (ziemlich gut, so gut es eben geht). Die Suche ist das erste Werkzeug, zu dem wir greifen, wenn wir recherchieren oder ein neues Projekt beginnen, und bis vor kurzem lag es an uns, unsere Suchanfragen so zu formulieren, dass eine lexikalische Suchmaschine sie versteht. Die lexikalische Suche basiert auf dem Abgleich von Suchbegriffen mit Schlüsselwörtern in einem Dokumentenkorpus – unabhängig davon, ob der Inhalt unstrukturiert oder strukturiert ist. Damit eine lexikalische Suche ein Dokument als Treffer zurückgibt, muss dieses mit dem entsprechenden Schlüsselwort übereinstimmen (oder über ein kontrolliertes Vokabular wie eine Synonymliste oder ein Wörterbuch verfügen, um die konzeptionelle Verbindung für uns herzustellen).

Beispiel einer lexikalischen Mehrfachabfrage

Suchmaschinen haben zumindest die Möglichkeit, Treffer mit einer Relevanzbewertung zurückzugeben. Suchmaschinen bieten eine Fülle von Abfragesyntaxoptionen, um indizierte Daten effektiv anzusprechen, sowie integrierte Relevanzalgorithmen, die die Ergebnisse im Verhältnis zur Absicht der Abfragesyntax des Benutzers bewerten. Suchmaschinen profitieren von jahrzehntelangen Fortschritten bei Relevanz-Ranking-Algorithmen und sind dadurch eine effiziente Datenabrufplattform, die Ergebnisse liefern kann, die nach ihrer Relevanz für die Suchanfrage bewertet und sortiert sind. Datenbanken und andere Systeme, die SQL als ihre Hauptmethode zum Abrufen von Daten verwenden, sind hier im Nachteil: Es gibt kein Relevanzkonzept in einer Datenbankabfrage; sie können bestenfalls Ergebnisse alphabetisch oder numerisch sortieren. Die gute Nachricht ist, dass Sie mit diesen Schlüsselwörtern alle Treffer (Recall) erhalten, diese aber nicht unbedingt in einer hilfreichen Reihenfolge im Hinblick darauf, warum Sie danach gesucht haben (Präzision). Das ist ein wichtiger Punkt, wie wir gleich sehen werden…

Betreten Sie den (semantischen) Drachen

Das Potenzial von Vektordarstellungen von Informationen als Alternative zur Stichwortsuche wird schon seit geraumer Zeit erforscht. Vektoren bergen großes Potenzial, da sie uns aus dem rein schlüsselwortbasierten Modus des Inhaltsabgleichs herausführen – da Vektoren numerische Darstellungen von Begriffen und Gewichtungen sind, ermöglichen sie es, Konzepte mathematisch nahe beieinander zu bringen, basierend auf dem Verständnis eines Sprachmodells darüber, wie Begriffe im Trainingsbereich miteinander in Beziehung stehen. Die lange Verzögerung bei der allgemeinen Vektorsuche war darauf zurückzuführen, dass die Modelle größtenteils auf spezifische Domänen beschränkt waren; sie waren einfach nicht groß genug, um die vielen verschiedenen Konzepte, die ein Begriff in unterschiedlichen Kontexten repräsentieren könnte, ausreichend zu verstehen.

Erst mit dem Aufkommen der Large Language Models (LLMs) vor einigen Jahren, die in der Lage sind, mit viel größeren Datenmengen zu trainieren (unter Verwendung von Transformatoren und Aufmerksamkeit), wurde die Vektorsuche praktikabel – die Größe und Tiefe der LLMs ermöglichten es Vektoren schließlich, genügend Nuancen zu speichern, um tatsächlich semantische Bedeutung zu erfassen. Dieser plötzliche Anstieg des Verständnisses ermöglichte es LLMs, nun eine große Anzahl von Funktionen der natürlichen Sprachverarbeitung (NLP) zu erfüllen, die zuvor gesperrt waren. Die vielleicht wirkungsvollste Funktion ist die Fähigkeit, aus dem Kontext dessen, was sich bisher in der Sequenz befindet, auf das wahrscheinlichste nächste Glied in einer Sequenz zu schließen. Inferenz ist der Prozess, der generativer KI ihre nahezu menschenähnliche Fähigkeit verleiht, Texte zu erzeugen. Der KI-generierte Text basiert auf dem Verständnis des LLM darüber, wie Begriffe in seinen Trainingsdaten miteinander in Beziehung stehen, und verwendet außerdem die Formulierung der Anfrage, um zwischen verschiedenen Kontexten, in denen die Begriffe vorkommen könnten, zu unterscheiden.

So magisch generative KI auch sein mag, es gibt Einschränkungen bei LLMs, die zu Fehlern in Qualität und Genauigkeit führen, die gemeinhin als Halluzinationen bezeichnet werden. Halluzinationen treten auf, wenn das LLM keinen Zugang zu den Informationen hat (oder nicht in den richtigen Kontext geführt wird), um seine Antwort auf die Wahrheit zu gründen. Stattdessen generiert es, um hilfreich zu sein, eine selbstsicher und plausibel klingende, aber erfundene Antwort. Ein Teil der Ursache liegt darin, dass LLMs zwar den Sprachgebrauch in großen Bereichen mit vielfältigen Informationen erlernen, das Training aber irgendwann beendet werden muss. Daher gibt es einen Zeitfaktor für ihr Verständnis – das heißt, das Modell kann nur das wissen, was bis zum Zeitpunkt des Trainingsstopps korrekt war. Ein weiterer Faktor für Halluzinationen ist, dass das Modell normalerweise keine Kenntnis von privat gespeicherten Daten hat (Daten, die nicht im öffentlichen Internet verfügbar sind), und das ist besonders bedeutsam, wenn diese Daten spezifische Begriffe und Nomenklatur enthalten.

Vektordatenbanken

LLMs vektorisieren Inhalte in ihren Modellraum mithilfe einer Technik namens Text Embedding. Dabei wird die semantische Bedeutung des Inhalts auf der Grundlage des erhaltenen Trainings in die Weltanschauung des Modells eingebettet oder abgebildet. Zur Vorbereitung und Verarbeitung von Inhalten für die Einbettung sind einige Schritte erforderlich, darunter Chunking und Tokenisierung (sowie Subwort-Tokenisierung). Das Ergebnis ist typischerweise eine Menge dichter Vektoren, die das Verständnis des Modells für die Bedeutung dieses Inhaltsabschnitts innerhalb seines Vektorraums darstellen. Chunking ist ein ungenaues Verfahren, das darauf abzielt, Inhalte an die Verarbeitungsbeschränkungen eines Modells zur Generierung von Einbettungen anzupassen und gleichzeitig verwandten Text mithilfe semantischer Konstrukte wie Satz- und Absatzindikatoren zu einem Chunk zusammenzufassen.

Die Notwendigkeit der Segmentierung kann zu einem gewissen semantischen Verlust in einem eingebetteten Dokument führen, da einzelne Segmente nicht vollständig mit anderen Segmenten aus demselben Dokument verknüpft sind. Die inhärente Undurchsichtigkeit neuronaler Netze kann diesen Verlust noch verschlimmern – ein LLM ist in Wahrheit eine „Black Box“, bei der die während des Trainings hergestellten Verbindungen zwischen Begriffen und Konzepten nicht deterministisch und für Menschen nicht interpretierbar sind. Dies führt zu Problemen mit der Erklärbarkeit, der Wiederholbarkeit, unbewussten Voreingenommenheit und möglicherweise zu einem Verlust an Vertrauen und Genauigkeit. Dennoch ist die Möglichkeit, Ideen semantisch zu verknüpfen und bei Suchanfragen nicht an bestimmte Schlüsselwörter gebunden zu sein, extrem wirkungsvoll:

Ein Beispiel für eine semantische Anfrage

Bei Vektordatenbanken gibt es noch einen weiteren Punkt zu beachten: Sie sind keine Suchmaschinen, sondern Datenbanken! Bei einer Vektorähnlichkeitssuche werden die Suchbegriffe kodiert, um einen Satz von (Einbettungs-)Koordinaten innerhalb des Vektorraums des Modells zu finden. Diese Koordinaten dienen dann als Zielscheibe, um die Dokumente zu finden, die die „nächsten Nachbarn“ der Zielscheibe sind – das heißt, der Rang eines Dokuments (oder seine Platzierung in den Ergebnissen) wird durch die berechnete Ähnlichkeitsdistanz der Koordinaten dieses Dokuments zu den Koordinaten der Anfrage bestimmt. In welche Richtung sollte die Rangfolge Vorrang haben, welcher der möglichen Kontexte entspricht am ehesten der Absicht des Nutzers? Das Bild, mit dem ich es vergleiche, ist eine Szene aus dem Film Stargate, in der wir die sechs Koordinatenpunkte haben, die sich schneiden, um uns das Ziel (die Zielscheibe) zu nennen, aber wir können es nicht erreichen, ohne das „7. Symbol“ zu kennen – die Koordinaten des Startpunkts, die die subjektive Absicht des Benutzers repräsentieren. Anstatt also die relative Rangfolge der Vektoren auf einer sich ständig erweiternden und undifferenzierten Sphäre der Ähnlichkeit zu basieren, können wir durch die Berücksichtigung der subjektiven Absicht der Anfrage mittels ausdrucksstarker Syntax und Relevanzbewertung so etwas wie einen Zylinder abgestufter subjektiver Relevanz erhalten.

Die Inferenzfähigkeiten eines LLM können zwar helfen, den wahrscheinlichsten Kontext für die Anfrage zu identifizieren, das Problem besteht jedoch darin, dass ohne diese Unterstützung die Koordinaten der eingehenden Anfrage nur anhand der Art und Weise bestimmt werden können, wie das Modell ursprünglich trainiert wurde.

In gewisser Hinsicht könnte man sagen, dass Vektorähnlichkeit das entgegengesetzte Extrem darstellt als eine strikte Stichwortübereinstimmung – ihre Stärke liegt in ihrer Fähigkeit, die Probleme der Begriffsabweichung zu überwinden, aber fast bis zum Exzess: LLMs neigen dazu, verwandte Konzepte zu vereinheitlichen, anstatt zwischen ihnen zu unterscheiden. Die Vektorähnlichkeit verbessert unsere Fähigkeit, Inhalte semantisch abzugleichen, garantiert aber keine Präzision, da sie exakte Schlüsselwörter und spezifische Details übersehen kann, die vom Modell nicht ausreichend unterschieden werden. Die Vektorähnlichkeitssuche ist an sich schon leistungsstark, aber wir brauchen Möglichkeiten, die Ergebnisse, die wir aus einer Vektordatenbank abrufen, mit Ergebnissen anderer Abrufmethoden zu korrelieren.

Neubewertungstechniken

An dieser Stelle sei eine allgemeine Technik namens Reranking erwähnt, bei der die Ergebnismengen neu bewertet oder normalisiert werden, um eine einheitliche Rangfolge zu erhalten. Die Notwendigkeit einer Neubewertung könnte darauf zurückzuführen sein, dass Ergebnisse aus mehreren Quellen oder Abrufmethoden unterschiedliche Bewertungsmechanismen (oder gar keine, SQL!) haben, oder die Neubewertung könnte dazu dienen, die Ergebnisse aus nicht-semantischen Quellen semantisch an die Anfrage des Benutzers anzupassen. Das Reranking ist ein zweiter Schritt, bei dem es sich um eine Reihe von Ergebnissen handelt, die durch eine erste Abrufmethode (z. B. Anschließend werden SQL-, lexikalische und Vektorsuchen mit einer anderen Bewertungsmethode neu geordnet.

Es stehen verschiedene Ansätze zur Verfügung, darunter Learning-To-Rank (LTR) und Reciprocal Rank Fusion (RRF) – LTR eignet sich, um Suchergebnisse zu erfassen (Likes, Bewertungen, Klicks usw.) und diese zu nutzen, um Ergebnisse zu bewerten und zu verstärken oder zu verzerren. RRF eignet sich perfekt zum Zusammenführen von Ergebnissen, die von verschiedenen Abfragemodalitäten zurückgegeben werden (z. B. lexikalische und Vektordatenbankrecherchen) werden zu einer einzigen Ergebnisliste zusammengeführt. Elastic bietet außerdem die Flexibilität, die Ergebnisse mithilfe linearer Neubewertungsmethoden anzupassen.

Eine der effektivsten Reranking-Techniken ist jedoch das semantische Reranking, bei dem das semantische Verständnis eines LLM genutzt wird, um die Vektoreinbettungen sowohl der Anfrage als auch der Ergebnisse gemeinsam zu analysieren und anschließend eine Relevanzbewertung/Rescoring anzuwenden, um die endgültige Reihenfolge zu bestimmen. Für das semantische Reranking ist natürlich eine Verbindung zu einem Reranking-Modell erforderlich. Elasticsearch bietet eine Inference API , mit der Sie Rerank- Endpunkte erstellen können, die integrierte Modelle (Elastic Rerank), importierte Modelle von Drittanbietern oder extern gehostete Dienste wie Cohere oder Google Vertex AI nutzen. Anschließend können Sie mithilfe der Abstraktionssyntax der Retriever -Abfrage ein Reranking durchführen:

Ein Beispiel für eine mehrstufige Retriever-Neubewertungsoperation

Klingt super, oder? Wir können eine Neubewertung der Ergebnisse aus unterschiedlichen Quellen durchführen und so ein nahezu vollständiges semantisches Verständnis aller Inhaltsarten erreichen… Die semantische Neubewertung kann sowohl rechenintensiv als auch zeitaufwendig sein, weshalb sie nur bei einer begrenzten Anzahl von Ergebnissen praktikabel ist. Daher ist es wichtig, wie die ursprünglichen Ergebnisse abgerufen werden.

Die Methode zur Kontextabfrage ist wichtig.

Die subjektive Intention ist ein wichtiger Faktor bei der Bestimmung der Genauigkeit eines Ergebnisses und bei der Bewertung seiner Relevanz. Ohne die Möglichkeit, die Absicht des Benutzers bei der Durchführung der Abfrage zu berücksichtigen (ausgedrückt durch eine flexible Syntax oder durch eine Neubewertung in einer zweiten Stufe), können wir nur aus den bereits im Modellraum kodierten Kontexten auswählen. Um diesem Mangel an Kontext zu begegnen, setzen wir üblicherweise Techniken wie Retrieval Augment Generation (RAG) ein. Die Funktionsweise von RAG besteht darin, dass die Koordinaten der Abfrage effektiv verschoben werden, indem zusätzliche verwandte Begriffe aus einer Vorabfrage für kontextrelevante Daten einbezogen werden. Dadurch wird die Art und Weise, wie die Engine diesen zusätzlichen Kontext bereitstellt, und ihre anfängliche Methode zur Datenabfrage umso wichtiger für die Genauigkeit des Kontextes!

Lassen Sie uns die verschiedenen Methoden zur Kontextabfrage und deren Einfluss auf eine RAG-Operation betrachten:

• Hybride Suchabrufe ohne Suchmaschine weisen immer noch einen Mangel an subjektiver Relevanz auf. Wenn die Plattform, die RAG bereitstellt, im Wesentlichen auf SQL basiert (was auf die meisten „Data Lake“-Plattformen zutrifft), fehlt ihr die Relevanzbewertung in der ersten Abrufphase. Viele Data-Lake-Plattformen bieten ihre eigene Version des hybriden Retrieval (nicht der Suche) an, wobei in der Regel Reranking-Techniken wie semantisches Reranking und RRF auf ihren SQL-basierten Retrieval- und Vektordatenbankergebnissen kombiniert werden. Eine einfache Sortierung reicht offensichtlich nicht für eine subjektive Rangfolge aus, aber selbst wenn sie als Grundlage für eine semantische Neubewertung in einem zweiten Schritt verwendet wird, wird SQL als erste Stufe der Abfrage problematisch, wenn die semantische Neubewertung nur auf den „Top k“ Treffern durchgeführt wird – ohne eine Möglichkeit, die Ergebnisse bei der Abfrage zu bewerten, welche Garantie haben wir, dass die besten Ergebnisse tatsächlich unter den Top-Ergebnissen enthalten sind?

• Vektorähnlichkeit allein reicht für RAG nicht aus. Das liegt eigentlich an einer Reihe von sich gegenseitig verstärkenden Problemen – es ist der Verlust beim Einbetten, zusammen mit naiven Chunking-Methoden, der Art und Weise, wie Ähnlichkeit berechnet wird, und der entscheidenden fehlenden Komponente der subjektiven Absicht. Eines der Hauptziele von RAG ist es, generative KI-Interaktionen auf objektiver Wahrheit zu gründen, um sowohl Halluzinationen zu verhindern als auch das LLM über private Informationen zu informieren, von denen es während des Trainings keine Kenntnis hatte. Wir können den durch RAG bereitgestellten zusätzlichen Kontext nutzen, um LLMs einzuschränken und anzuleiten, die Verbindungen und Details zu berücksichtigen, von denen wir wissen, dass sie für die Beantwortung der jeweiligen Frage am wichtigsten sind. Dazu müssen wir sowohl semantische als auch lexikalische Ansätze verwenden.

• Dateibasierte grep/regex RAG. Einige Kreise im Universum der agentenbasierten KI plädieren für die Verwendung stark vergrößerter Kontextfenster, die über grep und reguläre Ausdrücke für RAG auf lokale Dateien zugreifen, anstatt externe Abrufplattformen zu nutzen. Die Idee dahinter ist, dass LLMs mit einem wesentlich größeren Kontextfenster in der Lage sein werden, konzeptionelle Verbindungen innerhalb ihres eigenen Denkraums herzustellen, anstatt sich auf fragmentierte Informationen und verschiedene Abrufmethoden/Plattformen zu verlassen, um relevante Informationen zu sammeln. Theoretisch ist es zwar richtig, dass ein ganzes Dokument ein umfassenderes Bild liefert als Dokumentsegmente, dies funktioniert jedoch nur in kleinen Datenbereichen (oder beispielsweise bei der Bereitstellung von Dateien für Vibecoding), und selbst dann besteht die erste Abrufmethode in einem Scan aller Dokumente mit einer reinen Stichwortübereinstimmung.

Suche ist mehr als nur Abruf.

Suchmaschinen sind speziell dafür entwickelt, Suchanfragen so schnell und flexibel wie möglich zu gestalten. Intern nutzen sie spezialisierte Datenstrukturen zum Speichern und Abrufen verschiedener Datentypen, die auf diese Datentypen zugeschnitten sind. Elasticsearch bietet optimiertes Speichern und Abfragen für praktisch alle Datentypen, einschließlich unstrukturierter/Volltext-Lexikalsuche (Match, Phrase, Proximity, Multi-Match), schneller Keyword-Suche (exakte Übereinstimmung) und Filterung, numerischer Bereiche, Datumsangaben, IP-Adressen und ist sehr flexibel in der Speicherung von Dokumentstrukturen (z. B. …). verschachtelte oder flache Dokumente). Elasticsearch ist außerdem eine native Vektordatenbank, die sowohl dünnbesetzte als auch dichte Vektortypen speichern und abfragen kann, und wir erforschen weiterhin innovative Wege (zum Beispiel Better Binary Quantization (BBQ) & DiskBBQ), um die Suchgenauigkeit zu erhalten und gleichzeitig die Geschwindigkeit, Skalierbarkeit und Kosten im Zusammenhang mit vektorisierten Inhalten zu verbessern. Die Elasticsearch-Plattform bietet zudem integrierte Datenstabilität und Hochverfügbarkeit und beinhaltet Funktionen für das Datenlebenszyklusmanagement wie Searchable Snapshots , mit denen Sie selten genutzte oder langfristig aufzubewahrende Daten auf kostengünstigem Objektspeicher speichern können – und diese dennoch vollständig durchsuchbar sind.

Die Hybridsuche vereint das Beste aus allen Welten.

Hybride Suche (nicht nur hybride Abfrage!) kombiniert die Stärken der traditionellen lexikalischen Suche mit dem semantischen Verständnis von LLMs und der Vektorähnlichkeitssuche. Diese Synergie ermöglicht es, bereits in der Abrufphase hochrelevante Ergebnisse durch die flexiblen Abfragesyntaxoptionen einer Suchmaschine zu erzielen: absichtsgesteuerte Syntaxoptionen und Relevanzbewertung, multimodaler Datenabruf, Filterung, Aggregation und Biasing. Mit Suchsyntax wie ES|QL und mehrstufigen Abrufern können wir die traditionelle Suche flexibel mit semantischer Suche, Filtern und mehreren Reranking-Techniken in einer einzigen Anfrage kombinieren.

Einer der größten Vorteile der hybriden Suche ist, dass Ihre Abfragen eine spezialisierte Syntax für mehrere verschiedene Datentypen gleichzeitig verwenden können. Diese unterschiedlichen Abfragesyntaxen können nicht nur zum Auffinden von Ergebnissen verwendet werden, sondern auch als Filter oder Aggregationen der Ergebnisse. Ein Beispiel hierfür ist die Geodatenanalyse, eine der häufigsten Abfragearten, die oft mit anderen Syntaxelementen kombiniert wird. Sie können beispielsweise Abfragen durchführen, um Ergebnisse zu erhalten, deren Geokoordinaten sich innerhalb einer bestimmten Entfernung von einem Punkt befinden, oder um Aggregationen Ihrer Ergebnisse nach Region anzufordern, oder um Aggregationen anzufordern, um Bewegungen in/aus einer Zone zu verfolgen und Warnungen auszugeben. Mit der Hybridsuche haben Sie die Flexibilität, Syntaxen zu kombinieren, um Ergebnisse so präzise wie möglich zu liefern und die Inhalte abzurufen, die Ihrem Kontext am nächsten kommen.

Pause

Dieser erste Teil erzählt die Geschichte, wie die Vektorsuche die Art und Weise verändert hat, wie wir Daten abrufen können, und bereitet den Boden für die Veränderungen, die LLMs an den Abfragemechanismen mit sich gebracht haben, mit denen wir mit Daten interagieren. Wir werden so tun, als hätten wir das in mehrere Teile aufteilen müssen, damit LLMs es verstehen können, ohne den Kontext zu verlieren… ;-) Erfahren wir mehr darüber, warum das wichtig ist, in Teil II: Agentische KI und die Notwendigkeit des Kontext-Engineerings, und in Teil III kehren wir zu unserer Diskussion über die hybride Suche zurück.