HarnessSQL: model 8B z 15,5% do 45,2% w testach SQL

• Zespół z Hong Kong University of Science and Technology (HKUST) zbudował HarnessSQL: agenta, który zamienia pytania o dane na zapytania SQL. Trenował go w open-source'owym frameworku DeepSeek Harness.
• Model 8B (na bazie Qwen3-8B) poprawił wynik na Spider 2.0-SQLite z 15,5% do 45,2%. Wersja 14B doszła do 54,8%.
• Modele 32B, z którymi porównują się autorzy, dostały od 14,8% do 16,3%.
• To wyniki z publikacji samych autorów (arXiv, październik). Kod jest dostępny na GitHubie.

Autorzy twierdzą, że o sukcesie decyduje dobrze zaprojektowana uprząż agenta (po angielsku harness), a nie sama wielkość modelu. Liczby z ich testów zgadzają się z tą tezą: model cztery razy mniejszy od konkurentów 32B zdobył na Spider 2.0-SQLite ponad dwukrotnie wyższy wynik. Pamiętaj jednak, że to testy zespołu, który sam zbudował to rozwiązanie.

Agent z czterema narzędziami zamiast jednego strzału

Text-to-SQL to zadanie, w którym pytasz bazę danych zwykłym językiem, a model pisze zapytanie wyciągające odpowiedź. Na prawdziwej firmowej bazie rzadko udaje się to za pierwszym razem. Trzeba zajrzeć, jakie są tabele i kolumny, spróbować, popatrzeć na błąd i poprawić.

Właśnie to robi komponent DSH-SQL, czyli DeepSeek Harness przerobiony na agenta bazodanowego. Ma cztery narzędzia: wylistowanie tabel, odczyt schematu, wykonanie zapytania i oddanie ostatecznej odpowiedzi. To nie magia, tylko system: pętla, w której model sam sprawdza, co jest w bazie, zanim zacznie zgadywać. Harness to po prostu otoczka wokół modelu, czyli jego narzędzia plus reguły pracy.

Jak go trenowano

Zespół zbudował 79 baz w piaskownicy z zestawów Spider 2.0-Lite i Spider 2.0-DBT. Projekty DuckDB przekonwertował na SQLite i uruchamiał je w trybie tylko do odczytu, z limitem 60 sekund na zapytanie. W tym środowisku agent nie może więc niczego skasować, a pojedyncze zapytanie nie zawiesi się w nieskończoność.

Trening miał dwa etapy. Najpierw było nadzorowane dostrajanie (SFT) na pełnych zapisach pracy agenta. Taki zapis ma średnio 11 800 tokenów, 16 tur i 14 wykonanych zapytań. Odpowiedzi bazy (tzw. obserwacje narzędzi) wyłączono z funkcji straty, więc model uczy się na własnych ruchach, a nie na tym, co zwróciła baza. Potem przyszło uczenie ze wzmocnieniem (czyli nagrody za dobry wynik) algorytmem DAPO.

Liczby: 8B przed 32B, 14B jeszcze wyżej

Na Spider 2.0-SQLite model 8B wzrósł z 15,5% do 45,2%. Wersja 14B zdobyła 54,8%. Trzy modele 32B użyte jako punkt odniesienia (OmniSQL-32B, Arctic-Text2SQL-32B i Qwen2.5-Coder-32B) zmieściły się w przedziale 14,8-16,3%.

Drugi test, LiveSQLBench, pokazuje podobny układ:

• 8B: 24,8%
• 14B: 28,5%
• modele 32B użyte jako punkt odniesienia: 7,0-8,9%

Jest też druga strona medalu. Nawet najlepszy wynik, 54,8%, oznacza, że prawie połowa zadań kończy się błędem. To duży skok, ale nie powód, by puścić agenta na produkcyjne raporty bez sprawdzania wyników.

Skąd bierze się przyrost: wyniki ablacji

Autorzy sprawdzili też, co się stanie, gdy wyłączą kolejne elementy. Ta część jest dla mnie ciekawsza niż sam rekord:

• Same uczenie ze wzmocnieniem, bez SFT: 20,0%.
• Sam etap SFT: 30,4% dla 8B i 37,8% dla 14B.
• Dostrajanie na zapisach zebranych bez harnessu: 9,6%.
• Okno kontekstu: 27,4% przy 8K i 45,2% przy 32K (przy średnim zapisie 11 800 tokenów 8K po prostu się nie mieści).
• Algorytm RL: GRPO 40,7%, GSPO 43,7%, DAPO 45,2%.

Nauka z nagrań pracy bez narzędzi, z których ta praca korzystała, dała 9,6%. To jak uczenie się gotowania z filmów, na których nikt nie pokazuje garnków. Wniosek: liczy się cały zestaw, czyli narzędzia, zapis pełnych trajektorii, dość długie okno i dopiero na końcu wzmocnienie.

Co z tego dla Ciebie, jeśli nie piszesz SQL-a

Ta sama myśl wraca w kilku ostatnich tekstach o agentach. W Harness² od Google Research chodzi o poprawianie agenta bez zmiany modelu, a wokół DeepSeek Harness powstają kolejne projekty, jak prototyp Super-agenta czy zlecanie zadań Codex i Claude Code. Jeśli interesują Cię małe modele, zajrzyj też do tekstu o Flincie, darmowym modelu do kodu na laptopa. Wspólny mianownik: coraz częściej to konstrukcja wokół modelu robi różnicę.

Moja interpretacja, nie deklaracja autorów: jeśli mały model da się nauczyć pracy na bazie danych, to polskie firmy z danymi w SQL-u mogą kiedyś liczyć na mniejszy rachunek i łatwiejsze trzymanie danych u siebie. Na razie to jednak wynik naukowy na benchmarku. Licencję i wymagania kodu sprawdzisz w repozytorium projektu na GitHubie.

Nie musisz znać SQL-a, żeby rozumieć, jak wygląda dobra odpowiedź z bazy. Weź jedno pytanie do danych, które zadajesz w pracy, na przykład „ile sprzedaliśmy w tym regionie w zeszłym kwartale”. Rozpisz na kartce, przez jakie kroki przechodzisz: które tabele i kolumny sprawdzasz, ile razy poprawiasz wynik, zanim uznasz go za wiarygodny. Zajmie to 10 minut i zobaczysz, że agent z tej publikacji, który robi średnio 16 tur i 14 zapytań, po prostu naśladuje Twoją żmudną robotę.