¿Qué es grounding? El pipeline de retrieval sobre el que se para una respuesta | Cleon

Un agente o un solo prompt razona sobre lo que sea que le pases. Grounding es la práctica de pasarle hechos reales — recuperados de tus datos, una base, un conjunto de documentos, una API — en vez de dejar que responda desde lo que el modelo absorbió en el entrenamiento. La versión de un párrafo de esto vive en qué es un agente; esta página va en profundidad, porque el grounding es la base a la que casi todo otro problema de calidad termina rastreándose. Un modelo sin grounding responde desde sus parámetros y adivina con confianza cuando esos se agotan. Un modelo con grounding responde a partir de lo que le pusiste enfrente en esta corrida. Esa diferencia es el principio 2 — groundeá antes de generar — y es la diferencia entre una respuesta que es fluida y una respuesta que es verdadera.

La forma estándar de construir grounding tiene nombre: RAG, retrieval-augmented generation. La palabra "augmented" es toda la idea — aumentás el prompt con hechos recuperados antes de que el modelo genere. RAG no es un producto ni una librería; es un pipeline, seis etapas que van de documentos crudos a una respuesta groundeada. Esta página recorre ese pipeline una vez, de punta a punta, expone el vocabulario sobre el que se apoya el resto de esta subcategoría, y traza la línea honesta de cuándo necesitás retrieval. La profundidad de cada etapa vive en las páginas hermanas; acá el trabajo es la forma del conjunto.

El pipeline, de punta a punta

RAG se parte limpio en dos. Las primeras tres etapas pasan de antemano, cuando indexás tu conocimiento. Las últimas tres pasan en tiempo de query, cada vez que alguien hace una pregunta. Confundir las dos es donde arrancan muchos diseños de RAG embarullados.

Chunk — partí tus documentos fuente en pasajes lo bastante chicos como para recuperarlos y alimentarlos con precisión. Un PDF entero de 40 páginas es demasiado grueso para ser una unidad de retrieval; una sola oración es demasiado fina para cargar contexto. El chunking es la decisión de cómo cortar, y es más consecuente de lo que parece — ver chunking y embeddings.
Embed — convertí cada chunk en un embedding: un vector, una lista de números, que codifica el significado del chunk de manera que los pasajes sobre la misma cosa caen cerca uno del otro en el espacio vectorial. Esto es lo que te deja buscar por significado en vez de por palabras exactas.
Store — cargá esos vectores en un vector store (un vector index) para poder buscarlos rápido. El index se construye una vez y se reutiliza en cada query; reconstruirlo es cómo entran los documentos nuevos o cambiados.
Retrieve — en tiempo de query, embebé la pregunta del usuario de la misma forma, y después traé los chunks cuyos vectores quedan más cerca de ella. Este es el corazón de RAG, y la etapa que más a menudo decide si la respuesta es correcta — calidad de retrieval es una disciplina en sí misma.
Augment — inyectá los chunks recuperados en el prompt, junto con la pregunta y las instrucciones, para que el modelo tenga los hechos enfrente. Esto es el "augmented" de RAG: el prompt que el modelo ve es la pregunta más lo que el retrieval encontró.
Generate — el modelo lee el prompt aumentado y escribe la respuesta, groundeada en los chunks que le pasaste en vez de en el entrenamiento. Bien hecho, podés rastrear cada afirmación de la respuesta de vuelta a un chunk que la sostiene.

El corte importa porque las dos mitades fallan distinto y se arreglan en lugares distintos. Una respuesta mala que se rastrea a lo que indexaste — chunking equivocado, documentos viejos, huecos de cobertura — se arregla de antemano, en las primeras tres etapas. Una respuesta mala que se rastrea a lo que se recuperó en esta corrida — volvieron los chunks equivocados, o no volvió ninguno — se arregla en tiempo de query, en el retrieval. Saber en cuál mitad estás es la mitad del debugging.

Cuándo necesitás grounding — y cuándo no

Acá está el test honesto, paralelo al de los agentes: ¿la respuesta depende de hechos para los que el modelo no fue entrenado, o que cambian?

Si sí, necesitás grounding. Cualquier cosa sobre tus datos — el historial de pedidos de un cliente, la política de este trimestre, un documento escrito la semana pasada, un registro en tu CRM — por definición no está en el entrenamiento del modelo, y ninguna astucia de prompt la conjura. El modelo o va a decir que no sabe o, peor, va a inventar algo plausible. El retrieval es la única forma honesta de poner esos hechos al alcance. Lo mismo vale para cualquier cosa que cambia más rápido de lo que se reentrenan los modelos: precios, inventario, estado, el estado actual de cualquier sistema de registro.

Si no, no la necesitás. Una tarea autocontenida — una donde todo lo que el modelo necesita ya está en el prompt — no necesita retrieval para nada. Resumí este email. Clasificá este ticket. Reescribí este párrafo en un registro más simple. Extraé las fechas de este contrato. La entrada carga sus propios hechos; no hay nada que ir a buscar. Atornillarle RAG a una tarea autocontenida agrega latencia, costo y un nuevo modo de falla (mal retrieval) a cambio de nada. La disciplina refleja la de los agentes: agarrá retrieval solo cuando la respuesta genuinamente vive afuera del prompt, y ni un paso antes.

El vocabulario

Esta subcategoría se apoya en un conjunto chico de términos. Acá están una vez, en simple; vas a conocer cada uno en profundidad a medida que la subcategoría avanza.

Chunk — un pasaje de un documento fuente, dimensionado para ser una unidad de retrieval. Demasiado grande y diluye; demasiado chico y pierde contexto.
Embedding — un vector que codifica el significado de un chunk, de manera que el texto semánticamente similar queda cerca en el espacio vectorial. Lo produce un embedding model, que es un modelo distinto del que genera la respuesta.
Vector store / vector index — la base que guarda los embeddings y responde rápido las búsquedas de vecinos más cercanos sobre ellos. A veces un servicio dedicado, a veces una feature de una base que ya corrés.
Semantic search — retrieval por significado: embebé la query, encontrá los chunks cuyos vectores están más cerca. Atrapa paráfrasis y sinónimos que la búsqueda por palabra exacta se pierde.
Keyword / BM25 search — retrieval por superposición de términos, el enfoque léxico clásico. Es imbatible en los matches exactos — nombres, códigos, strings de error, IDs — justo donde el semantic search puede aflojar.
Hybrid search — correr el retrieval semántico y el de keyword juntos y fusionar los resultados, para tener significado y matches exactos. En producción esto suele ser el default correcto, antes que cualquiera de los dos solo.
Top-k — cuántos chunks recuperás por query. Traé los top-5 y le pasás al modelo cinco pasajes; traé demasiados y ahogás la señal y quemás presupuesto de contexto (principio 10); traé muy pocos y te perdés el chunk que tenía la respuesta.
Re-ranking — una segunda pasada que toma los candidatos recuperados y los reordena por relevancia con un modelo más cuidadoso (y más caro), para que los mejores chunks queden primeros y los apenas-cercanos caigan.
Context window — el espacio finito del prompt que los chunks recuperados tienen que compartir con las instrucciones y la pregunta. El retrieval no se queda con toda la ventana; se queda con lo que queda después de todo lo demás, que es por qué el top-k y el re-ranking importan.

Cómo se ata esto a los agentes

Un agente lee el mundo a través del retrieval de la misma forma que un solo prompt groundeado — sus tools traen datos, sus respuestas se paran sobre lo que vuelve. Toda falla de grounding en esta subcategoría es entonces también una falla de agente: cuando un agente está equivocado con confianza, la causa es mucho más a menudo lo que el retrieval le pasó que el modelo que razonó sobre eso. Esa falla exacta es el gotcha 8 en gotchas de agentes — un prompt ingenioso sobre un retrieval vacío o equivocado es una alucinación con seguridad que suena idéntica a una respuesta correcta. El grounding está aguas arriba de eso. Hacé bien el retrieval y toda una clase de bugs de "el modelo está equivocado" desaparece, porque nunca fueron culpa del modelo.

Por eso la subcategoría existe como par de los agentes y no como una nota al pie adentro. El modelo aporta fluidez; el grounding aporta los hechos; y la línea entre una IA que impresiona en una demo y una que es correcta el lunes a la mañana atraviesa de lleno el pipeline de retrieval.

A dónde ir después

Desde acá, dos direcciones hacia la profundidad. La mitad de antemano — cómo cortar documentos y qué codifican de verdad los embeddings — es chunking y embeddings. La mitad de tiempo de query — por qué vuelven los chunks equivocados y cómo medirlo y arreglarlo — es calidad de retrieval. Y los modos de falla antes de chocártelos en producción, el equivalente en grounding de los gotchas de agentes, están en gotchas de grounding.

El lado de plataforma se parte igual que en los agentes, en tools complementarias que un ingeniero compone y no en un versus. Dentro del modelo de seguridad de Salesforce, el grounding se construye con los retrievers de Agentforce sobre el perfil de Data 360 — un modelo de datos limpio y gobernado es la precondición, que es el chequeo de agent-readiness de Data 360. Por fuera, el grounding es un pipeline de RAG sobre tu propio vector store, cableado con LangChain y la Claude API. Ambos construyen el mismo pipeline que esta página recorre; difieren solo en dónde viven los datos y quién los gobierna.

Chunking y embeddings — la mitad de antemano: cómo cortar documentos, y qué codifica de verdad un embedding
Calidad de retrieval — la mitad de tiempo de query: por qué vuelven los chunks equivocados, y cómo medirlo y arreglarlo
Gotchas de grounding — los modos de falla — retrieval vacío, index viejo, alucinación con seguridad — y cómo atraparlos
Qué es un agente — el sistema cuyas respuestas se paran sobre el grounding
Gotchas de agentes — el gotcha 8 es la falla de grounding, vista desde el lado del agente
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 — groundeá antes de generar (2), el sistema es el trabajo (4), el contexto es un presupuesto (10)

Reference: