IA en producción: RAG, eval y prompt injection

Existe un patrón previsible en los proyectos de IA: la demo funciona en dos semanas, y el producto no sale en seis meses.

No es falta de capacidad técnica. Es que la demo y el producto exigen cosas distintas, y las tres cosas que exige el producto son justamente las menos glamurosas.

Primera: recuperación que funciona#

Cuando un RAG responde mal, el instinto del equipo es cambiar de modelo. En la aplastante mayoría de los casos, el problema no es el modelo: es la recuperación.

Si el fragmento correcto no entró en el contexto, ningún modelo lo salva.

Las causas, en orden de frecuencia:

Chunking malo. Partiste por número fijo de caracteres y cortaste la tabla por la mitad, o separaste la pregunta de la respuesta. Parte por estructura (sección, párrafo) con algo de solapamiento. Y guarda el título de la sección junto al fragmento, porque el contexto del título es frecuentemente lo que hace comprensible el fragmento.

Búsqueda solo semántica. El embedding es malo con códigos de producto, números de factura, nombres propios y negaciones: "con intereses" y "sin intereses" quedan cerca porque los textos son casi idénticos.

La búsqueda híbrida (vectorial más BM25) es el cambio de mayor impacto que existe en RAG. Casi siempre le gana a cualquiera de las dos por separado, y es barata de implementar.

Falta de reordenación. Recupera veinte candidatos y pásalos por un reranker, un modelo menor entrenado específicamente para ordenar relevancia. Mejora mucho y cuesta poco.

Falta de metadatos. Sin filtro por fecha, producto o permiso, recuperas el documento revocado de 2019. Y, peor, puedes recuperar un documento que aquel usuario no tenía derecho a ver, lo que es una filtración con cara de funcionalidad.

El diagnóstico que ahorra semanas#

Cuando la respuesta venga mal, mira primero lo que se recuperó.

Si el fragmento correcto no estaba ahí → es recuperación.

Si estaba y el modelo lo ignoró → es prompt o modelo.

Dos situaciones completamente distintas, con soluciones completamente distintas. Sin separarlas, te pasas meses ajustando el prompt para un problema de búsqueda.

Segunda: evaluación#

Esta es la disciplina que separa el producto de la demo, y es la que casi nadie hace.

La pregunta es simple: ¿puedes responder, con un número, si el cambio que acabas de hacer mejoró o empeoró?

Si la respuesta es "probé tres preguntas a mano y pareció mejor", estás ajustando a ciegas.

Evaluar IA es distinto de probar software. No existe un pasa/falla determinista: existe una distribución de calidad medida sobre una muestra.

Cómo empezar, y es más simple de lo que parece:

Necesitas un conjunto de casos. Veinte ya te cambian la vida. Cien es cómodo.

De dónde sacarlos: de los logs reales, si tienes tráfico; de los casos que salieron mal, que son los más valiosos; y de las preguntas que recibe soporte. No inventes casos sintéticos bonitos: no se parecen a lo que hacen los usuarios.

Los tipos de verificación, del más barato al más caro:

Determinista. ¿La respuesta contiene el número correcto? ¿El JSON es válido? ¿El id existe en la base? Siempre que se pueda verificar con código, verifica con código: es gratis, rápido y no se equivoca.

Comparación con referencia. Cuando existe respuesta esperada. Para texto libre, usa similitud semántica en vez de igualdad literal.

Juez por modelo. Cuando el criterio es subjetivo.

Humano. Caro, e insustituible en una muestra pequeña para calibrar los demás.

Y el proceso: todo cambio de prompt, de modelo o de recuperación se ejecuta contra el conjunto, y comparas antes y después. Es el equivalente del CI para IA.

Usando un LLM como juez, sin engañarte#

Funciona, con cuidados que cambian el resultado.

Criterio específico y escala pequeña. "¿La respuesta está fundamentada solo en el contexto proporcionado? Sí o no" funciona mucho mejor que "dale una nota del 0 al 10". Las notas continuas acaban todas en siete u ocho.

Pide la justificación antes de la nota. El mismo efecto que razonar por pasos, y permite auditar.

Los sesgos son reales y están medidos: sesgo de posición, en el que el juez prefiere la primera o la última opción de una comparación, y que se corrige ejecutando en los dos órdenes; sesgo de verbosidad, en el que una respuesta más larga se considera mejor; y autopreferencia, en la que el modelo prefiere el texto generado por él mismo.

Y calíbralo contra humanos. Evalúa cincuenta casos a mano y mide la concordancia. Si es baja, tu juez está midiendo otra cosa, y tienes un número que parece objetivo y no lo es.

Tercera: observabilidad#

Una aplicación de IA es distribuida y no determinista. Sin trazas, no depuras.

Qué registrar en cada llamada: el prompt completo, incluido lo que se recuperó; la respuesta; el modelo y la versión; los parámetros; el número de tokens de entrada y salida; la latencia; el coste; y el identificador de correlación que lo une a la petición del usuario.

En un flujo agéntico, registra cada paso del bucle: qué herramienta, con qué argumentos, qué devolvió.

Por qué es innegociable: cuando un usuario se queje de una respuesta equivocada, la primera pregunta es "¿qué se recuperó?". Sin traza no puedes responder, y no vas a conseguir reproducirlo, porque no es determinista.

El panel mínimo por ruta: coste por día, latencia p95, tasa de error, distribución de tokens. El coste de IA crece en silencio, y la primera vez que la mayoría de los equipos lo mira es cuando llega la factura.

1. Recuperaciónel techo de la calidadSi el fragmento correcto no entró en el contexto, ningún modelo lo salva. La búsqueda híbrida es el cambio de mayor impacto.
2. Evaluaciónmedir el cambioVeinte casos reales ya te cambian la vida. Sin ellos, todo cambio de prompt es un ajuste a ciegas.
3. Observabilidadpoder depurarSin la traza de lo que se recuperó, no respondes a la queja ni reproduces, porque no es determinista.

Prompt injection: el problema sin solución#

La causa raíz es la misma que la de la inyección de SQL: instrucción y dato viajan por el mismo canal. La diferencia es que no existe consulta parametrizada para lenguaje natural.

La inyección directa es el usuario mandando "ignora las instrucciones anteriores". Relativamente fácil de mitigar.

La inyección indirecta es la peligrosa: el contenido malicioso está en un documento que tu RAG recupera, en una página que el agente lee, en un correo que procesa. El atacante nunca habló con tu sistema: plantó el texto donde el sistema iba a buscar.

Lo que ayuda, y ninguna de ellas es completa:

→ Delimitar claramente el contenido no confiable e instruir al modelo para tratarlo como dato.

→ Menor privilegio en la herramienta. El destrozo depende de lo que el agente pueda hacer.

→ Confirmación humana para acciones irreversibles.

→ Validar la salida con código antes de actuar.

→ Limitar el alcance: si el agente solo puede escribir en un borrador, la inyección no manda correos.

La regla mental: trata la salida del modelo como entrada de usuario no confiable.

Y el punto que más gente ignora: el riesgo no escala con la inteligencia del modelo. Escala con el privilegio que le diste.

Enseñar a decir "no lo sé"#

El comportamiento más valioso y menos implementado.

Cómo conseguirlo: instruye explícitamente ("si el contexto no contiene la información, responde que no la encontraste"); da ejemplos de rechazo en el few-shot, porque sin ejemplo el modelo no aprende el formato; exige cita, porque si toda afirmación tiene que apuntar a un fragmento, inventar se vuelve más difícil; y usa la puntuación de recuperación: si el mejor fragmento tiene similitud baja, ni llames al modelo.

Y mide la tasa de rechazo correcto como métrica de primera clase. El contrapunto importa: rechazar de más también es malo, y es el error que aparece cuando aprietas demasiado. Por eso es métrica, no regla.

Agentes: la matemática del error compuesto#

Si estás construyendo un agente, una cuenta que vale la pena interiorizar:

Un noventa por ciento de acierto por paso, en diez pasos, da un treinta y cinco por ciento de acierto al final.

Un agente largo es frágil por matemática, no por mala implementación. Las mitigaciones: menos pasos, verificación determinista entre ellos, límite de iteraciones, y checkpoint humano en los puntos caros.

Y sobre el multi-agente, una honestidad: en la mayoría de los casos, un agente bien instrumentado con buenas herramientas le gana a una orquesta. El multi-agente compensa cuando las subtareas son genuinamente independientes, o cuando quieres perspectivas distintas a propósito, como un crítico revisando a un autor.

Qué hacer esta semana#

Un ejercicio concreto y pequeño:

Monta veinte preguntas reales de tu dominio, con la respuesta correcta y el documento correcto anotados. Ejecuta tu sistema y mide cuántas veces el documento correcto apareció entre los recuperados.

Ese número es el techo de tu calidad. Ningún ajuste de prompt lo supera.

Y vas a descubrir, en la mayoría de los casos, que el problema nunca fue el modelo.