Entrada, procesamiento, salida y retroalimentación, lo que va en código y lo que va al modelo

Un pipeline toma cada adjunto de una casilla compartida, le pide a Claude que extraiga proveedor, monto y vencimiento, y lo carga en el ERP. A la semana aparecen facturas duplicadas y registros sin sentido, porque a la casilla también llegan remitos y newsletters. El equipo agrega al prompt “ignorá duplicados y lo que no sea factura”. Los duplicados siguen: el modelo nunca vio los mails anteriores. El problema no era el prompt; era que el diseño tenía una sola etapa.

Las cuatro etapas

Una arquitectura de punta a punta (end-to-end architecture) tiene cuatro partes, y el examen espera que detectes cuál falta:

Etapa	Qué resuelve	Ejemplos
Entrada	Que al modelo le llegue lo que corresponde, limpio	Deduplicar, clasificar y descartar, normalizar formatos, quitar datos sensibles
Procesamiento	El trabajo que necesita lenguaje o criterio	Extraer, resumir, clasificar, redactar
Salida	Que lo que sale sea usable y seguro	Validación de esquema, reglas de negocio, ruteo a revisión humana
Retroalimentación	Saber qué pasó con cada salida	Qué se aceptó, qué se corrigió, qué se descartó

Lo que va en código, no en el prompt

La regla: si se puede resolver con un control determinista (deterministic check), va en código, en la etapa de entrada o de salida. Una instrucción en el prompt es una sugerencia; el código se cumple siempre.

• Duplicados: un hash del archivo o el número de factura contra lo ya registrado. El modelo no tiene ese historial, ningún modelo lo tiene.
• Lo que no corresponde: un clasificador previo (puede ser un modelo chico) que separa facturas de remitos antes de extraer, con su propia métrica de error.
• Formato: pedí una salida estructurada (structured output) y aplicá una validación de esquema (schema validation) antes de cargar nada. Si no pasa, se reintenta o va a una cola de revisión, nunca directo al sistema.
• Reglas de negocio: montos fuera de rango, fechas imposibles o totales que no suman se verifican en código.

Esto también decide dónde poner a las personas. Mandar cada registro a aprobación manual con 2.500 adjuntos por semana elimina el beneficio; mandar solo lo que falla una validación o cae debajo de un umbral pone la revisión donde está el riesgo.

Sin retroalimentación no hay mejora

El circuito de retroalimentación (feedback loop) es la etapa que más se olvida. Un asistente que sugiere cambios a contratos puede funcionar meses sin que nadie sepa qué sugerencias aceptan los abogados, porque sus ediciones quedan en el sistema documental. Entonces los prompts se cambian por anécdotas del socio que más se queja, y nadie puede decir si un cambio mejoró o empeoró.

Para cerrar el circuito:

1. Capturá la reacción a cada salida: aceptada, editada (y cómo), descartada.
2. Guardala con la versión del prompt y del modelo que la generó.
3. Usala para alimentar el set de evaluación y priorizar qué arreglar (por tipo de cláusula, por categoría).
4. Compará cada cambio contra esos datos antes de lanzarlo.

Lo que no conviene es saltar a un modelo más grande, traer más contexto o sumar otra llamada que “mejore” la salida sin tener esos datos: es optimizar a ciegas.

Las trampas típicas

• Pedirle al modelo que detecte duplicados o filtre basura que solo se puede detectar con datos que no ve.
• Reforzar el prompt con más ejemplos después de que la instrucción ya falló por diseño.
• Cargar al sistema destino sin validar el esquema “porque el modelo casi siempre responde bien”.
• Humano en todo para compensar una entrada sin filtros.
• Diseñar entrada, procesamiento y salida, y dejar la retroalimentación para “una segunda fase”.
• Cambiar de modelo o sumar un paso de reescritura cuando nadie sabe qué salidas fallan.

En el examen

Leé el escenario buscando la etapa ausente. Si el problema aparece porque al modelo le llega lo que no debería (duplicados, documentos ajenos), la respuesta es una etapa de entrada con controles en código. Si las salidas llegan mal formadas a otro sistema, es validación en la salida. Si el equipo “no sabe qué falla” o mejora por anécdotas, falta el circuito de retroalimentación. Desconfiá de las opciones que resuelven todo dentro del prompt o con un modelo más capaz.