Lista de Verificación para Pruebas de LLM: Una Guía Previa al Lanzamiento

Air Canada perdió un caso judicial porque su chatbot inventó una política de reembolsos. El tribunal dictaminó que la aerolínea debía cumplir lo que el bot prometió. Klarna revirtió su estrategia de atención al cliente basada en IA después de que su chatbot ofreciera un servicio peor que el humano, y comenzó a reincorporar agentes. Ambas historias acapararon titulares porque el problema subyacente era el mismo: un modelo de lenguaje grande lanzado a producción sin el proceso de QA que la tecnología realmente necesita.

El patrón es generalizado. El informe 2025 State of AI de McKinsey encontró que el 78% de las organizaciones usa ahora la IA en al menos una función empresarial, pero solo alrededor de un tercio la ha escalado a nivel empresarial. La mayoría del resto ejecuta proyectos piloto que o bien se estancan en el desarrollo o se lanzan antes de estar listos, sin una forma estructurada de saber cuál de las dos está ocurriendo.

Esta lista de verificación para pruebas de LLM está diseñada para el segundo grupo. Cubre siete etapas previas al lanzamiento, los umbrales que separan “listo” de “aún no”, las herramientas que necesita cada etapa y los patrones de fallos que aparecen con mayor frecuencia en las pruebas de LLM para productos destinados a producción. Trátela como una revisión estructurada antes del lanzamiento.

Por Qué las Pruebas de LLM Rompen con los Supuestos Tradicionales de QA

El software tradicional es determinista. La misma entrada produce la misma salida, por lo que las aserciones de prueba pasan o fallan con claridad. Los modelos de lenguaje grande no se comportan así. Haga la misma pregunta dos veces y obtendrá dos respuestas válidas pero diferentes. Cambie una palabra en el prompt del sistema y el comportamiento posterior cambiará de formas que no puede predecir completamente.

Ese no determinismo transforma cómo realizar las pruebas de LLM de comportamiento. Se reemplazan las aserciones binarias por umbrales puntuados. Se mide con qué frecuencia el modelo se comporta correctamente, en lugar de si lo hace o no en una sola ejecución. Y se tienen en cuenta una nueva clase de fallos sobre los que el QA tradicional nunca tuvo que pensar: alucinaciones, inyección de prompts, jailbreaks, filtración de datos de entrenamiento, deriva de sesgos y regresiones silenciosas tras cada actualización del modelo.

El resultado es una disciplina de pruebas diferente, anclada a las métricas de evaluación de LLM que importan y a un alcance más amplio que la simple corrección funcional. La lista de verificación a continuación organiza esa disciplina en siete etapas que se apoyan entre sí.

La Lista de Verificación para Pruebas de LLM de 7 Etapas

Ejecute estas etapas en orden. Cada una produce una salida que la siguiente etapa necesita. Saltarse las primeras le costará caro después, cuando corregir un conjunto de datos defectuoso o reescribir un prompt del sistema cuesta diez veces más de lo que habría costado el primer día. Las siete etapas a continuación reflejan la secuencia que siguen la mayoría de los programas de evaluación de LLM destinados a producción, y escalan hacia arriba o hacia abajo según el nivel de riesgo.

Etapa 1: Defina su Contrato de Evaluación

Antes de escribir una sola prueba, documente tres cosas: el caso de uso, el nivel de riesgo y los umbrales aceptables para cada métrica que planea rastrear. Obtenga la aprobación de producto, ingeniería y QA en los tres. Sin este contrato, cada debate posterior sobre “¿es esto suficientemente bueno para lanzarlo?” se convierte en una opinión.

El nivel de riesgo es lo más importante. Un chatbot orientado al cliente puede tolerar una tasa de alucinaciones de alrededor del 5%. Un asistente médico o legal debe mantenerse por debajo del 1%. Elija el nivel primero, luego los umbrales seguirán. Puntos de partida comunes para implementaciones en producción:

• Fidelidad: 0.75 o superior en una escala normalizada de 0 a 1.
• Relevancia de la respuesta: 0.70 o superior.
• Toxicidad: 0.10 o inferior.
• Tasa de alucinaciones: 5% o inferior para uso general, 1% para contextos de alto riesgo.

El contrato se convierte en el criterio de aprobación. Si un modelo no supera algún umbral, no se lanza.

Etapa 2: Cree su Conjunto de Datos Dorado

El conjunto de datos es la base de todas las pruebas que siguen. Un conjunto de datos débil le da números que parecen sólidos pero que no significan nada en producción.

Para un lanzamiento básico, construya al menos 50 ejemplos. Para una evaluación de calidad de producción, apunte a 500 o más. La mejor fuente son datos de uso real, anonimizados y etiquetados. Si aún no los tiene, simule entradas representativas en tres categorías: casos normales que los usuarios encontrarán la mayor parte del tiempo, casos límite como escenarios poco frecuentes y entradas mal formadas, y entradas adversariales que incluyan intentos de jailbreak y prompts que violen el alcance.

Cuando los equipos preguntan cómo probar aplicaciones LLM sin antes construir un conjunto de datos dorado, la respuesta honesta es que no pueden. El conjunto de datos debe ser lo primero, aunque empiece pequeño, y debe crecer a medida que los registros de producción revelan nuevos patrones de fallos durante las primeras semanas de uso.

Etapa 3: Pruebe la Calidad de las Salidas

Aquí es donde comienzan la mayoría de los equipos, a menudo antes de lo que deberían. Las pruebas de calidad de salida cubren tres métricas que funcionan conjuntamente:

• Fidelidad mide si la respuesta del modelo se mantiene dentro del material fuente. Es innegociable para cualquier sistema RAG.
• Relevancia de la respuesta mide si la respuesta aborda realmente la pregunta del usuario. Una respuesta fiel puede seguir respondiendo a la pregunta equivocada.
• Tasa de alucinaciones mide con qué frecuencia las salidas contienen afirmaciones factualmente incorrectas, con umbrales que se ajustan a su nivel de riesgo.

Para las canalizaciones RAG, las pruebas de recuperación preceden a las pruebas de generación. El análisis del sector demuestra sistemáticamente que la mayoría de los fallos de RAG se originan en la recuperación, no en el propio modelo. Un conjunto práctico de herramientas de evaluación de RAG detecta las brechas de recuperación antes de que lleguen a las respuestas que ve el usuario.

Las herramientas que funcionan bien en esta etapa incluyen DeepEval, Ragas y G-Eval para la puntuación de LLM-como-juez. Planifique de una a dos semanas para esta etapa en un producto orientado al cliente.

Etapa 4: Pruebe Sesgos y Seguridad

Las pruebas de seguridad cubren dos superficies distintas. La puntuación de toxicidad detecta salidas dañinas, ofensivas o discriminatorias en el momento de la generación. Las pruebas de sesgo revelan diferencias sistemáticas en cómo el modelo trata a diferentes grupos demográficos, incluso cuando las respuestas individuales parecen correctas por sí solas.

Los escáneres automatizados detectan los casos obvios. La API Perspective de Google es un punto de referencia habitual para la toxicidad, y bibliotecas como AIF360 ayudan con los análisis de equidad demográfica. Pero las herramientas automatizadas pasan por alto daños sutiles y específicos del contexto, por eso el Marco de Gestión de Riesgos de IA del NIST y su Perfil de IA Generativa instan a combinar la evaluación automatizada con la revisión humana a lo largo del ciclo de vida de la IA. Los programas más sólidos combinan cada análisis automatizado con la revisión manual de 50 o más casos límite marcados para el juicio humano.

La presión de cumplimiento normativo refuerza ahora esta etapa. La Ley de IA de la UE exige que los sistemas de IA de alto riesgo documenten las pruebas de precisión, mitigación de sesgos y supervisión humana. Para los productos que operan en la UE, esta etapa ya no es opcional aunque antes se hubiera omitido.

Etapa 5: Ejecute Pruebas de Seguridad y Red Team

Los LLM introducen una superficie de ataque para la que las pruebas de seguridad tradicionales no fueron diseñadas. Los cinco vectores más comunes que hay que sondear antes del lanzamiento:

• Inyección directa de prompts, donde la entrada del usuario anula el prompt del sistema.
• Inyección indirecta de prompts a través de instrucciones maliciosas incrustadas en documentos recuperados, URLs o archivos subidos.
• Jailbreaks que utilizan juegos de rol, marcos hipotéticos o prompts al estilo DAN que eluden los filtros de seguridad.
• Intentos de extracción del prompt del sistema que revelan su plantilla y cualquier contexto sensible en su interior.
• Filtración de datos de entrenamiento mediante consultas elaboradas que extraen fragmentos del conjunto de entrenamiento del modelo.

Los escáneres automatizados como Garak y PyRIT cubren los patrones de ataque conocidos en la capa de entrada y salida. Son necesarios pero no suficientes. La inyección indirecta a través de contenido confiable y los exploits de herramientas encadenadas suelen necesitar red teamers humanos para ser descubiertos, ya que dependen de un contexto que el escáner no puede ver.

Para implementaciones en producción, complemente la línea base automatizada con servicios de pruebas de penetración centrados. Esta es la etapa donde más pierden los equipos que omiten la experiencia externa, ya que los ataques de mayor impacto a los LLM rara vez son los que figuran en la documentación.

Etapa 6: Valide el Rendimiento, la Latencia y el Costo

Las pruebas de rendimiento para productos impulsados por LLM van más allá de “¿la respuesta se siente rápida?”. Tres números son los más importantes. El tiempo hasta el primer token (TTFT) determina la velocidad percibida en las interfaces de streaming y debe estar por debajo de un segundo en el chat. La latencia total de la respuesta, especialmente la cifra p95, le dice más que el promedio sobre la experiencia real del usuario. El costo por solicitud debe rastrearse en la línea base y a diez veces el volumen de producción esperado, porque la arquitectura que gestiona 10 usuarios de prueba por doscientos dólares al mes se comporta de forma muy diferente con cincuenta mil sesiones concurrentes.

Aquí es donde los equipos que preguntan cómo probar los LLM bajo carga realista descubren que su arquitectura piloto no puede escalar. Las capas de caché, los modelos de respaldo, la limitación de velocidad y los balanceadores de carga modifican el perfil de latencia y costo en producción. Ejecute las pruebas de carga contra la arquitectura de producción, no el piloto.

Etapa 7: Consolide la Suite de Regresión y la Observabilidad

La etapa final es la que la mayoría de los equipos tratan como opcional, que es también la razón por la que implementan y luego se degradan silenciosamente. Cada actualización de prompt, cambio de modelo y modificación de la base de conocimiento puede romper lo que funcionaba ayer.

Integre las pruebas de todas las etapas anteriores en una suite de regresión que se ejecute en cada cambio, no en cada lanzamiento. Capture las puntuaciones de referencia para que las regresiones futuras sean visibles inmediatamente, en lugar de después de una queja de un cliente. Añada la observabilidad de producción antes del lanzamiento, no después del primer incidente. El rastreo, el registro de respuestas y las alertas de deriva deben estar en su lugar desde el primer día.

Las pruebas de regresión para productos impulsados por LLM son diferentes de la regresión tradicional. La suite es probabilística, los umbrales son puntuados y las comparaciones ocurren entre distribuciones en lugar de coincidencias exactas. Sin embargo, el principio es el mismo: detectar la regresión en CI, no en la captura de pantalla de un cliente en redes sociales.

Dónde Fallan las Pruebas de LLM Incluso con la Lista de Verificación

Una lista de verificación de pruebas de IA completa sigue dejando espacio para fallos predecibles. Tres patrones aparecen repetidamente en las revisiones previas al lanzamiento de productos impulsados por LLM.

Tratar la evaluación como un ritual de lanzamiento. Los equipos ejecutan la lista de verificación una vez, alcanzan sus umbrales, lanzan y archivan la suite. La primera actualización del modelo rompe silenciosamente la mitad de los logros, y nadie lo nota hasta que lo hace un usuario. La solución es hacer que la suite de regresión sea parte de cada implementación, no un hito que se marca y se olvida.

Probar el modelo de forma aislada. Un modelo que puntúa bien en un entorno de pruebas puede seguir fallando en producción porque la recuperación está rota, el prompt del sistema está desactualizado o una integración de herramientas aplica limitación de velocidad en el momento equivocado. La lista de verificación solo funciona cuando se aplica al stack integrado completo, incluida la capa de orquestación, la canalización RAG y cualquier API posterior a la que pueda llegar el modelo.

Omitir las pruebas adversariales porque el producto parece de bajo riesgo. Las herramientas internas también son objeto de jailbreak. Cualquier LLM conectado a datos reales, herramientas o entradas de usuario pertenece a la Etapa 5, independientemente de si su audiencia es un equipo o un millón de usuarios. El caso de Klarna es instructivo aquí. Un bot de soporte al que los usuarios engañaron para que escribiera Python no era una implementación de alto riesgo, pero las consecuencias reputacionales aún obtuvieron cobertura global.

De la Lista de Verificación al Lanzamiento

Una revisión de pruebas previa al lanzamiento suele durar de tres a seis semanas para un producto orientado al cliente. Las herramientas internas pueden lanzarse en una o dos semanas si el conjunto de datos está listo. Las implementaciones de alto riesgo en industrias reguladas suelen necesitar de seis a doce semanas para satisfacer la revisión de cumplimiento.

El flujo de siete etapas le da la estructura. Los umbrales le dan el criterio de aprobación. La suite de regresión y la capa de observabilidad le dan una manera de mantener lo que ganó a través de las pruebas. Lo que esta lista de verificación no puede darle es el tiempo que no presupuestó para las pruebas desde el principio.

Si está más cerca del lanzamiento de lo que le gustaría, contáctenos y le diremos qué etapas ejecutar primero según su cronograma. Los servicios de pruebas de LLM de QAwerk cubren la secuencia completa con ingenieros sénior con experiencia en evaluación previa al lanzamiento de LLM para producción.

FAQ

¿Cuál es la diferencia entre las pruebas de LLM y la evaluación de LLM?

La evaluación mide la calidad de las salidas frente a métricas definidas como fidelidad, relevancia de la respuesta y toxicidad. Las pruebas son el proceso más amplio que incluye la evaluación más las comprobaciones de seguridad, rendimiento, integración y regresión. La mayoría de los equipos de producción necesitan ambas, ejecutadas en secuencia, antes de lanzar un modelo de lenguaje grande en un contexto orientado al cliente.

¿Cuánto tiempo toman las pruebas de LLM?

Una revisión estándar previa al lanzamiento tarda de tres a seis semanas para un producto orientado al cliente. Las herramientas internas pueden lanzarse en una o dos semanas si el conjunto de datos está listo. Las implementaciones de alto riesgo en dominios médicos, legales o financieros suelen requerir de seis a doce semanas para cumplir con las expectativas regulatorias y de cumplimiento.

¿En qué se diferencian las pruebas de LLM de las pruebas de software tradicionales?

El software tradicional es determinista, por lo que las pruebas pasan o fallan según la coincidencia exacta de la salida. Los modelos de lenguaje grande producen salidas probabilísticas, lo que significa que la misma entrada puede devolver diferentes respuestas válidas. Las pruebas reemplazan las aserciones binarias por umbrales puntuados en precisión, seguridad, latencia y consistencia, y añaden una categoría completamente nueva de comprobaciones adversariales.

¿Qué herramientas se usan para las pruebas de LLM?

Las herramientas comunes incluyen DeepEval y Ragas para la calidad de salidas, Promptfoo para la regresión de prompts, Garak y PyRIT para la seguridad adversarial, LangSmith y OpenAI Evals para las canalizaciones de evaluación, y Guardrails AI para el cumplimiento de seguridad en tiempo de ejecución. La mayoría de los equipos de producción combinan tres o cuatro según su caso de uso y presupuesto.