Retrieval Augmented Generation, abreviado RAG, combina el potencial de los modelos de lenguaje con el conocimiento específico de una empresa. Este enfoque permite incorporar documentos y datos internos de manera dirigida en las respuestas sin perder el control sobre la propia información. De este modo, RAG se percibe cada vez más como una tecnología clave para usar modelos de lenguaje de forma segura y con soberanía de datos. En la práctica, sin embargo, pronto se hace evidente que una simple búsqueda vectorial en combinación con un LLM no es suficiente para obtener resultados realmente consistentes y de alta calidad. Para aprovechar al máximo el potencial de RAG, son necesarios métodos y optimizaciones adicionales.

Para mejorar la calidad de una aplicación RAG no basta con intervenir en un solo punto del proceso. Las optimizaciones pueden aplicarse en diferentes fases, desde la preparación de los datos y la forma en que se dividen y generan los embeddings de los documentos, hasta la selección y evaluación de la información relevante para la generación de respuestas. Una distinción clara de estas categorías ayuda a implementar de manera precisa las medidas adecuadas y a abordar sistemáticamente los puntos débiles. A partir de esto, se pueden emplear distintos enfoques para optimizar de forma específica los sistemas RAG.

Categorías para optimizaciones en el proceso RAG

Preparación de documentos
Antes de que los documentos entren en un sistema RAG, deben prepararse de forma fiable. Esto incluye la extracción de texto de diversos formatos como PDF, Word, PowerPoint o correo electrónico. Igualmente importante es eliminar contenidos irrelevantes como encabezados y pies de página, elementos de navegación o textos de plantilla recurrentes. En esta fase también se realiza la normalización de conjuntos de caracteres y la unificación del lenguaje. Adicionalmente, los documentos pueden enriquecerse con metadatos como autor, fecha o tipo de documento. Estos trabajos iniciales garantizan que los siguientes pasos trabajen con datos limpios y estructurados, lo que constituye la base para una alta calidad en todo el proceso RAG.

Chunking
Una vez que los documentos han sido extraídos y limpiados, se dividen en secciones más pequeñas, denominadas chunks. El chunking determina de manera decisiva cómo se podrá aprovechar más tarde el conocimiento para embeddings y recuperación. Los chunks pueden formarse basándose en la longitud de caracteres, párrafos o títulos. En escenarios más avanzados, el chunking se realiza semánticamente, evitando que oraciones o párrafos se fragmenten artificialmente. Puede ser útil una cierta superposición de chunks para no perder las transiciones entre secciones. Los contenidos tabulares o las listas también se tratan de manera específica en esta fase para no perder su estructura.

Embedding
En la fase de embedding, los chunks preparados se convierten en vectores. Estos vectores representan el significado semántico de los textos y permiten buscarlos en la base de datos de vectores. Para casos de uso generales, se emplean modelos entrenados con conjuntos de datos amplios y no específicos. Capturan el lenguaje en muchos contextos, pero no están adaptados a dominios concretos. Si se procesan contenidos de dominios altamente especializados, puede resultar útil ajustar los embeddings con un fine-tuning en datos sectoriales o entrenar modelos propios. Los modelos de embedding multilingües también son relevantes cuando hay contenidos en distintos idiomas. La normalización y el control de calidad de los embeddings son cruciales para crear una base coherente para la recuperación.

Indexación y almacenamiento de vectores
Tras el embedding, los chunks se almacenan e indexan en una base de datos de vectores. La elección del índice y sus parámetros influye en la calidad y la latencia de la recuperación. Decisiones importantes incluyen HNSW o IVF, la función de distancia, parámetros como M y efSearch, cuantización como PQ u OPQ, fragmentación y replicación, reindexado incremental, así como cambios de índice con control de versiones y rollback.

Retrieval
En la fase de recuperación, se buscan los embeddings que corresponden a una consulta concreta del usuario. La consulta también se convierte en un vector y se compara con los chunks almacenados. Normalmente se genera una lista de candidatos conocida como top K resultados. Para mejorar la calidad de estos resultados existen varias estrategias: por ejemplo, métodos híbridos que combinan búsqueda vectorial con búsqueda clásica por palabras clave, o Multi Query Retrieval, en el que una consulta se reformula en múltiples variantes. También se pueden incorporar metadatos en la ponderación, de modo que, por ejemplo, se prioricen documentos recientes o de ciertos departamentos.

Generación de respuestas
Una vez seleccionados los mejores chunks de la lista de candidatos, se incorporan en el prompt del modelo de lenguaje. La calidad de la respuesta depende en gran medida de cómo se integren estas informaciones en el prompt. Una estructura clara, la indicación de fuentes y la evitación de redundancias son determinantes. También el diseño del prompt en sí puede mejorar la calidad, por ejemplo, instruyendo al modelo para que responda de manera precisa y basada en hechos.

Feedback y mejora continua
Un sistema RAG no es un producto estático, sino que evoluciona mediante feedback y monitorización. Los usuarios pueden valorar si una respuesta les ha sido útil. Estos comentarios pueden emplearse para optimizar gradualmente la pipeline. La evaluación automatizada también juega un papel importante, por ejemplo, mediante benchmarks o preguntas de prueba con respuestas conocidas. Así se asegura y mejora la calidad del sistema a largo plazo.

Seguridad y acceso
Los derechos de acceso deben aplicarse a nivel de documento y chunk. Esto incluye filtros basados en roles o atributos ya en la fase de recuperación, enmascaramiento de datos personales antes del embedding, separación de tenants en los índices y un registro de auditoría completo de fuentes y consultas.

Orquestación y rendimiento
La operación requiere un control y escalado fiables. Esto abarca caching de embeddings y resultados de búsqueda, procesamiento por lotes y asíncrono, backpressure y límites de tiempo, reintentos ante errores, así como autoescalado y planificación de capacidad para embedding, indexación y búsqueda.

Contexto conversacional y estado de sesión
Los diálogos multi-turno necesitan reglas sobre cómo usar y almacenar historial y contexto. Esto incluye reformulación de consultas con vista al historial, límites claros entre contexto de corto y largo plazo, referencia de sesión a través de varios pasos y olvido controlado de contenidos sensibles.

Gestión del conocimiento y ciclo de vida de los datos
El conocimiento empresarial cambia. Un catálogo de datos con linaje, versionado de documentos, fechas de validez y caducidad, retirada de contenidos obsoletos, así como plazos definidos de retención y eliminación aseguran actualidad, trazabilidad y cumplimiento normativo.

Preparación de documentos

Clasificación de documentos

La clasificación de documentos asigna los archivos entrantes a uno o varios tipos útiles. El objetivo es proporcionar desde el inicio una categoría fiable a cada documento, por ejemplo contrato, factura, acta, presentación, directriz o ticket de soporte. Esta asignación determina el recorrido posterior por la pipeline. Decide qué extractores son adecuados, qué reglas de chunking aplicar, qué modelo de embedding utilizar, los niveles de seguridad necesarios y los filtros posteriores en la recuperación. La clasificación debe distinguirse claramente de la extracción de texto, que solo extrae el contenido del formato. Aquí se trata del tipo de documento en su conjunto.

Funcionamiento. Primero se generan características. Estas incluyen extractos de texto, título, nombre de archivo, metadatos, señales de maquetación sencillas como la presencia de tablas o encabezados típicos, así como indicios de dominio como número de cliente o número de contrato. Un modelo entrenado evalúa estas características y devuelve una probabilidad para cada clase. Según las necesidades, se elige una clase única o se asignan varias, por ejemplo factura y confidencial. Los casos dudosos se controlan con umbrales y pasan a una revisión manual o a una ejecución adicional con reglas extra.

Sin clasificación de documentos, los pasos posteriores trabajan a ciegas. Las facturas podrían tratarse como presentaciones, las tablas se perderían como texto continuo y las reglas de seguridad actuarían demasiado tarde. Esto da lugar a chunks inapropiados, embeddings de menor calidad, latencias más altas por procesamiento innecesario y respuestas basadas en fuentes equivocadas. En situaciones de auditoría falta la justificación trazable de por qué un documento se procesó de cierta forma. Una clasificación de documentos fiable es por tanto un pilar central para la calidad, la seguridad y la reproducibilidad en todo el proceso RAG.

Extracción de texto de distintos formatos

La extracción de texto de diversos formatos significa convertir de forma fiable el contenido de archivos fuente en una representación uniforme y legible por máquina. El foco está en reconocer el tipo de archivo y aplicar un parser adecuado que solo entregue lo que el formato ofrece de forma nativa. Esto incluye texto continuo, señales de estructura simples como límites de párrafo y los metadatos nativos del documento. La extracción no realiza limpieza de contenido ni corrección de maquetación. El resultado de esta fase es un flujo de texto consistente con estructura básica y una referencia a las posiciones originales en el documento para permitir citas precisas en fases posteriores.

Un ejemplo ilustrativo es un correo electrónico en formato EML con un adjunto. La extracción lee el texto del mensaje de la parte correcta, conserva asunto y fecha como metadatos nativos y almacena los adjuntos por separado, sin reescribir ni truncar su contenido. La limpieza de contenido o la eliminación de elementos de navegación no se lleva a cabo en esta fase.

Si esta etapa falta o no se implementa bien, se generan daños colaterales en todos los pasos siguientes. Textos vacíos o dañados hacen que contenidos importantes no entren en el repositorio de conocimiento. Codificaciones de caracteres erróneas producen palabras corruptas, inutilizando los embeddings posteriores. Fragmentos mezclados de distintas partes del documento llevan a la recuperación de secciones irrelevantes. Sin una extracción fiable, el sistema en su conjunto resulta impreciso, difícil de citar y poco comprensible para los usuarios.

Eliminación de boilerplate y texto de relleno

La eliminación de boilerplate y texto de relleno consiste en filtrar de manera dirigida las partes de texto sin valor informativo. Esto incluye navegación, encabezados, pies de página, avisos de cookies, secciones de aviso legal, barras laterales, firmas automáticas de correo y siempre los mismos avisos de confidencialidad. Esta fase se distingue claramente de la extracción de texto, que solo entrega texto bruto y estructura básica. Técnicamente, la limpieza se basa en el reconocimiento de patrones repetidos en múltiples páginas y en características estructurales de objetos HTML o PDF. Áreas sensibles como tablas, bloques de código y citas se protegen mediante reglas para no eliminarlas. Sin esta medida, los embeddings se crearían a partir de boilerplate y relleno en lugar de basarse en la información esencial.

OCR para documentos escaneados

El OCR para documentos escaneados significa procesar cualquier fuente cuyo contenido o texto exista solo como píxeles. Esto abarca PDFs escaneados, TIFF, JPEG, PNG, archivos de fax, fotos y capturas de pantalla, así como imágenes incrustadas en Word o PowerPoint. En cuanto un documento contiene texto seleccionable, se aplica la extracción de texto. En documentos mixtos se trabaja por zonas: las áreas de imagen pasan por OCR, las de texto se extraen.

El proceso comienza con la preparación de la imagen. Se corrigen inclinaciones y distorsiones, se ajustan contraste y nitidez y se reducen ruidos. A continuación se realiza un análisis de maquetación para segmentar zonas de texto, líneas y palabras, definiendo el orden de lectura. El reconocimiento convierte los segmentos de imagen en cadenas de texto, guiado por ajustes de idioma y diccionarios apropiados. El resultado son texto y metadatos como número de página, coordenadas y un valor de confianza para cada unidad reconocida.

Sin esta medida, el contenido de las imágenes permanece invisible. Pasajes importantes no entran en los embeddings, el retrieval no encuentra las secciones relevantes y las respuestas resultan incompletas.

Detección de idioma y codificación

La detección de idioma y codificación significa determinar de forma fiable, antes de cualquier otro procesamiento, en qué idioma está un contenido y qué codificación de caracteres usa. El objetivo es decodificar correctamente el texto de entrada a Unicode y asignar a cada documento o sección una etiqueta de idioma fiable. Esta fase se diferencia de la extracción de texto, que solo lee formatos.

Detección de tablas y formularios

La detección de tablas y formularios implica identificar contenidos estructurados en documentos como tales y transformarlos en un formato legible por máquina en lugar de tratarlos como texto continuo. El objetivo es reconocer de manera fiable filas, columnas, encabezados, celdas combinadas, filas de sumas y unidades, así como, en formularios, la relación entre etiquetas de campo y valores. Esta fase se separa claramente de la extracción de texto, pues aquí no se trata solo de caracteres, sino de estructura. Técnicamente, el proceso comienza con un análisis de maquetación que emplea límites de tabla, retículas o líneas, espacios en blanco y alineación. A partir de estas pistas se generan celdas con coordenadas, orden y tipos de datos. En formularios se crean pares clave-valor, se detectan casillas marcadas y se asigna la opción seleccionada en campos desplegables. Se tipifican además números, monedas y fechas. Cada celda o campo detectado conserva referencias a página y posición para permitir citas exactas en etapas posteriores.

Sin esta medida se pierden conexiones esenciales. Las tablas se convierten en texto sin estructura, las columnas se mezclan y los números o importes pueden interpretarse mal en fases posteriores, lo que conduce a errores o respuestas inconsistentes a preguntas sobre sumas, cantidades o elementos específicos.

Named Entity Recognition (NER) para metadatos

La Named Entity Recognition (NER) para metadatos detecta en los textos menciones de elementos relevantes y las almacena como características estructuradas. Esto incluye personas, empresas, productos, proyectos, números de contrato, números de cliente, lugares, importes, monedas, indicaciones temporales y referencias a normas o leyes. El objetivo no es clasificar todo el documento, sino capturar menciones individuales por documento y por chunk para disponer de una base precisa para búsqueda, filtrado y citación. Sin NER, estos vínculos permanecen ocultos en el texto continuo. El retrieval no puede filtrar por cliente, proyecto o periodo, el reranking se basa solo en similitud textual tosca, documentos importantes quedan relegados y la generación de respuestas carece de fuentes sólidas. Las citas se vuelven imprecisas y aumentan los costes y la latencia al procesar chunks irrelevantes en exceso. La NER para metadatos crea la base para resultados más precisos, citas trazables y respuestas fiables.

Detección de duplicados y control de consistencia

La detección de duplicados y el control de consistencia aseguran que contenidos idénticos o muy similares entren en el repositorio de conocimiento solo una vez y que versiones y metadatos sean coherentes. Primero se normalizan los documentos, por ejemplo eliminando artefactos técnicos y unificando espacios. Después se generan huellas de texto mediante shingles de palabras o caracteres y hashes como SimHash o MinHash. Un valor de similitud decide si es un duplicado exacto o cercano. Para duplicados encontrados, el sistema elige una versión canónica según reglas claras, por ejemplo mayor nivel de aprobación, fecha más reciente o metadatos más completos. Todas las demás versiones se descartan o se almacenan como referencias a la fuente canónica. A nivel de chunk se puede aplicar de nuevo el procedimiento para evitar embeddings redundantes. El control de consistencia verifica además campos obligatorios y rangos de valores por tipo de documento, detecta números, fechas o sumas contradictorias e incorpora información de versión y aprobación como metadatos para mantener la claridad en retrieval y citación.

Sin esta medida, el índice crece con contenidos redundantes, aumentando el almacenamiento y los costes de embedding. El retrieval muestra resultados duplicados o desactualizados, el reranking se ve distorsionado por chunks casi idénticos y las respuestas pueden citar datos contradictorios. En auditorías falta trazabilidad, los usuarios pierden confianza y las correcciones no se propagan totalmente al seguir circulando versiones antiguas.

Validación y controles de calidad de datos

La validación y los controles de calidad de datos garantizan que solo contenidos útiles y completos ingresen en la pipeline. Se verifica la estructura y el contenido de un documento junto con sus metadatos. Esto incluye longitudes mínimas de texto, codificación de caracteres correcta, idioma reconocible, orden coherente de páginas, éxito en la detección de tablas y formularios, formatos válidos de fechas y números, campos obligatorios por tipo de documento y calidad suficiente en los resultados de OCR. Los resultados de estas pruebas se almacenan como estado y métricas. Los documentos que violan reglas se envían a cuarentena o se procesan de nuevo. Solo los contenidos aprobados pasan la puerta de entrada y se autorizan para chunking y embedding.

Sin esta medida, textos vacíos o corruptos entrarían en el índice. Los embeddings representarían ruido en lugar de contenidos relevantes, el retrieval mostraría resultados inapropiados, las citas referenciarían lugares erróneos y las respuestas perderían precisión. Además, aumentarían costes y latencia al indexar y buscar documentos defectuosos, y la trazabilidad sufriría al descubrirse los errores demasiado tarde.

Análisis de maquetación y orden de lectura en PDFs y escaneos

El análisis de maquetación y el orden de lectura en PDFs y escaneos describe la detección de la estructura visual de un documento y la reconstrucción del orden de texto correcto para su lectura por máquinas. El objetivo es identificar y agrupar bloques relacionados como títulos, párrafos, columnas, notas al pie, marginalia y elementos gráficos, y linearizarlos según el orden de lectura humano. Esta fase se separa del OCR, que convierte píxeles en caracteres; el análisis de maquetación asigna estos caracteres a bloques y define la secuencia. También difiere de la detección de tablas y formularios, que tipifica estructuras especiales.

El procesamiento comienza con la segmentación de la página en texto y no texto. Líneas, espacios en blanco, alineación, tamaños de fuente y espaciado indican columnas y secciones. Dentro de cada bloque se reconocen líneas y palabras con coordenadas. Reglas sobre saltos de columna, jerarquías de títulos y rutas de lectura garantizan una correcta linearización. Se conservan referencias a página y posición para permitir citas precisas. En documentos multipágina, el análisis evita mezclar encabezados y pies de página con el texto continuo y enlaza correctamente las continuaciones de secciones. El resultado es un texto limpio con estructura básica y un conjunto de anclajes que describen la posición visual original.

Sin esta medida aparecen errores típicos. Las columnas se mezclan, los pies de foto aparecen en medio de oraciones, las notas al pie interrumpen el texto continuo, los saltos de línea generan separaciones de palabras incorrectas y párrafos relacionados se separan. Los embeddings representan entonces una señal desordenada, el retrieval encuentra resultados irrelevantes y la generación de respuestas no puede citar fuentes con precisión, ya que los anclajes apuntan a posiciones incorrectas. Aumentan latencia y costes al requerirse correcciones posteriores y al detectarse fallos tarde. Un análisis de maquetación fiable con orden de lectura correcto es por tanto requisito para un chunking preciso, citas sólidas y respuestas coherentes.

Resolución de entidades a IDs empresariales para clientes, proyectos y productos

La resolución de entidades a IDs empresariales para clientes, proyectos y productos significa vincular de forma inequívoca las menciones de texto con los datos maestros. El objetivo es que “Müller Maschinenbau” en el texto no sea solo una cadena de caracteres, sino un enlace fiable al ID de cliente del CRM con su forma jurídica, ubicación, responsabilidades y periodo de validez. Esta fase difiere de la NER, que marca la mención como organización o producto. La resolución de entidades asigna esa mención a un ID empresarial concreto y registra la decisión con un valor de confianza, marca temporal y origen.

El procesamiento comienza normalizando nombres, variantes ortográficas y caracteres. Luego se obtienen candidatos de las tablas de datos maestros usando nombre, dominio de correo, número de identificación fiscal, número de artículo o clave de proyecto. Un matcher evalúa candidatos con reglas y similitudes estadísticas. Los casos inciertos se resuelven usando similitud de nombres, dirección, idioma, departamento y menciones conjuntas. El resultado es una asignación única o una incertidumbre marcada. La asignación se almacena como metadato por documento y por chunk, incluida la versión de los datos maestros, para que filtros de búsqueda, permisos y citas funcionen de forma estable.

Sin esta medida surgen duplicados y confusiones. El retrieval no puede filtrar con fiabilidad por cliente o proyecto, empresas idénticas con distinta ortografía se tratan como entradas diferentes, los permisos por cliente fallan y las respuestas citan procesos erróneos. En auditorías falta procedencia clara, las correcciones no se propagan totalmente y las métricas de uso y calidad se distorsionan al no asociar eventos con el ID correcto. La resolución de entidades es por tanto la base para filtros precisos, separación de tenants, citas rastreables y análisis sólidos.

Taxonomía y ontología en concordancia con el vocabulario corporativo

La taxonomía y el alineamiento de ontologías con el vocabulario de la empresa consiste en vincular los términos usados en los documentos con un sistema de conceptos acordado a nivel corporativo. Una taxonomía clasifica términos en clases y subclases, una ontología añade relaciones como “pertenece a”, “causa”, “aplica a” o “reemplaza”. El objetivo es que realidades iguales o relacionadas sean buscables bajo un término canónico, independientemente de ortografía, abreviatura, idioma o jerga sectorial. Este paso difiere de la NER, que solo marca menciones, y de la resolución de entidades, que asocia nombres a registros maestros. Aquí se unifica el nivel de significado para que búsqueda, filtrado, permisos y análisis usen un vocabulario común.

En la práctica, primero los departamentos definen un glosario controlado. Para cada término hay una ortografía preferida, sinónimos permitidos, abreviaturas habituales, traducciones disponibles y variantes no deseadas. Cada registro recibe un ID de concepto estable. Al procesar los documentos, los términos detectados se comparan con este glosario. Por chunk se almacenan como metadatos el ID de concepto, el término preferido, la ortografía original y la posición en el texto. Una ontología añade relaciones entre conceptos como “pertenece a”, “parte de”, “reemplaza” o “es versión de”. La pipeline usa estos metadatos más adelante. El retrieval puede filtrar por concepto e incluir sinónimos, el reranking puede priorizar coincidencias exactas de concepto y la generación de respuestas utiliza la designación actual y puede explicitar relaciones. Es importante la diferenciación: la limpieza de contenido, el chunking y el embedding siguen siendo pasos separados que se benefician de los metadatos de concepto.

Sin este alineamiento aparecen lagunas sistemáticas. La búsqueda omite contenidos porque no se unifican sinónimos, abreviaturas o traducciones. El reranking ordena por mera similitud textual en lugar de igualdad semántica. Las respuestas usan denominaciones inconsistentes y parecen contradictorias. Los filtros temáticos fallan. Las métricas de frecuencia y tendencias no son comparables al existir variantes del mismo concepto. No se pueden aplicar reglas de negocio o compliance de forma segura. El alineamiento con el vocabulario corporativo crea una capa de significado compartido, aumenta recall y precisión y hace los resultados trazables.

Anclajes de página y sección para citas precisas

Los anclajes de página y sección para citas precisas aseguran que cada afirmación en el sistema se pueda rastrear de forma inequívoca a una ubicación en el documento original. Se trata de una vinculación estable compuesta por el identificador del documento, número de página o diapositiva, denominación de la sección y opcionalmente párrafo, línea o posición de carácter. Estos anclajes se generan inmediatamente en la extracción o el OCR y se almacenan inalterados como metadatos en el texto y los chunks. Se diferencian del análisis de maquetación, que solo reconoce la estructura, y de la NER, que marca menciones. Los anclajes proporcionan la dirección para citar exactamente la fuente.

Técnicamente, se crea un identificador único por página y sección y se asocia con las posiciones. En PDFs esto incluye página, título de sección y coordenadas. En presentaciones, número de diapositiva y nombre del marcador de posición. En páginas web, la URL y el identificador del elemento. Estos identificadores permanecen estables incluso cuando el contenido se integra en chunks o se almacena en una base de vectores. La generación de respuestas y la evaluación pueden así citar cualquier afirmación con documento, página o diapositiva y sección. Además, las actualizaciones se gestionan de forma segura al poder comparar anclajes antiguos y nuevos y migrarlos si es necesario.

Sin esta medida falta un anclaje de fuente inequívoco y ya no es posible verificar la ubicación exacta en el documento original. Los lectores y auditores no pueden consultar la sección con fiabilidad, la evidencia en auditorías y compliance pierde fuerza, y aumenta el riesgo de confusiones entre versiones o secciones idénticas. Al actualizarse, los enlaces quedan rotos por no existir anclajes estables para su migración. En conjunto, la trazabilidad y la reproducibilidad disminuyen a pesar de que el texto citado permanezca igual.

Chunking

Chunking orientado a la estructura

El chunking orientado a la estructura requiere marcadores de estructura fiables obtenidos de la extracción y del análisis de maquetación. Un chunk corresponde a una unidad existente como bloque de título, sección, párrafo, lista, tabla o bloque de código. Los párrafos muy cortos del mismo nivel pueden unirse, los párrafos muy largos pueden dividirse en fronteras de oraciones dentro de esa unidad. No se realizan cortes que atraviesen unidades. Los límites de longitud de caracteres sirven como tope técnico, pero no definen el corte. Si faltan estos marcadores de estructura o resultan poco fiables, este método no se utiliza y se recurre a otros procedimientos, como el chunking semántico.

Sin chunking orientado a la estructura surgen chunks mixtos donde título, medio párrafo y elementos ajenos coinciden. Las definiciones se fragmentan, se pierden referencias y el retrieval aporta fragmentos sin sentido completo. La generación de respuestas necesita más contexto, consume más tokens y aporta citas menos precisas. Con una clara orientación estructural las unidades informativas permanecen intactas, las citas son exactas y los pasos posteriores trabajan sobre una base estable.

Chunking semántico con NLP

El chunking semántico con NLP divide textos según unidades de contenido, no según formatos externos. El corte sigue el tema y la intención del mensaje, incluso si un documento no tiene secciones formales claras o si las secciones existentes son demasiado amplias. Así complementa el chunking orientado a la estructura. Donde falta estructura fiable, la segmentación semántica ofrece unidades de sentido más precisas.

Su implementación empieza con una segmentación de oraciones. Luego, procedimientos NLP analizan el flujo de texto en busca de rupturas temáticas. Señales de cambio incluyen palabras clave, transiciones, contrastes o saltos claros en el contenido. En esos puntos se forman chunks para que cada unidad quede semánticamente cerrada. Los segmentos muy cortos pueden fusionarse con vecinos temáticos, mientras que los muy largos se cortan en límites naturales de oraciones.

Sin chunking semántico se obtienen fragmentos mixtos con demasiado contenido irrelevante. El retrieval da resultados imprecisos y la generación de respuestas debe procesar contexto innecesario. Como resultado, disminuyen la precisión y la eficiencia, aunque la información exista. El chunking semántico crea unidades de sentido bien delimitadas y mejora notablemente la calidad de los resultados.

Tamaño de chunk adaptable según el contexto

El tamaño de chunk adaptable según el contexto significa que los chunks no se forman rígidamente con una longitud fija, sino que se ajustan de forma flexible al contenido y a las condiciones técnicas. Mientras el chunking semántico con NLP responde a la pregunta dónde cortar, el tamaño adaptable se ocupa de cuán grande debe ser el chunk. El objetivo es que cada chunk sea una unidad completa, pero sin ser ni demasiado pequeño ni demasiado grande.

Las longitudes fijas tienen la ventaja de ser sencillas y previsibles. Garantizan no exceder la longitud máxima de entrada de los modelos de embedding y mantienen un tamaño uniforme en la base de vectores. Sin embargo, suelen cortar a mitad de párrafos o tablas, creando brechas sin sentido semántico que empobrecen el retrieval y sobrecargan la generación de respuestas con información irrelevante.

El tamaño adaptable resuelve esto teniendo en cuenta propiedades del documento como longitud de párrafos, densidad de texto, estructuras tabulares y límites de oración. Párrafos cortos o elementos de lista se unen hasta alcanzar una longitud adecuada. Párrafos largos se dividen en puntos lógicos antes de exceder la ventana de contexto del modelo. Los límites de tokens siguen siendo un tope técnico, pero ya no determinan el punto de corte.

Sin tamaño adaptable aparecen fragmentos sin coherencia o chunks excesivamente grandes, que se procesan de manera ineficiente y reducen la precisión. Con un procedimiento adaptable las unidades informativas permanecen completas, la calidad del retrieval aumenta y la generación de respuestas trabaja con menos pero más relevante contexto.

Chunking con ventana deslizante

El chunking con ventana deslizante describe un método en el que los chunks se solapan para no perder transiciones entre secciones. En lugar de dividir el texto en bloques consecutivos, se desliza una ventana de longitud fija sobre él y el siguiente chunk comienza antes de que termine el anterior. De este modo, los chunks comparten pasajes comunes que actúan como colchón y garantizan que la información relacionada no se fragmente.

A diferencia del chunking estructural o semántico, el chunking con ventana deslizante no se basa principalmente en párrafos o cambios temáticos, sino en una estrategia técnica de redundancia. Suele emplearse adicionalmente cuando el texto se procesa de forma lineal y carece de estructura clara. La ventaja es que, incluso en cortes poco afortunados, parte del contexto aparece en ambos chunks y queda completo en al menos uno de ellos.

Sin esta técnica se pierden estas transiciones. Los embeddings representan fragmentos aislados sin contexto. El retrieval ofrece resultados formalmente correctos pero sin la conexión crítica, y la generación de respuestas trabaja con información a medias, lo que genera imprecisiones. El método de ventana deslizante previene estas brechas al conservar deliberadamente contexto duplicado.

Chunking jerárquico

El chunking jerárquico significa que un documento se descompone en múltiples niveles de granularidad simultáneamente. En lugar de usar solo párrafos o secciones, se generan chunks en distintos niveles de la estructura del documento, manteniendo sus relaciones. Por ejemplo, existen chunks a nivel de capítulo, sección y párrafo. Todas las unidades contienen anclajes de fuente y referencias jerárquicas, lo que permite a la etapa de recuperación elegir la granularidad adecuada.

Este enfoque difiere del chunking estructural, que solo sigue la estructura visible, y del chunking semántico, que busca rupturas temáticas. El chunking jerárquico combina ambas perspectivas y crea un esqueleto multicapa. Así, las consultas pueden obtener tanto una visión general como detalles.

Ejemplo: Un informe interno de proyecto está dividido en capítulos, subcapítulos y párrafos numerados. Con chunking jerárquico, cada párrafo se indexa como chunk, y también cada subcapítulo y cada capítulo, manteniendo metadatos que las vinculan. Cuando una consulta requiere una visión global, se usan las unidades grandes; para preguntas detalladas, el sistema accede a los párrafos finos.

Sin chunking jerárquico hay que elegir una única granularidad. Si se eligen chunks grandes, las respuestas son imprecisas y las citas poco exactas. Si se eligen chunks pequeños, se pierde la visión de conjunto. Con un enfoque jerárquico, ambas perspectivas están disponibles y la pipeline puede escoger según la consulta, aumentando precisión, flexibilidad y trazabilidad.

Pipelines específicas por tipo de documento

Las pipelines específicas por tipo de documento implican usar reglas y procesos distintos para cada clase de documento en lugar de una rutina estándar común. La idea es que contratos, manuales, correos electrónicos o tablas tienen estructuras muy diferentes y deben segmentarse de manera distinta. Cada pipeline define cómo proceder con extracción, chunking, enriquecimiento y asignación de metadatos.

A diferencia de los métodos genéricos, que tratan todo el contenido igual, las pipelines específicas respetan las particularidades de cada formato. Por ejemplo, contratos se cortan según párrafos y cláusulas, manuales por capítulos y secciones, presentaciones por diapositivas y viñetas, y tablas por filas y columnas. Las pipelines producen chunks que, aunque indexados de forma uniforme, están adaptados al tipo de documento.

Sin pipelines específicas surgen chunks que no reflejan estructuras clave. Los párrafos se fragmentan, las filas de tabla pierden sus columnas y las diapositivas se convierten en bloques de texto inútiles. El retrieval solo encuentra palabras y no unidades relevantes, y la generación de respuestas pierde precisión y trazabilidad. Con pipelines a medida por tipo de documento se conserva la estructura y el sistema RAG puede operar tanto con precisión legal como técnica.

Chunking centrado en entidades

El chunking centrado en entidades significa dividir un documento no solo según estructuras formales o secciones semánticas, sino alrededor de las posiciones donde aparecen entidades importantes. Las entidades son, por ejemplo, personas, empresas, productos, proyectos, números de contrato, lugares, importes o períodos de tiempo. La idea es que cada entidad se capture completamente en un chunk y su contexto se mantenga. Así, más tarde se pueden realizar búsquedas y filtros específicos directamente sobre esas entidades.

La diferencia con otros métodos es que aquí la entidad misma define el punto de corte. Mientras el chunking estructural sigue párrafos y el semántico sigue temas, el chunking centrado en entidades agrupa o marca claramente todas las menciones de una entidad en un chunk.

Sin este enfoque la información sobre una entidad se distribuye en varios chunks no relacionados. El retrieval devuelve fragmentos individuales pero no el contexto completo. Una respuesta sobre el proyecto ORN 2025 podría contener solo la mitad de la información o mezclar datos de distintos proyectos. Con chunking centrado en entidades se crea un conjunto claro por entidad que se puede buscar, filtrar e integrar correctamente en las respuestas.

Chunking consciente de tablas y listas

El chunking consciente de tablas y listas asegura que contenidos estructurados como tablas o listas no se conviertan en texto continuo, sino que se mantengan como chunks independientes. Mientras los métodos normales dividen el texto en párrafos o unidades semánticas, este procedimiento reconoce explícitamente estructuras tabulares, numeraciones y viñetas, formando segmentos lógicos. El objetivo es preservar la relación entre columnas, filas o elementos de lista y evitar que se pierda al recuperar información.

Una diferencia clave con los métodos puramente textuales es que aquí se conserva la estructura interna. Una tabla no se trata como un bloque de texto largo, sino que se almacena como chunk completo o se divide en chunks por fila o columna según convenga. En las listas, el bloque entero puede almacenarse como un chunk, y a la vez cada elemento de la lista como chunk propio con referencia a la lista madre.

Sin chunking consciente de tablas y listas, la estructura se diluye en texto lineal. Los números quedan sin contexto, los puntos de la lista se pierden y el retrieval solo reconoce palabras, no lógica tabular. La generación de respuestas no puede aportar citas precisas, sino fragmentos imprecisos de largos bloques de texto. Con chunking consciente de tablas y listas, las estructuras permanecen intactas, haciendo las respuestas mucho más precisas y trazables.

Reglas impulsadas por el dominio

Las reglas impulsadas por el dominio en el chunking implican que la división de documentos no solo siga estructuras generales o unidades semánticas, sino también directrices específicas del área de negocio. Estas reglas reflejan la forma de trabajar y la terminología de la organización, garantizando que las unidades pertinentes para el dominio se mantengan como chunks independientes.

A diferencia de los métodos genéricos, aquí no solo aplican criterios técnicos como longitud o límites de párrafo, sino requisitos explícitos del dominio. En el ámbito jurídico, por ejemplo, cláusulas y párrafos nunca se dividen. En medicina, cada diagnóstico o informe puede tratarse como un chunk único. En desarrollo de software, funciones de código o bloques de configuración pueden considerarse unidades indivisibles.

Sin reglas del dominio se producen cortes arbitrarios dentro de estructuras clave. Una cláusula se fragmenta, un diagnóstico se reparte en varios fragmentos o una función de código aparece en partes inconexas. El retrieval devuelve trozos, y la generación de respuestas pierde coherencia y trazabilidad. Con reglas del dominio se asegura que la división siga los requisitos del área y se preserve la consistencia profesional.

Chunking controlado por presupuesto de tokens según el modelo objetivo

El chunking controlado por presupuesto de tokens según el modelo objetivo significa ajustar el tamaño de los chunks para que encajen con la longitud máxima de contexto del modelo de lenguaje. Los modelos solo pueden procesar un número limitado de tokens a la vez. Con ventanas de contexto pequeñas, los chunks deben ser muy compactos para dejar espacio a la pregunta y la respuesta planeada. Con ventanas grandes, los chunks pueden ser más extensos, ya que varios pueden procesarse sin exceder los límites técnicos. No se trata de crear una jerarquía de chunks grandes y pequeños, sino de adaptar cada chunk al presupuesto de tokens disponible.

Un manual con capítulos extensos, por ejemplo, se dividirá en segmentos de pocos cientos de tokens con una ventana pequeña. Con una ventana amplia, los segmentos pueden ampliarse para cubrir pasos completos de configuración. Aun así, la granularidad permanece lo bastante fina para que el retrieval seleccione segmentos relevantes sin manejar bloques de diez páginas inabarcables.

Sin esta adaptación, los chunks o bien se recortan o bien se procesan de forma ineficiente. Con un dimensionado acorde al modelo, se mantiene el equilibrio entre precisión, eficiencia y uso óptimo de la capacidad del modelo.

Almacenamiento multicore de una misma parte como sección y párrafo con vinculación

El almacenamiento multicore de una misma parte como sección y párrafo con vinculación significa que un documento se indexa en varios niveles de granularidad simultáneamente. Una sección larga se almacena como un chunk grande y también se descompone en chunks más pequeños, por ejemplo párrafos. Ambas variantes se enlazan en el índice para que el retrieval elija el nivel de detalle adecuado según la consulta.

La diferencia con el chunking jerárquico es que aquí no se construye todo el documento en múltiples niveles, sino que se duplican partes específicas cuando se sabe que una sección puede ser relevante tanto en su totalidad como en fragmentos. Por ejemplo, una cláusula legal de un contrato con varios párrafos se almacena como chunk completo para recuperarse entera y a la vez cada párrafo como chunk independiente para preguntas concretas sobre “límites de responsabilidad en la suma X”. Los metadatos mantienen claro que ambas variantes provienen del mismo origen.

Sin multicore storage hay que elegir una granularidad. Con solo chunks grandes, las respuestas resultan sobrecargadas e imprecisas. Con solo chunks pequeños se pierde la visión global y la trazabilidad. Con almacenamiento multicore se ofrecen ambas variantes en paralelo, retrieval y generación de respuestas pueden elegir según convenga, y los resultados permanecen precisos y completos.

Límites estrictos de bloque para código, tablas y fórmulas

Los límites estrictos de bloque para código, tablas y fórmulas significan que estas estructuras especiales nunca se fragmentan al hacer chunking, sino que se tratan como unidades cerradas. La razón es que dichos bloques solo tienen sentido completo. Un fragmento de código no ejecutable, una tabla sin todas sus columnas o una fórmula incompleta carecen de valor.

Este enfoque difiere de los métodos que dividen textos según longitud o párrafos. Mientras que en el texto continuo puede causar menos problemas si se recorta a mitad de frase, fragmentar bloques estructurados suele provocar pérdida de información. Por eso se definen límites duros que el chunking respeta.

Sin esta medida surgen fragmentos inútiles. Una fórmula podría incluir solo la parte izquierda de una ecuación, una tabla solo la mitad de sus columnas o un bloque de código el encabezado sin cuerpo. El retrieval devuelve resultados incompletos y la generación de respuestas debe adivinar lo que falta. Los límites estrictos aseguran que las estructuras complejas permanezcan intactas y que entren al proceso RAG como unidades de conocimiento completas.

Conclusión

La optimización de una aplicación RAG comienza con la preparación de documentos y el chunking. Ambas fases sientan las bases para todos los pasos posteriores como embedding, indexación, recuperación y generación de respuestas. Solo si los textos se extraen, limpian, estructuran y segmentan de manera fiable, los procedimientos posteriores pueden operar con precisión. Errores u omisiones en estas fases tempranas afectan a todo el proceso. Las consecuencias van desde embeddings imprecisos y un retrieval ineficiente hasta respuestas débiles o contradictorias.

Este artículo es la parte 1 de una serie en varios entregables. En las próximas partes se describirán otros procedimientos que abarcan embedding, indexación y almacenamiento de vectores, recuperación, generación de respuestas, así como feedback y mejora continua. El objetivo es mostrar paso a paso cómo un sistema RAG, mediante medidas específicas, se vuelve más sólido, preciso y trazable.

Continúa con Parte 2.