Estrategias de procesamiento en bloques para RAG en producción: de tamaño fijo, semánticas y padre-hijo.

Supongamos que un encargado de siniestros en una compañía de seguros le pregunta a un asistente interno: ¿qué aprobación se necesita para una reclamación por daños causados por agua de 40.000 euros, y qué se debe verificar antes de poder pagarla? El asistente cuenta con el manual actual de siniestros. Los archivos se procesaron correctamente, el OCR funcionó, el preprocesamiento eliminó los ruidos, el modelo de incrustación encontró el manual adecuado y el reordenador lo colocó cerca del principio.

Aun así, la respuesta que se obtiene sigue estando incompleta.

Un ajustador experimentado no se sorprendería. La regla no está contenida en un solo párrafo. Una oración narrativa indica que las reclamaciones que involucran daños previos sospechosos requieren una inspección independiente antes del pago. Debajo de ella se encuentra una tabla de autoridades. La página siguiente muestra un diagrama de flujo que indica que la detección de fraudes y la verificación de la propiedad también deben completarse primero. El sistema de documentos agrega el identificador del manual, su versión y la región a la que se aplica.

Para quien lo maneja, estos no son cuatro hechos separados. Son una sola regla de negocio expresada en cuatro formatos diferentes: el párrafo establece la condición, la tabla indica quiénes pueden aprobarlo, el diagrama muestra el orden de las verificaciones y los metadatos indican qué versión está en vigor.

Un divisor estándar configurado en 500 tokens puede colocar el párrafo en un bloque, la mitad superior de la tabla en otro, la fila correspondiente de la tabla en un tercero y el texto extraído del diagrama en un cuarto. Cada bloque es válido. Cada llamada de incrustación tiene éxito. El panel de control permanece en color verde. Sin embargo, los conocimientos han sido reorganizados fundamentalmente. En el momento de la consulta, el sistema debe vincular el tipo de afirmación con el rango de cantidad, asignarlo a un aprobador, encontrar los requisitos de inspección y recuperar las verificaciones, todo a partir de fragmentos que no pueden leerse por sí solos. El modelo de lenguaje recibe piezas sueltas y genera una respuesta incompleta.

Por esta razón, la depuración de RAG engaña. Los equipos cambian los modelos de incrustación, aumentan el valor top-k, adquieren un reordenador más potente o reescriben la instrucción. A veces ayuda. Con mayor frecuencia, solo compensa los daños causados durante la segmentación. Una mala calidad en RAG suele ser un problema de particionamiento disfrazado de problema del modelo de lenguaje grande.

La mayor parte de las discusiones sobre el fragmentado se reducen a un único número: 256 tokens, 512 o 1,000, junto con el grado de superposición. Esas son preguntas legítimas relacionadas con la implementación, pero la cuestión arquitectónica es diferente:

¿Qué debe permanecer unido para que siga teniendo el mismo significado cuando se recupere por separado?

Lo que sigue abarca desde las estrategias más simples hasta las técnicas que surgieron en 2024 y 2025, señala en qué casos cada una compensa su costo y finaliza con un diseño para entornos de producción capaz de manejar documentos empresariales complejos.

El lugar del fragmentado en el proceso

El fragmentado no es un paso aislado de procesamiento de texto. Es el límite entre comprender documentos limpios y crear conocimiento buscable. Todo lo que ocurre antes determina qué se puede dividir, y todo lo que ocurre después depende de si las partes conservan suficiente significado, estructura y origen para poder encontrarse correctamente.

Imagínese la ruta completa. Fuentes como PDF, tablas, imágenes, JSON, bases de datos, APIs y código son ingeridas, analizadas, limpiadas y normalizadas. Solo entonces una capa de particionamiento decide cómo cada tipo de contenido se convierte en una unidad de recuperación. Los textos narrativos pueden dividirse de forma estructural o semántica. Las declaraciones de reglas detalladas pueden ser adecuadas para representaciones a nivel de proposición. Las tablas necesitan límites acordes a su esquema. El JSON debe seguir los objetos de negocio. Las imágenes requieren descripciones visuales vinculadas al original.

Por lo tanto, un sistema de producción rara vez elige un único tamaño de bloque para todo. Un corpus puede contener representaciones a nivel de documento, sección, párrafo, proposición y token al mismo tiempo. Las parejas de recuperación padre-hijo utilizan bloques pequeños para mayor precisión y bloques más grandes para el contexto, mientras que la particionación tardía, la recuperación contextual y RAPTOR reconstruyen información que de otro modo sería descartada al dividirla.

El procesamiento en bloques tampoco termina cuando existen vectores. Los metadatos de los bloques, las versiones del documento, los enlaces padre-hijo, los controles de acceso y las referencias de origen deben mantenerse intactos durante el indexado, la recuperación, el reordenamiento, la compilación de contexto y la generación. La evaluación cierra el ciclo: las búsquedas fallidas, los contextos duplicados, las citaciones incorrectas y los patrones de consulta cambiantes deben influir nuevamente en las decisiones de procesamiento en bloques. El procesamiento en bloques en entornos de producción se centra menos en dividir los documentos y más en diseñar las unidades de recuperación sobre las cuales funciona todo lo demás.

El compromiso central

Tomemos un fragmento breve de una política:

High-risk corporate customers must complete Enhanced Due Diligence.

Facilities above EUR 10 million require Group Credit Committee approval.

Fully cash-collateralised facilities may follow the exception defined in Section 7.4.3.

Mantener todo unido preserva el contexto pero genera un vector amplio y difuso. Dividir de forma agresiva permite una recuperación precisa, pero la regla de aprobación puede desviarse de la clase de cliente a la que se aplica, y la excepción puede terminar separada de la regla que modifica.

Esa es toda la tensión: los fragmentos pequeños mejoran la precisión, los grandes preservan el contexto, y los sistemas de producción necesitan un equilibrio deliberado. Cada técnica de fragmentación es una ruta diferente dentro de este compromiso, y ninguna elimina la necesidad de conocer bien los documentos y las preguntas que realmente plantean los usuarios.

Lineamientos simples

Fragmentación de tamaño fijo

La fragmentación de tamaño fijo divide el texto en secciones de una longitud determinada, generalmente en tokens, con posibilidad opcional de solapamiento. Es sencilla, determinista y económica.

Contar tokens generalmente es mejor que contar caracteres, ya que los modelos de embedding procesan tokens. Quinientos caracteres en alemán o chino pueden contener muchas menos unidades significativas que la misma cantidad en inglés. El método codifica el texto en tokens, los procesa a intervalos fijos y decodifica cada ventana. La superposición implica que cada ventana comienza antes de que termine la anterior.

• Funciona bien para: prosa uniforme, puntos de referencia básicos, casos en los que la simplicidad operativa es lo más importante y prototipos iniciales que necesitan primero un pipeline funcional.
• Falla cuando: el significado depende de la estructura. Una condición puede terminar en el token 499 mientras su excepción comienza en el token 501, y el límite no tiene conocimiento alguno sobre la lógica de negocio.

Qué hace la superposición

La superposición sirve como seguro contra fallos en los límites. Sin ella, una oración podría dividirse en dos fragmentos, y ninguno de ellos funcionaría por sí solo. Con ella, cada fragmento incluye algo del vecino, por lo que ambos siguen siendo interpretables.

El costo es real: más vectores, mayor gasto en embeddings, más almacenamiento y listas de resultados llenas de pasajes casi idénticos. Un porcentaje del veinte por ciento es más bien una práctica habitual que una regla fija, así que úsalo como parámetro para comparar con las métricas de recuperación.

La división en fragmentos de tamaño fijo se mantiene no porque sea óptima, sino porque proporciona una línea de base estable. Si un método más avanzado no logra superarla de manera significativa en tu corpus, la complejidad adicional no está justificada.

División recursiva

Los documentos empresariales ya incluyen límites útiles en encabezados, secciones, párrafos, oraciones y listas. La división recursiva utiliza estos límites antes de recurrir a puntos de corte arbitrarios. Por ejemplo, el divisor de caracteres recursivo de LangChain prueba primero con dobles saltos de línea, que suelen marcar los párrafos. Si una parte sigue siendo demasiado grande, prueba con saltos de línea simples, luego con puntuación de oraciones, después con espacios y finalmente con caracteres individuales. El límite de tamaño es el umbral que activa cada método alternativo.

El orden de los separadores es más importante que el número de caracteres. Para políticas, procedimientos, manuales y documentación técnica bien organizados, esto suele ser una opción predeterminada muy eficaz.

Una precaución importante durante la producción: si el proceso de extracción ya ha obtenido la jerarquía, no la descarte ni pida a un divisor que la descubra de nuevo. Una sección numerada 7.4 dentro de un capítulo relacionado con préstamos ya indica qué texto pertenece al mismo grupo. Mantenga esa estructura en los metadatos y úsela para limitar las divisiones. En otras palabras, no destruya la estructura al dividir el contenido y luego intente reconstruirla al recuperarlo.

