Retrievers de Agentforce: grounding dentro de la plataforma Salesforce | Cleon

Echá mano de los retrievers de Agentforce cuando los datos sobre los que necesitás groundear ya viven en Data 360 y el trabajo corre dentro del modelo de seguridad de Salesforce. Este es el build nativo de la plataforma del pipeline de RAG que recorre qué es grounding — ingestar, chunkear, embeber, almacenar, recuperar, aumentar, generar — salvo que la plataforma corre las etapas y vos cableás la última. La razón para elegirlo no es lealtad a una plataforma sino encaje: cuando los hechos están en el perfil unificado y la respuesta tiene que honrar los permisos del usuario, los retrievers de Agentforce groundean el prompt dentro del modelo de seguridad que ya operás, en vez de pedirte que armes a mano el retrieval y un filtro de acceso desde cero.

Esta página es cómo se arma ese grounding, parte por parte, y — igual de importante — qué es tuyo y qué es de la plataforma. Vos construís y refinás el retriever y elegís el search index del que toma; la plataforma corre el embedding, el almacenamiento, la búsqueda y el chequeo de permisos. Es un instrumento componible, no el kit entero: un sistema real muchas veces groundea un agente de Agentforce sobre Data 360 y groundea un agente externo sobre su propio vector store fuera de la plataforma, y se pasan la posta. El vocabulario de acá — chunk, embedding, vector store, hybrid search, top-k — es el vocabulario de qué es grounding; esta página lo asume y muestra dónde cae cada pieza en la plataforma.

El retriever: el puente del search index al prompt

Un retriever es un wrapper de una operación de Einstein Search, creado y refinado en Einstein Studio. Su trabajo es ser el puente entre un search index y los lugares donde se arma un prompt — tus Prompt Templates y Flow. Cuando un agente de Agentforce groundea una respuesta, un retriever es lo que entra al índice, saca los chunks que matchean y se los pasa al prompt. Es el nombre que le da la plataforma a la etapa de retrieval del pipeline, empaquetada para que la configures en vez de codearla.

Llegás ahí de dos formas. Data 360 auto-crea un retriever por cada search index, así que apenas existe un índice ya hay un retriever funcionando sobre él — el camino rápido a groundear sobre una fuente. O construís un retriever custom en Einstein Studio cuando necesitás más control sobre cómo se comporta el retrieval: los filtros que aplica, cómo se rankean los resultados, el nivel de detalle que devuelve. El retriever auto-creado es el default sensato; el custom es la palanca que tirás cuando el ranking o el alcance del default no es lo que el grounding necesita.

Un hecho estructural le da forma a todo diseño acá: un retriever toma de un search index, y un search index indexa un DMO. Un retriever está, por lo tanto, acotado a una sola fuente. Cuando una respuesta tiene que groundear sobre más de una — un DMO de perfil y un DMO de conocimiento, digamos — componés un ensemble retriever que toma de varios retrievers a la vez, en vez de estirar un retriever más allá del único índice para el que está construido.

Tipos de search index: vector y hybrid

Un retriever es tan bueno como el índice que tiene debajo, y Data 360 soporta dos tipos de search index: vector search y hybrid search. Vector search es retrieval semántico — el matcheo basado en embeddings de qué es grounding, donde la query y los chunks se embeben y vuelven los vectores más cercanos. Captura significado y paráfrasis, y es el índice correcto cuando el corpus es prosa y las queries están redactadas en lenguaje natural.

Hybrid search combina retrieval por keyword y por vector y fusiona los dos sets de resultados con un fusion ranker. Esta es la misma idea de hybrid search que tu hermana retrieval quality plantea como una palanca que de otro modo construirías — semántico para el significado, keyword para los strings exactos que el search semántico deja caer en silencio (códigos, IDs, nombres, términos raros) — acá provista como un tipo de índice gestionado que seleccionás, en vez de un merge de dos caminos que cableás y tuneás vos. Cuando el corpus tiene términos exactos que tienen que matchear literal, hybrid suele ser el índice a elegir, por la misma razón por la que suele ser el default correcto fuera de la plataforma.

Retrievers no-code y retrievers custom

Las dos formas de construir un retriever mapean a dos audiencias. Los retrievers no-code dejan que un admin traiga datos no estructurados — PDFs, knowledge articles, transcripciones de llamadas — a Prompt Templates y Flow para que Agentforce groundee sobre ellos, configurados con filtros y sin escribir código de query vectorial. Este es el camino que pone el grounding al alcance de la gente que es dueña del contenido, no solo de la que escribe queries: apuntá el retriever a la fuente no estructurada, seteá los filtros, y el agente puede responder sobre ella.

Los retrievers custom, construidos en Einstein Studio, son el mismo puente con más control — filtros más finos, ranking y nivel de detalle, para los casos donde los defaults no-code no surfacean lo que el grounding necesita. La línea entre ambos es la conocida: el camino no-code es lo más angosto que hace el trabajo para la mayoría del contenido, y el camino custom es a donde vas cuando la calidad del retrieval sobre una fuente puntual necesita una mano en los diales. Echá mano del retriever no-code primero y del custom cuando el set de eval dice que el default se está perdiendo chunks que debería estar encontrando.

Grounding dentro del modelo de seguridad

Acá está la parte que le gana a la plataforma su lugar. El grounding a través de un retriever de Agentforce corre dentro del modelo de seguridad de Salesforce — el retrieval honra los permisos del usuario que corre por construcción. Un chunk que el usuario que pregunta no podría abrir por la puerta de entrada es un chunk que el retriever no le va a devolver, porque el retrieval pasa como ese usuario, bajo sus sharing rules, no como un lector sin límites del índice entero.

Esta es la respuesta de la plataforma a la falla de fuga de permisos que el lado del grounding tiene que resolver en todos lados — gotcha 8 en grounding gotchas, y el principio 5: todo camino de retrieval es un radio de explosión, y un índice aplanado que ignora quién pregunta convierte al search semántico en un confused deputy que lee material restringido en voz alta. Un pipeline externo tiene que construir ese filtro de permisos solo — etiquetar cada chunk con su metadata de acceso en la ingesta y filtrar por el usuario que pregunta en query time, antes de rankear — y equivocarse es un incidente de exposición de datos con cara de respuesta servicial. Del lado de Agentforce, el filtro no es algo que te acordás de agregar; es donde corre el retrieval.

El punto de composición: retrievers de Agentforce acá, un pipeline externo allá

Los retrievers de Agentforce son un instrumento, y el encuadre honesto es composición, no elección (principio 7). El camino nativo de la plataforma es el correcto cuando los datos viven en Data 360 y el trabajo corre en el modelo de seguridad de Salesforce — el grounding, el embedding, el almacenamiento y el filtro de permisos están todos resueltos donde los datos ya están. Un pipeline de RAG externo es el correcto cuando el corpus está fuera de la plataforma, los datos no pertenecen a Data 360, o el retrieval necesita un control de flujo que los tipos de índice gestionados no te dan — mirá external RAG para ese lado. Un sistema real muchas veces groundea sobre ambos: un retriever de Agentforce sobre el perfil unificado para los hechos gobernados en plataforma, un pipeline externo sobre un document store para el resto, compuestos detrás de un agente.

Un modelo de Data 360 limpio es la precondición del lado de la plataforma, exactamente como un corpus limpio lo es afuera. Un retriever groundea sobre un DMO, y un modelo fragmentado, viejo o mal resuelto está confiadamente equivocado por más bueno que sea el retrieval sobre él — el principio 2 cae acá tanto como en cualquier lado. Corré el chequeo de agent-readiness de Data 360 antes de que el agente groundee sobre datos de marketing o de service, no después de que salga la primera respuesta equivocada. El retriever es el puente; aquello a lo que conecta tiene que valer la pena groundearlo.

El hilo

Un retriever de Agentforce es un wrapper de una operación de Einstein Search que hace de puente entre un search index y tus Prompt Templates y Flow: auto-creado por índice o construido custom en Einstein Studio, tomando de un search index vector o hybrid, configurado no-code por un admin o con control más fino en código, y compuesto en un ensemble retriever cuando la respuesta cruza más de un DMO. Vos sos dueño del retriever y de la calidad del índice; la plataforma es dueña del embedding, el almacenamiento, la búsqueda y — la parte que más importa — el filtro de permisos, porque el retrieval corre dentro del modelo de seguridad de Salesforce por construcción. Esa división es todo el atractivo, y todo su límite: cuando los datos viven en Data 360 y el trabajo está gobernado, es el camino más directo a respuestas groundeadas y conscientes de permisos; cuando el corpus está fuera de la plataforma, esa es la señal para componer un pipeline externo y pasar la posta. La habilidad es saber dónde viven los datos, no defender el instrumento. (Mirá grounding gotchas para los modos de falla que un build nativo igual hereda, y el Style Guide de grounding para la vara que un sistema groundeado pasa antes de salir.)

What is grounding — el pipeline de RAG que esta página arma en términos de Agentforce
Chunking and embeddings — la calidad de índice de arriba que el retriever no puede arreglar
Retrieval quality — la vara que un retriever pasa, medida de la misma forma en plataforma
Grounding gotchas — los modos de falla que un build nativo igual tiene, siendo gotcha 8 el límite de permisos que esta página responde
External RAG — el pipeline fuera de plataforma con el que los retrievers de Agentforce componen
Debugging grounding — trazar una respuesta groundeada cuando vuelve el chunk equivocado
Grounding Style Guide — la vara que un sistema groundeado pasa antes de salir
Agentforce agents — el agente que llama al retriever para groundear su respuesta
Data 360 agent-readiness check — el modelo limpio sobre el que un retriever groundea, chequeado antes de salir
AI Engineering principles — groundeá antes de generar (2), toda tool es un radio de explosión (5), componé el toolkit (7)

Reference: