Skip to main content

Style Guide de grounding: la vara que el retrieval pasa antes de salir

Las reglas con opinión que Cleon aplica a cada sistema groundeado — la primera decisión (¿necesitás retrieval siquiera?), la vara de retrieval quality que un pipeline pasa antes de salir, y cómo componemos los retrievers de Agentforce y el RAG externo según dónde viven los datos en vez de elegir un bando. El documento de disciplina que convierte los gotchas de grounding en una vara y los principios en práctica, puntuando el retrieval antes de que nadie toque el prompt.

Marco de decisión·Actualizado 2026-06-03·Escrito por Lira · Editado por German Medina

Esta es la página donde Cleon deja de describir qué es el grounding y dice qué hacemos antes de que el retrieval salga. Las páginas de referencia presentan las partes — qué es grounding, el chunking y los embeddings que fijan el techo, la retrieval quality que medís y ajustás. Los gotchas presentan dónde muerde cada parte. Este Style Guide es la disciplina que decide si conviene groundear, y la vara que el retrieval tiene que pasar antes de que una respuesta que alimenta toque un cliente o un registro.

Las reglas son cortas a propósito. Cuando una regla necesita explicación, la explicación vive en la página que enlaza. Esta es la forma operativa de los principios de AI Engineering — cada regla de abajo es uno de esos principios con las mangas arremangadas, y citamos el número para que puedas rastrear la regla hasta su razón. Es la compañera del lado de grounding del Style Guide de agentes: un agente lee el mundo a través del retrieval, así que su vara arranca acá.

La primera decisión: ¿necesitás grounding siquiera?

Antes que todo lo demás, contestá esto: ¿la respuesta de verdad necesita retrieval? El test honesto es una pregunta — ¿la respuesta depende de hechos sobre los que el modelo no fue entrenado, o que cambian? (Mirá qué es grounding.) Si sí, groundeás; ninguna astucia en el prompt conjura un hecho que el modelo nunca vio. Si no, no — y enchufarle RAG a una tarea cuyos hechos ya están en el prompt te compra latencia, costo y un modo de falla nuevo a cambio de nada (principio 12 — arrancá del problema).

El corte, según dónde viven los hechos:

  • Groundealo cuando la respuesta depende de tus datos — el historial de pedidos de un cliente, la política de este trimestre, un registro en el CRM, un documento escrito la semana pasada — o de cualquier cosa que cambia más rápido de lo que se reentrena el modelo: precios, inventario, estado. El hecho no está en el entrenamiento; el retrieval es la única manera honesta de ponerlo al alcance.
  • No cuando la tarea es autocontenida — todo lo que el modelo necesita ya está en el prompt. Resumir este email, clasificar este ticket, reescribir este párrafo, extraer estas fechas. El input lleva sus propios hechos; no hay nada que ir a buscar.

La vara de retrieval quality

Un sistema groundeado que sale a producción está chunkeado para ser encontrable, embebido de forma consistente, mantenido fresco, medido sobre el retrieval y no solo la respuesta, presupuestado en contexto, permission-aware y trazable — o es una demo que recuperó el único documento que testeaste (principio 1). Antes de que el retrieval alimente una respuesta a un cliente o un registro, confirmá cada casilla. Cada una cierra un gotcha que convirtió una demo que funcionaba en un sistema que desinforma con seguridad.

  • [ ] Chunkeado para ser encontrable. Cada chunk leva suficiente contexto para sostenerse solo, y los límites caen en costuras naturales — secciones, párrafos, filas completas — no un conteo fijo de caracteres que corta a través del significado. (Principio 2 · gotcha 1.)
  • [ ] Embebido de forma consistente. Cada vector del índice — documentos y queries por igual — lo produce el mismo embedding model y versión, y ese modelo encaja con el vocabulario de este dominio. (Principio 2 · gotcha 2.)
  • [ ] Índice fresco. Un disparador de re-index salta cuando una fuente cambia, y fijaste un presupuesto de staleness por fuente que de verdad podés tolerar — un índice vectorial es un caché, mal en el momento en que la fuente se mueve. (Principio 2 · gotcha 3.)
  • [ ] Retrieval medido por su cuenta. Un retrieval eval set de pares reales query → chunk correcto puntúa recall y posición por separado de la calidad de la respuesta, y corre antes de que se ajuste el prompt. (Principio 3 · gotcha 5.)
  • [ ] k ajustado al más chico que pasa el recall. Recuperás al número más chico de chunks que de forma confiable contiene la respuesta en el eval set, no al más grande que podés pagar — sin over-retrieval "por las dudas". (Principio 10 · gotcha 6.)
  • [ ] Filtrado por permisos en el retrieval. Un chunk que el usuario que pregunta no puede ver se filtra antes del ranking, sobre metadata indexada para exactamente esto — no recuperado y suprimido con suerte en la UI. (Principio 5 · gotcha 8.)
  • [ ] Un camino de "no sé". Cuando el retrieval vuelve vacío o de baja relevancia, abstenerse — "no está en la base de conocimiento", derivar a un humano, preguntar — es un resultado de primera clase y testeado, no un accidente. (Principio 8 · gotchas 4, 7.)
  • [ ] Citas trazables al chunk usado. Cada afirmación groundeada leva una cita de vuelta al chunk del que de verdad salió, y verificaste que las citas son reales — el chunk citado de verdad sostiene la afirmación. (Principio 11 · gotcha 10.)

