Text to SQL Agent Cost: Was ein "Ask Your Data"-Feature wirklich kostet

Der Text to SQL Agent Cost für ein produktionsreifes SaaS-Feature liegt irgendwo zwischen wenigen Wochen fokussierter Entwicklung und einem Quartal Arbeitszeit für ein kleines Team. Die Spannbreite bei diesem Text to SQL Agent Cost ergibt sich fast ausschließlich aus drei Faktoren: wie unübersichtlich Ihr Schema ist, wie strikt die Mandantentrennung sein muss und wie viele Fragen der Agent korrekt beantworten muss, bevor Kunden ihn zu Gesicht bekommen. Das Modell ist der billige Teil. Das Geld fließt in die semantische Schicht und die Sicherheitsvorkehrungen.

Was Gründer tatsächlich kaufen

Das Feature auf der Roadmap ist ein Textfeld im Dashboard mit der Aufschrift "ask your data". Ein Kunde tippt "welche Accounts sind letztes Quartal nach einer fehlgeschlagenen Zahlung abgewandert" ein, der Agent schreibt SQL, führt sie aus und liefert eine Tabelle oder ein Diagramm zurück. Jede Vendor-Demo dieses Features funktioniert wunderbar, weil jede Vendor-Demo auf fünf Tabellen mit Namen wie customers und orders läuft.

Ihre Datenbank hat status, status_v2 und eine deleted_at-Spalte, die die Hälfte der Queries vergisst. Sie hat ein tenant_id auf den meisten Tabellen und ein organisation_id auf den älteren. Sie hat drei Wege, Umsatz zu berechnen, und Finance vertraut nur einem davon. Ein LLM, das dieses Schema kalt einliest, wird plausible SQL produzieren, die auf eine Weise falsch ist, die ein Kunde am Output nicht erkennen kann. Diese Lücke zwischen der Demo und Ihrem Schema ist das Projekt.

Text to SQL Agent Cost: Wo das Geld tatsächlich hinfließt

Die semantische Schicht ist der größte Posten

Eine semantische Schicht ist eine schriftliche Beschreibung dessen, was Ihre Daten bedeuten: welche Tabellen der Agent anfassen darf, wie sie verknüpft werden, wie "aktiver Kunde" und "monatlicher Umsatz" definiert sind, und welche Spalten Legacy-Rauschen sind. Aktuelle Tools in diesem Bereich existieren genau deshalb, um zu verhindern, dass Agenten SQL aus rohen Spaltennamen heraus raten, und die Idee ist sinnvoll. Das Modell hört auf, Joins zu erfinden, und fängt an, eine Vorlage zu füllen, die Sie kontrollieren.

Der teure Teil ist, dass das Schreiben dieser Schicht Business-Arbeit ist, nicht nur Engineering. Jemand, der das Produkt kennt, muss sich hinsetzen und schriftlich festlegen, was die Metriken bedeuten. Wenn sich Ihr Team noch nie auf eine Churn-Definition geeinigt hat, finden Sie das in dieser Woche heraus. Kalkulieren Sie das ehrlich ein. Bei einem ausgereiften Produkt mit hundert Tabellen kann die semantische Schicht allein ein Drittel der Gesamtkosten ausmachen, und sie ist auch der Teil, der sich dauerhaft auszahlt, weil am Ende auch Ihre menschlichen Analysten sie nutzen.

Mandantentrennung und Berechtigungen

Ein Text to SQL Agent ist ein Programm, das beliebige, von einem Sprachmodell geschriebene Queries gegen die Daten Ihrer Kunden ausführt. Behandeln Sie ihn entsprechend. Die Datenbankverbindung, die der Agent nutzt, sollte eine dedizierte, schreibgeschützte Rolle sein, niemals der Anwendungsnutzer und niemals etwas mit Schreibrechten. In PostgreSQL erzwingen Sie die Mandantengrenze mit Row-Level-Security-Policies, die an den Mandanten gebunden sind, sodass eine falsche WHERE-Klausel des Modells nichts zurückgibt, statt die Zeilen eines anderen Kunden zurückzugeben. Setzen Sie ein statement_timeout auf dieser Rolle, damit ein schlechter Join nicht zehn Minuten auf Ihrer Primärdatenbank hängen bleibt.

Das ist das gleiche Designproblem wie bei permission-aware RAG: Die Zugriffskontrolle muss unterhalb des Modells liegen, in einer Schicht, aus der sich das Modell nicht heraustalken kann. Wenn die Antwort eines Vendors auf "wie verhindern Sie Cross-Tenant-Leaks" lautet "der Prompt sagt ihm, nach Mandant zu filtern", gehen Sie weiter.

Das Eval-Set

Bevor das Feature ausgeliefert wird, brauchen Sie einen Fundus realer Fragen mit bekannten korrekten Antworten, zusammengestellt aus Support-Tickets und Sales-Calls, ausgeführt gegen eine Kopie der Produktionsdaten. Fünfzig Fragen sind ein dünner Anfang. Zweihundert sind komfortabel. Jede kostet jemanden Zeit, die korrekte SQL zu schreiben und das Ergebnis zu verifizieren, und genau dieses Ergebnis sagt Ihnen, ob die Sache funktioniert. Wir haben bereits darüber geschrieben, warum Evals in den Vendor-Vertrag gehören, und bei diesem Feature ist das der klarste Fall dafür: ohne den Frage-Fundus bedeutet "es funktioniert" nichts anderes als "es hat bei den drei Queries funktioniert, die wir in der Demo ausprobiert haben".

