Creating An Information Edge With Conversational Access To Data

Neuauflage von Plato

Verfolger: 0

Konversations-KI zur Datenanalyse

Abbildung 1: Darstellung des Text2SQL-Flusses

Da unsere Welt immer globaler und dynamischer wird, sind Unternehmen immer stärker auf Daten angewiesen, um fundierte, objektive und zeitnahe Entscheidungen zu treffen. Derzeit ist es jedoch oft das Privileg einer Handvoll Datenwissenschaftler und -analysten, das volle Potenzial von Unternehmensdaten auszuschöpfen. Die meisten Mitarbeiter beherrschen den herkömmlichen Data-Science-Toolkit (SQL, Python, R etc.) nicht. Um auf die gewünschten Daten zuzugreifen, durchlaufen sie eine zusätzliche Ebene, auf der Analysten oder BI-Teams die Prosa von Geschäftsfragen in die Sprache der Daten „übersetzen“. Das Potenzial für Reibungsverluste und Ineffizienz auf diesem Weg ist hoch – zum Beispiel könnten die Daten mit Verzögerungen geliefert werden oder sogar, wenn die Frage bereits überholt ist. Informationen können unterwegs verloren gehen, wenn die Anforderungen nicht genau in analytische Abfragen übersetzt werden. Darüber hinaus erfordert die Generierung hochwertiger Erkenntnisse einen iterativen Ansatz, der bei jedem weiteren Schritt in der Schleife nicht mehr empfohlen wird. Auf der anderen Seite verursachen diese Ad-hoc-Interaktionen Störungen für teure Datentalente und lenken sie von der strategischeren Datenarbeit ab, wie in diesen „Geständnissen“ eines Datenwissenschaftlers beschrieben:

Als ich bei Square war und das Team noch kleiner war, gab es eine gefürchtete „Analyse-Bereitschafts“-Rotation. Es gab einen strikten wöchentlichen Wechsel, und wenn Sie an der Reihe waren, wussten Sie, dass Sie in dieser Woche nur sehr wenig „echte“ Arbeit erledigen würden und die meiste Zeit damit verbringen würden, Ad-hoc-Fragen der verschiedenen Produkt- und Betriebsteams zu beantworten Unternehmen (SQL-Monkeying, wie wir es nannten). Es herrschte ein harter Wettbewerb um Managerpositionen im Analyseteam, und ich denke, das lag ausschließlich daran, dass Manager von dieser Rotation ausgenommen waren – kein Statuspreis konnte mit der Zuckerrübe mithalten, die darin bestand, keine Bereitschaftsarbeit zu leisten.[1]

Wäre es nicht cool, direkt mit Ihren Daten zu sprechen, anstatt mehrere Interaktionsrunden mit Ihren Datenmitarbeitern durchlaufen zu müssen? Diese Vision wird durch Konversationsschnittstellen verkörpert, die es Menschen ermöglichen, mithilfe von Sprache, unserem intuitivsten und universellsten Kommunikationskanal, mit Daten zu interagieren. Nach dem Parsen einer Frage kodiert ein Algorithmus sie in eine strukturierte logische Form in der Abfragesprache Ihrer Wahl, z. B. SQL. Somit können technisch nicht versierte Benutzer mit ihren Daten chatten und schnell an spezifische, relevante und aktuelle Informationen gelangen, ohne den Umweg über ein BI-Team machen zu müssen. In diesem Artikel betrachten wir die verschiedenen Implementierungsaspekte von Text2SQL und konzentrieren uns auf moderne Ansätze unter Verwendung von Large Language Models (LLMs), die derzeit die beste Leistung erzielen (vgl. [2]; für eine Übersicht über alternative Ansätze über LLMs hinaus wird auf die Leser verwiesen [3]). Der Artikel ist nach dem folgenden „mentalen Modell“ der Hauptelemente aufgebaut, die bei der Planung und Erstellung einer KI-Funktion zu berücksichtigen sind:

Konversations-KI zur Datenanalyse — Abbildung 2: Mentales Modell einer KI-Funktion

Beginnen wir mit dem Ende im Hinterkopf und rekapitulieren den Wert – warum Sie eine Text2SQL-Funktion in Ihr Daten- oder Analyseprodukt integrieren würden. Die drei Hauptvorteile sind:

Geschäftsanwender können direkt und zeitnah auf Organisationsdaten zugreifen.
Das entlastet Datenwissenschaftler und Analysten von der Belastung durch Ad-hoc-Anfragen von Geschäftsanwendern und ermöglicht es ihnen, sich auf anspruchsvolle Datenherausforderungen zu konzentrieren.
Dies ermöglicht dem Geschäft seine Daten flüssiger und strategischer zu nutzen und sie schließlich in eine solide Grundlage für die Entscheidungsfindung umzuwandeln.