Si alguna casilla queda sin marcar, la respuesta groundeada no está lista — y una respuesta equivocada con seguridad es la peor salida que un sistema groundeado puede producir, porque se ve exactamente como una correcta hasta que alguien chequea la fuente. Mirá debuggear grounding para ver cómo el eval set convierte una respuesta equivocada en un diagnóstico en vez de una adivinanza.

Componer el toolkit

El toolkit es un conjunto de instrumentos complementarios, no bandos rivales entre los que elegís. Un sistema real los compone; la habilidad es ajustar cada uno a dónde viven los datos y quién los gobierna, no jurarle lealtad a uno (principio 7).

  • Retrievers de Agentforce sobre Data 360 cuando los datos viven en Salesforce. El retrieval corre dentro del modelo de seguridad, permission-aware por construcción — las sharing rules y la seguridad a nivel de campo del usuario en corrida aplican en el retrieval, no solo en la UI — así que el gotcha 8 lo cierra la plataforma en vez de código que escribís vos. La precondición es un modelo limpio y gobernado: el chequeo de agent-readiness de Data 360. Mirá retrievers de Agentforce.
  • RAG externo cuando el corpus es off-platform — LangChain para cablear el pipeline, un vector store para guardar los embeddings, un proveedor de embeddings para los vectores, y la Claude API para la generación. El mismo pipeline, gobernado por vos: el filtro de permisos del gotcha 8 es tuyo para construir, y no es opcional. Mirá RAG externo.

Una forma común es retrievers de Agentforce groundeando la respuesta en plataforma mientras un pipeline externo groundea un corpus que la plataforma no alcanza — compuestos por dónde viven los datos, nunca retrievers de Agentforce vs. RAG externo. La única decisión que esta página no es dueña es la decisión de superficie Agentforce vs. IA externa dentro de Marketing Cloud — eso es otro framework, y vive completo en el Style Guide de IA de Marketing Cloud.

Patrones a preferir

  • Medir el retrieval antes de ajustar el prompt — cuando una respuesta está mal pero fluida, puntuá recall y posición primero; un prompt ajustado contra retrieval roto solo memoriza la rotura. (Principio 3 · gotcha 5.)
  • Hybrid search donde importan los términos exactos — semántica más keyword (BM25), mergeados, para que códigos, IDs, nombres y jerga matcheen literalmente en vez de caerse en silencio. (Principio 2 · gotchas 1–2.)
  • El k más chico que pasa el recall — el número más chico de chunks que de forma confiable contiene la respuesta, ajustado contra el eval set, nunca rellenando el contexto "por las dudas". (Principio 10 · gotcha 6.)
  • Un filtro de permisos en el retrieval — el control de acceso aplica en el retrieval, no en la UI; en Agentforce el modelo de seguridad lo hace por vos, off-platform lo construís vos. (Principio 5 · gotcha 8.)
  • Un camino de "no sé" cableado y testeado, para que una pregunta fuera de alcance se vuelva una abstención en vez de una alucinación. (Principio 8 · gotchas 4, 7.)
  • Citas trazables de vuelta al chunk de verdad usado, verificadas reales, para que una respuesta groundeada se pueda auditar y replayear. (Principio 11 · gotcha 10.)
  • El chequeo de agent-readiness de Data 360 pasando antes de groundear en la ruta de plataforma — un modelo limpio es donde arranca un retrieval seguro.

Patrones a rechazar

  • Editar el prompt antes de chequear qué devolvió el retrieval — la respuesta son dos sistemas compuestos; reescribí el prompt sobre los chunks equivocados y no arreglás nada mientras el bug real espera. (Gotcha 5 · principio 3.)
  • Over-retrieval "por las dudas" — top-cincuenta en vez de top-cinco inunda la ventana de distractores, y pasado un punto degrada la respuesta; el contexto es un presupuesto, no un balde. (Gotcha 6 · principio 10.)
  • Un embedding model para los documentos y otro para las queries — vectores en dos espacios distintos, una distancia que es ruido; lo mismo vale para cambiar el modelo sin re-embeber el corpus. (Gotcha 2 · principio 2.)
  • Un índice sin ruta de refresco — una foto envejeciendo en silencio hacia la ficción, correcta contra sí misma y equivocada contra la realidad, el miss más difícil de atrapar. (Gotcha 3 · principio 2.)
  • Groundear sobre un modelo de Data 360 fragmentado — equivocado con seguridad es peor que "no sé", porque alguien actúa sobre ello; un modelo limpio es la precondición, no un lujo. (Gotcha 8 · principio 2.)

Cierre

Ninguna de estas reglas es difícil de aplicar de entrada; todas son caras de descubrir en vivo, porque un bug de grounding se ve exactamente como una respuesta correcta hasta que alguien chequea la fuente. El hilo conductor es el que recorre cada página de esta subcategoría: la demo recupera el único documento correcto y el modelo lo lee, mientras producción tiene que surfacear el chunk correcto desde todo lo que tenés y groundear un modelo limpio sobre ello. La vara de arriba es cómo nos aseguramos de que la respuesta que sacamos se pare sobre el chunk que dice.

Si ves que falta una regla — o que una de estas reglas se viola en nuestro trabajo público — escribí a hello@wearecleon.com. La agregamos, o lo arreglamos y lo decimos.

Related

Reference: