Calidad de retrieval: medir y mejorar lo que recibe el modelo | Cleon

Cuando una respuesta fundamentada está mal, hay dos sospechosos, y la mayoría de los equipos interroga al equivocado primero. Editan el prompt. Pero la respuesta puede estar mal porque el modelo razonó mal o porque el retrieval le pasó el chunk equivocado para razonar — y son fallas distintas con arreglos distintos. Un modelo razonando con fidelidad sobre los tres chunks equivocados va a defender una respuesta equivocada hermosamente (principio 2). Así que antes de tocar el prompt, fijate qué surfaceó el retrieval de verdad. Ese chequeo solo existe si medís el retrieval como su propia cosa, separado de la respuesta que alimenta.

Esta es la disciplina central del grounding: la calidad del retrieval es una cosa separada de la calidad de la respuesta, y la tenés que medir por su cuenta. Esta página va en dos mitades. Primero, cómo medir el retrieval — las métricas que te dicen si el chunk correcto volvió y qué tan alto rankeó, y el eval set chico que vuelve reales a esas métricas. Después las palancas que lo mejoran, cada una con dónde encaja y qué cuesta, en la forma en que el toolkit está pensado para leerse: instrumentos complementarios que componés, no un bando que elegís (principio 7).

Medir el retrieval por separado

La calidad de la respuesta está río abajo de la calidad del retrieval, así que un solo puntaje end-to-end esconde cuál de las dos mitades está fallando. Podés tener un prompt impecable y una respuesta inútil porque el retrieval falló; podés tener un prompt mediocre que igual responde bien porque el retrieval vino limpio. Puntualos aparte, y una respuesta equivocada se parte al instante en una pregunta con un siguiente paso claro: ¿volvió el chunk correcto, sí o no?, y ¿volvió lo suficientemente alto como para que el modelo lo use?.

Dos métricas cargan con la mayor parte de eso.

Recall — ¿el chunk que debería responder la query se recuperó, sí o no, en algún lugar del set devuelto? Esta es la primera falla que hay que descartar, porque nada río abajo se recupera de un chunk que nunca se surfaceó. Si el recall es el problema, ningún trabajo de prompt ayuda; el hecho correcto nunca llegó al modelo.
Precisión y posición (precision@k) — de lo que volvió, cuánto es relevante, y dónde aterrizó el chunk correcto. Un chunk correcto recuperado en la posición 9 de una ventana de 10 chunks apenas es mejor que un miss: compite con ocho distractores por la atención del modelo, y en un contexto largo puede ser ignorado por completo. La posición importa porque el modelo pondera disparejo lo que ve; un chunk correcto enterrado abajo es un casi-miss, no un hit.

El instrumento que vuelve medibles a las dos es un eval set de retrieval: una lista chica y fija de query → el chunk (o chunks) que debería volver. Las queries las escribís desde preguntas reales — el primer puñado que te mordió en testing vale más que cualquier set sintético, porque codifican cómo falla tu corpus de verdad — y etiquetás, a mano, cuál chunk es la respuesta correcta para cada una. Después corrés el retrieval sobre el set y puntuás recall y posición de forma automática. Este es el principio 3 aplicado al retrieval en particular: si no podés evaluar el retrieval, no lo podés mejorar, solo lo podés adivinar. Y corre antes de que tunees el prompt (principio 2) — puntuá el retrieval primero, porque un prompt tuneado contra un retrieval roto solo memoriza la rotura.

Mejorar el retrieval

Una vez que lo podés medir, las palancas de abajo mueven cada una un número específico — recall, precisión, o posición. Ninguna es gratis, e ir por la más elaborada primero es el instinto del slide deck; el instinto de producción es encontrar qué métrica está fallando y tirar de la palanca más barata que la mueva. Cada palanca acá viene con dónde encaja y qué cuesta.

Hybrid search

