Predir errors en la generació automàtica de consultes SQL és un dels reptes més rellevants de la intel·ligència artificial aplicada a les dades. La tasca coneguda com a Text-to-SQL consisteix a convertir una pregunta escrita en llenguatge natural en una consulta SQL que s'executa sobre una base de dades relacional. El criteri de correcció no és la validesa sintàctica, sinó l'equivalència de resultats: la consulta generada ha de retornar el mateix conjunt de dades que una consulta de referència escrita per un humà. En un entorn empresarial, aquesta diferència és crítica, perquè una consulta aparentment ben formada pot amagar un error lògic que destrueix la confiança en la dada.
A Q2BSTUDIO treballem cada dia amb tecnologies que combinen dades, automatització i experiència d'usuari. Quan una organització demana una solució de programari, no només necessita una aplicació que funcioni; també necessita saber quin grau de fiabilitat té cada resposta generada per IA. Per això, l'avaluació de la incertesa en Text-to-SQL no és un problema teòric. És un component de disseny. Una plataforma de reporting, un assistent intern o un procés d'automatització que fa servir SQL generat per IA ha d'incorporar senyals de confiança i mecanismes d'abstenció. Sense ells, el sistema pot donar respostes errònies amb la mateixa naturalitat que respostes correctes.
El context de negoci fa que el problema sigui encara més delicat. Les decisions comercials depenen cada vegada més de quadres de comandament actualitzats en temps real. Un error silenciós en una consulta pot alterar una mètrica, un KPI o un informe executiu. Si, a més, aquesta consulta s'executa sobre infraestructura al núvol AWS/Azure, l'impacte es propaga a tota l'organització. A Q2BSTUDIO ho veiem sovint en projectes de Business Intelligence: la qualitat de les dades no es resol només amb un bon model de dades o amb una capa de transformació de processos; també requereix verificar les consultes que es generen dinàmicament. Per això, quan integrem assistents en plataformes de BI/Power BI, prestem una atenció especial a la validació de les sentències generades.
Quines senyals poden indicar que una consulta SQL generada per IA és correcta? La investigació ha explorat diverses famílies de senyals. L'executabilitat comprova que la consulta no falli. La rellevància d'esquema avalua si la consulta fa servir les taules i columnes necessàries per respondre. La consistència d'execució executa diverses versions de la consulta i comprova si els resultats coincideixen. La consistència estructural examina l'arbre sintàctic i el compara amb referències o variants. La consistència de text compara diferents formulacions de la mateixa pregunta; si el model genera sempre la mateixa consulta, la confiança augmenta. Finalment, la probabilitat logarítmica que el model assigna a la seqüència generada ofereix un senyal de caixa blanca, basat en la confiança interna del model.
Cada una d'aquestes senyals té capacitat predictiva, però també un sostre clar. En benchmarks complexos, ordenen correctament una part significativa de les consultes, però no permeten separar amb seguretat les correctes de les incorrectes. És com tenir diverses pistes, cap de concloent. La consistència de text sol ser la més sòlida entre les senyals de caixa negra, però continua lluny de ser suficient. La probabilitat logarítmica aporta una perspectiva diferent, tot i que no gaire superior. La conclusió és que les senyals superficials, les que no requereixen raonament profund, són necessàries, però no n'hi ha prou.
El progrés real apareix quan s'introdueix un verificador. Un verificador és un model de llenguatge que rep la pregunta original, l'esquema de la base de dades i la consulta generada, i emet un veredicte: correcta o incorrecta. Aquest enfocament funciona millor perquè obliga el model a raonar sobre el significat de la consulta i la seva adequació a l'esquema. Els verificadors basats en models grans superen totes les senyals anteriors. A més, una troballa important és que els errors de diferents proveïdors no se superposen del tot. En combinar dos verificadors de famílies diferents, la precisió conjunta augmenta de manera notable. La clau és que la verificació no depèn d'un únic patró, sinó de capacitats complementàries de raonament.
Un bon verificador no només ordena les consultes per qualitat; produeix una probabilitat calibrada. Això permet definir una política d'abstenció. Si la confiança del verificador supera un llindar, el sistema respon automàticament; si no, deriva la consulta a una persona o a un flux de supervisió. Aquesta lògica és especialment útil en entorns d'agents d'IA, on el sistema ha d'actuar de manera autònoma però amb límits clars. Un agent que sap quan no respondre és més segur i més útil que un que sempre retorna una resposta. A Q2BSTUDIO apliquem aquesta filosofia a les nostres solucions d'intel·ligència artificial, on la verificació forma part del disseny.
Una altra línia de desenvolupament és entrenar verificadors específics per a una organització. Es crea un conjunt de dades amb consultes correctes i incorrectes i s'ajusta un model perquè les classifiqui. Els resultats en el domini d'entrenament són bons, gairebé comparables als d'un jutge gran. Tanmateix, quan el verificador s'enfronta a esquemes de dades no vistos, el seu rendiment cau de manera significativa. Augmentar la mida del model, afegir més esquemes a l'entrenament, destil·lar els raonaments d'un jutge potent o entrenar amb múltiples benchmarks no aconsegueix tancar aquesta bretxa. La generalització sembla dependre de la capacitat de raonament del model base, no de les capes addicionals de classificació.
Aquesta conclusió té una implicació estratègica clara. Si una empresa vol construir un assistent SQL fiable a llarg termini, hauria d'invertir en models de raonament potents i congelats, desplegats en infraestructura pròpia o consumits a través de serveis al núvol, en lloc d'assumir el cost de crear i mantenir un verificador ajustat. El verificador ajustat pot ser una bona eina en un entorn estable i conegut, però no és una garantia per a escenaris oberts. La combinació de raonament general, senyals clàssiques i calibració de la confiança és avui la solució més robusta.
La verificació de consultes SQL també té un component de ciberseguretat. Una consulta generada per IA pot accedir a taules que no hauria, o combinar dades de manera que reveli informació sensible. Un verificador pot detectar accessos inesperats i comportaments anòmals, complementant així els controls d'accés i les polítiques de prevenció de fuites. En entorns regulats, aquesta capa de validació és imprescindible per auditar què va fer el sistema i per què. La traçabilitat deixa de ser un complement i es converteix en part de l'algorisme mateix.
Per avançar en la predicció d'errors en Text-to-SQL, una organització pot seguir un camí pràctic. Primer, construir un conjunt d'avaluació amb consultes reals i anotacions de correcció. Segon, mesurar el rendiment de les senyals clàssiques com a referència. Tercer, incorporar un verificador basat en raonament, idealment combinant dos proveïdors. Quart, calibrar la confiança amb dades pròpies. Cinquè, definir llindars de resposta automàtica i de derivació a supervisió humana. Sisè, monitoritzar el comportament davant de canvis d'esquema. Aquest procés converteix la incertesa en una dada de gestió, no en una limitació.
A Q2BSTUDIO creiem que la propera frontera del programari no és només generar respostes, sinó saber quan són fiables. Per això integrem mecanismes de verificació en projectes que van des del desenvolupament d'aplicacions a mida fins a l'automatització de processos, passant per solucions de BI/Power BI i el núvol AWS/Azure. Un sistema de Text-to-SQL ben dissenyat no és el que no s'equivoca mai, sinó el que detecta els seus propis errors, els comunica amb honestedat i permet a les persones prendre el control en els moments crítics. Aquesta és la senyal que realment importa.
