rag-service/RAG/docs/PROCESADO.md

Procesado

Proyecto: Workspace de tools IA para empresas
Modulo: RAG
Ultima actualizacion: 2026-04-02
Ultima modificacion por: Agente tools IA para potenciar servicios empresariales
Estado: En definicion

---

Proposito

Definir el modulo de procesado del sistema RAG, encargado de transformar la salida de ingesta en contenido preparado para indexacion y recuperacion.

---

Que es el procesado

El procesado toma las fuentes ya leidas por la ingesta y las prepara para el resto del pipeline.

Su trabajo incluye, segun el tipo de contenido:

• limpieza basica
• normalizacion
• extraccion de estructura util
• preparacion de metadatos
• division en chunks

---

Responsabilidades del procesado

1. Recibir la salida de la ingesta.
2. Normalizar el contenido a una representacion interna util.
3. Conservar contexto estructural relevante.
4. Generar chunks recuperables.
5. Entregar el resultado listo para indexacion.

---

Decision inicial sobre chunking

Para la v1 del sistema se adopta una estrategia comun de chunking para todos los documentos.

No se implementaran aun estrategias distintas por tipo de documento.

Decision cerrada para esta v1 documental:

• se adopta un modo documental estable como base
• se deja abierta una futura variante para documentos extensos, por ejemplo documental_largo o documental_jerarquico

Decision ya implementada adicional:

• se implementa tambien un modo codigo
• su chunking se hace por bloques top-level y no por parrafos

---

Por que se decide asi

• reduce complejidad en la primera version
• permite validar antes el valor real del RAG
• evita abrir demasiadas variantes demasiado pronto
• deja la puerta abierta a estrategias especificas cuando haya evidencia real de necesidad

---

Vision futura

Mas adelante el sistema podra permitir chunking distinto segun:

• tipo de documento
• tipo de fuente
• uso esperado del contenido
• formato tecnico o estructura interna

Ejemplos:

• documentacion general
• historiales o logs
• PDFs tecnicos
• codigo fuente

---

Principio adoptado

Regla actual:

• una estrategia comun, simple y estable para la v1

Regla futura:

• estrategias adaptables por tipo de documento o fuente si el beneficio supera el coste de complejidad

---

Politica oficial de chunking documental v1

Se adopta esta estrategia para el modo documental:

1. Intentar partir primero por estructura natural del documento.
2. Usar como unidades preferentes:

• titulos
• subtitulos
• bloques de parrafos relacionados

3. Si una seccion o bloque supera el tamano maximo permitido, subdividirla por parrafos.
4. Si aun asi sigue siendo demasiado grande, cortar por longitud sin romper mas de lo necesario.
5. Mantener metadatos estructurales del bloque, por ejemplo titulo o seccion de origen.
6. Aplicar overlap pequeno y fijo entre chunks contiguos.

---

Criterio de tamano para la v1

Para mantener la implementacion simple y estable, la v1 trabajara con una medida aproximada por caracteres, no por tokens.

Propuesta cerrada:

• tamano objetivo por chunk: alrededor de 1500 caracteres
• tamano maximo por chunk: alrededor de 2200 caracteres
• overlap aproximado: alrededor de 200 caracteres

Como se aplican estos valores

• si un bloque natural cabe dentro del rango objetivo, se conserva como un solo chunk
• si supera el objetivo, se intenta dividir por parrafos
• si supera el maximo incluso despues de agrupar o dividir por parrafos, se corta por longitud controlada
• el overlap se toma del final del chunk anterior para conservar continuidad

Por que se decide asi

• caracteres es una medida mas simple de implementar en la v1
• estos valores son suficientemente pequenos para no cargar demasiado cada fragmento
• siguen siendo suficientemente amplios para conservar contexto util en documentacion normal
• el overlap pequeno ayuda a no perder continuidad entre ideas cercanas

---

Limitaciones conocidas del modo documental v1

• funciona especialmente bien para documentacion general, notas, manuales, PDFs con texto extraible y contenido textual estructurado
• puede quedarse corto para libros tecnicos, documentos muy largos o contenido extremadamente denso
• para esos casos se deja prevista una futura variante especializada, sin romper el modo documental base

---

Politica oficial de chunking de codigo v1

Se adopta esta estrategia para el modo codigo:

1. Detectar bloques top-level relevantes del fichero.
2. Usar como unidades preferentes:

• funciones
• clases
• interfaces
• tipos
• bloques exportados o definidos al nivel principal

3. Si un bloque supera el tamano maximo, subdividirlo por longitud controlada.
4. Conservar metadatos utiles del bloque:

• sectionTitle
• startLine
• endLine

Por que se decide asi

• el codigo no debe partirse como si fueran parrafos documentales
• interesa recuperar unidades semanticas utiles para preguntas tecnicas
• mantener rango de lineas y cabecera del bloque mejora la trazabilidad practica

Soporte actual de extensiones de codigo

• ts
• tsx
• js
• jsx
• mjs
• cjs
• py
• json
• yml
• yaml

---

Impacto de cambiar la estrategia de chunking

La forma de chunking condiciona directamente como queda representado el conocimiento dentro del RAG.

Por eso, si en el futuro cambiamos de manera relevante la estrategia de chunking, lo normal sera tener que reprocesar e indexar de nuevo los documentos afectados.

Que implica esto

• si cambia la forma de partir un documento, sus chunks dejan de ser equivalentes a los anteriores
• los embeddings asociados a esos chunks tambien dejan de representar exactamente la nueva estructura
• por tanto, lo correcto suele ser rehacer chunking e indexacion para esa parte del conocimiento

Que no significa necesariamente

• no siempre hara falta rehacer todo el RAG completo
• puede bastar con reingestar solo determinadas fuentes, tipos documentales o tenants

Criterio recomendado

• en la v1 conviene usar una estrategia estable y suficientemente buena
• no buscar la perfeccion absoluta desde el inicio
• dejar preparado el sistema para reindexacion parcial cuando haya mejoras posteriores

---

Convivencia de estrategias distintas

En el futuro podran convivir estrategias distintas de chunking, por ejemplo documental y codigo.

Pero esa convivencia debe hacerse de forma controlada y explicita, no mezclando sin criterio chunks equivalentes del mismo tipo documental.

Ejemplo sano:

• documentos de negocio en modo documental
• codigo fuente en modo codigo

Ejemplo menos sano:

• misma clase de documentos documentales partida a la vez con dos reglas distintas sin control de version o motivo claro

Por eso, lo que decidimos ahora es importante: fija la base de la v1 y condiciona como se representara inicialmente el conocimiento.

---

Overlap entre chunks

Overlap significa repetir una pequena parte del contenido entre un chunk y el siguiente.

Ejemplo simple

Si un texto se parte asi:

• chunk 1: parrafos 1, 2 y 3
• chunk 2: parrafos 3, 4 y 5

entonces el parrafo 3 actua como zona de solapamiento entre ambos chunks.

Para que sirve

• evita que una idea importante quede cortada justo en el limite entre chunks
• conserva mejor continuidad entre fragmentos vecinos
• mejora la recuperacion cuando una consulta depende de contexto compartido entre dos trozos

Recomendacion para la v1

• usar overlap pequeno
• suficiente para conservar continuidad
• sin duplicar demasiado contenido ni disparar el coste de indexacion

---

Preguntas a cerrar

1. Como sera exactamente la estrategia de chunking comun de la v1.
2. Si los chunks se construiran por estructura del documento, por longitud o con un enfoque mixto.
3. Si habra overlap entre chunks desde la primera version.
4. Que informacion estructural debe conservar cada chunk.