Los patrones de este curso aparecen casi siempre con las mismas formas: un asistente de soporte, un , búsqueda interna, procesamiento de documentos y un que toca producción. Esta lección recorre cinco de ellas como escenarios trabajados —el tipo de situación que te vas a encontrar— y muestra qué construyes, qué falla primero y qué mides.
Los escenarios son casos compuestos, escritos para enseñar; no son reportes sobre una empresa concreta. Cada número describe la situación (volumen de tickets, tamaño del equipo, plazo), nunca un resultado: cuánto ganas es justo lo que tienes que medir tú.
Un asistente de soporte que responde con tus políticas
Qué construyes. Ingesta del centro de ayuda, fragmentación e índice (Embeddings y RAG). Cada respuesta cita el artículo del que salió. Antes de llegar al cliente, una validación compara la respuesta con los artículos recuperados; si no se sostiene, la conversación pasa a una persona en lugar de a una suposición (Gobernanza y human-in-the-loop).
Qué falla primero. Marketing cambia el plazo de devolución y el índice sigue sirviendo el anterior, así que el asistente afirma con seguridad una política que ya no existe. Lo que dice tu asistente es un compromiso de tu empresa, no la sugerencia de un tercero: la exposición legal es la misma que la de una página equivocada en tu sitio.
Qué mides. Porcentaje de respuestas respaldadas por una fuente citada, tasa de escalamiento, tiempo de resolución contra la línea base que registraste antes de lanzar y cuántas respuestas tuvo que corregir un humano.
Lección. Reindexar es parte del producto, no mantenimiento, y "pasar a una persona" es una función que diseñas, no una salida que improvisas.
Agentes de código en un equipo que ya tiene código
Qué construyes. La migración es el caso bueno: el cambio es mecánico, la suite de tests es el oráculo y cada diff pasa por revisión. Un harness ejecuta el agente por repositorio, el agente propone el cambio y CI decide si es aceptable. El módulo de pagos es el caso malo: ningún test te dice si el agente entendió la regla de negocio.
Qué falla primero. Alguien reporta que "vamos mucho más rápido" por cómo se sintió. La percepción y la medición se separan en ambas direcciones, y un equipo que nunca registró una línea base no puede distinguir una ganancia real del entusiasmo.
Qué mides. Tiempo por repositorio migrado, proporción de diffs integrados sin retrabajo, defectos encontrados después del merge y tiempo de revisión, que suele subir aunque escribir baje.
Lección. La ganancia viene de la forma de la tarea, no del modelo. Donde hay un oráculo automático, los agentes escalan; donde el criterio de corrección vive en la cabeza de alguien, sobre todo mueven trabajo hacia quien revisa.
Búsqueda interna para un equipo de guardia
Qué construyes. Empieza por la evaluación, no por el modelo: pide a los expertos 100 preguntas reales con la respuesta que consideran correcta, el . Después arregla la ingesta, que es donde está casi toda la calidad: un PDF exportado de diapositivas se parsea como basura y ningún ajuste de lo recupera. Combina búsqueda por palabras clave con para que los códigos de error exactos sigan coincidiendo, y recién ahí compara modelos.
Qué falla primero. La primera versión pasa la demo y falla el golden set, casi siempre porque la recuperación trae documentos plausibles pero equivocados. Ese fallo es invisible si no armaste el golden set antes.
Qué mides. Precisión sobre el golden set, tasa de acierto de la recuperación y cuánto tarda una ronda de evaluación: si tarda dos semanas, no va a pasar dos veces.
Lección. La calidad de un se decide en la ingesta y en la evaluación. Ver Testing y evals para agentes.
Procesamiento de documentos
Qué construyes. Un pipeline, no un prompt: , luego extracción hacia un esquema, luego reglas de negocio en código y después revisión humana con el documento al lado de los campos extraídos (El LLM como componente de software). Totales, impuestos y formatos de fecha van en código: eso es aritmética, y un modelo que suma "casi siempre" bien es peor que uno que no lo intenta.
Qué falla primero. Los campos del encabezado (proveedor, fecha, total) salen bien y las líneas de detalle salen mal, que es la peor combinación: el documento se ve correcto de un vistazo y el error es silencioso.
Qué mides. Precisión por campo, no por documento. Un promedio del 95% por documento puede esconder un campo que se equivoca un tercio de las veces.
Lección. Mantén la revisión humana hasta que los números por campo justifiquen quitarla, campo por campo, nunca de todo el pipeline a la vez.
Un agente que actúa sobre producción
Qué construyes. Dos etapas. Primero el agente solo sugiere: reduce cientos de cambios recientes a las pocas causas más probables y el ingeniero decide. Recién cuando confías en eso puede actuar, y entonces con una credencial acotada, una lista de operaciones permitidas y una aprobación para todo lo destructivo (Sandboxing y seguridad de agentes).
Antes de confiar en las sugerencias, corre un : reproduce incidentes pasados cuya causa ya se conoce y mide con qué frecuencia esa causa aparece en la lista corta del agente.
Qué falla primero. Alguien escribe "no toques producción" en el prompt de sistema y lo trata como un control. No lo es. Un prompt es un pedido; un límite de permisos se aplica fuera del modelo, y un agente que tiene credenciales de producción tarde o temprano las va a usar.
Qué mides. Proporción de incidentes en los que la causa real está en la lista corta, tasa de falsos positivos y cuántas acciones aprobó o rechazó un humano.
Lección. Sugerir antes de actuar, y que el límite sea técnico. Ver Gobernanza y human-in-the-loop.
Cómo elegir entre patrones
| Patrón | Arquitectura típica | Riesgo principal | Lección |
|---|---|---|---|
| Soporte al cliente | RAG + validación + escalamiento | respuesta equivocada que compromete | gobernanza |
| Código | agente + tests + revisión | ganancia sentida, no medida | agentes de código |
| Búsqueda interna | ingesta + búsqueda híbrida + evals | mala ingesta, sin golden set | RAG |
| Documentos | OCR + extracción + reglas + humano | errores silenciosos por campo | LLM como componente |
| Operaciones | sugerir, luego actuar con permisos acotados | acciones destructivas | sandboxing |
Para CTOs
Para elegir el primer caso de uso:
- Tarea frecuente, verificable y con dueño. Si nadie sabe cuál es la respuesta correcta, no vas a poder evaluar.
- Error barato o atrapable. Empieza donde un humano revisa la salida —copiloto, extracción, búsqueda interna— antes de ponerlo frente al cliente.
- Datos de evaluación antes que modelo. Un golden set armado con tus expertos vale más que elegir el mejor modelo.
- Línea base medida. Registra primero el tiempo de atención y la tasa de error de hoy, o no vas a poder defender el resultado.
- Salida definida. Decide de antemano cuándo el sistema deriva a un humano y bajo qué condiciones lo apagas.
Para llevar
- Las mismas cinco formas cubren casi todo lo que se construye; reconocer la tuya ya te dice la arquitectura y el riesgo.
- Donde hay un oráculo automático, los agentes escalan; donde no lo hay, mueven el trabajo hacia quien revisa.
- La empresa responde por lo que dice su sistema: un chatbot no es un tercero.
- Los límites de permisos se aplican fuera del modelo; un prompt no es un control.
- Las cifras publicadas muestran que algo es posible, no lo que vas a obtener.
Comprueba lo aprendido
¿Por qué una migración de librería es mejor primer objetivo para un agente de código que una función del módulo de pagos?
Porque la migración tiene un oráculo automático: la suite de tests y CI deciden si el cambio es correcto. En el módulo de pagos el criterio de corrección está en las personas que conocen la regla de negocio, así que el trabajo del agente cae sobre quien revisa en vez de verificarse solo.
¿Por qué armar el golden set antes de elegir el modelo?
Porque sin él no puedes distinguir una respuesta buena de una plausible, y la primera versión suele fallar en la recuperación, no en el modelo. El golden set es lo que convierte una demo que "se ve bien" en una medición.
¿Por qué "no toques producción" en el prompt de sistema no es un control?
Porque es un pedido al modelo, no un límite que se aplica. El control es la credencial que tiene el agente y la lista de operaciones que puede ejecutar, y ambos se aplican fuera del modelo.