RAG externo: el pipeline de grounding que controlás vos

Salís de la plataforma para grounding cuando el corpus no es donde Salesforce lo alcanza. El conocimiento vive en document stores, wikis, manuales de producto, o sistemas que ningún retriever de plataforma indexa; o el pipeline necesita una forma que controlás de punta a punta; o los datos cruzan fuentes más allá de un solo perfil de Data 360. Ahí es cuando un pipeline de RAG externo es el instrumento correcto (principio 7) — no porque sea más avanzado, sino porque calza con un corpus que el camino de la plataforma no alcanza. Este es el lado "más allá de Salesforce" del grounding, y se gana su lugar exactamente cuando los datos dejaron la plataforma.

La frase que define el camino externo: sos dueño del pipeline. Los retrievers de Agentforce te dan el índice de búsqueda, el retriever, el hybrid search y el grounding dentro del modelo de seguridad de Salesforce gratis — los apuntás a un perfil de Data 360, no a un pipeline que armás vos. Fuera de la plataforma, cada etapa la construís vos mismo. Eso es el costo y la libertad en la misma respiración, y esta página trata sobre todo de ser honestos sobre ambos. El pipeline en sí — de chunk a respuesta groundeada — es qué es grounding; esta página no lo vuelve a enseñar, trata sobre quién lo construye.

El stack: cuatro instrumentos, compuestos

Un pipeline de RAG externo suele ser cuatro piezas trabajando juntas, y Cleon las compone en vez de tratar a una sola como la respuesta entera:

• LangChain — orquestación. Cablea el pipeline entero: los loaders que traen los documentos fuente, los splitters que los chunkean, el retriever que busca en query time, y la chain que le pasa el contexto recuperado al modelo. La mecánica del pipeline — chunk, embed, store, retrieve, augment, generate — está cubierta en qué es grounding y chunking y embeddings; esta página no la vuelve a enseñar. Lo que importa acá es quién arma la chain: fuera de la plataforma, vos. No hay un retriever gestionado; la chain que construís es el pipeline.
• Un vector store que corrés vos — el índice. Fuera de la plataforma los embeddings viven en algún lado que vos operás: una base de datos vectorial dedicada, o una extensión vectorial sobre una base de datos que ya corrés. De cualquier forma es tuyo de levantar, indexar y mantener sano — el índice de búsqueda gestionado de la plataforma es exactamente lo que estás reemplazando. La elección correcta es una decisión de categoría, no un producto único, y depende de la escala, del filtrado que necesitás, y de lo que ya operás.
• Un proveedor de embeddings — emparejado con Claude. Recordá de chunking y embeddings que no hay un modelo de embeddings de Claude propio. Emparejás Claude — para el razonamiento y la generación — con un proveedor de embeddings dedicado para los vectores, dos componentes de dos proveedores. Esto es normal; los embeddings son su propia especialidad. El modelo que escribe la respuesta y el modelo que embebe los chunks no son el mismo.
• La Claude API — generación. Los chunks recuperados, la pregunta y las instrucciones van a la Claude API, que lee el prompt aumentado y escribe la respuesta groundeada. El acceso directo a la API es lo que te da control sobre cómo lo llamás y un camino de capacidad que la plataforma quizás no expone — la misma relación de llamada directa que el agente externo usa para su núcleo de razonamiento.

Ninguno de estos compite con el camino de la plataforma. Son los instrumentos a los que recurrís cuando el corpus está fuera de la plataforma; la habilidad es componerlos, no defenderlos contra los retrievers de Agentforce.

Lo que controlás vos fuera de la plataforma

Esto es el corazón de la diferencia. Dentro del modelo de seguridad de Salesforce, los retrievers de Agentforce te dan el índice, el retriever, el hybrid search y el grounding del modelo de seguridad por construcción — vos aportás un perfil de Data 360 limpio y apuntás el retriever ahí. Fuera de la plataforma, cada una de esas etapas es tuya de construir, tunear y mantener funcionando:

• El chunking y la elección del modelo de embeddings. Cómo cortás los documentos y qué modelo de embeddings corrés — las dos palancas de arriba de chunking y embeddings — son decisiones que tomás y con las que convivís. Equivocate y ningún tuning río abajo lo recupera.
• El vector store y su índice. Lo levantás, lo cargás, lo mantenés indexado y rápido a medida que el corpus crece. El índice de búsqueda gestionado hacía esto por vos; acá son operaciones que controlás.
• El tuning de retrieval. Hybrid search, re-ranking, la k que recuperás, el filtrado por metadata — todo el toolkit de retrieval quality es un set de palancas que tirás vos mismo contra tus propios números, no defaults que te entregan.
• El filtrado de permisos en el retrieval. Esta es la que una demo nunca muestra. La plataforma filtraba por las sharing rules del usuario que corre por construcción; fuera de la plataforma construís ese filtro, sobre metadata que indexaste para exactamente eso, aplicado antes de rankear. Salteátelo y el índice devuelve chunks que el usuario nunca podría abrir por la puerta de adelante — el gotcha 8 en gotchas de grounding, y no es opcional.
• Frescura y re-indexado. La fuente de verdad cambia; tu índice no cambia con ella a menos que vos lo hagas. El camino de refresco, el contrato de frescura, el re-embed incremental — todo tuyo de diseñar antes de salir, o el índice envejece en silencio hasta volverse ficción.
• El set de eval. La calidad de retrieval solo es confiable una vez que se mide (retrieval quality), y fuera de la plataforma el set de eval query → el chunk que debería volver es tuyo de construir y correr en cada cambio.

Esto es el principio 4 dicho en limpio — el modelo es la parte fácil; el pipeline es el trabajo. Llamar la Claude API sobre algo de texto recuperado es una tarde. Construir el chunking, el índice, el tuning de retrieval, el filtro de permisos, el contrato de frescura y el set de eval alrededor es el trimestre, y fuera de la plataforma toda esa factura es tuya.

Cuándo external es la decisión correcta

El camino externo es el instrumento correcto, no el avanzado, en un conjunto específico de casos:

• El corpus vive fuera de Salesforce — los documentos, la base de conocimiento, los manuales de verdad están en otro lado, y no hay razón para arrastrarlos a un perfil de Data 360 solo para hacer retrieval sobre ellos.
• Un pipeline o un vector store que la plataforma no ofrece — cuando necesitás una estrategia de chunking, una técnica de retrieval, o un vector store específico que Salesforce no provee, y el control directo del pipeline es lo que lo consigue.
• Multi-fuente más allá de Data 360 — cuando el grounding tiene que cruzar varias fuentes a la vez, más de lo que un solo perfil de plataforma es la unidad correcta para abarcar, y armás el corpus vos mismo.
• Portabilidad entre hosts — cuando querés que el pipeline y su índice se muevan entre entornos en vez de quedar soldados a una plataforma.

Si ninguna de esas es cierta y los datos ya están en Data 360 y el trabajo vive en el modelo de seguridad de Salesforce, el camino de la plataforma es muy probablemente el mejor instrumento. External no es la mejora — es la respuesta correcta a una pregunta distinta. Si el corpus son datos gobernados de clientes en un perfil de Data 360 limpio, construir un pipeline aparte para hacer retrieval sobre una copia de ellos suele ser un paso atrás, no adelante.

El costo de dejar la plataforma

Acá está la parte que una demo nunca muestra. Todo lo que los retrievers de Agentforce te daban gratis ahora es tuyo de construir y mantener funcionando:

• El índice de búsqueda. No hay un índice gestionado sobre un perfil de Data 360 — vos levantás el vector store, lo cargás, y lo mantenés indexado a medida que el corpus crece. Las operaciones que la plataforma absorbía ahora son tuyas.
• Hybrid search y re-ranking. No hay un retriever que ya mezcle búsqueda semántica y por keyword por vos. Las palancas de retrieval quality son tuyas de construir, cablear y tunear contra tu propio set de eval.
• El grounding del modelo de seguridad. No hay sharing rules, seguridad a nivel de campo, ni "corre como este usuario" horneado en el retrieval. Cualquier control de acceso que el corpus necesite, lo implementás y lo aplicás como un filtro de permisos en query time — y un pipeline que se lo saltea es el gotcha 8 esperando pasar.
• El contrato de frescura. No hay una plataforma manteniendo el índice al día con el registro. Vos diseñás cómo una edición llega al índice, cuánto es el lag, y qué fuentes cambian con suficiente frecuencia como para necesitar más que un rebuild nocturno.

Esto es el principio 4 de nuevo, desde el lado del grounding. El modelo es una tarde; el pipeline es el trimestre. Fuera de la plataforma el pipeline entero es tuyo de construir y operar — y el principio 6 vale todo el tiempo, porque la factura de embeddings y la latencia del re-indexado son líneas que diseñás, no sorpresas que descubrís cuando el corpus llega a un millón de documentos. Presupuestalo antes de dejar la plataforma, no después de que el primer incidente pregunte por qué el retrieval sacó un chunk que un usuario nunca tuvo permitido leer.

Composición, no competencia

La imagen honesta no es external o plataforma — seguido es ambas. Un sistema real groundea Agentforce sobre un perfil de Data 360 para los datos gobernados dentro de la plataforma donde el trabajo vive en el modelo de seguridad, y corre un pipeline de RAG externo para un corpus que vive en otro lado — un manual de producto, un document store, una base de conocimiento que ningún retriever de plataforma indexa — compuestos en una sola experiencia groundeada. Los retrievers de Agentforce son dueños de la parte que necesita el modelo de seguridad de la plataforma; el pipeline externo es dueño de la parte cuyo corpus está fuera de la plataforma. Ninguno está ganando; cada uno groundea los datos para los que es el instrumento correcto.

Esa es toda la postura de esta subcategoría dicha desde el lado fuera de la plataforma. El camino externo es el control y el alcance que conseguís cuando el corpus dejó la plataforma — y un pipeline que firmaste por construir y operar en el momento en que lo hiciste. Componelo con el camino de la plataforma (principio 7), respetá lo que ahora tenés que construir vos mismo (principio 4), y el pipeline fuera de la plataforma se vuelve un instrumento que controlás en vez de uno que desinforma en silencio.

Related

• Retrievers de Agentforce — el camino complementario de la plataforma, donde el índice, el retriever y el grounding del modelo de seguridad vienen horneados
• Qué es grounding — el pipeline chunk → embed → store → retrieve → augment → generate sobre el que esta página construye sin volver a enseñarlo
• Chunking y embeddings — las palancas de arriba que controlás vos fuera de la plataforma, y por qué emparejás Claude con un proveedor de embeddings
• Retrieval quality — el hybrid search, el re-ranking y el tuning de k que cableás vos mismo fuera de la plataforma
• Gotchas de grounding — las fallas de fuga de permisos, índice viejo y retrieval vacío que son tuyas cuando dejás la plataforma
• Agentes externos — la contraparte del agente fuera de la plataforma, el loop que controlás vos para el pipeline que controlás vos de esta página
• Style Guide de grounding — la vara que un pipeline externo pasa antes de salir
• Principios de AI Engineering — componé el toolkit (7), el sistema es el trabajo (4), el costo y la latencia son features (6)

Reference:

• LangChain — Retrieval-augmented generation (RAG): loaders, splitters, retrievers, and the chain ↗
• LangChain — Retrieval ↗
• Anthropic — Embeddings (Anthropic ships no first-party model; pair Claude with a provider) ↗