Skip to main content

Gotchas de grounding: cómo falla el retrieval en producción

Una demo de RAG recupera el único documento que probaste, sobre la única pregunta que hiciste. Producción recupera de todo lo que tenés, sobre preguntas que nadie guionó — y el chunk equivocado es una respuesta equivocada con seguridad. Diez gotchas que matan el grounding después de la demo, cada uno con la pregunta que tenés que contestar primero y el costo de equivocarte.

Nota de producción·Actualizado 2026-06-03·Escrito por Lira · Editado por German Medina

Una demo de RAG recupera el único documento que probaste, lo rankea primero y contesta la única pregunta que hiciste. Producción recupera de todo lo que tenés — el corpus entero, viejo y limpio y contradictorio todo a la vez — sobre preguntas que nadie guionó, y el chunk equivocado no se anuncia. Vuelve rankeado primero y el modelo responde desde él con fluidez. Una falla de grounding no parece un error; parece una respuesta con seguridad, bien escrita y equivocada, y alguien actúa sobre ella.

Diez gotchas que convierten una demo de retrieval que funciona en un sistema que desinforma con seguridad. Tienen la misma forma que los que matan agentes: la demo hace que el camino fácil parezca el camino entero, y producción es todo lo que el camino fácil dejó afuera. Cada uno va con la pregunta a contestar antes de salir a producción y el costo de equivocarte. Nada de esto depende del toolkit — un grounding armado sobre retrievers de Agentforce sobre el perfil de Data 360, o un pipeline de RAG externo sobre tus propios documentos, hereda todos y cada uno. Los retrievers y el pipeline externo son instrumentos complementarios que componés según el corpus y el modelo de seguridad, no bandos rivales; los modos de falla se comparten igual.

Los gotchas

1. Mal chunking — el límite mismo puede destruir el significado

El retrieval trabaja sobre chunks, y cómo cortás los documentos decide qué se puede llegar a encontrar. Chunks demasiado grandes diluyen la señal — la única oración relevante queda enterrada en tres páginas de contexto, y el embedding la promedia hasta volverla ruido. Chunks demasiado chicos pierden el contexto que hacía que la oración significara algo — un número sin unidad, una cláusula sin sujeto. Y el límite mismo es una tercera falla: un corte por la mitad de una tabla, un procedimiento o una definición puede dejar las dos mitades inservibles.

El costo de equivocarte es un corpus que contiene la respuesta pero no la puede traer — el dato está adentro, cortado de modo que nunca rankea. La pregunta a contestar antes de indexar: ¿carga cada chunk suficiente contexto para sostenerse solo, y caen tus límites sobre costuras naturales — secciones, párrafos, filas completas — en vez de un conteo fijo de caracteres que corta por el medio del significado?

2. Embedding desalineado — el modelo equivocado, o uno inconsistente, falla en silencio

La búsqueda semántica es tan buena como los embeddings que tiene debajo. Un modelo de embedding de propósito general sobre un dominio que no conoce — códigos densos de producto, términos clínicos, jerga interna — mapea texto que no puede distinguir a vectores cercanos, y la búsqueda devuelve casi-aciertos que se leen plausibles. Peor es la inconsistencia: embeddear los documentos con un modelo y las queries con otro, o cambiar el modelo y no re-embeddear el corpus, de modo que los vectores de query y los de documento ya no viven en el mismo espacio.

El costo es una búsqueda que falla sin fallar — devuelve resultados, solo que son los equivocados, y nada lo señala porque la distancia coseno es felizmente chica. La pregunta: ¿es tu modelo de embedding un fit para el vocabulario de este dominio, y está cada vector del index — documentos y queries por igual — producido por el mismo modelo y versión, de modo que una query y el chunk que la responde puedan de verdad caer cerca?

3. Index desactualizado — el agente groundea sobre la verdad de ayer

La fuente de verdad cambia; el index no cambia con ella a menos que algo lo haga. Un precio se actualiza, una política se reescribe, un registro se corrige — y el vector index todavía tiene el embedding del texto viejo hasta que corre una re-indexación. Hasta entonces, el retrieval trae el chunk viejo, el modelo groundea sobre él, y la respuesta está desactualizada con seguridad respecto del sistema que todos los demás están leyendo.

El costo es una respuesta correcta contra el index y equivocada contra la realidad — la más difícil de cazar, porque el retrieval se ve sano. La pregunta: ¿qué dispara una re-indexación cuando una fuente cambia, cuál es la máxima desactualización que podés tolerar por fuente, y cómo te darías cuenta siquiera de que el index derivó de la verdad?

4. Retrieval vacío o equivocado, contestado igual — el modelo llena el hueco desde los parámetros

El retrieval puede volver vacío, o volver con chunks que no tienen nada que ver con la pregunta, y un modelo sin instrucción de frenar no va a frenar. Responde desde su entrenamiento en cambio — con fluidez, con seguridad, y sin señal de que se lo acaba de inventar entero. Esto es el principio 2 (groundeá antes de generar) fallando en la costura, y es la misma falla que los gotchas de agentes marcan desde el lado del agente: un prompt ingenioso sin grounding es una alucinación con seguridad, y suena exactamente igual que una respuesta correcta.

El costo es la peor salida que un sistema groundeado puede producir — una respuesta sin grounding disfrazada de una groundeada, indistinguible de una cita real hasta que alguien chequea. La pregunta: ¿qué hace el sistema cuando el retrieval vuelve vacío o vuelve con chunks de baja relevancia — se abstiene, pregunta o escala — y probaste de verdad el camino de retrieval-vacío, o solo el feliz donde el documento correcto siempre estuvo?

5. Sin eval de retrieval — puntuás la respuesta pero nunca el retrieval

Es natural evaluar la respuesta final y frenar ahí, pero la respuesta son dos sistemas compuestos: un retrieval que encuentra chunks, y una generación que razona sobre ellos. Puntuá solo el final y no podés distinguir un problema de generación de uno de retrieval — una buena respuesta puede haber salido de los chunks equivocados por suerte, y una mala puede ser un buen modelo hambreado del contexto correcto. No podés arreglar lo que no medís (principio 3), y no estás midiendo la mitad que más falla.

El costo es debuggear a ciegas: tuneás el prompt una semana para arreglar lo que era un bug de chunking todo el tiempo, porque nada te dijo que el chunk correcto nunca llegó al contexto. La pregunta: ¿medís el retrieval por su cuenta — ¿se recuperó de verdad el chunk que contiene la respuesta, y en qué rank — aparte de si la respuesta final fue buena, de modo que sepas qué mitad arreglar cuando cae la calidad?

6. Sobre-retrieval — meter los cincuenta chunks de arriba degrada el razonamiento

Cuando el retrieval se siente poco confiable, el arreglo tentador es recuperar más — top-cincuenta en vez de top-cinco, "por las dudas la respuesta esté ahí en algún lado". Sale al revés. Más contexto no es mejor contexto: el chunk relevante ahora compite con cuarenta y nueve distractores por la atención del modelo, la calidad del razonamiento cae mientras la señal se ahoga, la latencia sube, y cada llamada cuesta más por un resultado peor. Esto es el principio 10 (el contexto es un presupuesto, no un balde) del lado del retrieval — el context rot es un bug de grounding tanto como uno de agente.

El costo es un sistema que se pone peor cuanto más lo alimentás, por razones que nunca aparecen como error — solo una caída lenta y confusa en la calidad de respuesta que correlaciona con el tamaño del contexto que tan cuidadosamente hiciste crecer. La pregunta: ¿cuál es el menor número de chunks que confiablemente contiene la respuesta para tu corpus, y estás recuperando hasta ese — tuneado contra tu eval de retrieval — en vez de rellenar el contexto y esperar?

7. Sin camino de "no sé" — el sistema no puede decir que no está en la base de conocimiento

Una base de conocimiento tiene bordes. Algunas preguntas caen afuera, y un sistema groundeado tiene que poder decirlo — "eso no está en la base de conocimiento" — en vez de estirarse más allá del borde e inventar una respuesta que suena como si hubiera salido de adentro. Si "no tengo eso" no es un camino que el sistema tiene permitido tomar, entonces cada pregunta fuera de alcance se vuelve una alucinación, porque el único comportamiento que le dejaste es responder.

El costo es un sistema más confiado justo donde menos sabe — en los bordes del corpus, donde no tiene nada sobre qué groundear y responde igual. La pregunta: ¿puede este sistema declinar — devolver "no está en la base de conocimiento", rutear a un humano, hacer una pregunta de aclaración — y es declinar un resultado de primera clase y probado, en vez de un accidente en el que el modelo cae solo cuando el retrieval resulta obviamente vacío?

8. Fuga de permisos en el retrieval — el index devuelve chunks que el usuario no puede ver

Un vector index aplana tu corpus en un único espacio buscable, y a menos que el control de acceso lo acompañe, aplana los permisos con él. Si el retriever puede devolver cualquier chunk sin importar quién pregunta, entonces un usuario que nunca podría abrir un documento por la puerta del frente puede sacar su contenido por el agente — búsqueda semántica como diputado confundido, leyendo material restringido en voz alta en su nombre.

