El fallo no está en el LLM: cómo la arquitectura se disfraza de calidad del modelo

La experiencia al desplegar LLM en servicios al cliente ha revelado un patrón peligroso: cuando un LLM da una respuesta incorrecta, a menudo la culpa no es suya.

Demo frente a realidad

En la demo piloto, el sistema funcionaba a la perfección: el modelo respondía con soltura, el negocio veía avances y el equipo comparaba distintos LLM y ajustaba prompts. Luego llegaron usuarios reales, datos reales y limitaciones reales. Las respuestas se volvieron seguras de sí mismas, pero a veces erróneas.

La culpa no era del modelo

El equipo planeaba cambiar a un LLM más potente. Pero la revisión de los logs mostró que, en una parte de los diálogos, el modelo no debía responder en absoluto. El routing enviaba al usuario a la rama answer aunque la API devolvía una partial response, un caso en el que hace falta un handoff a una persona.

• El problema estaba en el enrutamiento, no en la calidad de la generación
• La API devuelve partial, así que el sistema debe derivar al usuario a soporte
• Pero el LLM recibía el partial como una respuesta completa y escribía una generación convincente pero errónea
• El modelo expresaba con elegancia los errores de la arquitectura

Dónde estaban los errores reales

Los bugs más caros no estaban en el LLM. Estaban en:

• El routing, que envía a los usuarios por ramas equivocadas
• Las integraciones de API, que no distinguen entre respuesta partial y full
• La lógica de handoff, es decir, cuándo pasar a una persona
• La base de conocimiento, con información desactualizada o incompleta
• La capa de compliance, es decir, el cumplimiento de las regulaciones
• Las métricas, es decir, qué se considera un error en primer lugar

El punto de inflexión

El cambio llegó cuando cambió la pregunta. En lugar de «¿Por qué el LLM respondió mal?», el equipo se preguntó: «¿Por qué el sistema puso al modelo en una situación en la que no podía existir una respuesta correcta?»

La conclusión es amarga: un LLM potente no compensa una arquitectura débil. Sin un routing decente, un responsable de la base de conocimiento y una lógica de handoff clara, comparar modelos suele convertirse en una costosa distracción. Es mejor dedicar el tiempo al sistema que a los prompts.