Salidas estructuradas
Hasta ahora hemos trabajado principalmente sobre la instrucción: qué debe hacer el sistema, con qué información, bajo qué criterios y en qué etapas.
Pero existe otra decisión de diseño que puede cambiar radicalmente la utilidad del resultado:
¿Cómo queremos que la información quede representada?
Supongamos que una revisión contractual devuelve veinte párrafos como éstos:
La cláusula 8.2 parece relevante porque permite ciertos usos de datos. También hay que considerar la cláusula de terminación, que podría ser problemática si...La respuesta puede ser razonable y aun así resultar difícil de:
- comparar;
- revisar;
- ordenar;
- copiar a una minuta;
- transformar en una planilla;
- utilizar como entrada de una etapa posterior.
Una salida estructurada intenta resolver ese problema imponiendo una forma más estable a la información.
Una salida estructurada organiza la respuesta según campos, categorías o una sintaxis definida.
Sirve para aumentar consistencia, revisión y reutilización.
Pero controla principalmente la forma de la salida. No demuestra que el contenido sea verdadero ni que la evaluación sea jurídicamente correcta.
Una escala de estructura
Podemos imaginar varios niveles:
texto libre
↓
lista
↓
tabla Markdown
↓
JSON o XML
↓
schema o estructura validableCada nivel agrega control formal, pero también exige más claridad sobre qué información queremos representar.
Si todavía no sabemos cuáles son las entidades, categorías o campos relevantes, pedir JSON no resolverá el problema conceptual.
Texto libre: máxima flexibilidad
Ejemplo:
Resume los principales riesgos del contrato en lenguaje claro.La ventaja del texto libre es que permite explicación, matices y transiciones naturales.
Puede ser ideal para:
- un informe narrativo;
- una explicación al cliente;
- una síntesis ejecutiva;
- un comentario doctrinal.
Su límite aparece cuando necesitamos comparar muchas unidades de información o procesarlas de manera uniforme.
Listas: estructura mínima
Podemos pedir:
Devuelve una lista numerada.
Para cada punto incluye:
- tema;
- hallazgo;
- impacto.La lista ya crea unidades separadas.
Sin embargo, cuando necesitamos comparar columnas —por ejemplo evidencia, riesgo e información faltante— una tabla suele ser más adecuada.
Tabla Markdown: buena para lectura humana
Los materiales del curso destacan la tabla Markdown como una excelente solución para revisión en pantalla, copia a Word o transformación posterior en minuta.
Por ejemplo:
| Nº | Documento | Cláusula | Tema | Texto relevante | Hallazgo | Riesgo | Pregunta |
|---:|---|---|---|---|---|---|---|
| 1 | contrato.pdf | 8.2 | datos | "..." | uso secundario | medio | ¿qué comprende...? |Una instrucción completa podría ser:
Devuelve una tabla Markdown con estas columnas:
| Nº | Documento | Cláusula | Tema | Texto relevante | Hallazgo | Riesgo | Pregunta para revisar |
Reglas:
- una fila por hallazgo;
- si una cláusula genera dos riesgos distintos, utiliza dos filas;
- si no puedes localizar la cláusula, escribe “ubicación no determinada”;
- no inventes referencias;
- después de la tabla incluye una síntesis de máximo cinco prioridades.La tabla obliga a separar conceptos que en prosa podrían mezclarse.
texto relevante ≠ hallazgo ≠ riesgo ≠ preguntaEse solo hecho puede mejorar considerablemente la auditabilidad de la respuesta.
Markdown: estructura para humanos y documentos
Markdown es una sintaxis ligera para estructurar texto mediante encabezados, listas, tablas, énfasis y bloques de código.
Esta misma página está escrita en Markdown/Quarto.
Podemos pedir:
Devuelve la respuesta en Markdown con esta estructura:
# Síntesis
# Matriz de hallazgos
# Información faltante
# Preguntas para la contraparteMarkdown es útil cuando la salida seguirá siendo principalmente documental y legible por personas, pero queremos una jerarquía consistente.
No necesitamos aprender programación para utilizarlo.
JSON: representar datos mediante campos y valores
JSON es una forma estructurada de representar datos.
Un objeto sencillo puede verse así:
{
"tema": "terminacion",
"riesgo": "alto",
"clausula": "12.3"
}Podemos leerlo sin conocimientos técnicos avanzados:
temaes un campo;terminaciones su valor;riesgoes otro campo;altoes su valor.
Una lista de hallazgos podría representarse así:
{
"hallazgos": [
{
"id": "H1",
"tema": "datos",
"clausula": "8.2",
"riesgo": "medio"
},
{
"id": "H2",
"tema": "terminacion",
"clausula": "12.3",
"riesgo": "alto"
}
]
}La principal ventaja es que la información deja de estar sólo escrita “para leer” y pasa a tener campos explícitos que pueden ser validados o procesados.
Cuándo JSON resulta especialmente útil
Puede ser apropiado cuando la respuesta deberá:
- convertirse en una planilla;
- almacenarse como registros;
- pasar a otra aplicación;
- compararse automáticamente;
- ser validada por reglas;
- alimentar otra etapa del proceso.
Por ejemplo:
Devuelve exclusivamente JSON válido con esta estructura:
{
"documento": "...",
"hallazgos": [
{
"id": "H1",
"clausula": "...",
"tema": "...",
"texto_relevante": "...",
"interpretacion": "...",
"riesgo": "alto|medio|bajo",
"informacion_faltante": null,
"pregunta_para_contraparte": "..."
}
]
}Aquí la estructura obliga a decidir qué información importa.
Ese es uno de los efectos más útiles de diseñar outputs: nos fuerza a definir las entidades del análisis.
null: representar ausencia sin inventar
Una salida estructurada puede crear una presión implícita por rellenar todos los campos.
Supongamos que no conocemos la jurisdicción aplicable.
Una mala salida sería:
{
"jurisdiccion": "Chile"
}si el documento no lo establece.
Podemos permitir explícitamente:
{
"jurisdiccion": null
}null representa que no existe un valor disponible para ese campo.
En el marco del curso, esta idea es importante porque información faltante no debe convertirse en información inventada sólo para completar una estructura.
Podemos instruir:
Si un campo no puede determinarse a partir de los documentos autorizados, usa null o “no determinado en el documento”. No inventes valores.XML: etiquetas y estructura anidada
XML representa información mediante etiquetas.
Ejemplo:
<hallazgo>
<tema>terminacion</tema>
<clausula>12.3</clausula>
<riesgo>alto</riesgo>
</hallazgo>La información puede anidarse:
<revision_contrato>
<documento>contrato.pdf</documento>
<hallazgos>
<hallazgo id="H1">
<clausula>8.2</clausula>
<tema>datos</tema>
<texto_relevante>...</texto_relevante>
<interpretacion>...</interpretacion>
<riesgo nivel="medio">...</riesgo>
</hallazgo>
</hallazgos>
</revision_contrato>Los materiales del curso destacan una ventaja pedagógica de XML: puede ser cómodo cuando queremos delimitar bloques largos y anidados mediante etiquetas visibles.
JSON y XML: una comparación inicial
| Criterio | JSON | XML |
|---|---|---|
| Lectura humana en datos breves | buena | buena |
| Verbosidad | menor | mayor |
| Datos compactos | muy cómodo | posible, pero más extenso |
| Bloques largos y anidados | puede ser menos cómodo | etiquetas explícitas ayudan |
| Validación formal | JSON Schema | XSD, DTD u otras reglas |
| Uso pedagógico en esta clase | matrices, extracción, datos | secciones anidadas, documentos, delimitación |
Esta comparación es orientativa. Los sistemas reales pueden imponer decisiones tecnológicas distintas.
La lección no es “JSON es mejor que XML” o viceversa. La pregunta es:
¿Qué forma sirve mejor a la tarea y al consumidor de la salida?
XML también puede utilizarse dentro del prompt
No es necesario pedir una salida XML para aprovechar etiquetas.
Podemos estructurar una instrucción larga así:
<encargo>
<objetivo>Preparar una revisión inicial antes de la firma.</objetivo>
<parte_representada>Cliente</parte_representada>
</encargo>
<contexto>
<hecho>El servicio procesará información confidencial.</hecho>
<hecho>La continuidad es crítica.</hecho>
</contexto>
<documentos>
<principal>contrato.pdf</principal>
<anexo>anexo_datos.pdf</anexo>
</documentos>
<reglas>
<regla>No inventes cláusulas.</regla>
<regla>Distingue texto e interpretación.</regla>
</reglas>Aquí XML cumple una función de delimitación de secciones, no de salida.
Podríamos lograr algo semejante con encabezados Markdown. Lo importante es hacer visible qué bloque cumple qué función.
¿Qué es un schema?
Hasta ahora hemos descrito una estructura esperada mediante un ejemplo.
Un schema formaliza qué estructura se considera válida.
Imaginemos que queremos exigir que todo hallazgo tenga:
id;tema;riesgo;evidencia.
Y además queremos que riesgo sólo pueda ser:
alto | medio | bajo | no_determinadoUn schema permite expresar reglas de ese tipo de manera más formal.
Para un principiante, basta comprender esta diferencia:
“devuelve JSON”
↓
control general de formato
“devuelve JSON que cumpla este schema”
↓
control más estricto de campos y tiposUn ejemplo mínimo de JSON Schema
No necesitamos aprender toda la especificación. Observemos sólo la idea:
{
"type": "object",
"required": ["tema", "riesgo"],
"properties": {
"tema": {
"type": "string"
},
"riesgo": {
"type": "string",
"enum": ["alto", "medio", "bajo", "no_determinado"]
}
}
}Esto expresa, simplificando:
- la salida debe ser un objeto;
- debe incluir
temayriesgo; - ambos son texto;
riesgosólo admite cuatro valores.
El schema controla estructura. Todavía no sabe si la clasificación es correcta.
Cinco niveles de corrección que no debemos confundir
Esta es una de las distinciones más importantes de toda la sección.
Una salida puede ser:
1. sintácticamente válida
2. compatible con el schema
3. semánticamente coherente
4. respaldada por la fuente
5. jurídicamente razonableCada nivel exige controles distintos.
1. Sintaxis
{
"riesgo": "alto"
}¿Es JSON válido?
2. Schema
¿Tiene los campos obligatorios y valores permitidos?
3. Semántica interna
¿El valor del campo corresponde realmente al significado del campo?
Un error semántico sería:
{
"riesgo": "clausula 8.2"
}4. Evidencia factual
¿La cláusula 8.2 existe y dice lo que la respuesta afirma?
5. Evaluación jurídica
¿Clasificarla como “alto” está suficientemente justificado?
Un JSON puede ser perfectamente válido, cumplir un schema y contener una cláusula inexistente.
Una tabla puede verse impecable y mezclar texto contractual con inferencias.
La presentación ordenada facilita el control. No reemplaza la evidencia ni la revisión.
Diseñar una salida verificable
Si queremos usar estructura para mejorar revisión, debemos incluir campos que hagan visible la procedencia.
Comparemos:
{
"riesgo": "alto"
}con:
{
"id": "H1",
"documento": "contrato.pdf",
"ubicacion": "clausula 8.2",
"texto_relevante": "...",
"interpretacion": "...",
"riesgo": "medio",
"base_del_riesgo": "...",
"informacion_faltante": null
}La segunda estructura no garantiza verdad, pero crea lugares específicos donde el sistema debe separar:
fuente
texto
interpretación
evaluación
incertidumbreEso favorece una revisión mucho más disciplinada.
Categorías cerradas y vocabulario controlado
Un formato estructurado puede limitar valores.
Por ejemplo:
Tema permitido:
- datos_personales
- confidencialidad
- propiedad_intelectual
- responsabilidad
- termino
- otroRiesgo permitido:
- alto
- medio
- bajo
- no_determinadoEsto ayuda a detectar desviaciones.
Si la respuesta devuelve:
riesgo = “bastante preocupante”sabemos que no siguió la taxonomía.
Pero también existe un peligro: si la lista de categorías está mal diseñada, podemos obligar a encajar casos complejos en una clasificación insuficiente.
La estructura amplifica tanto un buen diseño como un mal diseño.
La salida debe diseñarse desde su uso posterior
No debemos pedir JSON porque “suena técnico”.
Preguntemos primero:
¿Quién o qué consumirá esta salida después?
Si la leerá una persona en una reunión
Tabla Markdown.
Si irá a una minuta
Markdown con encabezados y tabla.
Si se transformará en registros o una planilla
JSON puede ser útil.
Si necesitamos bloques documentales largos y jerarquías anidadas
XML puede resultar cómodo.
Si otro sistema necesita validar campos
Puede ser conveniente un schema.
La forma debe seguir al proceso, no al entusiasmo por una sintaxis.
Salidas estructuradas en un proceso por etapas
La página anterior mostró cómo separar extracción y evaluación.
Podemos reforzar esa frontera mediante estructuras distintas.
Etapa 1:
{
"evidencias": [
{
"id": "E1",
"documento": "contrato.pdf",
"ubicacion": "8.2",
"texto": "..."
}
]
}Etapa 2:
{
"evaluaciones": [
{
"evidencia_id": "E1",
"interpretacion": "...",
"riesgo": "medio"
}
]
}Ahora la evaluación puede referirse a una evidencia identificada en vez de reescribirla libremente.
No estamos construyendo todavía un sistema automatizado. Sólo estamos aprendiendo una idea de diseño: la estructura puede preservar fronteras entre tipos de información.
Caso conductor: una matriz procesable
Para el contrato del proveedor de IA podríamos pedir:
Devuelve exclusivamente JSON válido.
Cada hallazgo debe contener:
- id;
- documento;
- ubicacion;
- tema;
- texto_relevante;
- interpretacion;
- riesgo;
- base_del_riesgo;
- informacion_faltante;
- pregunta_para_contraparte.
Reglas:
- no inventes ubicaciones;
- texto_relevante debe provenir del documento;
- separa texto e interpretación;
- riesgo sólo puede ser alto, medio, bajo o no_determinado;
- usa null cuando un dato no pueda determinarse;
- si no existe evidencia suficiente, no presentes el hallazgo como confirmado.La estructura ya puede utilizarse para revisar, comparar o procesar.
Sin embargo, la decisión de si el contenido es correcto sigue requiriendo evidencia y control.
Qué debes recordar
Una salida estructurada no es simplemente una respuesta “bonita”. Es una forma de hacer más estable la representación del resultado.
Podemos aumentar control desde texto libre hasta tablas, JSON, XML y schemas.
Pero debemos mantener esta separación:
FORMA CORRECTA
≠
CONTENIDO CORRECTO
≠
EVIDENCIA SUFICIENTE
≠
EVALUACIÓN JURÍDICA CORRECTALa estructura ayuda a revisar. No sustituye la revisión.
El problema que todavía queda abierto
Ya conocemos muchas técnicas para diseñar mejores prompts. Pero a veces el usuario sabe qué trabajo quiere realizar y, sin embargo, no sabe cómo traducirlo a una buena instrucción.
Podemos entonces pedir al propio modelo que critique, transforme o construya el prompt.
Ese es el objeto del siguiente nodo: los meta-prompts.