De pedirle cosas a la IA a trabajar con criterio

01 / LA IDEA EN UN MINUTO

Un buen encargo necesita un criterio de calidad.

Pedir hazlo mejor deja demasiadas decisiones sin explicar. Mejor puede significar más breve, más preciso, más cercano o más completo. Si no tienes claro qué necesitas, es fácil entrar en una conversación larga que cambia el estilo sin mejorar la utilidad.

Un encargo concreto describe para qué se usará el resultado, qué información debe respetar y qué formato facilita utilizarlo. También señala lo que no se sabe. Esa claridad no garantiza una respuesta correcta, pero hace posible reconocer dónde falla.

La iteración empieza cuando comparas la respuesta con un criterio. Si solo eliges la versión que más te gusta, puedes estar premiando seguridad, elegancia o confirmación de tus ideas. Trabajar con criterio exige preguntarte qué mejora de verdad y cómo lo has comprobado.

02 / LA SEMILLA DE ESTA IDEA

Contextualizar y aprender de cada intento.

Los apuntes del curso de Sngular recogen consejos como aclarar el objetivo, estructurar la petición, dar contexto y utilizar ejemplos. Son contenidos del curso, no conclusiones originales de Iván.[1]

En su LP posterior sobre una demo de IA, Iván describe técnicas que le sirvieron: conversar, explicar instrucciones, dividir tareas y ajustar la petición al observar la respuesta. Resume el prompting como un trabajo de contextualización.[2]

Conservamos ese aprendizaje de iteración, matizando dos generalizaciones. Más contexto no siempre es mejor si añade ruido o contradicciones. Y pedir que el modelo adopte un rol no demuestra que posea la competencia o haya comprobado los hechos de un especialista.

La ampliación añade una pieza esencial: probar el procedimiento con más de un caso. Conseguir una respuesta que te gusta para una entrada concreta no demuestra que la misma instrucción funcione de forma fiable cuando cambian los datos.

03 / DE LA INSTRUCCIÓN A UNA PRUEBA REPETIBLE

Cambia algo que puedas evaluar.

La documentación de OpenAI recomienda instrucciones claras, ejemplos y contexto pertinente, además de pruebas que permitan observar el comportamiento cuando se modifica el prompt o el modelo.[3] Usamos ese principio sin convertir la nota en una receta específica de una versión.

Puedes organizar el encargo en cuatro partes: propósito, material disponible, trabajo solicitado y criterios de aceptación. No necesitas una plantilla enorme. Necesitas que las condiciones importantes no queden escondidas en una conversación anterior o en tu cabeza.

Si el resultado falla, identifica el tipo de fallo. Tal vez falta información, se mezclan categorías o el formato dificulta revisar. Cambiar el tono no corrige una ausencia de datos. Añadir instrucciones contradictorias para arreglar cada caso puede empeorar el conjunto.

Guarda algunos ejemplos representativos y vuelve a usarlos al cambiar el procedimiento. Incluye un caso incompleto o ambiguo, no solo el caso fácil. Te interesa saber si el sistema reconoce lo que falta, además de si redacta bien cuando todo está preparado.

04 / RESUMIR UNA REUNIÓN SIN INVENTAR ACUERDOS

El criterio cambia la petición.

Imagina que un equipo quiere resumir sus reuniones. Es un ejemplo hipotético. Su primera instrucción pide un acta profesional. La respuesta convierte propuestas en decisiones y asigna responsables que nadie confirmó. El documento parece útil hasta que alguien intenta trabajar con él.

La revisión útil no es hacerlo más serio. Es separar decisiones confirmadas, propuestas pendientes y preguntas abiertas; conservar los responsables solo cuando figuren en las notas; y señalar la información ausente. El formato debe permitir volver al fragmento que respalda cada acuerdo.

El equipo prueba la instrucción con una reunión clara y otra donde hay desacuerdo. Si la segunda sigue inventando consenso, el procedimiento todavía necesita revisión. Una salida bonita en el primer ejemplo no compensa ese fallo.

Cuando funciona mejor, el equipo conserva la versión de la instrucción y sus criterios. Las actas siguen revisándose antes de utilizarlas. La automatización ahorra parte de la redacción, pero no puede decidir por sí sola qué se acordó si el registro no lo dice.

05 / LLÉVALO A TU PROYECTO

Define el trabajo y observa el fallo concreto.

Elige una tarea repetida y un material que puedas compartir. Escribe qué resultado necesitas y qué errores serían inaceptables para ese uso. Por ejemplo, inventar cifras, mezclar clientes o convertir una posibilidad en un compromiso.

Da un ejemplo de resultado adecuado si ayuda a explicar el criterio. Aclara qué es importante del ejemplo para que no se copie una característica accidental. Un buen ejemplo enseña la estructura y el nivel de precisión que buscas.

Prueba con casos distintos y revisa contra el material original. Cuando cambies la instrucción, conserva qué intentabas corregir. Así podrás distinguir una mejora real de una respuesta distinta que simplemente te resulta más atractiva.

Si el fallo persiste, considera cambiar el proceso: aportar otra fuente, dividir el trabajo o mantener una revisión humana más estrecha. No toda limitación se arregla insistiendo con el mismo prompt. El objetivo es un resultado utilizable, no ganar una discusión con la herramienta.

06 / APRENDIZAJES

Aprendizajes

• El criterio precede al prompt. Aclara qué significa un buen resultado.
• Contexto relevante supera contexto indiscriminado. Evita ruido y contradicciones.
• Un rol no acredita competencia. Las afirmaciones siguen necesitando comprobación.
• Iterar exige identificar el fallo. Modifica algo que puedas evaluar.
• Prueba más de un caso. Incluye ambigüedad e información incompleta.

07 / PREGUNTAS DETONANTES

Preguntas detonantes

1. ¿Qué significa mejor en esta tarea?
2. ¿Qué información falta y cómo debe señalarse?
3. ¿Qué error no puedo aceptar en el resultado?
4. ¿Estoy evaluando exactitud o solo estilo?
5. ¿Funciona la instrucción cuando el caso es ambiguo?

08 / CONEXIONES

Para seguir aprendiendo