compañero de Enterprise Document Intelligence, la serie cuya filosofía se expone en Amplify the Expert.
Se acerca al ladrillo 2 (análisis de preguntas) de la arquitectura de cuatro ladrillos y muestra las lecciones que se saltan la mayoría de los tutoriales.
La mayoría de los tutoriales de RAG omiten el análisis de preguntas. La cadena del usuario va directamente a la recuperación, el coseno se ejecuta en top-k y el modelo recibe lo que haya regresado. No hacemos eso por una razón: una pregunta de usuario no es una consulta de búsqueda. Trátelo como tal y obtendrá respuestas parciales silenciosas, y en la producción es ahí donde gran parte de RAG se rompe silenciosamente.
📓 Los cuadernos complementarios ejecutables están en GitHub: doc-intel/notebooks-vol1.
La ingenua línea de base que este artículo rechaza
La canalización ingenua incrusta la cadena de usuario y solicita al almacén de vectores los k fragmentos más similares. Nada en esa configuración sabe que la pregunta tenía dos partes o que el usuario quería un valor exacto y no un párrafo. Así que gastamos un bloque adicional en la pregunta en sí: una fila en question_df con cinco columnas escritas (palabras clave, alcance, forma, descomposición, aclaración) más tablas satélite y dos resúmenes derivados (RetrievalQuery para el bloque de recuperación, GenerationBrief para el bloque de generación).
El diagrama de anatomía muestra las cinco columnas principales, pero una pregunta de producción_df incluye dos más que deciden qué tan amplia será la ventana de recuperación hasta la generación. La disciplina del contexto se mide en líneas (ni caracteres, demasiado ruidosos; ni páginas, demasiado toscas). La siguiente tabla muestra tres filas de muestra: una búsqueda de hechos, una booleana de sí/no y una pregunta de listado. Cada fila dimensiona su ventana de contexto de manera diferente, leyendo la forma de la respuesta y el patrón de descomposición.
Las dos columnas esmeralda son la disciplina barata que la mayoría de los oleoductos nunca escriben. Una búsqueda de hechos (monto de la prima, fecha de vigencia, valor deducible) casi no necesita contexto circundante: una o dos líneas antes del ancla para la verificabilidad, algunas después para la cola de puntuación. Una pregunta de listado no necesita contexto antes y una ventana de avance larga porque la lista se extiende a lo largo de la sección. El analizador llena las líneas_antes_anchor y las líneas_después_anchor a partir de la forma analizada y la descomposición; la recuperación los respeta; ningún límite mágico top-k viaja a través de la tubería.
A continuación se presentan las seis lecciones no enseñadas que mantienen unido el ladrillo.
Lección 1 – Un esquema relacional, simétrico al lado del documento
La literatura incluye “comprensión de consultas” y “reescritura de consultas”, pero ambas tratan la pregunta como una cadena convertida en otra cadena. Modelarlo como una fila en question_df más tablas satélite no es la forma en que la gente suele enmarcarlo. Lo que hace que haga clic es la simetría con el lado del documento (line_df, toc_df, span_df): ambos lados son relacionales, ambos se unen y la recuperación se convierte en un filtro a través de ellos.
Por qué es importante. La mayoría de los canales de producción almacenan la pregunta como una sola cadena dentro de la plantilla de solicitud de LLM. No existe la noción de “la pregunta tiene forma”, “la pregunta tiene un alcance”, “la pregunta tiene una descomposición”. Cuando el equipo necesita una nueva capacidad (manejar la negación, manejar preguntas compuestas, manejar rangos), el único lugar para agregarla es la plantilla de indicaciones. Seis meses después, el aviso contiene sesenta líneas de cláusulas de casos especiales, ninguna de las cuales la auditoría puede rastrear. Al estructurar la pregunta una vez en el límite del analizador, la forma en que el análisis estructura el documento en su límite elimina esa podredumbre en su origen.
Contraste concreto. El usuario pregunta “¿Cuál es el monto de la prima y el plazo de renovación?”. La línea de base ingenua incrusta esa cadena y clasifica los fragmentos. La serie llena una fila de question_df: palabras clave ["prima", "monto", "renovación", "fecha límite"], alcance "contrato", forma (monto, fecha), descomposición "independiente" (dos subpreguntas). Ahora la recuperación tiene una fila para filtrar line_df y la generación tiene una forma escrita para llenar.
Un segundo. Un asesor jurídico pregunta: "¿La cláusula de indemnización sobrevive a la rescisión y, de ser así, durante cuánto tiempo?". La forma ingenua pasa toda la cadena al LLM; la respuesta a menudo es un sí o un no sobre la supervivencia y se salta silenciosamente la duración. La serie llena question_df con forma (Booleano, Duración), descomposición "condicional" (la duración solo es significativa si la supervivencia es Verdadera), y los ladrillos posteriores saben exactamente qué subpregunta está cerrada por cuál.
→ Artículo 6A: Analice la pregunta antes de realizar la búsqueda y recorra todo el analizador de principio a fin.
Lección 2: un esquema, no un código ramificado
La mayoría de las bases de código RAG desarrollan la lógica de manejo de preguntas como código ramificado, controlado por cadenas if intent == "…" que se osifican con el paso de los meses. En su lugar, hacemos crecer el ladrillo como un esquema: una nueva capacidad es una columna agregada a question_df, editada por el experto, no una nueva ruta de código. El costo de una nueva característica permanece lineal en el número de columnas, no cuadrático en las combinaciones de ramas.
Contraste concreto. Agregue "manejo de negación" al ladrillo. Manera ingenua: nueva rama en el código ensamblador del mensaje, más pruebas, más una prueba de integración para la regresión. Forma de serie: agregue una columna negation_present (booleana), agregue una fila en el diccionario de tokens de negación, documente el comportamiento posterior y el despachador leerá esa columna donde sea necesario.
→ Artículo 6B: Los cinco campos que el GAR debe extraer de cualquier pregunta construyen las cinco columnas una por una.
Lección 3: Dos resúmenes, uno por cada ladrillo aguas abajo
El valor predeterminado es un mensaje que incluye todo, donde la recuperación debe ignorar los campos de solo generación y la generación debe volver a analizar los campos de recuperación. Los dividimos: el bloque de recuperación recibe solo aquello sobre lo que puede actuar (palabras clave, alcance, sugerencias estructurales), y el bloque de generación recibe solo lo que necesita (intención, forma de salida, exclusiones). Cada ladrillo aguas abajo lee una breve descripción de su trabajo, no el problema completo.
Contraste concreto. Para "¿Cuál es el importe de la prima en dólares, no en euros?" el resumen de recuperación son las palabras clave ["prima", "cantidad"] más el alcance "contrato". El resumen de generación tiene la forma "Importe(valor, moneda='USD')" más exclusiones ["EUR"] . La recuperación no necesita conocer la exclusión de moneda; La generación no necesita volver a extraer las palabras clave.
→ El artículo 6A divide la pregunta en dos escritos y el artículo 6B extrae las columnas.
Lección 4: El diccionario experto que supera a las incrustaciones
La historia estándar vende incrustaciones como una forma de manejar sinónimos: un usuario escribe "premium", el modelo "sabe" que se relaciona con "contribución mensual". En la práctica, concept_keywords_df asigna la palabra del usuario a la palabra del documento antes de cualquier búsqueda, por una fracción del costo y sin deriva. El experto mantiene el diccionario como wiki; el modelo de incrustación no tiene opinión sobre qué alias es canónico en su corpus.
Contraste concreto. El usuario escribe "¿Cuánto pago cada mes?". La línea de base ingenua lo incorpora, el coseno devuelve páginas genéricas de "pago". La serie verifica primero concept_keywords_df: "pagar cada mes" se asigna a ["prima", "contribución mensual", "cuota mensual"] para este corpus de seguro. La recuperación ejecuta una búsqueda de palabras clave en esos tres términos; la línea real (“prima de $124/mes”) se ilumina inmediatamente.
→ Artículo 6B: Cinco campos que el GAR debe extraer de cualquier pregunta explican el mecanismo concept_keywords_df.
Lección 5: Cuatro patrones de preguntas compuestas, ninguna silenciosa
Una pregunta de dos partes (“monto y fecha límite”) generalmente se responde por una parte y se descarta silenciosamente por la otra. La serie nombra los cuatro patrones (independiente, secuencial, unificado, condicional) y obliga al analizador a marcar cuál se aplica. Luego, el oleoducto se descompone (y corre en paralelo), se encadena (y alimenta la parte A con la parte B) o se niega a responder a la mitad que no pudo cubrir. Ninguna respuesta parcial silenciosa.
Contraste concreto. El usuario pregunta "¿Cuál es el deducible si el reclamo excede el límite y cuál es el límite?", un compuesto secuencial*. Naive RAG envía ambos como una sola cadena; el LLM responde sobre el límite y se olvida de la cláusula condicional del deducible. La serie ve descomposición = "secuencial", analiza la parte A (¿límite?) y la parte B (¿deducible si reclamo > límite?), las ejecuta en orden y envía una respuesta para cada una con su propia cita, o marca una como no encontrada si realmente lo es.
→ Artículo 6B: Cinco campos que el GAR debe extraer de cualquier pregunta establecen los cuatro patrones compuestos.
Lección 6: El despachador determinista, no el LLM, decide
El reflejo agente dice: deje que el LLM elija qué recuperadores, esquemas y fragmentos de mensajes activar por llamada. Catalogamos tres enfoques: explícito por el usuario (el formulario impulsa las activaciones), despachador determinista (las reglas en el código asignan características de preguntas a las activaciones) y LLM-decide (el modelo planifica en sí). Los dos primeros se quedan. Eliminamos el tercero para empresas, porque un sistema que vuelve a planificar cada llamada no puede auditarse de la misma manera dos veces.
Contraste concreto. La misma pregunta sobre cumplimiento se repite dos veces en el sistema. Con deterministic-dispatcher, el registro de auditoría muestra la misma ruta de envío en ambas ocasiones: decide.py línea 47 activada, ruta = "factual_lookup", métodos de recuperación ["keyword", "toc"] activados, esquema de generación AmountWithEvidence. Con LLM-decides, el registro de auditoría muestra dos rastreos de razonamiento diferentes y no se puede garantizar el mismo enrutamiento mañana. El primero es auditable. El segundo no lo es.
→ Artículo 6C: Una pregunta RAG analizada, cuatro decisiones cubren el patrón del despachador.
Las seis lecciones comparten un movimiento: dar un paso que el manual convencional trata como procesamiento de cadenas en línea y convertirlo en un ladrillo mecanografiado. Una vez que la pregunta es una fila con columnas, el resto del proceso filtra, verifica el tipo y distribuye de una manera que una cadena plana nunca podría hacerlo. Las inmersiones profundas (6A, 6B, 6C, 6bis) envían código ejecutable en corpus reales; esta pieza es el catálogo que apunta a ellos.
Una nota sobre la detección de intenciones. El Vol.1 se mantiene mínimo en cuanto a intenciones: el despachador reconoce un conjunto de referencia (búsqueda de hechos, listado, lectura rápida de resumen de parsing_summary.summary, resumen profundo de TOC + primeras líneas, resolución de referencias cruzadas, rechazo fuera del corpus), suficiente para enviar correctamente las preguntas empresariales más comunes en PDF. La taxonomía de intención completa llega al Volumen 2 (traducción, resumen de documentos, comparación, redacción, revisión), donde la matriz de intención × formato produce docenas de rutas de envío en la parte superior del lomo de cuatro ladrillos. Vol.1 mantiene la columna limpia; Vol.2 construye la matriz.
En todos los sectores y profesiones
El ladrillo trata todos los dominios de la misma manera: extrae las columnas escritas de la pregunta, deriva los dos resúmenes. El diccionario experto dentro de concept_keywords_df es específico del sector; el esquema y la lógica de despacho son universales. Cinco sectores debajo, un patrón de análisis, las mismas cinco columnas.
Lo que cambia de fila en fila es el diccionario experto. El concept_keywords_df de un corredor de seguros asigna “pago cada mes” a ["prima", "contribución mensual", "cuota mensual"]; el equivalente médico asigna “anticoagulante” a ["anticoagulante", "warfarina", "heparina", "DOAC"]; el equivalente financiero asigna la “línea superior” a ["ingresos", "ingresos netos", "ingresos GAAP"] . Las columnas, el despacho y el registro de auditoría del ladrillo permanecen idénticos.
Dónde aterrizan estas lecciones en la serie
Los artículos numerados desarrollan cada lección en código, con cuadernos ejecutables:
El artículo 6A (análisis de preguntas: tesis) establece que una cadena no es una consulta y muestra la forma relacional. El artículo 6B (análisis de preguntas: extracción) recorre las cinco familias de columnas (palabras clave, alcance, forma, descomposición, aclaración) que llenan question_df. El artículo 6C (análisis de preguntas: envío) desarrolla el despachador que convierte una pregunta analizada en decisiones de enrutamiento. El artículo 6bis (bucle de aclaración) aborda el caso en el que la pregunta es demasiado vaga para formularse y el sistema solicita una aclaración específica.
Fuentes y lecturas adicionales
La literatura de libros/artículos sobre comprensión de consultas está basada en la búsqueda del consumidor (Elastic, Google) y no se transfiere claramente a un corpus de pequeñas empresas donde el vocabulario experto es el activo. La postura de la serie es la reconstrucción de la forma relacional en la parte superior del lado del documento estructurado.
Analice la pregunta antes de realizar la búsqueda (Artículo 6A). La tesis publicada sobre el análisis de preguntas. El GAR debe extraer cinco campos de cualquier pregunta (artículo 6B). La extracción columna por columna en código. Una pregunta del GAR analizada, cuatro decisiones (artículo 6C). El patrón del despachador que convierte las columnas analizadas en decisiones de enrutamiento. Cuando los usuarios del RAG hagan preguntas vagas (artículo 6bis). El ciclo de aclaración que aprende el valor predeterminado después de una pregunta.
Al principio de la serie: