La mayoría de los equipos que construyen sistemas de generación de recuperación aumentada (RAG) para clasificación de alto riesgo hacen la misma apuesta arquitectónica: enrutar cada caso ambiguo directamente al modelo de lenguaje y confiar en el contexto recuperado para ordenarlo. Esto funciona bien en una demostración. Colapsa tan pronto como el sistema tiene que sobrevivir a una auditoría, en la que un regulador o un responsable de cumplimiento 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 respuesta incorrecta del chatbot. Una decisión debe resistir el escrutinio mucho después de que el modelo la produzca. 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 darse el lujo de ser probabilístico en todo y cómo una arquitectura en cascada resuelve este problema.
El costo invisible de un proceso de LLM completo
El beneficio de enrutar todo a través de un modelo de lenguaje grande (LLM) es obvio: menos partes 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 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 por día y cada uno de ellos responde a una llamada de LLM con múltiples documentos recuperados en contexto, su factura de inferencia y su latencia aumentan con el volumen, a diferencia de la lógica basada en reglas.
En tercer lugar, y menos discutido, está la deriva del modelo hacia casos fáciles. Los LLM son excelentes para emitir juicios matizados. Son inconsistentes, de una manera que es difícil de detectar, en casos que deberían tener una respuesta determinista. La comparación clara y estructurada con criterios conocidos nunca debería depender del estado de ánimo de un modelo de lenguaje.
El enfoque de la 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.
El primer paso es determinista. Las coincidencias exactas, las comparaciones de campos estructurados y cualquier otra cosa con una regla clara se resuelven aquí sin necesidad de llamar a una plantilla. Este paso 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 investigación, no inferencia.
La segunda etapa es donde la recuperación entra en juego. Para los casos que sobreviven a la primera etapa (y me refiero a que sobreviven porque no se han resuelto claramente), se construye una capa de recuperación que extrae la evidencia específica relevante a la ambigüedad: decisiones de examinadores anteriores en casos similares, documentos de antecedentes que explican un conflicto aparente o un precedente histórico que aclara un caso límite. El paso de recuperación importa más aquí que el paso de generación. Si recupera el contexto equivocado, incluso el mejor modelo de lenguaje del mundo producirá una respuesta equivocada, segura y bien razonada.
El tercer paso es la llamada LLM y solo debería ver los residuos que los pasos uno y dos no pudieron resolver. Esta es la parte que la gente omite al diseñar su primera versión y es la mayor palanca en términos de costo y calidad. En un sistema en el que trabajé, enviar solo el 10-15% de los casos verdaderamente ambiguos al LLM redujo el costo de inferencia aproximadamente 6 veces en comparación con una línea base de todo el LLM, al tiempo que mejoró la coherencia en la mayoría determinista para un refinamiento eficiente.
Diseñar el 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 informarse». » Esta formulación es incorrecta para la clasificación de alto riesgo, porque el costo de los dos tipos de errores no es simétrico. Pasar por alto algo que realmente necesita atención puede provocar daños reales en el futuro. Informar falsamente algo que era correcto le cuesta tiempo y demora al evaluador. Estos dos resultados rara vez son tan malos, pero un mensaje neutral le indica al modelo que los trate como si lo fueran.
Un aviso de riesgo asimétrico hace que esta compensación sea explícita para el modelo en lugar de dejarlo adivinando sobre su tolerancia al riesgo. En términos prácticos, esto significa pedirle al modelo que trate la incertidumbre como una razón para escalar en lugar de una aclaración, proporcionar ejemplos calibrados de ambos tipos de errores con sus consecuencias explicadas 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 pasa a un evaluador humano en lugar de resolverse automáticamente, sin importar lo que diga la clasificación del modelo.
Parece un pequeño detalle de ingeniería rápido. En la práctica, ésta es la diferencia entre un sistema que reduce la carga de trabajo del evaluador y uno que silenciosamente aumenta el riesgo mientras parece funcionar.
Evaluar adecuadamente un sistema como este
Las métricas de evaluación estándar de RAG no se diseñaron para este caso de uso y usarlas sin adaptarlas 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 evalúa mal la evidencia. Síguelos de forma independiente.
Su conjunto de evaluación requiere un sobremuestreo deliberado de los casos que alcanzan la etapa tres, ya que aquí 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 estará ciego ante los mayores fracasos.
LLM como evaluación de juez 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 el compromiso incorrecto 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 continúa cometiendo la misma categoría de errores al mismo ritmo.
La lección más amplia
El instinto de buscar el modelo con mejor rendimiento para cada decisión es comprensible, pero en áreas donde las respuestas incorrectas tienen consecuencias reales, el trabajo de ingeniería más valioso es decidir qué es lo que nunca debe tocar el modelo. La arquitectura en cascada no es una solución alternativa a las limitaciones de LLM. Así es como se ve un sistema RAG maduro después de haber tenido que defender sus decisiones ante alguien cuyo trabajo es encontrar el defecto en su lógica.
Si está creando sistemas de inteligencia artificial para un dominio regulado o de alto riesgo, la pregunta que vale la pena hacerse antes de escribir una sola pregunta no es «¿Cómo puedo hacer que el modelo maneje esto correctamente?». Se trata de «qué partes de esta decisión nunca deberían haber sido trabajo del modelo en primer lugar».
Vineet Vijay es ingeniero senior de inteligencia artificial y aprendizaje automático.
¡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.
