Chunking y embeddings: los inputs de los que depende la calidad del retrieval | Cleon

El retrieval se lleva la atención, pero solo puede devolver lo que le pusiste enfrente. Dos pasos pasan antes de que corra una sola query, y los dos deciden el techo de todo lo que viene después: hacés chunking de los documentos — los partís en pedazos — y embedés cada pedazo — lo convertís en un vector que captura su sentido. Equivocate en cualquiera de los dos y no hay ajuste de retrieval, ni reranker, ni prompt ingenioso que lo recupere. Una query afilada sobre data mal chunkeada y mal embedeada es maquillaje sobre un error (principio 2 — groundeá antes de generar; principio 4 — el modelo es la parte fácil). Esta página es sobre esas dos palancas de upstream, en orden, porque ahí se gana o se pierde la calidad del retrieval.

Esto es una referencia, no una receta. Las técnicas de abajo son las que aguantan; el valor correcto de cada dial depende de tus documentos, y encontrarlo es para lo que sirve un set de eval (mirá retrieval quality).

Por qué hacés chunking

Hacés chunking porque no podés embedear un documento entero como un solo vector y esperar que sirva. Un embedding comprime su input en un único punto del espacio; cuanto más largo y variado el input, más sentido se promedia hasta que el vector no significa nada en particular. Una query sobre un párrafo enterrado en un contrato de cuarenta páginas no va a caer cerca de un vector que embarró las cuarenta páginas juntas. Así que partís el documento en pedazos lo bastante chicos como para que cada uno sea sobre algo, y embedés esos.

Todo el juego del chunking es un trade-off, corrido en el borde de cada chunk:

Demasiado grande diluye el embedding y desperdicia contexto. Un chunk que abarca tres temas sin relación produce un vector cerca de ninguno, y cuando lo recuperás gasta tu presupuesto de contexto en los dos tercios que la query no pidió (principio 10 — el contexto es un presupuesto, no un balde).
Demasiado chico pierde el contexto que un chunk necesita para tener sentido. Un fragmento de dos oraciones que dice "el límite es 500 por día" es inútil si el documento nunca repite qué tiene ese límite; el chunk ya no carga lo suficiente como para responder nada por sí solo.

La mayoría de los equipos descubre este trade-off saliendo con el primer número que se les cruzó — partir cada 1000 caracteres — y después se preguntan por qué el retrieval es mediocre. El arreglo no es un tamaño de chunk mágico. Es hacer coincidir el corte con la forma de tus documentos.

Estrategias de chunking

Tres estrategias, de la más burda a la más fina. Son complementarias — la mayoría de los pipelines reales las mezclan — no una escalera donde gana la última.

Fixed-size — partir cada N tokens, casi siempre con un overlap para que una oración cortada en un borde igual aparezca entera en el chunk siguiente. Es la más simple de armar y la menos consciente del sentido: te corta una tabla a la mitad o termina un chunk a media cláusula sin problema. Sirve como baseline, y a veces es todo lo que necesitan los documentos con forma de prosa.
Estructural — partir por la estructura propia del documento: por heading, por sección, por párrafo, por las filas de una tabla. Esto respeta los bordes que el autor ya dibujó, así que un chunk tiende a ser sobre una cosa porque quien escribió lo hizo sobre una cosa. Es la estrategia que más rinde en documentos con estructura real — docs, artículos de knowledge base, contratos con cláusulas numeradas.
Semántico — partir donde cambia el sentido, detectado midiendo cuándo dos oraciones consecutivas dejan de parecerse entre sí. Más caro de computar y más trabajoso de correr, puede encontrar bordes que ni fixed-size ni la estructura ven — un cambio de tema a media sección que ningún heading marca. Agarralo cuando la estructura es pobre y el baseline de fixed-size está dejando sentido tirado.

El overlap merece su propia línea porque es el arreglo más barato para el bug de chunking más común. Con overlap cero, un dato que cruza un borde — una oración con el sujeto en el chunk uno y el predicado en el chunk dos — no es recuperable desde ninguno. Un overlap modesto (una o dos oraciones repetidas en cada borde) recompra la mayor parte de esa pérdida por un costo chico de almacenamiento. No es gratis, y meter overlaps enormes por las dudas vuelve a traer el problema de demasiado grande, pero un poco casi siempre está bien.

Contextual Retrieval: la técnica que vale conocer

Hasta un chunk bien ubicado pierde el contexto del documento del que salió. "El límite es 500 por día" embeda igual sea sobre llamadas a la API o sobre intentos de login, porque el chunk solo no lo dice. Contextual Retrieval, una técnica que publicó Anthropic, arregla esto de frente: antes de embedear cada chunk, le prependés un resumen corto y específico del chunk que lo ubica en su documento de origen. El chunk deja de ser un fragmento desnudo; carga su propio contexto adentro del vector.

El prefijo contextual se genera por chunk — típicamente de 50 a 100 tokens — describiendo dónde se ubica el chunk y a qué se refiere. Un chunk pelado y su forma contextualizada hacen la idea concreta:

# Chunk pelado (lo que embeda un split ingenuo)
El límite es 500 por día.

# Chunk contextualizado (Contextual Retrieval prepende un resumen, después embeda esto)
Este chunk es de la sección Rate Limits de la referencia de la Orders API,
que describe el tope por key de las llamadas de creación de órdenes.
El límite es 500 por día.

La versión contextualizada embeda a un punto del espacio mucho más útil: una query sobre rate limits de la API ahora cae cerca, donde la versión pelada era ambigua. Anthropic reportó que los embeddings contextuales por sí solos redujeron la tasa de fallas de retrieval en el top-20 un 35 por ciento (y más al combinarlos con búsqueda por keyword contextual), que es una ganancia grande para un paso de preprocesamiento que corrés una sola vez. Cuesta una generación extra por chunk en el momento de indexar — un costo real, pero por única vez, y el prompt caching sobre el documento de origen lo mantiene modesto. Cuando al retrieval se le escapan chunks que son claramente relevantes, este es uno de los arreglos de mayor palanca disponibles. Mirá el link de referencia abajo para el write-up completo de Anthropic y los números.

Qué es un embedding en realidad

Un embedding es un vector — una lista de números, seguido unos pocos cientos hasta un par de miles de ellos — que representa un pedazo de texto como un único punto en un espacio de muchas dimensiones. El modelo que lo produce está entrenado para que el texto con sentido parecido caiga cerca de otro texto parecido, y el texto sin relación caiga lejos. "Cancelá mi suscripción" y "cómo termino mi plan" apuntan casi al mismo lugar a pesar de no compartir casi ninguna palabra; "cancelá mi suscripción" y "está lindo el día" apuntan a esquinas opuestas. Ese es todo el truco sobre el que corre el retrieval: embedés la query, embedés cada chunk, y los chunks cuyos vectores están más cerca del vector de la query son tus candidatos (el top-k — mirá retrieval quality).

La cantidad de dimensiones — digamos alrededor de 512, aunque los modelos ofrecen un rango — es una perilla. Más dimensiones pueden capturar distinciones más finas pero cuestan más de almacenar y comparar a lo largo de millones de chunks. Es un trade-off de ingeniería real, no un dial de "más grande es mejor".

El modelo de embedding es una decisión

Elegir un modelo de embedding es una decisión de diseño con los mismos trade-offs que cualquier otra, y cuatro ejes cargan la mayor parte:

Dimensión — qué tan largo es cada vector. Más alto puede significar resolución semántica más fina; también significa más almacenamiento y búsqueda de similitud más lenta a escala. Algunos modelos te dejan truncar a una dimensión más corta cuando preferís velocidad antes que el último incremento de precisión.
Costo — pagás por token embedeado, y embedés tu corpus entero una vez más cada query para siempre. Sobre un corpus grande esto es un renglón de la factura, no un error de redondeo (principio 6 — el costo y la latencia son features).
Latencia — el embedding de la query está directo en tu camino de cara al usuario. La query tiene que embedearse antes de que el retrieval siquiera arranque, así que un modelo de embedding lento es latencia que siente cada usuario.
Fit de dominio — un modelo entrenado sobre texto web general puede resolver mal un corpus cargado de jerga legal, médica o de dominio, donde las distinciones que importan son justo las que el texto general borra. Algunos proveedores ofrecen modelos afinados por dominio para exactamente esto.

Una regla no es un trade-off sino una restricción dura: la query y los documentos tienen que embedearse con el mismo modelo. Dos modelos distintos producen vectores en dos espacios distintos, y una distancia calculada entre espacios es ruido. Si cambiás el modelo de embedding, reembedés el corpus entero — no hay mezclar vectores viejos de documento con vectores nuevos de query. Ese costo de reembedear es parte de la decisión.

El hilo

El chunking y los embeddings están upstream del retrieval, y los problemas de upstream no se anuncian — aparecen downstream como "el retrieval anda mal" y te mandan a ajustar la capa equivocada. Un chunk partido de forma que perdió su contexto, o embedeado por un modelo que no resuelve tu dominio, ya era un error antes de que la query corriera. Por eso esta página viene antes de retrieval quality: ajustás el retrieval después de que los inputs están bien, no en lugar de tenerlos bien. Cuando el retrieval rinde poco, llevalo de vuelta hasta el origen — ¿son los chunks del tamaño y la forma correctos, cargan su contexto, es el modelo de embedding un fit para este corpus — antes de tocar top-k, reranking o el prompt. La query ingeniosa es la última palanca, no la primera.

What is grounding — por qué un agente responde desde lo que le entregás, no desde lo que memorizó
Retrieval quality — la capa que estos inputs alimentan: top-k, reranking, y medir si el retrieval funciona
Grounding gotchas — los modos de falla, incluido el retrieval vacío y de chunks equivocados
Tools and actions — el retrieval como una tool que un agente llama, y mantener su radio de explosión chico
Grounding Style Guide — the bar a grounded system clears before it ships
Debugging grounding — tracing a bad answer to its retrieval
AI Engineering principles — groundeá antes de generar (2), el modelo es la parte fácil (4), el costo y la latencia son features (6), el contexto es un presupuesto (10)

Reference: