Artículos · Mustapha Alouani
Tres controles antes de confiar en una extracción
Un JSON correcto puede contener información equivocada. Un protocolo para separar forma y significado.
La reunión en la ciudad equivocada
El documento dice: «La sede está en Paris. La reunión tendrá lugar en Lyon». Pides la ciudad de la reunión. El sistema devuelve un objeto con Paris. Nada falla, la aplicación muestra un mapa y la demostración parece funcionar. Sin embargo, te envía al lugar equivocado.
El error supera dos controles habituales: el JSON se puede leer y el valor es una cadena de texto. El problema es el papel de la ciudad seleccionada, no su representación.
Define el contrato antes del prompt
Especifica el campo esperado, su tipo y qué hacer cuando falta información. Aquí, meeting_city contiene texto o null, sin campos adicionales. null significa que la ciudad de la reunión está ausente; no que el modelo duda o que la ciudad no figura en una lista permitida.
Crea una respuesta de referencia por documento. Si dos anotadores no pueden ponerse de acuerdo, la tarea todavía no está suficientemente definida para evaluarla de manera fiable.
Mide tres éxitos diferentes
- Sintaxis: ¿el analizador puede leer la salida?
- Esquema: ¿los campos y tipos cumplen el contrato?
- Fidelidad: ¿la respuesta corresponde a la información y al papel solicitados?
Indica el denominador de cada tasa. «90 % de aciertos entre salidas válidas» no significa «90 % de documentos procesados correctamente». Las salidas inválidas no deben desaparecer del balance global.
Construye una prueba pequeña y útil
Incluye cuatro familias: una sola ciudad, varias ciudades con papeles distintos, ninguna ciudad de reunión y una ciudad fuera del catálogo habitual. Varía también el orden de las frases. Reserva documentos nuevos para la prueba final después de corregir el sistema.
La decodificación restringida puede reducir algunos errores de formato. No sustituye las referencias ni los casos difíciles. El tomo 2 ilustra esta distinción con un protocolo concreto; sus cifras no describen el rendimiento universal de todos los LLM.
Sigue un documento de principio a fin
Volvamos al documento como lectores que verifican el resultado. Buscamos una relación: ¿qué ciudad corresponde a la reunión? «Paris» cumple la condición «ser una ciudad presente en el texto», pero esa condición es demasiado débil. Su frase describe la sede. La segunda frase vincula explícitamente la reunión con Lyon. La referencia debe proceder de esa relación, no de la primera ciudad encontrada.
Por eso una extracción no siempre es una simple búsqueda de palabras. Reconocer una entidad, asignarle un papel y devolverla en el campo correcto son operaciones conceptualmente distintas. Aunque un mismo modelo las realice en una sola generación, separarlas permite comprender mejor sus errores.
Imagina tres salidas: texto libre que dice «Lyon», un objeto cuyo meeting_city es Paris y otro cuyo meeting_city es Lyon. La primera contiene la información correcta, pero incumple la interfaz de la aplicación. La segunda cumple la interfaz, pero comunica información falsa. Solo la tercera satisface ambas exigencias. El éxito operativo requiere un contenido correcto y una representación utilizable.
Del resultado global al diagnóstico
En otro ejemplo construido, evaluamos cien documentos. Diez salidas no se pueden interpretar, veinte son legibles pero incumplen el esquema y cincuenta de las setenta salidas conformes contienen la ciudad correcta. El éxito de principio a fin es 50 de 100. La fidelidad entre las salidas conformes es 50 de 70, aproximadamente el 71,4 %. Ambos números son útiles, pero responden a preguntas distintas. El primero describe lo que recibe el usuario; el segundo ayuda a aislar los errores de significado tras los errores de formato.
Mejorar el formato puede aumentar el número de salidas utilizables sin mejorar su exactitud. A la inversa, una mejor comprensión puede resultar invisible si la aplicación no puede leer las respuestas. Elige la siguiente corrección según la categoría de errores dominante y vuelve a medir con documentos reservados.
Una regla para los casos difíciles
Si un documento menciona dos reuniones en dos ciudades, nuestro contrato de un solo valor resulta insuficiente. Hay que precisar qué reunión buscamos, permitir varios valores o señalar la ambigüedad. Pedir al modelo que sea «más preciso» no repara una pregunta mal definida. Una extracción excelente comienza por una tarea que se pueda explicar y comprobar sin el modelo.
Ejercicio resuelto
«La sede está en Lyon. La reunión será en Marseille». ¿Es correcto devolver null porque Marseille no está en la lista? No. La información está presente. Prevé un estado distinto para valores fuera del catálogo o permite extraerlos, sin confundir presencia y ausencia.