Welche Produktszenarien könnten Sie nun für Text2SQL in Betracht ziehen? Die drei Haupteinstellungen sind:

Sie bieten ein skalierbares Daten-/BI-Produkt und möchten mehr Benutzern den Zugriff auf ihre Daten auf nicht-technische Weise ermöglichen und so sowohl die Nutzung als auch die Benutzerbasis vergrößern. Als Beispiel hat ServiceNow integrierte Datenabfragen in ein größeres Konversationsangebot und Atlan hat kürzlich kündigte die Exploration natürlichsprachlicher Daten an.
Sie möchten im Daten-/KI-Bereich etwas aufbauen, um den Datenzugriff in Unternehmen zu demokratisieren. In diesem Fall könnten Sie möglicherweise darüber nachdenken MVP mit Text2SQL im Kern. Anbieter mögen AI2SQL und Text2sql.ai haben in diesem Bereich bereits Einzug gehalten.
Sie arbeiten an einem Benutzerdefiniertes BI-System und den Einsatz im einzelnen Unternehmen maximieren und demokratisieren wollen.

Wie wir in den folgenden Abschnitten sehen werden, erfordert Text2SQL eine nicht triviale Vorabeinrichtung. Um den ROI abzuschätzen, berücksichtigen Sie die Art der Entscheidungen, die unterstützt werden sollen, sowie die verfügbaren Daten. Text2SQL kann ein absoluter Gewinn in dynamischen Umgebungen sein, in denen sich Daten schnell ändern und aktiv und häufig bei der Entscheidungsfindung verwendet werden, beispielsweise in der Investitions-, Marketing-, Fertigungs- und Energiebranche. In diesen Umgebungen sind herkömmliche Tools für das Wissensmanagement zu statisch, und flüssigere Möglichkeiten für den Zugriff auf Daten und Informationen helfen Unternehmen dabei, einen Wettbewerbsvorteil zu erzielen. In Bezug auf die Daten bietet Text2SQL den größten Wert mit einer Datenbank, die:

Groß und wachsend, sodass Text2SQL seinen Wert im Laufe der Zeit entfalten kann, da immer mehr Daten genutzt werden.
Hochwertig, damit der Text2SQL-Algorithmus nicht mit übermäßigem Rauschen (Inkonsistenzen, leere Werte usw.) in den Daten umgehen muss. Im Allgemeinen weisen Daten, die von Anwendungen automatisch generiert werden, eine höhere Qualität und Konsistenz auf als Daten, die von Menschen erstellt und gepflegt werden.
Semantisch ausgereift im Gegensatz zu Rohdaten, sodass Menschen die Daten auf der Grundlage zentraler Konzepte, Beziehungen und Metriken abfragen können, die in ihrem mentalen Modell vorhanden sind. Beachten Sie, dass die semantische Reife durch einen zusätzlichen Transformationsschritt erreicht werden kann, der Rohdaten in eine konzeptionelle Struktur umwandelt (siehe Abschnitt „Anreicherung des Prompts mit Datenbankinformationen“).

Im Folgenden werden wir uns eingehend mit den Daten, dem Algorithmus, der Benutzererfahrung sowie den relevanten nichtfunktionalen Anforderungen einer Text2SQL-Funktion befassen. Der Artikel richtet sich an Produktmanager, UX-Designer und Datenwissenschaftler und Ingenieure, die am Anfang ihrer Text2SQL-Reise stehen. Für diese Leute bietet es nicht nur einen Leitfaden für den Einstieg, sondern auch eine gemeinsame Wissensbasis für Diskussionen rund um die Schnittstellen zwischen Produkt, Technologie und Geschäft, einschließlich der damit verbundenen Kompromisse. Wenn Sie in Ihrer Implementierung bereits weiter fortgeschritten sind, bieten die Referenzen am Ende eine Reihe tiefer Einblicke, die Sie erkunden können.

Wenn dieser ausführliche Bildungsinhalt für Sie nützlich ist, können Sie dies tun Abonnieren Sie unsere AI Research Mailingliste benachrichtigt werden, wenn wir neues Material veröffentlichen.

1. Daten

Jedes maschinelle Lernvorhaben beginnt mit Daten. Deshalb klären wir zunächst die Struktur der Eingabe- und Zieldaten, die beim Training und bei der Vorhersage verwendet werden. Im gesamten Artikel verwenden wir den Text2SQL-Fluss aus Abbildung 1 als laufende Darstellung und heben die aktuell betrachteten Komponenten und Beziehungen gelb hervor.

1.1 Format und Struktur der Daten

Typischerweise besteht ein rohes Text2SQL-Eingabe-Ausgabe-Paar aus einer Frage in natürlicher Sprache und der entsprechenden SQL-Abfrage, zum Beispiel:

Fragen (FAQ)"Listen Sie den Namen und die Anzahl der Follower für jeden Benutzer auf.“

SQL-Abfrage:

Wählen Sie Name und Follower aus user_profiles aus

Im Trainingsdatenbereich ist die Zuordnung zwischen Fragen und SQL-Abfragen viele-zu-viele:

Eine SQL-Abfrage kann vielen verschiedenen Fragen in natürlicher Sprache zugeordnet werden; Beispielsweise kann die obige Abfragesemantik ausgedrückt werden durch: „Zeigt mir die Namen und Anzahl der Follower pro Benutzer", "Wie viele Follower gibt es für jeden Benutzer?" usw.
Die SQL-Syntax ist äußerst vielseitig und nahezu jede Frage kann auf verschiedene Arten in SQL dargestellt werden. Das einfachste Beispiel sind unterschiedliche Reihenfolgen von WHERE-Klauseln. Aus einer fortgeschritteneren Sichtweise weiß jeder, der sich mit der Optimierung von SQL-Abfragen beschäftigt hat, dass viele Wege zum gleichen Ergebnis führen und dass semantisch äquivalente Abfragen möglicherweise eine völlig unterschiedliche Syntax haben.

Besonders mühsam ist die manuelle Erfassung von Trainingsdaten für Text2SQL. Es erfordert nicht nur SQL-Kenntnisse seitens des Annotators, sondern auch mehr Zeit pro Beispiel als allgemeinere linguistische Aufgaben wie Stimmungsanalyse und Textklassifizierung. Um eine ausreichende Menge an Trainingsbeispielen zu gewährleisten, kann Datenerweiterung eingesetzt werden – beispielsweise können LLMs verwendet werden, um Paraphrasen für dieselbe Frage zu generieren. [3] bietet einen umfassenderen Überblick über Text2SQL-Datenerweiterungstechniken.

1.2 Anreicherung der Eingabeaufforderung mit Datenbankinformationen

Text2SQL ist ein Algorithmus an der Schnittstelle zwischen unstrukturierten und strukturierten Daten. Für eine optimale Leistung müssen beide Datentypen während des Trainings und der Vorhersage vorhanden sein. Konkret muss der Algorithmus die abgefragte Datenbank kennen und in der Lage sein, die Abfrage so zu formulieren, dass sie gegen die Datenbank ausgeführt werden kann. Dieses Wissen kann umfassen:

Spalten und Tabellen der Datenbank
Beziehungen zwischen Tabellen (Fremdschlüssel)
Datenbankinhalt

Es gibt zwei Möglichkeiten, Datenbankwissen einzubinden: Einerseits können die Trainingsdaten auf Beispiele beschränkt werden, die für die spezifische Datenbank geschrieben wurden. Dabei wird das Schema direkt aus der SQL-Abfrage und deren Zuordnung zur Frage gelernt. Diese Einzeldatenbank-Einstellung ermöglicht die Optimierung des Algorithmus für eine einzelne Datenbank und/oder ein Unternehmen. Es macht jedoch alle Ambitionen nach Skalierbarkeit zunichte, da das Modell für jeden einzelnen Kunden oder jede einzelne Datenbank fein abgestimmt werden muss. Alternativ kann in einer Umgebung mit mehreren Datenbanken das Datenbankschema als Teil der Eingabe bereitgestellt werden, sodass der Algorithmus auf neue, unbekannte Datenbankschemata „generalisieren“ kann. Wenn Sie Text2SQL auf vielen verschiedenen Datenbanken verwenden möchten, müssen Sie sich zwar unbedingt für diesen Ansatz entscheiden, bedenken Sie jedoch, dass dies einen erheblichen zeitnahen technischen Aufwand erfordert. Für jede vernünftige Unternehmensdatenbank ist die Einbeziehung der vollständigen Informationen in die Eingabeaufforderung äußerst ineffizient und aufgrund der Längenbeschränkungen der Eingabeaufforderung höchstwahrscheinlich unmöglich. Daher sollte die für die schnelle Formulierung verantwortliche Funktion intelligent genug sein, um eine Teilmenge der Datenbankinformationen auszuwählen, die für eine bestimmte Frage am „nützlichsten“ ist, und dies für potenziell unsichtbare Datenbanken zu tun.

Schließlich spielt die Datenbankstruktur eine entscheidende Rolle. In den Szenarien, in denen Sie ausreichend Kontrolle über die Datenbank haben, können Sie Ihrem Modell das Leben erleichtern, indem Sie es von einer intuitiven Struktur lernen lassen. Als Faustregel gilt: Je besser Ihre Datenbank widerspiegelt, wie Geschäftsanwender über das Unternehmen sprechen, desto besser und schneller kann Ihr Modell daraus lernen. Erwägen Sie daher die Anwendung zusätzlicher Transformationen auf die Daten, z. B. die Zusammenstellung normalisierter oder anderweitig verteilter Daten in breiten Tabellen oder einem Datentresor, die explizite und eindeutige Benennung von Tabellen und Spalten usw. Alle Geschäftskenntnisse, die Sie im Voraus kodieren können, werden reduziert Reduzieren Sie die Belastung Ihres Modells durch probabilistisches Lernen und helfen Sie dabei, bessere Ergebnisse zu erzielen.

