Imagina esto: un cliente llama a tu agente de IA sobre un paquete de productos que se lanzo hace dos dias. Tu agente conoce cada SKU de los ultimos tres anos. Conoce tu politica de devoluciones al dedillo. Pero este paquete en particular? Nunca lo ha visto.
Lo que pasa despues depende enteramente de como esta construido tu agente.
Algunos agentes alucinaran una respuesta segura pero incorrecta. Algunos entraran en un bucle incomodo. Algunos diran elegantemente "dejame conectarte con alguien que pueda ayudarte con eso" y haran la transferencia limpiamente. La diferencia entre esos resultados no es suerte. Es arquitectura, diseno de prompts y si realmente has probado para esto.
Este es el problema zero-shot, y es mucho mas comun en produccion de lo que la mayoria de los equipos esperan.
Que significa realmente "Zero-Shot" para tu agente
Cuando decimos que un agente de IA esta manejando una solicitud "zero-shot", queremos decir que esta encontrando algo para lo que nunca fue preparado explicitamente (sin ejemplos de entrenamiento, sin entrada coincidente en la base de conocimiento, sin plantilla a la cual recurrir) y tiene que razonar desde cero usando su comprension general y cualquier contexto que le hayas dado.
El termino viene de la investigacion en machine learning, donde "zero-shot" describe a un modelo realizando una tarea sin ningun ejemplo especifico de la tarea. Para propositos practicos en agentes de IA en produccion, significa cualquier solicitud que no encaja en los patrones para los que tu agente fue construido y probado. Podria ser una pregunta sobre un nuevo producto, una queja con una formulacion inusual, una solicitud de multiples partes que abarca dos temas, o algo genuinamente inesperado que nadie anticipo.
La realidad incomoda: los escenarios zero-shot no son casos limite. Son la condicion predeterminada para cualquier agente que habla con clientes reales, porque los clientes reales son infinitamente creativos en como expresan sus necesidades.
Tres tipos de solicitudes Zero-Shot (y por que fallan de forma diferente)
No todas las solicitudes nuevas son iguales. Entender los modos de falla te ayuda a construir y probar de forma mas deliberada.
Intencion nueva: la pregunta que no anticipaste. Un cliente le pregunta a tu agente de IA de telecomunicaciones si su plan funcionara en un area remota especifica de Chile donde esta haciendo senderismo. Construiste el agente para manejar facturacion, cambios de plan y soporte tecnico. Roaming internacional? Algo asi. Pero la geografia especifica, el contexto de senderismo, la pregunta implicita sobre confiabilidad de senal versus solo "funciona el roaming"? Eso es nuevo. El agente o intenta responder con lo que sabe sobre roaming internacional (posiblemente incorrecto), o malinterpreta la intencion por completo.
Cambio de dominio: nuevo territorio, mismo agente. Tu empresa lanza una linea de productos de hardware. Tu agente de IA existente es excelente manejando preguntas sobre suscripciones de software. Ahora estas enrutando llamadas de garantia de hardware a traves del mismo agente. Es la misma empresa, las mismas politicas de servicio al cliente, pero un dominio completamente diferente. Los patrones de razonamiento del agente de un dominio pueden o no transferirse limpiamente al otro.
Colapso de contexto: cambios de tema a mitad de conversacion. Un cliente comienza con una pregunta de facturacion, la resuelves, y luego pregunta (casi como comentario al pasar) sobre una interrupcion del servicio en su area. La conversacion ahora es sobre algo completamente diferente, y el agente tiene que decidir si eso esta dentro del alcance, como manejar el cambio de contexto, y si realmente sabe algo util sobre el estado de la interrupcion. Este tipo de cambio a mitad de llamada es particularmente dificil porque los sistemas de enrutamiento y recuperacion de conocimiento del agente no estan construidos para eso.
Por que los agentes fallan en Zero-Shot (y que esta realmente pasando)
Cuando ves a un agente de IA tropezar con una solicitud nueva, generalmente esta pasando una de estas cosas bajo el capo.
El prompt de sistema es un guion, no un framework de razonamiento. Los agentes construidos con prompts altamente prescriptivos ("Si el cliente dice X, responde con Y") son esencialmente arboles de decision pretendiendo ser IA conversacional. Funcionan bien dentro de su alcance y se desmoronan completamente fuera de el. Un mejor enfoque es escribir un prompt de sistema que le de al agente una comprension genuina de su proposito, alcance y principios, para que pueda razonar sobre situaciones nuevas en lugar de hacer coincidencia de patrones contra una tabla de busqueda.
El comportamiento de respaldo no esta definido. La mayoria de los agentes estan disenados para el camino feliz. La pregunta que nadie hace es: que deberia hacer el agente cuando genuinamente no sabe? Si no has definido explicitamente el comportamiento del agente para solicitudes fuera de alcance (incluyendo cuando escalar, que decir y como preservar el contexto para el humano que tome el relevo), entonces el agente improvisara. Y los respaldos improvisados en agentes basados en LLM frecuentemente se ven como respuestas seguras, fluidas e incorrectas.
La base de conocimiento tiene toda la profundidad, pero ningun ancho. Un error comun es construir una base de conocimiento extremadamente detallada alrededor de temas conocidos mientras se deja espacio en blanco en todo lo demas. Cuando una consulta del cliente cae en ese espacio en blanco, el sistema de recuperacion no devuelve nada util, y el agente tiene que proceder sin fundamento. La solucion no es necesariamente agregar mas contenido. Es tambien incluir contenido explicito de "esto esta fuera de alcance" o "para preguntas sobre X, enrutamos a Y" que le da al agente algo con que trabajar cuando no tiene una respuesta directa.
El modelo no tiene el tamano adecuado para la tarea. Los modelos mas pequenos pueden ser excelentes para tareas estrechas y bien definidas. Pero la generalizacion zero-shot (razonar sobre algo que no has visto antes extrayendo de patrones amplios) tiende a favorecer modelos mas grandes y capaces. Si tu agente esta corriendo en un modelo pequeno y afinado optimizado para velocidad y costo, simplemente puede no tener la capacidad de razonamiento para manejar solicitudes nuevas con elegancia.
Como se ve un buen manejo Zero-Shot
El objetivo no es un agente que pueda responder cada pregunta posible. Eso no es realista, y probablemente requeriria un prompt de sistema del tamano de un libro de texto. El objetivo es un agente que maneje situaciones nuevas con elegancia, lo cual significa cosas diferentes en contextos diferentes.
Para un agente de servicio al cliente, un manejo zero-shot elegante generalmente se ve asi:
Reconocer que la solicitud esta fuera de su conocimiento confiable. Esto es mas dificil de lo que suena. Los LLMs tienen una tendencia bien documentada hacia la sobreconfianza. Un agente bien disenado deberia poder senalar la incertidumbre explicitamente en lugar de simplemente generar algo plausible.
Intentar una respuesta parcial util cuando sea posible. Si un cliente pregunta sobre un producto recien lanzado del que el agente no tiene detalles, podria razonablemente decir "No tengo detalles especificos sobre eso todavia, pero puedo contarte sobre nuestra politica de devoluciones y conectarte con un especialista para las preguntas del producto". Eso no es un exito zero-shot, pero tampoco es una falla.
Escalar con contexto preservado. Cuando el agente necesita transferir, no deberia simplemente dejar al cliente en una cola. Una buena escalacion significa resumir lo que el cliente ha pedido y lo que se ha intentado, para que el humano pueda continuar sin empezar desde cero.
El patron de pruebas de escenarios que se ajusta bien a esto es el adversarial: enviar intencionalmente a los agentes preguntas fuera de su alcance y evaluar no solo si obtuvieron la respuesta correcta, sino como manejaron el no saber.
Probar fallas Zero-Shot antes de que lleguen a produccion
Aqui esta el problema con la mayoria de las pruebas de agentes de IA: los equipos prueban los caminos que conocen. Escriben casos de prueba basados en las preguntas que esperan que los clientes hagan. Verifican que su agente pueda manejar disputas de facturacion, busquedas de pedidos y cambios de plan. Y luego lo lanzan.
La primera solicitud nueva de un cliente revela cada suposicion que hicieron.
Un mejor enfoque es disenar pruebas que sean deliberadamente adversariales, no hostiles, pero nuevas. El objetivo es encontrar los limites de la competencia de tu agente antes de que lo hagan los clientes.
Ataques de reformulacion. Toma una pregunta que tu agente maneja bien y reformulala de maneras que sean cada vez mas indirectas, coloquiales o inusuales. "Quiero cancelar mi suscripcion" es facil. "Necesito que esta cosa deje de cobrarme cada mes" es un poco mas dificil. "Ya estoy harto, solo haganlo parar". Que hace el agente con eso? Si no puede manejar la misma intencion expresada de forma diferente, eso es una brecha de cobertura.
Sondeos fuera de alcance. Haz preguntas explicitamente fuera del dominio de conocimiento de tu agente y evalua la respuesta. No para enganar al agente, sino para verificar que conoce sus propios limites. Un agente que responde con confianza preguntas que no deberia estar respondiendo es mas peligroso que uno que escala con demasiada frecuencia.
Solicitudes multi-intencion. Haz dos o tres cosas en un solo mensaje: "Puedes revisar mi saldo y tambien contarme sobre sus planes empresariales y tambien cual es la forma mas rapida de agregar una linea?" La mayoria de los agentes fueron construidos alrededor de llamadas de una sola intencion. Las solicitudes multi-intencion estresan la logica de enrutamiento y gestion de contexto.
Inyeccion de temas nuevos. Introduce algo en la conversacion para lo que el agente no fue disenado (un nuevo producto, una promocion inventada, un cambio de politica hipotetico) y observa como responde. Se inventa algo? Reconoce la brecha? Pide una aclaracion?
El sistema de scorecards de IA puede evaluar estos sistematicamente, marcando respuestas donde la respuesta del agente no abordo la intencion real, o donde dio una respuesta segura a una pregunta que deberia haber escalado.
La palanca del prompt engineering
De todas las cosas que puedes hacer para mejorar el rendimiento zero-shot, el prompt engineering tiene la mayor relacion entre impacto y esfuerzo. Esto es lo que realmente mueve la aguja.
Dale al agente una comprension genuina del alcance. En lugar de listar cada tema que deberia manejar, describe para que es el agente: el proposito, el cliente al que sirve, el resultado que esta tratando de lograr. Un agente que entiende "estoy aqui para ayudar a los clientes a resolver problemas de facturacion y preguntas de cuenta" puede hacer inferencias razonables sobre que cae dentro y fuera de ese mandato. Un agente al que le dieron una lista de 200 puntos que deberia manejar solo esta haciendo coincidencia de patrones.
Define lo desconocido explicitamente. Agrega una seccion a tu prompt de sistema que le diga al agente que hacer cuando no sabe. Algo como: "Si un cliente pregunta sobre algo fuera de tu conocimiento o alcance, reconoce que no tienes esa informacion, explica con que puedes ayudar y ofrece conectarlo con un especialista". Esto convierte un comportamiento indefinido en uno disenado.
Ensenale a expresar incertidumbre. Los LLMs por defecto dan respuestas seguras. Contrarresta esto explicitamente: dile a tu agente que es aceptable decir que no sabe, y dale lenguaje para hacerlo con elegancia. "No tengo esa informacion a la mano" es mejor que una respuesta incorrecta dada con conviccion.
Separa el conocimiento del comportamiento. Tu prompt de sistema deberia enfocarse en como el agente razona y se comporta. Tu base de conocimiento deberia ser donde pones lo que sabe. Mezclarlos (meter detalles de producto en el prompt de sistema) hace que ambos empeoren y hace que el manejo zero-shot sea mucho mas dificil de ajustar.
Monitorear fallas Zero-Shot en produccion
Incluso con buen prompt engineering y pruebas adversariales, algunas fallas zero-shot llegaran a produccion. La pregunta es si las detectas.
Las huellas de una falla zero-shot en una transcripcion de llamada son distintivas: el cliente pregunta algo, el agente responde con algo que suena relacionado pero no aborda la pregunta real, el cliente intenta de nuevo, el agente responde con algo ligeramente diferente pero aun fuera de tema, y eventualmente o el cliente se rinde o el agente escala. Toda la llamada se gasta en una no-respuesta.
Algunas cosas para monitorear:
Llamadas cortas con baja resolucion. Si una llamada termina rapidamente sin resolver el problema planteado, eso frecuentemente es una falla zero-shot. O el cliente se rindio, o el agente dijo algo que no tenia sentido y el cliente colgo.
Alta confianza, baja precision. Los scorecards de IA que evaluan si la respuesta del agente realmente abordo la intencion del cliente (no solo si sono bien) detectan estos. Una respuesta fluida y segura a la pregunta equivocada es peor que una respuesta cautelosa e incierta a la pregunta correcta.
Escalaciones con contexto escaso. Cuando un agente humano recibe una transferencia con un resumen minimo, esa es una senal de que el agente de IA no tenia un buen modelo de lo que realmente estaba pasando en la conversacion.
La capa de analitica y monitoreo importa aqui. No solo rastrear si las llamadas se resuelven, sino entender por que no lo hacen, y si las solicitudes nuevas son un contribuyente sistematico.
La realidad practica
El manejo zero-shot no es una funcionalidad que implementas una vez y la tachas de la lista. Es una propiedad continua de tu agente que se degrada a medida que tu producto evoluciona y mejora a medida que aprendes de las fallas en produccion.
Los equipos que lo manejan bien comparten algunos habitos: prueban de forma adversarial antes de cada cambio importante de prompt o base de conocimiento, monitorean transcripciones especificamente buscando respuestas fuera de intencion, y tratan la escalacion como una fuente de datos en lugar de solo un centro de costos. Cada escalacion te dice algo sobre lo que tu agente no sabe manejar.
Los equipos que lo manejan mal generalmente cometieron uno de dos errores: asumieron que probar los caminos felices era suficiente, o asumieron que un LLM capaz "simplemente lo resolveria" sin disenar el andamiaje de razonamiento explicitamente.
Tu agente encontrara solicitudes zero-shot. La unica variable es si lo has preparado para ellas.
Engineering Lead
Building the platform for AI agents at Chanl — tools, testing, and observability for customer experience.
Aprende IA Agéntica
Una lección por semana: técnicas prácticas para construir, probar y lanzar agentes IA. Desde ingeniería de prompts hasta monitoreo en producción. Aprende haciendo.
