Generador de Prompts JSON

Por qué la prosa rompe el código y JSON no

Pide a un modelo "el nombre, el sueldo y la fecha de incorporación del candidato" y recibes un párrafo bien escrito. Pídelo dos veces y recibes dos párrafos distintos. Uno dice "unos 85.000 €", el siguiente "85.000 EUR anuales", un tercero arranca con "¡Claro! Esto es lo que he encontrado". Tu parser no tiene ninguna oportunidad.

El problema no es la exactitud: el modelo puede acertar siempre. Es que el texto libre no tiene contrato. Nada garantiza que el sueldo aparezca antes que la fecha, que un campo ausente se omita en vez de describirse, o que la respuesta se salte el preámbulo. Cada expresión regular que escribes para sobrevivir es un bug esperando una redacción ligeramente distinta.

JSON te da ese contrato. Las claves son fijas, los tipos son fijos, null significa "no encontrado" siempre. Tu código lee data.salary en vez de buscar un símbolo de moneda. Cuando el modelo se equivoca, te enteras al parsear y no tres funciones más abajo.

Si lo lee una persona, la prosa está bien. Si lo lee código, usa JSON.

Diseña un esquema que el modelo pueda cumplir

Los modelos satisfacen los esquemas simples con fiabilidad y los complejos de forma intermitente. Reglas que aguantan:

• Plano mejor que anidado. Dos niveles se llevan bien. En el cuarto empiezan a cerrarse llaves donde no toca. contact_email es más seguro que contact.channels.email.primary.
• Sé explícito con los tipos. Di "salary debe ser un número, no una cadena". Ante la duda, los modelos tiran de cadenas.
• Usa null, nunca omitas. Las claves ausentes rompen data.x.y de formas en que los valores ausentes no.
• Fija tus enums. "status debe ser exactamente uno de: open, closed, pending" produce tres valores. "status: el estado actual" produce quince maneras de decir esos tres.
• Nombra las claves como lo haría alguien que programa. snake_case, sin espacios. El modelo ya escribe mucho JSON.
• Quita los campos que no vas a usar. Cada clave de más es otra oportunidad de inventarse un valor.

Enseña la forma en vez de describirla. Un ejemplo literal con marcadores vale más que un párrafo de especificación:

Instrucciones que acaban con la prosa suelta y los bloques de código

Tres fallos causan casi todas las respuestas imposibles de parsear: un preámbulo, un bloque markdown y una explicación al final. Pon esto cerca del final, donde se lee al último:

• "Devuelve SOLO el objeto JSON. Sin prosa, sin explicación, sin bloques de código markdown."
• "Tu respuesta completa debe empezar con una llave de apertura y terminar con una de cierre."
• "No envuelvas la salida en comillas invertidas."

La segunda línea es la que más trabaja. Es una comprobación que el modelo puede verificar contra su propio primer token, mucho más fiable que un genérico "nada de texto extra".

Ayúdate también en el lado del parseo. Elimina los bloques de código al principio y al final antes de parsear: tres líneas defensivas que te ahorran un reintento. Y baja la temperatura a 0. El muestreo creativo es justo lo contrario de lo que quieres aquí.

Si un modelo insiste en añadir preámbulos, suele ser una manía de redacción y no una carencia. El generador de prompts para ChatGPT y el generador para Gemini ajustan la formulación a cada modelo, y el analizador marca las instrucciones que invitan a comentarios sin querer.

Arrays, campos opcionales y el caso vacío

Los arrays son donde los prompts de extracción se vuelven descuidados. Di cuántos y qué pasa cuando no hay ninguno.

"Devuelve [] si ninguna aplica" impide que el modelo escriba "ninguna" dentro de un array. El tope impide que infle un documento corto para parecer minucioso. Para objetos opcionales, prefiere null a la omisión: una rama en tu código en vez de dos.

Validar, reintentar y dónde encajan los modos nativos

Nunca te fíes del primer parseo. El bucle que sobrevive en producción:

1. Parsea. Si lanza error, quita bloques y espacios, y parsea otra vez.
2. Valida contra un esquema real: Zod, Pydantic, JSON Schema. Comprueba tipos y claves obligatorias, no solo que sea JSON válido.
3. Si falla, reintenta una vez con el error añadido: "Tu salida anterior no pasó la validación: se esperaba un número en salary y llegó una cadena. Devuelve solo el JSON corregido."
4. Tras dos fallos, registra la salida cruda y usa un plan B. No entres en bucle.

Ese reintento arregla la mayoría de fallos al primer intento, porque has convertido un fallo difuso en una corrección concreta.

Y ahora la parte que la gente se salta: casi todos los proveedores ofrecen salida estructurada nativa —modo JSON, esquemas de respuesta, llamadas a funciones—. Úsala donde exista. La API restringe la decodificación, así que un JSON malformado se vuelve casi imposible. Pero impone forma, no sentido. Una respuesta válida según el esquema puede seguir poniendo el nombre del reclutador en company. La semántica la lleva el prompt: qué significa cada campo, cuándo aplica null, qué valor del enum encaja. Son complementarios. La documentación de OpenAI cubre el lado de la API; la guía de fundamentos cubre los patrones que hay debajo de todo esto, y el optimizador aprieta un prompt de extracción hinchado sin tirar las restricciones que importan.