2. Algorithmus

Text2SQL ist eine Art von semantische Analyse — die Abbildung von Texten auf logische Darstellungen. Daher muss der Algorithmus nicht nur die natürliche Sprache „lernen“, sondern auch die Zieldarstellung – in unserem Fall SQL. Konkret sind folgende Kenntnisse zu erwerben:

SQL-Syntax und -Semantik
Datenbankstruktur
Natürliches Sprachverständnis (NLU)
Zuordnung zwischen natürlicher Sprache und SQL-Abfragen (syntaktisch, lexikalisch und semantisch)

2.1 Lösung sprachlicher Variabilität in der Eingabe

Bei der Eingabe liegt die größte Herausforderung von Text2SQL in der Flexibilität der Sprache: Wie im Abschnitt Format und Struktur der Daten beschrieben, kann dieselbe Frage auf viele verschiedene Arten umschrieben werden. Darüber hinaus müssen wir uns im realen Gesprächskontext mit einer Reihe von Problemen wie Rechtschreib- und Grammatikfehlern, unvollständigen und mehrdeutigen Eingaben, mehrsprachigen Eingaben usw. auseinandersetzen.

LLMs wie die GPT-Modelle, T5 und CodeX kommen der Lösung dieser Herausforderung immer näher. Indem sie aus riesigen Mengen unterschiedlicher Texte lernen, lernen sie, mit einer Vielzahl sprachlicher Muster und Unregelmäßigkeiten umzugehen. Am Ende sind sie in der Lage, Fragen zu verallgemeinern, die trotz unterschiedlicher Oberflächenformen semantisch ähnlich sind. LLMs können out-of-the-box (Zero-Shot) oder nach Feinabstimmung angewendet werden. Ersteres ist zwar praktisch, führt jedoch zu einer geringeren Genauigkeit. Letzteres erfordert mehr Geschick und Arbeit, kann aber die Genauigkeit deutlich erhöhen.

Was die Genauigkeit angeht, sind die Modelle mit der besten Leistung erwartungsgemäß die neuesten Modelle der GPT-Familie, einschließlich der CodeX-Modelle. Im April 2023 führte GPT-4 zu einer dramatischen Genauigkeitssteigerung von mehr als 5 % gegenüber dem bisherigen Stand der Technik und erreichte eine Genauigkeit von 85.3 % (bei der Metrik „Ausführung mit Werten“).[4] Im Open-Source-Lager konzentrierten sich die ersten Versuche zur Lösung des Text2SQL-Rätsels auf Auto-Encoding-Modelle wie BERT, die sich hervorragend für NLU-Aufgaben eignen.[5, 6, 7] Doch inmitten des Hypes um generative KI konzentrieren sich neuere Ansätze auf autoregressiven Modellen wie dem T5-Modell. T5 ist durch Multi-Task-Lernen vortrainiert und passt sich somit problemlos an neue sprachliche Aufgaben an, inkl. verschiedene Varianten des semantischen Parsens. Bei semantischen Parsing-Aufgaben weisen autoregressive Modelle jedoch einen grundsätzlichen Fehler auf: Sie verfügen über einen uneingeschränkten Ausgaberaum und keine semantischen Leitplanken, die ihre Ausgabe einschränken würden, was bedeutet, dass sie in ihrem Verhalten erstaunlich kreativ werden können. Während dies für die Generierung von Freiforminhalten erstaunlich ist, ist es für Aufgaben wie Text2SQL, bei denen wir eine eingeschränkte, gut strukturierte Zielausgabe erwarten, ein Ärgernis.

2.2 Abfragevalidierung und -verbesserung

Um die LLM-Ausgabe einzuschränken, können wir zusätzliche Mechanismen zur Validierung und Verbesserung der Abfrage einführen. Dies kann als zusätzlicher Validierungsschritt implementiert werden, wie im PICARD-System vorgeschlagen.[8] PICARD verwendet einen SQL-Parser, der überprüfen kann, ob eine teilweise SQL-Abfrage nach Abschluss zu einer gültigen SQL-Abfrage führen kann. Bei jedem Generierungsschritt durch das LLM werden Token, die die Abfrage ungültig machen würden, zurückgewiesen, und die gültigen Token mit der höchsten Wahrscheinlichkeit werden beibehalten. Da dieser Ansatz deterministisch ist, gewährleistet er eine 100-prozentige SQL-Gültigkeit, solange der Parser die korrekten SQL-Regeln beachtet. Außerdem wird die Abfragevalidierung von der Generierung entkoppelt, sodass beide Komponenten unabhängig voneinander gewartet und das LLM aktualisiert und geändert werden können.

