Vertex AI para RAG: las piezas que merece la pena usar y las que conviene construir

Google Cloud tiene más bloques de construcción para RAG que ningún otro proveedor, y ese es su principal problema. Vertex AI Search, Vertex AI Vector Search, la API de anclaje, Agent Builder y el RAG Engine se solapan lo bastante como para que la primera decisión de arquitectura sea cuál de ellos estás usando en realidad.

Así elegimos, según lo que sobrevive al contacto con usuarios reales.

Vertex AI Search cuando el corpus son documentos y la respuesta es un resultado de búsqueda

Si tu caso es "busca en nuestra documentación y responde con citas", Vertex AI Search (el producto de búsqueda y conversación) hace el pipeline entero: rastreo o ingesta, troceado, embeddings, recuperación, reordenación y generación con citas. Incluye un reordenador, que es un componente que los equipos se saltan y luego redescubren cuando la precisión decepciona.

Esta es de verdad la respuesta correcta para bases de conocimiento internas, portales de soporte y documentación de producto. Tómala. El trabajo que te quedas es el conjunto de evaluación y el modelo de permisos.

Móntalo tú cuando la recuperación no sea búsqueda documental

En el momento en que la respuesta necesita combinar un documento con una fila de una base de datos, o la recuperación depende de los permisos del usuario de forma no trivial, o necesitas un paso que filtre por metadatos estructurados antes de la búsqueda vectorial, quieres las piezas:

• Vector Search (antes Matching Engine) para el índice. Es rápido y escala bien, pero ojo: el endpoint de índice desplegado tiene un coste fijo real por hora — para corpus pequeños, AlloyDB o Cloud SQL con pgvector es más barato y más simple, y te deja unir vectores con tus datos relacionales en una sola consulta, que suele ser justo el motivo por el que lo montabas a mano.
• Los modelos de embedding y de generación en Vertex, para que cambiar de versión sea un parámetro.
• Tu propia orquestación en Cloud Run, porque esto es código de aplicación normal y se beneficia de ser testeable.

Las dos piezas gestionadas que merece la pena tomar igualmente

El anclaje con Google Search o con tus propios datos, expuesto como ajuste en la generación, devuelve puntuaciones de respaldo por afirmación. Usa la puntuación como puerta: por debajo de un umbral, el asistente dice que no lo sabe en vez de adivinar. Ese único comportamiento hace más por la confianza del usuario que cualquier cantidad de ingeniería de prompts.

El servicio de evaluación de Gen AI ejecuta métricas evaluadas por modelo sobre un conjunto de datos. Sigues teniendo que escribir el conjunto —de cincuenta a doscientas preguntas reales con sus fuentes esperadas— pero no tienes que construir el arnés. Conéctalo a CI para que un cambio de prompt ejecute la evaluación antes del merge, igual que los tests.

Permisos, que es donde mueren estos proyectos

Un índice vectorial no tiene ningún concepto de tu organigrama. Funcionan dos patrones:

Filtrado por metadatos en consulta. Cada fragmento lleva la ACL de su documento de origen como namespace o campo de restricción, y la consulta pasa los grupos del usuario. Rápido, y aguanta mientras tu pipeline de ingesta mantenga las ACL al día — lo que significa resincronizar cuando cambian los permisos, no solo cuando cambia el contenido.

Un índice por inquilino. Más caro y mucho más fácil de demostrar correcto. Para unos pocos inquilinos grandes con requisitos estrictos de aislamiento es la respuesta correcta, y el coste vale la conversación de auditoría que ahorra.

Lo que no funciona es filtrar después de recuperar en la aplicación, porque para entonces el modelo ya ha visto los fragmentos. Es el fallo que más nos llaman a arreglar, y el arreglo es reingerir.

Coste, y el número que hay que seguir

Tres líneas: tokens de generación, tokens de embedding (sobre todo puntuales en la ingesta, más el reembedding cuando cambias de modelo) y el índice o la base de datos. Añade Cloud Run, que en comparación suele ser ruido.

Sigue el coste por pregunta desde la primera semana, etiquetado por equipo y con la facturación exportada a BigQuery. Agrupa los embeddings en lotes en vez de llamar por documento, cachea los embeddings de fragmentos que no han cambiado entre ingestas y usa un modelo pequeño y rápido para reescribir consultas y clasificar. Esos tres hábitos suelen partir la factura por la mitad sin tocar la calidad de las respuestas.

La versión general de estas decisiones está en las cuatro decisiones que deciden un proyecto de RAG; el orden de aquí es específico de lo que Vertex te da gratis.

Qué hacer esta semana

Escribe el conjunto de evaluación: cincuenta preguntas reales de usuarios reales, cada una con el documento que debería responderla. Después ejecuta tu sistema actual contra él y anota la puntuación. Todo lo que venga después es medible, y casi nada de lo anterior lo era.