JSON con IA, formularios y extracción: una lista de verificación de confianza en cuatro puertas

El prompt no es el producto

Cuando una IA rellena un formulario, el usuario ve un nombre, una fecha, un número de teléfono y un botón. Si el modelo adivina, el producto ha tomado una decisión. Las evaluaciones de output estructurado deben funcionar como una puerta de liberación, no como una comprobación de sensaciones.

El primer fallo es de forma: una coma final, una llave que falta, un campo que debería ser un número pero es una cadena. Estos fallos son fáciles de detectar y deberían detener la liberación antes de que nadie discuta sobre el significado.

Un JSON válido no es un JSON correcto. Un formulario puede estar perfectamente tipado y aun así ser incorrecto: el número de calle está en el campo de ciudad, la fecha está en el siglo equivocado, la cantidad extraída le falta un decimal. La precisión de la extracción de datos necesita comprobaciones a nivel de campo, no solo un icono verde de análisis.

En las primeras pruebas de WordLift, añadir datos estructurados hizo que los fragmentos de GPT-5 fueran más coherentes y más relevantes en contexto. Eso es una evidencia útil de que la estructura ayuda, no una prueba de que cada campo sea correcto.

Publica solo cuando las cuatro puertas aprueben

Mantén la lista de verificación lo suficientemente breve para que un diseñador pueda ejecutarla en una revisión. Cada puerta debe responder a una pregunta que un usuario haría a posteriori: ¿Se analizó? ¿Significó lo que decía? ¿Sabía lo que no sabía? ¿Qué pasa cuando se equivoca?

• Puerta 1: Validez de esquema. Pasa una respuesta de muestra por un analizador y una comprobación de esquema; recházala si alguno falla. En Promptfoo, la aserción is-json puede verificar que una respuesta de LLM es JSON válido y también puede validar esa respuesta contra un esquema JSON proporcionado. La directiva transform de Promptfoo puede analizar la salida JSON antes de que se ejecuten las aserciones, de modo que los testers no necesitan repetir JSON.parse en cada aserción.
• Puerta 2: Precisión a nivel de campo. Asigna al menos una comprobación personalizada a cada campo obligatorio, como formato, rango o valor permitido. El tipo de aserción javascript de Promptfoo permite a los testers ejecutar comprobaciones JavaScript personalizadas sobre campos individuales en una respuesta JSON.
• Puerta 3: Calibración de confianza. Documenta el umbral de confianza, los ejemplos etiquetados utilizados para establecerlo y la ruta de revisión para registros débiles. Un diseñador debería poder señalar el umbral en las notas de liberación.
• Puerta 4: Respaldo seguro. Pasa una muestra de baja confianza por el flujo y confirma que llega a revisión, no a guardado automático.

La calibración necesita un conjunto pequeño etiquetado. El proceso de dos pasos de WordLift produjo 97 registros de URL con campos clave anotados. WordLift aplicó un método LLM-as-a-Judge impulsado por Gemini 2.5 Pro, una revisión puntuada por modelo, para extraer tres métricas principales de su conjunto de datos de URL. La herramienta importa menos que la brecha medida entre lo que el modelo dice y lo que una persona confirma.

Las puertas están ordenadas porque cada una cambia la siguiente pregunta: un fallo de esquema hace que la precisión de campo sea irrelevante, una precisión de campo no medida convierte la confianza en una suposición, y una confianza no calibrada deja que la cola de revisión pierda de vista los registros que la necesitan.

El respaldo es donde se construye la confianza

La baja confianza es un estado que la interfaz debe asumir, no un error que ocultar. Un usuario que ve requiere revisión entiende que el sistema tiene límites. Un usuario que descubre un número de teléfono incorrecto en un registro guardado aprende lo contrario. El rediseño comienza haciendo que el registro incierto sea visualmente distinguible: una insignia, un borde atenuado, una nota a nivel de campo que indique qué valor es débil.

Si un modelo trunca el texto de origen, el producto no debe fingir que el registro es completo. GPT-5 tiene una directiva interna wordlim que limita dinámicamente la cantidad de texto de la página web que puede incluirse en una respuesta generada.

El flujo de corrección debe preservar el trabajo útil del modelo. Si la dirección de calle es correcta pero el código postal es incorrecto, la persona debe corregir un campo, no volver a introducir todo el formulario. El producto gana confianza cuando el sistema admite la incertidumbre, el usuario mantiene el control y la ruta de datos permanece auditable.

Para las funciones de extracción, el valor predeterminado más seguro es un borrador, no un commit. El modelo propone; el producto verifica; el usuario aprueba. Un umbral de confianza demasiado alto ahoga al equipo en revisiones; uno demasiado bajo libera errores. Pon ese umbral en la especificación y revísalo cuando la tasa de error aceptable cambie.