ESQ-Bench: γιατί ένα SQL query που εκτελείται μπορεί να δίνει λάθος απάντηση

Ένα σύστημα τεχνητής νοημοσύνης μετατρέπει μια φυσική ερώτηση σε SQL, το query εκτελείται χωρίς error και επιστρέφει ένα εύλογο αποτέλεσμα. Είναι έτοιμο για παραγωγή; Το ESQ-Bench δείχνει γιατί η απάντηση μπορεί να είναι «όχι». Σε σύνθετες enterprise βάσεις, ένα query μπορεί να λειτουργεί τεχνικά και ταυτόχρονα να απαντά σε διαφορετικό επιχειρηματικό ερώτημα από εκείνο που τέθηκε.

Η μελέτη ESQ-Bench: A Multi-Tier Enterprise Oracle Benchmark for Evaluating NL2SQL Dialect Generalization and Silent Semantic Divergence σχεδιάστηκε για να εξετάσει αυτή την απόσταση. Δημιουργεί ένα Oracle-first περιβάλλον με αυξανόμενη πολυπλοκότητα schema, πολλαπλές SQL διαλέκτους και τέσσερις διαφορετικές μετρικές, ώστε η αξιολόγηση να μην τελειώνει στο «εκτελέστηκε».

Για ιδιοκτήτες e-commerce, marketers, BI ομάδες και στελέχη, το ζήτημα δεν είναι ακαδημαϊκό. Αν ένα AI εργαλείο απαντά σε ερωτήσεις για έσοδα, πελάτες, αποθέματα ή καμπάνιες, το κόστος ενός πειστικού αλλά λανθασμένου query μπορεί να είναι μεγαλύτερο από το κόστος ενός εμφανώς αποτυχημένου query. Το error σταματά τη ροή. Το εύλογο λάθος μπορεί να περάσει σε dashboard, report ή απόφαση.

Το κενό ανάμεσα στο benchmark score και στην παραγωγική αξιοπιστία

Οι συγγραφείς ξεκινούν από μια ένταση: σύγχρονα NL2SQL συστήματα αναφέρουν υψηλή execution accuracy σε καθιερωμένα benchmarks, όμως αυτή η επίδοση δεν αποτυπώνει αναγκαστικά την πολυπλοκότητα ενός enterprise database estate. Στην πράξη εμφανίζονται legacy ονόματα, πολλαπλές οντότητες με παρόμοια σημασία, ελλιπείς σχέσεις, NULL semantics, διαφορετικές SQL διάλεκτοι και οργανωτικές ιεραρχίες.

Ένα μικρό ακαδημαϊκό schema περιορίζει τον αριθμό των πιθανών joins και ερμηνειών. Ένα enterprise schema αυξάνει τα μονοπάτια που φαίνονται λογικά αλλά δεν αντιστοιχούν στην επιχειρηματική έννοια της ερώτησης. Γι’ αυτό το ESQ-Bench δεν εξετάζει μόνο αν δημιουργήθηκε έγκυρο SQL. Εξετάζει πώς αλλάζει η επίδοση όταν αυξάνονται οι πίνακες, οι ασάφειες, οι Oracle-specific κατασκευές και οι πιθανές διαδρομές σύνδεσης.

Η επιχειρηματική συνέπεια είναι σαφής: ένα υψηλό score σε γενικό benchmark δεν αποτελεί από μόνο του τεκμήριο ότι το ίδιο σύστημα μπορεί να συνδεθεί με production data. Η αξιολόγηση πρέπει να αναπαράγει τη διάλεκτο, το schema, τις ονομασίες, τα edge cases και τους ορισμούς του συγκεκριμένου οργανισμού. Η ίδια αρχή ισχύει όταν ένα dashboard χρησιμοποιείται για αποφάσεις: η καθαρή παρουσίαση δεν διορθώνει έναν λανθασμένο ορισμό ή ένα εσφαλμένο join.

Τι ακριβώς περιλαμβάνει το ESQ-Bench

Το benchmark διαθέτει έξι πλήρως populated, synthetic enterprise-representative schemas, συνολικά 465 πίνακες και 164.682 rows, χωρίς κενό πίνακα. Τα ίδια seed data αναπαράγονται σε Oracle, PostgreSQL, MySQL και SQL Server. Αυτή η παράλληλη κατασκευή επιτρέπει να μελετηθούν τόσο η κατανόηση του schema όσο και η γενίκευση ανά SQL dialect.

Η τράπεζα περιλαμβάνει 550 gold-validated ζεύγη ερώτησης και query. Από αυτά, 95 ανήκουν στο Tier 1, 228 στο Tier 2 και 227 στο Tier 3. Οι ερωτήσεις καλύπτουν απλά selects, aggregations, joins, set operations, nested queries, temporal λογική, analytic functions, hierarchical queries και ειδικές enterprise παγίδες.

Τα tiers δεν είναι απλώς τρία σύνολα διαφορετικού μεγέθους. Αντιστοιχούν σε αυξανόμενη πολυπλοκότητα schema, με μέσο αριθμό πινάκων 10, 48 και 177. Στο ανώτερο επίπεδο, η επιλογή του σωστού πίνακα και της σωστής επιχειρηματικής σχέσης γίνεται μέρος του ίδιου του προβλήματος, όχι απλή προϋπόθεση.

Τέσσερις μετρικές αντί για έναν βολικό αριθμό

The Exact Match (EM) ελέγχει αν το generated SQL ταιριάζει ακριβώς με το gold SQL μετά από normalization. Είναι αυστηρό και μπορεί να απορρίψει διαφορετικές αλλά ισοδύναμες διατυπώσεις. Το Execution Match (EX) ελέγχει αν το query εκτελείται και δίνει αποτέλεσμα συμβατό με το gold result στο συγκεκριμένο seeded dataset.

The Semantic Recall (SR) επιδιώκει να μετρήσει αν διατηρούνται τα ουσιαστικά στοιχεία της ζητούμενης λογικής. Το Silent Divergence (SD) αφορά την επικίνδυνη περίπτωση όπου ένα query φαίνεται επιτυχημένο στο διαθέσιμο test instance, αλλά αποκλίνει σε σημασιολογία ή συμπεριφορά όταν εμφανιστούν διαφορετικά δεδομένα και οριακές περιπτώσεις.

Η διάκριση είναι κρίσιμη επειδή ένα περιορισμένο seed dataset μπορεί να κάνει δύο διαφορετικά queries να επιστρέψουν προσωρινά το ίδιο αποτέλεσμα. Με άλλα δεδομένα, η απόκλιση μπορεί να εμφανιστεί. Άρα η αξιολόγηση χρειάζεται inspection του query path, test cases που διαχωρίζουν εναλλακτικές ερμηνείες και domain review.

Η επίδοση μειώνεται όσο μεγαλώνει η πολυπλοκότητα

Στο schema-linked πείραμα με GPT-4o, το EX μεταξύ των queries που εκτελέστηκαν ήταν 79,8% στο Tier 1, 60,3% στο Tier 2 και 57,2% στο Tier 3. Η μονοτονική πτώση στηρίζει την κεντρική υπόθεση του benchmark: η αυξανόμενη enterprise πολυπλοκότητα αποκαλύπτει αδυναμίες που δεν φαίνονται στα απλούστερα σχήματα.

Το Exact Match έμεινε χαμηλά: 6,3% στο Tier 1, 4,4% στο Tier 2 και 0,4% στο Tier 3. Αυτό δεν αποδεικνύει ότι κάθε διαφορετικό query ήταν λανθασμένο, επειδή το ίδιο αποτέλεσμα μπορεί να εκφραστεί με διαφορετικό SQL. Δείχνει όμως ότι η συντακτική ταύτιση και η εκτελεστική ταύτιση περιγράφουν διαφορετικά πράγματα.

Συνολικά, εκτελέστηκαν 489 από τα 550 generated queries και 307 από αυτά πέρασαν το EX. Το Tier 3 εμφάνισε ιδιαίτερα άνισες επιδόσεις ανά κατηγορία: τα hierarchical queries έφτασαν 86,7% EX με ρητές υποδείξεις για CONNECT BY, ενώ ambiguity resolution, multi-join και ordering έμειναν πολύ χαμηλότερα. Η αδυναμία δεν είναι μία και ενιαία. Εξαρτάται από τον τύπο της λογικής που ζητά η ερώτηση.

Τι μετρά πραγματικά το operational silent divergence

Στα queries που πέρασαν το EX, το paper αναφέρει operational SD 92,0% στο Tier 1, 91,5% στο Tier 2 και 99,1% στο Tier 3. Αυτές οι τιμές είναι εντυπωσιακές, αλλά χρειάζονται ακριβή ανάγνωση. Στο released harness, το operational SD ενεργοποιείται κυρίως όταν ένα query περνά το EX χωρίς να έχει Exact Match με το gold SQL.

Άρα το 92-99% δεν είναι αποδεδειγμένο ποσοστό λανθασμένων απαντήσεων. Περιλαμβάνει και εναλλακτικά SQL paths που μπορεί να είναι ισοδύναμα. Οι ίδιοι οι συγγραφείς διευκρινίζουν ότι η formal επιβεβαίωση silent divergence απαιτεί distractor queries και συμπληρωματικά database instances, υλικό που παραμένει υπό ανάπτυξη για τα Tier 2 και Tier 3. Στα υπάρχοντα Tier 1 probes, το current seed data δεν επιβεβαίωσε formal divergences.

Η σωστή επιχειρηματική χρήση της μετρικής είναι ως σήμα για audit, όχι ως αυτόματη καταδίκη κάθε διαφορετικού SQL. Αν ένα generated query φτάνει στο ίδιο αποτέλεσμα από άλλη διαδρομή, η ομάδα πρέπει να εξετάσει αν αυτή η διαδρομή διατηρεί τη λογική για NULLs, dormant accounts, πολλαπλές σχέσεις, χρονικά όρια και νέες τιμές δεδομένων.

Γιατί το zero-shot αποτέλεσμα κρύβει survivor bias

Στο GPT-4o, τα zero-shot queries που κατάφεραν να εκτελεστούν εμφάνισαν EX 78,7%, 73,5% και 77,8% στα τρία tiers. Στα Tier 2 και 3 αυτά τα conditional ποσοστά φαίνονται καλύτερα από το schema-linked prompting. Η εικόνα όμως αλλάζει όταν εξεταστεί πόσα queries έφτασαν καν στο στάδιο της εκτέλεσης.

Το zero-shot είχε execution rates 64,2%, 59,6% και 51,5%, έναντι 98,9%, 85,1% και 88,5% για το schema-linked setup. Όταν αποτυγχάνουν νωρίς περισσότερα δύσκολα queries, το υποσύνολο που τελικά εκτελείται είναι ευκολότερο και το EX μεταξύ των survivors μπορεί να φαίνεται τεχνητά υψηλό.

Με denominator όλες τις ερωτήσεις, το schema-linked GPT-4o πέτυχε 78,9%, 51,3% και 50,7%, ενώ το zero-shot 50,5%, 43,9% και 40,1%. Για business reports, αυτό είναι μάθημα μέτρησης: κάθε accuracy πρέπει να συνοδεύεται από το σύνολο των cases, τα exclusions και τον αριθμό των αποτυχιών πριν από τη βαθμολόγηση. Η ίδια πειθαρχία χρειάζεται σε κάθε επιστημικό audit ενός AI output.

Οι failure modes που ενδιαφέρουν μια επιχείρηση

Η ανάλυση του benchmark διαχωρίζει τις αποτυχίες αντί να τις συμπιέζει σε ένα accuracy score. Στο πλήρες GPT-4o run, 170 από τις 243 καταγεγραμμένες αποτυχίες ταξινομήθηκαν ως wrong-result semantics. Υπήρχαν επίσης syntax ή Oracle errors, περιπτώσεις χωρίς generation και projection mismatches.

Αυτό αλλάζει και το remediation. Ένα syntax error μπορεί να αντιμετωπιστεί με καλύτερο dialect prompting ή parser feedback. Ένα λάθος join path απαιτεί schema documentation και domain constraints. Μια αμφίσημη επιχειρηματική έννοια χρειάζεται clarification ή semantic layer, όχι απλώς μεγαλύτερο μοντέλο.

Για marketers και e-commerce ομάδες, οι κρίσιμες έννοιες πρέπει να έχουν επίσημους ορισμούς: τι θεωρείται νέα αγορά, ενεργός πελάτης, καθαρό revenue, επιστροφή, attributed conversion ή διαθέσιμο απόθεμα. Χωρίς αυτή τη βάση, το NL2SQL σύστημα καλείται να μαντέψει οργανωτική γνώση που δεν βρίσκεται απαραίτητα στα ονόματα των columns.

Η επιλογή μοντέλου παραμένει σημαντική αλλά δεν λύνει μόνη της το πρόβλημα. Στο schema-linked setup, το Claude Sonnet 4.6 ξεπέρασε το GPT-4o σε EX μεταξύ των executed queries και στα τρία tiers. Τα αποτελέσματα όμως αφορούν συγκεκριμένες εκδόσεις, prompts, schema representations και runs του Ιουνίου 2026. Δεν μεταφέρονται αυτούσια σε κάθε production περιβάλλον χωρίς τοπική επαλήθευση.

Η αρχιτεκτονική ελέγχου πριν από την παραγωγή

Ένα ασφαλέστερο NL2SQL σύστημα χρειάζεται περισσότερα από model και database credentials. Πρώτο επίπεδο είναι το semantic layer: business glossary, μετρικές με ιδιοκτήτη, επιτρεπόμενα join paths και τεκμηρίωση για αμφίσημα fields. Δεύτερο επίπεδο είναι το execution sandbox με read-only πρόσβαση, row limits, timeouts και αποκλεισμό write operations.

Τρίτο επίπεδο είναι η επαλήθευση. Το σύστημα μπορεί να συγκρίνει alternative queries, να εκτελεί counterexample datasets, να ελέγχει cardinality και να επισημαίνει ασυνήθιστες αποκλίσεις. Για ερωτήματα που επηρεάζουν χρήματα, πελάτες, συμμόρφωση ή δημόσια αναφορά, χρειάζεται ανθρώπινη έγκριση με ορατό SQL, πηγές και αιτιολόγηση.

