La señora no merece el clásico libro de jugadas. El artículo 3 decía que no existe la técnica EL TRAPO. Todavía tienes que elegir uno. Este artículo es el diagnóstico que le indica cuál.
La mayoría de los equipos que crean sistemas RAG utilizan el mismo manual: analizar el documento en fragmentos, incrustar cada fragmento, colocarlos en un almacén de vectores, incrustar la pregunta, recuperar el k superior por similitud de coseno y entregar el resultado a un LLM. Llámelo el clásico libro de jugadas de RAG. Cada tutorial lo enseña. Cada demostración se ejecuta en él.
Los problemas reales varían mucho más de lo que sugiere el manual. Algunos casos reales.
Tres casos en tres extremos diferentes.
Documentos con plantillas y de gran volumen. Certificados de seguro, formularios KYC, presentaciones regulatorias, estados de cuenta de corretaje mensuales. El mismo software escribe el mismo diseño en cada documento. Cien líneas de expresiones regulares extraen los campos en microsegundos. El libro de jugadas clásico también se ejecuta aquí, pero a un LLM le conviene hacer lo que el diseño le proporcionó de forma gratuita.
La misma forma en todas las industrias: recibos de nómina, extractos bancarios, informes de pruebas de laboratorio, declaraciones de impuestos, certificaciones de cumplimiento, facturas de proveedores desde un ERP. Dondequiera que una pieza de software escribe cada documento, el diseño es un contrato.
Sarcasmo en las transcripciones de atención al cliente. "Encuentre todos los comentarios sarcásticos en las grabaciones de llamadas de este mes". La puntuación estándar de sentimientos (ira, frustración, alegría) se resuelve en gran medida mediante un léxico de sentimientos: inaceptable, ridículo, frustrado, todos se marcan claramente. El sarcasmo es la excepción canónica. "Oh, fantástico servicio, solo tuve que esperar 45 minutos" obtiene una puntuación positiva en todos los léxicos, y la incorporación lo agrupa con la versión sincera porque las palabras superficiales son casi las mismas. El único método honesto es un LLM que lea cada llamada en su totalidad y juzgue la brecha entre lo que se dice y lo que se quiere decir.
La misma forma en todas las funciones: entrevistas de salida de RR.HH. en busca de frustraciones ocultas, archivos de chats internos en busca de señales de alerta culturales antes del cierre de una fusión y adquisición, transcripciones de llamadas de ganancias en busca de lugares cubiertos por el director financiero, grabaciones de llamadas de ventas en busca de promesas que el contrato no autorizó. Tono e intención, sin anclaje en el texto.
Esquemas de ingeniería (un eje completamente diferente). Dibujos, diapositivas donde se encuentran los datos en el gráfico, especificaciones técnicas con imágenes incrustadas. RAG de texto puro devuelve el título y pierde el esquema. Los modelos de visión encajan aquí y sólo aquí.
La misma forma: planos arquitectónicos, registros escritos a mano escaneados, presentaciones de diapositivas donde se encuentran los datos en el gráfico, páginas de cuadernos de laboratorio, informes de imágenes médicas. Dondequiera que el significado viva en los píxeles.
El libro de jugadas clásico es excesivo en documentos con plantillas (las expresiones regulares serían suficientes), dimensionalmente incorrecto en las transcripciones de llamadas (no existe ningún ancla) y es ciego a la modalidad en los esquemas (se requiere visión). Se ajusta a una banda intermedia de problemas y se envía como si lo cubriera todo. Esa banda media es real y la Sección 3.3 la cataloga; el costo del desajuste en el resto es lo que este artículo pretende evitar.
Este artículo es el diagnóstico. Tres pasos, en orden.
Identifique los dos ejes: los problemas de RAG no son un solo problema. Se asientan en una imagen con dos ejes: qué tan estructurados están sus documentos y qué tan controladas están sus preguntas. Cada combinación requiere una pila diferente. Identifique las técnicas por región: cada región de la imagen tiene su propia pila: expresión regular, recuperación de secciones, recuperación híbrida (búsqueda léxica + similitud de incrustación), visión, agregación SQL. Un tercer eje (la dimensión agente, sección 2.4) se ubica encima de estos y decide cuánto control del tiempo de ejecución obtiene el LLM. El catálogo que aparece más adelante en el artículo asigna cada región a su zona técnica. Localice su propio caso: ¿Dónde se ubican sus documentos en el eje de la complejidad? ¿Dónde se ubican sus preguntas en el eje de control? La intersección apunta a una región y a las técnicas que se ajustan a ella.
No estás aquí para construirlo todo. Estás aquí para encontrar dónde te sientas y luego leer las partes de la serie que coinciden. La mayoría de los lectores se saltarán la mitad.
Una nota antes de que el artículo se vuelva técnico. La mayoría de los RAG empresariales tienen dos formas: extraer campos de documentos con plantilla (el caso de expresiones regulares en la apertura) o responder preguntas de formato libre sobre documentos heterogéneos como contratos e informes (donde el resto de la serie pasa la mayor parte de su tiempo). Las transcripciones conversacionales son una tercera forma real, común en servicio al cliente, recursos humanos y cumplimiento; el sarcasmo es la pregunta más difícil que plantean. El contenido de visión pura (esquemas, presentaciones de diapositivas) y las preguntas a escala de corpus (Parte IV) surgen con menos frecuencia. Es posible que conozca uno o dos de estos. La siguiente cuadrícula le permite ubicar su caso a la vista.
Este diagnóstico es una parte de un marco más amplio: Enterprise Document Intelligence Volumen 1 construye RAG empresarial ladrillo a ladrillo, y las regiones de la cuadrícula que este artículo asigna apuntan a los artículos de la serie donde se construye cada técnica.
1. Dos ejes: complejidad del documento y control de preguntas
Cada problema que encontraremos en esta serie se ubica en algún lugar de dos ejes:
Complejidad del documento: ¿Qué tan redundante es la estructura de sus documentos? ¿Puede un analizador abordar los campos por posición, por encabezado, o necesita un modelo que vea la página? Control de preguntas: ¿Quién formula la pregunta? ¿Un ingeniero que escribe un mensaje fijo o un usuario que escribe libremente en un cuadro de chat, posiblemente sin tener idea de qué preguntar?
Estos dos ejes son casi independientes. El único acoplamiento: un documento de plantilla fija (Nivel 1, a continuación) generalmente obliga a hacer preguntas con plantilla de ingeniero (Nivel A), ya que el usuario nunca escribe una pregunta. Fuera de esa esquina, cualquier nivel de documento puede emparejarse con cualquier nivel de pregunta.
1.1 Eje del documento: de una plantilla fija a un modelo de visión
El volumen 1 permanece dentro del alcance del PDF. Los documentos multiformato (Word, Excel, PowerPoint, correo) son territorio del Volumen 2; Todo lo que aparece a continuación describe un PDF a la vez.
Los documentos varían en cuanto a redundancia estructural: qué parte de su diseño se comparte en todo el corpus. Cinco niveles cubren la mayoría de situaciones empresariales.
Nivel 1: plantilla fija: cada documento tiene la misma estructura, los mismos campos en el mismo lugar, a menudo producidos por el mismo software: certificados de seguro de un único corredor, formularios KYC, declaraciones de impuestos, certificaciones de cumplimiento interno. La estructura es tan predecible que puedes abordar los campos por sus coordenadas en la página. Técnica: extracción basada en expresiones regulares o coordenadas, sin modelo.
Nivel 2: Familia de plantillas: los documentos siguen un patrón reconocible con variaciones (diferente proveedor, diferente software, diferente año): facturas entre proveedores, arrendamientos entre propietarios, contratos de trabajo entre empresas en el mismo marco legal. Técnica: una expresión regular por plantilla más un LLM de algunos disparos como respaldo cuando la plantilla se desvía.
Nivel 3: estructura heterogénea: cada documento tiene su propia estructura (secciones, encabezados, tablas de contenido), pero las estructuras no se repiten en todos los documentos: contratos legales personalizados, manuales técnicos de diferentes proveedores, informes financieros. Técnica: analizar la estructura, recuperarla a través del propio índice del documento.
Nivel 4: No estructurado/OCR: archivos PDF escaneados, fotografías en papel, correos electrónicos, notas de formato libre: el texto está ahí pero el diseño está degradado o ausente. Técnica: OCR con puntuación de confianza, luego recuperación híbrida (léxico + incrustaciones) sobre el texto ruidoso.
Nivel 5: Visualmente rico: documentos donde el significado reside en lo visual: esquemas, tablas de datos densas incrustadas como imágenes, presentaciones de diapositivas con gráficos, dibujos de ingeniería. Un análisis de texto puro pierde la respuesta. Técnica: un modelo con capacidad de visión en la imagen de la página, a menudo combinado con RAG en el lado del texto.
Cuanto más abajo esté en este eje, más pagará por documento. Lo correcto es llevar cada problema tan lejos como lo permita un análisis honesto. Un equipo que decide que su corpus es "demasiado complejo para expresiones regulares" sin verificar la redundancia estructural está eligiendo la respuesta costosa por defecto.
1.2 Eje de preguntas: de un mensaje fijo a un chatbot multiturno
El eje de preguntas es el que se saltan la mayoría de los equipos. Dos preguntas pueden parecer idénticas sintácticamente pero requerir pilas completamente diferentes. La dimensión que importa es quién controla la cuestión y cuánto.
Nivel A: Plantilla de ingeniero: La pregunta es un parámetro del sistema: “Extraer la fecha de vigencia”, “¿Cuál es el número de póliza?”. El ingeniero escribió el mensaje, lo calibró y lo probó en mil documentos. El usuario, si lo hay, ni siquiera escribe una pregunta. Técnica: extracción de campo, salida estructurada, no es necesario ningún paso de análisis de preguntas.
Nivel B: El usuario llena los espacios: la pregunta es una plantilla con valores proporcionados por el usuario: "Muéstrame la cláusula sobre {tema} en este contrato". El usuario elige el tema de una lista o escribe una etiqueta. La forma de la consulta es fija, sólo varía un slot. Técnica: recuperación de secciones, búsqueda en una taxonomía conocida.
Nivel C: Consulta gratuita del usuario, única: el usuario escribe lo que quiere, el sistema responde de una vez: “¿Por qué este contrato difiere del del año pasado?”. Esta es la configuración clásica de chatear con su documento, donde la canalización debe analizar la pregunta, decidir qué recuperar y responder. Técnica: RAG de documento único con análisis de preguntas.
Nivel D: Consulta gratuita más aclaración. Igual que C, pero el sistema puede volver a preguntar al usuario cuando la pregunta es ambigua: "¿A qué página te refieres? ¿Te refieres al subinquilino o al inquilino principal?" Esto es lo que hacen los chatbots reales y amplía drásticamente la gama de preguntas que un sistema puede responder. Técnica: análisis de preguntas más un ciclo de aclaración.
Un pequeño ejemplo para concretar la idea de aclaración. Imaginemos que un usuario pregunta: “¿Cuál es el deducible?” en un solo contrato de seguro que menciona deducibles en tres secciones (hogar, automóvil, cobertura de viaje). Un canal ingenuo recupera algo plausible y devuelve una respuesta incorrecta y segura. Un sistema que pueda preguntar (“¿Qué cobertura: hogar, automóvil o viaje?”) soluciona el problema desde su origen.
Esto impone una restricción en sentido ascendente al análisis. Para detectar que el usuario mencionó la "página 3" o "el segundo apéndice", su analizador debe haber conservado los números de página, los índices de las secciones y el texto de los encabezados como metadatos en cada fragmento. El número de página suena trivial cuando se mira un documento individual, pero es el ejemplo más simple de una decisión de análisis de la que depende el lado de la pregunta. El artículo 5 trata esto en detalle.
La escala de preguntas es una pregunta separada, no un nivel en este eje. "¿Cuántos archivos PDF hay en su corpus? ¿Son homogéneos o heterogéneos?" es una preocupación relacionada con los datos, recogida en la sección 3.2 del diagnóstico y desarrollada en la Parte IV (Artículos 14 a 17). Mezclarlo en el eje de preguntas desdibuja dos cosas diferentes, por lo que queda fuera.
1.3 Del caso a la zona de la técnica
Cruce los dos ejes y cada problema de RAG de PDF aterrizará en algún lugar de la imagen. Cada región requiere una pila diferente. La mayoría de los equipos construyen para una o dos regiones y fingen que el resto no existe. La siguiente cuadrícula es una herramienta de pensamiento, no una taxonomía estricta: los problemas reales a menudo se sitúan entre dos casos y los límites entre zonas son borrosos a propósito.
La esquina superior izquierda (filas 1-2, columnas AB) es territorio determinista. Plantillas fijas, preguntas controladas. No se necesita ningún LLM para la extracción de campo en sí; el LLM aparece como máximo como un recurso alternativo cuando la plantilla se desvía. Aquí es donde vive el error del corredor de seguros desde la apertura. La mayoría de los flujos de trabajo de documentos empresariales caen aquí y la mayoría de ellos están sobrediseñados. El caso del corredor desde el principio es el ejemplo canónico: una pila de LLM a sesenta mil euros al año cuando una expresión regular de cien líneas sería suficiente.
La banda central (filas 2 a 4, columnas CD) es RAG de un solo documento. El caso de uso de chatear con su PDF que muestra cada demostración de proveedor. Es real, es difícil y el resto de la serie pasa la mayor parte del tiempo aquí. Fragmentar (dividir el documento en unidades de búsqueda), recuperación (elegir las correctas), reclasificar (un pase preciso en la lista corta) y evaluación (saber que funciona) son importantes cuando el documento es heterogéneo y la pregunta está abierta.
La fila inferior (fila 5, todas las columnas) es territorio de visión. Cuadros, esquemas, tablas densas. Un analizador de texto pierde la respuesta independientemente de cuán inteligente sea la recuperación. Los modelos de visión encajan aquí y sólo aquí. El artículo 10 analiza cuándo el paso de la visión vale la pena y cuándo no.
Los casos a escala de corpus se encuentran fuera de la cuadrícula, ya que la cuadrícula es un PDF a la vez. Cuando la pregunta se dirige a muchos PDF a la vez (“encontrar cada contrato de proveedor con un límite de responsabilidad inferior a un millón”), el diagnóstico pasa a la Parte IV (Artículos 14 a 17): clasificación en el momento de la ingesta, campos estructurados, SQL en el lado estructurado, RAG en las preguntas no estructuradas residuales.
La grilla no es una receta. Es un control de cordura. Localice su problema, observe la zona de técnica y pregunte si el sistema que está construyendo coincide. Si está construyendo más profundamente de lo que requiere el caso, no está pagando nada. Si construye a poca profundidad, descubrirá la brecha en la producción.
2. Las técnicas por caso y lo que no es técnica
Una vez que haya colocado su problema en la cuadrícula, sabrá aproximadamente qué familia de técnicas se aplica. El resto de la serie desarrolla cada técnica en detalle.
La familia determinista (expresiones regulares, anclajes de sección que ubican un encabezado por nombre, extracción basada en coordenadas que extrae un campo de un cuadro delimitador fijo en la página) no tiene su propio artículo. Es la base que todo ingeniero debería conocer. Todo ingeniero que lea esta serie ya debería saber cómo escribir una expresión regular. El objetivo de incluirlo en el mapa es recordarte que es una opción. Cuando la estructura de su entrada es fija, es la opción.
La familia RAG de documento único es de lo que tratan las partes II y III de la serie. Análisis sintáctico basado en el diseño (Artículo 5), análisis y calibración de preguntas (Artículo 6), recuperación como selección de alcance (Artículo 7), generación como ejecución controlada (Artículo 8), recuperación híbrida y enrutamiento TOC (Artículo 9), análisis adaptativo que incluye visión (Artículo 10), referencias cruzadas (Artículo 11), listado y síntesis (Artículo 12), canales compuestos con bucles de retroalimentación (Artículo 13). Cada una de estas es una técnica que alcanzarás en la banda central de la cuadrícula.
La familia a escala de corpus es la Parte IV. El problema del corpus (Artículo 14), la preparación de un corpus consultable a partir de una carpeta de archivos PDF (Artículo 15), la ontología del corpus (Artículo 16), la consulta con filtro SQL primero y la recuperación después (Artículo 17). Estos aparecen cuando pasas de un PDF a un corpus de archivos PDF.
Si su problema está en la esquina superior izquierda de la cuadrícula, puede dejar de leer la serie después del Artículo 5 (análisis) y pasar al Artículo 15 (preparación de un corpus consultable). Si su problema se encuentra en la banda media, necesitará las Partes II y III. Si su problema es a escala de corpus, necesitará la Parte IV encima de la base. El mapa te dice cuál.
2.1 Elige la técnica más sencilla que funcione
El instinto de todo equipo de ingeniería es construir el oleoducto más potente que puedan justificar. Ese instinto está mal aquí. El instinto correcto es elegir la técnica menos poderosa que resuelva el problema real. Tres razones:
Costo: con dos millones de documentos al año, una expresión regular en una máquina virtual es un error de redondeo; un LLM por documento cuesta sesenta mil euros. Latencia: microsegundos frente a segundos, la diferencia entre "se siente instantáneo" y "se siente como esperando". Confiabilidad: una expresión regular coincide o no y el ingeniero puede leer la regla; un LLM produce respuestas que a veces son sutilmente incorrectas y los modos de falla son más difíciles de detectar, lo que lo descalifica para la extracción con grado de auditoría.
La mayoría de los flujos de trabajo de documentos de producción aterrizan en un híbrido: un núcleo determinista que maneja la mayor parte de manera limpia, con un LLM alternativo para los casos en los que el formato se rompe. Ese híbrido casi siempre tiene la forma correcta y casi nunca es lo que los equipos construyen primero.
2.2 El contexto prolongado no es una salida
Cada pocos meses alguien anuncia que “RAG está muerto” porque las ventanas de contexto se han hecho más grandes. El argumento: volcar todo el documento en el mensaje y dejar que el modelo lo resuelva.
Esto funciona para un documento y un usuario. No funciona en producción por cuatro razones:
Desperdiciado: una pregunta típica no necesita todo el documento. La fecha de vigencia de un contrato se encuentra en una página; enviar los otros treinta y nueve paga por tokens que no se utilizarán. Omite información: Transformers lee de manera confiable lo que está al principio y al final de un contexto largo y rutinariamente omite lo que está en el medio, por lo que es posible que la página relevante nunca se lea incluso cuando está en el mensaje. No escala: los casos de uso reales involucran muchos documentos. Ninguna ventana contextual albergará jamás un archivo corporativo; en cualquier escala significativa, tienes que elegir qué enviar, y esa elección es la recuperación. Sin respuesta fundamentada: sin una recuperación y cita explícita, no se puede saber de qué parte del documento proviene la respuesta, no se puede verificar ni se puede auditar. Para cualquier caso de uso empresarial en el que la respuesta deba ser rastreable, eso es descalificador.
Los contextos largos son útiles como herramienta, especialmente para el análisis profundo de un solo documento. No son un sustituto de la recuperación. Cualquiera que te diga lo contrario está vendiendo algo.
2.3 Las técnicas sofisticadas suelen ser palabras clave disfrazadas
Las técnicas que se venden como “avanzadas” a menudo resultan ser trabajos de palabras clave en otra forma y, a menudo, en una forma incorrecta. HyDE (Hypothetical Document Embeddings, Gao et al., 2022) es el ejemplo más claro. El protocolo solicita a un LLM que escriba el documento hipotético que respondería a la consulta y luego lo recupera contra la incorporación de ese documento hipotético. El argumento es que lo hipotético lleva el vocabulario que usaría una respuesta real, ampliando el margen del coseno.
El cuaderno complementario prueba esto en el documento de Atención: pregunte por qué la atención de múltiples cabezas, deje que HyDE genere su pasaje, compárelo con el vocabulario real de la sección 3.2.2. Las dos listas se superponen exactamente en una frase, el título de la sección. HyDE escribe vocabulario de libros de texto de ML (relaciones semánticas, dependencias contextuales, procesamiento paralelo, patrones de atención); el artículo escribe vocabulario operativo (capas de atención, atención codificador-decodificador, diferentes posiciones, transformaciones lineales).
HyDE entendió la pregunta. Nunca leyó el documento. En la empresa, las palabras clave existen en algún lugar de la página y el experto en el dominio que ha leído la página las conoce. HyDE paga por consulta para inventar vocabulario que a menudo ni siquiera aparece en la página. El diccionario de expertos (Artículo 6), una lista seleccionada del vocabulario real del corpus creada una vez con el experto en el dominio, hace el mismo trabajo a una fracción del costo y se reutiliza en cada pregunta futura.
2.4 Dejar que el LLM elija el caso
Cada combinación de nivel de documento y nivel de pregunta es un caso elemental, con una técnica de comparación. En el Volumen 1, el ingeniero elige el caso en tiempo de compilación y envía la técnica. El despachador (Artículo 13) codifica la sabiduría de enrutamiento del equipo en Python; el LLM critica los resultados dentro de bucles fijos; cada ladrillo es auditable. Esto es suficiente para la gran mayoría de RAG empresariales.
Una extensión natural hace que el propio LLM elija el caso en tiempo de ejecución, observe la pregunta, la clasifique en un caso y elija la técnica a aplicar. Eso es lo que la industria de 2026 llama RAG agente. El Volumen 3 (Agentic Bricks) construye esa capa de selección en tiempo de ejecución sobre los ladrillos que produce el Volumen 1. El cambio se trata de quién decide cuándo, no de los ladrillos en sí: las pilas de agentes todavía utilizan las mismas primitivas de análisis, recuperación y generación que el Volumen 1 audita y prueba.
3. Localiza tu caso, en la práctica
3.1 Posicionar el sistema alrededor del experto que existe
El siguiente diagnóstico necesita una entrada que la mayoría de los equipos omiten: ¿quién es el usuario de este sistema?
Para casi todos los RAG empresariales, la respuesta es el experto que ya conoce los documentos. No soy un usuario de dominio abierto que escribe ninguna pregunta. No es un navegador curioso que explora un archivo público. El abogado leyendo un contrato. El asegurador revisando una cotización. El oficial de cumplimiento que audita una cláusula. Alguien que haya leído documentos como estos durante años y que conozca el vocabulario, los casos en los que un término significa dos cosas y los modos de fallo a los que hay que prestar atención.
El trabajo del sistema queda entonces claro: ampliar a ese experto, no reemplazarlo. Codificar su vocabulario, sus desambiguaciones, sus heurísticas año tras año. Deje que la tubería maneje el volumen; deje que el experto siga siendo la fuente de la verdad.
Esto es importante ante la grilla, porque cambia qué casos son realistas. Un equipo que dice “cualquiera puede preguntar cualquier cosa en todo el archivo” elige el caso inferior derecho de forma predeterminada: pregunta abierta, corpus mixto, el más difícil. Un equipo que dice "nuestro asegurador verifica un campo conocido en un tipo de documento conocido" está eligiendo el territorio superior izquierdo, a menudo de expresiones regulares.
El encuadre rara vez es propiedad de los documentos o de las preguntas. Es una elección que hace el equipo. La mayoría de los equipos lo heredan de los chatbots de los consumidores sin darse cuenta. Primero, coloque el sistema alrededor del experto que ya está allí. Luego lea el caso en la cuadrícula a la que apunta la respuesta.
3.2 Las preguntas de diagnóstico
Antes de escribir cualquier código, resuelva estas preguntas. En voz alta, frente a una pizarra, con los expertos del dominio en la sala.
Acerca de los documentos: ¿Qué tan parecidos son en todo el corpus? ¿Texto nativo u OCR? ¿Cuántos archivos PDF tienes? ¿Son homogéneos o heterogéneos? (Aquí es donde las preocupaciones a escala de corpus entran en el diagnóstico: conducen a la Parte IV). ¿Ingestión estática o diaria? ¿En qué parte del eje del documento se ubican?
Sobre las preguntas: ¿Quién las encuadra? ¿Un ingeniero en tiempo de diseño o un usuario en tiempo de ejecución? ¿El sistema es único o puede solicitar una aclaración? ¿La respuesta está siempre en un documento o distribuida en varios? ¿Qué significa no responder: aceptable o inaceptable? ¿En qué parte del eje de preguntas se ubican?
Acerca de las restricciones: ¿Es necesario que la respuesta sea rastreable hasta la fuente? ¿Qué tan preciso (mejor esfuerzo o grado de auditoría: cada cita rastreable hasta una línea fuente, cada respuesta reproducible)? ¿Cuál es el presupuesto de costos por documento? A veces, la diferencia entre expresiones regulares y LLM es la diferencia entre rentable y no.
Las respuestas le indican un caso en la red. El caso te indica una zona técnica. La zona técnica le indica los artículos del resto de la serie que necesitará.
3.3 Casos empresariales comunes en la red
Un puñado de patrones aparecen repetidamente en enfrentamientos reales. La mayoría de los lectores se reconocerán en uno de estos.
Extracción de campos de un formulario de plantilla fija. Piense en certificados de seguro de un corredor, formularios KYC de un banco, declaraciones de impuestos de una administración: el mismo software escribe el mismo diseño en cada página. Caso: documento de nivel 1, pregunta A, esquina superior izquierda. Pila: expresión regular en campos direccionables por coordenadas, con un respaldo de LLM para la rara deriva. El manual clásico es excesivo aquí, y ese es el error más común que encontramos en proyectos reales.
Extracción de campos entre variantes de plantilla. Piense en facturas de cientos de proveedores, arrendamientos de propietarios, contratos de trabajo de empresas en el mismo marco legal: cada documento sigue uno de los pocos patrones reconocibles. Caso: documento de nivel 2, pregunta A o B. Pila: una expresión regular por plantilla reconocida, más una extracción LLM de algunas tomas cuando el documento no coincide con nada en el registro. Clasificación antes de la extracción.
Preguntas y respuestas sobre un contrato personalizado largo: cada contrato está estructurado de manera diferente, las secciones varían y los glosarios de diez páginas no se repiten. El usuario hace preguntas de forma libre sobre el contrato que tiene delante. Caso: nivel de documento 3, pregunta C o D, banda media. Pila: RAG completo de un solo documento con enrutamiento TOC, recuperación híbrida, generación basada en esquemas. Aquí es donde los cuatro ladrillos de la serie soportan cada uno su propio peso.
Leer una presentación de diapositivas o un esquema: piense en dibujos de ingeniería, presentaciones financieras donde los datos se encuentran en el gráfico, especificaciones técnicas con imágenes incrustadas: el análisis de texto puro pierde la respuesta por completo. Caso: nivel de documento 5, cualquier columna de preguntas, fila inferior. Pila: modelo con capacidad de visión en la imagen de la página, combinado con RAG en el lado del texto para la prosa alrededor de las imágenes.
Fuera de la red – territorio del corpus: “Encuentre todos los contratos de proveedores con un límite de responsabilidad inferior a un millón” en cientos o miles de contratos. La cuadrícula de un solo PDF deja de ser el marco correcto; la pregunta se dirige al corpus, no a un documento. Pila: extracción de campos en el momento de la ingesta, campos estructurados almacenados en una base de datos, SQL en el lado estructurado, RAG solo como respaldo para las preguntas no estructuradas residuales. Los artículos 14 a 17 (Parte IV) desarrollan esto.
Fuera de la red, sin estructura en la que anclarse: una novela, una clasificación de intenciones, detección de sarcasmo. El documento no tiene estructura, el vocabulario no tiene términos característicos y la pregunta requiere comprender el tono o la intención en lugar de localizar un pasaje. Stack: un LLM que escanea todo el texto párrafo por párrafo, decidiendo qué marcar. No es un problema de RAG en el sentido del Volumen 1; La sección 2.4 da pistas sobre dónde pertenece este tipo de toma de decisiones en tiempo de ejecución (Volumen 3).
Si su caso no coincide con ninguno de estos, realice el diagnóstico en la sección 3.2 y el resultado le indicará cuál de los patrones anteriores es el más cercano.
4. Conclusión
Ejecute el diagnóstico en su propio corpus antes de escribir el código, idealmente con los expertos del dominio en la sala. El resultado es la lista de artículos del resto de la serie que necesita leer y la lista que puede omitir. Los equipos que consiguen que RAG entre en producción son los que localizaron su problema en la red primero. Los equipos que todavía se están sintonizando seis meses después suelen ser los que comenzaron a construir antes que ellos.
El siguiente artículo abre la Parte II con el primer ladrillo: el análisis de documentos. Todo lo que se pierde allí no se puede recuperar más tarde, por inteligente que sea la recuperación.
5. Fuentes y lecturas adicionales
La cuadrícula de dos ejes es un mapa de dónde encaja cada enfoque en la complejidad del documento y el control de preguntas en un solo PDF. La afirmación de que el contexto prolongado no reemplaza la recuperación en la que se apoya la cuadrícula está fundamentada por Liu et al. (Perdidos en el medio, TACL 2024) y Lee et al. (punto de referencia de contexto largo, 2024). La fila de visión se corresponde con Faysse et al. (ColPali, 2024). La demostración de HyDE utiliza la técnica de Gao et al. (HyDE, 2022). La extensión agente insinuada en la sección 2.4 (el LLM escogiendo el caso en tiempo de ejecución) es la dirección que se desarrolla el Volumen 3 sobre los ladrillos construidos aquí.
Misma dirección que el artículo:
Liu et al., Perdidos en el medio: cómo los modelos de lenguaje utilizan contextos largos, TACL 2024 (arXiv:2307.03172). Los modelos omiten información sistemáticamente a mitad de la entrada. Respalda la afirmación de que un contexto prolongado no es una salida. Lee et al., ¿Pueden los modelos de lenguaje de contexto largo incluir la recuperación, RAG, SQL y más?, 2024 (arXiv:2406.13121). Datos concretos sobre dónde el contexto largo reemplaza a la recuperación y dónde se interrumpe. Faysse et al., ColPali: Recuperación eficiente de documentos con modelos de lenguaje visual, 2024 (arXiv:2407.01449). Recuperación de visión-lenguaje en la propia imagen de la página. Ancla la fila visual de la cuadrícula. Gao et al., Recuperación densa precisa de disparo cero sin etiquetas de relevancia (HyDE), 2022 (arXiv:2212.10496). La técnica de incrustación de documentos hipotéticos probada en la sección 2.3.
Ángulo diferente, contexto diferente:
Yao et al., ReAct: Sinergia del razonamiento y la actuación en modelos lingüísticos, ICLR 2023 (arXiv:2210.03629). Documento fundacional de la línea LLM-picks-tools-at-runtime. El Volumen 3 desarrolla esto sobre los ladrillos que construye el Volumen 1. Schick et al., Toolformer: Los modelos de lenguaje pueden aprender a usar herramientas por sí mismos, NeurIPS 2023 (arXiv:2302.04761). Misma dirección que ReAct. Gao et al., Generación aumentada de recuperación para modelos de lenguaje grandes: una encuesta, 2024 (arXiv:2312.10997). encuesta RAG; trata a RAG como un paradigma con preocupaciones compartidas (calidad del recuperador, fidelidad del generador).