Ejercicios — Prompt Engineering

Presentes: rol (guía turístico), instrucción (recomendar qué hacer), restricción (presupuesto $40), formato (itinerario por día con costos).

Faltan: contexto (¿cuántas personas? ¿con vehículo o en bus? ¿desde dónde salen?), datos (no aplica mucho en esta tarea — no hay material a procesar; está bien que falte), criterio de éxito (¿qué hace bueno el itinerario: comer rico, caminar poco, fotos?).

Lección: no todo prompt necesita las siete piezas; este está bastante bien. Pero el contexto faltante (personas, transporte) va a producir suposiciones que pueden invalidar el presupuesto entero.

Explicame qué es la inflación y por qué sube el precio de la canasta
básica.                                              ← instrucción

Contexto: estudio primer año de administración; en el examen me van a
pedir explicar causas y consecuencias.               ← contexto

Formato: (1) definición simple, (2) 3 causas con un ejemplo
centroamericano cada una, (3) 3 consecuencias, (4) un párrafo de
cierre que conecte todo.                             ← formato

Restricción: sin fórmulas todavía — primero quiero la intuición.
Criterio: que pueda explicárselo a un compañero sin leer.

El punto no es la longitud: es que cada decisión importante (nivel, propósito, estructura, profundidad) quedó tomada por vos.

Ejercicio personal sin solución única. Lo típico que se descubre: el prompt reescrito tiene 3-5 veces la longitud del original, y cada corrección que hiciste en la conversación ("más corto", "en español", "sin tanta introducción", "para nivel principiante") era una pieza de las siete que faltaba (formato, restricción, contexto). Ese prompt reescrito es exactamente el tipo de entrada que va a tu biblioteca: ya pagaste su costo de desarrollo una vez — no lo pagués de nuevo.

Los dos tenían criterios de éxito distintos y no declarados: uno quería un resumen para repasar antes del examen (necesita fechas, nombres, causas — densidad de datos), el otro quería entender la idea general del período (necesita narrativa, conexiones, poco detalle). La respuesta satisfizo un criterio y no el otro — pero ninguno se lo dijo al modelo, así que el modelo eligió por ellos.

La pieza que lo evita: el criterio de éxito explícito ("una buena respuesta me permite responder preguntas de examen sobre fechas y actores" vs. "una buena respuesta me deja contar la historia del período de corrido"). Moraleja profunda: cuando dos personas juzgan distinto la misma salida de IA, casi siempre el desacuerdo estaba en los criterios no escritos, no en la salida.

El problema: los tres ejemplos son inconsistentes entre sí — uno da 3 hashtags, otro 1, otro 6; uno capitaliza (#Cuscatlán), otro no (#café); el tercero agrega hashtags genéricos de relleno (#noticias #2026). El modelo no puede saber cuál patrón imitar — va a imitar uno al azar o un promedio raro.

Arreglo: ejemplos con formato idéntico y regla implícita clara:

Convertí títulos de noticias a exactamente 3 hashtags: lugar o
protagonista, tema, categoría. CamelCase para hashtags compuestos.

"Selecta gana en el estadio Cuscatlán" → #LaSelecta #Fútbol #Deportes
"Inauguran nuevo hospital en Santa Ana" → #SantaAna #Hospital #Salud
"Suben los precios del café" → #Café #Precios #Economía

Convertí: "Estudiantes de UNIMO ganan concurso de robótica"

(Respuesta esperable: #UNIMO #Robótica #Educación.) En few-shot, la consistencia entre ejemplos ES la instrucción.

a) Etiquetas/delimitadores (sección 2.4): <articulo>...</articulo> + instrucción explícita "respondé usando solo el contenido de <articulo>", con la pregunta fuera (y al final).

b) Salida de escape (2.5): "si el manual no contiene la información, respondé 'el manual no lo especifica'" + pedir cita textual de la sección del manual para lo que sí responda.

c) Few-shot (2.1): mostrarle 2-3 evaluaciones reales hechas con la escala del curso. La escala descrita verbalmente se "interpreta"; la escala mostrada se imita. (Mención honorable: también ayuda poner la escala completa en el prompt como dato — descripción + ejemplos es la combinación ganadora.)

PASO 1 — Extraer transacciones del chat:
"Extraé cada pago o deuda mencionado en <chat>. Formato de salida:
una línea por transacción: quién_pagó | monto_usd | concepto |
quiénes_deben | DUDOSO si el mensaje es ambiguo.
Si un mensaje habla de dinero pero no se entiende, listalo aparte
en 'REVISAR A MANO' con el mensaje textual."

PASO 2 — Consolidar por persona (entrada: la tabla del paso 1):
"Con esta tabla de transacciones, calculá el balance por persona:
total pagado, total adeudado, saldo neto. Excluí las filas DUDOSO
y listalas aparte. Formato: tabla ordenada por saldo."

PASO 3 — Plan de pagos (entrada: la tabla del paso 2):
"Con estos balances, generá el plan de pagos mínimo: quién le
transfiere cuánto a quién, con el menor número de transferencias.
Formato: lista 'A → B: $X' + verificación de que los saldos cierran
en cero."

Claves: el caso ambiguo (DUDOSO, REVISAR A MANO) viaja por el contrato sin contaminar los cálculos; entre pasos vos revisás (especialmente las dudosas); y el paso 3 incluye su propia verificación. Advertencia honesta del cap. 5: aritmética sobre muchas filas es terreno resbaloso para un LLM — el paso 2 conviene verificarlo en una hoja de cálculo. La descomposición te da justo el punto donde hacer esa verificación.

Extraé los datos del texto y respondé ÚNICAMENTE con JSON válido.
- Sin texto antes ni después del JSON. Sin comentarios. Sin markdown.
- Usá EXACTAMENTE este esquema (claves y valores posibles):
{
  "nombre": "<string>",
  "fecha": "<YYYY-MM-DD o null si no aparece>",
  "categoria": "pago" | "deuda" | "otro",
  "monto_usd": <number o null>
}
- Si un campo no aparece en el texto, usá null (no lo omitás, no
  lo inventés).

<texto>
{{texto}}
</texto>

Los tres estabilizadores: "ÚNICAMENTE/sin texto antes ni después" (mata el "¡Claro!"), el esquema literal con tipos y enumeraciones (mata las claves creativas), y el null explícito (mata tanto los campos omitidos como los inventados — es la salida de escape en versión JSON).

Le sirve: con modelos sin razonamiento interno (pequeños/rápidos) en tareas de varios pasos (aritmética, lógica, planificación). Ahí el CoT clásico (Wei et al. 2022) sigue rindiendo.

Le es indiferente: con modelos razonadores modernos en tareas de razonamiento — ya lo hacen internamente y mejor; la frase no daña pero no aporta. Y en tareas sin razonamiento ("traducí esta frase"), no hay pasos que pensar.

Le juega en contra: (1) en tareas simples puede producir respuestas infladas — tres párrafos de "razonamiento" ceremonial para una traducción de una línea — más lentas de leer y, vía API, más caras; (2) lo peor: la frase le ocupa el lugar mental del trabajo real — cree que ya "optimizó" el prompt y no agrega lo que de verdad rinde con modelos modernos: claridad, contexto, ejemplos y criterios de éxito; (3) si lo que quiere es que el modelo siga el método del curso, "paso a paso" genérico le da el método promedio de internet, no el del profesor — debió dar los pasos él.

El prompt pide exactamente lo que recibió: "explicame... con ejercicios" = clase + solucionario. Si quiere practicar, las reglas deben invertir los papeles:

Sos un tutor socrático de cálculo. Vamos a practicar integrales por
partes. Reglas:
1. No expliqués el método todavía: dame UN ejercicio y dejame
   intentarlo. Yo te escribo mi desarrollo.
2. NUNCA resuelvas el ejercicio, aunque te lo pida. Si me trabo,
   pista mínima (¿qué elijo como u y como dv?), no el paso resuelto.
3. Si mi desarrollo tiene un error, señalá EN QUÉ LÍNEA está y
   preguntame qué pasa ahí — no me digas el error.
4. Cuando lo termine bien, subí la dificultad en el siguiente.
Mi nivel: ya sé derivar e integrar funciones básicas; por partes lo
vi una vez en clase.
Empezá con el primer ejercicio.

El problema: la rúbrica salió genérica porque la plantilla pedía porcentajes pero no descriptores por pregunta. Mejora al prompt original:

Para el problema de desarrollo, la rúbrica debe ser ESPECÍFICA de ese
problema, no genérica. Para cada criterio, escribí:
- qué debe contener una respuesta de puntaje completo (elementos
  concretos: qué ecuación, qué datos identificados, qué unidades),
- el error típico que haría perder ese criterio.

Ejemplo del nivel de detalle que quiero:
"Planteo (30%): identifica que es un problema de caída libre y
escribe v = gt con g ≈ 9.8 m/s². Error típico: usar la ecuación de
posición cuando piden velocidad."

Fijate la jugada: el ejemplo del nivel de detalle es few-shot aplicado a la rúbrica. "Rúbrica específica" descrito no funciona; mostrado, sí.

Falta: la entrada concreta que produce el problema, la salida obtenida, la salida esperada (¿qué es "raro"?), y el contexto de cómo lo llama. Reescritura:

Ayudame a depurar. Explicá la causa antes de corregir.

<codigo>
def promedio(notas):
    total = 0
    for n in notas:
        total += n
    return total / len(notas)

notas_juan = ["8", "7", "9"]   # vienen de input() en otra parte
print(promedio(notas_juan))
</codigo>

<error>
TypeError: unsupported operand type(s) for +=: 'int' and 'str'
</error>

<esperado>
Debería imprimir 8.0 (el promedio de 8, 7 y 9).
</esperado>

<contexto>
Python 3.12. Las notas las pide con input() y las guarda en una
lista. Con notas escritas directo como números [8, 7, 9] funciona.
</contexto>

Con el contexto completo, el diagnóstico es inmediato: input() devuelve strings; hay que convertir con int()/float() al leer (causa raíz), no dentro de promedio (parche al síntoma). La pista decisiva era "con números directos funciona" — información que el prompt original ni mencionaba.

Qué pasó: el modelo alucinó la cita — generó una frase plausible con el estilo del paper en vez de extraerla. Pasa especialmente con documentos largos, al parafrasear de memoria interna, o cuando el dato pedido no estaba y el modelo "completó" (la salida de escape no se activó).

Qué hacés con la ficha: desconfiar de TODA la ficha, no solo de esa cita — la verificación al azar existe porque una cita falsa detectada predice otras no detectadas. La ficha pasa de "fuente" a "borrador a verificar contra el original".

Qué cambiar: (1) en la plantilla: exigir ubicación precisa con cada cita (sección/página) — las citas con ubicación son más fáciles de verificar y el requisito mismo reduce la invención; (2) endurecer el escape: "si no encontrás una cita textual exacta, escribí PARÁFRASIS: y marcala como tal — nunca presentés una reconstrucción como cita"; (3) en el proceso: la verificación al azar de 2-3 citas se vuelve paso fijo del uso de la plantilla (anotalo en la ficha de la biblioteca), y este paper entra al set de casos de prueba del capítulo 5.

• a) System — regla estable de formato.
• b) Mensaje — la tarea puntual de hoy con sus datos.
• c) System — contexto estable del proyecto: no cambia entre sesiones y todas las respuestas deben conocerlo. (Es la gran ventaja de los Proyectos: el contexto de TU tesis se escribe una vez.)
• d) System — regla de comportamiento con salida de escape; de las más importantes para este caso de uso.
• e) Mensaje — es una excepción puntual ("hoy", "más que de costumbre") al tono por defecto. Si empezara a pedirse en cada sesión, sería señal de que el tono por defecto del system está mal calibrado y conviene actualizarlo.

Problemas: credenciales decorativas que no cambian comportamiento ("Harvard y MIT"); contradicciones sin resolver ("divertido pero serio", "exhaustivo pero conciso" — ¿cuál gana y cuándo?); "ayudas con todo" deshace la especialización (un buen system prompt recorta); cero reglas comprobables; cero salidas de escape; cero formato.

Reescritura:

# Identidad
Sos un tutor de estadística para estudiantes universitarios que la
ven por primera vez. Tu objetivo: que entiendan los conceptos, no
que aprueben copiando.

# Reglas
1. Priorizá brevedad: respuesta corta primero; ofrecé profundizar
   ("¿querés el detalle del cálculo?") en vez de darlo siempre.
2. Cada concepto nuevo lleva un ejemplo con datos pequeños (5-10
   números) que se puedan seguir a mano.
3. Si la pregunta es de tarea calificada, guiá sin dar el resultado
   final (modo socrático).
4. Si te preguntan algo fuera de estadística, redirigí en una frase.
5. Si un cálculo requiere datos que no te dieron, pedilos — no los
   supongás.

# Formato por defecto
Idea central (2-3 frases) → ejemplo numérico → "error típico" de ese
concepto en una línea.

# Tono
Cercano y claro. Términos técnicos siempre definidos al primer uso.

La tensión "exhaustivo pero conciso" quedó resuelta por una regla con mecanismo (regla 1: corto por defecto, profundidad a pedido) en vez de adjetivos enfrentados.

El bug está en el contrato entre eslabones: A rompió el formato de salida pactado y B procesó basura sin quejarse (basura entra, basura sale). Dos arreglos complementarios:

1. Endurecer la salida de A: "tu salida debe ser EXACTAMENTE una lista numerada con el formato [nombre | definición | depende de]. Sin párrafos introductorios ni texto fuera de la lista. Si los apuntes están demasiado desordenados para extraer un concepto con confianza, listalo como [nombre | REVISAR | -]" — el caso "entrada difícil" previsto dentro del contrato.
2. Validar en la entrada de B: "antes de armar el plan, verificá que la entrada sea una lista con el formato esperado. Si no lo es, no hagás el plan: respondé 'ENTRADA INVÁLIDA' y qué está mal." Un eslabón que rechaza entradas rotas vale más que uno que las procesa en silencio.

Y el cierre del capítulo 5: esos apuntes desordenados entran al set de casos de prueba de A. El fallo de hoy es el test de regresión de mañana.

Vas a responder preguntas sobre el texto de historia de abajo.

<texto>
[LAS 60 PÁGINAS]
</texto>

Preguntas:
1. ¿Cuáles fueron las causas del conflicto según el autor?
2. ¿El autor presenta contraargumentos a su propia tesis?

Instrucciones: primero extraé las citas textuales relevantes (con
capítulo/página), después respondé cada pregunta apoyándote solo en
ellas. Si algo no está en el texto, decilo.

Cambios: anuncio breve arriba; el documento al medio, etiquetado; las dos preguntas juntas, numeradas y DESPUÉS del documento (antes estaban una adelante y otra perdida al final, la peor combinación); extracción antes de respuesta; salida de escape. Es el ejercicio 4 del capítulo 4 en versión historia — porque este error es tan común que merece practicarse dos veces.

1. Formato: el examen tiene exactamente 5 opción múltiple + 3 cortas + 1 desarrollo, y la clave está en sección separada al final.
2. Contenido: toda pregunta es respondible con los apuntes provistos (verificación: para cada pregunta puedo señalar el fragmento del apunte que la responde).
3. Contenido/calidad: los distractores de opción múltiple son errores plausibles, no opciones absurdas (verificación: ninguna opción se descarta sin saber del tema).
4. Escape: con apuntes incompletos a propósito, las preguntas sobre lo faltante aparecen marcadas [VERIFICAR EN CLASE] en vez de inventadas.

El criterio 4 es el que casi nadie escribe y el que más protege: solo se puede probar dándole a la plantilla una entrada defectuosa adrede — por eso los sets de prueba llevan casos difíciles.

Errores: (1) entradas distintas (biología vs. química) — no compara las versiones, compara los capítulos; (2) mismo chat — la v2 corrió con el historial de la v1 en el contexto, contaminada; (3) "me pareció" sin criterios — juicio global de memoria, dos días después, sin nada verificable; (4) n=1 — un solo caso por versión; (5) borró la v1 — si la v2 resulta peor en otros casos, no hay vuelta atrás.

Protocolo corregido: mismos 4-6 casos para ambas versiones (los dos capítulos incluidos), conversaciones limpias separadas, criterios escritos antes, evaluación a ciegas (respuestas copiadas sin marcar de qué versión salieron), conteo de victorias por caso, y la v1 archivada en el historial de la ficha — no borrada.

Preparación: 8-10 respuestas de tu plantilla (mezclá buenas, regulares y malas — incluí 1-2 deliberadamente defectuosas como control: con una afirmación inventada, o pasada de longitud). Tus criterios medibles ya escritos.

Al juez (conversación limpia, idealmente modelo distinto del que generó): texto fuente + respuesta + criterios, formato CUMPLE/NO CUMPLE por criterio con evidencia textual, y "no premies la redacción: evaluá solo los criterios" (mitiga el sesgo de verbosidad). Una respuesta por conversación, para que no se influyan. Si además comparás pares de respuestas, evaluá cada par en los dos órdenes (mitiga el sesgo de posición; si el veredicto cambia con el orden, es empate).

En paralelo, vos evaluás los mismos casos con los mismos criterios, sin ver los veredictos del juez (a ciegas en ambas direcciones).

Decisión: coincidencia juez-vos por criterio. Umbral razonable: ≥80% de coincidencia global y que haya detectado las respuestas-control defectuosas (un juez que deja pasar la afirmación inventada queda descalificado, coincida lo que coincida en el resto). Si pasa: se adopta como primer filtro, con revisión humana de todo lo que apruebe "con dudas" y auditorías al azar cada tanto. Si no pasa: o se itera el prompt del juez (¡también es un prompt de tu biblioteca, con su ficha y sus casos!) o se evalúa a mano.

a) Es el prompt — falta la salida de escape para un caso previsible. La tarea tiene un hueco real (no toda librería tiene equivalente) y la plantilla no lo prevé, así que el modelo lo rellena inventando. Arreglo: "si una librería del original no tiene equivalente directo en {{destino}}, NO inventés un import: marcá [SIN EQUIVALENTE: nombre] y sugerí alternativas reales o el cambio de enfoque necesario". Ese código con librería exótica entra al set de casos.

b) Mezcla de contexto largo y arquitectura de la solución. En conversaciones muy largas, las instrucciones del inicio pierden peso frente al historial acumulado (cap. 4.6). Mitigaciones en orden: (1) si las reglas estaban en el primer mensaje y no en un system prompt/Proyecto, movelas ahí — las instrucciones de sistema resisten mejor; (2) sesiones más cortas: una conversación por tema (el hábito anti-"conversación eterna"); (3) un recordatorio periódico breve ("recordá: modo socrático") cuando la sesión deba ser larga.

c) Frontera tarea/prompt — pregunta de inferencia fina sobre contexto largo. "Qué opina A del trabajo de B" rara vez está dicho explícitamente: hay que localizar las citas a B y leer el tono — difícil para recuperación en contexto largo. Antes de culpar al modelo: descomponé (primero "extraé todos los pasajes donde se cita a B, textuales", después "con SOLO estos pasajes, ¿qué actitud muestra el autor?"). Si con la descomposición funciona, era el prompt (tarea demasiado implícita en un solo salto). Si ni así, el matiz quizás no está en el texto — y la respuesta honesta es la de escape: "el paper la cita pero no expresa una valoración clara". Forzar una opinión donde no la hay es pedirle al modelo que alucine.