Un clasificador de servicios con LLM pasó del 73% al 94%, pero una cadena de tres nodos sigue dando un 75%

Cualquier equipo que haya lanzado un LLM a producción conoce esta decepción. En el conjunto de prueba el modelo da un 98%, pero con datos reales sale un 73%. El autor del análisis en Habr considera que en producción rara vez se consigue una calidad del sistema completo superior al 90%. Por eso conviene tomar esa cifra como referencia. Algunos proyectos, por el alto coste del error, sencillamente no saldrán adelante.

La tarea: 50 clases y un único catálogo

El ejemplo proviene de un trabajo real. A partir del nombre de un servicio hay que elegir el código para el formulario 402. La clasificación es plana, con 50 clases, y cada tipo de servicio corresponde exactamente a un código. Por ejemplo, «842 — Desarrollo e instalación de software» o «7123 — Transporte de mercancías por carretera». La tarea parece sencilla, pero permite ver cómo se comporta un solo nodo.

El primer instinto es seguir añadiendo excepciones al prompt. Así el prompt se infla y aparecen tres problemas. Primero, el modelo puede «perder» parte de un contexto largo: la información está en la entrada, pero no en la respuesta. Segundo, si en un mismo prompt hay decenas de tareas distintas (por ejemplo, extraer 50 atributos, y solo para el importe ya hay un párrafo entero de reglas), algunas reglas se pierden. Tercero, aparece un análogo del sobreajuste: se ajusta el prompt al mismo benchmark y este memoriza los ejemplos en lugar de la regla general. Se detuvieron en 8 ejemplos y obtuvieron un 81%.

Qué mejoró realmente la calidad del nodo

El autor descarta la división ingenua del catálogo por la mitad. Se obtendrían dos candidatos y haría falta un tercer paso para elegir un solo código. Es un nuevo lugar donde pueden aparecer errores.

Lo que ayudó fue revisar los logs y hablar con el negocio. Resultó que en un mismo documento puede haber varios servicios. El nodo anterior los escribía en una sola línea, y el LLM elegía un código, mientras que los demás servicios se perdían. La corrección: extraer los servicios como lista, pasar cada uno por separado con el contexto necesario del documento y reunir el resultado con un código para cada uno. La calidad subió al 89%. El problema estaba en el planteamiento de la tarea, no en el modelo.

El siguiente paso son los ejemplos dinámicos. A partir del benchmark etiquetado se construye una tabla «vector del nombre del servicio — clase». Para un servicio nuevo se buscan los similares y se insertan en el prompt junto con los códigos correctos. Se obtuvo un 94%. No se puede llegar al 100%: la tabla está incompleta y los vectores a veces coinciden de forma falsa, de modo que al prompt llegan ejemplos inadecuados.

Cadenas: la calidad se multiplica

La idea principal de la segunda mitad del artículo: en una cadena de llamadas, la calidad final es el producto de la calidad de los pasos. Un ejemplo de un centro de contacto. La reformulación de la pregunta funciona al 95%, la búsqueda RAG en la base de conocimiento al 80% y la respuesta final al 99%. Total: 0,95 × 0,80 × 0,99 = 75%. El cálculo solo es honesto sobre un único conjunto de datos fijo: no se puede medir cada eslabón en su propio conjunto y luego multiplicar.

La tentación es comprensible: añadir una orquestación con una lista de exclusión de preguntas problemáticas. En efecto, descarta una parte de los casos y el RAG funciona mejor con el resto, digamos al 89%. Pero el propio orquestador también se equivoca, por ejemplo en un 5% de los casos. Resultado: 95% × 95% × 89% × 99% ≈ 79,5%. Hay mejora, pero pequeña, y el sistema se ha vuelto más complejo. No se volvió perfecto: la cadena ganó un paso más con su propio error.

Qué hacer en la práctica

• Mida la calidad con datos realistas, no solo con el benchmark interno. Una brecha del 98% al 73% es un escenario típico.
• Antes de complicar el prompt, revise los logs y hable con el negocio. Parte de los «errores del modelo» resultarán ser errores en el planteamiento de la tarea o en el paso anterior.
• Divida la tarea por significado (un servicio, una llamada), no de forma mecánica.
• Calcule la cadena de antemano: tres pasos al 90% dan alrededor del 73%.
• Si el coste del error es alto, incluya a una persona en el circuito. No conviene esperar un 100% de un sistema con LLM.

Limitaciones

Las cifras proceden de un solo caso del autor, en el que modificó los datos de partida conservando el sentido general. No hay verificación independiente, y el tamaño de la mejora de cada técnica depende de los datos. Pero la lógica es universal: la calidad del sistema la determinan el eslabón más débil y el número de pasos, y es mejor asumir desde el principio la referencia del 90%.