Published in: agentes de ia

Chunking en RAG: estrategias de fragmentación que funcionan

Author Diego Parada

Published on: 21 de junio de 2026

El chunking es la operación más silenciosa y más influyente de toda la pipeline RAG. Antes de que el retriever busque, antes de que el LLM genere, un splitter parte tus documentos en fragmentos. Si esos fragmentos son demasiado grandes, los embeddings diluyen el significado. Si son demasiado pequeños, el contexto se pierde y la respuesta resulta incoherente. El chunk size y la estrategia de fragmentación determinan, más que cualquier otro parámetro, la calidad de lo que el modelo finalmente recupera.

En este post cubrimos las cinco estrategias de chunking relevantes para producción: fixed-size, recursive character splitting, document-aware splitting, semantic chunking y agentic chunking. Cada una incluye código Python ejecutable con LangChain. Si estás construyendo agentes de IA para empresas y aún no tienes una estrategia de chunking definida, este es el punto de entrada correcto. El artículo asume familiaridad con RAG (Retrieval Augmented Generation) y con la API de LangChain.

Este post es para AI engineers y devs senior que ya han deployado un RAG básico y notan que la calidad de respuesta no es consistente. No cubre los fundamentos de embeddings ni cómo elegir una base de datos vectorial desde cero — para eso existen los posts específicos del cluster. Cubre únicamente la capa de fragmentación: qué decisiones tomar, por qué, y cómo medirlas.

¿Qué es chunking y por qué determina la calidad de tu RAG?

Chunking es el proceso de dividir un documento largo en fragmentos más pequeños (chunks) antes de generar sus embeddings semánticos e indexarlos en una base de datos vectorial. El objetivo es doble: ajustar cada fragmento a la ventana de contexto del modelo de embeddings, y garantizar que cada fragmento contiene suficiente información semántica coherente para responder a una query concreta.

La razón por la que el chunking es tan crítico para la calidad del RAG tiene que ver con cómo funcionan los modelos de embeddings. Un modelo como text-embedding-3-small de OpenAI recibe un texto y produce un vector de alta dimensión que representa su significado global. Si ese texto mezcla demasiados conceptos dispares — por ejemplo, una página completa de documentación técnica que cubre instalación, configuración y troubleshooting — el vector resultante «promedia» todos esos significados y pierde densidad semántica en cada uno de ellos. El retriever, al buscar el fragmento más relevante para una query específica sobre instalación, devolverá ese chunk gigante cuando lo que necesita el LLM es solo el párrafo de instalación.

El problema inverso es igualmente real: fragmentos demasiado pequeños — de 50-100 tokens — contienen tan poco contexto que el embedding no puede capturar el significado de la oración dentro de su párrafo. La respuesta generada queda descontextualizada.

Existen cuatro variables que definen cualquier estrategia de chunking:

• chunk_size: el número máximo de tokens (o caracteres) de cada fragmento.
• chunk_overlap: cuántos tokens del final de un chunk se repiten al inicio del siguiente, para preservar contexto entre fragmentos adyacentes.
• separadores: los delimitadores que el splitter usa para encontrar puntos de corte naturales (párrafos, frases, palabras).
• granularidad semántica: si el criterio de corte es estructural (caracteres, headers) o semántico (similitud de embeddings entre frases).

Las estrategias que siguen ordenan de menor a mayor complejidad computacional, no de menor a mayor calidad — en muchos escenarios de producción, una estrategia simple bien calibrada supera a una compleja mal configurada.

Fixed-size chunking: el más simple (y a menudo suficiente)

Fixed-size chunking divide el texto en fragmentos de N caracteres (o tokens) con un overlap fijo. No respeta estructura del documento, no analiza semántica: corta en el carácter número N, punto. Su principal ventaja es la predictibilidad: sabes exactamente cuántos chunks producirá un documento de X caracteres, y el coste de embedding es determinista.

La clase de LangChain que lo implementa es CharacterTextSplitter. Por defecto usa \n\n como separador de intento, pero si el fragmento resultante supera chunk_size, corta en ese punto sin más refinamiento. Para texto libre (artículos, emails, transcripciones de llamadas de ventas) donde no importa tanto preservar estructura, este approach es razonable como baseline.

from langchain_text_splitters import CharacterTextSplitter

# Texto de ejemplo: documentación de producto
text = """
Nuestro sistema de facturación automática procesa hasta 10.000 facturas al mes.
Integra con SAP, Holded y Sage mediante conectores nativos.
El proceso de validación tarda menos de 2 segundos por factura.

La configuración inicial requiere acceso de administrador al ERP de origen.
Una vez configurados los mapeos de campos, el sistema opera sin intervención humana.
Los errores de validación se notifican en tiempo real al equipo de contabilidad.
"""

splitter = CharacterTextSplitter(
    separator="\n\n",      # intenta cortar en doble salto de línea
    chunk_size=300,        # máximo 300 caracteres por chunk
    chunk_overlap=50,      # 50 caracteres de overlap entre chunks adyacentes
    length_function=len,   # mide en caracteres, no en tokens
    is_separator_regex=False,
)

chunks = splitter.split_text(text)

for i, chunk in enumerate(chunks):
    print(f"--- Chunk {i+1} ({len(chunk)} chars) ---")
    print(chunk)
    print()

El parámetro chunk_overlap es la palanca más importante del fixed-size chunking. Un overlap de 10-15% del chunk_size suele ser el punto de equilibrio: suficiente para no perder frases que quedan partidas entre chunks, sin duplicar tanto texto que infles innecesariamente el índice vectorial. Para documentos legales o contratos donde una cláusula puede depender de la anterior, aumenta el overlap al 20-25%.

El límite evidente de esta estrategia es que puede cortar en mitad de una oración o en mitad de un párrafo coherente. Cuando el documento tiene estructura clara — markdown, HTML, código — hay opciones mejores.

Recursive character splitting (la estrategia LangChain)

RecursiveCharacterTextSplitter es el splitter por defecto de LangChain y el punto de partida recomendado para la mayoría de casos de uso. La diferencia con CharacterTextSplitter es que intenta respetar jerarquía de separadores: primero intenta cortar en \n\n (párrafos), si el chunk sigue siendo demasiado grande intenta \n (líneas), luego espacio, y finalmente carácter a carácter. Solo llega al corte «bruto» si ningún separador natural ha funcionado.

Esto produce fragmentos que tienden a ser semánticamente más coherentes que el fixed-size puro, sin coste computacional adicional. En benchmarks de recuperación sobre corpus de documentación técnica, el recursive splitter mejora el recall@5 entre un 8-15% respecto al character splitter con los mismos parámetros de chunk_size.

from langchain_text_splitters import RecursiveCharacterTextSplitter

# Separadores en orden de preferencia (de mayor a menor granularidad)
SEPARATORS = [
    "\n\n",   # párrafos
    "\n",     # líneas
    ". ",     # frases
    ", ",     # cláusulas
    " ",      # palabras
    "",       # caracteres (último recurso)
]

splitter = RecursiveCharacterTextSplitter(
    separators=SEPARATORS,
    chunk_size=512,        # en tokens si usas tiktoken, en chars si usas len
    chunk_overlap=64,
    length_function=len,
    is_separator_regex=False,
    add_start_index=True,  # añade metadata con la posición del chunk en el doc original
)

# Aplicar sobre una lista de documentos LangChain
from langchain_core.documents import Document

docs = [
    Document(
        page_content=text,
        metadata={"source": "manual-facturacion-v2.pdf", "page": 1}
    )
]

split_docs = splitter.split_documents(docs)

for doc in split_docs:
    print(f"Source: {doc.metadata['source']} | Start index: {doc.metadata.get('start_index')}")
    print(f"Length: {len(doc.page_content)} chars")
    print(doc.page_content[:100], "...")
    print()

