Die Rolle von Vektordatenbanken in generativen KI-Anwendungen

von G2 Krishnamoorthy, Rahul Pathak, and Vlad Vlasceanu übersetzt durch David Surey

Generative KI hat unsere Vorstellungskraft erweitert und transformiert Branchen mit ihrer Fähigkeit, Fragen zu beantworten, Geschichten zu schreiben, Kunst zu erstellen und sogar Code zu generieren. AWS-Kunden fragen uns zunehmend, wie sie generative KI am besten in ihren eigenen Unternehmen nutzen können. Die meisten Unternehmen verfügen über eine Vielzahl an bereichsspezifischen Daten, darunter Finanzdaten, Gesundheitsdaten, Genom-Daten, Lieferketten. Diese Daten bieten ihnen einen einzigartigen und wertvollen Einblick in ihr Geschäft und die gesamte Branche. Diese proprietären Daten können ein Vorteil und Differenzierungsmerkmal für Ihre generative-KI-Strategie sein.

Gleichzeitig haben viele Kunden auch den Anstieg der Popularität von Vektordatenspeichern oder Vektordatenbanken bemerkt, die in generativen KI-Anwendungen verwendet werden, und fragen sich, wie diese Lösungen in ihre gesamte Datenstrategie rund um generative KI-Anwendungen passen.

In diesem Beitrag beschreiben wir die Rolle von Vektordatenbanken in generativen KI-Anwendungen und wie Ihnen die AWS-Lösungen dabei helfen können, die Vorteile der generativen KI zu nutzen.

Generative KI-Anwendungen

Im Zentrum jeder generativen KI-Anwendung steht ein großes Sprachmodell (LLM) [extern]. Ein LLM ist ein maschinelles Lernmodell, das auf einer großen Menge an Inhalten trainiert wurde – wie etwa allem Inhalt, der im Internet zugänglich ist. LLMs, die auf riesigen Mengen öffentlich zugänglicher Daten trainiert wurden, gelten als Basismodelle (FM) [extern]. Sie können für eine Vielzahl von Anwendungsfällen angepasst und verfeinert werden. Amazon SageMaker JumpStart bietet eine Vielzahl von vortrainierten, quelloffenen und proprietären Basismodellen, auf denen Sie aufbauen können, wie z.B. das Text2Image-Modell von Stability AI [en], das fotorealistische Bilder unter Verwendung einer Textaufforderung generieren kann, oder das Text2Text-Flan-T-5-Modell von Hugging Face [EN] für die Texterzeugung. Amazon Bedrock ist die einfachste Lösung für die Erstellung und Skalierung generativer KI-Anwendungen mit FMs. Sie gibt Ihnen Zugriff auf Modelle von AI21 Labs, Anthropic, Mistral, Stability AI und Amazon Titan über eine API.

Eine generative KI-Anwendung, die sich rein auf ein FM stützt, verfügt zwar über Zugriff auf breites, realweltliches Wissen, jedoch muss sie an bereichsspezifische oder spezialisierte Themen angepasst werden, um genaue Ergebnisse zu liefern.

Auch Halluzinationen (Ergebnisse, die präzise erscheinen, aber tatsächlich ungenau sind) [extern] treten umso häufiger auf, je spezialisierter die Interaktion ist. Wie können Sie also Ihre generative KI-Anwendung für eine bereichsspezifische Genauigkeit anpassen?

Hinzufügen von Domönenwissen mithilfe von Vektordatenbanken

Das Prompt-Engineering (auch als In-Context-Learning bezeichnet) [extern] ist möglicherweise der einfachste Weg, um Ihre generative KI-Anwendung in Ihren bereichsspezifischen Kontext einzubinden und die Genauigkeit zu verbessern. Obwohl es Halluzinationen nicht vollständig eliminieren wird, wird diese Technik den Bereich der semantischen Bedeutung auf Ihren eigenen Bereich eingrenzen.

Im Kern leitet das FM das nächste Token basierend auf einer Reihe von Eingabe-Tokens ab. Ein Token bezieht sich in diesem Fall auf jedes Element mit semantischer Bedeutung, wie ein Wort oder eine Phrase in der Texterzeugung. Je mehr kontextrelevante Eingaben Sie bereitstellen, desto höher ist die Wahrscheinlichkeit, dass das nächste abgeleitete Token ebenfalls kontextrelevant ist. Der Prompt, mit der Sie das FM abfragen, enthält die Eingabe-Tokens sowie so viele kontextrelevante Daten wie möglich.

Kontextdaten stammen in der Regel aus Ihren internen Datenbanken oder Data Lakes. Data Lakes sind Systeme, in denen Ihre domänenspezifischen Daten gespeichert sind. Obwohl Sie der Prompt durch einfaches Anhängen zusätzlicher bereichsspezifischer Daten aus diesen Datenspeichern anreichern können, helfen Ihnen Vektordatenbanken, Ihre Prompts mit semantisch relevanten Eingaben zu erstellen. Diese Methode wird als retrieval-gestützte Generierung (Retrieval Augmented Generation, RAG) [EN] bezeichnet. In der Praxis werden Sie einen Prompt erstellen, die sowohl kontextuell personalisierte Daten wie Benutzerprofil-Informationen als auch semantisch relevante Daten enthält.

Für die Verwendung in generativen KI-Anwendungen müssen Ihre bereichsspezifischen Daten als Satz von Elementen codiert werden, von denen jedes intern als Vektor dargestellt wird. Der Vektor enthält eine Reihe numerischer Werte über eine Reihe von Dimensionen. Die folgende Abbildung veranschaulicht ein Beispiel für die Umwandlung von Kontextdaten in semantische Elemente und dann in Vektoren.

Abbildung 1: Beispiel der Datentransformation

Diese numerischen Werte werden verwendet, um Elemente in Bezug zueinander in einem mehrdimensionalen Vektorraum abzubilden. Bei semantischen Vektorelementen, also Elementen, die eine Form von Bedeutung darstellen, lässt sich die räumliche Nähe als Indikator für den kontextuellen Zusammenhang verwenden. In diesem Sinne werden solche Vektoren als Embeddings bezeichnet. Zum Beispiel könnte das semantische Element für „Käse“ in der Nähe des semantischen Elements für „Milchprodukt“ in einem mehrdimensionalen Raum platziert werden, der den Datenbereichskontext von Lebensmitteln oder Kochen darstellt. Abhängig von Ihrem spezifischen Domänenkontext kann ein semantisches Element ein Wort, eine Phrase, ein Satz, ein Absatz, ein ganzes Dokument, ein Bild oder etwas ganz anderes sein. Der bereichsspezifische Datensatz wird in bedeutungstragende Elemente aufgeteilt, die zueinander in Beziehung gesetzt werden können. Die folgende Abbildung zeigt zum Beispiel einen vereinfachten Vektorraum für einen Kontext rund um das Kochen.

Abbildung 2: Beispiel eines Vektorraumes

Als Ergebnis müssen Sie, um den relevanten Kontext für den Prompt zu erzeugen, eine Datenbank abfragen und Elemente finden, die in Bezug auf Ihre Eingaben im Vektorraum eng verwandt sind. Eine Vektordatenbank ist ein System, das es ermöglicht, Vektoren in großem Maßstab zu speichern und abzufragen, mit effizienten Nearest-Neighbor-Abfragealgorithmen [extern] und geeigneten Indizes, um den Datenabruf zu verbessern. Jedes Datenbankmanagementsystem, das diese Vektor-bezogenen Funktionen bietet, kann eine Vektordatenbank sein. Viele der gängigen Datenbanksysteme bieten diese Vektor-Funktionen zusammen mit ihrer übrigen Funktionalität an. Ein Vorteil der Speicherung Ihrer bereichsspezifischen Datensätze in einer Datenbank mit Vektor-Funktionen ist, dass sich Ihre Vektoren in der Nähe der Quelldaten befinden. Sie können Vektordaten mit zusätzlichen Metadaten anreichern, ohne externe Datenbanken abfragen zu müssen, und Sie können Ihre Datenverarbeitungspipelines vereinfachen.

Um Ihnen den Einstieg in Vektordatenbanken zu erleichtern, haben wir das Vektormodul für Amazon OpenSearch Serverless [EN] veröffentlicht, welches eine einfache API zum Speichern und Abfragen von Milliarden von Embeddings bietet. Langfristig denken wir jedoch, dass alle AWS-Datenbanken Vektor-Funktionen haben werden, da dies Ihren Betrieb und Ihre Datenintegration vereinfacht. Darüber hinaus stehen folgende Optionen für fortgeschrittenere Vektordatenbank-Bedürfnisse zur Verfügung:

– Amazon Aurora PostgreSQL-kompatible Edition, eine relationale Datenbank, mit der quelloffenen pgvector-Erweiterung [EN, extern] für Vektorsimilaritätssuche.

– Amazon OpenSearch Service, ein verteilter Such- und Analyseservice, mit dem k-NN (k-nearest neighbor)-Plugin [EN, extern] und dem Vektormodul für Amazon OpenSearch Serverless [EN].

– Eine Amazon Relational Database Service (Amazon RDS)-Datenbank für PostgreSQL, mit der pgvector-Erweiterung.

Die Wahl der Speicheroption für Ihre Embeddings hängt von verschiedenen Faktoren ab. Dazu zählen der Ort der Datenspeicherung, Ihre Erfahrung mit Datenbanktechnologien sowie die Skalierungsanforderungen. Bevor wir tiefer in die spezifischeren Anleitungen für diese Optionen einsteigen, verstehen wir zunächst, wie RAG funktioniert und wie Sie Vektordatenbanken in RAG anwenden.

Verwendung von Vektordatenbanken für RAG

Abbildung 3: Architektur eines Dataflows

Sie können Embeddings (Vektoren) verwenden, um die Genauigkeit Ihrer generativen KI-Anwendung zu verbessern. Das folgende Diagramm veranschaulicht diesen Datenfluss.

Sie teilen Ihren bereichsspezifischen Datensatz, dargestellt in der rechten Hälfte der vorherigen Abbildung in blauer Farbe, in semantische Elemente auf. Sie verwenden dann das FM, um die Vektoren für diese semantischen Elemente zu berechnen. Dann speichern Sie diese Vektoren in einer Vektordatenbank, der es Ihnen ermöglicht, Ähnlichkeitssuchen durchzuführen.

Ihrer generativen KI-Anwendung, in der vorangegangenen Abbildung auf der linken Seite in Orange dargestellt, nehmen Sie die vom Endnutzer bereitgestellte Frage entgegen und zerlegen sie in semantische Elemente (Tokenisierung). Dazu verwenden Sie den gleichen Algorithmus, der auch für die Verarbeitung Ihres Datensatzes zum Einsatz kommt. Im Anschluss fragen Sie die Vektordatenbank nach den nächstgelegenen Nachbarn im Vektorraum für die Eingabe-Elemente ab.

Der Speicher wird Ihnen kontextuell ähnliche semantische Elemente liefern, die Sie dann zu Ihrem erstellten Prompt hinzufügen. Dieser Prozess wird das LLM weiter in Ihren bereichsspezifischen Kontext einbinden und die Wahrscheinlichkeit erhöhen, dass die LLM-Ausgabe für diesen Kontext genau und relevant ist.

Das Durchführen von Ähnlichkeitssuchen in Ihrer Vektordatenbank im kritischen Pfad von Endnutzern verwendet gleichzeitige Leseabfragen. Batchprozesse zum Auffüllen der Vektordatenbank mit Embeddings und zum Aktualisieren von Datenänderungen sind in erster Linie Datenschreibvorgänge in den Vektordatenbanken. Die genannten Aspekte sowie die zuvor genannten Überlegungen hinsichtlich Vertrautheit und Skalierung sind ausschlaggebend dafür, welcher Dienst für Sie am besten geeignet ist. Dabei kann es sich um Aurora PostgreSQL-kompatibel, Amazon OpenSearch Service, das Vektormodul für Amazon OpenSearch Serverless oder Amazon RDS für PostgreSQL handeln.

Überlegungen zu Vektordatenbanken

Das von uns beschriebene Nutzungsmuster führt auch zu einigen einzigartigen und wichtigen Überlegungen für Vektordatenbanken.

Die Anzahl der von Ihnen gewünschten Embeddings ist abhängig vom Volumen der bereichsspezifischen Daten, die Sie verwenden möchten, sowie dem Prozess, den Sie zum Aufteilen dieser Daten in semantische Elemente verwenden. Da Ihre bereichsspezifischen Daten im Laufe der Zeit wachsen und sich ändern, muss auch Ihr eVektordatenbank mit diesem Wachstum Schritt halten. Dies hat Auswirkungen auf die Indexierungseffizienz und Leistung bei Skalierung. Es ist nicht ungewöhnlich, dass bereichsspezifische Datensätze zu Hunderten von Millionen – sogar Milliarden – von Embeddings führen. Sie verwenden einen Tokenizer [extern], um die Daten aufzuteilen, und das Natural Language Toolkit (NLTK) [EN, extern] bietet mehrere allgemein verwendbare Tokenizer, die Sie verwenden können. Es gibt aber auch Alternativen. Der richtige Tokenizer ist abhängig von der jeweiligen Bedeutung des semantischen Elements in Ihrem bereichsspezifischen Datensatz. Hierbei kann es sich um ein Wort, eine Phrase, einen Absatz, ein gesamtes Dokument oder eine beliebige Unterteilung Ihrer Daten handeln, die eine unabhängige Bedeutung aufweist.

Die Anzahl der Dimensionen für die Embedding-Vektoren ist ein weiterer wichtiger Faktor, den es zu berücksichtigen gilt. Verschiedene FMs erzeugen Vektoren mit unterschiedlichen Dimensionszahlen. Das all-MiniLM-L6-v2-Modell [EN, extern] beispielsweise erzeugt Vektoren mit 384 Dimensionen, und Falcon-40B-Vektoren [EN, extern] haben 8.192 Dimensionen. Je mehr Dimensionen ein Vektor hat, desto reichhaltiger kann der dargestellte Kontext sein – bis zu einem gewissen Punkt. Irgendwann werden Sie erhöhte Abfrage-Latenz beobachten. Dies führt schließlich zum „Fluch der Dimensionalität“ (Objekte erscheinen dünn und unähnlich) [extern]. Um semantische Ähnlichkeitssuchen [EN, extern] durchzuführen, benötigen Sie in der Regel Vektoren mit dichter Dimensionalität, müssen die Dimensionen Ihrer Embeddings für Ihre Datenbank aber möglicherweise reduzieren [EN, extern], damit sie solche Suchen effizient durchführen kann.

Eine weitere Überlegung ist, ob Sie exakte Ähnlichkeitssuche-Ergebnisse benötigen. Die Indexierungsfähigkeiten in Vektordatenbanken werden die Ähnlichkeitssuche erheblich beschleunigen. Zur Generierung von Ergebnissen wird ein Algorithmus für approximative nächste Nachbarn (Approximate Nearest Neighbor, ANN) [EN, extern] verwendet. Dieser bietet eine hohe Leistungs- und Speichereffizienz, erfordert jedoch gewisse Abstriche bei der Genauigkeit. Es ist nicht garantiert, dass immer die exakt nächst

Schließlich müssen Sie auch den Datenschutz [EN] berücksichtigen. Ihre bereichsspezifischen Datensätze enthalten wahrscheinlich sehr sensible Daten wie personenbezogene Daten [extern] oder geistiges Eigentum. Mit Ihrer Vektordatenbank in der Nähe Ihrer bestehenden bereichsspezifischen Datensätze können Sie Ihre Zugriffskontrollen, Qualitäts- und Sicherheitskontrollen auf Ihre Vektordatenbank ausdehnen und so den Betrieb vereinfachen. In vielen Fällen wird es nicht praktisch sein, solche sensiblen Daten zu entfernen, ohne die semantische Bedeutung der Daten zu beeinträchtigen, was wiederum die Genauigkeit reduziert. Daher ist es wichtig, den Fluss Ihrer Daten durch die Systeme zu verstehen und zu kontrollieren, die Embeddings erstellen, speichern und abfragen.

Verwendung von Aurora PostgreSQL oder Amazon RDS für PostgreSQL mit pgvector

Pgvector, eine quelloffene, von der Community unterstützte PostgreSQL-Erweiterung, ist sowohl in Aurora PostgreSQL als auch in Amazon RDS für PostgreSQL verfügbar. Die Erweiterung erweitert PostgreSQL um einen Vektorentyp namens vector, drei Abfrageoperatoren für die Ähnlichkeitssuche (euklidische Distanz [extern], negative innere Produkte und Cosinusähnlichkeit [extern]) und den ivfflat-Indexierungsmechanismus (invertierte Datei mit gespeicherten Vektoren) [EN, extern] für Vektoren, um schnellere approximative Distanzsuchen durchzuführen. Obwohl Sie Vektoren mit bis zu 16.000 Dimensionen speichern können, können nur 2.000 Dimensionen indiziert werden, um die Leistung der Ähnlichkeitssuche zu verbessern. In der Praxis neigen Kunden dazu, Embeddings mit weniger Dimensionen zu verwenden. Der Beitrag Building AI-powered search in PostgreSQL using Amazon SageMaker and pgvector (KI-gestützte Suche in PostgreSQL mit Amazon SageMaker und pgvector aufbauen) [EN] ist eine großartige Ressource, um tiefer in diese Erweiterung einzutauchen.

Sie sollten Aurora PostgreSQL mit der pgvector-Erweiterung für Ihre Vektordatenbank stark in Betracht ziehen, wenn Sie bereits stark in relationale Datenbanken, insbesondere PostgreSQL, investiert sind und über viel Expertise in diesem Bereich verfügen. Hochstrukturierte, bereichsspezifische Datensätze eignen sich auch besser für relationale Datenbanken. Amazon RDS für PostgreSQL kann ebenfalls eine gute Wahl sein, wenn Sie bestimmte Community-Versionen von PostgreSQL verwenden müssen. Ähnlichkeitssuche-Abfragen (Lesevorgänge) können auch horizontal skalieren, vorbehaltlich der maximalen Anzahl von Lesereplikaten, die von Aurora in einem einzelnen DB-Cluster (15) und Amazon RDS in einer Replikationskette (15) unterstützt werden.

Aurora PostgreSQL unterstützt auch Amazon Aurora Serverless v2, eine On-Demand-Konfiguration mit automatischer Skalierung, die die Compute- und Speicherkapazität Ihrer DB-Instanzen automatisch basierend auf der Auslastung anpassen kann. Diese Konfiguration vereinfacht den Betrieb, da Sie in den meisten Anwendungsfällen nicht mehr für Spitzenlasten bereitstellen oder komplexe Kapazitätsplanung durchführen müssen.

Amazon Aurora Machine Learning (Aurora ML) ist ein Feature, das Sie nutzen können, um Aufrufe an ML-Modelle zu tätigen, die in Amazon SageMaker gehostet werden, über SQL-Funktionen. Sie können sie verwenden, um Aufrufe an Ihre FMs zu tätigen, um Embeddings direkt aus Ihrer Datenbank zu generieren. Sie können diese Aufrufe in gespeicherten Prozeduren verpacken oder sie mit anderen PostgreSQL-Funktionen integrieren, sodass der Vektorisierungsprozess für die Anwendung vollständig abstrahiert ist. Dank der Batch-Fähigkeiten in Aurora ML müssen Sie möglicherweise den ursprünglichen Datensatz aus Aurora gar nicht exportieren, um ihn in den anfänglichen Satz von Vektoren umzuwandeln.

Verwendung von Amazon OpenSearch Service mit dem k-NN-Plugin und dem Vektor-Engine für Amazon OpenSearch Serverless

Das k-NN-Plugin erweitert Amazon OpenSearch [EN, extern], eine quelloffene, verteilte Such- und Analysesuite, um den benutzerdefinierten Datentyp knn_vector, mit dem Sie Embeddings in OpenSearch-Indizes speichern können. Das Plugin bietet auch drei Methoden, um k-nearest-neighbor-Ähnlichkeitssuchen durchzuführen: Approximatives k-NN [EN, extern], Script Score k-NN (exakt) [EN, extern] und die Painless-Erweiterungen (exakt) [EN, extern]. Amazon OpenSearch enthält die Non-Metric Space Library (NMSLIB) [EN, extern] und die Facebook AI Research’s FAISS-Bibliothek [EN, extern]. Sie können verschiedene Suchalgorithmen für den Abstand verwenden, um den besten zu finden, der Ihren Bedürfnissen entspricht. Dieses Plugin ist auch in OpenSearch Service verfügbar, und der Beitrag Amazon OpenSearch Service’s vector database capabilities explained (Die Vektordatenbankfähigkeiten des Amazon OpenSearch Service erklärt) [EN] ist eine großartige Ressource, um tiefer in diese Funktionen einzutauchen.

Amazon OpenSearch ist aufgrund seiner verteilten Natur die ideale Wahl für Vektordatenbanken mit einer sehr großen Anzahl von Embeddings. Ihre Indizes skalieren horizontal, was es Ihnen ermöglicht, mehr Durchsatz für das Speichern von Embeddings und das Durchführen von Ähnlichkeitssuchen zu bewältigen. Es eignet sich auch für Kunden, die eine tiefere Kontrolle über die Methode und Algorithmen haben möchten, die zum Durchführen von Suchen verwendet werden. Suchmaschinen sind auf Niedriglatenz und hohen Durchsatz beim Abfragen ausgelegt, indem sie das transaktionale Verhalten opfern, um dies zu erreichen.

Amazon OpenSearch Serverless ist eine serverlose On-Demand-Konfiguration, die die operativen Komplexitäten des Bereitstellens, Konfigurierens und Abstimmens von OpenSearch-Domänen automatisiert und somit eine erhebliche Vereinfachung in der Nutzung mit sich bringt. Sie beginnen einfach damit, eine Sammlung von Indizes zu erstellen und mit dem Auffüllen Ihrer Indexdaten zu beginnen. Die Vektor-Engine für Amazon OpenSearch Serverless wird als neuer Vektorsammlungstyp angeboten, neben Such- und Zeitreihensammlungen. Die Vektorsimilaritätssuche bietet Ihnen einen einfachen Weg, um mit der Suche zu beginnen. Sie ermöglicht Ihnen, Vektorembeddings, Metadaten und beschreibenden Text einfach innerhalb eines einzelnen API-Aufrufs abzufragen. Dadurch werden genauere Suchergebnisse erzielt und gleichzeitig die Komplexität in Ihrem Anwendungsstapel reduziert.

Vektoren in Amazon OpenSearch mit dem k-NN-Plugin unterstützen bis zu 16.000 Dimensionen bei Verwendung der nmslib- und faiss-Engines und bis zu 1.024 Dimensionen mit der Lucene-Engine [EN, extern]. Lucene bietet die Kernsuche- und Analysekapazitäten von Amazon OpenSearch zusammen mit der Vektorsuche. Amazon OpenSearch verwendet eine benutzerdefinierte REST-API für die meisten Vorgänge, einschließlich Ähnlichkeitssuchen. Dies ermöglicht mehr Flexibilität bei der Interaktion mit OpenSearch-Indizes, während Sie gleichzeitig Fähigkeiten zum Aufbau verteilter webbasierter Anwendungen wiederverwenden können.

Amazon OpenSearch ist auch eine gute Option, wenn Sie semantische Ähnlichkeitssuche mit Schlüsselwortsuche-Anwendungsfällen kombinieren müssen. Prompt-Engineering für generative KI-Anwendungen umfasst sowohl den Abruf von Kontextdaten als auch RAG. Eine Kundenservice-Agent-Anwendung könnte beispielsweise einen Prompt erstellen, indem sie frühere Support-Fälle mit den gleichen Schlüsselwörtern sowie Support-Fälle einbezieht, die semantisch ähnlich sind, damit die empfohlene Lösung in den richtigen Kontext eingebettet ist.

Das Neural Search-Plugin (experimentell) [EN, extern] ermöglicht die Integration von ML-Sprachmodellen direkt in Ihre OpenSearch-Workflows. Mit diesem Plugin erstellt OpenSearch automatisch Vektoren für den während des Eingangs und der Suche bereitgestellten Text und verwendet die Vektoren dann nahtlos für Suchabfragen. Dies kann die für RAG verwendeten Ähnlichkeitssuche-Aufgaben vereinfachen.

Wenn Sie darüber hinaus eine vollständig verwaltete semantische Sucherfahrung für bereichsspezifische Daten bevorzugen, sollten Sie Amazon Kendra in Betracht ziehen. Es bietet integrierte semantische Suchmöglichkeiten für den State-of-the-Art-Ranking von Dokumenten und Passagen und eliminiert den Overhead für das Verwalten von Textextraktion, Passageenteilung, Embeddings-Erstellung und Verwaltung von Vektordatenbanken. Sie können Amazon Kendra für Ihre semantischen Suchanforderungen verwenden und die Ergebnisse in Ihren erstellten Prompt verpacken, um so die Vorteile von RAG mit dem geringstmöglichen operativen Overhead zu maximieren. Der Beitrag Amazon Kendra, LangChain und Large Language Models – Unternehmensdaten als Basis für generative KI Anwendungen bietet tiefergehende Anleitung für diesen Anwendungsfall.

Schließlich werden Aurora PostgreSQL und Amazon RDS für PostgreSQL mit pgvector, das Vektormodul für Amazon OpenSearch Serverless sowie Amazon OpenSearch Service mit k-NN in LangChain unterstützt. LangChain [EN, extern] ist ein beliebtes Python-Framework für die Entwicklung von datenbewussten, agentbasierten Anwendungen auf Basis von LLMs.

Zusammenfassung

Embeddings sollten in der Nähe Ihrer bereichsspezifischen Datensätze gespeichert und verwaltet werden. So können Sie sie mit zusätzlichen Metadaten kombinieren, ohne weitere, externe Datenquellen nutzen zu müssen. Ihre Daten sind auch nicht statisch, sondern ändern sich im Laufe der Zeit, und wenn Sie die Embeddings in der Nähe Ihrer Quelldaten speichern, vereinfachen Sie Ihre Datenpipelines für das Aktualisieren der Embeddings.

Aurora PostgreSQL und Amazon RDS für PostgreSQL mit pgvector sowie das Vektormodul für OpenSearch Serverless und OpenSearch Service mit dem k-NN-Plugin sind hervorragende Optionen für Ihre Vektordatenbank-Bedürfnisse, aber welche Lösung für Sie am besten geeignet ist, hängt letztendlich von Ihrem Anwendungsfall und Ihren Prioritäten ab. Wenn Ihre Datenbank keine Vektorfunktionen hat, umspannen die in diesem Beitrag besprochenen Optionen das Spektrum der Vertrautheit mit SQL und NoSQL und sind relativ einfach aufzunehmen, ohne großen operativen Aufwand. Unabhängig davon, welche Option Sie wählen, muss Ihre Vektordatenbank-Lösung den gleichzeitigen Durchsatz bewältigen können, der von der Anwendung übermittelt wird. Um Ihre Lösung im Maßstab zu validieren, führen Sie eine Suche mit einem vollen Satz von Embeddings durch. So können Sie sicherstellen, dass die Antwortlatenzen für die Ähnlichkeitssuche Ihren Erwartungen entsprechen.

Gleichzeitig ermöglicht Prompt-Engineering in Verbindung mit Basismodellen, die von SageMaker JumpStart und Amazon Bedrock bereitgestellt werden, die Entwicklung innovativer generativer KI-Lösungen, die Ihre Kunden begeistern. Dabei ist kein bedeutender Einsatz von ML-Fähigkeiten erforderlich.

Abschließend ist zu beachten, dass sich die Technologie in diesem Bereich sehr schnell weiterentwickelt und unsere Empfehlungen in diesem Beitrag möglicherweise nicht universell gültig sind, auch wenn wir uns bemühen werden, unsere Anleitung zu aktualisieren, sobald sich Dinge ändern.

Beginnen Sie noch heute mit dem Aufbau generativer KI-Anwendungen auf AWS! Entdecken Sie die Tools und Funktionen, die AWS bietet, um Ihnen zu helfen, schneller zu innovieren und Kundenerlebnisse neu zu erfinden.

Über die Autoren:

	G2 Krishnamoorthy ist Vice President of Analytics und leitet die AWS-Dienste für Data Lake, Datenintegration, Amazon OpenSearch Service und Amazon QuickSight. Vor seiner aktuellen Rolle baute und leitete G2 die Analytics- und ML-Plattform bei Facebook/Meta und war an verschiedenen Teilen der SQL Server-Datenbank, Azure Analytics und Azure ML bei Microsoft beteiligt.
	Rahul Pathak ist Vice President der Relational Database Engines und leitet Amazon Aurora, Amazon Redshift und Amazon QLDB. Vor seiner derzeitigen Rolle war er Vice President of Analytics bei AWS, wo er am gesamten AWS-Datenbankportfolio gearbeitet hat. Er hat zwei Unternehmen mitbegründet, eines mit Fokus auf digitale Medienanalyse und das andere auf IP-Geolokalisierung.
	Vlad Vlasceanu ist der weltweite technische Leiter für Datenbanken bei AWS. Er konzentriert sich darauf, die Akzeptanz zweckgebundener Datenbanken bei Kunden zu beschleunigen und Anleitungsmechanismen zu entwickeln, die Kunden dabei unterstützen, die richtigen Datenbanken für ihre Workloads auszuwählen. Außerdem leitet er die Datenbank-Expertengemeinschaft innerhalb von AWS. In dieser Rolle arbeitet er daran, die Datenbankfähigkeiten der Solutions Architects zu entwickeln und es ihnen zu ermöglichen, ihren Kunden optimale Datenbanklösungen bereitzustellen.