La mayoría de los canales de RAG empresariales están optimizados para el comportamiento de sondeo. Fallan silenciosamente a los demás. Un modelo entrenado para sintetizar informes entre documentos no maneja bien la búsqueda de entidades basada en restricciones. Un modelo adaptado a tareas de investigación simples colapsa en un razonamiento de varios pasos sobre notas internas. La mayoría de los equipos se dan cuenta cuando algo se rompe.
Databricks decidió solucionar este problema con KARL, abreviatura de Agentes de conocimiento mediante aprendizaje por refuerzo. La empresa capacitó a un agente en seis comportamientos distintos de búsqueda empresarial simultáneamente utilizando un nuevo algoritmo de aprendizaje por refuerzo. El resultado, afirma la compañía, es un modelo que coincide con Claude Opus 4.6 en un punto de referencia especialmente diseñado con un 33% menos de costo por consulta y un 47% menos de latencia, entrenado completamente en datos sintéticos que el propio agente generó sin necesidad de etiquetado humano. Esta comparación se basa en KARLBench, que Databricks creó para evaluar los comportamientos de búsqueda empresarial.
“Muchas de las grandes victorias en el aprendizaje por refuerzo que vimos en la comunidad el año pasado se produjeron en tareas verificables en las que hay una respuesta correcta y una incorrecta”, dijo a VentureBeat Jonathan Frankle, científico jefe de inteligencia artificial de Databricks, en una entrevista exclusiva. “Las tareas que realizamos para KARL y que son normales para la mayoría de las empresas, no se pueden verificar estrictamente de la misma manera”.
Estas tareas incluyen sintetizar inteligencia a partir de notas de reuniones de gerentes de producto, reconstruir resultados comerciales competitivos a partir de registros de clientes fragmentados, responder preguntas sobre el historial de cuentas donde ningún documento tiene la respuesta completa y generar gráficos de batalla a partir de datos internos no estructurados. Ninguno de ellos tiene una única respuesta correcta que un sistema pueda comprobar automáticamente.
“Hacer aprendizaje por refuerzo en un mundo donde no hay respuestas estrictamente correctas e incorrectas, y descubrir cómo guiar el proceso y asegurarse de que no se produzca una piratería de recompensas, eso realmente no es trivial”, dijo Frankle. “Muy poco de lo que las empresas hacen en el día a día en tareas de conocimiento es verificable”.
La trampa de la generalización en el RAG corporativo
El RAG estándar se divide en consultas ambiguas de varios pasos basadas en datos internos fragmentados que nunca fueron diseñados para ser consultados.
Para evaluar a KARL, Databricks creó el punto de referencia KARLBench para medir el rendimiento en seis comportamientos de búsqueda empresarial: búsqueda de entidades basada en restricciones, síntesis de informes entre documentos, recorrido de documentos largos con razonamiento numérico tabular, recuperación exhaustiva de entidades, razonamiento procesal en documentación técnica y agregación de hechos en notas internas de la empresa. Esa última tarea es PMBench, construida a partir de notas de reuniones de los propios gerentes de producto de Databricks: fragmentada, ambigua y desestructurada de una manera que los modelos de frontera no manejan bien.
Entrenar en cualquier tarea y probar las demás produce resultados insatisfactorios. El artículo de KARL muestra que la RL multitarea se generaliza de una manera que el entrenamiento de una sola tarea no lo hace. El equipo entrenó a KARL con datos sintéticos para dos de las seis tareas y descubrió que se desempeñó bien en las cuatro tareas que nunca antes había visto.
Para crear una carta de batalla competitiva para un cliente de servicios financieros, por ejemplo, el agente tiene que identificar cuentas relevantes, filtrar por lo reciente, reconstruir acuerdos competitivos pasados e inferir resultados, ninguno de los cuales está etiquetado en ninguna parte de los datos.
Frankle llama a lo que KARL hace “razonamiento razonado”: ejecutar una cadena de razonamiento difícil mientras se ancla cada paso en hechos recuperados. “Puedes considerarlo como RAG”, dijo, “pero como RAG plus plus plus plus plus plus plus, hasta 200 llamadas a bases de datos vectoriales”.
El motor RL: por qué es importante OAPL
La capacitación de KARL está impulsada por OAPL, abreviatura de Optimal Advantage-based Policy Optimization with Lagged Inference. Es un nuevo enfoque, desarrollado conjuntamente por investigadores de Cornell, Databricks y Harvard y publicado en un papel separado Una semana antes de Karl.
El aprendizaje por refuerzo estándar de LLM utiliza algoritmos que tienen en cuenta las políticas, como la optimización de políticas relativas al grupo (GRPO), que suponen que el modelo que genera datos de entrenamiento y el modelo que se actualiza están sincronizados. En la formación distribuida, nunca lo son. Los enfoques anteriores corrigieron esto con un muestreo de importancia, introduciendo varianza e inestabilidad. En cambio, OAPL adopta la naturaleza fuera de política de la capacitación distribuida, utilizando un objetivo de regresión que permanece estable con retrasos de política de más de 400 pasos de gradiente, 100 veces más fuera de política que los enfoques anteriores abordados. En experimentos de generación de código, coincidió con un modelo entrenado por GRPO utilizando aproximadamente tres veces menos muestras de entrenamiento.
La eficiencia de la muestra OAPL es lo que mantiene asequible el presupuesto de formación. Reutilizar implementaciones recopiladas previamente, en lugar de requerir nuevos datos por política para cada actualización, significó que la ejecución completa de capacitación de KARL tomó unos miles de horas de GPU. Ésa es la diferencia entre un proyecto de investigación y algo que un equipo empresarial puede intentar de manera realista.
Agentes, memoria y pila de contexto.
En los últimos meses se ha debatido mucho en la industria sobre cómo se puede reemplazar RAG por memoria contextual, también llamada memoria de agente.
Para Frankle, no se trata de una discusión sobre esto o lo otro, sino más bien una discusión en capas. En la base se encuentra una base de datos vectorial con millones de entradas, que es demasiado grande para el contexto. La ventana de contexto de LLM está en la parte superior. Entre ellos se encuentran capas emergentes de compresión y almacenamiento en caché que determinan qué parte de lo que un agente ya ha aprendido puede llevar adelante.
Para KARL esto no es abstracto. Algunas tareas de KARLBench requirieron 200 consultas secuenciales a la base de datos vectorial, con el agente refinando las búsquedas, verificando detalles y haciendo referencias cruzadas de documentos antes de comprometerse con una respuesta, agotando la ventana de contexto muchas veces. En lugar de entrenar un modelo de resumen separado, el equipo permitió que KARL aprendiera la compresión de un extremo a otro a través de RL: cuando el contexto se vuelve demasiado grande, el agente lo comprime y continúa, siendo la única señal de entrenamiento la recompensa al final de la tarea. La eliminación de esta compresión aprendida redujo la precisión en un punto de referencia del 57% al 39%.
“Simplemente dejamos que el modelo descubra cómo comprimir su propio contexto”, dijo Frankle. “Y eso funcionó fenomenalmente bien”.
Donde KARL se queda corto
Frankle fue sincero acerca de los modos de falla. KARL tiene más dificultades con preguntas con una ambigüedad significativa, donde hay múltiples respuestas válidas y el modelo no puede determinar si la pregunta es genuinamente abierta o simplemente difícil de responder. Este juicio sigue siendo una cuestión sin resolver.
El modelo también muestra lo que Frankle describió como darse por vencido temprano en algunas preguntas: detenerse antes de producir una respuesta final. Se negó a calificar esto como un fracaso, señalando que las consultas más costosas suelen ser aquellas en las que el modelo falla de todos modos. Dejar de fumar es muchas veces la decisión correcta.
KARL también ha sido formado y evaluado exclusivamente en búsqueda de vectores. Las tareas que requieren consultas SQL, búsqueda de archivos o cálculos basados en Python aún no están dentro del alcance. Frankle dijo que estas características son las siguientes en la hoja de ruta, pero no están en el sistema actual.
Qué significa esto para los equipos de datos empresariales
KARL presenta tres decisiones que vale la pena revisar para los equipos que evalúan su infraestructura de recuperación.
La primera es la arquitectura del oleoducto. Si su agente RAG está optimizado para un comportamiento de búsqueda, los resultados de KARL sugieren que está fallando en otros. El entrenamiento multitarea sobre diversos comportamientos de recuperación produce modelos que se generalizan. Las tuberías estrechas no.
La segunda es por qué la RL es importante aquí – y no es sólo un detalle de capacitación. Databricks probó la alternativa: destilar modelos especializados mediante ajustes supervisados. Este enfoque mejoró el rendimiento de la distribución, pero produjo ganancias insignificantes en tareas que el modelo nunca antes había visto. RL desarrolló comportamientos de búsqueda generales que se transfirieron. Para los equipos empresariales que se enfrentan a datos heterogéneos y tipos de consultas impredecibles, esta distinción es fundamental. El tercero es lo que realmente significa en la práctica la eficiencia de RL. Un modelo entrenado para buscar mejor completa las tareas en menos pasos, se detiene antes en consultas que no puede responder, diversifica su búsqueda en lugar de repetir consultas fallidas y comprime su propio contexto en lugar de quedarse sin espacio. El argumento para capacitar a agentes de búsqueda específicos en lugar de enrutar todo a través de API de frontera de propósito general no tiene que ver principalmente con el costo. Se trata de construir un modelo que sepa cómo hacer el trabajo.
