Chunking en RAG: la decisión que nadie revisa

En pocas palabras: Según el análisis de Fetchply, el chunking es la decisión de mayor impacto en un pipeline RAG: pesa más que los embeddings, la base vectorial y el reranker. Cortar a mitad de oración —como separar “no se pueden devolver” de su regla— genera respuestas mentirosas incluso con Claude de Anthropic.

El chunking en RAG decide qué fragmentos de tus documentos le llegan al modelo cuando responde, y según el análisis que publicó el equipo de Fetchply, es la decisión de mayor impacto y menor discusión de todo el pipeline: pesa más que el modelo de embeddings, la base vectorial o el reranker.

El chunking es el proceso de dividir documentos largos en fragmentos pequeños para indexarlos en un sistema de búsqueda semántica. En un pipeline RAG, cada consulta se convierte en un embedding, el sistema recupera los chunks más parecidos y el LLM responde usando ese contexto como única fuente. Si un corte separa una regla de su excepción, la respuesta sale mal aunque los modelos sean excelentes.

¿Qué es el chunking y por qué lo ignoran todos?

Preguntale a un equipo cómo funciona su sistema RAG y te va a describir el modelo de embeddings, la base vectorial y, si son finos, el reranker. Preguntales cómo dividen los documentos y la respuesta suele ser un encogimiento de hombros: “500 tokens con algo de overlap, lo que dejó el default”. Esa configuración heredada define la calidad de cada respuesta que da el sistema, y nadie la eligió a conciencia.

Acá hay algo medio irónico. Los modelos dan charlas, tienen benchmarks y tienen fans. Las funciones de splitting no: viven en un archivo utils.py que nadie abrió desde el prototipo. ¿Quién revisó esa función después del día uno? Nadie. Y es exactamente ahí donde se juega qué va a leer el modelo.

¿Qué pasa cuando un chunk corta una oración a mitad de sentido?

Cortás una regla de su excepción y obtenés respuestas incorrectas con todo el stack funcionando perfecto. El caso que trae el artículo original es tan simple que duele. Imaginá una política de reembolsos con dos partes: devolución dentro de 30 días de la entrega con embalaje original, y una excepción clave, los artículos en oferta no se devuelven salvo que estén defectuosos, en cuyo caso corren 90 días sin importar su condición.

Un chunker fijo que corta cada N caracteres puede generar un fragmento que termina así: “Los artículos en oferta son definitivos y no se pueden devolver salvo”. Fin del chunk. La palabra “defectuosos” y la ventana de 90 días quedaron en otro bloque que puntuó peor y nunca entró al prompt. Un cliente pregunta “¿puedo devolver un artículo en oferta?”, el retriever encuentra ese fragmento, el modelo lee y responde que no se puede. El embedding está bien, la base vectorial está bien, el LLM hizo lo que le pediste. La respuesta igual está mala. Te puede servir nuestra comparativa entre Claude y Gemini 2.5.

¿La causa? Un off-by-one en una función de corte que nadie miró. Corrís el chunker, te genera sus miles de fragmentos, los indexás, todo verde en producción, pasan tres meses, un usuario hace una pregunta trivial, el bot contesta cualquier cosa y nadie encuentra el origen del bug porque nadie piensa buscarlo en el splitter del primer día.

Mismo stack, mismos modelos, respuesta correcta si el chunker hubiera respetado los títulos y dejado la sección completa de reembolsos junta. (Sí, en serio: cambiar dónde cortás puede valer más que cambiar de modelo.)

¿Cuál es el tamaño de chunk ideal en RAG?

Para documentación en prosa, el punto de partida razonable es un chunk de 200 a 500 tokens, y después medir con tu propio corpus. No hay número universal: lo que existe es un tradeoff que conviene elegir a propósito y no por accidente.

El modelo mental es este: un embedding comprime un chunk en un único punto del espacio vectorial, y ese punto resume el significado del fragmento entero. De ahí salen los dos extremos del problema. Los chunks chicos te dan recuperación precisa pero contexto amnésico: un fragmento de dos oraciones sobre tasas de reposición genera un punto afilado y específico, tu pregunta aterriza al lado, pero cuando el modelo lo recibe quizás no alcanza para responder, porque “debe estar sin abrir” no sirve de nada si aquello a lo que refiere quedó definido dos párrafos atrás. Los chunks grandes van en dirección opuesta: uno de 2.000 tokens que mezcla reembolsos, envíos y garantías termina siendo un punto pastoso en el medio de los tres temas, tu pregunta precisa queda cerca del blob y un chunk más angosto sobre otro tema puede superarlo en el ranking.

Y está el costo silencioso: recuperar tres chunks de 2.000 tokens significa enviar 6.000 tokens al modelo para resolver una duda sobre una sola oración. Sobre eso hablamos en cómo rinde Claude frente a GPT-4o.

¿Conviene usar overlap entre chunks?

Un solapamiento del 10-20% ayuda y probablemente convenga usar algo, pero tiene precio. El mecanismo es simple: cada chunk repite el tramo final del anterior, de modo que una oración que cruza el límite aparezca entera en algún fragmento. Suena razonable hasta que mirás la factura (esa “solución” que nadie midió suele ser la más cara).

• Storage y dinero: un 15% de overlap significa embeber y almacenar 15% más tokens, para siempre (que no es poco), en cada re-ingesta. Si autoalojás el índice en un VPS, ese sobrante también paga disco y RAM.
• Casi-duplicados en el ranking: dos chunks solapados son semánticamente gemelos y se recuperan juntos; tu top 3 se vuelve un top 2 con un lugar quemado.
• No ataca el problema real: parchea cortes arbitrarios sin volverlos menos arbitrarios. Es una venda sobre un splitter que ignora la estructura del documento.

¿Qué diferencia hay entre chunking fijo, recursivo y por estructura?

La diferencia está en cuánto lee el splitter antes de cortar. El chunking fijo parte cada N caracteres sin mirar nada; el recursivo prueba separadores en orden de significancia (primero párrafos, después oraciones, y el conteo de caracteres como último recurso absoluto); el consciente de estructura arranca por los títulos y secciones que el autor ya escribió. La idea contraintuitiva es que el mejor algoritmo de chunking apenas califica como algoritmo: es respeto por la estructura que alguien ya te dio.

Todos los frameworks mainstream tienen versión de esto, desde el recursive character splitting de LangChain hasta los markdown header splitters nativos de LlamaIndex, y para documentación en HTML o markdown, partir por títulos elimina de raíz toda la clase de fallas del ejemplo del reembolso.

Estrategia	Cómo corta	Hit rate típico*	Cuándo conviene
Fija por caracteres	Cada N caracteres, a ciegas	~62%	Prototipos desechables
Recursiva con separadores	Párrafos, luego oraciones, caracteres al final	Intermedio	Texto plano sin estructura
Por títulos (structure-aware)	Respeta headings y secciones	~78%	Docs en HTML o markdown
Breadcrumbs contextuales	Jerarquía del documento antes del embedding	~84%	FAQs y secciones cortas

*Valores ilustrativos del artículo original, típicos de lo que vas a ver en tu propio corpus: importan los saltos entre estrategias, no los valores absolutos.

¿Qué son los headers contextuales en chunking?

Son la ruta jerárquica del documento pegada antes del texto de cada chunk antes de calcular el embedding. Una vez que partís por títulos, sabés en qué rama vive cada fragmento, y esa información se puede anteponer: “Devoluciones y Reembolsos > Política de devolución > Artículos en oferta”, seguido del cuerpo. Para más detalles técnicos, mirá el duelo actual entre GPT-5 y Claude.

Ponele que el cuerpo del chunk sea “Sí, dentro de los 30 días, con embalaje original”. Embebido solo no significa nada: podría hablar de devolver zapatillas o de alquilar andamios. Con la ruta jerárquica delante, ese mismo fragmento pasa a vivir cerca de cada consulta relacionada con devoluciones, y cuando llega al prompt el modelo entiende a qué refiere el “sí”. El truco cuesta unas decenas de tokens por chunk y rescata una y otra vez las secciones cortas dependientes de contexto, siendo las respuestas de FAQ el caso clásico, porque la mitad empiezan con un “Sí” o un “No” pelado.

Anthropic fue más lejos con su línea de investigación de contextual retrieval: usan un LLM para redactar una oración de contexto específica de cada chunk. La humilde ruta jerárquica te lleva gratis una parte sorprendente de ese beneficio (spoiler: antes de gastar tokens de LLM por chunk, probá el breadcrumb).

¿Cómo saber si tu estrategia de chunking funciona?

Con un golden set de 30 a 50 preguntas reales etiquetadas con su documento fuente y una métrica: el hit rate de recuperación en el top-k. Ahí es donde se corta la mayoría de los equipos: miran tres respuestas, les gustan, mandan a producción y después discuten el tamaño de chunk en Slack durante un año con las vibes como única evidencia. Medir es posible y la medición ni siquiera es difícil.

El procedimiento cabe en un párrafo: para cada pregunta del set, verificás si alguno de los chunks recuperados proviene de la sección etiquetada como respuesta correcta. Re-chunkeás con otra estrategia, re-embebés, corré el set, comparás un número. Como valores ilustrativos del artículo, los chunks fijos de 500 caracteres rondan el 62%, los conscientes de títulos el 78% y sumando headers contextuales el 84%. Opiniones convertidas en experimentos.

