ESQ-Bench: nowy benchmark ujawnia słabości modeli NL2SQL

Badanie opublikowane 12 czerwca 2026 roku przez Sanjaya Mishrę, Divyę Chukkapalli i Ganesha R. Naika podważa wiarygodność dotychczasowych benchmarków oceniających modele NL2SQL, czyli systemy tłumaczące zapytania w języku naturalnym na kod SQL. Autorzy wskazują, że najlepsze modele osiągają ponad 89 procent dokładności wykonania na uznanych zestawach testowych takich jak Spider i BIRD — ale te benchmarki opierają się na uproszczonych akademickich schematach baz danych i otwartych dialektach SQL, które nie odzwierciedlają złożoności rzeczywistych środowisk korporacyjnych. Odpowiedzią zespołu jest ESQ-Bench: nowy, zorientowany na Oracle benchmark z systematycznymi poziomami złożoności i mechanizmem wykrywania „cichej dywergencji semantycznej”.

Kluczowe wnioski

• ESQ-Bench zawiera sześć zapełnionych schematów bazodanowych (465 tabel, 164 682 wiersze, zero pustych tabel) z identycznymi danymi startowymi zaimplementowanymi jednocześnie w Oracle, PostgreSQL, MySQL i SQL Server.
• Benchmark obejmuje 550 zweryfikowanych par pytanie-zapytanie podzielonych na trzy poziomy złożoności: Tier-1 (95 par), Tier-2 (228 par) i Tier-3 (227 par).
• GPT-4o z promptowaniem opartym na schemacie odnotował spadek dokładności wykonania z 79,8 do 60,3 i 57,2 procent między poziomami złożoności — dokładność dopasowania w trybie exact match (EM) nie przekroczyła 7 procent na żadnym poziomie.
• Ukryte rozjazdy semantyczne (silent divergence) dotyczyły od 73 do 99 procent zapytań, które formalnie „zaliczyły” test wykonania — oznacza to, że zapytanie się wykonało, ale zwróciło błędny wynik.
• Claude Sonnet 4.6 przewyższył GPT-4o na każdym poziomie złożoności (87,4, 74,9 i 68,7 procent), a lokalny model Llama 3.2 osiągnął jedynie 13,3 procent dokładności w całym zbiorze (73 z 550 zapytań).

Dlaczego istniejące benchmarki nie wystarczają

Podstawowym problemem, który autorzy próbują rozwiązać, jest oderwanie popularnych testów NL2SQL od realiów przedsiębiorstw. Spider i BIRD, obecne standardy oceny modeli tłumaczących język naturalny na SQL, opierają się na akademickich schematach danych — mniejszych, uproszczonych i wykorzystujących dialekty SQL typowe dla otwartego oprogramowania. W rzeczywistych firmach dane żyją w znacznie bardziej złożonych strukturach, często w systemach Oracle, z rozbudowanymi relacjami między setkami tabel i specyficznymi wariantami składni SQL.

ESQ-Bench powstał, by zapełnić tę pustkę. Zespół zbudował i opublikował sześć w pełni zapełnionych schematów bazodanowych obejmujących łącznie 465 tabel i 164 682 wiersze danych, przy czym żadna tabela nie pozostała pusta — co ma znaczenie, bo puste tabele mogłyby sztucznie ułatwiać modelom generowanie „poprawnych” zapytań bez realnego przetwarzania danych. Kluczowe jest też to, że identyczne dane startowe zaimplementowano równolegle w czterech systemach: Oracle, PostgreSQL, MySQL i SQL Server, co pozwala testować, jak modele radzą sobie z różnicami dialektów SQL między platformami.

Do oceny modeli autorzy zastosowali zestaw czterech metryk: EM (exact match), EX (dopasowanie wykonania), SR oraz SD, gdzie SD odnosi się właśnie do wykrywania cichej dywergencji semantycznej — sytuacji, w której zapytanie wykonuje się bez błędu, ale zwraca wynik niezgodny z intencją pytania. Cały zestaw testowy obejmuje 550 par pytanie-zapytanie zweryfikowanych jako „złoty standard”, rozdzielonych na trzy poziomy złożoności: Tier-1 z 95 parami, Tier-2 z 228 parami i Tier-3 z 227 parami.

Wyniki modeli: od GPT-4o do lokalnej Llamy

Najważniejszym odkryciem badania jest monotoniczny spadek dokładności wykonania GPT-4o w miarę wzrostu złożoności schematu. Przy promptowaniu opartym na schemacie (schema-linked prompting) model osiągnął 79,8 procent dokładności EX na poziomie Tier-1, 60,3 procent na Tier-2 i 57,2 procent na Tier-3 (dane z wykonanych zapytań, czerwiec 2026). Dla porównania, na wcześniejszym, mniejszym wycinku pilotażowym liczącym 142 pytania wyniki wynosiły 75,6, 80,4 i 95,8 procent — co pokazuje, jak bardzo ograniczony zestaw testowy mógł zawyżać ocenę realnych możliwości modelu.

Jeszcze bardziej niepokojący jest wynik dotyczący dokładności exact match — utrzymywał się on poniżej 7 procent na wszystkich poziomach złożoności, niezależnie od tego, jak wysoka była dokładność wykonania. Autorzy podkreślają, że operacyjna cicha dywergencja sięgała od 73 do 99 procent wśród zapytań, które przeszły test wykonania. Innymi słowy, zapytanie mogło się uruchomić bez błędu, ale zwrócić dane niezgodne z pytaniem użytkownika — a analiza błędów wykazała, że na wyższych poziomach złożoności dominują właśnie błędy semantyczne dające nieprawidłowe wyniki, nie błędy techniczne wykonania.

W porównaniu modeli Claude Sonnet 4.6 z promptowaniem opartym na schemacie okazał się skuteczniejszy niż GPT-4o na każdym z trzech poziomów, osiągając 87,4, 74,9 i 68,7 procent dokładności EX na wykonanych zapytaniach. Co ciekawe, GPT-4o w wariancie zero-shot (bez promptowania opartego na schemacie) uzyskał wyniki 78,7, 73,5 i 77,8 procent — co odwraca zależność widoczną w wariancie schema-linked na poziomach Tier-2 i Tier-3. Autorzy wyjaśniają ten paradoks niższym wskaźnikiem wykonania zapytań w wariancie zero-shot oraz efektem „survivor bias” przy porównywaniu obu podejść — czyli sytuacją, w której do analizy trafiają tylko te zapytania, którym udało się wykonać, a to zawyża statystyki dokładności.

Najsłabszy wynik odnotował lokalny model Llama 3.2 z promptowaniem opartym na schemacie — jedynie 13,3 procent dokładności w skali całego zbioru testowego, co odpowiada 73 poprawnym odpowiedziom z 550. Ten rezultat, jak zauważają autorzy, podkreśla wciąż istniejącą przepaść między zamkniętymi modelami API a otwartymi modelami wagowymi w zastosowaniach na złożonych schematach korporacyjnych Oracle.

Znaczenie dla oceny modeli AI w praktyce biznesowej

Wyniki ESQ-Bench mają istotne implikacje dla wszystkich firm rozważających wdrożenie asystentów AI generujących zapytania SQL do baz produkcyjnych. Sama wysoka dokładność wykonania zapytania — czyli fakt, że kod SQL uruchamia się bez błędów — nie oznacza, że wynik jest poprawny. Zjawisko cichej dywergencji semantycznej, sięgające nawet 99 procent wśród „zaliczonych” zapytań na niektórych poziomach złożoności, oznacza, że model może systematycznie zwracać błędne dane bez żadnego sygnału ostrzegawczego dla użytkownika końcowego.

To zjawisko przypomina problemy opisywane wcześniej w kontekście metodologii oceny dużych modeli językowych — podobne pytania o wiarygodność wyników benchmarkowych stawia badanie opisane w artykule o zmianie formatu danych pamięci LLM wpływającej na wyniki testów. W obu przypadkach chodzi o to, że metodologia testowania może maskować rzeczywiste ograniczenia modeli.

Dla przedsiębiorstw korzystających z systemów Oracle — a więc typowo dużych organizacji finansowych, przemysłowych czy administracji — wynik ten sugeruje potrzebę wprowadzenia dodatkowych mechanizmów weryfikacji semantycznej zapytań generowanych przez AI, zamiast polegania jedynie na fakcie, że zapytanie się wykonało bez błędu technicznego.

Podsumowanie

ESQ-Bench dostarcza dowodów, że popularne benchmarki NL2SQL, takie jak Spider czy BIRD, mogą znacząco zawyżać rzeczywistą skuteczność modeli w środowiskach korporacyjnych opartych na Oracle. Kluczowym odkryciem jest nie tylko spadek dokładności wraz ze wzrostem złożoności schematu, ale przede wszystkim wysoki odsetek cichych rozjazdów semantycznych — sytuacji, w których zapytanie działa, ale zwraca błędny wynik, potencjalnie niezauważony przez użytkownika.