¿Cuándo debería una IA dejar de confiar en su propio conocimiento? — El desencadenante de la recuperación

Pregunta

¿Cuándo debería una IA dejar de confiar en lo que ya sabe y recuperar información externa antes de responder?

Esta pregunta parece simple, pero se sitúa en el centro de una de las decisiones de diseño más importantes en los sistemas de IA modernos.

Los grandes modelos de lenguaje contienen un conocimiento sustancial en sus parámetros. La Generación Aumentada por Recuperación añade información externa en tiempo de ejecución. Pero ninguno de los extremos es ideal.

Confiar siempre en el modelo puede producir respuestas desactualizadas o sin respaldo. Recuperar información siempre añade latencia, costo, contexto irrelevante y nuevas oportunidades para errores de recuperación.

El verdadero problema, por lo tanto, viene antes de RAG: ¿Cuándo debería ocurrir la recuperación en absoluto?

Este artículo utiliza el término Disparador de Recuperación para esa decisión. El Disparador de Recuperación no se presenta aquí como un término estandarizado de la literatura de investigación. Es un concepto práctico de sistemas que reúne ideas ya visibles en la investigación sobre recuperación activa, adaptativa y autorreflexiva.

Un Disparador de Recuperación es una condición que indica que un sistema de IA debería dejar de confiar únicamente en el conocimiento interno del modelo y obtener evidencia externa antes de producir o finalizar una respuesta.— Definición de trabajo

Qué significa esto realmente

Un LLM tiene dos formas fundamentalmente diferentes de obtener información.

La primera es el conocimiento del modelo. Esta es información representada en los parámetros aprendidos del modelo. No se requiere ninguna consulta a base de datos, búsqueda web o búsqueda de documentos en tiempo de ejecución.

La segunda es el conocimiento en tiempo de ejecución. Esta es información proporcionada mientras el modelo está operando: resultados de búsqueda, registros de bases de datos, documentos, APIs, archivos de usuario, salidas de herramientas u otra evidencia recuperada.

RAG conecta estos dos mundos. Pero RAG en sí mismo no responde a la pregunta de cuándo debería activarse esa conexión. Ese es el propósito del Disparador de Recuperación.

Question
   ↓
Model Knowledge
   ↓
Is internal knowledge sufficient?
   ↓
Retrieval Trigger
   ↓
External Retrieval, if required
   ↓
Evidence
   ↓
Reasoning
   ↓
Answer Validity Boundary
   ↓
Answer

El Disparador de Recuperación, por lo tanto, se sitúa antes de la recuperación. El Límite de Validez de la Respuesta se sitúa después.

El primero pregunta: ¿Necesito evidencia externa?

El segundo pregunta: ¿Tengo ahora suficiente evidencia para respaldar esta respuesta?

Estas son decisiones relacionadas, pero no son la misma decisión.

Ejemplo más simple

Considera tres preguntas.

La primera pregunta se basa en un hecho altamente estable.

User
↓
"What is the capital of France?"

Model knowledge
↓
Paris

Fresh external evidence required?
↓
No

Answer
↓
Paris

Recuperar documentos antes de responder normalmente añadiría poco valor.

Ahora considera una pregunta cuya respuesta cambia continuamente.

User
↓
"What is the current NVIDIA stock price?"

Model knowledge
↓
Potentially outdated

Current information required?
↓
Yes

RETRIEVAL TRIGGER
↓
Market data / search / API
↓
Answer

El modelo puede saber mucho sobre NVIDIA. Eso no significa que sepa el precio ahora.

El tercer ejemplo es aún más importante.

User
↓
"Does this new scientific paper prove that X causes Y?"

Model knowledge
↓
Can reason about causality,
statistics and scientific methodology.

But:
the actual evidence is not available internally.

RETRIEVAL TRIGGER
↓
Retrieve the paper
↓
Inspect methodology
↓
Inspect results
↓
Compare claim with evidence
↓
Answer Validity Boundary
↓
Answer

La capacidad de razonamiento del modelo puede ser perfectamente útil. El componente que falta es la evidencia.

Esa distinción es fundamental.

Dónde el ejemplo deja de funcionar

Los ejemplos anteriores hacen que la decisión parezca binaria: recuperar o no recuperar.

Los sistemas reales son más complicados. Una pregunta puede contener varias afirmaciones, algunas estables y otras actuales. Los documentos recuperados pueden contradecirse. Un recuperador puede devolver información irrelevante. La información relevante puede existir pero no clasificarse lo suficientemente alto. Un documento puede ser autorizado pero estar desactualizado.

La recuperación en sí misma también puede introducir contexto incorrecto en una respuesta por lo demás razonable.

Por esto la recuperación no debe tratarse como un sinónimo automático de verdad.

La investigación sobre la recuperación adaptativa se ha alejado cada vez más del supuesto de que toda consulta debe recibir la misma estrategia de recuperación.

Self-RAG, por ejemplo, explora explícitamente la recuperación bajo demanda en lugar de recuperar indiscriminadamente un número fijo de pasajes para cada entrada. Los autores analizan cómo la recuperación innecesaria o irrelevante puede reducir la calidad de la respuesta.

Adaptive-RAG selecciona de manera similar entre no recuperación, recuperación de un solo paso y estrategias de recuperación más complejas según la complejidad de la pregunta.

Así que la pregunta importante no es: ¿Este sistema tiene RAG?

Es: ¿Puede este sistema reconocer cuándo es necesaria la recuperación y qué tipo de recuperación es apropiada?

Respuesta directa

Una IA debe activar la recuperación cuando responder requiere información que el conocimiento de su modelo interno no puede proporcionar de forma segura con la frescura, especificidad, procedencia o respaldo probatorio requeridos.

En sistemas prácticos, un Disparador de Recuperación puede surgir de varias condiciones:

Need for current information
        OR
Need for exact source-specific information
        OR
Need for evidence or provenance
        OR
Need for private/user-specific information
        OR
Insufficient knowledge coverage
        OR
Conflicting evidence
        OR
High consequence of factual error

Si ninguna de estas condiciones está presente de manera sustancial, la recuperación puede ser innecesaria. Si una o más están presentes, la evidencia externa pasa a formar parte del proceso de generación de la respuesta.

Por qué esto es así

El conocimiento interno de un modelo de lenguaje suele describirse como conocimiento paramétrico. Se aprendió durante el entrenamiento y se codificó en los parámetros del modelo.

El trabajo original de RAG de Lewis et al. enmarcó la recuperación como una combinación de esta memoria paramétrica con una memoria externa no paramétrica. La memoria externa puede buscarse y actualizarse sin reentrenar todo el modelo de lenguaje.

Esta distinción crea un problema de sistemas inevitable.

El modelo puede saber cosas. Pero el modelo no puede asumir que todo lo que sabe está actualizado, es completo, es lo suficientemente específico y está respaldado por la evidencia requerida.

Por lo tanto, un modelo puede producir una respuesta lingüísticamente convincente mientras sigue operando más allá del punto en el que su conocimiento interno es suficiente.

Ese punto es donde un Disparador de Recuperación resulta útil.

Contexto

El RAG tradicional a menudo se ve así:

Question
↓
Retrieve documents
↓
Add documents to context
↓
Generate answer

Esta arquitectura asume la recuperación antes de la generación. Eso funciona bien para muchas aplicaciones intensivas en conocimiento, pero también puede realizar recuperaciones innecesarias.

Enfoques más avanzados introducen un paso adaptativo:

Question
↓
Evaluate information requirement
↓
        ┌───────────────┐
        │               │
   no retrieval      retrieval
        │               │
        ↓               ↓
 model knowledge    external evidence
        │               │
        └───────┬───────┘
                ↓
              answer

FLARE va más allá al considerar la recuperación durante la propia generación. Utiliza la generación próxima y los tokens de baja confianza como señales para recuperar información adicional.

Self-RAG introduce de manera similar mecanismos que permiten que la recuperación, la generación y la crítica interactúen en lugar de tratar la recuperación como un paso de preprocesamiento incondicional.

Adaptive-RAG aborda el mismo problema más amplio desde la complejidad de la consulta: diferentes preguntas pueden requerir diferentes estrategias de recuperación.

Estos enfoques difieren técnicamente. Pero exponen la misma idea arquitectónica: la recuperación debe ser una decisión, no simplemente un interruptor permanente.

Supuestos

El marco de Retrieval Trigger asume que un sistema tiene acceso a al menos una fuente de información externa cuando se requiere recuperación.

Esa fuente podría ser búsqueda web, un almacén de documentos, base de datos vectorial, base de datos SQL, grafo de conocimiento, API, sistema empresarial, documento subido por el usuario o salida de herramienta.

También asume que la recuperación tiene un costo. Ese costo no tiene que ser financiero.

La recuperación introduce latencia, consumo de tokens, uso de contexto, complejidad de infraestructura y la posibilidad de recuperar información engañosa.

Por lo tanto, el sistema óptimo no maximiza la recuperación. Maximiza la recuperación apropiada.

Variables

Un Retrieval Trigger práctico puede considerar cinco variables principales.

Frescura

¿Qué probabilidad hay de que la información requerida haya cambiado? La capital de Francia tiene muy baja volatilidad. El precio de una acción tiene una volatilidad extremadamente alta.

Especificidad

¿Requiere la pregunta información de una fuente, documento, organización, cuenta o conjunto de datos en particular? Si el usuario pregunta qué dice un contrato específico, el conocimiento general del modelo es irrelevante. El contrato debe recuperarse.

Requisito de evidencia

¿Necesita la respuesta procedencia? Un modelo puede saber que una afirmación es generalmente aceptada pero aún así necesitar una fuente cuando la tarea requiere verificación.

Cobertura del conocimiento

¿Es probable que el tema esté representado adecuadamente en el conocimiento interno del modelo? La información rara, propietaria, altamente local o recién publicada crea una mayor presión de recuperación.

Consecuencia del error

No todas las respuestas incorrectas tienen el mismo impacto. Cuando la precisión fáctica afecta materialmente a una decisión, el umbral de evidencia aceptable puede ser más alto.

Estas variables no tienen que implementarse como puntuaciones numéricas literales. Describen la superficie de decisión.

Método de diagnóstico / decisión

Se puede implementar un Disparador de Recuperación muy simple sin aprendizaje automático.

def should_retrieve(
    time_sensitive=False,
    source_specific=False,
    evidence_required=False,
    private_context=False,
    knowledge_uncertain=False,
    conflicting_information=False
):
    return any([
        time_sensitive,
        source_specific,
        evidence_required,
        private_context,
        knowledge_uncertain,
        conflicting_information,
    ])

Para una pregunta fáctica estable:

should_retrieve()
# False

Para un precio de acción actual:

should_retrieve(
    time_sensitive=True
)
# True

Para una afirmación científica:

should_retrieve(
    source_specific=True,
    evidence_required=True
)
# True

Los sistemas de producción pueden hacer esta decisión mucho más sofisticada. Un clasificador podría predecir los requisitos de recuperación. Un modelo podría emitir tokens de control especiales. Un enrutador podría clasificar la complejidad de la consulta. La recuperación también podría activarse repetidamente durante la generación.

La implementación puede cambiar. La cuestión arquitectónica sigue siendo la misma:

¿Es la evidencia actualmente disponible para el modelo suficiente para la respuesta que está a punto de producir?

Evidencia

El concepto propuesto aquí es consistente con varias líneas de investigación sobre recuperación.

La arquitectura RAG original demostró la utilidad de combinar el conocimiento paramétrico del modelo con conocimiento externo no paramétrico, particularmente para tareas intensivas en conocimiento.

FLARE explora explícitamente la recuperación activa durante la generación, incluida la recuperación provocada por contenido próximo de baja confianza.

Self-RAG demuestra una arquitectura en la que la recuperación puede ocurrir bajo demanda y va seguida de una reflexión sobre los pasajes recuperados y el contenido generado.

Adaptive-RAG elige dinámicamente entre diferentes estrategias según la complejidad de la pregunta, incluidas situaciones en las que no se requiere recuperación.

El término Disparador de Recuperación se utiliza aquí como una abstracción a nivel de sistema sobre esta familia más amplia de decisiones.

No afirma que estos artículos utilicen la misma terminología. En cambio, identifica el problema arquitectónico compartido: ¿Qué hace que un sistema de IA pase del conocimiento interno a la evidencia externa?

Ejemplos reales

Considere un asistente de soporte conectado a la documentación de una empresa.

"How do I reset my password?"

Si el procedimiento es estable y está representado de manera fiable en las instrucciones actuales del asistente, la respuesta directa puede ser apropiada.

"What permissions does my account currently have?"

Esa información es específica del usuario y dinámica. Se activa el Disparador de Recuperación. El sistema debe inspeccionar los datos reales de la cuenta o de autorización.

"Why was my production deployment rejected yesterday?"

El modelo puede entender los sistemas de despliegue y explicar razones comunes. Pero la pregunta se refiere a un evento particular. Se requieren registros, salida de CI/CD o registros de incidentes.

La misma lógica se aplica a la búsqueda web.

"What is RAG?"

Una explicación general puede no requerir recuperación.

"What did the authors of Self-RAG specifically conclude about unnecessary retrieval?"

Ahora se requiere evidencia específica de la fuente.

"What is the latest research on adaptive retrieval?"

Esto también introduce un requisito de actualidad. El tema subyacente no ha cambiado. El requisito de información sí.

Conceptos erróneos comunes y modos de fallo

Más recuperación produce automáticamente una mejor respuesta. No es así. Los documentos irrelevantes consumen contexto y pueden distraer la generación.

Una alta confianza del modelo significa que la recuperación es innecesaria. Un modelo puede producir una respuesta incorrecta con confianza. Por lo tanto, la confianza autoinformada no debe tratarse como el único disparador.

Una recuperación exitosa significa que la respuesta está verificada. La recuperación solo proporciona evidencia candidata. La evidencia aún debe ser relevante, suficientemente autorizada e interpretada correctamente.

RAG resuelve automáticamente el conocimiento desactualizado. Solo lo hace si el propio corpus de recuperación contiene información actual. Recuperar un documento desactualizado no crea una respuesta actual.

Un paso de recuperación siempre es suficiente. Las preguntas complejas pueden requerir varias piezas de evidencia o recuperación iterativa.

Casos límite

Algunas preguntas contienen información tanto estable como inestable.

"Who founded NVIDIA, and what is its market capitalization today?"

La primera parte puede ser respondible a partir del conocimiento estable del modelo. La segunda parte requiere información actual.

Un sistema suficientemente capaz no debería tratar necesariamente toda la consulta como una única decisión de recuperación. Puede activar la recuperación solo donde sea necesario.

Otro caso límite es el desacuerdo entre fuentes. Supongamos que la recuperación devuelve tres documentos que hacen afirmaciones incompatibles.

El Disparador de Recuperación ya ha tenido éxito: el sistema reconoció que se requería evidencia externa. Pero la tarea no ha terminado.

El sistema ha alcanzado ahora un problema de evaluación de evidencia. Aquí es donde el Límite de Validez de la Respuesta se vuelve importante.

El sistema puede haber recuperado información y aún no poseer evidencia suficiente para llegar a una conclusión sólida.

Retrieval Trigger
≠
permission to answer

El disparador obtiene evidencia. El límite de validez determina si esa evidencia es suficiente.

Limitaciones

El Disparador de Recuperación es un marco conceptual, no un algoritmo universal.

Diferentes sistemas requerirán diferentes reglas de activación. Un bot de atención al cliente, un asistente de investigación científica, un motor de búsqueda y un agente de software autónomo no tienen requisitos de evidencia idénticos.

Los umbrales de activación también pueden crear sus propios modos de fallo. Un umbral demasiado bajo causa una recuperación excesiva. Un umbral demasiado alto causa respuestas sin respaldo.

La infraestructura de recuperación en sí también importa. Un disparador perfecto conectado a una colección de fuentes pobre sigue produciendo evidencia pobre.

De manera similar, una base de conocimiento excelente proporciona poco valor si el disparador nunca se activa cuando se necesita.

El Disparador de Recuperación, por lo tanto, resuelve solo una parte de una arquitectura más amplia.

¿Qué cambiaría esta respuesta?

Los modelos futuros pueden contener mejores mecanismos para identificar sus propias limitaciones de conocimiento. Los recuperadores pueden volverse más baratos y rápidos. Los sistemas de contexto largo pueden llevar mucho más material fuente de forma continua.

Los modelos también pueden combinar cada vez más búsqueda, bases de datos, herramientas y conocimiento estructurado sin exponer una etapa RAG distinta al desarrollador de la aplicación.

Estos cambios podrían alterar cómo se implementa el disparador. No necesariamente eliminan la decisión subyacente.

Siempre que exista una diferencia entre la información ya disponible para el modelo y la información que debe obtenerse externamente, un sistema aún necesita algún mecanismo para determinar cuándo cruzar esa frontera.

La implementación puede desaparecer de la vista. La cuestión arquitectónica permanece.

Conclusión

RAG comienza demasiado tarde para explicar todo el problema.

Antes de que pueda ocurrir la recuperación, un sistema de IA debe determinar si la recuperación es necesaria. Esa decisión es el Disparador de Recuperación.

Stable known fact
→ answer from model knowledge

Current fact
→ retrieve

Source-specific or evidence-dependent claim
→ retrieve and verify

Pero la implicación más amplia es más importante. La IA confiable no solo necesita acceso al conocimiento. Necesita un método para determinar cuándo su conocimiento actual es insuficiente.

Model Knowledge
        ↓
Retrieval Trigger
        ↓
Runtime Knowledge / RAG
        ↓
Evidence
        ↓
Reasoning
        ↓
Answer Validity Boundary
        ↓
Answer

El Disparador de Recuperación determina cuándo el sistema debe buscar evidencia. El Límite de Validez de la Respuesta determina si esa evidencia es suficiente.

Juntos describen algo más útil que RAG por sí solo: un proceso de decisión para pasar de lo que una IA parece saber hacia lo que realmente puede respaldar.

Fuentes Primarias

Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (2020). Trabajo fundacional de RAG que describe la combinación de memoria paramétrica del modelo con memoria no paramétrica externa.

Zhengbao Jiang et al., Active Retrieval Augmented Generation (2023). Introduce FLARE y la recuperación activa durante la generación, incluida la recuperación basada en contenido predicho con baja confianza.

Akari Asai et al., Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection (2023). Explora la recuperación adaptativa bajo demanda y la autorreflexión en lugar de la recuperación fija incondicional.

Soyeong Jeong et al., Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity (2024). Selecciona dinámicamente entre sin recuperación, recuperación de un solo paso y estrategias de recuperación más complejas según la pregunta entrante.