Dos notas prácticas que valen oro. Primero: sacá las preguntas doradas de consultas reales de usuarios si las tenés, porque la gente real escribe peor que vos, y eso es lo que la recuperación tiene que sobrevivir. Segundo: mantené el eval rápido y corrélo en cada cambio de ingesta, igual que los unit tests en cada commit. Un eval que exige abrir un notebook y una tarde libre se corre dos veces y después nunca más. ¿Quién abre un notebook un jueves a las seis de la tarde? Exacto: nadie.

Errores comunes de chunking en RAG (y cómo corregirlos)

Estos cuatro errores aparecen en proyecto tras proyecto, y todos se arreglan en una tarde. Complementá con precios y benchmarks de Google frente a Claude.

• Dejar el default del framework sin revisar. Lo heredaste del prototipo y quedó congelado desde entonces. Corrección: abrí el índice y leé diez chunks al azar hoy mismo.
• Agrandar los chunks para que “no se corte nada”. Canjeás una falla visible por una más tramposa: embeddings diluidos y ranking más pobre. Corrección: mantené el rango de 200-500 tokens y atacá el corte con estructura, no con tamaño.
• Tratar el overlap como solución completa. Encarece storage y quema ranuras del top-k con duplicados. Corrección: overlap modesto solo donde falte estructura, y de preferencia arreglá el splitter.
• Validar a ojo. Tres respuestas simpáticas no son un benchmark. Corrección: golden set de 30-50 preguntas con hit rate por versión, corriendo en cada ingesta.

El test rápido que propone el autor: si un chunk aislado te confunde sin contexto extra, al modelo de embeddings lo confunde el doble.

¿Cómo implemento chunking correcto en mi pipeline, paso a paso?

Ordenado por esfuerzo creciente, este es el camino que recomienda el análisis:

• Partí por estructura, no por caracteres: títulos primero, párrafos después, oraciones si todavía falta.
• Mantené la prosa en 200-500 tokens por chunk y ajustá midiendo, nunca a ojo.
• Sumá overlap modesto únicamente donde no haya estructura disponible.
• Anteponé la ruta jerárquica antes de embeber cada chunk.
• Armá el golden set para que cada cambio futuro sea una medición y no otra discusión de Slack.

Preguntas Frecuentes

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

Entre 200 y 500 tokens por chunk para documentación en prosa, según el análisis publicado por el equipo de Fetchply. Ese rango equilibra precisión de recuperación con contexto suficiente, y siempre debe afinarse midiendo el hit rate sobre preguntas reales de tu propio corpus.

¿Cuánto overlap conviene usar entre chunks?

Un 10-20% del chunk anterior es el punto habitual. Ese solapamiento garantiza que una oración cortada por el límite aparezca entera en algún fragmento, aunque cada punto porcentual suma storage y genera casi-duplicados que desperdician ranuras del top-k.

¿Qué es el contextual retrieval de Anthropic?

Es una técnica que usa un LLM para redactar una oración de contexto específica de cada chunk antes de calcular su embedding. La versión económica antepone la ruta jerárquica del documento (breadcrumb) y captura buena parte del beneficio sin costo adicional de modelos.

¿Cómo evalúo si mi estrategia de chunking es buena?

Construí un golden set de 30 a 50 preguntas reales etiquetadas con su documento fuente y medí el hit rate de recuperación en el top-k. Como valores ilustrativos del artículo, ese número va de 62% con chunks fijos de 500 caracteres a 84% combinando estructura y headers contextuales: importan los saltos entre estrategias, no los valores absolutos.

¿Por qué mi RAG responde mal si uso buenos modelos?

Revisá los chunks antes de culpar al modelo: probablemente un corte a mitad de oración separó una regla de su excepción y el LLM respondió fielmente un contexto roto. Ningún modelo puede responder bien desde un párrafo partido a la mitad.

Conclusión

Lo que cambió con esta discusión es la mirada, más que la tecnología. Los modelos se llevan la atención porque son la parte emocionante, pero el chunking es la parte gris que determina qué lee el modelo, y ningún modelo responde bien desde un párrafo cortado a la mitad. Si tus respuestas RAG vienen flojas, antes de comprar un embedding mejor, abrí el índice y mirá qué le estás dando de comer.

Hoy mismo podés hacer tres cosas: leé diez chunks al azar, cambiá el splitter fijo por uno consciente de títulos y armá el golden set de 30 preguntas. Es una tarde de trabajo, te deja números comparables de ahora en adelante y la próxima vez que alguien proponga “probar otro modelo” vas a tener data para discutir de igual a igual.

Fuentes

• Fetchply en Dev.to – Chunking: the most underrated decision in your RAG pipeline
• Anthropic Research – investigaciones de contextual retrieval