La división recursiva asume que la estructura sigue más o menos al significado, pero eso no siempre es cierto. Un párrafo puede contener tres reglas sin relación entre sí, y cinco párrafos pueden describir un único proceso. Ahí es donde entran en juego los métodos basados en el significado.

Unidades de oración y párrafo

Herramientas como spaCy y NLTK ofrecen detectores de oraciones entrenados que manejan los casos en los que la división simple por puntos interrumpe elementos como abreviaturas, decimales, títulos y signos de tres puntos. La división en párrafos es más sencilla y a menudo efectiva, ya que un párrafo es un agrupamiento elegido intencionalmente por el autor. En documentos limpios, dividir por párrafos y combinar párrafos cortos adyacentes hasta alcanzar un tamaño mínimo constituye un punto intermedio razonable entre los enfoques de tamaño fijo y los semánticos.

La desventaja radica en la variabilidad del tamaño de los bloques. Algunos párrafos contienen 50 tokens y otros 800, lo que complica el agrupamiento en lotes, aumenta la latencia al generar embeddings y dificulta predecir el tamaño del índice. Si las mejores fronteras justifican esto depende del corpus.

Ventanas deslizantes como herramienta de recuperación

Una ventana deslizante es un método de particionamiento de tamaño fijo en el que la superposición se considera un mecanismo de recuperación y no solo una forma de garantizar los límites. La lógica es la siguiente: un vector de consulta coincide mejor con el pasaje que responde directamente a él. Si dicho pasaje se encuentra en dos segmentos distintos, ninguno de los fragmentos podrá obtener una buena puntuación. Con una superposición adecuada, cada pasaje de longitud razonable aparece completo al menos en un fragmento.

Una mayor superposición mejora la capacidad de recuperación, pero a costa de la redundancia. Por encima del 30 al 40 por ciento, las listas top-k se llenan de duplicados casi idénticos que agotan el presupuesto de contexto sin aportar nuevos datos; por su parte, entre el 10 y el 25 por ciento es el porcentaje adecuado para la mayoría de los corpus. Para evaluar la superposición, mida la tasa de recuperación de duplicados junto con el Recall@k, ya que mejorar el Recall@5 al mismo tiempo que se duplican los resultados puede no mejorar la calidad de las respuestas.

Estrategias conscientes del significado

Particionamiento semántico

El agrupamiento semántico reemplaza la regla de conteo de tokens por una pregunta: ¿ha cambiado lo suficiente el tema como para iniciar una nueva unidad? Imagine una sección cuyas dos primeras oraciones tratan sobre los requisitos de inspección, la tercera aborda los límites de pago y la cuarta menciona las reglas contra el fraude. Un divisor fijo no puede detectar esos cambios de tema, mientras que un agrupador semántico bien ajustado sí puede hacerlo.

La metodología habitual consta de tres etapas. Primero, dividir el texto en oraciones con un modelo lingüístico. Luego, incrustar cada oración, o una pequeña ventana de oraciones adyacentes, con un sentence-transformer. Finalmente, calcular la distancia de coseno entre las incrustaciones vecinas y establecer un límite donde dicha distancia supere un umbral porcentual, generalmente entre el 85º y el 95º percentil de las distancias en ese documento.

Ese umbral es el parámetro crítico. Si es demasiado agresivo, las ideas relacionadas se desintegran en fragmentos diminutos e insignificantes. Si es demasiado indulgente, los temas distintos permanecen fusionados, restableciendo el ruido que se quería eliminar.

También implica un mayor costo, ya que es necesario realizar un proceso completo de incrustación antes de conocer los límites entre los temas. En documentos cortos y bien estructurados, ese costo no aporta mucho beneficio. Sin embargo, en narrativas largas con formato inconsistente, identificar cambios reales de tema puede mejorar notablemente la recuperación de información. Un límite importante: el método asume que los temas cambian gradualmente y de manera detectable entre oraciones. En textos legales o regulatorios densos, donde una sola oración puede contener tres condiciones y dos excepciones, las distancias a nivel de oración generan señales ruidosas.

División en grupos padre-hijo

Este es uno de los patrones de mayor impacto en los sistemas RAG en producción, ya que resuelve una tensión que el enfoque de unidad por unidad ignora: la mejor unidad para la recuperación de información no es necesariamente la mejor unidad para su generación.

Tomemos una sección de 2,000 tokens que abarca límites, excepciones, controles y procedimientos de escalada. Al incrustarla completa se preserva el contexto, pero se obtiene un vector vago. Al dividirla en fragmentos de 200 tokens se mejora la capacidad de recuperación, pero el fragmento coincidente podría carecer de lo necesario para que el modelo razone adecuadamente.

El método de agrupamiento en bloques padre-hijo separa estas dos tareas. Un bloque padre es una sección más grande y coherente, como toda una oración, procedimiento o subsección. Los bloques hijos son fragmentos más pequeños y específicos derivados de él: condiciones individuales, umbrales o excepciones. Solo los bloques hijos se incrustan y se buscan. Cuando un bloque hijo coincide, su identificador de padre permite obtener el texto fuente más extenso, y ese es el texto que realmente lee el modelo.

LlamaIndex y LangChain ofrecen versiones de esto a través de nodos jerárquicos, recuperación de información de tamaño pequeño a grande y recuperación del documento padre. Cada elemento hijo almacena un ID del padre en sus metadatos, y una búsqueda posterior amplía las coincidencias a sus padres antes de compilar el contexto.

En entornos regulados, los identificadores necesitan un historial real. Un ID legible que combine el documento, la versión y la sección es más seguro que un UUID arbitrario, ya que un elemento hijo de la versión 7.2 que se relacione con un padre de la versión 7.1 genera un contexto que parece plausible pero es operativamente incorrecto. Este patrón también funciona en diferentes modalidades: un elemento hijo puede ser una fila de tabla serializada, una descripción visual de un diagrama o una proposición, todos compartiendo un padre que representa una sección lógica.

Fragmentación de proposiciones

Tomemos una oración como esta de una política de préstamos: los prestatarios corporativos de alto riesgo requieren una diligencia debida reforzada además de una revisión anual, y un comité debe dar su aprobación cada vez que su exposición supere un límite establecido. Esta oración contiene tres hechos distintos. Un sistema que responda con qué frecuencia se revisan tales clientes no debería tener que analizar los criterios de aprobación para encontrar una coincidencia.

El fragmentación de proposiciones divide el texto en afirmaciones atómicas y autónomas, cada una recuperable por separado. La extracción se realiza típicamente en el momento del indexado por un modelo de lenguaje con una instrucción cuidadosamente estructurada que mantiene todas las condiciones, umbrales, calificadores y excepciones, resuelve los pronombres cuando el texto lo permite e infiere solo aquello que está expresado explícitamente. En cuanto a la oración anterior, el resultado podría ser tres afirmaciones: dichos clientes requieren una debida diligencia, necesitan una revisión anual y, al superar el umbral de exposición, requieren la aprobación del comité.

Cada proposición recibe su propio embedding, de modo que el espacio vectorial se convierte en un espacio de hechos atómicos y no de pasajes completos, lo que aumenta la precisión en preguntas específicas orientadas a buscar hechos. Aplican dos restricciones de generación:

• La proposición no es la fuente de la verdad. Es una representación generada por un modelo. En trabajos regulados, se debe recuperar la información con la proposición y luego volver al texto autoritativo para fundamentar, razonar y citar. La proposición es una entrada del índice y no una afirmación.
• El costo aumenta drásticamente. Un documento de 10,000 tokens puede generar cientos de proposiciones, cada una de las cuales requiere una llamada de incrustación, por lo que el índice crece rápidamente.

Restaurar el contexto perdido

Fragmentación tardía

La fragmentación convencional divide primero y incrusta cada parte por separado. La fragmentación tardía, introducida por Jina AI en 2024, invierte parte de ese orden.

El método de fragmentación tardía primero procesa todo el documento con un modelo de embedding de contexto amplio para obtener representaciones a nivel de token que tengan en cuenta el contexto. Posteriormente se aplican los límites entre fragmentos, agrupando los vectores de token que se encuentran dentro de cada ventana. La diferencia con respecto al uso simplemente de fragmentos más grandes es que la unidad de recuperación sigue siendo pequeña. El pasaje mantiene su enfoque, pero su vector refleja el entorno en el que apareció. Los pronombres, abreviaturas, referencias directas y términos definidos anteriormente se resuelven en el embedding y no se dejan para que los maneje el modelo en el momento de la generación.

El costo de la infraestructura es real. Se necesita un modelo de embedding de contexto amplio que ofrezca resultados a nivel de token, memoria adicional para indexación y un código de agrupamiento cuidadoso. Tampoco puede solucionar una mala segmentación: una tabla mal serializada o un diagrama incluido en el preprocesamiento permanece perdido. Lo que resuelve es la pérdida de contexto en el momento del embedding y nada más anterior. En corpus con dependencias intensas entre oraciones, como regulaciones, contratos y manuales, la mejora en la calidad del embedding puede ser significativa.

Recuperación contextual

La recuperación contextual de Anthropic, publicada en 2024, aborda el mismo problema de aislamiento de manera diferente. No modifica la arquitectura de embedding; en su lugar, enriquece el texto a recuperar de cada fragmento en el momento del indexado.

Una oración aislada que indica un límite podría no coincidir con una consulta que menciona la categoría del cliente, la jurisdicción y la autoridad de aprobación, ya que esos términos se encuentran en el documento circundante. Por lo tanto, antes de indexar se genera una breve declaración de contexto específica para cada fragmento, por ejemplo indicando de qué sección de qué versión de la política proviene el pasaje y qué define. Esa declaración se coloca al principio, y la combinación resultante se incluye en el índice.

Según la evaluación de Anthropic, combinar embeddings contextuales con BM25 contextual redujo las fallas en la recuperación de los 20 mejores resultados en un 49 por ciento, y agregar un proceso de reclasificación las redujo en un 67 por ciento. Esos números provienen de los propios corpus de Anthropic y no constituyen garantías. Las ganancias reales dependen de sus documentos, consultas, modelo de embeddings y configuración de recuperación. La lección no son las cifras, sino que agregar contexto específico del documento a fragmentos aislados puede ser de gran ayuda siempre que el significado importante se encuentre fuera de los límites del fragmento.

Ayuda especialmente con fragmentos ambiguos: filas sueltas de tablas, leyendas de imágenes, menciones a términos definidos y segmentos cuyo alcance provenía de una sección padre que ya no incluyen. También funciona de manera natural junto con la recuperación de información entre elementos padre e hijo. Rige una regla clave: el contexto generado sirve como ayuda para la recuperación y no como declaración de fuente. Si se asigna a cada segmento la misma descripción genérica, los vectores se vuelven demasiado similares, lo que perjudica la recuperación de información. Una buena contextualización solo añade aquello que un segmento necesita para ser comprendido sin depender de sus vecinos.

RAPTOR: varios niveles de abstracción

RAPTOR, abreviatura de Recursive Abstractive Processing for Tree-Organized Retrieval, aborda un límite común a los sistemas de recuperación de un solo nivel: los fragmentos detallados responden bien a preguntas factuales específicas, pero tienen dificultades con aquellas que requieren síntesis de información proveniente de distintas secciones. Compare preguntar quién aprueba una afirmación concreta con solicitar todo el marco de control de la organización para ese tipo de afirmaciones. En el primer caso hay una respuesta autorizada en una tabla; en el segundo se necesitan pruebas provenientes de reglas de inspección, autoridad delegada, políticas de respaldo o recuperación, procedimientos de revisión y vías de escalada, probablemente distribuidas en varias secciones y documentos.

RAPTOR construye una jerarquía. Los fragmentos de origen forman la capa inferior. Los fragmentos relacionados se agrupan según su similitud mediante técnicas de embedding, y un modelo de lenguaje resume cada grupo. Esos resúmenes se agrupan nuevamente y se resumen una vez más, repitiendo el proceso hasta que unos pocos resúmenes de alto nivel representen todo el documento o corpus. En el momento de la consulta, una pregunta específica puede coincidir con un fragmento individual, mientras que una pregunta más general coincide con un resumen de nivel superior; así, un mismo sistema puede manejar ambos tipos de consultas sin necesidad de cambios arquitectónicos.

La principal preocupación en la producción es el origen de los datos. Los resúmenes son interpretaciones, y las interpretaciones pueden distorsionar los umbrales, los casos límite y las excepciones, que son precisamente los detalles más importantes en el trabajo regulado. Utilice nodos de nivel superior para encontrar las partes relevantes del corpus y luego vuelva a los pasajes originales antes de generar el contenido. El resumen ayuda a localizar pruebas, mientras que el texto original es el punto de partida para que el modelo razonee. RAPTOR justifica su costo en políticas extensas, marcos regulatorios y manuales grandes donde los usuarios plantean preguntas tanto detalladas como de síntesis en una sola solicitud. En colecciones cortas o tipos de consultas uniformes, la complejidad rara vez compensa.

Contenido estructurado y no textual

Tablas: la estructura es el significado

Volver a la tabla de autoridades. Esta contiene relaciones explícitas: tipo de reclamación por daños causados por agua, rango de importe superior a 25.000 euros, y el responsable de aprobación es el gerente regional de reclamaciones. Al convertir todo esto en una secuencia de palabras, las relaciones entre columnas que dan significado a cada valor desaparecen, por lo que las tablas requieren un manejo adecuado que tenga en cuenta su estructura.

Con tablas pequeñas, suele ser mejor mantenerla intacta, especialmente cuando las consultas comparan filas o necesitan todo el rango de condiciones. Es necesario formatearla de manera que los vínculos entre columnas y filas se conserven, por ejemplo convirtiendo cada fila en pares de etiqueta-valor que nombre cada columna. En el caso de tablas grandes, las filas permiten dividirlas en segmentos más precisos, pero cada fila debe incluir sus encabezados, ya que tres valores sin etiquetas no significan nada por sí solos.

Detrás de la serialización se esconde una decisión más importante. Si los usuarios realizan consultas deterministas, como listar a todos los aprobadores para montos superiores a un valor determinado, la recuperación vectorial podría ser la herramienta completamente inadecuada. Las tablas consultadas mediante SQL o un dataframe superan a cualquier enfoque de embedding para búsquedas con filtros precisos. El principio es: no destruir la estructura explícita solo para que todo parezca texto.

JSON y registros estructurados

El mismo razonamiento se aplica a JSON. Un registro que contiene segmento, calificación, región, monto, aprobador y una bandera de revisión ya indica qué campos pertenecen entre sí, por lo que aplicar un divisor de tokens a JSON serializado ignora esto. Los registros pequeños deben permanecer completos, con un formulario de recuperación legible que muestre cada campo junto a su etiqueta. En el caso de cargas grandes, se deben identificar entidades empresariales naturales como clientes, cuentas, transacciones, eventos de evaluación o decisiones relacionadas con casos, y dividir el contenido en partes alrededor de ellas.

Dentro de un registro, se deben separar los campos semánticos de aquellos que son filtrables. Los campos a los que se refieren las preguntas en lenguaje natural deben formar parte del embedding. Campos como región, versión, unidad de negocio y fecha de vigencia suelen funcionar mejor como filtros de metadatos en el índice que como parte del vector. El prefiltrado con metadatos es más rápido y preciso para límites categóricos, además de mantener al embedding centrado en el significado.

Código: la sintaxis marca los límites

El código plantea el mismo problema en otro ámbito. Un divisor genérico que divide un archivo de Python en el token 500 podría separar una función de su instrucción de retorno o una clase de sus métodos. Para la búsqueda de código, los límites deben seguir la sintaxis: funciones, métodos, clases y módulos. El módulo ast de Python puede analizar el código fuente para convertirlo en un árbol y extraer cada función, función asíncrona y clase como una unidad completa, de modo que los fragmentos sigan la semántica del lenguaje en lugar de aproximarse a ella mediante el conteo de caracteres. Para repositorios en muchos lenguajes, tree-sitter ofrece una única interfaz de análisis para docenas de ellos y maneja casos límite que las expresiones regulares pasan por alto. La relación padre-hijo se adapta de forma natural: se puede recuperar un método con precisión y luego expandirlo a su clase o archivo cuando el modelo necesita un contexto más amplio.

Diagramas e imágenes

No trate el texto OCR como una representación completa de una imagen. Un diagrama de flujo transmite significado a través de flechas, secuencias, ramificaciones, agrupaciones y disposición espacial, elementos que el OCR no puede capturar. Utilice un modelo capaz de procesar imágenes para redactar una descripción que indique qué comunica la imagen y no solo qué palabras aparecen en ella. Almacene un puntero hacia el original. La descripción generada es la entrada del índice, mientras que la imagen de origen es lo que el sistema muestra como evidencia. En sistemas regulados, la cita debe referirse al elemento visual original y no a su descripción.

Ruteo por tipo de contenido

Los documentos reales están mezclados. Un mismo manual puede contener reglas narrativas, una tabla de autoridad, un diagrama de proceso, metadatos en JSON y referencias incrustadas. No existe razón lógica para aplicar el mismo herramienta de separación a los cuatro elementos, ya que cada uno tiene un significado distinto: un párrafo por su continuidad lingüística, una tabla por las intersecciones de filas y columnas, un diagrama por su posición, dirección y agrupación, y JSON por sus claves explícitas.

La solución de producción es un enrutador de fragmentación, un distribuidor que identifica el tipo de contenido de cada bloque extraído y lo envía a la estrategia adecuada. El enrutador no necesita ser sofisticado; su valor radica en convertir el enrutamiento por tipo de contenido en una elección de diseño explícita y no en un accidente derivado del uso de un divisor genérico. En el manual de reclamaciones, los textos narrativos irían a un proceso de fragmentación estructural o semántica, la tabla de autoridad a una serialización consciente de tablas, el diagrama de flujo a un modelo visual para su descripción y los metadatos en JSON a una separación basada en objetos.

Cada fragmento resultante debe contener los mismos metadatos esenciales, como el ID del documento, la versión, el ID del padre, la sección y la región. Esa herencia compartida permite que las etapas posteriores identifiquen que una fila de tabla, un párrafo y la descripción de un diagrama son evidencias relacionadas provenientes de una misma sección.

Cuando ganan las unidades más grandes

Una pregunta sobre la frecuencia con la que se debe revisar un tipo de cuenta tiene una respuesta del tamaño de una proposición. Pedir el marco completo de control para un tipo de reclamo requiere evidencia de varias áreas, y la recuperación de alta granularidad puede obligar al sistema a unir una respuesta amplia a partir de muchos fragmentos aislados, por lo que aparecen errores de ensamblaje incluso cuando cada fragmento es correcto.

Elegir y medir

Cómo seleccionar una estrategia

Ninguna estrategia de fragmentación es la mejor en todos los casos. La elección depende de la estructura del documento, los tipos reales de consultas, el presupuesto de latencia, la tolerancia al costo de indexación y el diseño de generación posterior. El tipo de consulta es tan importante como el tipo de documento. El mismo conjunto de políticas puede servir para búsquedas específicas sobre una frecuencia mínima de revisión y solicitudes más amplias para explicar todo un marco, y estas últimas requieren una granularidad de recuperación diferente. Si sus datos de evaluación abarcan solo un tipo, la estrategia ganadora podría tener un rendimiento inferior en tráfico real.

Una guía aproximada:

• Prosa uniforme, prototipo inicial: tamaño fijo con una superposición moderada.
• Manuales y procedimientos bien estructurados: división recursiva o basada en la estructura, manteniendo la jerarquía en los metadatos.
• Narrativas largas con formato inconsistente: fragmentación semántica, si el costo adicional genera una mejora medible.

Preguntas que requieren tanto precisión como contexto: relación padre-hijo.

Enunciados de reglas complejos y consultas basadas en hechos específicos: proposiciones con conservación del contexto padre.

Fragmentos que pierden su significado cuando se analizan por separado: recuperación contextual o agrupamiento tardío de fragmentos.

Tipos mixtos de consultas en documentos extensos: métodos jerárquicos como RAPTOR.

Tablas, JSON, código y diagramas: manejo específico según el tipo a través de un enrutador.

Pruebas de rendimiento en lugar de conjeturas

Echar un vistazo a unos pocos fragmentos y concluir que parecen razonables ayuda en la depuración, pero no constituye una evaluación real. La verdadera pregunta es si una estrategia permite al sistema recuperar las pruebas necesarias para las consultas que realmente envían los usuarios.

Cree un conjunto de evaluación que cubra diferentes necesidades: un hecho específico relacionado con una sola fila de tabla, una pregunta que requiere múltiples evidencias y que exige una oración narrativa además de una descripción del proceso, una pregunta condicional sobre una excepción y una pregunta de síntesis que abarque varias secciones. Asocie cada consulta con los IDs de las unidades de recuperación que deben encontrarse.

Las métricas de recuperación no son suficientes por sí solas. Registre el tamaño del índice en comparación con un valor de referencia de tamaño fijo, los costos de incrustación por documento, la latencia de indexación y recuperación, los tokens de contexto por consulta, la tasa de duplicados, la exactitud de las respuestas y la exactitud de las citaciones. Tres puntos adicionales en Recall@5 no tienen mucho valor si el índice se cuadruplica y los resultados están llenos de copias casi idénticas.

En un corpus típico de políticas, un patrón plausible es que la división recursiva supera a la de tamaño fijo por unos pocos puntos con el mismo costo de índice; el fragmentación semántica añade un poco más a un costo adicional modesto; la estructura padre-hijo mejora aún más el recuerdo con un aumento notable en el índice; y las proposiciones junto con sus padres alcanzan el mayor recuerdo, pero a un costo y complejidad mucho mayores. La recuperación contextual puede igualar ese nivel de recuerdo con menos crecimiento del índice, lo que justifica su uso en el momento de indexar, mientras que RAPTOR puede quedar por detrás de la estructura padre-hijo en hechos específicos pero ganar en tareas de síntesis. Considérelo como una ilustración de la naturaleza de los compromisos, y no como un resultado medido. El punto óptimo depende de las necesidades de precisión, los límites de latencia, el presupuesto de indexación y de si cada mejora justifica su complejidad.

No optimice solo la recuperación

Supongamos que una gran superposición mejora el Recall@5, pero los cinco primeros resultados ahora contienen cuatro pasajes casi idénticos de una misma oración, lo que hace que una sección relevante diferente quede fuera del límite de contexto. Una métrica mejoró y el sistema empeoró. Es necesario evaluar todo el proceso, desde la recuperación hasta el reordenamiento, la compilación del contexto y la generación final, preguntándose en cada etapa si la evidencia necesaria se ha conservado, si los duplicados ocupan espacio útil, si la respuesta es correcta y está fundamentada, y si la cita apunta a la fuente y versión adecuadas.

En los sistemas regulados, la corrección de las citas no es un detalle menor. Una respuesta puede ser factualmente correcta pero basarse en la versión incorrecta de una política. Eso sigue siendo un incumplimiento, y permanece invisible a menos que se verifique explícitamente el origen de las citas.

Una arquitectura de producción

El cambio fundamental en la forma de pensar es que un pipeline empresarial maduro rara vez necesita un procesador universal. Lo que necesita es una capa de enrutamiento que envíe cada bloque de contenido a la estrategia adecuada, mantenga metadatos de linaje compartido en todos los fragmentos resultantes y almacene enlaces explícitos hacia la fuente autoritativa.

Para el manual de reclamaciones, una configuración plausible es la siguiente: las secciones narrativas se dividen estructural o semánticamente; las cláusulas de reglas complejas se convierten en proposiciones manteniendo al elemento padre; las tablas pequeñas se serializan completas; las tablas grandes se dividen en grupos de filas con información de encabezados; los diagramas reciben descripciones basadas en modelos visuales; y los registros JSON se separan mediante objetos. Cada grupo, sea cual sea su tipo, lleva los mismos identificadores: ID del documento, versión, ID del elemento padre, sección, región y una referencia al artefacto de origen. Esta línea de herencia compartida es tan importante como los propios grupos, ya que permite reconectar una fila de tabla, una cláusula y una descripción de proceso como evidencia proveniente de una sección de una versión determinada.

Volver a la reclamación por daños causados por agua

Nunca estuvo en duda si 500 o 800 tokens era el tamaño adecuado. La fuente contenía diferentes tipos de evidencia: el párrafo indicaba que se necesitaba una inspección independiente, la tabla mostraba quién aprobaba el rango de cantidades, el diagrama detallaba las verificaciones previas al pago y los metadatos especificaban qué versión y región eran aplicables.

Una capa de particionamiento bien diseñada mantiene cada fragmento en su estructura original y registra que comparten una sección. Esto permite opciones al recuperar la información: las preguntas relacionadas con la aprobación obtienen la fila de la tabla, las preguntas sobre inspección obtienen la cláusula correspondiente, las preguntas de procesamiento obtienen la descripción del diagrama, y las preguntas más complejas recuperan varios fragmentos relacionados y se expanden hasta su padre común. Esa es la diferencia entre dividir el texto y diseñar unidades de recuperación.

El orden que se sigue no es de tamaño fijo: primero lo semántico, luego lo proposicional, donde gana la idea más reciente. Más bien: aprender el origen, conocer las consultas, mantener la estructura existente, elegir la granularidad de recuperación, restaurar el contexto faltante, preservar el origen, medir la recuperación y las respuestas, y añadir complejidad solo donde sea realmente necesario.

Una última lista de verificación antes de indexar

Antes de que los fragmentos lleguen al proceso de incrustación, cada uno debe cumplir con tres propiedades:

• Recuperable. Lo suficientemente específico como para coincidir con las consultas relevantes, y no tan amplio como para coincidir de forma vaga con todo.
• Interpretable. Contiene suficiente contexto como para mantener su significado por sí solo, o dispone de una forma fiable de recuperar ese contexto a través de una búsqueda en un elemento padre.

Rastreable. Hace referencia a la fuente autorizada: el documento exacto, versión, sección, página, tabla, imagen o registro del cual fue tomado.

Cuando falta alguno de estos elementos, la capa de particionamiento transfiere sus problemas a las tareas de recuperación, reclasificación, montaje de contexto y generación. Un almacén de vectores indexará sin problemas una unidad deficiente, una API de embeddings devolverá un vector sin quejas y un modelo podrá escribir una respuesta confiada sobre él, pero ninguno de estos casos indica que la representación sea correcta. Corregir una unidad defectuosa es lo más económico antes de que se convierta en un embedding.

Antes del lanzamiento, también planifique el registro de actividades, el manejo de secretos y configuraciones, IDs deterministas, la versionación de modelos e instrucciones, el seguimiento del origen de los datos particionados, los controles de acceso, los conjuntos de datos de evaluación, la gestión del ciclo de vida del índice y el monitoreo de la calidad de la recuperación, la latencia y los costos.