Der Modellaufruf selbst

Die Inferenzkosten sind im Vergleich zum Vorherigen fast eine Rundungsdifferenz, und die Architektur rund um den Aufruf sollte einfach bleiben. Das Muster, das sich meist durchsetzt, ist ein einziger Aufruf mit der semantischen Schicht, den relevanten Tabellendefinitionen und einer Handvoll durchgerechneter Beispiele im Kontext, der SQL plus eine einzeilige Erklärung zurückgibt. Mehrstufige Chains (ein Planer, der Tabellen auswählt, ein Writer, der SQL entwirft, ein Fixer, der Fehler behebt) wirken fundierter und fügen in der Praxis Latenz, Kosten und neue Fehlerquellen hinzu.

Wir haben dasselbe in einem ganz anderen System beobachtet. Unsere eigene Outreach-Engine scraped die Website eines Prospects mit einem selbst gehosteten Crawler und einem lokalen Modell und schreibt dann eine maßgeschneiderte E-Mail pro Unternehmen. Wir sind mit einer Chain gestartet, die in einem Schritt Fakten extrahierte und im nächsten den Entwurf schrieb. Ein einziger Aufruf, der beides erledigte, mit gutem Kontext, schlug die Chain bei Kosten und bei Output-Qualität. Text to SQL verhält sich genauso: Legen Sie das Wissen in den Kontext, nicht in die Orchestrierung. Ein Retry bei einem SQL-Fehler ist in Ordnung. Eine fünfstufige Pipeline ist meist ein Zeichen dafür, dass die semantische Schicht fehlt.

Bauen vs. Kaufen

Es gibt drei realistische Optionen.

• Das KI-Feature in Ihrem bestehenden BI-Tool. Am günstigsten und schnellsten. Gut für interne Dashboards oder ein Single-Tenant-Produkt. Schwach, wenn jeder Kunde nur seine eigenen Zeilen sehen darf und die Metrikdefinitionen das sind, was das Tool erahnt.
• Ein Embedded-Analytics-Vendor mit Natural Language oben drauf. Ein vernünftiger Mittelweg, wenn Ihr Schema sauber ist und Ihr Tenancy-Modell zu dem des Vendors passt. Prüfen Sie, wo die Daten verarbeitet werden. Wenn Ihre Kunden im Golf oder im Gesundheitswesen sitzen, kann Datenresidenz das von vornherein ausschließen.
• Selbst auf dem eigenen Stack bauen. Im Vorfeld am teuersten, und die richtige Entscheidung, wenn Mandantentrennung nicht verhandelbar ist, wenn Ihre Metriken hauseigene Definitionen haben oder wenn das Feature Teil dessen ist, was Sie verkaufen, statt ein Nice-to-have zu sein.

Der ehrliche Test ist, ob die "ask your data"-Box ein Produktdifferenzierungsmerkmal oder eine Annehmlichkeit ist. Wenn Kunden mehr dafür zahlen würden oder ohne sie abwandern würden, bauen Sie. Wenn es eine Checkbox für das Sales-Deck ist, kaufen Sie und machen Sie weiter.

Wie eine vernünftige erste Version aussieht

Grenzen Sie den Umfang des ersten Releases eng ein. Eine Version, die ein enges Set an Fragen korrekt beantwortet, ist besser als eine, die alles versucht und meistens richtig liegt.

1. Wählen Sie eine Domäne (Billing, Usage oder Support) und zehn bis fünfzehn Tabellen.
2. Schreiben Sie die semantische Schicht nur für diese Domäne, mit Metrikdefinitionen, die von demjenigen abgesegnet wurden, der für die Zahlen verantwortlich ist.
3. Erstellen Sie die schreibgeschützte Rolle, die Row-Level-Security-Policies und die Timeouts, bevor der erste Prompt geschrieben wird.
4. Bauen Sie das Eval-Set aus realen Kundenfragen und führen Sie es bei jeder Änderung aus.
5. Zeigen Sie die generierte SQL und die Zeilenanzahl neben jeder Antwort, damit Power-User Fehler erkennen können.
6. Rollen Sie es für eine Handvoll wohlgesinnter Accounts aus und lesen Sie zwei Wochen lang jede Query, die sie ausführen.

Erweitern Sie auf die nächste Domäne erst, wenn die Eval-Erfolgsquote bei der ersten langweilig stabil ist.

Fragen an denjenigen, der Ihnen ein Angebot macht

Ein Angebot für dieses Feature, das als einzelne Zahl ohne Rückfragen zurückkommt, ist ein Angebot für die Demo, nicht für das Produkt. Fragen Sie:

• Wie verbindet sich der Agent mit der Datenbank, und mit welchen Rechten?
• Wo lebt der Mandantenfilter, und was passiert, wenn das Modell ihn weglässt?
• Wer schreibt die Metrikdefinitionen, und wie lange soll das geschätzt dauern?
• Wie sieht das Eval-Set bei der Übergabe aus, und welche Erfolgsquote ist das Abnahmekriterium?
• Welches Modell wird verwendet, und wie sehen die Kosten pro Query bei tausend Fragen am Tag aus?
• Was passiert, wenn sich das Schema im nächsten Quartal ändert?

Die Antworten zeigen Ihnen, ob das Team das Feature bereits gegen ein echtes Schema oder nur gegen ein Tutorial ausgeliefert hat. Wenn Sie eine zweite Meinung zu einem Angebot wollen oder eine konkrete Schätzung für Ihre eigene Datenbank, melden Sie sich bei uns.