Estrategias de chunking en RAG: 7 métodos clasificados con datos de recuperación (2026)

Estrategias de chunking en RAG: 7 métodos clasificados con datos de recuperación (2026)

Las estrategias de chunking en RAG deciden lo que tu retriever puede encontrar antes de que se ejecute una sola consulta. El estudio de Chroma de julio de 2024 ejecutó 472 consultas sobre cinco corpus con text-embedding-3-large, y el splitter que elijas mueve el recall unos cinco puntos: 86,7% para un splitter de tokens simple y 91,7% para el de GPT-4o, recuperando cinco chunks por consulta. La precisión oscila mucho más. En el informe completo va del 1,5% al 8,0%, lo que convierte tu elección de tamaño de chunk en una decisión de costes disfrazada de decisión de calidad, y todas las guías de la primera página de Google listan los mismos siete métodos sin mostrar cuál recupera mejor.

Ideas clave

• El chunking divide los documentos antes del embedding; los puntos de corte deciden lo que tu retriever puede y no puede encontrar.
• En el estudio de Chroma de julio de 2024 con 472 consultas, el recall fue del 86,7% al 91,7% según el splitter medido.
• La precisión varía varias veces más que el recall, así que el tamaño de chunk es sobre todo una decisión de coste de tokens.
• Empieza con 512 tokens y un 10% de solapamiento, y luego ajusta contra tu propio conjunto de evaluación.

¿Qué estrategia de chunking RAG deberías usar? (Clasificadas)

Para la mayoría de los equipos que trabajan con prosa plana, el chunking recursivo de caracteres con 512 tokens y un 10% de solapamiento es el valor por defecto correcto. Respeta los límites de párrafo y oración, no cuesta nada extra y en el benchmark de 472 consultas de Chroma quedó a 3,2 puntos de recall del splitter basado en LLM. Apártate de él solo si tus documentos tienen una estructura fuerte o tu conjunto de evaluación demuestra lo contrario.

Nuestra lectura: empieza con carácter recursivo. Solo queda por detrás de los splitters cluster y LLM en recall en los datos de Chroma, y el 3,9% de precisión del splitter LLM significa que alimentas al generador con aproximadamente el doble de ruido por token relevante. La mayoría de los equipos no tiene un problema de chunking; tiene un problema de tamaño de chunk que nunca ha medido.

¿Qué dicen realmente los datos sobre el tamaño de chunk?

La única comparación pública cara a cara de estrategias de chunking RAG es el informe técnico de Chroma "Evaluating Chunking Strategies for Retrieval" (Brandon Smith y Anton Troynikov, publicado el 3 de julio de 2024). Ejecutaron 472 consultas sobre 5 corpus (328.208 tokens), vectorizaron todo con text-embedding-3-large de OpenAI y recuperaron 5 chunks por consulta. Las filas de abajo vienen de la tabla del apéndice del informe para todos los corpus con text-embedding-3-large y 5 chunks recuperados, así que son directamente comparables entre sí:

La tabla de resultados principal de Chroma, que usa un ajuste de recuperación distinto, sitúa la mejor precisión del chunker cluster en 8,0% con un recall del 87,3%, y estira el rango de precisión de todos sus splitters del 1,5% (KamradtSemanticChunker) al 8,0%. Fuente: Chroma Research, Evaluating Chunking Strategies

"Introducing Contextual Retrieval" de Anthropic (publicado el 19 de septiembre de 2024) ataca el problema desde otro ángulo. Su tasa de fallo de recuperación top-20 base era del 5,7%; solo los embeddings contextuales la bajaron al 3,7% (reducción del 35%), el BM25 contextual encima la llevó al 2,9% (49%) y el reranking la empujó al 1,9% (67%). Anthropic no publica el tamaño de chunk ni el solapamiento exactos que usó, así que trátalos como evidencia a nivel de método, no de tamaño. Fuente: Anthropic, Contextual Retrieval.

Nuestra lectura: tres conclusiones que salen de las cuentas. Primera, la elección de splitter vale recall de verdad, y Chroma lo dice sin rodeos: algunas estrategias superan a otras hasta en un 9% de recall. En su tabla de resultados principal el recall va del 83,6% (KamradtSemanticChunker) al 91,9% (LLMSemanticChunker), y dentro de las filas de 5 recuperados de arriba todavía abarca del 86,7% al 91,7%. La precisión se mueve varias veces más con los mismos datos: del 1,5% al 8,0%, una horquilla de 5,3x contra 1,1x del recall. Así que el recall es donde ganas unos pocos puntos, y la precisión y el coste de tokens son donde la elección duele de verdad. Segunda, el splitter basado en LLM compra el mejor recall a la peor precisión: pagas una llamada de LLM por documento y das al generador más ruido. Tercera, los números de Anthropic muestran que enriquecer los chunks con contexto (del 5,7% al 3,7%) movió la tasa de fallo más que cualquier elección de splitter de la tabla de Chroma. Enriquece los chunks antes de volver a ajustar el splitter. El reranking recupera chunks que tu splitter destrozó, y la búsqueda híbrida combina BM25 con recuperación vectorial por la misma razón.

Límites honestos: ambos estudios usan un solo modelo de embeddings, corpus solo en inglés, y ninguno es una prueba controlada de tu corpus. En 472 consultas, la diferencia entre el mejor y el peor splitter fue de unos 5 puntos de recall con 5 chunks recuperados, y una diferencia proporcionalmente mucho mayor en precisión.

¿Por qué el tamaño de chunk decide la calidad de recuperación?

El tamaño de chunk fija la granularidad de tu clave de recuperación. Un chunk de 400 tokens produce un embedding enfocado que coincide con consultas específicas; un chunk de 4.000 tokens promedia entre muchos temas y no coincide con nada con precisión. Los chunks pequeños recuperan el pasaje exacto pero pueden fragmentar una respuesta entre varios resultados. Los chunks grandes mantienen el contexto junto pero debilitan la señal del embedding.

El techo de contexto del modelo de embeddings también importa. Si tu modelo tiene un máximo de 512 tokens de entrada y le pasas 800, la cola se trunca en silencio. Tu embedding representa dos tercios del chunk. Sin ningún error en los logs.

Luego está el lado del generador. Liu et al. mostraron en "Lost in the Middle" (arXiv 2307.03172, 2023) que la precisión del LLM cae más de un 20% cuando el documento relevante queda en medio de un contexto largo. Recuperar cinco chunks de 1.000 tokens vuelca 5.000 tokens en el prompt, y la respuesta que necesitas puede caer en la posición que el modelo lee peor. Los chunks más pequeños mantienen el pasaje relevante más cerca de una posición que el modelo maneja bien.

Piénsalo como el índice de una biblioteca. Una ficha que dice "Sección 4.2, párrafo 3: política de reembolsos" te lleva a la página. Una ficha que dice "todo sobre el comercio en el siglo XX" te lleva al edificio. Tu embedding es la ficha. Construye una aplicación RAG de principio a fin para ver dónde encaja el chunking en el pipeline, y lee nuestra guía de context engineering para ver cómo los chunks recuperados se convierten en tokens del prompt. La guía de chunking de Pinecone plantea el mismo intercambio desde el lado de la base de datos vectorial.

Chunking de tamaño fijo y recursivo (empieza aquí)

El tamaño fijo es la línea base contra la que mides todo; el recursivo es lo que de verdad despliegas.

Chunking de tokens de tamaño fijo

Divide cada N tokens sin importar el contenido.

def fixed_size_chunks(text: str, size: int = 512, overlap: int = 50) -> list[str]:
    tokens = text.split()  # whitespace proxy; use tiktoken for real token counts
    chunks = []
    step = size - overlap
    for i in range(0, len(tokens), step):
        chunk = " ".join(tokens[i : i + size])
        chunks.append(chunk)
        if i + size >= len(tokens):
            break
    return chunks

La respuesta correcta para: prosa plana sin estructura de encabezados, prototipos rápidos y cualquier comparación de línea base. No es una tontería. Es el grupo de control.

Chunking recursivo de caracteres

El RecursiveCharacterTextSplitter de LangChain divide por una jerarquía de separadores: primero \n\n (párrafos), luego \n (líneas), luego . (oraciones), luego (palabras). Cada chunk se mantiene por debajo de chunk_size respetando el límite natural más grande que quepa.

from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=50,
    separators=["\n\n", "\n", ". ", " ", ""],
    length_function=len,  # swap for tiktoken len for true token counts
)
chunks = splitter.split_text(document)