Corré semantic search (de embeddings) y keyword search — BM25 — juntas, y mergeá los resultados. La semantic search matchea por significado y se pierde los strings exactos; un SKU de producto, un código de error, el apellido de una persona, un acrónimo raro son las cosas que una búsqueda de embeddings pura descarta en silencio porque son semánticamente irrelevantes. BM25 atrapa el término literal. Hybrid se queda con los dos.

Cuándo encaja: cualquier corpus con términos exactos que tienen que matchear de forma literal — códigos, IDs, nombres, jerga, números de producto — que es la mayoría de los corpus reales. Si tus misses de recall se agrupan en queries que contienen un token específico, esta suele ser la primera palanca para tirar.

Trade-off: ahora corrés y mantenés dos caminos de retrieval y un paso de merge (comúnmente una fusión que intercala ambos rankings), así que hay más para construir y tunear que un solo índice semántico. El costo es ingeniería y un poco de latencia, no mucha plata en runtime — y suele ser el primer movimiento de mayor apalancamiento cuando hay términos exactos en juego.

Re-ranking

Una segunda pasada: recuperás un set de candidatos top-N más amplio de forma barata, después corrés un re-ranker — un modelo que puntúa cada candidato contra la query por relevancia — y reordenás, quedándote solo con los mejores pocos. La primera pasada optimiza para recall (tirá ancho, no te pierdas nada); el re-ranker optimiza para precisión y posición (poné el chunk correcto arriba). Esta es la palanca que más directo arregla una falla de "el chunk correcto volvió, pero rankeó demasiado abajo".

Cuándo encaja: cuando el recall está bien pero la posición no — el chunk correcto está en tu top-N pero no cerca del tope, así que el modelo lo subpondera. Es de alto valor justamente porque la posición es donde muchos sistemas fundamentados pierden en silencio: el hecho estaba ahí, solo que no donde el modelo lo usaría.

Trade-off: el re-ranker es otra llamada al modelo en cada query, así que suma latencia y costo a cada retrieval. Eso lo pagás a propósito por la ganancia de precisión. El trabajo de Contextual Retrieval ↗ de Anthropic reporta el tamaño del premio: combinar contextual embeddings con contextual BM25 bajó la tasa de falla de retrieval de top-20-chunk un 49%, y sumar re-ranking encima llevó la baja al 67% — sustancialmente menos retrievals fallidos, pagados con la pasada extra.

Metadata filtering

Antes de que corra la semantic search, achicá el pool de candidatos con filtros estructurados — fuente, fecha, tipo de documento, idioma, y especialmente permisos. No busques sobre el corpus entero esperando que el chunk correcto gane por similitud; restringí a la porción que siquiera es elegible, y después buscá adentro de ella. Acá también es donde va el control de acceso: un chunk que el usuario actual no tiene permitido ver debería filtrarse antes del retrieval, no recuperarse y después suprimirse con suerte.

Cuándo encaja: cualquier corpus con estructura que valga la pena aprovechar — múltiples fuentes de confianza distinta, contenido sensible al tiempo donde los documentos viejos están mal en vez de solo añejos, o permisos por usuario. Recorta el espacio de búsqueda, lo que levanta tanto la precisión (menos candidatos irrelevantes contra los cuales rankear) como, a menudo, la latencia.

Trade-off: el filtro es tan bueno como la metadata, así que el costo está río arriba — los chunks tienen que estar etiquetados bien en la ingesta, y una etiqueta equivocada o ausente filtra el chunk correcto en silencio. Un filtro demasiado agresivo se vuelve un problema de recall que solo vas a atrapar con el eval set. Filtrar por permisos no es opcional pase lo que pase; el resto lo sumás donde el corpus tenga estructura sobre la cual apoyarse.

Query rewriting y expansión

Arreglá la query antes de que pegue contra el índice. Las queries reales de los usuarios son vagas, a medio especificar, llenas de pronombres ("¿y la segunda?"), o redactadas en nada parecido a los documentos que las responden. Un paso de rewrite — normalmente un modelo chico y rápido — convierte la query cruda en algo que el retrieval pueda matchear de verdad: resolviendo referencias de la conversación, expandiendo un acrónimo, sumando sinónimos, o partiendo una pregunta compuesta en partes que recuperás por separado.

Cuándo encaja: sistemas conversacionales donde las queries cargan contexto de turnos anteriores, y cualquier corpus donde los usuarios formulan preguntas en un lenguaje lejano a cómo está escrita la fuente. Si tus misses de recall se agrupan en queries cortas o vagas en vez de en el corpus en sí, la query es lo que hay que arreglar, no el índice.

Trade-off: otra llamada al modelo antes del retrieval — latencia y costo — y un rewrite puede derivar de lo que el usuario quiso decir, convirtiendo una query vaga-pero-respondible en una confiada-pero-equivocada. Mantené el rewriter barato y acotado, y metelo en el mismo eval set: un paso de rewrite que no podés puntuar es un lugar más donde el sistema falla en silencio.

Tuneo de chunk-size y k

Las dos perillas que están debajo de todo lo de arriba: qué tan grande es cada chunk, y cuántos (k) recuperás. Las dos se setean cuando construís el índice y la llamada de retrieval, y las dos están cubiertas en profundidad en chunking y embeddings — acá el punto es que son la base que tuneás primero, porque toda otra palanca opera encima de lo que estas produzcan. Chunks demasiado grandes entierran la respuesta en ruido; demasiado chicos y la respuesta queda partida entre chunks que no se recuperan todos. Un k demasiado bajo arriesga perderse el chunk correcto; un k demasiado alto arrastra distractores adentro de la ventana.

Cuándo encaja: siempre, como lo primero que hay que dejar más o menos bien antes de sumar maquinaria. Si el recall está fallando, probá un k más grande o límites de chunk distintos antes de construir un re-ranker; la perilla barata muchas veces mueve el número que iba a mover la palanca cara.

Trade-off: la perilla k es donde vive la tentación de sobre-recuperar, y sale para atrás. Subir k "por las dudas" inunda el contexto con chunks marginalmente relevantes, y pasado un punto eso degrada la respuesta — la señal que el modelo necesita se ahoga en los chunks que agregaste por si acaso. Eso es context rot (principio 10): el contexto es un presupuesto, no un balde, y la precisión importa tanto como el recall. El k correcto es el más chico que pasa tu vara de recall en el eval set, no el más grande que podés pagar.

El hilo

Un sistema fundamentado es tan bueno como su retrieval, y el retrieval solo es confiable si se mide. Esas dos frases son la página entera. La mitad de la medición (principio 3) es lo que convierte "la respuesta está mal, editemos el prompt" en "el recall está bien, la posición está mal, sumá un re-ranker" — un diagnóstico en vez de una adivinanza. La mitad de la mejora es un set de palancas que tirás contra un número, no un stack que ensamblás por completitud. Y la trampa debajo de todo es sobre-recuperar: llenar la ventana para sentirte seguro es el mismo error que llenar el prompt, y te cuesta de la misma forma (principio 10). La precisión se gana su lugar al lado del recall — una respuesta fundamentada necesita el chunk correcto y lo necesita donde el modelo de verdad lo vaya a usar.

Qué es el grounding — por qué el retrieval es lo que hace que una respuesta sea verdadera, y dónde se ubica en un sistema fundamentado
Chunking y embeddings — el índice sobre el que operan estas palancas: límites de chunk, elección de embedding, y la perilla k
Gotchas de grounding — los modos de falla contra los que la calidad de retrieval hace trade-off, y el costo de tenerlos mal
Debuggear agentes — el mismo hábito de medir-primero-la-capa-que-falla, aplicado a una corrida completa de agente
Gotchas de agentes — los huecos de grounding como una de las formas en que un agente se muere después de la demo
Style Guide de grounding — la vara que un sistema fundamentado pasa antes de salir
Debuggear grounding — trazar una respuesta equivocada hasta el retrieval
Principios de AI Engineering — fundamentá antes de generar (2), si no lo podés evaluar no lo podés shipear (3), el contexto es un presupuesto (10)

Reference: