# Semantic parsing y salidas estructuradas

«Muéstrame los artículos de semiótica publicados después de 2020 que tengan al menos dos autores». Para responder a esta petición en un catálogo, un sistema debe identificar una colección, interpretar restricciones temporales y temáticas, contar relaciones de autoría y producir un resultado. El sistema podría redactar una respuesta plausible sin realizar ninguna de esas operaciones. Una interfaz fiable, en cambio, necesita conectar la expresión lingüística con una representación que permita ejecutarlas y comprobarlas. Ese paso es uno de los problemas centrales del análisis semántico computacional.

La expresión inglesa semantic parsing suele designar la transformación de lenguaje natural en una representación formal de significado, a menudo ejecutable. Las salidas estructuradas, una categoría más amplia, organizan información según un formato o esquema sin representar siempre el significado completo de una intervención. Un objeto con campos bien escritos puede contener una interpretación errónea; a la inversa, una interpretación adecuada puede quedar expresada en una estructura inválida que otro programa no logra procesar. El texto estudia esta separación entre forma, interpretación y ejecución. Examina el diseño de las representaciones, las dificultades que introduce la ambigüedad del lenguaje y la combinación de aprendizaje y restricciones, con el propósito de entender qué aporta la formalización y qué aspectos del sentido siguen dependiendo del contexto, de la organización de los datos y de las decisiones de quienes construyen el sistema.

## La representación como contrato de interpretación

Una representación formal establece distinciones explícitas que un programa puede utilizar. En una búsqueda documental puede separar tema, fechas, autoría y orden de presentación para aplicar sobre cada componente operaciones definidas, sin tratar cada respuesta como prosa libre. Los campos, sin embargo, no surgen espontáneamente del lenguaje. Los diseñadores eligen qué diferencias son relevantes para el servicio y cómo se relacionan con los datos disponibles. Esa elección delimita lo que el sistema puede expresar. Dentro del contrato pueden distinguirse tres niveles. La sintaxis del formato determina qué secuencias están bien formadas; el esquema define campos, tipos y relaciones permitidas; la interpretación vincula esos elementos con la petición y con el dominio. A veces un objeto cumple los dos primeros niveles y falla en el tercero, como ocurre cuando contiene una fecha de aceptación en el campo destinado a la de publicación. La validación automática de estructura detectaría ciertos problemas, pero no necesariamente esa confusión conceptual.

El contrato incluye también convenciones sobre la ausencia de información. Cuando un campo queda vacío, la ausencia puede significar que no se preguntó, que se desconoce el dato o que el campo no corresponde al caso. Si todos esos estados se representan del mismo modo, las operaciones posteriores pierden distinciones necesarias. Un sistema que lee la ausencia como respuesta negativa puede cometer errores sistemáticos. Por eso el diseño debe especificar qué significa cada valor y qué decisiones son admisibles cuando falta evidencia para completar el campo.

La formalización hace visibles ciertos supuestos y vuelve verificables las operaciones, aunque también puede imponer categorías inadecuadas. Conviene tratar el esquema como una hipótesis sobre la actividad antes que como un contenedor neutral. Sus límites aparecen en los casos difíciles (peticiones incompletas, categorías superpuestas, excepciones, cambios de criterio), cuya revisión forma parte del desarrollo semántico del sistema.

## Composición, relaciones argumentales y contexto

Una consulta no se interpreta sumando significados de palabras aisladas, sino atendiendo a cómo se combinan. En el ejemplo inicial, «después de 2020» restringe la fecha de publicación y «al menos dos autores» impone una condición sobre el número de participantes relacionados con cada artículo. El sistema necesita construir una organización en la que cada restricción se aplique al objeto correcto. Un procedimiento que solo detectara las palabras «2020», «dos» y «autores» no podría representar la petición.

La composición puede describirse mediante operaciones sobre conjuntos y relaciones. Se parte del conjunto de artículos, se seleccionan los que cumplen las condiciones temáticas y temporales y se conserva cada artículo cuya relación de autoría satisface el umbral. Algunas de estas operaciones pueden reordenarse sin que cambie el resultado; otras dependen de agrupaciones previas. Gracias a esa estructura es posible distinguir una interpretación equivalente de una secuencia que solo contiene los mismos términos.

Las relaciones argumentales plantean un problema semejante. «Artículos que critican a Rivera» y «artículos que Rivera critica» pueden mencionar las mismas entidades y, aun así, les asignan papeles inversos. Un extractor basado únicamente en la presencia de nombres perdería la diferencia, que las representaciones semánticas intentan conservar mediante roles o relaciones explícitas. La tarea se complica cuando los participantes quedan implícitos o se expresan con pronombres, o cuando la construcción sintáctica altera la correspondencia entre la forma superficial y el orden de los argumentos.

La composición encuentra además límites contextuales. «Los más recientes» requiere saber qué fecha cuenta y respecto de qué colección se compara; «los nuestros» exige resolver una pertenencia. En esos casos el análisis combina estructura lingüística y contexto de la aplicación. Cuando el contexto no basta, una representación responsable puede dejar variables pendientes o solicitar una aclaración. Si, en cambio, la representación completa todos los campos con valores plausibles, produce una apariencia de precisión sin asegurar que el sistema haya recuperado la intención del usuario.

## Formas lógicas, grafos y programas

Las salidas del análisis semántico adoptan formas diversas. Una forma lógica representa predicados, variables, operadores y relaciones. En un grafo, las entidades o los eventos son nodos cuyas propiedades se conectan mediante aristas. Los programas, por su parte, describen operaciones ejecutables en un entorno. Estas opciones no son intercambiables sin condiciones, ya que cada una conserva ciertas distinciones y facilita determinadas comprobaciones. Todas requieren, además, reglas que las relacionen con el lenguaje de entrada.

Banarescu y colaboradores (2013) presentaron Abstract Meaning Representation, o AMR, como una propuesta de representación mediante grafos para construir anotaciones semánticas de oraciones. AMR busca abstraer algunas diferencias sintácticas y organizar información conceptual y relacional. Como sus autores señalaron explícitamente que la propuesta estaba orientada en su origen al inglés, no corresponde tratarla como una representación universal de todas las dimensiones del significado ni como una lengua intermedia que borre automáticamente las diferencias entre lenguas.

Una representación ejecutable añade otra relación, pues necesita un intérprete y un mundo de datos sobre el cual operar. La misma expresión formal puede producir resultados diferentes si se consulta otra base, porque la ejecución depende de una interpretación y de un estado, sin que por ello su significado cambie de manera arbitraria. Si se distinguen programa, entorno y resultado, pueden localizarse errores que una evaluación limitada a la respuesta final podría confundir.

El formato adecuado varía con la tarea. Para registrar menciones de acontecimientos puede resultar apropiado un grafo; para consultar un catálogo, una expresión de consulta; para coordinar una herramienta, una llamada con argumentos tipados.

Representar toda la comunicación en un único formato puede añadir complejidad innecesaria. También puede ocultar información si el formato elegido solo admite acciones y parámetros mientras la intervención incluye dudas, condiciones o compromisos que requieren un tratamiento separado.

## Vincular expresiones con un esquema de datos

Una base de datos puede contener columnas llamadas fecha_publicacion, fecha_ingreso y fecha_revision. Nada en la palabra «recientes» indica cuál de ellas corresponde. El enlace con el esquema, conocido habitualmente como schema linking, relaciona expresiones del usuario con tablas, campos, valores y relaciones. Para hacerlo bien, el sistema necesita descripciones precisas y ejemplos del dominio, ya que los nombres técnicos de las columnas pueden ser insuficientes o incluso engañosos cuando reflejan convenciones históricas. La documentación del esquema es parte de la interfaz lingüística. Debe explicar unidades, convenciones temporales, relaciones y valores especiales. Si una columna almacena fechas de distintos calendarios o si el estado «activo» tiene un significado administrativo específico, esa información afecta a la consulta. Como las convenciones que el modelo nunca recibió no pueden recuperarse de manera fiable, mejorar la documentación puede resolver problemas que, de otro modo, se atribuirían indebidamente a una falta de capacidad general del analizador semántico.

La relación entre entidades también debe conocerse. Como un artículo puede tener varios autores y una persona figurar en varios artículos, una consulta que combine artículos y autores puede devolver varias filas por artículo. Si cada fila se cuenta como una publicación independiente, el resultado será incorrecto aunque la consulta sea ejecutable. Este tipo de error muestra que la interpretación incluye comprender cómo están organizados los datos, además de traducir palabras a nombres de columnas.

Los valores requieren una resolución propia. «Semiótica» puede ser una categoría controlada, una palabra del título o una clasificación derivada del resumen; cada opción responde a una pregunta distinta. «Rivera», a su vez, puede identificar a varias personas. El sistema debe trabajar con identificadores y con contexto suficiente sin descartar la posibilidad de que la ambigüedad persista. Elegir el primer valor encontrado puede funcionar en un ejemplo sencillo y fallar sistemáticamente cuando el catálogo crece o aparecen nombres compartidos.

## Una consulta completa sobre un catálogo

Consideremos un catálogo hipotético con tres tablas, Articulos, Autores y Autorias. La primera contiene identificador, título, tema y anio_publicacion; la segunda identifica personas; la tercera relaciona artículos y autores. Con ellas es posible convertir la petición inicial en una consulta que seleccione los artículos clasificados como semiótica, limite el año y agrupe por artículo las relaciones de autoría. El umbral debe aplicarse al número de autores distintos, según la definición adoptada para el catálogo. La consulta SQL siguiente es una traducción aproximada.

```sql
SELECT a.id, a.titulo
FROM Articulos AS a
JOIN Autorias AS r ON r.articulo_id = a.id
WHERE a.tema = 'semiotica'
  AND a.anio_publicacion > 2020
GROUP BY a.id, a.titulo
HAVING COUNT(DISTINCT r.autor_id) >= 2;
```

El ejemplo da por sentado que el tema utiliza el valor normalizado que aparece en la consulta y que el año es un entero. Esas convenciones forman parte de la interpretación. La condición «mayor que 2020» excluye ese año completo; si el usuario quisiera incluirlo, habría que cambiarla. También se presupone que las relaciones de autoría corresponden a autores válidos y que la clasificación temática permite exactamente ese filtro. Que la consulta sea correcta bajo esos supuestos no indica que estos sean adecuados para cualquier colección.

Cambiemos ahora la petición por «artículos con dos autores». La formulación podría entenderse como exactamente dos o, en ciertos contextos, como una referencia informal a la coautoría. Un sistema diseñado para la precisión debe fijar una convención o aclarar la diferencia cuando esta altere el resultado. En la consulta ejecutable la elección queda visible en un operador y puede revisarse antes de usar el resultado en un informe o en otra operación que dependa de su exactitud.

## Cuantificación, negación y alcance

Los cuantificadores introducen dificultades que las correspondencias léxicas simples no resuelven. «Todos los autores publicaron un artículo» puede describir un artículo compartido o un caso en que cada autor publicó uno diferente. Como una base de datos necesita una consulta concreta y las dos lecturas pueden dar resultados distintos, el analizador semántico debe considerar estructura y contexto, sin asignar siempre una representación fija a cada combinación de palabras. La negación plantea un contraste semejante. Frente a «ningún artículo fue revisado», que los excluye a todos, «no todos los artículos fueron revisados» admite que algunos sí lo fueron. Una salida estructurada que redujera ambas afirmaciones a revisado=false perdería una diferencia central. Para conservarla, el esquema debe representar el alcance de la negación y la unidad sobre la cual se evalúa. Cuando el esquema no puede hacerlo, el límite corresponde también al diseño representacional.

Las condiciones temporales interactúan con estos operadores. «Autores que no publicaron después de 2020» puede incluir a personas sin publicaciones registradas, según cómo se defina el universo de autores. Además, que el catálogo carezca de registros de una persona no prueba que esa persona no tenga publicaciones fuera de él. La consulta responde sobre los datos y sobre sus convenciones de completitud. Para presentar el resultado como una afirmación exhaustiva sobre el mundo haría falta evidencia que la ejecución no aporta.

Los ejemplos de alcance permiten construir pruebas informativas, en las que se varían negaciones, cuantificadores y relaciones sin alterar el resto de la consulta, para comprobar si la representación cambia donde corresponde. También conviene incluir situaciones en que dos interpretaciones coinciden accidentalmente en el resultado, pues sobre una sola base de prueba el error podría pasar inadvertido. La evaluación semántica necesita observar la operación, además de comparar respuestas en un conjunto limitado de datos.

## Datos ausentes y valores NULL

La ausencia de valores merece una prueba aparte. Si el año de una publicación no está registrado, no debe convertirse automáticamente en cero ni en una fecha anterior al límite, porque las operaciones sobre datos faltantes necesitan una semántica explícita. Quien diseña la consulta puede excluir esos registros, presentarlos por separado o declarar que no es posible clasificarlos temporalmente. Cualquiera de esas decisiones modifica el universo sobre el cual se informa. Documentarla impide que la incompletitud del catálogo se transforme en una conclusión histórica que los datos no sostienen.

En SQL, la comparación de un año NULL con 2020 produce un valor lógico desconocido. Como WHERE conserva únicamente los resultados verdaderos, WHERE anio_publicacion > 2020 y WHERE NOT (anio_publicacion > 2020) excluyen ambos el registro cuyo año falta. Para recuperarlo hace falta una condición como anio_publicacion IS NULL (PostgreSQL Global Development Group, s. f.). El ejemplo separa dos fallos, la mala interpretación de la petición y el desconocimiento de la semántica del lenguaje formal de destino. La negación verbal «no consta que sea posterior», por su parte, tampoco obliga a escoger la misma consulta que «consta que no es posterior».

## Aprender con representaciones y con respuestas

Una vía de entrenamiento usa pares de expresiones y representaciones formales, de los que el modelo aprende a predecir la estructura anotada. Se obtiene así supervisión directa sobre la interpretación a cambio de elaborar anotaciones especializadas y decidir cómo tratar las variantes equivalentes. Como los anotadores pueden discrepar por la ambigüedad del enunciado o por las convenciones del formalismo, esa discrepancia tiene que analizarse antes de atribuir cualquier diferencia a errores del modelo.

Otra vía utiliza preguntas y respuestas y trata la representación como una variable que debe inferirse. Berant y colaboradores (2013) estudiaron el aprendizaje de análisis semántico sobre Freebase a partir de pares de pregunta y respuesta, sin exigir formas lógicas anotadas para cada ejemplo. Este enfoque reduce parte de la necesidad de supervisión especializada, aunque introduce el problema de encontrar, entre numerosas alternativas posibles, los programas que producen la respuesta correcta. Aparece entonces la dificultad general de las soluciones espurias, programas que obtienen el resultado esperado por una coincidencia de los datos aunque representen mal la pregunta. Supongamos que, en el conjunto de entrenamiento, todos los artículos de cierto tema tienen exactamente dos autores. Un sistema podría aprender a usar el tema como sustituto del recuento. Con la incorporación de artículos nuevos la equivalencia desaparecería. El acierto en el conjunto de entrenamiento no prueba que se haya aprendido la relación composicional pretendida.

Para estudiar la generalización se recomienda separar combinaciones, esquemas o dominios según la pregunta de investigación. Memorizar consultas frecuentes puede ser útil en un servicio acotado, pero dice poco sobre la capacidad de interpretar estructuras nuevas. El conjunto Spider, presentado por Yu y colaboradores (2018), contribuyó a estudiar consultas complejas y la generalización entre bases con esquemas diferentes. Su interés metodológico está en evaluar transferencias explícitas y en procurar que una partición aparentemente nueva no conserve las mismas plantillas y estructuras esenciales.

## Salidas estructuradas y tipos de información

Un formato como JSON organiza objetos, listas y valores de manera legible para los programas. Puede usarse para expresar una consulta intermedia antes de traducirla a SQL o para registrar información extraída de documentos. Sin embargo, JSON define una sintaxis y carece de una teoría del significado. Un objeto con campos tema, fecha y autor se procesa con facilidad aunque contenga valores inventados o mal atribuidos, cuya detección requiere verificaciones adicionales. Los tipos, por su parte, ayudan a restringir ciertos errores. Puede exigirse que un año sea un entero, que una lista de identificadores no tenga duplicados y que un estado tome uno de varios valores admitidos. Con estas restricciones desaparecen variaciones de formato innecesarias. Un entero válido, con todo, puede ser el año equivocado, del mismo modo que un identificador existente puede corresponder a otra persona. Por eso la validez de tipo cubre solo una parte de la exactitud que se espera de la salida.

En una extracción bibliográfica, el título puede aparecer explícitamente mientras el tipo de documento se infiere por el contexto. Si ambos campos se presentan con idéntico estatuto, una aplicación posterior puede tratarlos como datos igualmente seguros. Para evitarlo, el esquema debería distinguir entre información observada, inferida y pendiente. También puede incorporar la procedencia y el estado de revisión cuando esa información tenga consecuencias. Como la complejidad añadida tiene que justificarse por decisiones reales, carece de sentido crear campos que nadie interpreta ni mantiene.

La estructura debe permitir también representar el desconocimiento sin forzar una respuesta. Un campo obligatorio que no acepta un valor de ausencia puede inducir al sistema a completar lo que falta. Con estados definidos, en cambio, el sistema tiene la opción de detenerse, pedir información o continuar de manera limitada, según la tarea. Para modificar registros, resolver antes las ambigüedades puede ser una condición necesaria, aunque en una búsqueda exploratoria pueda bastar una interpretación provisional.

## Decodificación restringida y entradas irresolubles

Un modelo generativo ordinario puede producir cualquier secuencia admitida por su vocabulario. Cuando la salida debe pertenecer a un lenguaje formal, parte de esas secuencias resulta inválida. La decodificación restringida limita las continuaciones posibles según una gramática, un analizador sintáctico o un esquema. De ese modo, el procedimiento de generación incorpora condiciones que una instrucción verbal como «responde con un objeto válido» deja sin asegurar.

Scholak, Schucher y Bahdanau (2021) propusieron PICARD, un método que usa análisis incremental para rechazar continuaciones inadmisibles durante la generación. Su aplicación a consultas SQL muestra cómo puede combinarse un modelo de lenguaje con restricciones formales. El mecanismo reduce ciertos errores de construcción, aunque elegir entre las consultas válidas la que expresa la petición requiere todavía conocimiento del dominio y una evaluación aparte.

Las restricciones pueden operar con distintos grados de detalle. La gramática asegura determinadas formas y el esquema puede verificar nombres y tipos; otras comprobaciones son capaces de detectar referencias inexistentes o relaciones incompatibles. Cuanto más específica es una restricción, más información del dominio necesita; si está mal definida, puede excluir soluciones legítimas. Por ello los rechazos deben poder inspeccionarse y distinguirse de los casos en que el modelo no logra una respuesta adecuada.

Un sistema fiable debe manejar también las entradas irresolubles, aquellas para las que ninguna opción satisface las condiciones. Forzar siempre un objeto aparentemente completo puede ocultar contradicciones de la petición o limitaciones del esquema. Es preferible representar el fallo de interpretación de manera explícita y permitir la recuperación. Esta política forma parte del contrato, que debe fijar los errores que se comunican, los datos que se solicitan y las condiciones para intentar otra formulación.

## Validar antes de ejecutar

Una consulta o una llamada estructurada puede atravesar varias comprobaciones. Se analiza su forma, se verifican nombres, tipos y relaciones y, por último, se evalúan las condiciones de ejecución. Una búsqueda de solo lectura y una instrucción que modifica datos tienen consecuencias distintas, aunque ambas se expresen en lenguaje formal. Los permisos y las reglas de aplicación deben mantenerse al margen de la plausibilidad lingüística del resultado. Tampoco la ejecución asegura el éxito semántico. Un programa puede terminar sin errores y devolver un conjunto vacío porque consultó el campo equivocado; otro puede devolver miles de filas por una relación mal especificada. Una precaución razonable es comprobar invariantes como las cardinalidades esperadas, las unidades, las duplicaciones y la coherencia con las restricciones explícitas. Estas comprobaciones deben detectar patrones incompatibles con el contrato o lo bastante anómalos para justificar una revisión, sin inventar los resultados deseados.

Cuando hay efectos sobre el entorno, la separación entre interpretación y acción adquiere más peso. La frase «¿podrías borrar los duplicados?» puede ser una solicitud y, aun así, deja por determinar qué registros son duplicados y qué alcance tiene el borrado. Una representación útil identifica candidatos y criterios antes de ejecutar. Que la estructura satisfaga un esquema técnico no justifica transformar una incertidumbre de referencia en una acción irreversible.

