La mayoría de los equipos construyen recuperación de generación aumentada (RAG) para clasificación de alto riesgo hacen la misma apuesta arquitectónica: encaminar cada caso ambiguo directamente al modelo de lenguaje y confiar en el contexto recuperado para resolverlo. Esto funciona bien en una demostración. Se desmorona en el momento en que el sistema tiene que sobrevivir a una auditoría, a un regulador o a un funcionario de cumplimiento que pregunta por qué se tomó una decisión específica hace seis meses.
Pasé el último año construyendo sistemas de clasificación basados en RAG en entornos empresariales regulados, donde el costo de una respuesta incorrecta no es una mala respuesta de chatbot. Una decisión debe resistir el escrutinio mucho después de que el modelo la haya producido. Este entorno impone una filosofía de diseño diferente a la que asume la mayoría del contenido de ingeniería de IA.
Esto es lo que cambia cuando no puede permitirse el lujo de ser probabilístico en todo y cómo lo resuelve una arquitectura en cascada.
El costo invisible de un proceso completo de LLM
El atractivo de encaminarlo todo a través de un modelo de lenguaje grande (LLM) es obvio: menos piezas móviles, iteración más rápida, el modelo maneja casos extremos imprevistos. El problema aparece más tarde, en tres lugares.
Primero, la auditabilidad. «El modelo decidido en función del contexto recuperado» no es una respuesta aceptable. Necesita un camino de decisión que un ser humano pueda reconstruir sin volver a ejecutar la inferencia y esperar el mismo resultado.
En segundo lugar, el costo a escala. Si su sistema procesa decenas de miles de casos al día y cada uno de ellos recibe una llamada de LLM con varios documentos recuperados en contexto, su factura de inferencia y su latencia aumentan con el volumen de una manera que la lógica basada en reglas no lo hace.
En tercer lugar, y menos discutido, la deriva del modelo en los casos fáciles. Los LLM son excelentes para tomar decisiones matizadas. Son inconsistentes, de maneras difíciles de detectar, en casos que deberían tener una respuesta determinista. Una comparación clara y estructurada con criterios conocidos nunca debería depender del estado de ánimo de un modelo de lenguaje.
El enfoque en cascada
La solución: dejar de tratar el LLM como la primera línea y comenzar a tratarlo como el camino de escalada. En la práctica, esto significa un proceso de tres etapas.
La primera etapa es determinista. Las coincidencias exactas, las comparaciones de campos estructurados y cualquier cosa con una regla clara se resuelven aquí sin ninguna llamada de modelo. Esta etapa debería eliminar la mayor parte del volumen, a menudo más de la mitad dependiendo de la calidad de los datos, y cada decisión es completamente explicable porque es una búsqueda, no una inferencia.
La segunda etapa es donde la recuperación gana su sustento. Para los casos que sobreviven a la etapa uno, y me refiero a que sobreviven porque no se resolvieron claramente, se crea una capa de recuperación que extrae la evidencia específica relevante a la ambigüedad: decisiones previas de los revisores sobre casos similares, documentos contextuales que explican un conflicto aparente o un precedente histórico que aclara un caso límite. Aquí el paso de recuperación importa más que el paso de generación. Si recupera el contexto equivocado, incluso el mejor modelo de lenguaje del mundo producirá una respuesta equivocada, bien razonada y segura.
La tercera etapa es la convocatoria de maestríay solo debería ver el residuo que las etapas uno y dos no pudieron resolver. Esta es la parte que la gente omite cuando diseñan su primera versión, y es el factor más importante tanto en términos de coste como de calidad. En un sistema en el que trabajé, enrutar solo el 10 al 15% de los casos genuinamente ambiguos al LLM redujo el costo de inferencia aproximadamente 6 veces en comparación con una línea base de LLM, al tiempo que mejoró la coherencia en la mayoría determinista para perfeccionar efectivamente.
Diseño del aviso para riesgo asimétrico
Una vez que un caso llega a la etapa LLM, la mayoría de los equipos utilizan de forma predeterminada un mensaje neutral: «Evaluar si este caso debe aprobarse o marcarse». Ese marco es incorrecto para la clasificación de alto riesgo porque el costo de los dos tipos de error no es simétrico. Pasar por alto algo que realmente necesitaba atención puede significar un daño real en el futuro. Marcar incorrectamente algo que estaba bien le cuesta tiempo y retraso al revisor. Esos dos resultados rara vez son igualmente malos, pero un mensaje neutral le pide al modelo que los trate como si lo fueran.
Un aviso de riesgo asimétrico hace que esa compensación sea explícita para el modelo en lugar de permitirle adivinar su tolerancia al riesgo. Concretamente, esto significa instruir al modelo para que trate la incertidumbre como una razón para escalar en lugar de aclararla, proporcionar ejemplos calibrados de ambos tipos de error con sus consecuencias detalladas y solicitar una puntuación de confianza junto con la clasificación en lugar de una respuesta binaria. La puntuación de confianza se convierte en su segundo punto de cascada: cualquier cosa que esté por debajo de cierto umbral va a un revisor humano en lugar de resolverse automáticamente, sin importar lo que diga la clasificación del modelo.
Esto suena como un pequeño detalle de ingeniería. En la práctica, es la diferencia entre un sistema que reduce la carga de trabajo de los revisores y uno que aumenta silenciosamente el riesgo mientras parece que está funcionando.
Evaluar un sistema como este correctamente
Las métricas de evaluación estándar de RAG no se crearon teniendo en cuenta este caso de uso, y usarlas sin adaptación le dará una falsa sensación de confianza. Algunos ajustes que importan.
La calidad de la recuperación debe medirse por separado de la precisión de la clasificación final. Un sistema puede tener excelentes puntuaciones de clasificación de recuperación y aun así tomar malas decisiones finales si el paso de generación pondera mal la evidencia. Seguimiento de ellos de forma independiente.
Su conjunto de evaluación necesita un sobremuestreo deliberado de los casos que alcanzan la etapa tres, ya que ahí es donde realmente se prueba el juicio de su sistema. Si su conjunto de evaluación refleja su distribución de producción, estará dominado por los casos deterministas que su cascada ya maneja bien y no podrá ver exactamente las fallas que más importan.
LLM como evaluación de jueces funciona para este dominio, pero solo si el mensaje del juez codifica el mismo marco de riesgo asimétrico que su mensaje de producción. Un juez que trate ambos tipos de errores por igual favorecerá sistemáticamente la compensación incorrecta cuando ajuste su sistema.
Finalmente, cree un circuito de retroalimentación a partir de los resultados confirmados en su corpus de recuperación. Cuando un revisor humano anula una decisión modelo, ese caso y su resolución correcta deberían convertirse en un contexto recuperable para futuros casos similares. Sin esto, el manejo de casos ambiguos por parte de su sistema nunca mejora, simplemente sigue cometiendo la misma categoría de error al mismo ritmo.
La lección más amplia
El instinto de buscar el modelo más capaz para cada decisión es comprensible, pero en ámbitos donde las respuestas incorrectas tienen consecuencias reales, el trabajo de ingeniería más valioso es decidir qué es lo que nunca debería tocar el modelo. La arquitectura en cascada no es una solución alternativa para las limitaciones de LLM. Así es como se ve un sistema RAG maduro una vez que has tenido que defender sus decisiones ante alguien cuyo trabajo es encontrar el defecto en tu lógica.
Si está creando sistemas de IA para cualquier dominio regulado o de alto riesgo, la pregunta que vale la pena hacerse antes de escribir una sola pregunta no es «¿Cómo consigo que el modelo maneje esto bien?». Se trata de «qué partes de esta decisión nunca deberían haber sido trabajo del modelo en primer lugar».
Vineet Vijay es ingeniero líder en inteligencia artificial y aprendizaje automático.
¡Bienvenido a la comunidad VentureBeat!
Nuestro programa de publicaciones invitadas es donde los expertos técnicos comparten conocimientos y brindan análisis profundos neutrales y no adquiridos sobre inteligencia artificial, infraestructura de datos, ciberseguridad y otras tecnologías de vanguardia que dan forma al futuro de las empresas.
Leer más de nuestro programa de publicaciones de invitados y consulte nuestro pautas ¡Si estás interesado en contribuir con un artículo propio!
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.
