So erstellen Sie eine produktionsreife Text2SQL-Engine

Die Interaktion mit Datenbanken erfordert oft ein gewisses Maß an technischem Fachwissen, das dazu führen kann, dass viele Menschen nicht so leicht auf die Daten zugreifen können. Stellen Sie sich einen Finanzmanager vor, der die Finanzzahlen und -trends des Unternehmens verstehen muss. Traditionell müsste sich dieser Manager auf SQL-Analysten verlassen, um die erforderlichen Daten aus der Datenbank zu extrahieren. Diese Abhängigkeit kann zu Verzögerungen und Kommunikationslücken führen, insbesondere wenn der Manager seine Abfragen mehrmals verfeinern muss, um die gewünschten Erkenntnisse zu erhalten. Doch text2SQL, eine Funktion, die natürliche Sprache in strukturierte Abfragesprachenanweisungen umwandelt, hat die Spielregeln geändert. Mit text2SQL kann der Finanzmanager direkt in natürlicher Sprache mit der Datenbank interagieren. Ein Benutzer kann beispielsweise eine geschäftsbezogene Frage eingeben wie „Wie hoch war der durchschnittliche Bestellwert jedes Kunden im letzten Monat?“ Die Text-to-SQL-KI-Engine verarbeitet die Frage und generiert die entsprechende SQL-Abfrage: Select customer_id, AVG(order_value) AS average_order_value FROM orders WHERE order_date >= DATE_SUB(CURRDATE(), INTERVAL 1 MONTH) GROUP BY customer_id; Führen Sie es dann für die Datenbank aus und zeigen Sie dem Benutzer die Ergebnisse an. In diesem Artikel erläutern wir die Rolle von LLMs in Text2SQL, diskutieren die mit dieser Funktion verbundenen Herausforderungen und erkunden SherloQ, eine äußerst genaue und robuste Text2SQL-Engine, die vom -Team entwickelt wurde. Skypoint Die Rolle von LLMs in text2SQL Die Fähigkeit, Text in SQL umzuwandeln, hat sich mithilfe (LLMs) deutlich verbessert. Diese Modelle verwenden riesige Datenmengen und leistungsstarke neuronale Netzwerkarchitekturen, um menschenähnlichen Text zu verstehen und zu generieren. Durch Training mit unterschiedlichen Datensätzen können LLMs auf verschiedene Aufgaben verallgemeinert werden, einschließlich der Übersetzung natürlicher Sprache in SQL-Abfragen. großer Sprachmodelle Beispielsweise zeigt das Dokument „ “, wie LLMs Aufgaben mit minimalen Beispielen ausführen können, und hebt ihre Fähigkeit hervor, sich mit begrenzten Daten an neue Aufgaben anzupassen. Dieser Ansatz reduziert den Bedarf an umfangreichen aufgabenspezifischen Daten erheblich und erleichtert den Einsatz von LLMs in verschiedenen Anwendungen. Language Models are Few-Shot Learners „ “ bietet einen umfassenden Datensatz zum Trainieren und Auswerten von Modellen für komplexe SQL-Abfragen in verschiedenen Domänen. Dieser Datensatz war ausschlaggebend für die Weiterentwicklung des neuesten Stands der Technik in Text2SQL, da er einen robusten Benchmark für die Modellleistung lieferte. Spider: Ein groß angelegter, von Menschen markierter Datensatz für komplexe und domänenübergreifende semantische Analyse und Text-zu-SQL-Aufgaben Darüber hinaus untersucht „ “, wie erweiterte Trainingstechniken, z. B. die Skalierung von Modellgrößen und die Optimierung von Trainingspfaden, die Modellleistung in verschiedenen Anwendungen, einschließlich Text2SQL, verbessern können. PALM: Scaling Language Modeling with Pathways Während diese LLMs in kontrollierten Umgebungen sehr effektiv sind, stehen sie in Produktionsumgebungen oft vor Herausforderungen. Dazu gehören der Umgang mit mehrdeutigen Eingabeaufforderungen, die Verwaltung komplexer Datenbankschemata und die Gewährleistung der Echtzeitleistung. Darüber hinaus erfordert die Integration dieser Modelle in bestehende Systeme erheblichen Aufwand und laufende Wartung, um sich an veränderte Daten und Benutzeranforderungen anzupassen. Hier sind drei LLMs, die für diese Aufgabe gut geeignet sind: SQLcoder Der Hauptzweck des SQLCoder besteht darin, natürliche Spracheingaben in SQL-Abfragen umzuwandeln. Im Gegensatz zu den anderen Allzweckmodellen wurde SQLCoder auf SQL-spezifische Daten optimiert und ist daher besonders effektiv beim Verstehen und Generieren von SQL-Abfragen. SQLCoder zeigt eine bemerkenswerte Leistung beim Spider-Datensatz, einem komplexen und domänenübergreifenden Benchmark für Text2SQL-Systeme. SQLCoder generiert die korrekte SQL-Abfrage für neue Schemata, die im Training nicht vorkommen, mit einer . Es übertrifft GPT-3.5-turbo und text-davinci-003, die mehr als 10-mal so große Modelle sind. Dies unterstreicht die Fähigkeit von SQLCoder, vielfältige und komplexe SQL-Abfragen zu verarbeiten, was für Produktionsumgebungen von entscheidender Bedeutung ist. Genauigkeit von 64,6 % GPT 3.5/GPT 4 GPT-3.5 und GPT-4 (Generative Pre-trained Transformer) gehören zu den fortschrittlichsten und effektivsten Allzweck-Sprachmodellen. Beide Modelle zeichnen sich durch Few-Shot-Learning aus und passen sich mit minimalen Beispielen schnell an neue Aufgaben an, was ideal für die Erstellung von SQL-Abfragen aus begrenzten Eingaben ist. Beispielsweise liegt der Prozentsatz korrekt generierter SQL-Abfragen für GPT-3.5-turbo bei der Auswertung des Spider-Datensatzes bei 60,6 %, wenn es um neue Schemata geht, die im Training nicht enthalten waren, während GPT-4 74,3 % erreicht. Diese Modelle weisen eine robuste Leistung auf, insbesondere beim Verstehen des Kontexts und beim Generieren genauer SQL-Abfragen aus komplexen natürlichen Spracheingaben. Ihr allgemeines Design erfordert jedoch manchmal zusätzliche Feinabstimmung, um optimale Ergebnisse in speziellen Anwendungen wie der SQL-Generierung zu erzielen. PaLM SQL PaLM (Pathways Language Model) SQL ist ein weiteres leistungsstarkes Modell, das von Google entwickelt wurde. Dank der erweiterten Funktionen und Architektur von PaLM SQL kann es natürliche Sprache äußerst effizient in SQL-Abfragen übersetzen und komplexe und vielfältige Datenbankschemata mit größerer Genauigkeit verarbeiten. Trotz der Fortschritte bei LLMs kann es problematisch sein, sich in der Produktion auf ein einziges LLM für Text2SQL zu verlassen. Ein einzelnes Modell wird die große Vielfalt an Abfragen, Datenbankschemata und Echtzeit-Latenzanforderungen einer Unternehmensdatenumgebung nicht effektiv bewältigen können. Produktionsumgebungen erfordern Robustheit, Anpassungsfähigkeit und die Fähigkeit, mit mehrdeutigen Eingabeaufforderungen von realen Geschäftsbenutzern umzugehen. Daher sollte eine Text2SQL-Engine drei Eigenschaften aufweisen, um als produktionstauglich zu gelten: – Syntaktisch unterschiedliche Benutzereingabeaufforderungen können auf dieselbe SQL-Abfrage reduziert werden. Eine gute Text2SQL-Engine sollte in der Lage sein, die Motivation hinter einer Benutzereingabeaufforderung unter Berücksichtigung des Kontexts des Datenmodells zu verstehen und die SQL-Abfrage entsprechend zu formulieren. Die Fähigkeit, unterschiedliche Abfrageformulierungen zu verstehen Produktionsdatenmodelle neigen zum Chaos, wenn mehrere verschiedene Teams innerhalb einer Organisation zu ihnen beitragen und die Daten im Laufe ihres Lebenszyklus mehrmals den Eigentümer wechseln. Die Fähigkeit, mit mehrdeutigen Datenbankschemata und Datenmodellen zu arbeiten – Eine gute Text2SQL-Engine sollte in der Lage sein, das Datenmodell für den Benutzer eindeutig zu machen und sicherzustellen, dass Rauschen und Mehrdeutigkeiten nicht zu Halluzinationen führen, eine Eigenschaft aktueller LLMs, die viele Produktionsbenutzer abschreckt. Antworten, die ein Benutzer in Echtzeit erwartet, sollten in Echtzeit zurückgegeben werden. Dies bedeutet, dass die Engine optimale Abfragen innerhalb der ersten drei Versuche formulieren sollte. Es sollte sichergestellt werden, dass die Funktionsweise der Engine keine erheblichen Verzögerungen bei der Ausführung der Abfrage verursacht - Wir stellen vor: SherloQ SherloQ ist Skypoints Text2SQL-Engine, die Abfragen aus natürlicher Sprache in SQL übersetzt. Ein wesentlicher Teil der Architektur besteht darin, ein benutzerdefiniertes internes (LLM) zur Abfragegenerierung zu nutzen. Die Effektivität von SherloQ beruht jedoch auf einer Kombination aus fortschrittlichen Komponenten, die die Datenabfragefunktionen verbessern sollen. SherloQ zeichnet sich durch hohe Genauigkeit bei der Abfrageübersetzung, robuste Fehlerbehandlung und nahtlose Integration mit Produktionsdatenbanksystemen aus und eignet sich daher für große Datenumgebungen. In den nächsten Abschnitten gehen wir auf die internen Architekturdetails von SherloQ ein und teilen einige der Ergebnisse, die wir bei der Verwendung in Produktionsumgebungen erzielt haben. Architekturkomponenten von SherloQ Die Architektur von SherloQ besteht aus mehreren beweglichen Teilen, die jeweils dazu beitragen, die Genauigkeit, Zuverlässigkeit und Latenz des Systems zu verbessern. Hier ist ein Überblick über die Architektur: – Die Benutzereingabe ist eine Abfrage in natürlicher Sprache. Benutzereingabe Unsere Implementierung einer LangChain-Schnittstelle, die den Status während des gesamten Ausführungsprozesses verfolgt. Sie nutzt Redis und DataStax Astra DB, um den Status von Argumentation und Speicher während der Ausführung zu verfolgen. Der Executor verwaltet den Ablauf der Vorgänge durch die Koordination zwischen verschiedenen Modulen. State Agent Eeecutor – Es stellt sicher, dass Benutzereingaben korrekt analysiert, verarbeitet und an nachfolgende Komponenten weitergeleitet werden, sodass ein Fluss von der Eingabe bis zur Generierung der SQL-Abfrage aufrechterhalten wird. – Eine erweiterte Klasse des Langchain Base Tools, die eine Statusvariable hat und diesen Status an das jeweilige Tool weitergibt. Durch die Pflege einer Statusvariable verfolgt das State-Tool die erforderlichen Daten, die an die jeweiligen Tools weitergeleitet werden müssen. Dies stellt die Konsistenz des Datenflusses sicher und verhindert Informationsverluste beim Übergang zwischen Agenten. State-Tool : Die staatlichen Werkzeuge von SherloQ verwendet die abgerufenen Few-Shot-Abfragen, den Datenmodellkontext und das DB-Schema, um die erste SQL-Abfrage zu generieren. Es verbessert die Genauigkeit und Relevanz der generierten SQL-Abfragen, indem es analysierte Schemainformationen verwendet und aus kontextbezogenen Beispielen lernt. Das Abfragegenerierungstool analysiert alle während der Abfrageausführung auftretenden Fehler und generiert eine neue Abfrage, die den Fehler behebt. Das Wiederholungstool hilft beim Abrufen des Datenbankschemas und der entsprechenden Metadaten (Anmerkungen, Kommentare usw.), die für die Abfragegenerierung hilfreich sein könnten. Die abgerufenen Schemainformationen werden mithilfe eines zeitbasierten Caching-Mechanismus zwischengespeichert, um die Leistung zu optimieren und Datenbankabfragen zu reduzieren. Außerdem führt es die Abfrage an die Datenbank aus und gibt die Ergebnisse oder einen Fehlerstapel-Trace zurück. Das DB-Tool Dateneingaben und Techniken zur Verbesserung der Leistung von SherloQ Um die Leistung von SherloQ zu verbessern, verwenden wir verschiedene Techniken und versorgen das Modell mit wichtigen Dateneingaben. Diese bestehen aus strukturierter Zerlegung, Beispielen mit wenigen Versuchen, Abrufen des Kontexts des Datenmodells, Reflexion und einem Wiederholungsmechanismus. Jeder Teil ist wichtig, um die Fähigkeit des Modells zu verbessern, präzise und relevante SQL-Abfragen aus natürlichen Spracheingaben zu erstellen. Strukturierte Zerlegung Bei der strukturierten Zerlegung wird die Benutzereingabeaufforderung in ihre grundlegenden Bestandteile zerlegt. Die Konzentration auf und Identifizierung der wesentlichen Komponenten der Abfrage hilft dem Modell bei der Erstellung präziser SQL-Anweisungen. Beispiel: Eingabe: Welche Menge ist derzeit für alle von XYZ Corp. gelieferten Artikel verfügbar? Ausgabe: ["aktuell verfügbare Menge", "alle Artikel", "geliefert von XYZ Corp"] Beispiele mit wenigen Aufnahmen Dem Modell werden Referenzfragen in Form einiger SQL-Beispiele bereitgestellt, die ihm dabei helfen, SQL-Abfragen basierend auf ähnlichen Mustern zu generieren. Diese Beispiele verbessern die Fähigkeit des Modells, neue SQL-Abfragen für verschiedene Eingabeaufforderungen präzise zu generieren, indem sie ihm dabei helfen, die Struktur und das Format der beabsichtigten Abfragen zu erkennen. Hier sind einige Beispiele: Beispiel 1 Eingabe: Artikel mit einer verfügbaren Menge von weniger als 20 Einheiten anzeigen. Ausgabe: SELECT * FROM stock WHERE Quantity_Available 100); Wir wählen dynamisch die ähnlichsten Beispielaufnahmen aus, indem wir die semantische Ähnlichkeitsübereinstimmung aus , unserer Vektordatenbank, verwenden. Die Vektordatenbank ermöglicht es uns, die Beispiele zu finden, die in Struktur und Inhalt der neuen Eingabeabfrage am nächsten kommen. Dadurch wird sichergestellt, dass das Modell die relevantesten Muster nutzen kann, um genaue SQL-Abfragen zu generieren. Astra DB In unserer Produktionsumgebung verwenden wir durchschnittlich etwa zwei Beispiele mit wenigen Stichproben pro Abfrage. Unserer Erfahrung nach ist das einfache Hinzufügen weiterer Beispiele mit wenigen Stichproben zur Verbesserung der Genauigkeit keine skalierbare Vorgehensweise. Datenmodellkontext Der Datenmodellkontext enthält domänenspezifische Details, die beim Erstellen einer SQL-Abfrage hilfreich sein können. Im Kontext von Finanzdaten für ein Krankenhausnetzwerk können dies beispielsweise Finanzmetrikcodes und deren Beschreibungen sein. Dieser Kontext wird vom Modell verwendet, um sicherzustellen, dass die erstellten SQL-Abfragen der Datenstruktur der Domäne entsprechen. Die Einbeziehung des Datenmodellkontexts ist optional und nur erforderlich, wenn die Tabelle komplex ist und Domänenkenntnisse zum Erstellen einer SQL-Abfrage erforderlich sind. Zum Beispiel: „MGMTFEE“ -> Beschreibung: „Für die Verwaltung von Immobilien erhobene Gebühren – Verwaltungsgebühren“ Metrikcodes: SQL-DB-Schema Das SQL-DB-Schema ist die strukturierte Darstellung der verfügbaren Daten. Das Schema wird durch die Kommentierung der Tabelle und ihrer Spalten erweitert. Es enthält Tabellennamen und -beschreibungen sowie die Spalten, ihre Beschreibungen und Datentypen. Durch die Bereitstellung des Schemas kann das Modell die Datenbankstruktur und die mit jeder Tabelle und Spalte verbundene Bedeutung besser verstehen. So wird sichergestellt, dass die generierten SQL-Abfragen syntaktisch korrekt sind und die richtigen Datenbankelemente verwenden. Spiegelung Reflexion bezieht sich auf die Fähigkeit des Modells, seine eigenen früheren Antworten, sein Verhalten oder generierten Inhalte zu beurteilen und zu bewerten. Dadurch kann das Modell seine Antworten verfeinern, indem es Fehler oder Schwächen identifiziert und korrigiert. Der Prozess umfasst die Berücksichtigung von Abfragen, die zuvor von der Sherloq-Engine gesehen wurden, sowie Feedback während der Abfragegenerierungsphase. Diese Szenarien helfen dem Modell, die Erfolge ähnlicher Fragen, die es in der Vergangenheit gesehen hat, zu reproduzieren oder deren Misserfolge zu vermeiden. Dieser Schritt nutzt auch Astra DB, um die semantisch ähnlichsten Abfragen zur aktuellen zu finden. Wiederholungsmechanismus SherloQ verfügt über einen Wiederholungsmechanismus, der die von der Datenbank empfangenen Fehler verwendet. Wenn eine generierte SQL-Abfrage zu einem Fehler führt, verwendet die Engine einen Agenten mit einer vordefinierten Vorlage, um die Abfrage zu korrigieren: „“” Ihre Aufgabe besteht darin, eine aus einer Frage generierte falsche SQL-Abfrage zu korrigieren, um sie mit ANSI SQL kompatibel zu machen. Befolgen Sie diese Richtlinien: Analysieren Sie die Frage, das Datenbankschema und die erhaltene Fehlermeldung sorgfältig, um genaue Antworten sicherzustellen. Verwenden Sie Tabellenaliase, um Verwirrung zu vermeiden. Beispiel: . SELECT t1.col1, t2.col1 FROM table1 AS t1 JOIN table2 AS t2 ON t1.id = t2.id Konvertieren Sie beim Berechnen von Verhältnissen immer den Zähler in eine Gleitkommazahl. Verwenden Sie das folgende Format: Aufgabe: Generieren Sie eine SQL-Abfrage zur Beantwortung der Frage [QUESTION] [/QUESTION] Die korrekte Abfrage lautet: {sql_query} Die bei der letzten Ausführung empfangene Fehlermeldung lautet: {error_message} {user_input} Antwort: Basierend auf den obigen Eingaben ist hier die korrigierte SQL-Abfrage: {response_sql} “”” Vergleich der Ergebnisse: Vor und nach der SherloQ-Implementierung Durch die Verwendung fortschrittlicher LLMs und eines gut konzipierten Systems erzeugt SherloQ präzisere und kontextbezogenere SQL-Abfragen. Hier vergleichen wir die Ergebnisse der Benutzereingabeaufforderungen vor und nach SherloQ anhand der Metriken Latenz und Genauigkeit. Vergleich anhand einer Produktionsfrage Hier sehen wir uns einen unserer Produktionskunden an, einen bekannten Betreiber von Seniorenwohnheimen. Einer ihrer Anwendungsfälle ist, dass ihr Finanzteam die Plattform von Skypoint nutzt, um die konsolidierten Finanzkennzahlen ihrer verschiedenen Seniorenwohnheime zu verstehen und zu beurteilen. „Bestimmen Sie den vierteljährlichen Trend der Housekeeping-Kosten für Facility CM im gesamten Jahr 2022.“ Benutzeraufforderung: Vor SherloQ Generierte Abfrage SELECT SUM(Total_Amount_Numerator) / SUM(Total_Amount_Denominator) AS Housekeeping_Expenses FROM skypoint_metric_fact_denormalized_vw WHERE Facility_Name = ‚CM‘ AND Year = 2022 AND Metric_Name = ‚Housekeeping Expense‘ GROUP BY Quarter_Number‘; Identifizierte Probleme Die Abfrage gruppiert nach „Quarter_Number“, wählt es aber nicht aus, was zu unvollständigen Ergebnissen führen kann. Verwendung von Metric_Name anstelle einer spezifischeren Kennung wie Metric_Code. Eine mögliche Division durch Null wird in SUM(Total_Amount_Denominator) nicht behandelt. Durchschnittliche Latenz: 29 Sekunden Das Setup vor SherloQ verwendete eine Kombination aus GPT-3.5 zusammen mit Prompt Engineering und 5+ Few-Shot-Abfragen pro Benutzeraufforderung. Mit SherloQ Generierte Abfrage SELECT Jahr, Quartalsnummer, SUMME (Gesamtbetragszähler) / COALESCE (SUMME (NULLIF (Gesamtbetragsnenner, 0)), 1) AS Haushaltskosten FROM skypoint_metric_fact_denormalized_vwWHERE Metrikcode = ‚EXPOTHHOU‘ UND Einrichtungsname = ‚CM‘ UND Jahr = 2022 GROUP BY Quartalsnummer, Jahr ORDER BY Quartalsnummer ASC; Verbesserungen festgestellt Die Abfrage enthält „Quarter_Number“ und bietet so die erforderliche vierteljährliche Aufschlüsselung. Das Feld „Metric_Code“ wird verwendet und bietet eine genauere Kennung für die Metrik. Die Funktion COALESCE(SUM(NULLIF(Total_Amount_Denominator,0)),1) verarbeitet mögliche Divisionsfehler durch Null. Die Ergebnisse werden nach Quartalsnummer sortiert, um den Quartalstrend widerzuspiegeln. Durchschnittliche Latenz: 10 Sekunden Basierend auf Benchmarks bei Produktionsarbeitslasten sind unten die Ergebnisse aufgeführt, die wir hinsichtlich Genauigkeit und Zuverlässigkeit vor und mit SherloQ berichten: Vor SherloQ Genauigkeit: 65 % Zuverlässigkeit: 60 % Mit SherloQ Genauigkeit: 92 % Zuverlässigkeit: 90 % Die obigen Ergebnisse stammen aus einer internen Benchmark-Suite, die jede Eingabeaufforderung 100 Mal mit separaten Kennungen ausführt, um die Auswirkungen des Caching (sowohl in unseren internen Systemen als auch in den Modellen) zu negieren. Die Suite misst die Genauigkeit, indem sie die zurückgegebene Antwort mit einer Benchmark-Antwort vergleicht, und die Zuverlässigkeit, indem sie misst, wie oft sie ähnliche Antworten zurückgibt. Der Vergleich veranschaulicht deutlich die Vorteile von SherloQ bei der Umwandlung von Abfragen in natürlicher Sprache in präzise SQL-Abfragen. Die Gesamtleistung verbesserte sich nach SherloQ um 30 %. Die zuvor generierten Abfragen litten unter Problemen wie unvollständigen Ergebnissen und fehlender Fehlerbehandlung, was sich sowohl auf die Genauigkeit als auch auf die Zuverlässigkeit auswirkte. Mit SherloQ sind die generierten Abfragen präziser, effizienter und robuster, mit deutlichen Verbesserungen bei Latenz, Genauigkeit und Zuverlässigkeit. Diese Verbesserung zeigt, dass SherloQ zuverlässige Datenabfragen ermöglicht und somit ein wertvolles Tool für Unternehmen ist, die ihre Datenabfrageprozesse optimieren möchten. Um andere Teile der Skypoint-Plattform zu erkunden oder eine Demo von SkyPoint AI zu buchen, besuchen Sie die . Skypoint-Website Von Alok Raj, leitender KI-Ingenieur, Skypoint, und Sayandip Sarkar, technischer Leiter, Skypoint