La lista de separadores es la parte que todos los competidores omiten. El splitter prueba \n\n primero y solo baja a . cuando un párrafo supera chunk_size. Si tu Markdown tiene encabezados, añade "## " antes de "\n\n" para que las secciones queden intactas.

Aritmética del solapamiento: con 512 tokens y 50 de solapamiento, el paso es 462. Un documento de 10.000 tokens produce ceil(10000 / 462) = 22 chunks. Total de tokens vectorizados: 22 x 512 = 11.264, es decir, vuelves a vectorizar aproximadamente el 12,6% del corpus como solapamiento. Ese es el coste de almacenamiento y de API de evitar que las oraciones de los límites queden huérfanas.

¿Cómo funciona el chunking semántico y vale lo que cuesta?

El chunking semántico vectoriza cada oración, mide la distancia coseno entre embeddings de oraciones vecinas y corta donde esa distancia supera un umbral de percentil (normalmente el 95). Los chunks se rompen en los cambios de tema y no en recuentos arbitrarios de tokens. El notebook "5 Levels of Text Splitting" de Greg Kamradt originó este enfoque de puntos de ruptura por percentil, y el estudio de Chroma pone nombre a sus chunkers en el benchmark.

from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai import OpenAIEmbeddings

embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
splitter = SemanticChunker(
    embeddings,
    breakpoint_threshold_type="percentile",
    breakpoint_threshold_amount=95,
)
chunks = splitter.split_text(document)

Las cuentas del coste son la parte que nadie pone por delante. El chunking semántico vectoriza tu corpus dos veces: una para calcular las distancias entre oraciones y encontrar los puntos de ruptura, y otra para vectorizar los chunks resultantes para el índice. Al precio de 0,13 $ por 1M de tokens del text-embedding-3-large de OpenAI, un corpus de 10M de tokens cuesta 1,30 $ indexado de forma normal y 2,60 $ con chunking semántico. Pagas el doble antes de que se ejecute una sola consulta.

¿Qué compras con eso? En las filas de 5 recuperados de Chroma, el chunker semántico basado en clusters alcanzó un 89,0% de recall y un 6,7% de precisión contra 88,5% y 7,0% del recursivo al mismo tamaño de 200 tokens. En la tabla de resultados principal, el mismo chunker logra la mejor precisión del estudio, 8,0%, con un recall del 87,3%. Medio punto de recall arriba o abajo, y un resultado de precisión que cambia de signo según el ajuste de recuperación que leas, por el doble de factura de embeddings. Nuestro veredicto: el chunking semántico sale a cuenta en corpus con temas variados (hemerotecas, colecciones de artículos) donde los límites fijos parten temas por la mitad de forma rutinaria. Para corpus homogéneos (documentación de producto, una base de conocimiento), el recursivo te da el 95% de la calidad a la mitad del coste. Si ejecutas modelos de embeddings en local con Ollama, el coste de la doble vectorización se reduce a tiempo de cómputo.

Chunking consciente del documento: Markdown, HTML y código

La división consciente de la estructura usa los límites del propio documento (encabezados, elementos de lista, definiciones de funciones) en vez de recuentos de caracteres. Un H2 de Markdown es un límite semántico que un humano colocó a propósito; un splitter de caracteres lo tritura.

from langchain_text_splitters import MarkdownHeaderTextSplitter

headers = [("#", "h1"), ("##", "h2"), ("###", "h3")]
splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers)
splits = splitter.split_text(markdown_doc)
# Each split carries metadata: {"h1": "...", "h2": "...", "h3": "..."}

Para código, los límites son nodos del AST. Los NodeParsers de LlamaIndex traen splitters conscientes del lenguaje que cortan en definiciones de funciones y clases. El detalle crítico: mantén el bloque de imports y la firma de la clase contenedora pegados a cada chunk de función. El cuerpo de una función sin sus imports es ruido no vectorizable, así que antepón ambos a cada chunk y el embedding capturará lo que hace la función y de qué depende.

Para RAG de código en concreto: división por límites de AST, imports antepuestos, 256-512 tokens por función, solapamiento cero.

¿Y el chunking tardío, jerárquico y agéntico?

Estas son las estrategias de chunking RAG avanzadas detrás del ruido sobre "RAG 2.0", y las tres están en 1/10 de cobertura en las SERP.

Chunking tardío

El chunking tardío, introducido por Günther et al. en "Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models" (arXiv 2409.04701, septiembre de 2024), primero vectoriza el documento completo con un modelo de contexto largo y luego agrupa los embeddings a nivel de token en vectores de chunk, de modo que cada chunk lleva contexto de todo el documento y "cuesta 40 $/mes" sabe a qué se refiere "cuesta". El abstract afirma una recuperación superior en varias tareas pero no publica ninguna cifra de titular que pudiéramos verificar. El artículo de Weaviate explica la mecánica y también se detiene antes de una comparación controlada. Estado de la evidencia: prometedor, sin cuantificar.

Chunking jerárquico (padre-hijo)

Indexa chunks pequeños (256 tokens) para la recuperación; devuelve el padre (1.024 tokens) al generador. El retriever encuentra la aguja; el generador recibe el pajar que la rodea. Mantienes dos niveles de índice y un mapeo padre-hijo. Ningún benchmark público aísla el efecto.

Chunking basado en LLM / agéntico

El LLMSemanticChunker del estudio de Chroma usa GPT-4o para decidir los puntos de corte por documento: 91,7% de recall (el más alto) y 3,9% de precisión (la más baja). Pagas una llamada de LLM por documento en el momento de indexar (unos 100 $ para un corpus de 10.000 documentos) y das al generador más ruido. Resérvalo para corpus genuinamente irregulares: escritos judiciales, PDFs escaneados sin encabezados extraíbles.

¿Qué tamaño de chunk encaja con tu modelo de embeddings?

El máximo de tokens de entrada de tu modelo de embeddings es un techo de truncamiento, no una recomendación. Un modelo que acepta 8.192 tokens no vectoriza mejor a 8.192 que a 512. La calidad se degrada por dilución mucho antes del techo: el modelo promedia el significado entre más tokens y el vector deriva hacia el centroide del corpus. La columna de recomendación de abajo es la interpretación de Techsy, no la guía de los vendors.

Fuentes: guía de embeddings de OpenAI, docs de Cohere embed, docs de embeddings de Voyage, ficha del modelo BGE.

El patrón: los modelos con un techo duro de 512 tokens (Cohere v3, BGE) exigen chunks muy por debajo de 512, porque el truncamiento es silencioso. Pásale 600 tokens a uno y los últimos 88 desaparecen del embedding sin que se registre ningún error. Los modelos con techos grandes (OpenAI, Voyage, Cohere v4) toleran chunks más grandes pero no los premian. La longitud máxima de entrada de un modelo es un límite de truncamiento, no una recomendación.

Combina esto con nuestro repaso de los mejores modelos de embeddings para RAG, lo que realmente mide un score MTEB y Voyage, OpenAI y Cohere embeddings cara a cara antes de decidirte por un modelo.

¿Cómo haces chunking de documentos que no están en inglés?

Los tokenizers no son neutrales al idioma. Petrov et al. mostraron en "Language Model Tokenizers Introduce Unfairness Between Languages" (arXiv 2305.15425, 2023) que el mismo texto traducido entre idiomas puede diferir hasta 15x en longitud tokenizada. Incluso los modelos a nivel de carácter y de byte muestran más de 4x de diferencia para algunos pares de idiomas. Un chunk de 512 tokens contiene mucho menos significado en turco, árabe o japonés que en inglés.

Aquí está la misma oración tokenizada con la codificación cl100k_base de tiktoken (el tokenizer de GPT-4):

import tiktoken
enc = tiktoken.get_encoding("cl100k_base")
en = "The retrieval system returns relevant documents."
tr = "Erişim sistemi ilgili belgeleri döndürür."
ja = "検索システムは関連文書を返します。"
print(len(enc.encode(en)), len(enc.encode(tr)), len(enc.encode(ja)))
# 7 tokens, 19 tokens, 19 tokens: same meaning, 2.7x token spread

Recuentos generados con tiktoken cl100k_base, 30 de julio de 2026.

