Los modelos de lenguaje no solo cometen errores: fabrican realidad con total confianza. Un Agente de IA podría afirmar que creó registros de base de datos que no existen, o insistir en que realizó acciones que nunca intentó. Para los equipos que implementan estos sistemas en producción, esa distinción determina cómo solucionas el problema.
Dmytro Kyiashko se especializa en pruebas de sistemas de IA. Su trabajo se centra en una pregunta: ¿cómo detectar sistemáticamente cuándo un modelo miente?
El problema de probar disparates seguros
El software tradicional falla de manera predecible. Una función rota devuelve un error. Una API mal configurada proporciona una señal de falla determinista: normalmente un código de estado HTTP estándar y un mensaje de error legible que explica qué salió mal.
Los modelos de lenguaje fallan de manera diferente. Informarán que completaron tareas que nunca iniciaron, recuperarán información de bases de datos que nunca consultaron y describirán acciones que solo existen en sus datos de entrenamiento. Las respuestas parecen correctas. El contenido es fabricado.
"Cada Agente de IA opera según instrucciones preparadas por ingenieros", explica Kyiashko. "Sabemos exactamente qué puede y qué no puede hacer nuestro agente". Ese conocimiento se convierte en la base para distinguir las alucinaciones de los errores.
Si un agente entrenado para consultar una base de datos falla silenciosamente, eso es un error. ¿Pero si devuelve resultados detallados de consulta sin tocar la base de datos? Eso es una alucinación. El modelo inventó una salida plausible basada en patrones de entrenamiento.
Verificación contra la verdad fundamental
El enfoque de Kyiashko se centra en la verificación contra el estado real del sistema. Cuando un agente afirma que creó registros, sus pruebas verifican si esos registros existen. La respuesta del agente no importa si el sistema la contradice.
"Normalmente uso diferentes tipos de pruebas negativas, tanto unitarias como de integración, para verificar las alucinaciones de LLM", señala. Estas pruebas solicitan deliberadamente acciones que el agente no tiene permiso para realizar, luego validan que el agente no confirme falsamente el éxito y que el estado del sistema permanezca sin cambios.
Una técnica prueba contra restricciones conocidas. Un agente sin permisos de escritura de base de datos recibe indicaciones para crear registros. La prueba valida que no aparecieron datos no autorizados y que la respuesta no afirma éxito.
El método más efectivo utiliza datos de producción. "Uso el historial de conversaciones de clientes, convierto todo a formato JSON y ejecuto mis pruebas usando este archivo JSON". Cada conversación se convierte en un caso de prueba que analiza si los agentes hicieron afirmaciones que contradicen los registros del sistema.
Esto captura patrones que las pruebas sintéticas pierden. Los usuarios reales crean condiciones que exponen casos extremos. Los registros de producción revelan dónde los modelos alucinan bajo uso real.
Dos estrategias de evaluación
Kyiashko utiliza dos enfoques complementarios para evaluar sistemas de IA.
Los evaluadores basados en código manejan la verificación objetiva. "Los evaluadores basados en código son ideales cuando la definición de falla es objetiva y se puede verificar con reglas. Por ejemplo: analizar estructura, verificar validez JSON o sintaxis SQL", explica.
Pero algunas fallas resisten la clasificación binaria. ¿Fue apropiado el tono? ¿Es fiel el resumen? ¿Es útil la respuesta? "Los evaluadores LLM-as-Judge se usan cuando el modo de falla implica interpretación o matices que el código no puede capturar".
Para el enfoque LLM-as-Judge, Kyiashko confía en LangGraph. Ningún enfoque funciona solo. Los marcos efectivos usan ambos.
Lo que la capacitación clásica en QA pasa por alto
Los ingenieros de calidad experimentados luchan cuando prueban sistemas de IA por primera vez. Los supuestos que los hicieron efectivos no se transfieren.
"En QA clásico, conocemos exactamente el formato de respuesta del sistema, conocemos exactamente el formato de datos de entrada y salida", explica Kyiashko. "En las pruebas de sistemas de IA, no existe tal cosa". Los datos de entrada son un prompt, y las variaciones en cómo los clientes formulan solicitudes son infinitas.
Esto exige monitoreo continuo. Kyiashko lo llama "análisis continuo de errores": revisar regularmente cómo responden los agentes a los usuarios reales, identificar dónde fabrican información y actualizar los conjuntos de pruebas en consecuencia.
El desafío se agrava con el volumen de instrucciones. Los sistemas de IA requieren prompts extensos que definan comportamiento y restricciones. Cada instrucción puede interactuar de manera impredecible con otras. "Uno de los problemas con los sistemas de IA es la enorme cantidad de instrucciones que constantemente necesitan actualizarse y probarse", señala.
La brecha de conocimiento es significativa. La mayoría de los ingenieros carecen de una comprensión clara de las métricas apropiadas, la preparación efectiva de conjuntos de datos o métodos confiables para validar salidas que cambian con cada ejecución. "Hacer un Agente de IA no es difícil", observa Kyiashko. "Automatizar la prueba de ese agente es el desafío principal. Por mis observaciones y experiencia del usuario, se pasa más tiempo probando y optimizando sistemas de IA que creándolos".
Lanzamientos semanales confiables
Las alucinaciones erosionan la confianza más rápido que los errores. Una función rota frustra a los usuarios. Un agente que proporciona con confianza información falsa destruye la credibilidad.
La metodología de pruebas de Kyiashko permite lanzamientos semanales confiables. La validación automatizada detecta regresiones antes de la implementación. Los sistemas entrenados y probados con datos reales manejan correctamente la mayoría de las solicitudes de clientes.
La iteración semanal impulsa la ventaja competitiva. Los sistemas de IA mejoran al agregar capacidades, refinar respuestas y expandir dominios.
Por qué esto importa para la ingeniería de calidad
Las empresas que integran IA crecen diariamente. "El mundo ya ha visto los beneficios de usar IA, así que no hay vuelta atrás", argumenta Kyiashko. La adopción de IA se acelera en todas las industrias: más startups se lanzan, más empresas integran inteligencia en productos principales.
Si los ingenieros construyen sistemas de IA, deben entender cómo probarlos. "Incluso hoy, necesitamos entender cómo funcionan los LLM, cómo se construyen los Agentes de IA, cómo se prueban estos agentes y cómo automatizar estas verificaciones".
La ingeniería de prompts se está volviendo obligatoria para los ingenieros de calidad. Las pruebas de datos y la validación dinámica de datos siguen la misma trayectoria. "Estas ya deberían ser las habilidades básicas de los ingenieros de pruebas".
Los patrones que Kyiashko ve en toda la industria confirman este cambio. A través de su trabajo revisando artículos técnicos sobre evaluación de IA y evaluando arquitecturas de startups en foros técnicos, los mismos problemas aparecen repetidamente: los equipos en todas partes enfrentan problemas idénticos. Los desafíos de validación que resolvió en producción hace años ahora se están convirtiendo en preocupaciones universales a medida que se escala la implementación de IA.
Infraestructura de pruebas que escala
La metodología de Kyiashko aborda principios de evaluación, evaluación de conversaciones de múltiples turnos y métricas para diferentes modos de falla.
El concepto central: pruebas diversificadas. La validación a nivel de código detecta errores estructurales. La evaluación LLM-as-Judge permite la evaluación de la efectividad y precisión del sistema de IA según la versión de LLM que se esté utilizando. El análisis manual de errores identifica patrones. Las pruebas RAG verifican que los agentes usen el contexto proporcionado en lugar de inventar detalles.
"El marco que describo se basa en el concepto de un enfoque diversificado para probar sistemas de IA. Usamos cobertura a nivel de código, evaluadores LLM-as-Judge, análisis manual de errores y Evaluación de Generación Aumentada por Recuperación". Múltiples métodos de validación trabajando juntos detectan diferentes tipos de alucinaciones que los enfoques únicos pierden.
Lo que viene después
El campo define mejores prácticas en tiempo real a través de fallas de producción y refinamiento iterativo. Más empresas implementan IA generativa. Más modelos toman decisiones autónomas. Los sistemas se vuelven más capaces, lo que significa que las alucinaciones se vuelven más plausibles.
Pero las pruebas sistemáticas detectan fabricaciones antes de que los usuarios las encuentren. Las pruebas de alucinaciones no se tratan de perfección: los modelos siempre tendrán casos extremos donde fabrican. Se trata de detectar fabricaciones sistemáticamente y evitar que lleguen a producción.
Las técnicas funcionan cuando se aplican correctamente. Lo que falta es una comprensión generalizada de cómo implementarlas en entornos de producción donde la confiabilidad importa.
Dmytro Kyiashko es un Desarrollador de Software en Pruebas especializado en pruebas de sistemas de IA, con experiencia en la construcción de marcos de prueba para IA conversacional y Agentes de IA autónomos. Su trabajo examina los desafíos de confiabilidad y validación en sistemas de IA multimodales.
