Cómo implementar RAG y Google Search Grounding en Agentes IA con Google ADK
Un agente empresarial no debería depender exclusivamente del conocimiento paramétrico de un LLM. La arquitectura robusta combina recuperación sobre conocimiento privado, grounding sobre información pública y tiempo real, control de herramientas y políticas explícitas para decidir qué fuente puede utilizar el agente en cada consulta.
Lo que aprenderás
RAG y Google Search Grounding resuelven problemas distintos
Una de las decisiones arquitectónicas más importantes es no tratar cualquier mecanismo de recuperación como si fuera equivalente. Google Search Grounding permite conectar Gemini con contenido web público y actualizado. RAG, en cambio, permite recuperar contexto desde un corpus controlado por la organización.
Google documenta que Grounding with Google Search conecta Gemini con contenido web en tiempo real y puede proporcionar citas verificables. Para datos privados, la búsqueda pública no es suficiente: la arquitectura necesita una fuente de recuperación autorizada para el conocimiento empresarial.
| Patrón | Fuente | Actualización | Control | Latencia | Caso de uso |
|---|---|---|---|---|---|
| Knowledge del LLM | Pesos del modelo | Limitada al modelo | Bajo | Muy baja | Conocimiento general y razonamiento |
| Google Search Grounding | Web pública | Tiempo real | Medio | Variable | Noticias, documentación pública, actualidad |
| RAG empresarial | Documentos privados | Controlada por la empresa | Alto | Variable | Políticas, contratos, manuales, conocimiento interno |
| SQL / APIs de negocio | Sistemas transaccionales | Tiempo real | Muy alto | Variable | Pedidos, clientes, inventario, KPIs operativos |
Antipatrón crítico: “activar Search y ya tenemos RAG”
Error: asumir que Google Search Grounding puede recuperar documentos privados simplemente porque el agente utiliza Gemini. La búsqueda web no debe considerarse un sustituto de un índice empresarial con autorización y control de acceso.
El patrón correcto es separar los dominios de conocimiento. El router del agente debe determinar si la consulta requiere conocimiento general, información pública actualizada, documentación privada o datos operacionales. Cada dominio debe tener su propia herramienta y sus propias políticas de seguridad.
Esto también evita otro problema frecuente: enviar indiscriminadamente grandes cantidades de documentos recuperados al contexto del modelo. La recuperación debe minimizar el contexto inútil, priorizar relevancia y preservar metadatos de autorización y procedencia.
Arquitectura recomendada para un agente RAG híbrido
El patrón de producción recomendado es un agente que dispone de herramientas especializadas. El modelo decide qué herramienta utilizar siguiendo instrucciones y políticas, mientras que cada herramienta encapsula el mecanismo de acceso a su fuente.
Clasificar la intención
Determinar si la pregunta necesita conocimiento interno, información web actualizada, datos estructurados o una combinación de fuentes.
Recuperar contexto
Ejecutar la herramienta correspondiente. Para documentos privados, aplicar filtros de autorización, búsqueda semántica y ranking.
Generar con evidencia
Entregar al modelo únicamente el contexto relevante y exigir que diferencie evidencia, inferencia y ausencia de información.
Principio arquitectónico
Search no es RAG; RAG no es una base de datos operacional; y ninguno de los dos sustituye una política de autorización.
El agente debe actuar como orquestador, no como propietario de toda la lógica de acceso a datos. Esto facilita pruebas, observabilidad, evolución de índices y controles de seguridad.
Implementación práctica con Google ADK y Gemini
En Google ADK, las herramientas pueden encapsular funciones Python que el agente invoca cuando necesita información externa. El siguiente patrón mantiene separadas la recuperación empresarial y la búsqueda pública.
from google.adk.agents import Agent
from google.adk.models import Gemini
from google.genai import types
MODEL = "gemini-3.7-flash"
def search_private_knowledge(query: str) -> str:
"""
Busca información en el índice privado de la empresa.
En producción esta función debe:
1. Validar la identidad del usuario.
2. Aplicar ACL/RBAC/ABAC.
3. Recuperar únicamente documentos autorizados.
4. Devolver contenido y metadatos de procedencia.
5. Evitar enviar documentos completos cuando no sean necesarios.
"""
# Sustituir por Vertex AI Search, Vector Search,
# un motor vectorial corporativo o la capa RAG elegida.
return (
"RESULTADOS_PRIVADOS\n"
"Fuente: knowledge-base-corporate\n"
"Contenido relevante recuperado para la consulta."
)
root_agent = Agent(
name="enterprise_rag_agent",
model=Gemini(
model=MODEL,
retry_options=types.HttpRetryOptions(attempts=3),
),
instruction="""
Eres un agente empresarial orientado a respuestas verificables.
REGLAS:
1. Para documentación privada de la empresa utiliza
search_private_knowledge.
2. Para información pública y actualizada utiliza
Google Search Grounding cuando esté disponible.
3. Nunca inventes información que no esté respaldada por
el contexto recuperado o por conocimiento fiable del modelo.
4. Si una fuente privada y una fuente pública contradicen sus
datos, explícitalo y prioriza la fuente según la política
de autoridad definida por la aplicación.
5. No reveles documentos, metadatos o información privada que
el usuario no esté autorizado a consultar.
6. Cuando la evidencia sea insuficiente, dilo explícitamente.
""",
tools=[
search_private_knowledge,
],
)¿Dónde entra Google Search Grounding?
En la arquitectura moderna de Gemini, Google Search se habilita como herramienta de grounding.
Google documenta actualmente el uso de google_search para los modelos compatibles,
mientras que integraciones antiguas utilizaban google_search_retrieval.
El modelo puede analizar la petición, generar consultas de búsqueda, procesar los resultados y producir una respuesta fundamentada con anotaciones de citación. Esto resulta especialmente útil para información que cambia con frecuencia.
El verdadero objetivo: reducir alucinaciones, no prometer cero alucinaciones
RAG y grounding pueden reducir el riesgo de respuestas no fundamentadas, pero no convierten automáticamente al modelo en un sistema determinista. La arquitectura debe asumir que pueden existir errores en retrieval, ranking, interpretación y generación.
Retrieval quality
Si el documento correcto no aparece entre los candidatos recuperados, el modelo no puede utilizarlo. Evalúa recall@k, precision@k y relevancia contextual.
Grounded generation
Recuperar evidencia no garantiza que el LLM la utilice correctamente. Evalúa faithfulness, corrección de citas y contradicciones.
Operational controls
Añade timeouts, retries, límites de contexto, políticas de fallback, observabilidad y circuit breakers para evitar que una dependencia externa degrade todo el agente.
FinOps: el contexto también tiene un coste
Un error habitual en sistemas RAG consiste en optimizar únicamente el coste del vector store y olvidar el coste de inferencia. Recuperar veinte documentos de gran tamaño puede ser más caro y menos fiable que recuperar tres fragmentos altamente relevantes.
Una arquitectura madura debe medir al menos:
- Tokens de entrada por consulta.
- Número de llamadas a herramientas.
- Latencia de retrieval.
- Latencia total del agente.
- Porcentaje de consultas que necesitan búsqueda web.
- Recall y precisión del retrieval.
- Porcentaje de respuestas con evidencia insuficiente.
- Coste por respuesta satisfactoria.
La optimización correcta no consiste simplemente en utilizar el modelo más barato. Consiste en minimizar el coste total de producir una respuesta correcta.
Patrones de diseño y mejores prácticas
1. Tool isolation
Cada fuente debe estar encapsulada en una herramienta clara. Esto permite sustituir el backend de retrieval sin rediseñar el agente completo.
2. Source authority
Define qué fuente tiene autoridad para cada tipo de afirmación. Una política empresarial interna puede tener prioridad sobre una página pública genérica.
3. Defense in depth
La autorización debe ejecutarse en la herramienta y en el backend de datos. Nunca debe depender únicamente de una instrucción del prompt.
4. Evidence first
Diseña la respuesta para diferenciar hechos recuperados, inferencias y preguntas que no pueden responderse con la evidencia disponible.
5. Evaluation-driven
Mantén un dataset de preguntas reales, casos ambiguos, documentos conflictivos y consultas sin respuesta. Evalúa cambios antes de desplegarlos.
6. Observability
Registra traces de agente, llamadas a herramientas, latencias, errores, fuentes utilizadas y métricas de calidad sin almacenar datos sensibles innecesariamente.
Checklist de implementación empresarial
Define las fuentes de verdad
Clasifica cada dominio como conocimiento del modelo, web pública, documentación privada o sistema operacional.
Diseña el contrato de retrieval
Define qué recibe la herramienta, qué devuelve, qué metadatos proporciona y cómo se expresa la ausencia de resultados.
Implementa autorización antes de recuperar
Aplica identidad y permisos antes de retornar cualquier fragmento. Nunca utilices el LLM como mecanismo de control de acceso.
Añade Google Search Grounding
Utilízalo para preguntas que dependen de información pública actualizada, no como sustituto automático del conocimiento empresarial.
Define reglas de autoridad
Determina qué ocurre cuando dos fuentes presentan información contradictoria o tienen diferentes fechas de actualización.
Evalúa retrieval y generación por separado
No atribuyas una respuesta incorrecta automáticamente al LLM. Primero determina si la evidencia correcta fue recuperada.
Observa producción
Mide latencia, errores, coste, tool calls, calidad de recuperación y frecuencia de respuestas sin evidencia suficiente.
Itera con casos reales
Construye un conjunto de evaluación a partir de consultas reales y casos de fallo encontrados en producción.
Preguntas frecuentes
¿Google Search Grounding sustituye a un sistema RAG empresarial?
No. Google Search Grounding está orientado a recuperar información pública de la web en tiempo real. Los documentos privados necesitan una arquitectura de recuperación empresarial con controles de acceso, indexación y gobernanza.
¿Cómo ayuda RAG a evitar las alucinaciones de un LLM?
RAG proporciona contexto recuperado desde fuentes externas antes de generar la respuesta. Reduce la dependencia exclusiva del conocimiento paramétrico del modelo, pero no elimina por completo las alucinaciones. La calidad del retrieval y la generación debe evaluarse de forma independiente.
¿Se pueden combinar Google Search Grounding y herramientas propias?
Sí, en escenarios compatibles. Los modelos Gemini actuales permiten combinar herramientas integradas, como Google Search, con herramientas personalizadas. Esto permite construir agentes híbridos capaces de trabajar con información pública y lógica o datos privados.