El costo es un incidente de exposición de datos con la cara de una respuesta servicial — el agente hizo su trabajo y trajo exactamente el chunk que le pidieron, a alguien que nunca tuvo permitido leerlo. La pregunta: ¿filtra el retrieval por los permisos del usuario que pregunta antes de rankear, y podés probar que un chunk restringido es inalcanzable por el agente para un usuario que no tiene acceso a su fuente?

9. Costo y latencia de re-indexación ignorados — "re-embeddear todo en cada edición" no escala

Embeddear no es gratis y re-indexar no es instantáneo. Embeddear un corpus grande es una factura real en API o cómputo, y re-embeddearlo es una demora real antes de que el contenido nuevo sea buscable — minutos a horas sobre un corpus de cualquier tamaño. Un diseño que re-embeddea todo en cada edición funciona sobre los cien documentos de la demo y se cae sobre el millón de producción, donde se vuelve o una línea de costo que nadie aprobó o un lag de frescura que nadie planeó.

El costo es un sistema de grounding correcto e impagable, o pagable y desactualizado — el trade-off que no diseñaste se vuelve el trade-off con el que quedás trabado. La pregunta: ¿cuánto cuesta una re-indexación completa y cuánto tarda al tamaño real de tu corpus, y podés actualizar de forma incremental — re-embeddeando solo lo que cambió — en vez de reconstruir el mundo cada vez que un documento se mueve?

10. Citas faltantes o alucinadas — la respuesta no puede mostrar sus fuentes, o cita una que no usó

El punto del grounding es una respuesta trazable: este dato vino de ese chunk, y podés seguir el link y chequear. Dos fallas rompen esa confianza. La respuesta no muestra fuentes en absoluto, así que es indistinguible de una suposición sin grounding e imposible de verificar. O — más sutil y peor — cita una fuente que no usó de verdad, una referencia de aspecto plausible pegada después, de modo que la cita misma es una alucinación y seguirla refuta el dato que se suponía que sostenía. Sin citas trazables no podés confiar en la respuesta ni debuggearla (principio 11); no podés repetir lo que no podés ver.

El costo es un grounding que no podés auditar — una respuesta que puede estar bien o puede ser inventada, sin forma de saber cuál desde afuera y sin traza que repetir cuando está mal. La pregunta: ¿carga cada dato groundeado una cita de vuelta al chunk del que de verdad salió, y verificaste que las citas son reales — que el chunk citado de verdad sostiene el dato — en vez de confiar en un modelo que fabrica una referencia con la misma facilidad que un dato?

El hilo común a los diez: un grounding que sale a producción está chunkeado para ser encontrable, embeddeado de forma consistente, mantenido fresco, evaluado en el retrieval y no solo en la respuesta, presupuestado en contexto, consciente de permisos, pagable de refrescar y trazable a sus fuentes — o es una demo que recuperó el único documento que probaste y todavía no se encontró con una pregunta que no escribiste. Cada gotcha de arriba es un lugar donde el único retrieval feliz de la demo y la realidad de producción de recuperar-de-todo se separan, y el chunk equivocado siempre está esperando en el corpus contra el que no probaste.

Cierre

Estos diez son las fallas de grounding que Cleon vio con más frecuencia, tanto en retrievers de Agentforce como en RAG externo. La disciplina que las previene es la misma que recorre toda la ingeniería de IA: la demo recupera el único documento correcto y el modelo lo lee, mientras producción tiene que traer el chunk correcto de todo lo que tenés y después groundear un modelo limpio sobre él — la vara de calidad de retrieval y un modelo que valga la pena groundear. Acertá la vara de calidad de retrieval y la mayoría de estos nunca se dispara; salteala y lanzás un sistema que desinforma con seguridad. Ninguno es difícil de prevenir de entrada; todos son caros de descubrir en vivo, porque un bug de grounding se ve exactamente como una respuesta correcta hasta que alguien chequea la fuente.

Si querés la mecánica de grounding completa, qué es grounding es el vocabulario, chunking y embeddings es el pipeline de retrieval parte por parte, y calidad de retrieval es la vara que un sistema de retrieval pasa antes de salir. El modelo sobre el que el agente groundea importa tanto como el retrieval que corre sobre él — el chequeo de agent-readiness de Data 360 es donde un modelo limpio se encuentra con un agente seguro.

Si un gotcha de grounding le pegó a tu equipo y no está acá, escribí a hello@wearecleon.com — lo agregamos, con crédito.

Related

Reference: