Automatyzacja konwersji tekstu na SQL wciąż jest dużym zadaniem, a dostępnych jest bardzo mało dobrych modeli open source do tego zadania. Rozłóżmy to na czynniki - >Modele konwersji tekstu na SQL to w zasadzie nic innego jak modele encoder-decoder z warstwą wielokrotnej uwagi i warstwą łączenia schematów pomiędzy nimi. > Encoder przetwarza zarówno zapytanie użytkownika, jak i schemat bazy danych, generując kontekstowe osadzenia (kodowanie uwzględniające relacje). >Dzięki łączeniu schematów, tokeny w zapytaniu są dopasowywane do odpowiadających im encji schematu. > Mechanizm uwagi uwzględniający schemat pozwala modelowi skupić się na odpowiednich częściach schematu podczas dekodowania. > Dekoder sekwencyjnie produkuje tokeny SQL (dekodowanie oparte na ograniczeniach). Gdzie te modele mają braki? - >Większość dostępnych modeli brakuje złożonych zapytań w danych treningowych, przez co słabo radzą sobie z zapytaniami międzydomenowymi lub pętlami. > Wymagania dotyczące języka i zapytania nie zawsze są poprawne ze strony zwykłego użytkownika. Nawet błędy ortograficzne prowadzą do błędnych wpisów i powodują problemy podczas pobierania, dlatego podpowiadanie jest ważnym elementem w tym zadaniu. Osobiście pracowałem nad tym szczegółowo, gdy tworzyłem projekt end-to-end, nawet stworzyłem syntetyczne dane i próbowałem trenować własny SLM, ale poniosłem sromotną porażkę, a następnie przeszedłem do używania modelu open-source. Jeśli chcesz zagłębić się w ten temat, polecam najpierw przeczytać te prace badawcze - >LLM Enhanced Text-to-SQL Generation >Next-Generation Database Interfaces: >Text-to-SQL Parsing: Concepts and Methods >RASAT: Integrating Relational Structures into Pretrained Seq2Seq Model