TAPAS: Table QA débilmente supervisado sin SQL y qué significa para Beancount

He estado dedicando tiempo al linaje de text-to-SQL — BIRD, DIN-SQL, MAC-SQL —, pero todos ellos comparten una suposición que quiero cuestionar: que la interfaz adecuada para Table QA (respuesta a preguntas sobre tablas) es la generación de SQL. TAPAS, publicado por Herzig et al. en Google Research (ACL 2020), toma la apuesta contraria. Nunca genera una consulta. En su lugar, simplemente selecciona celdas y, opcionalmente, aplica una agregación escalar, entrenado de extremo a extremo solo a partir de denotaciones de respuesta.

El artículo

TAPAS extiende BERT para codificar tablas añadiendo seis nuevas dimensiones de embebido sobre los IDs de posición y segmento estándar. El ID de Columna y el ID de Fila marcan dónde reside cada token en la cuadrícula de la tabla. Un ID de Rango codifica el orden numérico relativo dentro de las columnas ordenables (el rango 0 significa no comparable, el rango i+1 para el i-ésimo valor más pequeño). Un indicador de Respuesta Anterior marca las celdas que fueron seleccionadas en el turno conversacional previo. Combinado con el embebido de segmento binario que distingue los tokens de la pregunta de los tokens de la tabla, esto le da a TAPAS su representación de tokens de siete tipos.

En el momento de la inferencia, el modelo selecciona un conjunto de celdas mediante el establecimiento de umbrales en las probabilidades por celda, luego aplica uno de cuatro operadores de agregación — NONE (ninguno), COUNT (conteo), SUM (suma) o AVERAGE (promedio) — para producir la respuesta final. No hay SQL intermedio ni forma lógica. El preentrenamiento ejecuta un objetivo estándar de modelo de lenguaje enmascarado (MLM) sobre 6.2 millones de pares de texto y tablas de Wikipedia en inglés.

Ideas clave

• Los embebidos de columna/fila son fundamentales. La ablación muestra que eliminarlos cuesta 19.4 puntos de precisión en SQA, 10.6 en WikiSQL y 11.6 en WikiTQ, una pérdida mucho mayor que cualquier otro componente arquitectónico.
• El preentrenamiento de tablas importa casi tanto como lo anterior. Eliminarlo reduce SQA en 12.5 puntos y WikiTQ en 11.1 puntos, incluso después del ajuste fino (fine-tuning).
• En SQA (Table QA conversacional), TAPAS eleva la precisión del 55.1% al 67.2%, un salto de 12 puntos. El embebido del token de Respuesta Anterior es el mecanismo que permite que la continuidad conversacional funcione sin un seguidor de estado independiente.
• En WikiSQL (tabla única, mayormente búsqueda y agregación), TAPAS alcanza el 83.6%, igualando esencialmente al analizador semántico de vanguardia (SOTA) del 83.9%, con cero generación de SQL.
• El aprendizaje por transferencia de WikiSQL a WikiTQ (razonamiento de múltiples pasos y múltiples columnas) rinde un 48.7%, 4.2 puntos por encima del estado del arte en ese momento. La transferencia de SQA da un 48.8%.
• La supervisión débil es la principal ventaja de asequibilidad: el modelo se entrena con pares (pregunta, respuesta), no con triples (pregunta, SQL, respuesta), por lo que se pueden anotar grandes corpus sin experiencia en SQL.

Qué se mantiene — y qué no

La idea central — que muchas preguntas de Table QA pueden responderse seleccionando celdas y aplicando una de cuatro operaciones escalares — es empíricamente sólida para los puntos de referencia (benchmarks) probados. Pero el honesto análisis de errores del artículo sobre WikiTQ es revelador: el 37% de los errores no son clasificados por los propios autores, el 16% requiere manipulación de cadenas que el modelo no puede realizar y el 10% implica un razonamiento temporal complejo. Esto significa que el techo de TAPAS no se debe a que los operadores de agregación sean incorrectos; se trata de categorías enteras de preguntas que están estructuralmente fuera de su alcance.