El parámetro add_start_index=True es valioso para producción: añade la posición de inicio del chunk dentro del documento original como metadata. Esto permite implementar window expansion en el retriever — si recuperas el chunk en el índice 450, puedes extraer también los 100 caracteres anteriores del documento fuente para dar más contexto al LLM sin inflar el índice.

Para ajustar chunk_size a tokens en vez de caracteres, sustituye length_function=len por una función que use tiktoken con el modelo de embeddings objetivo. La regla práctica: para text-embedding-3-small (ventana de 8.192 tokens) y text-embedding-3-large (igual), un chunk_size de 300-512 tokens con overlap de 50-80 tokens es el punto de partida estándar de la comunidad.

Document-aware splitting: respetar markdown, código, HTML

Cuando el documento tiene estructura semántica propia — encabezados markdown, bloques de código, tablas HTML — ignorarla es un error de diseño. Cortar en mitad de un bloque de código o separar un párrafo de su encabezado produce chunks con baja densidad semántica y embeddings ruidosos.

LangChain ofrece MarkdownHeaderTextSplitter para documentación en markdown. Este splitter no divide por tamaño sino por estructura: crea un chunk por sección del documento, preservando los headers como metadata. El resultado es que cada chunk ya lleva consigo su contexto jerárquico — útil para construir filtros de metadata en el retriever.

from langchain_text_splitters import MarkdownHeaderTextSplitter, RecursiveCharacterTextSplitter

markdown_doc = """
# Manual de Integración API

## Autenticación

La API usa Bearer tokens con expiración de 24 horas.
Obtén tu token en el panel de control bajo Configuración > API Keys.
Cada request debe incluir el header `Authorization: Bearer {token}`.

## Endpoints disponibles

### POST /facturas

Crea una nueva factura en el sistema. El body debe ser JSON con los campos
obligatorios: `cliente_id`, `lineas`, `fecha_emision`.

### GET /facturas/{id}

Recupera una factura existente por su ID único. Devuelve el objeto completo
incluyendo estado de pago, líneas y metadatos de auditoría.

## Errores comunes

Los códigos 4xx indican errores del cliente. El más frecuente es 422 (Unprocessable Entity)
cuando el campo `lineas` está vacío o malformado.
"""

# Paso 1: split por headers de markdown, propagando metadata
headers_to_split_on = [
    ("#", "titulo"),
    ("##", "seccion"),
    ("###", "subseccion"),
]

md_splitter = MarkdownHeaderTextSplitter(
    headers_to_split_on=headers_to_split_on,
    strip_headers=False,  # mantiene el header en el chunk (mejor para el embedding)
)

md_chunks = md_splitter.split_text(markdown_doc)

# Paso 2: si algún chunk es demasiado largo, aplicar recursive sobre él
char_splitter = RecursiveCharacterTextSplitter(chunk_size=400, chunk_overlap=40)
final_chunks = char_splitter.split_documents(md_chunks)

for chunk in final_chunks:
    print(f"Metadata: {chunk.metadata}")
    print(f"Content: {chunk.page_content[:120]}...")
    print()

El patrón de dos pasos — primero split estructural, luego recursive si el chunk sigue siendo grande — es el estándar de producción para documentación técnica. El metadata de headers propagado es especialmente útil en combinación con filtros de search_kwargs en el retriever: puedes restringir la búsqueda a chunks cuya metadata seccion == "Autenticación" cuando la query del usuario es claramente sobre auth.

Para documentos HTML, LangChain ofrece HTMLHeaderTextSplitter con la misma lógica. Para código fuente, el splitter correcto depende del lenguaje: el Language enum de RecursiveCharacterTextSplitter.from_language(Language.PYTHON) usa separadores específicos del lenguaje (clases, funciones, métodos) en vez de párrafos.

Semantic chunking: dividir por significado

Semantic chunking abandona los criterios estructurales y decide los puntos de corte midiendo la similitud semántica entre frases adyacentes. La idea: si dos frases consecutivas tienen embeddings muy similares, pertenecen al mismo chunk. Cuando la similitud cae por debajo de un umbral, ahí está el corte natural.

Este enfoque, popularizado por Greg Kamradt en su implementación de referencia y adoptado después en langchain_experimental, produce chunks que respetan los cambios de tema en el documento. Es especialmente efectivo en documentos sin estructura explícita: transcripciones de reuniones, artículos largos, libros blancos de consultoría.

from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai import OpenAIEmbeddings

embeddings = OpenAIEmbeddings(model="text-embedding-3-small")

# breakpoint_threshold_type controla cómo se calcula el umbral de corte:
# - "percentile": corta en el Xth percentil de distancias entre frases adyacentes
# - "standard_deviation": corta cuando la distancia supera la media + N desviaciones
# - "interquartile": usa el rango intercuartílico para detectar outliers de distancia
splitter = SemanticChunker(
    embeddings=embeddings,
    breakpoint_threshold_type="percentile",
    breakpoint_threshold_amount=85,  # corta en el 85th percentil de distancias
    # number_of_chunks=None,         # si lo defines, ignora el threshold y produce N chunks
)

long_text = """
Los agentes de IA para ventas automatizan el proceso de cualificación de leads.
Cuando un lead entra por el formulario web, el agente verifica su email, su empresa 
y estima el tamaño de la cuenta consultando fuentes públicas.
Esta información se vuelca automáticamente en el CRM antes de que el comercial reciba la notificación.

El proceso de onboarding de nuevos empleados requiere coordinar múltiples departamentos.
RRHH necesita contratos firmados, IT necesita provisionar accesos, y el mánager directo
necesita organizar la formación inicial. Un agente de onboarding puede orquestar todos estos
pasos de forma asíncrona, notificando a cada stakeholder en el momento correcto.
"""

chunks = splitter.create_documents([long_text])

for i, chunk in enumerate(chunks):
    print(f"=== Chunk {i+1} ===")
    print(chunk.page_content)
    print(f"[{len(chunk.page_content)} chars]")
    print()

El coste del semantic chunking es real: genera un embedding por cada frase del documento durante el proceso de indexación. Para un corpus de 10.000 páginas PDF, esto puede triplicar el tiempo y el coste de la fase de ingestion respecto al recursive splitter. La decisión de usarlo depende de si la mejora en retrieval quality compensa ese coste. En benchmarks propios con documentación de procesos empresariales de media complejidad, el semantic chunker mejora el faithfulness score (medido con la metodología de Chroma Research) entre un 10-20% respecto al recursive splitter, con un coste de ingestion 2,5x mayor.

El parámetro breakpoint_threshold_amount requiere calibración por dominio. Documentos técnicos con terminología densa necesitan umbrales más altos (90-95th percentil) porque los cambios de tema son sutiles. Documentos heterogéneos como transcripciones de reuniones responden mejor a umbrales del 70-80th percentil.

Hierarchical / parent-document retrieval

El parent-document retrieval es una arquitectura, no un splitter. Resuelve una tensión fundamental del chunking: los chunks pequeños producen embeddings más precisos semánticamente, pero los chunks pequeños también tienen menos contexto para que el LLM genere una respuesta coherente.

La solución es indexar dos versiones del mismo documento: chunks pequeños (child chunks, 100-200 tokens) para la búsqueda vectorial, y chunks grandes (parent chunks, 500-2000 tokens) o el documento completo para la generación. El retriever busca en los child chunks, identifica cuál es el más relevante, y en vez de pasar ese fragmento pequeño al LLM, pasa el parent chunk correspondiente. Mejor retrieval, mejor contexto.

LangChain implementa esto con ParentDocumentRetriever, que gestiona automáticamente el mapeo entre child y parent:

• vectorstore: almacena los embeddings de los child chunks (Chroma, Pinecone, Qdrant, etc.).
• docstore: almacena los parent chunks completos, recuperables por ID. Puede ser InMemoryStore para desarrollo o Redis/MongoDB para producción.
• child_splitter: genera los fragmentos pequeños para indexar.
• parent_splitter (opcional): si se define, fragmenta el documento en parents intermedios antes de aplicar el child splitter. Si no se define, el parent es el documento completo.

Esta estrategia es especialmente relevante cuando construyes agentes de IA para empresas sobre documentación corporativa larga — normativas internas, manuales de producto, contratos — donde el contexto que rodea a una frase específica es determinante para la correcta interpretación. Un agente que trabaja con la normativa fiscal de una empresa necesita recuperar el párrafo concreto sobre deducibilidad, pero el LLM necesita el artículo completo para interpretar ese párrafo correctamente.

El overhead de esta arquitectura es de almacenamiento: tienes dos copias de los datos, una en el vector store (child chunks como embeddings) y otra en el docstore (parent chunks como texto). Para corpus de varios GB, planifica esto en tu infraestructura antes de elegir el approach.

Agentic chunking: LLM decide los cortes

Agentic chunking invierte la lógica de todos los enfoques anteriores: en vez de que un algoritmo (estructural o estadístico) decida dónde cortar, le pasas el documento a un LLM y le pides que identifique los puntos de corte semánticamente significativos. El modelo puede entender intención, narrativa y coherencia conceptual de una forma que ningún splitter basado en reglas puede.

El coste es obvio: una llamada LLM por documento (o por ventana de documento si es largo). Para corpus de millones de documentos, esto no escala. Pero para colecciones de documentos de alta precisión — contratos legales, informes financieros, protocolos médicos — donde la calidad del retrieval es crítica y el volumen es manejable, el agentic chunking produce los fragmentos de mayor calidad semántica.

from openai import OpenAI
import json

client = OpenAI()

AGENTIC_CHUNK_PROMPT = """Eres un experto en procesamiento de documentos para sistemas RAG.
Tu tarea es analizar el siguiente documento e identificar los puntos de corte naturales
para crear fragmentos semánticamente coherentes.

Reglas:
1. Cada fragmento debe ser auto-contenido: comprensible sin necesidad de leer los demás.
2. Respeta las unidades conceptuales: no separes una pregunta de su respuesta, ni un problema de su solución.
3. Los fragmentos ideales tienen entre 150 y 400 palabras.
4. Devuelve SOLO un JSON array con los fragmentos resultantes, sin explicación adicional.

Formato de respuesta:
{"chunks": ["fragmento 1 completo", "fragmento 2 completo", ...]}

Documento a fragmentar:
{document}
"""

def agentic_chunk(document: str, model: str = "gpt-4o-mini") -> list[str]:
    """
    Usa un LLM para fragmentar un documento de forma semánticamente coherente.
    Recomendado para documentos de alta precisión con volumen manejable (<500 docs).
    """
    prompt = AGENTIC_CHUNK_PROMPT.format(document=document)

    response = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        response_format={"type": "json_object"},
        temperature=0,  # determinista: mismas entradas, mismos cortes
    )

    result = json.loads(response.choices[0].message.content)
    return result.get("chunks", [])


# Uso
sample_doc = """
La deducción por inversión en I+D+i permite reducir la cuota íntegra del Impuesto
sobre Sociedades. Para actividades de investigación y desarrollo, la deducción es del
25% de los gastos incurridos en el ejercicio. Si los gastos superan la media de los
dos años anteriores, el exceso tiene una deducción adicional del 42%.

Para actividades de innovación tecnológica, la deducción es del 12% sobre los gastos
del ejercicio. Esta categoría incluye proyectos de software avanzado, diseño industrial
y proyectos de demostración inicial.

El procedimiento para aplicar la deducción requiere que la empresa solicite un informe
motivado del Ministerio de Ciencia e Innovación antes del final del período impositivo.
Sin este informe, la deducción puede ser impugnada en una inspección fiscal.
"""

chunks = agentic_chunk(sample_doc)
for i, chunk in enumerate(chunks):
    print(f"=== Chunk {i+1} ===")
    print(chunk)
    print()

En proyectos de agentes de IA sobre documentación jurídica o normativa, el agentic chunking combinado con parent-document retrieval produce los mejores resultados. El LLM hace los cortes, y los fragmentos resultantes se indexan como child chunks con el documento original como parent. El coste de ingestion es alto, pero el coste de un retrieval erróneo en un contexto legal es mayor.

Una optimización práctica: usa un modelo barato (gpt-4o-mini) para el chunking y el modelo principal para la generación. El chunking es una tarea de extracción y segmentación, no de razonamiento complejo.

Elegir el chunk size: experimentación y métricas

No existe un chunk size universalmente óptimo. Existe el chunk size óptimo para tu corpus, tu modelo de embeddings, tu query distribution y tu caso de uso. La única forma de encontrarlo es mediante experimentación sistemática con métricas objetivas.

El framework de evaluación para chunking sigue este flujo:

1. Construir un golden dataset: 50-100 pares (query, respuesta esperada) representativos de las queries reales del sistema. Si no tienes queries reales, usa un LLM para generarlas a partir del corpus.
2. Definir métricas de retrieval: Recall@K (¿el chunk correcto está entre los K recuperados?), MRR (Mean Reciprocal Rank), y NDCG si tienes relevance scores graduados.
3. Grid search sobre parámetros: chunk_size (128, 256, 512, 1024 tokens), chunk_overlap (0%, 10%, 20%), estrategia (fixed, recursive, semantic).
4. Medir end-to-end quality: faithfulness (el LLM no alucina sobre el chunk recuperado) y answer relevancy usando LLM-as-judge. Ver el post sobre text splitters en la documentación oficial de LangChain.

Las reglas empíricas de la comunidad, validadas por estudios como el de LlamaIndex sobre node parsers y el citado trabajo de Chroma, apuntan a:

Un patrón que funciona en producción: empezar con recursive splitter a 512 tokens + 10% overlap, medir el recall@5 con el golden dataset, y solo añadir complejidad (semantic, agentic) si ese baseline no alcanza el 0.70 de recall. En la mayoría de proyectos empresariales que implementamos en Baigency, el recursive splitter bien calibrado alcanza recall@5 de 0.75-0.85 sobre documentación corporativa estándar.

Otro factor a considerar: el modelo de embeddings tiene su propia ventana óptima. Modelos de Hugging Face como bge-m3 o multilingual-e5-large rinden mejor con chunks de 256-512 tokens. Los modelos de OpenAI admiten hasta 8.192 tokens pero su calidad de embedding no es lineal — los fragmentos de 300-500 tokens producen mejores resultados en recuperación que los de 2.000 tokens, aunque el modelo técnicamente los procese.

Por último: el chunking no es una decisión de una sola vez. A medida que el corpus evoluciona y añades nuevos tipos de documentos, los parámetros óptimos pueden cambiar. Implementa el pipeline de evaluación como parte de la CI/CD de tu sistema RAG, no como una exploración de una sola vez.

Preguntas frecuentes sobre chunking en RAG

¿Cuál es el chunk size óptimo para empezar?

No existe un valor universalmente óptimo, pero el punto de partida más extendido en producción es 512 tokens con un overlap del 10% (51 tokens). Ese rango funciona razonablemente bien para documentación técnica, artículos y bases de conocimiento corporativo con la mayoría de modelos de embeddings actuales (text-embedding-3-small, bge-m3, e5-large). A partir de ese baseline, mide el recall@5 sobre un conjunto de queries representativo y ajusta en función de los resultados. Solo añade estrategias más complejas si el recall no supera 0.70.

¿Semantic chunking siempre es mejor que recursive?

No. El semantic chunking produce fragmentos semánticamente más coherentes, pero tiene un coste de ingestion 2-3x mayor porque genera embeddings durante la propia fase de chunking. En benchmarks sobre corpus de documentación empresarial estándar, el semantic chunker mejora el faithfulness score entre un 10-20%, pero el recursive splitter bien calibrado alcanza recall@5 de 0.75-0.85 en la mayoría de casos. Para corpus de menos de 50.000 documentos con estructura moderada, el recursive splitter es la elección correcta por defecto. El semantic chunking justifica su coste en documentos sin estructura explícita y con alta variabilidad temática.

¿Qué es el chunk overlap y por qué importa?

El chunk overlap es el número de tokens que se repiten al final de un chunk y al inicio del siguiente. Su función es preservar el contexto de frases o ideas que quedan partidas en el punto de corte. Sin overlap, una oración que se corta entre dos chunks puede quedar sin contexto en ambos, produciendo embeddings ruidosos. Un overlap del 10-15% del chunk_size es el punto de equilibrio estándar: suficiente para capturar contexto limítrofe sin duplicar demasiado datos en el índice vectorial, lo que incrementaría costes de almacenamiento y tiempo de búsqueda.

¿Cómo afecta el chunking al coste de la API de embeddings?

El coste de embeddings es directamente proporcional al número total de tokens procesados. Chunks más pequeños generan más fragmentos por documento, lo que aumenta el número de llamadas a la API pero mantiene el total de tokens similar. El overlap sí añade tokens adicionales: con un overlap del 15% y 10.000 chunks, estás procesando aproximadamente un 15% más de tokens que sin overlap. Para corpus grandes, reduce el overlap al 10% y usa tiktoken para medir el tamaño real de cada chunk en tokens antes de enviarlo a la API, evitando sorpresas en la factura.

¿Debo re-indexar si cambio la estrategia de chunking?

Sí, siempre. Los embeddings son específicos del texto exacto que reciben: si cambias el chunk_size, el overlap o la estrategia, los fragmentos resultantes son diferentes y sus embeddings no son comparables con los anteriores. Cambiar la estrategia de chunking implica regenerar todos los embeddings y reindexar el corpus completo. Por eso es importante invertir tiempo en la calibración inicial antes de escalar la ingestion. Mantén un pipeline de evaluación automatizado que te permita comparar estrategias sobre un subconjunto del corpus antes de comprometerte con una re-indexación completa.

¿Qué diferencia hay entre chunking y context engineering?

El chunking decide cómo dividir documentos en el momento de la indexación, antes de que el usuario haga ninguna query. El context engineering decide qué información inyectar en el prompt del LLM en el momento de la inferencia, incluyendo qué chunks recuperados incluir, en qué orden, con qué metadatos y con qué instrucciones de sistema. Son capas complementarias: un buen chunking facilita el retrieval correcto, pero un buen context engineering determina cómo ese material recuperado se convierte en contexto útil para el modelo. Las dos disciplinas se solapan en técnicas como el parent-document retrieval, donde la decisión de qué pasar al LLM se toma post-retrieval.

Conclusión

El chunking no tiene una solución única. El espectro va desde el fixed-size chunking — simple, predecible, suficiente para muchos casos — hasta el agentic chunking, donde un LLM hace los cortes semánticamente óptimos a cambio de un coste de ingestion significativo. La decisión correcta depende de tu corpus, tu presupuesto de inferencia y tus métricas de retrieval.

La recomendación operativa: empieza con RecursiveCharacterTextSplitter a 512 tokens + 10% overlap, construye un golden dataset de 50-100 queries y mide el recall@5. Si no alcanzas 0.70, explora semantic chunking para documentos sin estructura o parent-document retrieval para documentos donde el contexto amplio es crítico. Reserva el agentic chunking para corpus de alta precisión y volumen manejable.

Si estás implementando un sistema RAG sobre documentación corporativa y necesitas validar tu arquitectura de chunking antes de escalar, el equipo de Baigency puede ayudarte a diseñar el pipeline de evaluación y seleccionar la estrategia más adecuada para tu caso. El siguiente paso natural es profundizar en la capa de recuperación: cómo se construyen y consultan las bases de datos vectoriales que almacenan estos chunks, y cómo se combinan con embeddings semánticos de alta calidad para maximizar el recall. Para sistemas más complejos que requieren razonamiento multi-paso sobre el corpus recuperado, la arquitectura de agentes de IA para empresas añade la capa de orquestación necesaria.

Post del cluster AI Engineering de Baigency. Revisión técnica: Diego Parada. Última actualización: junio 2026.