seis meses para perfeccionar su cartera de RAG.
Hicieron cinco barridos de Optuna. Agregaron un reranker personalizado. Ajustaron un modelo de integración con sus propios datos.
La precisión de la producción nunca cambió. Los pilotos seguían quejándose de las mismas respuestas incorrectas. Seis meses después, el error estaba en el analizador.
El equipo estaba perdido, no estancado. RAG no es aprendizaje automático y el conjunto de herramientas de ML resuelve el problema equivocado. Este es el error más costoso en el RAG empresarial actual. Cuesta meses de trabajo cuidadoso, las personas equivocadas en las tareas equivocadas y una silenciosa erosión de la confianza en el sistema.
RAG se parece tanto al aprendizaje automático que el conjunto de herramientas de ML parece el siguiente paso natural. Los instintos (optimización de hiperparámetros, conjuntos de datos de evaluación, marcos de explicabilidad) no son incorrectos de forma aislada. Se importan del campo equivocado. Los métodos que funcionan para entrenar modelos no funcionan para ensamblar sistemas de búsqueda.
La cuestión no es que el aprendizaje automático sea malo. El modelo de integración que impulsa la búsqueda de vectores es en sí mismo un modelo de aprendizaje profundo, pero no lo entrenas, lo consumes. La cuestión es que el sistema que se está construyendo a su alrededor no es un modelo, y tratarlo como una pérdida de tiempo, elegir las métricas equivocadas, contratar a las personas equivocadas y ocultar los verdaderos modos de fallo.
La posición “RAG no es ML” es una parte del Volumen 1 de Enterprise Document Intelligence, que construye RAG empresarial ladrillo a ladrillo. Los cuatro ladrillos (análisis, análisis de preguntas, recuperación, generación) son el conjunto de herramientas de ingeniería al que apunta este artículo.
1. Dos problemas diferentes
El aprendizaje automático resuelve problemas en los que se desconoce la verdadera respuesta y es necesario predecirla. ¿Este cliente abandonará? ¿Cuál es la probabilidad de que esta transacción sea fraude? ¿Es esta imagen un gato? No sabes la respuesta de antemano. Por eso entrenas a un modelo. El modelo aprende de ejemplos etiquetados, generaliza a nuevas entradas y produce una predicción. El rendimiento se mide de forma agregada, en miles de casos de prueba, porque las predicciones individuales pueden ser erróneas mientras el modelo sigue siendo útil en general.
RAG resuelve un problema diferente. La respuesta a "¿cuál es la fecha de entrada en vigor de este contrato?" existe, escrito en la página uno del documento, o no existe en ninguna parte. No hay nada que predecir. El sistema o encuentra la respuesta en el documento y la informa fielmente, o falla y debería decirlo. El rendimiento es binario a nivel de pregunta (lo entendí o no), incluso si mide las tasas agregadas en muchas preguntas.
Estas diferencias son concretas:
En ML, “el modelo estaba equivocado en el 8% de los casos” es una característica del sistema. Usted crea redundancia, controles posteriores y revisión humana para los casos límite. En RAG, “el sistema dio una respuesta incorrecta el 8% de las veces” es un error. Cada uno de ese 8% tiene una causa específica: se recuperó el pasaje equivocado, se recuperó el pasaje correcto pero el modelo lo parafraseó mal, la respuesta no estaba en el corpus y el sistema inventó una. No son ruido estadístico para optimizar en promedio. Son fallos que se pueden solucionar individualmente. En ML, generalmente no se puede saber por qué el modelo se equivocó en un caso particular. Por eso la explicabilidad es un campo de investigación. En RAG siempre se nota. La recuperación registra qué pasajes devolvió. El generador vio exactamente esos pasajes. Si la respuesta es incorrecta, recorre la cadena hacia atrás y encuentra el eslabón roto. No hay nada escondido. En ML, el modelo mejora al entrenar con más datos. En RAG, el sistema mejora al indexar mejor, analizar con más cuidado, recuperar con mayor precisión y solicitar mensajes con mayor claridad. Nada de eso es entrenamiento. Es ingeniería.
Esa diferencia cambia las herramientas a las que recurre cuando algo se rompe.
Los casos catalogados en el artículo 2 caen exactamente aquí: negación, identificadores exactos, acrónimos internos, dilución de la señal en un contexto largo, proximidad temática que supera la respuesta real. Ninguno de ellos se mueve cuando intercambias modelos de incrustación o barres tamaños de fragmentos. No son errores de los que un modelo pueda aprender a salir, porque no hay una señal etiquetada que diga "esta es la línea correcta" para que el modelo entrene. La solución es estructural (análisis de preguntas, palabras clave de expertos, recuperación que conoce la estructura del documento) y las siguientes secciones analizan los tres reflejos de ML que eligen la herramienta incorrecta.
2. Tres argumentos que no se aplican
De forma predeterminada, se importan tres métodos de aprendizaje automático a los proyectos RAG: optimización de hiperparámetros, conjuntos de datos de evaluación con divisiones de entrenamiento/prueba y explicabilidad de atribución de características. Cada uno es razonable dentro de ML. Cada uno falla aquí.
2.1 El argumento del hiperparámetro
El encuadre más común es algo así: tamaño del fragmento, superposición, top-k, umbral de similitud. Estos son hiperparámetros y debes optimizarlos de la misma manera que optimizas los modelos de ML, utilizando herramientas como Optuna o Ray Tune. Realice un barrido, trace las curvas y elija la mejor configuración.
En estas configuraciones, top_k es el número de pasajes que conserva el recuperador y similarity_threshold es la puntuación mínima de coseno que debe alcanzar un pasaje para calificar. El siguiente código declara los cuatro como números para optimizar:
# Lo que suelen escribir los equipos (y por qué es la actividad incorrecta) import optuna def Objective(trial): chunk_size = juicio.suggest_int("chunk_size", 100, 2000) chunk_overlap = juicio.suggest_int("chunk_overlap", 0, 200) top_k = juicio.suggest_int("top_k", 1, 20) umbral = trial.suggest_float("threshold", 0.5, 0.95) precision = run_rag_pipeline_and_score( chunk_size, chunk_overlap, top_k, umbral ) estudio de precisión de retorno = optuna.create_study(direction="maximize") Study.optimize(objective, n_trials=200) # dos semanas de cálculo después…
Hay una pizca de verdad aquí. Estas variables afectan la calidad de la recuperación y vale la pena ajustarlas. El problema comienza con la palabra "hiperparámetro", que introduce una metáfora con suposiciones ocultas.
En el aprendizaje automático, un hiperparámetro controla cómo aprende un modelo: tasa de aprendizaje, intensidad de regularización, número de capas. El modelo en sí es lo que cambia durante el entrenamiento; las formas de hiperparámetros que cambian. En RAG no hay aprendizaje. El tamaño del fragmento no controla cómo aprende algo. Controla cómo una función divide el texto, de la misma manera siempre, independientemente de lo que le hayas dado antes.
Lo que parece un hiperparámetro es una elección de configuración, del tipo que haría al configurar un motor de búsqueda. La experiencia necesaria para ajustarlo bien no es optimización estadística. Es comprender la estructura de sus documentos y la forma de sus preguntas. Un tamaño de fragmento de 512 tokens puede funcionar maravillosamente en artículos académicos densos y desastrosamente en contratos de seguros donde una sola cláusula abarca 800 tokens y al dividirla por la mitad se pierde el condicional que le da significado a la cláusula. Ninguna búsqueda en la red te dirá eso. Necesitas leer tus documentos.
Esta es la razón por la que los equipos que buscan en la cuadrícula el tamaño de los fragmentos a menudo encuentran un "mejor" valor que funciona marginalmente mejor en el conjunto de pruebas e idénticamente en los datos de producción. Lo óptimo en el conjunto de prueba fue un artefacto del conjunto de prueba, no una mejora genuina en el sistema subyacente. Optimizaron un número, no resolvieron un problema.
Error común: un equipo que ejecuta Optuna sobre chunk_size, top_k y similarity_threshold durante dos semanas, termina en chunk_size=487 sin tener idea de por qué. La respuesta honesta a "¿por qué 487?" es "porque Optuna lo dijo". Esa respuesta no sobrevive a un fallo real de producción y no se generaliza cuando cambia la distribución de documentos. Un tamaño de fragmento de 500 elegido porque es aproximadamente el tamaño de un párrafo en este corpus es más defendible que 487 elegido porque un barrido aterrizó allí.
La actividad correcta no es ajustar números. Se trata de decidir estructuralmente cómo fragmentar. ¿Por sección? ¿Por párrafo? ¿Por las entradas del índice? ¿Por tipo de pregunta, con diferentes fragmentos para búsquedas cortas frente a cláusulas largas? Respondido mirando documentos y preguntas, no mediante curvas de optimización.
Hay una razón más profunda por la que el tamaño de los fragmentos se resiste a la optimización: por construcción, ningún tamaño de fragmento único puede responder a todas las preguntas. Responda dos preguntas sobre el mismo contrato de seguro:
"¿Cuál es la fecha de entrada en vigor?" La respuesta está en una línea, en algún lugar de la página uno. Quiere un trozo lo suficientemente pequeño como para precisar una sola línea con precisión. “¿Cuáles son las exclusiones de la póliza?” La respuesta puede ser una página o tres páginas, dependiendo de cómo la redactó la aseguradora. Quiere un fragmento lo suficientemente grande como para capturar una sección completa.
No existe un número que satisfaga a ambos. Un trozo de 200 tokens divide la sección de exclusiones en fragmentos incoherentes. Un trozo de 2000 tokens oculta la fecha de entrada en vigor en el ruido circundante.
Por lo tanto, tratar de encontrar “el mejor tamaño de fragmento” no es un problema de ajuste. El marco en sí está roto: ningún número por sí solo puede servir para una distribución de preguntas cuyas respuestas tienen diferentes longitudes.
En principio, podría hacer que el tamaño del fragmento responda a la pregunta entrenando un modelo pequeño que prediga el fragmento correcto a partir de las características de la pregunta: clasificar la intención, retroceder sobre la longitud esperada de la respuesta, generar una estrategia. Sería aprendizaje automático aplicado legítimamente a un problema en el que se está aprendiendo algo.
Pero no es necesario. Puedes escribir la regla. Mire una pregunta y podrá saber si pide una fecha, una sección o una comparación. También puede hacerlo un experto en dominios. También pueden hacerlo diez líneas de Python con condiciones escritas a mano sobre palabras clave. La razón más profunda por la que RAG no es aprendizaje automático es que, para la mayoría de las decisiones dentro del sistema, usted ya sabe la respuesta, o alguien de su equipo la sabe. El aprendizaje automático es la herramienta para problemas en los que nadie sabe la respuesta de antemano.
El enfoque correcto es dejar de buscar un tamaño de fragmento y comenzar a dirigir diferentes tipos de preguntas a diferentes estrategias de recuperación:
# Qué hacer en su lugar: ruta por tipo de pregunta def chunk_for_question(question: str, line_df, toc_df): intent = classify_intent(question) if intent == "point_lookup": # "¿cuál es la fecha de vigencia?" return chunk_by_line(line_df) elif intent == "section_retrieval": # "¿cuáles son las exclusiones?" return chunk_by_toc_section(line_df, toc_df) elif intent == "comparación": # "comparar cláusulas A y B" return chunk_by_full_section(line_df, toc_df)
Los dos bloques de código anteriores son el argumento completo de esta sección. El primero ejecuta Optuna en cuatro números durante dos semanas y produce un valor que nadie puede defender. El segundo toma una decisión estructural por tipo de pregunta y produce un sistema cuyo comportamiento cualquiera puede explicar.
Artículos posteriores desarrollan cómo clasificar la intención (Artículo 6, sobre comprensión de las preguntas) y cómo se implementan los diferentes métodos y granularidades de recuperación (Artículo 7, sobre recuperación). El punto aquí es simplemente que la actividad no es sintonización, sino enrutamiento.
2.2 El argumento del conjunto de datos de evaluación
La siguiente importación de ML es el método de evaluación. El razonamiento es el siguiente: RAG, como cualquier sistema de aprendizaje automático, necesita un conjunto de datos de evaluación adecuado: preguntas combinadas con las respuestas esperadas, divididas en conjuntos de entrenamiento y prueba, calificadas con precisión y recuperación. Marcos como RAGAS han hecho que esto sea aún más tentador, ofreciendo métricas de fidelidad, relevancia de las respuestas y recuerdo del contexto que parecen satisfactoriamente ML-ish.
La evaluación es útil. La cuestión no es si evaluar o no. Eso es lo que significan las métricas. En el aprendizaje automático, la evaluación le indica si un modelo se ha generalizado a partir de datos de entrenamiento a ejemplos invisibles. La división tren/prueba existe porque desea detectar el sobreajuste: un modelo que memorizó el conjunto de entrenamiento en lugar de aprender un patrón transferible.
En RAG no hay nada que generalizar. El sobreajuste (cuando un modelo memoriza ejemplos de entrenamiento en lugar de aprender un patrón que se transfiere a nuevos datos) no puede ocurrir aquí: el sistema no cambia entre consultas. El recuperador calcula las mismas distancias de cosenos cada vez. El generador sigue la misma plantilla de indicaciones. No existe un modelo que se ajuste a los datos.
Lo que la evaluación mide en RAG son tres cosas, todas las cuales son cuestiones de cobertura y calidad, no generalizaciones estadísticas:
¿Mi corpus contiene la respuesta? Si no, el sistema no puede encontrarlo. Ésta es una pregunta de contenido, no una pregunta modelo. ¿Mi perro perdiguero encuentra el pasaje correcto? Si la respuesta está en el corpus pero el perro la omitió, el sistema falla. Esta es una pregunta de búsqueda. ¿Mi generador se mantiene fiel a lo que se recuperó? Si se recuperó el pasaje correcto pero el modelo lo parafraseó incorrectamente o alucinó extras, el sistema falla. Ésta es una cuestión de disciplina generacional.
Cada uno apunta a una solución específica. Mezclarlos bajo una puntuación agregada de "precisión" pierde información. Una precisión del 75 % de “al corpus le falta el 25 % de los temas documentados” exige una acción diferente a una precisión del 75 % de “el recuperador omite el pasaje correcto el 25 % de las veces”. El primero exige ingerir más documentos. El segundo exige arreglar al perro perdiguero. Una métrica agregada que los trata igual oculta el diagnóstico.
Esto también explica por qué los equipos que utilizan marcos de trabajo estilo RAGAS a veces informan excelentes métricas en un conjunto de pruebas retenido y luego observan cómo el sistema falla en producción. El conjunto de pruebas cubrió temas en los que el corpus tenía respuestas y el perro perdiguero las encontró. La producción tiene preguntas cuyas respuestas no están en absoluto en el corpus, y el sistema alucina o no dice "no encontrado". La métrica fue alta en el conjunto de prueba porque el conjunto de prueba era amigable. El sistema no está roto. La evaluación fue.
Lo que necesita evaluar, desglosado por tipo de pregunta, ocupa unas diez líneas:
# Recuperación de recuperación, por pregunta, por intención def evalua_retrieval(reference_set, retrieve_fn): filas =[]para referencia en conjunto_referencia: líneas_recuperadas = recuperar_fn(ref.question) recordar = len(set(líneas_retrieves) & set(ref.expected_lines)) / len(ref.expected_lines) filas.append({ "pregunta": ref.question, "intención": ref.intent, "recordar": recordar, "hit": recordar > 0, }) return pd.DataFrame(filas) # Siempre desglose por tipo de pregunta, nunca solo un agregado df.groupby("intent")["hit"].mean() # point_lookup 0.92 # sección_retrieval 0.41 <– este es el verdadero problema # comparación 0.55
Una precisión agregada única del 63 % habría ocultado la catástrofe en la sección_recuperación. El desglose por intención lo revela al instante. Recordar aquí significa: en preguntas cuya respuesta existe en el corpus, ¿el perro perdiguero encontró el pasaje correcto? La agrupación por intención (point_lookup, sección_retrieval,…) muestra qué tipo de pregunta falla y, por lo tanto, qué parte del proceso se debe corregir.
RAG tiene dos superficies de evaluación con formas muy diferentes.
La superficie de recuperación es un problema de búsqueda: ¿aterrizó el pasaje correcto frente al modelo? Medir esto significa verificar, en un conjunto de preguntas de referencia, si se recuperaron las líneas o páginas relevantes. La métrica se recupera en el nivel que le interesa (recuperación en línea, en página, en sección) y es específica de su corpus. Nadie más puede realizar esta evaluación por usted. Tu corpus es único. Aquí es donde pertenece la mayor parte del esfuerzo de evaluación.
La superficie de generación es diferente. Una vez que se ha recuperado el pasaje correcto, la pregunta es: ¿produjo el modelo una respuesta fiel, en el formato correcto, con las citas adecuadas y un “no encontrado” limpio cuando el pasaje no contenía la respuesta? Parte de esto lo evalúa usted mismo, pero una gran parte ya la evalúan los proveedores de LLM. OpenAI, Anthropic y Mistral gastan enormes recursos probando si sus modelos siguen esquemas JSON, se niegan a inventar y respetan las instrucciones rápidas. Ésas son las dimensiones en las que mejoran sus modelos. Como constructor de RAG, no estás entrenando al generador. Lo estás consumiendo. Si el modelo falla gravemente al devolver JSON estructurado o permanece infiel a sus entradas, lo notará una hora después de la integración. Esa no es una métrica que deba configurarse; es una verificación de cordura que es obvia o buena.
Lo que esto significa en la práctica: la mayor parte del tiempo de evaluación debe dedicarse a la recuperación (que es específica del corpus y solo usted puede hacerlo), no a la generación (que es principalmente problema del proveedor y que muestra fallas obvias rápidamente). Los equipos que pasan semanas construyendo complejos conjuntos de evaluación de generación generalmente posponen el trabajo de recuperación más duro que mejoraría el resultado.
Yendo más allá: Evaluando su sistema (más adelante en la serie) explica cómo crear un conjunto de referencia para su corpus específico, las cuatro métricas que importan y por qué las métricas por tipo de pregunta son esenciales mientras que las métricas agregadas son engañosas.
2.3 El argumento de la explicabilidad
El aprendizaje automático tiene su propio conjunto de herramientas para la explicabilidad. Valores SHAP para atribuir predicciones a características. LIME para aproximaciones locales de modelos complejos. Visualización de atención para transformadores. Cuando la gente empieza a preguntar por la explicabilidad de RAG (“¿por qué el sistema dio esta respuesta?”), naturalmente recurren a estas herramientas. Quieren calificar la relevancia de la recuperación, ponderar las contribuciones de los documentos y visualizar qué tokens influyeron en el resultado.
La ironía es que RAG es más explicable por diseño que la mayoría de los modelos ML. No hay necesidad de SHAP. No hay opacidad para abrir. El sistema recuperó estos pasajes específicos de estas fuentes específicas y la respuesta se construyó sobre ellos. Esa es la explicación. Es documental, no estadístico.
Esto apunta a una asimetría más profunda entre el aprendizaje automático y RAG. En el aprendizaje automático, el humano tiene intuición pero no puede cuantificarla. Pregunte quién sobrevivió al Titanic y la gente dirá riqueza, edad, clase social: ninguno incorrecto, ninguno preciso. El modelo no tiene esa duda: ajusta un árbol de decisión y la división de la raíz es el sexo, el siguiente corte es un umbral de edad exacto que nadie habría adivinado, luego la clase. Cada división es un número que la intuición por sí sola no podría haber producido. El modelo existe para anotar esos números.
Para datos de texto, la dirección se invierte. El usuario puede leer la fuente. Un abogado que escanea un contrato ve las condiciones, las excepciones, las fechas. Un oficial de cumplimiento lee una política y sabe si un comportamiento la infringe. El texto no oculta su significado y el experto ya lo lee con fluidez.
Hay excepciones: el sarcasmo y la ironía son los clásicos, donde los LLM modernos a veces captan lo que un lector literal se pierde. Pero en contextos empresariales el usuario es el experto en el dominio.
El modelo no está ahí para explicar el texto. Está ahí para hacer la lectura a escala de corpus, y una cita es suficiente para que el experto verifique cualquier respuesta en segundos.
Cuando un usuario pregunta "¿por qué esta respuesta?", la respuesta correcta no es un mapa de calor de ponderaciones de atención o una puntuación de atribución de características. Es: "Miré las páginas 12, 47 y 89 de este contrato. Aquí está el texto exacto que utilicé. La respuesta se desprende de ese texto". Si el usuario no está de acuerdo con la respuesta, puede leer la fuente él mismo y juzgar. No necesitan un marco de explicabilidad. Necesitan una citación.
El oleoducto de cincuenta líneas del Artículo 1 ya lo demostró. El mensaje le pedía al modelo que devolviera los números de línea inicial y final (con sus páginas) junto con la respuesta, en un JSON estructurado; Luego, el anotador resaltó esas líneas exactas en el PDF. Sin SHAP, sin LIME, sin visualización de atención, sin plataforma de observabilidad especializada. La "explicación" fue un producto secundario de cómo se escribió el mensaje. La cita es parte de la respuesta, no una capa de análisis agregada encima.
La huella es la explicación. Leerlo no requiere interpretación, sólo lectura.
Importar la explicabilidad de ML a RAG es resolver un problema que no existe. SHAP en una puntuación de recuperación consiste en utilizar un bisturí para abrir un buzón. La puntuación de recuperación ya es un número que usted calculó a partir de entradas que puede leer. No hay nada que atribuir que no hayas visto ya.
El fallo más profundo del marco de explicabilidad del aprendizaje automático es que te hace centrarte en algo equivocado. Empiezas a intentar explicar por qué un pasaje en particular obtuvo una puntuación más alta que otro en el espacio vectorial, una pregunta casi imposible que no importa. Lo que importa es si se recuperó el pasaje correcto y si la respuesta lo refleja fielmente. Esas son preguntas que puedes responder leyendo los registros y la fuente. No se necesitan herramientas.
3. ¿Qué cambia cuando ves RAG correctamente?
Una vez que dejas de tratar a RAG como ML, dos cosas cambian. Las herramientas, las métricas y las personas del día a día se reorganizan en torno a la búsqueda en lugar de la formación. Y una cuestión más profunda (dónde se ubica la inteligencia) pasa del modelo al equipo. Ambos provienen del mismo encuadre.
3.1 Herramientas, métricas, personas
Tres cosas concretas cambian.
Las herramientas cambian: no necesita PyTorch, ni un clúster de entrenamiento, ni marcos de optimización de hiperparámetros para el sistema en sí. Necesita un buen analizador, un recuperador flexible, una ingeniería rápida y cuidadosa y un registro estructurado de todo lo que sucede. Los componentes que son ML (el modelo de incorporación, el LLM) se consumen como servicios. Son insumos básicos, no cosas que uno construye o entrena.
Las métricas cambian: la precisión agregada da paso a métricas por modo de error: recuperación de recuperación (¿encontramos el pasaje correcto?), fidelidad de la respuesta (¿se mantuvo el modelo?), precisión de extracción (al extraer datos estructurados, ¿coincidieron los valores?), tasa de no encontrados (cuando la respuesta no está en el corpus, ¿lo dijimos claramente?). Cada uno mide algo específico, cada uno se asigna a una parte específica de la tubería que puede arreglar.
La gente cambia: un equipo de ML puro que intenta implementar un sistema RAG a menudo pasa por alto lo que lo hace funcionar y lo que lo hace fallar. Las habilidades que más importan son la ingeniería de software (el sistema tiene muchas partes móviles que necesitan componerse limpiamente), la experiencia en el dominio (alguien tiene que saber cómo es una buena respuesta a una pregunta de dominio) y la intuición para la recuperación de información (alguien tiene que pensar como un diseñador de motores de búsqueda, no como un entrenador de modelos). La experiencia en ML es útil, pero no es la habilidad dominante. Un equipo de investigadores de ML y ningún experto en el campo producirá un sistema bellamente ajustado que no capta el objetivo. Un equipo con un ingeniero experto en ML, dos ingenieros de software y un experto en el dominio normalmente lo superará.
3.2 Dónde se encuentra la inteligencia
El cambio en las personas apunta a una pregunta más profunda: ¿dónde vive la inteligencia del sistema?
En un sistema de ML, la inteligencia vive en el modelo. El modelo sostiene los patrones. El equipo le proporciona datos de entrenamiento y ajusta la función de pérdida. En un sistema RAG la inteligencia vive en el equipo. El abogado sabe qué cláusulas mirar primero. El asegurador sabe lo que significa "deducible" y en qué página suele figurar. El responsable de cumplimiento sabe qué normativa se aplica a cada producto. Nada de eso vive dentro del modelo de incrustación. Nada de esto surge de un barrido de hiperparámetros. Ya vive en la cabeza de las personas que han leído estos documentos durante años.
Observe a un asegurador abrir una nueva póliza. Ella no lo lee linealmente. Primero salta a la sección de exclusiones porque ha leído quinientos de estos y sabe que ahí es donde suele vivir la trampa. Ella revisa el calendario de beneficios para los deducibles y los límites máximos. Ella revisa la cláusula territorial. Tres minutos después, tiene una visión más clara del contrato que la que cualquier modelo de integración produciría en mil de esos contratos. Ese hábito es lo que el sistema tiene que amplificar.
3.3 Ampliando al experto, ladrillo a ladrillo
El trabajo de un sistema RAG empresarial es ampliar esa experiencia a escala, no reemplazarla. El aspecto que tenga depende del ladrillo.
El análisis es lo primero. Si el analizador convierte el PDF de un contrato en texto codificado, ninguna inteligencia posterior lo recupera. Si el documento tiene una tabla de contenido funcional, el analizador tiene que extraerla limpiamente, porque el TOC es en lo que se basa el experto para navegar. Cuando un documento no tiene ninguna tabla de contenido (faxes escaneados, presentaciones de diapositivas exportadas a PDF, políticas mecanografiadas antiguas), reconstruirlo se convierte en un trabajo en sí mismo, a menudo más útil que cualquier ajuste de recuperación.
La comprensión de las preguntas lleva el vocabulario del equipo a través de la brecha entre cómo un usuario formula una pregunta y cómo el documento escribe la respuesta. El usuario piloto escribe hervidor, el contrato dice pequeño electrodoméstico. El oficial de cumplimiento escribe violación de datos, la política dice divulgación no autorizada de información personal. El experto conoce el mapeo. El analizador de preguntas convierte ese mapeo en una tabla de búsqueda: traducciones entre idiomas, variantes ortográficas, formas plurales, acrónimos internos. Nada de ello se aprende de los datos, lo dicta el experto y lo anota.
La recuperación amplifica lo que el experto ya hace a mano. El experto busca palabras clave; Esa parte ya es fácil. Lo que el experto no puede hacer a escala es ejecutar patrones de expresiones regulares en miles de páginas, comprobar si dos términos coexisten dentro del mismo párrafo o combinar condiciones booleanas en todo el corpus. El recuperador hace ese trabajo rápidamente y luego devuelve a los candidatos para que el experto pueda verificarlos.
Generation hace las dos cosas que el experto haría a mano: citar el pasaje exacto que respalda la respuesta y formatear el valor bruto en algo utilizable. La cadena 3455434 de la página pasa a ser 3.455.434€ en la respuesta. 20260516 pasa a ser el 16 de mayo de 2026. Treinta días a partir de la fecha del siniestro queda palabra por palabra, con una cita retrospectiva de la cláusula para que el perito pueda verificarla con un solo clic.
Los artículos 5, 6, 7 y 8 desarrollan cada bloque por turno: el analizador que extrae la estructura TOC, el diccionario experto que mapea el vocabulario, el recuperador compatible con TOC, el generador de respuestas escritas. Siempre el mismo principio: tomar una parte de la experiencia humana y trasladar la parte repetitiva a la máquina.
Por eso también la serie tiene cuidado con los agentes autónomos. Prefiere la recuperación de palabras clave a la incorporación de similitud de forma predeterminada. Trata el ajuste del reranker como último recurso. Cada uno de esos valores predeterminados supone que no hay ningún experto a quien consultar. En contextos empresariales el experto siempre está ahí. El sistema debería escucharlos.
Si trabajas en un entorno sin expertos, con preguntas ilimitadas, con documentos muy diferentes, esta serie no será tu mejor guía. La recuperación de propósito general y los agentes autónomos encajan mejor allí.
4. Dos partes, dos modos de falla
Una forma útil de imaginarse a RAG es como un motor de búsqueda, además de un LLM que escribe la respuesta. Dos partes, cada una con un trabajo claro, cada una con su propia forma de romper.
El motor de búsqueda recupera pasajes de documentos. Dada una pregunta, devuelva las líneas, párrafos o secciones con mayor probabilidad de contener la respuesta. Éste es un problema puro de búsqueda: selectividad, recuperación, clasificación. Se aplican décadas de teoría de recuperación de información. El hecho de que parte de él utilice incrustaciones neuronales no cambia su naturaleza; incorporar similitud es sólo una señal de clasificación entre varias.
El LLM toma un pasaje y una pregunta y produce una respuesta en lenguaje natural con una cita. El LLM no encuentra la respuesta. El buscador ya lo hizo. El LLM escribe la respuesta a partir de un pasaje que se coloca delante. Está más cerca de un traductor o un escriba que de un oráculo.
Remontándonos a los cuatro ladrillos del Artículo 1: el análisis, la comprensión de las preguntas y la recuperación juntos conforman el motor de búsqueda; La generación es el LLM. La vista de ladrillo es la operativa (un cuadro de código por ladrillo); la visión de dos partes es el modelo mental que llevas en la cabeza cuando algo sale mal.
Las dos partes fallan de diferentes maneras y el diagnóstico comienza en la unión entre ellas. Extraiga el rastro de una consulta fallida: ¿los pasajes recuperados estaban delante del modelo y contenían la respuesta?
Si la respuesta no estaba en los pasajes recuperados, el motor de búsqueda es el culpable y la solución está en el origen. ¿El analizador corrompió la página correcta (errores de OCR, términos de varias palabras divididos en líneas, intercalado de dos columnas)? ¿El analizador de preguntas omitió algún sinónimo que el vocabulario experto debería haber ampliado? ¿El mecanismo de recuperación clasificó la página correcta fuera de top_k o interrumpió la puntuación que necesitaba una expresión regular? ¿O el documento relevante simplemente no está en el corpus? Cuatro soluciones muy diferentes, todas en sentido ascendente. "Sintonizar el perro perdiguero" no tiene sentido hasta que hayas localizado cuál. Los mismos cuatro ladrillos que amplifican al experto cuando trabaja (sección 3.3) se rompen aquí a su manera, cada uno con su propio artículo profundo (Artículos 5, 6, 7).
Si la respuesta estaba en los pasajes recuperados pero es incorrecta, el LLM es el culpable y la solución es posterior. Patrones comunes: el modelo parafraseó y perdió un condicional, devolvió el 3455434 sin formato porque el esquema dejó la respuesta en forma libre, citó números de línea incorrectos, inventó un valor que no estaba en el pasaje o produjo una respuesta cuando debería haber dicho "no encontrado". Cinco errores de generación, cinco correcciones diferentes, todo en la capa de aviso, esquema o posvalidación (Artículo 8). Ninguno de ellos mejora al sintonizar el perro perdiguero.
Así es como se ve ese diagnóstico en la práctica. Un usuario pregunta "¿cuántos cabezales usa el transformador base?" (respuesta: 8, página 5 del artículo Attention Is All You Need, Vaswani et al. 2017; licencia de distribución no exclusiva de arXiv, declarada en la página de resumen de arXiv). El sistema informa "16". Tira del rastro.
La recuperación devolvió las páginas 4, 7, 8. Ninguna de ellas contiene la configuración del modelo base: la página 8 describe el modelo grande (que utiliza 16 cabezales), las páginas 4 y 7 describen la estructura del codificador. El generador leyó las páginas equivocadas y devolvió el número que encontró allí. El error es la recuperación, no la generación.
¿Por qué la recuperación no llegó a la página 5? Las palabras clave fueron ['cabezas', 'base', 'modelo']. La página 7 tiene caras seis veces; La página 5 lo tiene dos veces. El recuperador de palabras clave clasificó la página 7 mejor porque calificó por frecuencia de términos sin procesar, sin verificar si la base, el modelo y los encabezados coexisten en la misma línea. Cinco líneas de Python en el recuperador de palabras clave lo solucionan.
Lo que no pasó: nadie afinó nada. Nadie hizo un barrido. Nadie agregó un reranker. El diagnóstico tardó cinco minutos; la solución tomó una tarde.
Esta separación es lo que hace que RAG sea viable en la práctica. Cada falla tiene una parte específica que arreglar. No existe un circuito de entrenamiento en el que la recuperación y la generación se enreden. Son componentes independientes, compuestos limpiamente, cada uno reemplazable por sí solo. Los sistemas de producción ganan mucho con esta propiedad: puede intercambiar modelos integrados, intercambiar LLM, intercambiar analizadores, todo sin volver a entrenar nada.
Todo el proceso es configuración, no modelo.
Cuando algo sale mal, cambia una configuración: el método de recuperación, el mensaje, el esquema, una regla de validación. No vuelves a entrenar. Cambia un archivo Python, lo envía, mide la métrica por tipo de pregunta para la categoría afectada y confirma la solución. Ciclo de iteración: horas, no semanas.
Una vez que ves RAG como una configuración para ensamblar en lugar de un comportamiento para aprender, el resto de las opciones de la serie siguen de forma natural.
5. Seis meses en el problema equivocado
A un equipo de una mediana empresa se le dan seis meses para entregar un sistema RAG sobre unos pocos miles de documentos internos. Comienzan construyendo un conjunto de datos de evaluación de 500 preguntas, dividiéndolo 70/30 en entrenamiento y prueba. Configuraron Optuna para barrer el tamaño de los fragmentos, la superposición, el top-k y el umbral de similitud. El primer barrido requiere una semana de cálculo, regresa con una "mejor" configuración y el equipo la envía para pruebas internas.
Los usuarios del piloto se quejan inmediatamente. El sistema responde con fluidez pero se equivoca la mitad de las veces en preguntas que los evaluadores conocen claramente: preguntas sobre cláusulas específicas, fechas específicas, límites numéricos específicos. La respuesta del equipo es expandir el conjunto de datos de evaluación, realizar otro barrido, ajustar el modelo de incrustación en pares sintéticos de preguntas y documentos y agregar un reclasificador. Pasan tres meses más. La precisión de la producción no cambia.
Lo que estaba mal: el analizador trataba las páginas escaneadas con capas de OCR degradadas como si fueran texto nativo. Alrededor del 30% del corpus era efectivamente ilegible, pero el conjunto de evaluación del equipo se extrajo del 70% legible. Ninguna optimización del tamaño de los fragmentos, ajustes de incrustación o integración de reordenadores pudieron solucionarlo: un tercio de los documentos generaban basura. Una inversión de dos días en revisar cada página (el trabajo del Artículo 5, sobre análisis) habría detectado esto el primer día.
El equipo había pasado seis meses en modo ML (barriendo hiperparámetros, aumentando los conjuntos de evaluación, afinando modelos) cuando la solución fue un cambio del analizador.
Esta historia es compuesta, pero cada elemento de ella ha sucedido en proyectos reales. El patrón es consistente: los reflejos de ML impulsan al equipo hacia actividades de optimización que se sienten productivas, mientras que los problemas estructurales permanecen intactos en el analizador, el corpus o la lógica no encontrada. El primer instinto en un sistema RAG en problemas no debería ser "sintonicemos". Debería ser "rastreemos lo que sucede con una consulta fallida, de un extremo a otro, y encontremos el enlace roto".
6. Conclusión
RAG parece aprendizaje automático. El parecido es superficial. La respuesta existe en el documento o no. No existe una generalización estadística, ni una curva de aprendizaje, ni una división tren/prueba que se corresponda con fallos reales. El marco correcto es el ensamblaje del motor de búsqueda: un motor de búsqueda más un LLM, dos partes que puedes arreglar de forma independiente, con métricas por modo de falla que reemplazan la precisión agregada.
El costo de aferrarse al marco del ML no es intelectual. Son seis meses de trabajo cuidadoso en el problema equivocado. El artículo 4 convierte el marco correcto en un diagnóstico de trabajo: los problemas de RAG se ubican en una cuadrícula de complejidad de documentos mediante control de preguntas, y cada celda requiere una pila diferente.
El artículo 4 es un punto de entrada al Volumen 1 de Enterprise Document Intelligence, que construye RAG empresarial ladrillo a ladrillo a través del análisis, el análisis de preguntas, la recuperación y la generación: cada ladrillo se maneja con el kit de herramientas de ingeniería, no con el de ML.
7. Fuentes y lecturas adicionales
El artículo sitúa a RAG en la tradición de RI de 50 años (Manning, Raghavan, Schütze, Introducción a la recuperación de información, 2008) en lugar de en la tradición de ML. La afirmación empírica de que BM25 a menudo supera a los perros perdigueros densos fuera de distribución proviene de Thakur et al. (BEIR, NeurIPS 2021). El encuadre por modo de falla es la misma dirección que Barnett et al. (Siete puntos de fracaso, 2024). La concesión honesta es que el reranker es una fina capa aprendida donde se aplica la metodología ML. El marco que utiliza el artículo para la explicabilidad es la cita como explicación: una respuesta RAG lleva sus líneas fuente, por lo que el presupuesto de herramientas de explicabilidad para proyectos de ML se vuelve innecesario.
Misma dirección que el artículo:
Manning, Raghavan, Schütze, Introducción a la recuperación de información (Cambridge, 2008). La tradición de RI de 50 años en la que el artículo sitúa a RAG. Thakur et al., punto de referencia BEIR, NeurIPS 2021 (arXiv:2104.08663). Los recuperadores densos sintonizados con MS MARCO a menudo pierden debido a la falta de distribución del BM25. Soporte empírico para el marco IR, no para ML. Barnett et al., Siete puntos de falla al diseñar un sistema RAG, 2024 (arXiv:2401.05856). Taxonomía profesional de dónde se rompe RAG. Misma dirección que el encuadre por modo de falla. Kamradt, Aguja en un pajar (2023). El punto de referencia canónico de recuperación de contexto largo. Solo para investigación: prueba un único hecho palabra por palabra en un contexto extenso, no las preguntas agregadas que hacen los usuarios empresariales. Discutido en el Artículo 1 y desarrollado en el Artículo 7.
Ángulo diferente, contexto diferente:
Es et al., RAGAS: Evaluación automatizada de generación aumentada de recuperación, EACL 2024 (arXiv:2309.15217). Trata RAG con métricas agregadas de ML (fidelidad, relevancia de la respuesta, precisión/recuperación del contexto) en conjuntos de datos de referencia. El contexto son los puntos de referencia de la investigación; El marco del artículo son las tasas por modo de fallo en un corpus empresarial fijo. Saad-Falcon et al., ARES: Un marco de evaluación automatizado para sistemas de generación aumentada de recuperación, NAACL 2024 (arXiv:2311.09476). Marco de evaluación RAG estilo ML con divisiones sintéticas de tren/desarrollo/prueba. Mismo contexto que RAGAS; El artículo sostiene que el paradigma de división tren/prueba no se ajusta al RAG empresarial donde la respuesta existe en el documento o no. Lewis et al., Generación aumentada de recuperación para tareas de PNL con uso intensivo de conocimiento, NeurIPS 2020 (arXiv:2005.11401). El periódico que nombró a RAG y el que entrenó al perro perdiguero y al generador conjuntamente. Una referencia límite útil: el artículo RAG original era un artículo ML, aunque el patrón de ingeniería que heredó el nombre no lo es.