La restricción de 512 tokens es un muro infranqueable. Las tablas con más de aproximadamente 500 celdas deben truncarse, y el modelo no tiene mecanismos para el razonamiento multitabla. Esto no es un problema de ajuste, es un problema arquitectónico. El modelo tampoco puede anidar agregaciones: una pregunta como "¿cuántas cuentas tienen un saldo promedio mayor a cero?" requiere dos pasadas (un promedio dentro de un predicado COUNT), algo que el cabezal de cuatro operadores no puede expresar.

TAPEX (ICLR 2022) aborda directamente el cuello de botella del preentrenamiento reemplazando el MLM de tablas de Wikipedia con la ejecución de SQL sintético sobre programas autogenerados, elevando WikiTQ al 57.5% (+4.8) y SQA al 74.5% (+3.5). Esa es una brecha significativa. Pero TAPEX hereda los mismos límites arquitectónicos en cuanto al tamaño de la tabla y la profundidad composicional.

La pregunta más profunda que no se resuelve en ninguno de los dos artículos es si el paradigma de selección de celdas se adapta mejor al Table QA del mundo real que la generación de SQL por razones prácticas, no por la precisión del benchmark, sino por las garantías de auditabilidad y corrección. La selección de celdas es opaca: obtienes una respuesta pero no un programa. La generación de SQL es verbosa pero verificable. Para su uso en producción, ese equilibrio importa más que unos pocos puntos de precisión.

Por qué esto importa para la IA financiera

Un libro mayor de Beancount es, efectivamente, una tabla plana y estructurada: cuentas en filas, montos, fechas, monedas y etiquetas en columnas. El paradigma de selección directa de celdas de TAPAS se mapea naturalmente a las consultas más comunes de un libro mayor — "¿cuál es el total gastado en comestibles en marzo?" —, que son exactamente agregaciones SUM y COUNT sobre filas filtradas. El embebido de Respuesta Anterior es directamente útil para sesiones conversacionales donde un usuario refina una consulta ("¿y qué hay del año pasado?").

Sin embargo, los libros mayores de Beancount a gran escala rompen las restricciones de TAPAS. Un libro mayor multianual con miles de transacciones supera el presupuesto de 512 tokens por órdenes de magnitud. Las jerarquías de cuentas requieren razonamiento a través de grupos de filas. Las consultas como "¿qué cuentas tienen una salida neta mayor que su promedio de los últimos tres años?" necesitan agregaciones anidadas que el cabezal de cuatro operadores no puede expresar. Y lo más crítico: para la seguridad de la escritura (write-back), la selección de celdas no ofrece un programa auditable que se pueda revisar antes de confirmar un cambio. SQL, al menos, proporciona un artefacto inspeccionable.

Mi conclusión provisional es que el paradigma de selección de celdas es la interfaz adecuada para una capa de consulta de solo lectura en lenguaje natural sobre pequeños fragmentos de un libro mayor: las transacciones de un mes, el historial de una sola cuenta. Para el razonamiento sobre el libro mayor completo y cualquier cosa que implique escritura, un enfoque de síntesis de programas (ya sea de estilo SQL o el DSL de Beancount) sigue siendo más seguro y expresivo.

Qué leer a continuación

• TAPEX: Table Pre-training via Learning a Neural SQL Executor (arXiv:2107.07653, ICLR 2022) — el sucesor directo que reemplaza el MLM de Wikipedia con la ejecución de SQL sintético; responde directamente a si el preentrenamiento en programas supera al preentrenamiento en texto para Table QA.
• Binder: Binding Language Models in Symbolic Languages (arXiv:2210.02875) — utiliza GPT-3 para generar programas en SQL o Python sobre tablas y logra SOTA en WikiTQ; el enfoque híbrido que los defensores de la selección de celdas deben considerar.
• OmniTab: Natural and Artificially Structured Data for Table QA (arXiv:2207.02270) — combina corpus de tablas naturales con datos de SQL sintético en una sola receta de preentrenamiento; prueba si TAPAS y TAPEX son complementarios en lugar de competidores.