257 lines
7.7 KiB
Markdown
257 lines
7.7 KiB
Markdown
# 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.
|