Riepilogo Tecnico: Schema-First Retrieval per l'Analisi del Linguaggio Naturale

Definizione del Problema

I sistemi enterprise di text-to-SQL falliscono frequentemente non durante la generazione del codice SQL, bensì durante la fase precedente di selezione del contesto. Nei moderni data warehouse, i modelli vengono spesso presentati con nomi di tabelle grezzi che non riescono a catturare il contesto critico: nomi di colonne abbreviati, metriche di business informali, convenzioni di join nascoste e confini di autorizzazione. Quando un modello riceve il contesto dello schema errato (ad esempio, le tabelle, le chiavi di join o le definizioni di business sbagliate), produce uno SQL sintatticamente valido ma analiticamente inutile. I benchmark esistenti come Spider 2.0 evidenziano che i workflow realistici richiedono la ricerca di metadati e il contesto di progetto piuttosto che schemi accademici compatti. Gli approcci attuali trattano la selezione dello schema come un dettaglio di formattazione del prompt o si affidano a pipeline incentrate sulla generazione che assumono che lo schema corretto sia già stato fornito.

Metodologia: Schema-First Retrieval

Il documento propone lo Schema-First Retrieval, uno strato di recupero che tratta il catalogo dei dati — e non le righe grezze del warehouse — come l'obiettivo primario del recupero. Il sistema opera in due fasi:

1. Indicizzazione Offline

Il sistema definisce una tassonomia di oggetti del catalogo a cinque tipi, rendendo ogni tipo di oggetto in un template testuale specifico prima dell'embedding:

• Tabelle: Ancorano il dominio (nomi, schemi, descrizioni, proprietari).
• Colonne: Fondano i predicati e le proiezioni (tipi di dati, valori campionari, contesto genitore).
• Metriche: Collegano il linguaggio di business allo schema fisico (formule, colonne sorgente).
• Relazioni: Proteggono le join codificando le chiavi esterne e i percorsi documentati.
• Cronologia delle Query: Cattura la memoria del carico di lavoro (domande precedenti e oggetti acceduti).

Questi oggetti vengono inseriti in collezioni vettoriali separate utilizzando template specifici per tipo.

2. Pipeline di Recupero Online

• Ricerca Parallela: Una query dell'utente viene incorporata e cercata contro tutte e cinque le collezioni del catalogo simultaneamente utilizzando un bi-encoder (Amazon Titan Embeddings V2).
• Espansione della Lineage: Se sono necessarie le relazioni, il sistema espande le tabelle candidate attraverso un percorso di join a ricerca in ampiezza (breadth-first) per includere tabelle ponte e chiavi di join non esplicitamente nominate nella query.
• Reranking: Un cross-encoder (Cohere Rerank V3.5) ri classifica i candidati raggruppati. Questo è particolarmente critico per le colonne, che sono spesso brevi, duplicate o abbreviate.
• Fusione dei Punteggi: Il punteggio di recupero finale combina la similarità semantica, la rilevanza del cross-encoder e l'evidenza della cronologia delle query (pesata in base alla recenza).
• Governance Deterministica: Il controllo degli accessi è applicato al di fuori del Large Language Model (LLM). Un filtro deterministico rimuove gli oggetti del catalogo non autorizzati in base alle liste di controllo degli accessi (ACL) prima dell'assemblaggio del contesto. Lo SQL generato viene ulteriormente verificato e riscritto per imporre i predicati a livello di riga.

3. Generazione

Il generatore SQL riceve un sottoinsieme dello schema focalizzato e validato dal catalogo (DDL, definizioni delle metriche, percorsi di join) invece dell'intero warehouse. Il generatore è trattato come un componente sostituibile; il sistema si affida al routing guidato dall'intento (classificazione della complessità della query) e all'assemblaggio del contesto con budget di token per ottimizzare l'input.

Contributi Chiave

1. Tassonomia di Oggetti del Catalogo Tipizzati: Il documento definisce template di embedding separati per tabelle, colonne, metriche, relazioni e cronologia delle query, sostenendo che questi oggetti rispondono a domande di recupero distinte e non dovrebbero essere appiattiti in un generico blocco di testo.
2. Pipeline di Recupero Multi-Segnale: Un sistema che integra la ricerca vettoriale parallela, il reranking tramite cross-encoder, l'espansione della lineage e la memoria del carico di lavoro in un contesto unificato per la generazione di SQL.
3. Governance Deterministica: Un approccio a livello di sistema in cui il controllo degli accessi è gestito tramite il filtraggio del catalogo e la riscrittura dello SQL, anziché affidarsi all'LLM per ricordare o seguire le policy.

Risultati Sperimentali

Il sistema è stato valutato su tre benchmark: CRUSH4SQL (1.534 domande), SEDE (857 domande) e BIRD (96 domande).

• Qualità del Recupero (CRUSH4SQL):

  • Il recupero semantico (bi-encoder) ha superato il baseline BM25 di +32,8 punti nel Table Recall@5.
  • Il reranking tramite cross-encoder ha aggiunto +11,1 punti nel Column Recall@10.
  • L'intero sistema ha raggiunto il 96,4% di Table Recall@20.
  • Gli studi di ablazione hanno confermato che la rimozione di uno qualsiasi dei cinque tipi di oggetti degradava le prestazioni, validando la natura non ridondante della tassonomia.

• Memoria del Carico di Lavoro (SEDE):

  • L'incorporazione della cronologia delle query ha elevato il Table Recall@5 dal 52,1% al 92,3% (+40,2 punti), dimostrando che i pattern storici migliorano significativamente il ranking delle tabelle rilevanti.

• Generazione End-to-End (BIRD):

  • Lo Schema-First Retrieval ha ridotto gli errori di esecuzione SQL dal 15,6% al 6,2% (una riduzione di 2,5 volte).
  • La riduzione è stata statisticamente significativa (test di McNemar, p=0,035).
  • L'analisi degli errori ha rivelato che il sistema ha eliminato 8 di 9 errori fissi relativi al grounding lessicale (ad esempio, quoting degli identificatori e riferimenti a colonne di tabelle errate) portando alla luce le forme superficiali corrette nel contesto recuperato.

• Efficienza:

  • La pipeline di recupero aggiunge circa 1,28 secondi per query.
  • Il costo sperimentale totale è stato inferiore a 3 dollari per tutti i dataset (~0,006 dollari per domanda).

Significato e Rivendicazioni

Il documento sostiene che la selezione del catalogo è un problema di recupero di prima classe, non semplicemente un dettaglio di formattazione del prompt. Spostando l'obiettivo del recupero dagli snippet grezzi dello schema a un catalogo tipizzato e governato, il sistema colma il divario tra il linguaggio dell'analista (metriche di business, termini informali) e lo schema fisico (colonne abbreviate, scorciatoie operative).

Gli autori affermano che un'analisi affidabile del linguaggio naturale richiede uno strato di recupero costruito specificamente su come i warehouse vengono documentati, interrogati e governati. La separazione delle responsabilità — dove il recupero fornisce una porzione di catalogo dotata di provenienza e la generazione scrive su tale porzione — consente al sistema di migliorare sia le metriche di recupero che il comportamento di esecuzione. Inoltre, imponendo il controllo degli accessi deterministicamente al di fuori del modello, il sistema evita le insidie del fare affidamento sugli LLM per aderire alle policy di sicurezza.

Il documento conclude che, sebbene l'approccio riduca significativamente gli errori lessicali e di grounding, non risolve gli errori di semantica dei dati (ad esempio, confronti con NULL o violazioni di arità degli aggregati), identificando il confine dove il recupero non è più il collo di bottiglia.