Guía práctica: con un tamaño fijo de 512 tokens, tus chunks en turco y japonés contienen alrededor del 37% del significado de tus chunks en inglés, y tus chunks en árabe contienen alrededor del 26%. Haz chunking por recuento de caracteres o de oraciones por idioma, o sube el presupuesto de tokens en proporción (unos 1.400 para turco, 2.000 para árabe). Los idiomas CJK no tienen límites de palabra por espacios, así que los splitters de caracteres se comportan distinto. La morfología del árabe empaqueta varios marcadores gramaticales en un solo token, lo que infla aún más los recuentos.

Un árbol de decisión para elegir tu estrategia de chunking

¿Qué tipo de documento?
├── Estructurado (Markdown / HTML / código)
│   └── División consciente del documento por encabezados o límites de AST
│       ├── Sitio de docs → MarkdownHeaderTextSplitter, 512 tokens, 0 solapamiento
│       └── Base de código → splitter de AST/funciones, 256-512 tokens, imports antepuestos
├── Prosa plana (artículos, informes, libros)
│   └── RecursiveCharacterTextSplitter, 512 tokens, 50 de solapamiento
│       └── ¿Temas variados? → prueba SemanticChunker en el percentil 95
├── Registros conversacionales (chat, tickets de soporte)
│   └── Corta en límites de turno, agrupa 3-5 turnos por chunk, 256 tokens
└── Corpus mixto
    └── Enruta por tipo MIME → aplica la estrategia por tipo de arriba
        └── Luego: ¿qué longitud tienen las respuestas esperadas?
            ├── Cortas (1-2 oraciones) → hijo 256, sin padre
            └── Largas (varios párrafos) → jerárquico: hijo 256, padre 1.024

Tres recetas rápidas. Chatbot de docs: MarkdownHeaderTextSplitter a 512 tokens, solapamiento cero, ruta del encabezado en los metadatos. Asistente de búsqueda de código: división por límites de AST a 256-512 tokens por función, imports antepuestos. Corpus empresarial mixto: enruta por tipo de documento en la ingesta y guarda en la base de datos vectorial donde almacenas los chunks con metadatos de tipo para ajustar por tipo después. Ese enrutamiento por documento es la totalidad del chunking adaptativo para aplicaciones RAG.

Herramientas: LangChain vs LlamaIndex vs Chonkie

No vendemos ninguna de estas; las tres primeras páginas que rankean para esta palabra clave son blogs de vendors con CTAs de producto.

Fuentes: docs de LangChain, NodeParsers de LlamaIndex, docs de Chonkie.

Las tres implementan los mismos algoritmos centrales, así que elige según lo que ya use tu pipeline. Para el stack de herramientas RAG más amplio más allá de los splitters y Qdrant, Chroma y pgvector comparados para almacenamiento, mira nuestras guías del cluster.

Cómo aborda Techsy el chunking

En los proyectos RAG de clientes, el equipo de Techsy empieza con 512 tokens y un 10% de solapamiento y no toca el splitter hasta que ha construido un conjunto de evaluación de 20-50 preguntas a partir de los tickets de soporte reales del cliente. El conjunto de evaluación va primero; luego cambiamos una variable cada vez: tamaño, solapamiento, estrategia. Nada de cambiar de splitter sin un número de antes y después sobre las mismas preguntas. Pide una consulta gratuita para tener un segundo par de ojos sobre tu pipeline de recuperación.

Preguntas frecuentes

¿Qué es el chunking en RAG?

El chunking es el paso de preprocesamiento que divide los documentos en segmentos más pequeños antes del embedding, para que el retriever pueda hacer coincidir las consultas con pasajes enfocados y no con archivos enteros. Los puntos de corte determinan lo que tu sistema puede y no puede encontrar en el momento de la consulta.

¿Cuál es la mejor estrategia de chunking para RAG?

Para la mayoría de los sistemas en producción con documentos generales, el chunking recursivo de caracteres con 512 tokens y un 10% de solapamiento es el valor por defecto más sólido. En el estudio de Chroma con 472 consultas (julio de 2024) logró un 88,5% de recall, a 3,2 puntos del método basado en LLM más caro, sin coste adicional.

¿Cuál es el tamaño de chunk óptimo para RAG?

Empieza con 512 tokens. Baja a 256 si tu modelo de embeddings tiene un techo de 512 tokens de entrada (Cohere v3, BGE) o si tus consultas esperan respuestas de una sola oración. Sube a 1.024 solo si tu conjunto de evaluación muestra respuestas de varios párrafos que se fragmentan. Mide siempre contra tus propias preguntas.

