Wie Parlance natürliche Sprache in präzise SQL-Abfragen übersetzt —
Schritt für Schritt, nachvollziehbar und datensouverän.
Bestehende Lösungen umgehen das Problem — sie lösen es nicht.
Klassische RAG-Systeme linearisieren Tabellen in Fließtext. JOINs, Aggregationen und Fremdschlüssel gehen dabei verloren. Das System sieht nie die komplette Datenbasis.
LLMs sind probabilistische Textgeneratoren. Finanzkennzahlen, Summen und Ratios erfordern exakte symbolische Berechnung — keine approximative Textgenerierung.
Cloud-basierte Text-to-SQL-Dienste senden Datenbankmetadaten an externe Server. Für regulierte Branchen ist das kein Graubereich — es ist verboten.
Aktuelle Forschung (ReViSQL, UIUC 2026) zeigt: In 61% aller realen SQL-Trainingspaare steckt mindestens ein semantischer Fehler — fehlende DISTINCT, NULL-unsafe Aggregationen oder tie-unsichere Rankings. Komplexe Architekturen kompensieren diese Fehler nicht; saubere Daten und Prompts schon.
Jede Anfrage durchläuft vier präzise definierte Stufen.
Klicken Sie auf eine Stufe für Details — oder animieren Sie die Pipeline.
Der Demo-Prototype zeigt eine fiktive Maschinenbau-Gruppe: 4 Tochtergesellschaften, 6 Märkte, 25 Produkte, 3 Jahre Transaktionsdaten. Klicken Sie auf eine Tabelle für Details.
Der Semantic Layer ist die Brücke zwischen Geschäftssprache und Datenbankschema. Er definiert, was "Umsatz" bedeutet, welche Tabellen gejoint werden — und kennt alle Synonyme.
SELECT
so.fiscal_year,
SUM(soi.net_amount_eur) -- Umsatz
AS revenue_eur,
ROUND(
SUM(soi.gross_profit_eur)
/ NULLIF(SUM(soi.net_amount_eur), 0)
* 100, 2
) -- Bruttomarge %
AS gross_margin_pct
FROM parlance.sales_orders so
JOIN parlance.sales_order_items soi
ON so.id = soi.order_id
JOIN parlance.companies c
ON so.company_id = c.id
WHERE c.code = 'GMDE'
AND so.fiscal_quarter = 4
AND so.fiscal_year IN (2023, 2024)
GROUP BY so.fiscal_year
ORDER BY so.fiscal_year;Erfolgreiche SQL-Abfragen werden als Vektor gespeichert. Ähnliche Anfragen finden den gespeicherten SQL-Code — ohne ihn neu generieren zu müssen.
Das Embedding-Modell kodiert die Anfrage als numerischen Vektor. Semantisch ähnliche Anfragen landen im Vektorraum nah beieinander.
Im Vektorraum werden die k ähnlichsten gespeicherten Q&A-Paare gesucht. Diese werden als Few-Shot-Beispiele dem LLM mitgegeben — für bessere SQL-Qualität.
Liefert der generierte SQL ein valides Ergebnis, wird das Paar (Anfrage → SQL) in der Vektordatenbank gespeichert. Es steht ab sofort künftigen Anfragen zur Verfügung.
Mit jeder Nutzung wächst die Wissensbasis. Die Plattform wird schneller, präziser und auf das spezifische Schema des Kunden zugeschnitten — proprietäres IP-Asset.
Parlance kontrolliert den gesamten Prozess von der Anfrage bis zum Ergebnis — Read-Only-Enforcement ist kein Feature, sondern Architekturprinzip.
Ausschließlich SELECT-Statements werden zugelassen. DML und DDL sind systemseitig blockiert — nicht konfigurierbar.
Schlägt ein generiertes SQL syntaktisch fehl, versucht das System bis zu 3× mit angepasster Formulierung. Erst bei validem Ergebnis wird in die Vektordatenbank gespeichert.
Jede Anfrage wird mit Zeitstempel, User-ID, generiertem SQL, Retry-Count und Ergebnis-Zeilenanzahl in audit_log protokolliert und ist durchsuchbar.
Weder Metadaten noch Nutzdaten verlassen die Kundeninfrastruktur. Der LLM-Server läuft lokal via Ollama oder LM-Studio — kein Cloud-API-Call mit Kundendaten.
Jedes generierte SQL wird automatisch auf die drei häufigsten Fehlerpatterns geprüft: fehlende DISTINCT-Klauseln bei JOINs, fehlende NULL-Behandlung vor Aggregationen und unsichere Ranking-Queries (LIMIT 1 ohne CTE). Reale Trainingsdaten enthalten diese Fehler in bis zu 61% der Fälle (ReViSQL, UIUC 2026).
Stage 3 generiert parallel 3 SQL-Kandidaten mit unterschiedlichen Sampling-Parametern. Alle validen Kandidaten werden ausgeführt, nach Ergebnis gruppiert und per Majority Voting entschieden. Das reduziert die Wahrscheinlichkeit zufälliger Fehler um 4–14% gegenüber Single-Shot-Generierung (ReViSQL, arXiv:2603.20004).
Parlances Kernthesen werden durch aktuelle Forschung an führenden Universitäten bestätigt.
These 1 validiert: 61,1% aller BIRD-Train-Instanzen enthalten mindestens einen SQL-Fehler. Datenqualität ist der kritischste Engpass — nicht Architekturkomplexität. Parlances DB-Design-Check und Prompt Library adressieren genau das.
These 2 validiert: Multi-Candidate-Generierung mit Reconciliation verbessert die Accuracy um 4,4–13,6% gegenüber Single-Shot-Generierung — besonders bei komplexen oder mehrdeutigen Fragen. Parlance setzt dieses Verfahren in Stage 3 um.
These 3 validiert: Verifizierte SQL-Trainingspaare sind 21,9% aggregationsreicher und enthalten 66,8% mehr Subqueries als rohe Daten. Jedes verifizierte Paar in der Parlance Prompt Library ist wertvoller als ein roher LLM-Output — und schwer kopierbar.
Die Demo-Applikation zeigt alle 4 Stufen live — mit echten SQL-Queries, dem Semantic Layer und dem selbstlernenden Feedback-Loop. Alle Daten bleiben lokal.
Demo starten →