Procesamiento de documentos: De archivos a fragmentos inteligentes

En la lección anterior viste que RAG tiene tres etapas. La primera — ingestión — es donde la mayoría de los sistemas fallan. No por el LLM. No por la base de datos vectorial. Sino porque los documentos se procesaron mal.

Basura entra, basura sale. Si tus fragmentos están mal cortados, ninguna estrategia de recuperación va a encontrar la información correcta.

Lo que aprenderás

Al terminar esta lección sabrás cómo convertir documentos reales en fragmentos optimizados para búsqueda — con las estrategias de chunking que funcionan en producción.

El pipeline de ingestión

Documento original (PDF, DOCX, HTML, Markdown)
    ↓
1. Parseo — Extraer texto limpio
    ↓
2. Chunking — Dividir en fragmentos
    ↓
3. Enriquecimiento — Agregar metadata
    ↓
4. Embedding — Convertir a vectores
    ↓
5. Almacenamiento — Guardar en base vectorial

En esta lección cubrimos los pasos 1 a 3. Embeddings y almacenamiento vienen en las próximas lecciones.

Paso 1: Parseo — Extraer texto limpio

Cada formato tiene sus trampas:

Regla práctica: Siempre revisa manualmente los primeros 10 documentos parseados. Si el texto tiene basura (headers repetidos, caracteres rotos, código HTML), tu RAG va a fallar sin importar qué tan bueno sea el resto del pipeline.

Paso 2: Chunking — El arte de cortar bien

Chunking es dividir un documento largo en fragmentos más pequeños. Suena trivial. No lo es.

¿Por qué no usar el documento entero?

Los LLMs tienen límites de contexto (128K tokens en modelos modernos). Pero meter un documento de 50 páginas completo como contexto tiene problemas:

• El modelo se confunde con demasiada información — las respuestas pierden calidad
• Pagas por todos esos tokens en cada consulta
• El “context cliff”: la calidad cae drásticamente después de ~2,500 tokens de contexto

Estrategia 1: Chunking de tamaño fijo

La más simple — corta cada N caracteres o tokens.

Documento: "La IA generativa está transformando..."
Fragmento 1: [tokens 0-500]
Fragmento 2: [tokens 500-1000]
Fragmento 3: [tokens 1000-1500]

Problema: Corta en medio de oraciones, párrafos e ideas. Un benchmark de 2025 mostró solo 13-35% de precisión. No lo uses en producción.

Estrategia 2: Chunking recursivo (recomendado)

Intenta cortar por jerarquía natural del texto:

1. Primero intenta cortar por secciones (headers)
2. Si la sección es muy larga, corta por párrafos
3. Si el párrafo es muy largo, corta por oraciones
4. Solo como último recurso, corta por caracteres

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,       # tokens objetivo
    chunk_overlap=50,     # ~10% overlap
    separators=["\n\n", "\n", ". ", " "]  # jerarquía de corte
)

chunks = splitter.split_text(document_text)

Resultado en benchmarks: 69% de precisión con 512 tokens. Es el default de LangChain por buena razón.

Estrategia 3: Chunking semántico

Usa un modelo de embeddings para detectar dónde cambia el tema dentro del documento. Corta en los “puntos de inflexión” semánticos.

Ventaja: Cada fragmento contiene una idea coherente. Desventaja: Más lento, más costoso, y en benchmarks logra 54% — menos que el recursivo para la mayoría de tareas.

Úsalo cuando: Tus documentos mezclan muchos temas sin estructura clara (transcripciones de reuniones, textos largos sin headers).

Estrategia 4: Chunking adaptativo

Combina análisis de estructura del documento + detección de temas. El más preciso (87% en benchmarks) pero también el más complejo.

Úsalo cuando: Documentos clínicos, legales o técnicos donde cada fragmento necesita ser perfecto.

✅ Quick Check: Tienes manuales técnicos bien estructurados con secciones claras. ¿Qué estrategia de chunking usarías? (Recursivo con 400-512 tokens. Los manuales técnicos tienen headers y secciones naturales — exactamente lo que el chunking recursivo aprovecha. El semántico no te da ventaja aquí porque la estructura ya está definida.)

Los números que importan

El “context cliff”: La calidad de las respuestas cae significativamente cuando metes más de ~2,500 tokens de contexto. Fragmentos más pequeños (3-5 de 500 tokens = 1,500-2,500 total) funcionan mejor que pocos fragmentos grandes.

Paso 3: Metadata — El secreto de la recuperación precisa

Sin metadata, solo puedes buscar por similitud semántica. Con metadata, puedes filtrar.

Metadata esencial para cada fragmento:

{
  "text": "La política de devoluciones permite...",
  "metadata": {
    "source": "politica-devoluciones-v3.pdf",
    "page": 4,
    "section": "Devoluciones — Plazos",
    "date": "2026-01-15",
    "author": "Departamento Legal",
    "language": "es"
  }
}

Esto te permite hacer consultas como:

• “Busca en documentos de 2026 sobre devoluciones” → filtro por fecha + semántica
• “Solo en la sección de Políticas del manual” → filtro por sección
• “Documentos del equipo legal únicamente” → filtro por autor

Sin metadata, la búsqueda semántica devuelve fragmentos de cualquier documento, cualquier fecha, cualquier sección. Con metadata, la precisión mejora dramáticamente.

Puntos clave

• El procesamiento de documentos es donde la mayoría de los sistemas RAG fallan — basura entra, basura sale
• Chunking recursivo (400-512 tokens, 10-20% overlap) es el estándar de producción — 69% precisión
• El “context cliff” a ~2,500 tokens significa que fragmentos pequeños funcionan mejor que documentos completos
• La metadata (fuente, fecha, sección) permite filtrar resultados y mejora drásticamente la precisión
• Siempre revisa manualmente los primeros documentos parseados — los errores de parseo son invisibles si no miras

Siguiente lección

Tienes documentos fragmentados con metadata. Ahora necesitas convertir esos fragmentos de texto en algo que una computadora pueda comparar: vectores. En la siguiente lección aprenderás cómo funcionan los embeddings y por qué son la base de la búsqueda semántica.