Τέταρτο επίπεδο είναι η παρακολούθηση μετά την ανάπτυξη. Οι ερωτήσεις, τα generated queries, τα execution outcomes, οι διορθώσεις και οι απορρίψεις πρέπει να δημιουργούν audit trail. Η παρακολούθηση καταστάσεων και αποτυχιών ενός AI agent βοηθά να μη χάνεται η διαδρομή ανάμεσα στο αίτημα και στο αποτέλεσμα, ενώ ο human-in-the-loop σχεδιασμός πρέπει να δίνει πραγματική δυνατότητα απόρριψης και όχι τυπική επιβεβαίωση.

Ένα πρωτόκολλο επτά βημάτων για ασφαλέστερο NL2SQL

Η πρώτη έκδοση ενός production benchmark δεν χρειάζεται να καλύψει κάθε πιθανή ερώτηση. Χρειάζεται όμως να αναπαράγει τις ερωτήσεις που επηρεάζουν πραγματικές αποφάσεις και να κάνει ορατούς τους τρόπους αποτυχίας. Το παρακάτω πρωτόκολλο μεταφέρει το κεντρικό μάθημα του ESQ-Bench σε λειτουργικό έλεγχο.

Το NIST AI RMF ενισχύει αυτή τη λογική: πρώτα χαρτογραφείται το context και ο κίνδυνος, μετά επιλέγονται κατάλληλες μετρήσεις, τα αποτελέσματα διαχειρίζονται και οι ρόλοι παραμένουν σαφείς σε όλο τον κύκλο ζωής. Σε μια πραγματική υλοποίηση, οι Business Automation & AI πρέπει να ενσωματώνουν αυτά τα checkpoints στη ροή, όχι να τα προσθέτουν ως χειροκίνητο έλεγχο αφού ληφθεί η απόφαση.

Οι περιορισμοί της μελέτης

Το ESQ-Bench είναι μεγάλο για το συγκεκριμένο Oracle-first κενό, αλλά παραμένει benchmark 550 ερωτήσεων πάνω σε έξι synthetic enterprise-representative schemas. Δεν αναπαράγει όλη την ποικιλία πραγματικών data estates, permissions, data quality προβλημάτων και οργανωτικών ορισμών.

Η operational μέτρηση silent divergence εξαρτάται από το Exact Match και το αποτέλεσμα πάνω στο seeded dataset. Ένα εναλλακτικό query μπορεί να είναι σωστό χωρίς να έχει την ίδια μορφή ή διαδρομή. Η formal SD χρειάζεται distractors και συμπληρωματικά instances, ενώ οι συγγραφείς αναφέρουν ότι αυτά παραμένουν ανοιχτό έργο για τα Tier 2 και Tier 3.

Υπάρχει επίσης περιορισμός μοντέλου και χρόνου. Τα αποτελέσματα προέρχονται από pinned model versions και συγκεκριμένο evaluation pipeline. Η μελέτη δεν αποτελεί certification standard ούτε πρόβλεψη για κάθε οργανισμό. Προσφέρει αναπαραγώγιμη βάση για να σχεδιαστεί αυστηρότερος τοπικός έλεγχος.

Το συμπέρασμα για AI analytics και data products

Το ουσιαστικό μήνυμα του ESQ-Bench είναι ότι η παραγωγική αξιοπιστία δεν ισούται με query execution. Όσο μεγαλώνει το schema, αυξάνεται ο χώρος των τεχνικά έγκυρων αλλά επιχειρηματικά λανθασμένων διαδρομών. Η επίδοση πρέπει να αξιολογείται πάνω στη συνολική εργασία: κατανόηση ερώτησης, επιλογή δεδομένων, SQL dialect, εκτέλεση, αποτέλεσμα και σημασιολογική πιστότητα.

Η σωστή ερώτηση για μια επιχείρηση που σχεδιάζει conversational BI ή AI agents με πρόσβαση σε δεδομένα δεν είναι «γράφει SQL;». Είναι «γνωρίζουμε πότε το SQL απαντά πράγματι στη σωστή ερώτηση;». Η απάντηση απαιτεί τοπικό benchmark, business definitions, adversarial test data, πολλαπλές μετρικές, guardrails και ανθρώπινο έλεγχο εκεί όπου το λάθος έχει κόστος.

Όταν αυτά τα στοιχεία γίνουν μέρος της αρχιτεκτονικής, το NL2SQL μπορεί να μειώσει την απόσταση ανάμεσα σε ερώτηση και ανάλυση χωρίς να κρύβει την αβεβαιότητα. Χωρίς αυτά, η φυσική γλώσσα απλώς κάνει ένα δύσκολο database problem να φαίνεται ευκολότερο από όσο είναι.