Los fallos deben comunicarse con precisión. «No encontré registros» expresa algo distinto de «no pude consultar la base» o de «la consulta no pudo interpretarse». Si se mezclan esos estados, el usuario puede concluir que cierta información no existe cuando en realidad hubo un problema de acceso o de construcción. Los códigos internos bien definidos, traducidos luego a explicaciones comprensibles, ayudan a conservar la relación entre lo que se intentó, lo que ocurrió y lo que se sabe.

Otra comprobación se basa en casos pequeños cuyo resultado pueda calcularse a mano. Para la consulta del catálogo bastan artículos con uno, dos y tres autores, años a ambos lados del límite, un registro sin fecha y una relación de autoría duplicada que permita verificar el efecto de contar identificadores distintos.

Estos casos complementan una evaluación amplia. Si aíslan consecuencias semánticas y no repiten mecánicamente la implementación del generador, con ellos puede comprobarse que los operadores expresan las decisiones declaradas.

## Ambigüedad y reparación mediante diálogo

Cabe organizar el análisis semántico como una actividad interactiva. Si una petición admite varias lecturas relevantes, el sistema formula una pregunta que permita distinguirlas. Una aclaración útil apunta al aspecto que cambia la operación y evita pedir por defecto una reformulación completa. Ante «publicaciones recientes», el sistema podría preguntar qué intervalo temporal interesa si el contexto no aporta una convención; ante «las de Rivera», quizá deba resolver primero qué persona o qué papel de autoría se menciona. Las aclaraciones excesivas tienen, con todo, su costo, porque preguntar por cada detalle vuelve difícil una tarea sencilla. El diseño debe separar las ambigüedades que afectan al resultado de las variaciones irrelevantes para la finalidad. En operaciones reversibles puede apoyarse en convenciones explícitas y permitir la corrección posterior. La política elegida se evalúa con estudios de uso que midan las reparaciones necesarias, los errores persistentes y el grado en que los usuarios comprenden la interpretación adoptada por el sistema.

Antes de una operación delicada, el sistema también puede presentar una paráfrasis de su interpretación. Esa paráfrasis tiene que corresponder a la estructura que de verdad se ejecutará. Si se genera por separado, puede describir una intención correcta mientras el programa contiene otra, de modo que la relación entre representación y explicación debe poder comprobarse. Si la interfaz muestra, además de una frase tranquilizadora, los parámetros y las relaciones que gobiernan la acción, el usuario puede revisarlos antes de confirmarla.

La reparación introduce estado conversacional. Después de una consulta, «incluye también 2020» modifica un límite anterior y conserva las demás condiciones, mientras que «no, los de un solo autor» reemplaza el criterio de autoría. El sistema necesita identificar qué parte se actualiza y cuál permanece. Si reinterpreta cada intervención de forma aislada, corre el riesgo de perder restricciones. El error inverso es arrastrarlas todas sin revisarlas, con lo que pueden mantenerse condiciones que el usuario canceló. El seguimiento del diálogo debe admitir cambios de distinto alcance, desde la sustitución de un criterio hasta la ampliación o la corrección parcial de otro.

## Evaluar representación, resultado y generalización

La coincidencia exacta con una representación de referencia es una medida clara, aunque puede penalizar variantes equivalentes. Dos consultas pueden devolver siempre el mismo resultado pese a ordenar sus operaciones de manera distinta. A la inversa, la coincidencia de resultados en una sola base puede premiar programas espurios. Por eso conviene combinar criterios de estructura y de ejecución con pruebas sobre estados de datos capaces de distinguir interpretaciones.

La evaluación por componentes ayuda a localizar problemas. Puede examinar la selección de tablas, los enlaces entre entidades, los operadores, los límites temporales y las agrupaciones. Esa descomposición complementa la evaluación integral, porque acertar en cada componente por separado no asegura que las piezas se combinen correctamente. Sin embargo, permite diseñar intervenciones dirigidas. Si el fallo se concentra en nombres ambiguos, quizá haya que mejorar la resolución de entidades; si aparece en la cuantificación, hará falta otra clase de ejemplos y comprobaciones. Las explicaciones de error deberían desglosarse del mismo modo. Calificar una consulta de «incorrecta» informa poco si no se distingue una entidad mal resuelta de una agregación equivocada. Con una clasificación estable de errores cabe observar qué mejora tras modificar datos, restricciones o instrucciones, así como comparar versiones sin reducir todos los cambios a una sola cifra. Cuando una modificación corrige un fenómeno y deteriora otro, el equipo puede decidir sabiendo qué usuarios y qué tareas resultan afectados.

La partición de los datos debe corresponder a la generalización que se afirma. Una separación aleatoria de preguntas puede dejar plantillas casi idénticas en entrenamiento y prueba. Separar bases examina otra capacidad, distinta, a su vez, de la que se pone a prueba al separar combinaciones de operadores. Como ninguna partición es universalmente mejor, el informe debe explicar qué diferencias introduce la partición elegida y qué permanece compartido. Con esa información puede valorarse si el resultado avala una herramienta para un dominio conocido o una pretensión más amplia de interpretación entre dominios.

También hay que evaluar las respuestas de abstención y aclaración. Un sistema que siempre produce un programa puede obtener mayor cobertura y cometer errores costosos. En el extremo opuesto, el que se detiene con demasiada frecuencia resulta poco útil. La comparación debe considerar ambos aspectos junto con la capacidad de recuperación tras una corrección. En aplicaciones reales, la calidad se mide por las tareas resueltas de manera verificable y por los fallos manejables, además de por el porcentaje de entradas que reciben alguna estructura.

## Mantenimiento del significado operativo

Los esquemas cambian. Una institución puede redefinir una categoría, añadir una tabla o modificar el significado de un estado. Si el analizador semántico conserva ejemplos e instrucciones antiguos, puede producir consultas formalmente válidas bajo una interpretación desactualizada. El mantenimiento requiere versionar la documentación, las representaciones y las pruebas, ya que una modificación técnica en apariencia pequeña puede alterar qué preguntas responde el sistema y cómo deben leerse sus resultados, sobre todo cuando los usuarios siguen empleando las mismas palabras.

La procedencia permite reconstruir las decisiones interpretativas. Para una operación relevante es útil conservar la petición, la interpretación estructurada, la versión del esquema y el estado de ejecución, dentro de los límites de privacidad que correspondan. Esta trazabilidad, que no requiere almacenar indiscriminadamente cada conversación, facilita investigar errores sin depender exclusivamente de una explicación generada después. Delimitar su alcance exige decidir qué evidencia hace falta para verificar resultados y durante cuánto tiempo se justifica conservarla.

El semantic parsing muestra que formalizar una expresión redistribuye el trabajo interpretativo entre lenguaje, esquema, programa y contexto. Las salidas estructuradas hacen posible coordinar componentes y comprobar condiciones siempre que sus categorías estén bien definidas. Su valor crece cuando permiten revisar una interpretación, representar la incertidumbre y separar una propuesta de una acción. En esas condiciones, la precisión computacional puede contribuir a una práctica lingüística más transparente en lugar de limitarse a dar apariencia formal a decisiones poco justificadas.

## Referencias

Banarescu, L., et al. (2013). Abstract Meaning Representation for Sembanking. *Proceedings of the 7th Linguistic Annotation Workshop and Interoperability with Discourse*, 178–186. https://aclanthology.org/W13-2322/

Berant, J., Chou, A., Frostig, R., y Liang, P. (2013). Semantic Parsing on Freebase from Question-Answer Pairs. *Proceedings of EMNLP*, 1533–1544. https://aclanthology.org/D13-1160/

PostgreSQL Global Development Group. (s. f.). *Comparison Functions and Operators*. En *PostgreSQL Documentation*. Consultado el 22 de octubre de 2026. https://www.postgresql.org/docs/current/functions-comparison.html

Scholak, T., Schucher, N., y Bahdanau, D. (2021). PICARD: Parsing Incrementally for Constrained Auto-Regressive Decoding from Language Models. *Proceedings of EMNLP*, 9895–9901. https://aclanthology.org/2021.emnlp-main.779/

Yu, T., et al. (2018). Spider: A Large-Scale Human-Labeled Dataset for Complex and Cross-Domain Semantic Parsing and Text-to-SQL Task. *Proceedings of EMNLP*, 3911–3921. https://aclanthology.org/D18-1425/