Generación aumentada por recuperación para tareas de PLN con uso intensivo de conocimiento

"Generación aumentada por recuperación para tareas de PLN con uso intensivo de conocimiento" (NeurIPS 2020) de Lewis et al. es probablemente el artículo científico más responsable de cómo se estructuran los sistemas de IA de producción en la actualidad. Cinco años después de su publicación, sigue siendo el punto de referencia con el que se mide casi cualquier sistema de lenguaje fundamentado en documentos. Lo estoy leyendo ahora porque todo en mi lista de pendientes de Bean Labs —desde el control de calidad (QA) de libros contables hasta la explicación de anomalías— termina topándose con la cuestión de la recuperación, y quiero entender claramente las decisiones de diseño originales antes de pasar a sus sucesores.

El artículo

El problema central que aborda RAG es que los modelos de lenguaje preentrenados consolidan el conocimiento en sus pesos en el momento del entrenamiento, lo que hace que ese conocimiento sea estático, opaco e imposible de actualizar sin volver a entrenar. Lewis et al. proponen una arquitectura híbrida: una memoria paramétrica (BART-large como generador) emparejada con una memoria no paramétrica (un índice FAISS denso sobre 21 millones de pasajes de Wikipedia), conectados por un recuperador entrenado basado en la Recuperación de Pasajes Densos (DPR, Karpukhin et al. 2020). En el momento de la inferencia, el modelo recupera los K pasajes más relevantes y luego los marginaliza para generar la salida final.

El artículo introduce dos variantes. RAG-Sequence recupera una vez y utiliza el mismo conjunto de documentos para toda la secuencia generada —más coherente pero menos adaptativo—. RAG-Token permite al modelo atender a un documento recuperado diferente en cada paso de la generación, lo que le permite sintetizar información de múltiples fuentes a mitad de la frase. Ambas variantes entrenan el recuperador y el generador de forma conjunta durante el ajuste fino (fine-tuning), aunque el codificador de documentos se congela para evitar el coste de reconstruir el índice FAISS durante el entrenamiento.

Ideas clave

• RAG-Sequence logra un 44.5 de Coincidencia Exacta (EM) en Natural Questions, 56.8 EM en TriviaQA y 68.0 EM en WebQuestions, lo cual era el estado del arte al momento de la publicación.
• En la tarea de QA abstractivo de MS-MARCO, RAG-Sequence obtiene una puntuación de 40.8 ROUGE-L frente a 38.2 de una línea base de solo BART; una mejora modesta pero constante.
• Generación de preguntas de Jeopardy: los evaluadores humanos juzgaron los resultados de RAG como más basados en hechos que los de BART en el 42.7% de los casos (BART fue más factual en el 7.1%).
• En la verificación de hechos de FEVER, RAG alcanza un 72.5% de precisión en tres vías (4.3 puntos por debajo del SOTA especializado) sin ninguna ingeniería específica para la tarea.
• Congelar el codificador de documentos durante el entrenamiento solo cuesta unos ~3 puntos de EM en NQ (44.0 → 41.2), lo que hace que el enfoque sea computacionalmente viable a cambio de que el conocimiento del índice se vuelva obsoleto.
• La recuperación densa supera a BM25 en todas las tareas excepto en FEVER, donde las consultas centradas en entidades favorecen el solapamiento de términos, una señal concreta de que la recuperación dispersa no es uniformemente inferior.

Qué se mantiene vigente — y qué no

La idea fundamental —separar el almacenamiento de conocimiento del motor de razonamiento— ha envejecido muy bien. Permite tener conocimiento actualizable (basta con reindexar), atribución de fuentes (los pasajes recuperados son inspeccionables) y se generaliza a través de QA de dominio abierto, generación y verificación de hechos sin arquitecturas específicas para cada tarea. Esas propiedades siguen importando más en la práctica que las cifras específicas de Coincidencia Exacta.

Los revisores de NeurIPS tenían razón en que la novedad técnica es limitada. DPR y BART ya existían; RAG es una integración cuidadosa, no un avance algorítmico fundamental. La decisión de congelar el codificador de documentos también crea un problema sutil que el artículo pasa un poco por alto: el índice se construye una vez y se convierte en una instantánea. Cualquier hecho que cambie después de que se construya el índice es invisible para el modelo. Para corpus estáticos como las presentaciones ante la SEC, esto es aceptable. Para sistemas en vivo —precios en tiempo real, flujos de transacciones diarios— es una restricción arquitectónica genuina, no un detalle menor.

El hallazgo del colapso de la recuperación merece más atención de la que recibe. En tareas de generación de historias, el modelo aprendió a ignorar por completo los documentos recuperados y a generar a partir de la memoria paramétrica. El artículo señala que esto ocurre cuando la tarea no "requiere conocimiento específico", pero no explica el mecanismo ni ofrece a los profesionales una forma fundamentada de detectarlo. Un agente que deja de recuperar silenciosamente mientras parece funcionar con normalidad es exactamente el modo de fallo que me preocupa en los sistemas financieros de producción.

La huella de memoria también es considerable: el índice de Wikipedia por sí solo requiere unos ~100 GB de RAM de CPU. El artículo presenta esto como una característica (la memoria no paramétrica es "rápida de actualizar"), pero es un coste operativo real que dio forma a la evolución de la técnica —hacia índices comprimidos y recuperación aproximada— en los años siguientes.

Por qué esto es importante para la IA financiera

La arquitectura de recuperación se adapta de forma natural a la estructura del problema de Beancount. Un libro contable de Beancount es un gran corpus de documentos de solo adición donde las entradas individuales están vinculadas semánticamente: un gasto deducible de impuestos hace referencia a una categoría, una categoría a una regla y una regla a un año fiscal. Ningún modelo paramétrico entrenado con datos públicos conoce el catálogo de cuentas específico de un usuario. La separación que hace RAG entre razonamiento y conocimiento la convierte en la respuesta estructural correcta: ajustar el generador para los formatos de tareas contables, pero fundamentar las búsquedas de hechos en el índice del libro contable real del usuario.

La preocupación práctica es la misma que identifica el artículo pero a la que resta importancia: los índices obsoletos. Si un agente de Beancount recupera información de un índice construido ayer, puede omitir las transacciones de hoy. El indexado incremental y el reindexado activado por escrituras en el libro contable deben formar parte del diseño del sistema desde el principio, no como una adaptación posterior. La otra preocupación es la precisión de la recuperación sobre datos estructurados. RAG fue diseñado para la prosa de Wikipedia. Un libro contable de Beancount tiene rangos de fechas, jerarquías de cuentas y denominaciones de moneda que los recuperadores optimizados para prosa no manejan de forma nativa. La pregunta sobre si "pueden los LLM razonar sobre datos tabulares" que exploré anteriormente limita directamente qué puede recuperar RAG de manera útil.

Qué leer a continuación

• Fusion-in-Decoder (FiD), Izacard & Grave 2020 (arXiv:2007.01282): procesa de forma independiente cada pasaje recuperado y los fusiona en el decodificador, logrando puntuaciones NQ más altas que RAG siendo arquitectónicamente más simple; vale la pena entenderlo antes de adoptar el enfoque de lectura conjunta de RAG-Token.
• FLARE: Active Retrieval Augmented Generation, Jiang et al. 2023 (arXiv:2305.06983): recupera bajo demanda durante la generación prediciendo cuándo el modelo está a punto de alucinar; la extensión más natural de las ideas de RAG hacia agentes más adaptativos.
• "¿Ajuste fino o recuperación?" Ovadia et al. 2023 (arXiv:2312.05934): comparación sistemática de métodos de inyección de conocimiento a través de diversas tareas; la evidencia empírica que se necesita antes de decidir si ajustar un generador específico para libros contables o simplemente mejorar la recuperación.