Nuestro sistema hizo una cosa, y lo hizo bien: convirtió preguntas en lenguaje natural en llamadas API.
Los usuarios incluían analistas, gerentes de cuentas y gerentes de operaciones. Sabían qué datos necesitaban, pero reunirlos manualmente implicaba aprovechar cuatro paneles, dos herramientas de BI y un generador de informes de Salesforce. Con nuestro sistema, escribieron la solicitud en inglés sencillo. Una consulta como «Compilar un informe sobre el volumen de ventas de enero a marzo de 2026 para la región Noreste, desglosado por ciudad» se tradujo en una llamada API sobre la que el sistema podía actuar:
json
{
«description»: «El usuario solicitó el volumen de ventas para el rango de fechas dado, aquí está la llamada API para obtener la respuesta»,
«api_call»: «/api/volumen_ventas»,
«post_body»: {
«start_date»: «01/01/2026»,
«end_date»: «31/03/2026»,
«región»: «noreste»
}
}
El resto del oleoducto era ingeniería convencional. El sistema envió la llamada al backend correcto (teníamos integraciones con portales de informes internos, Salesforce y varios servicios locales), aplicó un modelo de lenguaje extendido (LLM) (consulta JSON generada para filtrar y dar forma a la respuesta, y la entregó por correo electrónico, como un documento de Drive o se muestra como un gráfico en el navegador).
A mediados de 2025, el sistema generaba varios cientos de informes al mes. Estos informes fueron vistos por ejecutivos y analistas y distribuidos a partes interesadas externas. Se había convertido en la forma predeterminada para que la mayoría de los equipos extrajeran datos ad hoc.
El contrato entre el LLM y el resto del sistema era un objeto JSON estructurado como se describe en el ejemplo anterior.
json
{
«description»: «El usuario solicitó el volumen de ventas para el rango de fechas dado, aquí está la llamada API para obtener la respuesta»,
«api_call»: «/api/volumen_ventas»,
«post_body»: {
«start_date»: «01/01/2026»,
«end_date»: «31/03/2026»,
«región»: «noreste»
}
}
Lo creamos sobre Claude Sonnet 3.5 a principios de 2025. Actualizamos a 3.7 sin incidentes y a 4.0 sin incidentes. Cuando se lanzó Sonnet 4.5, nos habíamos vuelto complacientes con la estabilidad y previsibilidad de los LLM para resolver lo que pensábamos que era un problema simple. Las actualizaciones de modelos se habían vuelto rutinarias, como reemplazar una versión menor de una biblioteca que se comportaba bien.
Luego implementamos la versión 4.5. Para un porcentaje significativo de consultas, el modelo comenzó a integrar el contenido post_body en el campo de descripción. Siguieron dos modos de falla.
Primero, los parámetros del filtro nunca llegaron a la API. Nuestro sistema lee cuerpo_postal como fuente de verdad para la carga útil de la consulta y este campo resultó vacío. La llamada a la API se realizó sin un intervalo de fechas ni un filtro de región. Dependiendo de la API específica llamada, el backend devolvería el volumen de ventas de todos los tiempos o de todas las regiones, o devolvería un error 500.
En segundo lugar, el modelo comenzó a hacer preguntas aclaratorias en su respuesta. Era nuevo. Las versiones anteriores siempre adoptaban el mejor enfoque posible ante una solicitud ambigua y devolvían un objeto estructurado. Sonnet 4.5, siendo más cauteloso, respondía en ocasiones con una pregunta. Nuestro sistema no tenía medios para esto. Se construyó bajo el supuesto de que cada llamada al modelo daría como resultado una llamada a la API. No había ningún elemento humano en el circuito ni ningún estado que mantuviera una solicitud parcialmente completada. Esto provocó que los sistemas posteriores fallaran de varias maneras.
Volvemos a la versión 4.0. Esto fue más difícil de lo que debería haber sido: entre las implementaciones 4.0 y 4.5, nuestro equipo agregó nuevas integraciones de API, todas calificadas frente a 4.5. Revertir el modelo significó reclasificar cada uno de ellos frente a 4.0 bajo presión de tiempo.
¿Por qué la disciplina de ingeniería tradicional falla aquí?
La ingeniería de software se basa en la capacidad de limitar el efecto de un cambio. Cuando actualiza un controlador o una biblioteca, lee las notas de la versión para ver si debe esperar algún cambio significativo. Las pruebas unitarias delimitan lo que podría haber cambiado. Puede explotar la siguiente propiedad: el sistema que se está modificando es lo suficientemente determinista como para que su comportamiento pueda predecirse, o al menos muestrearse lo suficientemente denso como para darle confianza. El radio de explosión está limitado por la construcción.
Los sistemas respaldados por LLM rompen esta suposición. El componente que produce su resultado no está bajo su control. No puede actualizar una versión de plantilla de 4.0 a 4.5. Este es un reemplazo completo de las funciones de las que depende su sistema.
Esto es lo que entendemos por un radio de explosión infinito: un cambio cuyos efectos posteriores no se pueden enumerar de antemano porque el espacio de entrada (lenguaje natural) y los modos de falla (cualquier cosa que el modelo pueda hacer de manera diferente) son ilimitados.
Anatomía del fracaso
La autopsia reveló que nuestra indicación siempre había estado poco especificada. Le dijimos al modelo que devolviera un objeto JSON con tres campos. Habíamos descrito para qué servía cada campo. No hemos indicado explícitamente que la descripción debe ser una cadena en lenguaje natural y no debe contener representaciones serializadas de otros campos.
Las versiones anteriores del modelo dedujeron esta restricción del contexto. Sonnet 4.5, claramente más «útil» en sus opciones de formato, decidió que pedir una aclaración o proporcionar el cuerpo de la solicitud en la descripción hacía que la respuesta fuera más útil. Desde la perspectiva del modelo, ésta era una interpretación razonable de una instrucción ambigua. Sin embargo, esto viola los supuestos sobre los que se construyó nuestro sistema.
El error no estaba en el modelo. El error radicaba en nuestra suposición de que el modelo continuaría llenando nuestros vacíos de especificaciones como siempre lo ha hecho. Tres actualizaciones exitosas nos habían enseñado a creer que estas vulnerabilidades eran seguras.
Los modos de salida estructurados y las API de uso de herramientas habrían detectado esta falla específica a nivel de esquema. No los usábamos por razones de ingeniería fuera del alcance de este artículo. Pero los esquemas sólo restringen la sintaxis, no la semántica. Un esquema no puede especificar que una pregunta de aclaración no deba aparecer en un sistema sin una ruta de aclaración, o que un rango de fechas nunca deba ser permanente de forma predeterminada. Los esquemas resuelven la mitad más simple del problema.
Arquitectura basada en evaluaciones
La disciplina que llena este vacío es tratar el conjunto de evaluaciones –no el mensaje– como la especificación formal del sistema. El mensaje es un implementación de la especificación. El modelo es un intérprete. Las evaluaciones son la especificación en sí, y cualquier modelo o cambio rápido es válido si y solo si los aprueba.
En la práctica, una evaluación es un triple: un insumo, una propiedad que debe satisfacer el resultado y una función de puntuación. Para nuestro sistema, la evaluación que habría detectado la regresión 4,5 se parece a esta:
pitón
def test_description_contains_no_serialized_payload (respuesta):
desc = respuesta[«description»].más bajo()
prohibido = [«curl», «post_body», «{«, «http://», «https://»]
afirmar ninguno (token en la descripción del token prohibido),\
f»descripción del contenido estructurado divulgado: {respuesta[‘description’]}»
Unos cientos de estas propiedades, algunas escritas a mano para invariantes importantes conocidas, algunas generadas como pruebas de regresión a partir de tráfico de producción real, algunas calificadas por un LLM como juez de cualidades más confusas como el tono, se convierten en una puerta. Las actualizaciones de modelos y los cambios rápidos deben tratarse como solicitudes de extracción que deberían hacer que la suite reverdezca antes de fusionarse.
Las evaluaciones son costosas de construir y mantener. Van a la deriva a medida que evoluciona su producto. La puntuación de LLM como juez introduce su propia variación en los resultados. Y la suite solo puede detectar los modos de falla que pensó especificar: no puede evaluar su camino hacia la seguridad frente a una categoría de falla que nunca imaginó. Aprendimos esta lección de la manera más difícil: nadie en nuestro equipo había escrito nunca una afirmación de que «el campo de descripción no debería contener un comando curl», porque nadie había pensado que el modelo colocaría uno allí.
Las evaluaciones no son una panacea. Le brindan la capacidad de limitar el alcance de un cambio de la única manera disponible cuando la función subyacente es una caja negra: muestreando densamente la respuesta de entrada-salida que realmente le interesa y negándose a implementarla cuando ese comportamiento evolucione.
La hoja de ruta
La comunidad de ingenieros aún necesita desarrollar un conjunto de conocimientos para escribir reseñas efectivas. No existen estándares ampliamente aceptados sobre lo que significa «cobertura» en espacios de entrada de lenguaje natural. Los sistemas CI/CD no fueron diseñados para monitorear resultados de pruebas probabilísticas. A medida que los agentes asumen un trabajo más autónomo (escribir código, mover dinero, planificar cambios en la infraestructura), la brecha entre “el modelo pasó nuestras pruebas de humo” y “sabemos lo que hará este sistema en producción” se convierte en el problema central de ingeniería para los próximos años.
Los equipos que cierren esta brecha serán aquellos que dejen de tratar las evaluaciones como garantía de calidad a posteriori y comiencen a tratarlas como la verdadera especificación de su sistema.
Vijay Sagar Gullapalli es ingeniero de inteligencia artificial fundador de Adopt AI e inventor patentado por la USPTO.
Sarat Mahavratayajula es ingeniera de software senior en Sherwin-Williams.
¡Bienvenido a la comunidad VentureBeat!
Nuestro programa de publicaciones invitadas es donde los expertos técnicos comparten sus conocimientos y brindan análisis neutrales e imparciales en profundidad sobre inteligencia artificial, infraestructura de datos, ciberseguridad y otras tecnologías de vanguardia que están dando forma al futuro de los negocios.
Más información de nuestro programa de publicación de invitados y consulte nuestro pautas ¡Si quieres contribuir con tu propio artículo!
Suscríbete y recibe las historias más importantes del día.
Al suscribirte aceptas nuestros términos y condiciones y política de privacidad.
