Casos de uso aplicados

Casi todos los proyectos de IA que llegan a usarse de verdad toman una de cinco formas: un asistente que responde a clientes, un agenteAgente Sistema en el que un modelo, dentro de un bucle, elige la siguiente acción hasta decidir que terminó o alcanzar una condición de parada. que escribe código, un buscador de documentos internos, un pipeline que lee documentos y un agente que trabaja sobre sistemas en producción. Cada una trae su propia arquitectura y su falla típica, así que saber cuál tienes te dice mucho antes de escribir código.

Esta lección recorre las cinco como escenarios trabajados: qué construyes, qué falla primero y qué mides. Tres ideas las atraviesan a todas: una tarea sale bien cuando algo puede verificar los resultados de forma automática, una ganancia solo cuenta si mediste el punto de partida y los límites de seguridad se aplican fuera del modelo.

Los escenarios son casos compuestos, escritos para enseñar; no son reportes sobre empresas reales. Sus números describen la situación, nunca un resultado.

Un asistente de soporte que responde con tus políticas

Qué construyes. Un asistente que busca los artículos relevantes del centro de ayuda antes de responder y cita el que usó, una técnica llamada RAGRAG Retrieval-augmented generation: encontrar pasajes relevantes en tus documentos y agregarlos al prompt antes de que el modelo responda. (Embeddings y RAG). Antes de que la respuesta llegue al cliente, una validación la compara con esos artículos. Si no se sostiene, toma el control una persona en lugar de que el asistente adivine (Gobernanza y human-in-the-loop).

Qué falla primero. Marketing cambia el plazo de devolución, pero la copia en la que busca el asistente sigue teniendo el anterior, así que afirma con seguridad una política que ya no existe. Lo que dice es un compromiso de tu empresa, no el consejo de un tercero.

Qué mides. Respuestas respaldadas por una fuente citada, pases a una persona, tiempo de resolución contra tus números previos al lanzamiento y respuestas que alguien tuvo que corregir.

Lección. Mantener esa copia al día es parte del producto. 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, y los tests que ya existen pueden decidir si cada servicio sigue funcionando. Algo que juzga resultados de forma automática así se llama oráculo. Un harness, el programa que ejecuta al agente, toma un repositorio a la vez: el agente propone, los tests deciden y una persona revisa. El módulo de pagos es el caso malo: ningún test puede decir 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ó. Un equipo que nunca registró su punto de partida, su línea base, no puede distinguir una ganancia real del entusiasmo.

Qué mides. Tiempo por repositorio migrado, cambios aceptados sin retrabajo, defectos posteriores y tiempo de revisión, que suele subir mientras el de escritura baja.

Lección. La ganancia viene de la forma de la tarea, no del modelo. Donde hay un oráculo, los agentes escalan. Donde "correcto" 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, cada una con la respuesta que consideran correcta: el golden setGolden set Conjunto pequeño de entradas con respuestas aprobadas por expertos para decidir si un sistema está listo.. Después arregla cómo se leen y preparan los documentos, que es donde se decide casi toda la calidad. Un PDF exportado de diapositivas suele salir revuelto, y ningún promptPrompt Todo lo que se envía al modelo en una llamada: instrucciones, mensajes de la conversación y las definiciones de herramientas, si las hay. lo recupera. Combina la búsqueda por palabras clave con la búsqueda por significado para que los códigos de error exactos sigan apareciendo. Recién entonces compara modelos.

Qué falla primero. La primera versión pasa la demo y falla el golden set, casi siempre porque la búsqueda trae documentos plausibles pero equivocados. Sin el golden set, nadie lo notaría.

Qué mides. Precisión sobre el golden set, con qué frecuencia la búsqueda encuentra el documento correcto y cuánto tarda una ronda de evaluación. Una ronda de dos semanas nunca se corre dos veces.

Lección. Aquí la calidad se decide en la preparación de los documentos y en la evaluación. Ver Testing y evals para agentes.

Procesamiento de documentos

Qué construyes. Un pipeline de pasos, no un único prompt: el reconocimiento de texto (OCROCR Reconocimiento óptico de caracteres: convertir texto de imágenes o PDF escaneados en texto procesable.) convierte las imágenes en texto, el modelo extrae los campos a un formato fijo, código común aplica las reglas de negocio y una persona revisa el documento junto a los campos extraídos (El LLM como componente de software). Totales, impuestos y fechas van en código. Eso es aritmética, y un modelo que suma bien "casi siempre" 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, así que el documento se ve correcto a simple vista.

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. Quita la revisión humana campo por campo, a medida que los números de cada uno lo justifiquen, 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. Para confiar en esas sugerencias, reproduce incidentes pasados cuya causa ya se conoce y revisa con qué frecuencia la causa real entra en la lista corta; eso se llama backtestingBacktesting Evaluar un sistema con casos pasados ya resueltos para estimar cómo habría funcionado.. Solo después el agente actúa, con una credencial de permisos acotados, una lista de operaciones permitidas y un paso de aprobación para todo lo destructivo (Sandboxing y seguridad de agentes).

Qué falla primero. Alguien escribe "no toques producción" en las instrucciones del modelo y lo trata como una protección. No lo es. Una instrucción es un pedido; un límite de permisos se aplica fuera del modelo. Un agente con credenciales de producción tarde o temprano las va a usar.

Qué mides. Con qué frecuencia la causa real está en la lista corta, con qué frecuencia el agente culpa a la equivocada y cuántas acciones aprobó o rechazó una persona.

En la práctica

Para elegir un primer caso de uso:

• Elige una tarea frecuente, verificable y con dueño. Si nadie sabe cuál es la respuesta correcta, nadie puede evaluar el sistema.
• Empieza donde los errores son baratos o se detectan, con una persona revisando la salida, antes de ponerte frente al cliente.
• Arma los datos de evaluación y la línea base antes de elegir modelo. Un golden set escrito con tus expertos, junto con el tiempo de atención y la tasa de error de hoy, vale más que el mejor modelo.
• Define la salida. Decide de antemano cuándo el sistema pasa a una persona y cuándo lo apagas.

Para llevar

• Reconocer cuál de las cinco formas tienes te dice la arquitectura y el riesgo principal.
• Donde algo puede verificar los resultados de forma automática, los agentes escalan. Donde nada puede, mueven el trabajo hacia quien revisa.
• La empresa responde por lo que dice su sistema; un chatbot no es un tercero.
• Sugerir antes de actuar, y aplicar los límites de permisos fuera del modelo.

Comprueba lo aprendido