Ein anderer Ansatz besteht darin, Struktur- und SQL-Kenntnisse direkt in das LLM einzubinden. Beispielsweise verwendet Graphix [9] graphfähige Schichten, um strukturiertes SQL-Wissen in das T5-Modell einzubringen. Aufgrund der probabilistischen Natur dieses Ansatzes tendiert das System zu korrekten Abfragen, bietet jedoch keine Erfolgsgarantie.

Schließlich kann das LLM als mehrstufiger Agent verwendet werden, der die Abfrage autonom prüfen und verbessern kann.[10] Mithilfe mehrerer Schritte in einer Gedankenkette kann der Agent beauftragt werden, über die Richtigkeit seiner eigenen Abfragen nachzudenken und etwaige Mängel zu beheben. Wenn die validierte Abfrage immer noch nicht ausgeführt werden kann, kann der SQL-Ausnahme-Traceback als zusätzliches Feedback zur Verbesserung an den Agenten übergeben werden.

Über diese automatisierten Methoden im Backend hinaus ist es auch möglich, den Benutzer in den Abfrageprüfungsprozess einzubeziehen. Wir werden dies im Abschnitt „Benutzererfahrung“ ausführlicher beschreiben.

2.3 Bewertung

Um unseren Text2SQL-Algorithmus zu bewerten, müssen wir einen Testdatensatz (Validierung) generieren, unseren Algorithmus darauf ausführen und relevante Bewertungsmetriken auf das Ergebnis anwenden. Eine naive Aufteilung des Datensatzes in Trainings-, Entwicklungs- und Validierungsdaten würde auf Frage-Abfrage-Paaren basieren und zu suboptimalen Ergebnissen führen. Während des Trainings werden dem Modell möglicherweise Validierungsabfragen angezeigt, die zu einer zu optimistischen Einschätzung seiner Generalisierungsfähigkeiten führen. A Abfragebasierte Aufteilung, bei dem der Datensatz so aufgeteilt wird, dass weder während des Trainings noch während der Validierung eine Abfrage erscheint, liefert wahrheitsgemäßere Ergebnisse.

Was die Bewertungsmetriken betrifft, geht es uns bei Text2SQL nicht darum, Abfragen zu generieren, die vollständig mit dem Goldstandard identisch sind. Das „Genaue Zeichenfolgenübereinstimmung“ Die Methode ist zu streng und generiert viele falsch-negative Ergebnisse, da verschiedene SQL-Abfragen zum gleichen zurückgegebenen Datensatz führen können. Stattdessen wollen wir Höchstleistungen erbringen semantische Genauigkeit und bewerten Sie, ob die vorhergesagten und die „Goldstandard“-Abfragen immer dieselben Datensätze zurückgeben würden. Es gibt drei Bewertungsmaßstäbe, die diesem Ziel nahe kommen:

Exakt eingestellte Übereinstimmungsgenauigkeit: Die generierten und Ziel-SQL-Abfragen werden in ihre Bestandteile aufgeteilt und die resultierenden Mengen werden auf Identität verglichen.[11] Der Nachteil besteht darin, dass nur Reihenfolgevariationen in der SQL-Abfrage berücksichtigt werden, nicht jedoch ausgeprägtere syntaktische Unterschiede zwischen semantisch äquivalenten Abfragen.
Ausführungsgenauigkeit: Die aus den generierten und Ziel-SQL-Abfragen resultierenden Datensätze werden auf Identität verglichen. Mit etwas Glück können Abfragen mit unterschiedlicher Semantik diesen Test auf einer bestimmten Datenbankinstanz trotzdem bestehen. Geht man beispielsweise von einer Datenbank aus, in der alle Benutzer über 30 Jahre alt sind, würden die folgenden beiden Abfragen trotz unterschiedlicher Semantik identische Ergebnisse liefern:
Wählen Sie * vom Benutzer aus
Wählen Sie * von einem Benutzer aus, dessen Alter > 30 ist
Genauigkeit der Testsuite: Die Genauigkeit der Testsuite ist eine fortgeschrittenere und weniger freizügige Version der Ausführungsgenauigkeit. Für jede Abfrage wird ein Satz („Testsuite“) von Datenbanken generiert, die hinsichtlich der Variablen, Bedingungen und Werte in der Abfrage stark differenziert sind. Anschließend wird die Ausführungsgenauigkeit für jede dieser Datenbanken getestet. Diese Metrik erfordert zwar zusätzlichen Aufwand für die Entwicklung der Testsuite-Generierung, reduziert aber auch das Risiko falsch positiver Ergebnisse bei der Bewertung erheblich.[12]

3. Benutzererfahrung

Der aktuelle Stand der Technik von Text2SQL erlaubt keine völlig nahtlose Integration in Produktionssysteme – stattdessen ist es notwendig, die Erwartungen und das Verhalten des Benutzers aktiv zu steuern, der sich immer darüber im Klaren sein sollte, mit was er interagiert ein KI-System.

3.1 Fehlermanagement

Text2SQL kann in zwei Modi fehlschlagen, die auf unterschiedliche Weise abgefangen werden müssen:

SQL-Fehler: Die generierte Abfrage ist ungültig – entweder ist die SQL ungültig oder sie kann aufgrund lexikalischer oder semantischer Fehler nicht für die spezifische Datenbank ausgeführt werden. In diesem Fall kann kein Ergebnis an den Benutzer zurückgegeben werden.
Semantische Fehler: Die generierte Abfrage ist gültig, spiegelt jedoch nicht die Semantik der Frage wider, was zu einem falschen zurückgegebenen Datensatz führt.

Der zweite Modus ist besonders heikel, da das Risiko von „stillen Fehlern“ – Fehlern, die vom Benutzer unentdeckt bleiben – hoch ist. Der prototypische Benutzer verfügt weder über die Zeit noch über die technischen Fähigkeiten, um die Richtigkeit der Abfrage und/oder der resultierenden Daten zu überprüfen. Wenn Daten für die Entscheidungsfindung in der realen Welt verwendet werden, kann ein solches Versagen verheerende Folgen haben. Um dies zu vermeiden, ist es wichtig, die Benutzer zu schulen und zu etablieren Leitplanken auf betriebswirtschaftlicher Ebene die die potenziellen Auswirkungen begrenzen, wie z. B. zusätzliche Datenprüfungen für Entscheidungen mit größeren Auswirkungen. Andererseits können wir die Benutzeroberfläche auch dazu nutzen, die Mensch-Maschine-Interaktion zu verwalten und dem Benutzer dabei zu helfen, problematische Anfragen zu erkennen und zu verbessern.

3.2 Mensch-Maschine-Interaktion

Nutzer können sich unterschiedlich intensiv auf Ihr KI-System einlassen. Mehr Interaktion pro Anfrage kann zu besseren Ergebnissen führen, verlangsamt aber auch die Fluidität der Benutzererfahrung. Bedenken Sie neben den möglichen negativen Auswirkungen fehlerhafter Abfragen und Ergebnisse auch, wie motiviert Ihre Benutzer sein werden, hin und her Feedback zu geben, um genauere Ergebnisse zu erhalten und auch zur langfristigen Verbesserung des Produkts beizutragen.

Der einfachste und am wenigsten ansprechende Weg besteht darin, mit Vertrauenswerten zu arbeiten. Während die naive Berechnung des Vertrauens als Durchschnitt der Wahrscheinlichkeiten der generierten Token zu einfach ist, können fortgeschrittenere Methoden wie verbales Feedback verwendet werden. [13] Das Vertrauen kann in der Benutzeroberfläche angezeigt und mit einer expliziten Warnung hervorgehoben werden, falls es gefährlich niedrig ist. Dadurch liegt die Verantwortung für eine angemessene Nachverfolgung in der „realen Welt“ – sei es eine Ablehnung, Annahme oder eine zusätzliche Prüfung der Daten – auf den Schultern Ihres Nutzers. Während dies für Sie als Anbieter eine sichere Sache ist, kann die Übertragung dieser Arbeit auf den Benutzer auch den Wert Ihres Produkts mindern.

Eine zweite Möglichkeit besteht darin, den Benutzer bei unsicheren, mehrdeutigen oder anderweitig verdächtigen Anfragen in einen Aufklärungsdialog zu verwickeln. Beispielsweise schlägt Ihr System möglicherweise orthografische oder grammatikalische Korrekturen für die Eingabe vor und fordert Sie auf, bestimmte Wörter oder grammatikalische Strukturen eindeutig zu machen. Es könnte dem Benutzer auch ermöglichen, proaktiv Korrekturen in der Abfrage anzufordern:[14]

BENUTZER: Zeigen Sie mir Johns Aufgaben in diesem Sprint.

ASSISTENT: Möchten Sie die Aufgaben sehen, die John erstellt hat oder an denen er arbeitet?

BENUTZER: Aufgaben, die John erstellt hat

ASSISTENT: Ok, hier sind die Aufgaben-IDs:

BENUTZER: Danke, ich würde auch gerne mehr Informationen zu den Aufgaben sehen. Bitte auch nach Dringlichkeit sortieren.

ASSISTENT: Klar, hier sind die Aufgaben samt Kurzbeschreibungen, Beauftragten und Fristen, sortiert nach Frist.

Um das Verständnis von Abfragen durch den Benutzer zu erleichtern, kann Ihr System schließlich auch eine explizite Textumformulierung der Abfrage bereitstellen und den Benutzer auffordern, diese entweder zu bestätigen oder zu korrigieren.[15]

4. Nichtfunktionale Anforderungen

In diesem Abschnitt besprechen wir die spezifischen nichtfunktionalen Anforderungen für Text2SQL sowie die Kompromisse zwischen ihnen. Wir konzentrieren uns auf die sechs Anforderungen, die für die Aufgabe am wichtigsten erscheinen: Genauigkeit, Skalierbarkeit, Geschwindigkeit, Erklärbarkeit, Datenschutz und Anpassungsfähigkeit im Laufe der Zeit.

4.1-Genauigkeit

Für Text2SQL sind die Anforderungen an die Genauigkeit hoch. Erstens wird Text2SQL typischerweise in einer Konversationsumgebung angewendet, in der Vorhersagen einzeln getroffen werden. Daher hilft das „Gesetz der großen Zahlen“, das normalerweise dabei hilft, den Fehler bei Stapelvorhersagen auszugleichen, nicht weiter. Zweitens ist die syntaktische und lexikalische Gültigkeit eine „harte“ Bedingung: Das Modell muss eine wohlgeformte SQL-Abfrage generieren, möglicherweise mit komplexer Syntax und Semantik, andernfalls kann die Anforderung nicht für die Datenbank ausgeführt werden. Und wenn dies gut geht und die Abfrage ausgeführt werden kann, kann sie immer noch semantische Fehler enthalten und zu einem falschen zurückgegebenen Datensatz führen (vgl. Abschnitt 3.1 Fehlermanagement).

4.2 Skalierbarkeit

Die wichtigsten Überlegungen zur Skalierbarkeit bestehen darin, ob Sie Text2SQL auf einer oder mehreren Datenbanken anwenden möchten – und im letzteren Fall, ob der Satz von Datenbanken bekannt und geschlossen ist. Wenn ja, fällt es Ihnen leichter, da Sie die Informationen zu diesen Datenbanken in das Training einbeziehen können. In einem Szenario eines skalierbaren Produkts – sei es eine eigenständige Text2SQL-Anwendung oder eine Integration in ein vorhandenes Datenprodukt – muss Ihr Algorithmus jedoch im Handumdrehen mit jedem neuen Datenbankschema zurechtkommen. Dieses Szenario bietet Ihnen auch nicht die Möglichkeit, die Datenbankstruktur zu transformieren, um sie für das Lernen intuitiver zu gestalten (Link!). All dies führt zu einem starken Kompromiss mit der Genauigkeit, was auch erklären könnte, warum aktuelle Text2SQL-Anbieter, die Ad-hoc-Abfragen neuer Datenbanken anbieten, noch keine nennenswerte Marktdurchdringung erreicht haben.

4.3 Geschwindigkeit

Da Text2SQL-Anfragen typischerweise online in einer Konversation verarbeitet werden, ist der Geschwindigkeitsaspekt wichtig für die Benutzerzufriedenheit. Positiv zu vermerken ist, dass Nutzer sich oft darüber im Klaren sind, dass Datenanfragen eine gewisse Zeit in Anspruch nehmen können und die nötige Geduld erfordern. Dieser gute Wille kann jedoch durch die Chat-Einstellung untergraben werden, in der Benutzer unbewusst eine menschenähnliche Gesprächsgeschwindigkeit erwarten. Brute-Force-Optimierungsmethoden wie die Reduzierung der Modellgröße können einen inakzeptablen Einfluss auf die Genauigkeit haben. Ziehen Sie daher eine Inferenzoptimierung in Betracht, um diese Erwartung zu erfüllen.

4.4 Erklärbarkeit und Transparenz

Im Idealfall kann der Benutzer verfolgen, wie die Abfrage aus dem Text generiert wurde, die Zuordnung zwischen bestimmten Wörtern oder Ausdrücken in der Frage und der SQL-Abfrage sehen usw. Dies ermöglicht es, die Abfrage zu überprüfen und bei der Interaktion mit dem System etwaige Anpassungen vorzunehmen . Darüber hinaus könnte das System auch eine explizite textliche Umformulierung der Anfrage bereitstellen und den Benutzer auffordern, diese entweder zu bestätigen oder zu korrigieren.

4.5-Datenschutz

Die Text2SQL-Funktion kann von der Abfrageausführung isoliert werden, sodass die zurückgegebenen Datenbankinformationen unsichtbar bleiben können. Die entscheidende Frage ist jedoch, wie viele Informationen über die Datenbank in der Eingabeaufforderung enthalten sind. Die drei Optionen (durch Verringerung des Datenschutzniveaus) sind:

Keine Information
Datenbankschema
Datenbankinhalt

Datenschutz geht mit Genauigkeit einher – je weniger Einschränkungen Sie bei der Eingabe nützlicher Informationen in die Eingabeaufforderung haben, desto besser sind die Ergebnisse.

4.6 Anpassungsfähigkeit im Laufe der Zeit

Um Text2SQL dauerhaft nutzen zu können, müssen Sie sich an die Datendrift anpassen, also an die sich ändernde Verteilung der Daten, auf die das Modell angewendet wird. Nehmen wir beispielsweise an, dass die für die anfängliche Feinabstimmung verwendeten Daten das einfache Abfrageverhalten der Benutzer widerspiegeln, wenn sie mit der Nutzung des BI-Systems beginnen. Mit der Zeit werden die Informationsbedürfnisse der Benutzer anspruchsvoller und erfordern komplexere Abfragen, die Ihr naives Modell überfordern. Darüber hinaus können sich die Ziele oder die Strategie einer Unternehmensveränderung auch verschieben und den Informationsbedarf auf andere Bereiche der Datenbank lenken. Eine Text2SQL-spezifische Herausforderung ist schließlich die Datenbankdrift. Wenn die Unternehmensdatenbank erweitert wird, gelangen neue, unsichtbare Spalten und Tabellen in die Eingabeaufforderung. Während Text2SQL-Algorithmen, die für Anwendungen mit mehreren Datenbanken konzipiert sind, dieses Problem gut bewältigen können, kann es die Genauigkeit eines Einzeldatenbankmodells erheblich beeinträchtigen. All diese Probleme lassen sich am besten mit einem Feinabstimmungsdatensatz lösen, der das aktuelle, reale Verhalten der Benutzer widerspiegelt. Daher ist es von entscheidender Bedeutung, Benutzerfragen und -ergebnisse sowie alle damit verbundenen Rückmeldungen, die bei der Nutzung gesammelt werden können, zu protokollieren. Darüber hinaus können semantische Clustering-Algorithmen, beispielsweise mithilfe von Einbettungen oder Themenmodellierung, angewendet werden, um zugrunde liegende langfristige Änderungen im Benutzerverhalten zu erkennen und diese als zusätzliche Informationsquelle für die Perfektionierung Ihres Feinabstimmungsdatensatzes zu nutzen

Zusammenfassung

Fassen wir die wichtigsten Punkte des Artikels zusammen:

Text2SQL ermöglicht die Implementierung eines intuitiven und demokratischen Datenzugriffs in einem Unternehmen und maximiert so den Wert der verfügbaren Daten.
Text2SQL-Daten bestehen aus Fragen am Eingang und SQL-Abfragen am Ausgang. Die Zuordnung zwischen Fragen und SQL-Abfragen ist viele-zu-viele.
Es ist wichtig, im Rahmen der Eingabeaufforderung Informationen über die Datenbank anzugeben. Darüber hinaus kann die Datenbankstruktur optimiert werden, um dem Algorithmus das Erlernen und Verstehen zu erleichtern.
Bei der Eingabe besteht die größte Herausforderung in der sprachlichen Variabilität von Fragen in natürlicher Sprache, die mithilfe von LLMs angegangen werden können, die für eine Vielzahl unterschiedlicher Textstile vorab trainiert wurden
Die Ausgabe von Text2SQL sollte eine gültige SQL-Abfrage sein. Diese Einschränkung kann durch das „Injizieren“ von SQL-Kenntnissen in den Algorithmus integriert werden; alternativ kann durch einen iterativen Ansatz die Abfrage in mehreren Schritten überprüft und verbessert werden.
Aufgrund der potenziell großen Auswirkungen „stiller Fehler“, die falsche Daten für die Entscheidungsfindung zurückgeben, ist das Fehlermanagement ein Hauptanliegen der Benutzeroberfläche.
Auf „erweiterte“ Weise können Benutzer aktiv an der iterativen Validierung und Verbesserung von SQL-Abfragen beteiligt werden. Dies macht die Anwendung zwar weniger flüssig, verringert aber auch die Fehlerquote, ermöglicht den Benutzern eine flexiblere Datenerkundung und schafft wertvolle Signale für weiteres Lernen.
Die wichtigsten nichtfunktionalen Anforderungen, die es zu berücksichtigen gilt, sind Genauigkeit, Skalierbarkeit, Geschwindigkeit, Erklärbarkeit, Datenschutz und Anpassungsfähigkeit im Laufe der Zeit. Die Hauptkompromisse bestehen zwischen Genauigkeit einerseits und Skalierbarkeit, Geschwindigkeit und Datenschutz andererseits.