Was wir über die Eingabe von Prompts für LLMs bei der Text-zu-SQL-Umwandlung gelernt haben

Bei Actian entwickeln wir KI-Agenten, die natürliche Sprache automatisch in SQL umwandeln. Das klingt zwar fast wie Zauberei, erfordert aber viel sorgfältige Entwicklungsarbeit, um es richtig hinzubekommen. Eine der wichtigsten Erkenntnisse, die wir gewonnen haben: Wie man das Modell anweist, macht einen riesigen Unterschied.

Vor kurzem haben wir uns mit einer ganzen Reihe verschiedener Prompt-Strategien beschäftigt: Zero-Shot, Few-Shot, Single-Domain, Cross-Domain. Prompt-Formate, Datenbeispiele, Beziehungen zwischen Tabellen – wir haben alles ausprobiert. Und ich kann euch sagen: Wir haben uns eine klare Meinung darüber gebildet, was funktioniert und was nicht.

In diesem Blog werden einige dieser Erkenntnisse vorgestellt. Egal, ob Sie Ihr eigenes Text-to-SQL-Tool entwickeln oder einfach nur neugierig sind, wie wir das bei Actian handhaben – lesen Sie weiter.

Grundlagen der Prompt-Erstellung (Kurzer Auffrischungskurs)

Wenn wir hier von „Prompting“ sprechen, meinen wir Folgendes: Was zeigen wir dem Sprachmodell, bevor wir es auffordern, SQL zu generieren?

Eine einfache Text-zu-SQL-Eingabeaufforderung enthält in der Regel:

• Eine kurze Anweisung („Erstellen Sie eine SQL-Abfrage unter Verwendung der folgenden Tabellen“).
• Eine Beschreibung der Datenbank (Tabellennamen, Spalten, Beziehungen).
• Manchmal: Beispiele für Fragen + die dazugehörigen SQL-Abfragen.
• Und dann: die Frage, auf die wir eine Antwort suchen.

Es gibt zwei gängige Konfigurationen:

Bei Actian nutzen wir beides, je nachdem, was der Nutzer und welche Daten verfügbar sind.

Ein Schema allein reicht nicht aus

Bei Zero-Shot-Prompts reicht es nicht aus, lediglich die Tabelle und die Spalten aufzulisten. Wir haben festgestellt, dass sich die Genauigkeit durch das Hinzufügen von Tabellenbeziehungen (z. B. Fremdschlüsseln) deutlich verbessert.

Noch besser: Fügen Sie Beispielwerte hinzu. Das hilft dem Modell zu verstehen, wie Spaltenwerte in der Praxis aussehen – was entscheidend ist, wenn es versucht, WHERE-Klauseln mit der richtigen Formatierung zu erstellen (z. B. „USA“ vs. „The United States of America“).

Wir haben verschiedene Möglichkeiten getestet, Tabelleninhalte darzustellen. Der Gewinner? Ein Format, das einzelne Spaltenwerte anzeigt (in der Veröffentlichung als „SelectCol“ bezeichnet). Dies führte zu besseren Ergebnissen als die Darstellung roher Zeilen („InsertRow“) oder die einfache Ausführung von „SELECT * LIMIT 3“.

In der Zero-Shot-Konfiguration von Actian beziehen wir nun also immer Folgendes mit ein:

• Das vollständige Schema (CREATE TABLE)
• Fremdschlüsselbeziehungen
• Einige wenige Werte pro Spalte

(Und ja, wir vereinheitlichen alles – Kleinbuchstaben, einheitliche Abstände, keine seltsamen Formatierungen.)

Few-Shot: Je mehr, desto besser (meistens)

Wenn Sie Beispiele einbringen können, tun Sie es. Wir haben selbst bei nur 1–2 Beispielen durchweg positive Ergebnisse festgestellt. Und wenn Sie sogar 4–8 gute Beispiele aus demselben Bereich anführen können? Das reicht oft schon aus, um die meisten Vorteile zu erzielen.

Aber hier kommt die Überraschung:

• Der Inhalt der Tabelle ist auch bei Beispielen nach wie vor wichtig.
• Wie man diese Inhalte darstellt, spielt eine immer geringere Rolle – das Modell wird weniger wählerisch, sobald es einige Beispiele gesehen hat.
• Die Beziehungen zwischen Tabellen (wie Verknüpfungen) lassen sich anhand der Beispiele selbst nachvollziehen.

Im Ein-Domänen-Modus kommt man mit einem einfacheren Schemaformat durch, solange man echte, nützliche Beispiele vorzeigt – wir empfehlen jedoch weiterhin, Tabelleninhalte einzufügen, sofern dies möglich ist.

Beispieldaten verbessern die Genauigkeit

Wenn Sie zusätzlich Beispielwerte aus der Tabelle angeben – etwa einige Beispielzeilen –, werden die Ergebnisse besser. Dies hilft dem Modell zu verstehen, welche Art von Werten gespeichert ist, was für das Erstellen von Filtern (z. B. WHERE-Klauseln) wichtig ist.

Wir haben verschiedene Möglichkeiten getestet, dies zu veranschaulichen:

• Raw-Insert-Anweisungen
• SELECT * LIMIT 3
• Eindeutige Werte pro Spalte

Die letzte Variante (unterschiedliche Werte pro Spalte) hat am besten funktioniert. Sie bietet mehr Vielfalt und vermeidet Redundanzen.

Aber Aufforderungen sind nicht alles

Die Sache ist die: Egal, wie gut man einem LLM die richtigen Eingabeanweisungen gibt – es ist unrealistisch zu erwarten, dass es immer von Grund auf perfekte SQL-Code schreibt.

Wir bei Actian haben gelernt, dass es mehr als nur Aufforderungen braucht. Man braucht ein Framework den Agenten:

• Die Möglichkeit, zuvor erstellte SQL-Abfragen zu speichern – und sie wiederzuverwenden, wenn ein Nutzer später eine ähnliche Frage Nutzer .
• Eine Möglichkeit, wichtige Begriffe zu definieren (z. B. was „Churn“ oder „aktive Nutzereigentlich bedeuten) und diese Definition in die Eingabeaufforderung einzufügen, wenn es relevant ist.

Eine solche Infrastruktur macht einen großen Unterschied in Bezug auf Zuverlässigkeit und Leistung. Prompting ist ein Ausgangspunkt – doch erst durch eine robuste Kontextverarbeitung und Wiederverwendung wird das Ganze skalierbar intelligent.

Und ja – hinter den Kulissen tun wir bei Actian noch ein paar andere Dinge. Wir wollen aber noch nicht alles verraten … einige davon sind noch zum Patent angemeldet.

Wir setzen alles daran, die Text-zu-SQL-Funktion zu verbessern – damit sie präziser, zuverlässiger und für Datenteams noch nützlicher wird. Die Eingabeaufforderung ist nur ein Teil dieses Puzzles, aber ein wichtiger.

Wenn Sie Ihre eigenen, auf LLM basierenden Datentools entwickeln, hoffen wir, dass Ihnen dies ein paar Anregungen gibt. Und wenn Sie sehen möchten, wie das in der Praxis aussieht, wissen Sie ja, wo Sie uns finden 🙂

Über den Autor

Über Amra Dorjbayar

Amra Dorjbayar ist Mitbegründer von Wobby (2026 von Actian übernommen) und federführend hinter dem Actian AI Analyst. Als ehemaliger preisgekrönter Investigativ- und Datenjournalist hat Amra viele Jahre damit verbracht, Geschichten in komplexen Datensätzen aufzudecken. Er nutzte dieses Fachwissen, um „agente“ KI-Systeme zu entwickeln, die den Datenzugriff durch natürliche Sprache demokratisieren.