Hochleistungsdatenbasis für AI-Agents: Architektur und Ingenieurpraxis
Mit der raschen Entwicklung von Large Language Models (LLMs) entwickeln sich die von AI Agents angetriebenen neuen Generationen von AI-nativen Anwendungen rasch und haben großen Erfolg erzielt. AI-native Anwendungen basieren auf LLMs und interagieren über verschiedene Agents mit Anwendungsdaten, um verschiedene Aufgaben intelligent zu erledigen. Die Entwicklung und Iteration von Anwendungen, die von AI Agents angetrieben werden, erfolgen schnell. Gleichzeitig werden Daten in verschiedenen Modalitäten verwaltet, und die Zugriffsmuster und der Datenverkehr dieser verschiedenen Modalitäten unterscheiden sich stark. Diese Merkmale stellen neue Herausforderungen für die zugrunde liegende Datenplattform dar. Welche Art von Datenbasis wird in Zukunft für AI Agent-angetriebene native Anwendungen benötigt?
Bei der QCon Global Software Development Conference (Beijing-Standort), die von InfoQ organisiert wurde, hielt Chen Liang, Gründer und Chefarchitekt von Chenzhang Data, einen Vortrag mit dem Titel "High-Performance Data Foundation for AI Agents: Architektur und Engineering-Praktiken". Er teilte seine Überlegungen zur Architektur der Datenbasis in der AI-Ära, wie diese Architektur die Datenherausforderungen von AI-nativen Anwendungen lösen kann, sowie die Engineering-Praktiken zur Realisierung einer Hochleistungsdatenbasis in der Cloud-Computing-Umgebung und unter neuen Hardwarebedingungen mit.
Im Folgenden finden Sie die Transkription des Vortrags (bearbeitet und zusammengefasst von InfoQ ohne Änderung der ursprünglichen Bedeutung).
AI Agent-angetriebene AI-native Anwendungen
Heute führt der AI Agent die Umgestaltung des gesamten Softwareparadigmas an. Vor der AI-Ära sprachen wir über SaaS. Damals war die Software als Werkzeug eigentlich ein Arbeitsablauf, der Menschen bei der Erledigung bestimmter Aufgaben half. Wenn SaaS von AI angetrieben wird, ändert sich das Paradigma. Die Software wird intelligenter und wird zu einem Intelligenten Agenten, der sehr komplexe Aufgaben ausführen kann und sogar über eine gewisse Fähigkeit zur Selbstentwicklung und -verbesserung verfügt. In diesem Sinne ist es nicht länger ein Softwarewerkzeug, das Menschen hilft, sondern selbst ein Intelligenter Agent, der direkt einen Service anbieten kann.
In der SaaS-Ära hatte SaaS-Software einen Arbeitsablauf. Der Benutzer gab eine Eingabe ein, und der Arbeitsablauf half dem Benutzer bei der Erledigung bestimmter Aufgaben. Im Arbeitsablauf wurden viele Daten und Zustände gesammelt, die in einer Datenbank gespeichert wurden. Oft handelte es sich um strukturierte Daten. Ein bemerkenswertes Merkmal ist, dass die ersten Daten von der Software generiert wurden, oder wir können sagen, dass die Daten eine "Emission" der Software sind. In einer solchen Architektur haben Menschen relativ einfache Erwartungen an die Daten.
Zunächst wird das Datenformat oft von Softwareentwicklern definiert. Da ich die Software geschrieben habe, kann ich bestimmen, welche Attribute die Daten haben sollen, in welchem Format sie vorliegen sollen, ob es sich um eine Tabelle oder ein Diagramm handelt. Dies wird vom Entwickler festgelegt. Gleichzeitig werden die Daten im Laufe des Softwarebetriebs kontinuierlich gesammelt, was bedeutet, dass die Datenmenge mit der Größe der Software und der Interaktion mit den Benutzern langsam wächst und insgesamt kontrollierbar ist.
Natürlich wird mit zunehmender Komplexität der Software und der Menge der gesammelten Daten das Datenformat möglicherweise komplexer. Ich benötige dann eine intelligenter Analyse. Dieser Prozess ist jedoch relativ langsam und entwickelt sich mit zunehmender Popularität der Software und steigender Anzahl von Benutzern. Viele Softwareprodukte werden möglicherweise nicht zu "Hits", und ihre Anforderungen an die Daten sind daher nicht so hoch.
Was ändert sich in der Agent-Ära? Zunächst ist im Agent-Szenario der Arbeitsablauf nicht mehr der klassische Arbeitsablauf. Die Entwicklung konzentriert sich eher auf die Orchestrierung von Agenten. Wir haben möglicherweise viele Agenten. Der Kern ist natürlich das Large Language Model. Wie können wir das Large Language Model nutzen, um verschiedene Agenten anzutreiben? Ein wichtiger Unterschied ist, dass wir bereits bei der Entwicklung einer Anwendung Daten benötigen. Die Daten können aus einem Wissensspeicher oder aus externen strukturierten Daten stammen. Diese Daten sind wie der Treibstoff für den Agenten, ähnlich wie ein Auto beim Kaltstart Treibstoff benötigt. Das Large Language Model ist eher wie ein Antriebsmotor. Da es nur allgemeine Informationen liefern kann, ist es schwierig, sehr branchenspezifische Aufgaben zu lösen. Daher benötigen wir viele Daten, insbesondere branchenspezifische Daten. Diese Daten stammen jedoch von außen, und ich kann nicht vollständig kontrollieren, welches Format und welche Größe die Daten haben.
Die ständige Interaktion zwischen AI und Benutzern erzeugt auch mehr Daten, die wiederum die zugrunde liegenden Daten bilden. Wir haben viele Projekte zur Agent-Entwicklung kennengelernt und festgestellt, dass bereits am ersten Tag die Rückkopplung der Daten berücksichtigt wird. Mit anderen Worten, wir sammeln nicht nur Daten, sondern nutzen sie auch, um unseren Wissensspeicher zu erweitern. Schließlich bieten wir einen Service an, den der Benutzer als Ganzes wahrnimmt. Die Software ist nicht länger ein Werkzeug, das Menschen hilft, sondern wird selbst zu einem Intelligenten Agenten.
Nehmen wir als konkretes Beispiel ein Finanzszenario.
Hier gibt es 4 Agenten. Ein Agent ist hauptsächlich für die Marktanalyse zuständig, ein anderer Agent muss sich um das Risikomanagement kümmern, und so weiter. Aus Datenperspektive benötigen wir in dieser App möglicherweise viele verschiedene Datenbanken. Ich benötige möglicherweise Benutzerinformationen, die normalerweise in einer Tabelle gespeichert werden. Ich habe möglicherweise Finanzberichte, die oft halbstrukturierte Daten sind und einige strukturierte Informationen enthalten. Wenn der externe Wissensspeicher sehr groß ist und viele Logs enthält, müssen diese möglicherweise in einer MongoDB gespeichert werden.
Pinecone und Elastic sind uns bekannt, denn im Zeitalter der Large Language Models sind Texte sehr wichtig. Wenn wir über Textsuche sprechen, müssen wir in der Regel Vektoren und Volltextsuche kombinieren und möglicherweise auch einen Ranker verwenden. Natürlich gibt es auch Wissensspeicher, die als Graphen dargestellt werden können. Wenn Benutzer ständig Feedback geben, benötigt der Agent möglicherweise Gesprächsinformationen, und die Latenzzeit muss sehr kurz sein. Daher benötigen wir eine datenbankbasierende Speicherung in den Arbeitsspeicher.
Beim Aufbau einer Agent-Anwendung kann es bereits am ersten Tag erforderlich sein, viele verschiedene Datenbanken zu verwenden. Die Größe der externen Daten ist jedoch nicht kontrollierbar. Was tun, wenn die Datenmenge sehr groß ist? In diesem Fall müssen Sie eine skalierbare Lösung wählen. Darüber hinaus sind die Leistungsanforderungen aufgrund der Interaktion mit Benutzern sehr hoch, und die Latenzzeit muss sehr kurz sein. Daher benötigen wir unbedingt eine rein arbeitsspeicherbasierte Lösung.
Das obige Bild zeigt einen typischen Arbeitsablauf eines Agents. Es handelt sich in der Regel um einen Netzwerkservice. Der Benutzer meldet sich an, und nach der Anmeldung werden Benutzerinformationen abgerufen. Hierfür müssen Sie auf eine relationale Datenbank zugreifen.
Ein wichtiger Bestandteil des Agents ist die sogenannte "Agent Loop" oder "Schleife". Da die Interaktion in der Regel nicht nur einmal erfolgt, sondern mehrere Male iteriert werden muss, ruft der Agent möglicherweise das Large Language Model auf, um Informationen zu erhalten, und es gibt auch viele externe Aufrufe. Diese externen Aufrufe können aus einer Netzwerksuche stammen oder von einem externen Rechenservice. Ein weiterer wichtiger Ansatz ist die Retrieval Augmented Generation (RAG), bei der möglicherweise ein Volltext-Wissensspeicher verwendet wird.
Hier gibt es auch kurz- und langfristige Speicherungen mit unterschiedlichen Latenzanforderungen. Die kurzfristige Speicherung sollte möglicherweise in einem arbeitsspeicherbasierten System erfolgen, während die langfristige Speicherung mit größerer Datenmenge in einer relativ dauerhaften Datenbank gespeichert werden kann. Daher benötigen verschiedene Daten jeweils eine entsprechende Datenbank, und während der Interaktion der Anwendung werden ständig neue Daten generiert.
Fassen wir kurz zusammen. Der erste Unterschied zwischen der Internet-Ära und der Agent-Ära aus Datenperspektive besteht darin, dass die Daten in der ersten Ära von der Anwendung generiert wurden, was bedeutet, dass die Daten kontrollierbar waren. In der AI-Ära ist es jedoch anders, da möglicherweise viele externe Daten hinzukommen, die nicht vollständig kontrollierbar sind und möglicherweise auch sehr groß sein können. Darüber hinaus gibt es in der AI-Ära eine große Menge an unstrukturierten Daten. Daher müssen fast alle Datenbanken heute die Fähigkeit zur Vektorverarbeitung entwickeln, da die Suche immer wichtiger wird. Schließlich interagieren Agenten miteinander und mit der Außenwelt, und die Inhalte müssen aufgezeichnet werden. Daher kann sich die Datenmenge schnell akkumulieren.
Datenherausforderungen, denen AI-native Anwendungen gegenüberstehen
Von der Systemperspektive aus stellen die Merkmale der AI-Ära viele Herausforderungen für die Datenbankverwaltung dar. Die erste Herausforderung besteht darin, dass die Datenbank multimodale Fähigkeiten aufweisen sollte. Zweitens müssen bei der Verwendung vieler Datenbanken die Daten synchronisiert und die Datenkonsistenz gewährleistet werden. Beispielsweise haben wir möglicherweise eine kurzfristige Speicherung in einem Chat, die schließlich in eine langfristige Speicherung überführt werden muss. Gleichzeitig müssen die Ausgaben der Anwendung auch in die ursprünglichen Datenmodelle zurückgeführt werden, was zu einem Datenkreislauf führt. Drittens haben verschiedene Datenbanken in der Anwendung unterschiedliche Anforderungen an die Leistung, Größe und andere Attribute. Schließlich ist die Wartung und Verwaltung mehrerer Systeme komplex. In der heutigen AI-Ära können wir eine Anwendung schnell entwickeln. Möglicherweise kann ein Team von 3 Personen in 6 Monaten schnell eine App erstellen. Die Wartung der App wird jedoch zu einem großen Kostenfaktor, da die Daten ständig akkumuliert werden, was Ihr Kernwert ist.
Zusammenfassend lässt sich sagen, dass AI Agent-angetriebene Anwendungen bereits in der frühen Phase die Datenherausforderungen haben, denen traditionelle Großunternehmen gegenüberstehen. Gleichzeitig ist der Datenkreislauf in der AI Agent-Ära schneller, was den Druck auf das Datenbanksystem erhöht.
Multimodale Datenbasis
Vor diesem Hintergrund fragen wir uns, was wir tun sollten und ob es eine einheitliche Datenarchitektur geben kann, um diese Aufgaben zu bewältigen. Das Ziel ist schließlich eine multimodale Datenbasis.
Unsere Designziele bestehen aus drei Punkten. Der erste Punkt ist die Unterstützung von verschiedenen Datenmodalitäten. In der AI-Ära kann eine Anwendung möglicherweise mit der Unterstützung von Multimodalität konfrontiert sein. Wir möchten besonders zwei Aspekte betonen. Erstens möchten wir, dass die API nativ kompatibel ist. Beispielsweise sollte eine JSON-API zumindest mit MongoDB kompatibel sein, und eine SQL-API sollte mit MySQL kompatibel sein. Dies ist ein sehr wichtiger Punkt. Da Entwickler möchten, dass ihr System erweiterbar und migrierbar ist, können sie möglicherweise die App in der Cloud oder privat deployen. Privatdeployments können sogar viele Einschränkungen haben. Daher ist die Verwendung einer standardisierten API sehr wichtig. Natürlich kann ich auch meine eigene API definieren, aber wenn ich anderen ermöglichen möchte, Apps auf meiner Plattform zu entwickeln, besteht in Zukunft ein hohes Risiko. Zweitens möchte ich die Leistung betonen. Leistung und Kosten sind immer langfristige Überlegungen. Ich denke, dies ist für Systementwickler der wichtigste Punkt. Wenn die Leistung Ihres Systems langsamer ist als die anderer Systeme, wird Ihre Argumentation, dass der Wert Ihres Systems in der Multimodalität liegt, sehr schwach.
Das zweite Designziel ist die dynamische Skalierung und die automatische Verwaltung. Dies entspricht der heutigen Cloud-Native-Trend.
Das dritte Ziel ist der multimodale Zugriff und die Konsistenz. Zwischen den Modalitäten gibt es eine gegenseitige Synchronisierung der Daten und einen konsistenten Zugriff. Ich möchte nicht, dass beispielsweise 8 Datenbanken unabhängig voneinander funktionieren. Die Barrieren zwischen den Datenbanken müssen abgebaut werden, was ein wichtiger Aspekt der Multimodalität ist. Ich brauche keine Middleware oder einen Proxy, um alle Datenbanken zu verbinden und dann eine einheitliche Schnittstelle bereitzustellen. Dies hat nicht viel Sinn, da es die Verwaltungskosten nicht verringert. Darüber hinaus gibt es in einigen Anwendungen oft einen multimodalen Zugriff, beispielsweise von der langfristigen Speicherung zur kurzfristigen Speicherung oder von den Ergebnissen zurück in den Wissensspeicher.
Bevor ich die multimodale Datenarchitektur bespreche, möchte ich kurz die Evolutionsgeschichte der Datenbankarchitektur zusammenfassen.
Früher bestand die Datenbank eigentlich aus einer einzigen Maschine. Später hat sich die Datenbankentwicklung aufgeteilt in OLAP und OLTP. In der Cloud-Ära war die Shared-Nothing-Architektur der OLAP-Datenbank nicht mehr ideal, und es wurde eine neue Methode namens "Storage-Compute Separation" eingeführt. Auch die OLTP hatte zunächst eine Shared-Nothing-Architektur, aber ihre Entwicklung war nicht so einfach. Der Hauptunterschied zwischen TP und AP besteht darin, dass bei AP der Arbeitsspeichercache nicht so wichtig ist. Da es erforderlich ist, eine große Menge an Daten zu scannen, kann der Arbeitsspeicher diese nicht aufnehmen, und es muss schließlich auf die Festplatte zugegriffen werden. Bei der Online-TP ist es jedoch anders, da eine Latenzzeit im Millisekundenbereich erforderlich ist. Daher ist der Arbeitsspeichercache sehr wichtig und das wichtigste Mittel zur Gewährleistung der Latenzzeit. In der Shared-Nothing-Architektur befinden sich die Berechnung und der Cache nicht an einem Ort, und bei jedem Zugriff muss über das Netzwerk kommuniziert werden. In der Agent-Ära ist es schwierig, die Latenzzeit zu gewährleisten. Daher wurde in der Branche die Aurora-Architektur vorgeschlagen, bei der der Cache erhöht wird, die Berechnung und der Cache an einem Ort platziert werden, und darunter ein Speicher, den wir eine Shared-Storage-Architektur nennen. So kann die Latenzzeit gewährleistet werden.