¿Cuánto solapamiento de chunks debería usar?

10-20% del tamaño de chunk (50-100 tokens a 512). El solapamiento evita que las oraciones de los límites queden huérfanas: un hecho partido entre dos chunks aparece completo en al menos uno. Por encima del 20%, vuelves a vectorizar demasiado del corpus para un rendimiento decreciente. La mayoría de los equipos se queda en el 10% y nunca lo revisa.

¿Es el chunking semántico mejor que el de tamaño fijo?

Marginalmente, y al doble de coste de embedding. El benchmark de Chroma de julio de 2024 mostró el chunker semántico basado en clusters con un 89,0% de recall y un 6,7% de precisión contra un 88,5% de recall y un 7,0% de precisión del recursivo al mismo tamaño de tokens, y su resultado de mejor precisión (8,0%) viene de un ajuste de recuperación distinto. Vale la pena para corpus con temas variados; es difícil de justificar para conjuntos de documentos homogéneos.

¿Depende el tamaño de chunk del modelo de embeddings?

Sí. Los modelos con un techo de entrada de 512 tokens (BGE, Cohere v3) requieren chunks muy por debajo de 512 porque el truncamiento es silencioso. Los modelos con techos de 8.192 o más toleran chunks más grandes pero no los premian; la calidad del embedding se degrada por dilución antes del techo. Mira la tabla de emparejamiento de arriba para los puntos de partida por modelo.

¿Cómo hago chunking de código para un sistema RAG?

Corta en límites de AST (definiciones de funciones y clases) y no en recuentos de tokens. Mantén cada chunk en 256-512 tokens por función, antepón el bloque de imports del archivo y la firma de la clase contenedora, y usa solapamiento cero ya que las funciones son unidades autocontenidas. El CodeSplitter de LlamaIndex y los splitters conscientes del lenguaje de LangChain hacen esto.

¿Qué es el chunking tardío?

El chunking tardío primero vectoriza el documento completo con un modelo de contexto largo y luego agrupa los embeddings a nivel de token en vectores de chunk. El embedding de cada chunk lleva contexto de todo el documento, lo que resuelve el problema de "¿a qué se refiere 'eso'?". Introducido por Günther et al. (arXiv 2409.04701, septiembre de 2024). Aún no hay ningún benchmark público cara a cara que cuantifique la ganancia.

¿Cómo hago chunking de documentos en otros idiomas que no sean inglés?

Los recuentos de tokens no son neutrales al idioma. La misma oración tomó 2,7x más tokens en turco y japonés que en inglés, y 3,9x en árabe (tiktoken cl100k_base). Un presupuesto fijo de 512 tokens da en silencio menos significado a los chunks que no están en inglés. Haz chunking por recuento de caracteres o de oraciones por idioma, o sube el presupuesto en proporción.

¿Cómo sé si mi chunking está funcionando de verdad?

Construye un conjunto de evaluación de 20-50 preguntas a partir de consultas reales de usuarios antes de tocar el splitter. Puntúa hit@5 y MRR contra tus chunks actuales. Cambia una variable (tamaño, solapamiento, estrategia), vuelve a ejecutar, compara. Sin un conjunto de evaluación, estás ajustando a ojo. Veinte preguntas bastan para empezar.

En resumen

• Empieza con chunking recursivo de caracteres a 512 tokens y un 10% de solapamiento. El valor por defecto correcto para prosa plana.
• En las cuatro familias de splitters que alguien ha medido, las 472 consultas de Chroma mueven el recall unos 5 puntos y la precisión varias veces más. Ajusta primero por precisión y coste.
• Casa el tamaño de chunk con el techo de entrada de tu modelo de embeddings. Un modelo con techo de 512 tokens exige chunks por debajo de 512.
• Enriquece los chunks con contexto (la caída de tasa de fallo del 5,7% al 3,7% de Anthropic) antes de volver a ajustar el splitter.
• Construye primero el conjunto de evaluación. Toda decisión de splitter sin un número de antes y después es una suposición.

Para el pipeline completo alrededor de tu elección de chunking, mira construir una aplicación RAG de principio a fin. ¿Sigues decidiendo entre recuperación y fine-tuning? RAG o fine-tuning detalla cuándo gana cada uno.