Construyendo un pipeline de RAG con Gemini

Los LLMs son excelentes con el lenguaje. Son pésimos para saber qué pasó la semana pasada, qué hay en tus documentos privados o qué hace realmente el producto de tu empresa. El conocimiento del modelo termina en su fecha de corte de entrenamiento (training cutoff), y fuera de ese límite, alucinará con total confianza. Pregúntale a un modelo base sobre las especificaciones de tu último producto o el proyecto reciente de un cliente y obtendrás algo que suena correcto pero no lo es.

Ese es el vacío que llena RAG. La Generación Aumentada por Recuperación (Retrieval-Augmented Generation) permite que el modelo busque información antes de responder. En este post, explicaré qué es RAG, por qué es importante y cómo la API File Search de Gemini elimina gran parte del dolor de cabeza de la infraestructura al construir uno — usando un ejemplo de procesamiento de currículums porque es un caso de uso limpio y común.

El problema de los LLMs puros

El conjunto de entrenamiento estático es el problema. El modelo aprendió de una instantánea de texto público y eso es todo lo que sabe. Para la mayoría del trabajo empresarial, eso no es suficiente:

Alucinaciones. Sin una base de referencia (grounding), el modelo producirá respuestas seguras pero erróneas. Inaceptable para cualquier operación real.
Información desactualizada. El modelo entrenado el año pasado no conoce los números de este trimestre, el lanzamiento de producto de esta semana o el cambio regulatorio que entró en vigor el mes pasado.
Sin conocimiento de dominio. Terminología interna, políticas, detalles de productos — el modelo nunca los ha visto.
Sin verificabilidad. Cuando el modelo responde, no puede señalar una fuente. Los usuarios no pueden verificar los hechos.

Si quieres desplegar un LLM sobre tus propios datos, necesitas una forma de cerrar esa brecha. RAG es la respuesta más sólida por la que optan la mayoría de los equipos.

Qué es RAG realmente

RAG es un framework de IA que empareja un LLM con una fuente de datos externa y actualizada. El paper original salió de Meta en 2020. El patrón es: permitir que el modelo "busque" información relevante de una base de conocimientos designada antes de generar una respuesta. Un examen a libro abierto, no a libro cerrado.

El flujo estándar de RAG:

Consulta del usuario. Alguien hace una pregunta.
Recuperación (Retrieval). El sistema consulta una base de conocimientos externa, típicamente indexada con vector embeddings, y extrae los documentos o fragmentos más relevantes. Búsqueda semántica en lugar de coincidencia de palabras clave, para que el recuperador entienda qué significa la consulta en lugar de solo qué tokens contiene.
Aumentación (Augmentation). Los fragmentos recuperados se añaden a la consulta original, construyendo un "prompt aumentado" con el contexto específico que el modelo nunca habría conocido por sí solo.
Generación (Generation). El modelo recibe el prompt aumentado y responde, fundamentado en el contexto proporcionado.

Ese flujo no es abstracto — este blog lo utiliza. A continuación se muestran ejecuciones grabadas de un pequeño agente de RAG que responde preguntas sobre latentSource llamando al endpoint de búsqueda del propio sitio como una herramienta, y luego fundamentando su respuesta en lo que realmente obtuvo. Presiona play:

Un bucle ReAct real: el agente llama a blog_search contra el endpoint /api/search en vivo, lee los artículos recuperados (expande el resultado de la herramienta), razona sobre ellos y finaliza con una respuesta que cita artículos reales por título y enlace. Si no hay artículo recuperado, no hay afirmación — ese es todo el punto de la recuperación aumentada.

Los beneficios, cuando se hace bien:

Menos alucinaciones. El modelo tiene fuentes reales en las cuales basarse. Estudios han medido que las respuestas fundamentadas en RAG son aproximadamente un 43% más precisas que sus equivalentes que solo usan fine-tuning.
Respuestas actualizadas. El recuperador extrae información de una fuente viva. No es necesario reentrenar cuando los datos cambian.
Cobertura de dominio. Carga tus datos propietarios y el modelo podrá responder sobre ellos.
Verificabilidad. Cita los documentos fuente en la respuesta y los usuarios podrán verificar el trabajo.
Más barato que el fine-tuning. Especialmente cuando los datos subyacentes cambian a menudo.
Más control. Tú eres el dueño del recuperador y decides en qué se le permite al modelo fundamentarse.

Gemini File Search API

Construir RAG desde cero significa ejecutar un pipeline de ingesta, fragmentar (chunking) documentos, generar embeddings, alojar una base de datos vectorial y vincular todo a tu modelo. Son muchas piezas. La API File Search de Gemini es la versión gestionada de Google: RAG integrado en la API de Gemini, con la mayor parte de la infraestructura abstraída.

Lo que maneja por ti:

Almacenamiento. Los archivos entran. La API los almacena.
Fragmentación (Chunking). Divide los documentos en piezas digeribles con valores predeterminados razonables.
Embedding. Los modelos de embedding de Gemini convierten cada fragmento en un vector.
Búsqueda vectorial. Los embeddings residen en una base de datos vectorial gestionada. Sin despliegue, sin escalado.
Cobertura de formatos. PDF, DOCX, TXT, JSON y los tipos de archivos de código más comunes.
Citas. Las respuestas pueden incluir citas que remiten a los fragmentos de origen.
Precios. El almacenamiento y el embedding en tiempo de consulta son gratuitos. Pagas por la indexación inicial — aproximadamente $0.15 por millón de tokens al momento de escribir esto.

La API se conecta al endpoint generateContent existente, por lo que adoptarla no implica cambiar mucho tu código de generación.

Ejemplo práctico: procesando currículums

Los currículums (resumes) son el caso clásico. No estructurados, propietarios, con formatos variados. Extraer habilidades, experiencia y fechas manualmente es lento y propenso a errores.

Paso 1 — Ingesta. Sube los currículums a un File Search Store. La API procesa, fragmenta, genera embeddings e indexa.

import google.generativeai as genai
import time

# Initialize the client (ensure you have configured your API key)
# genai.configure(api_key="YOUR_API_KEY")

client = genai.Client()

# Create a File Search store
# This store will hold the embeddings of your resume documents
file_search_store = client.file_search_stores.create(
    config={'display_name': 'Resume_Data_Store'}
)
print(f"File Search Store created: {file_search_store.name}")

# Example: Uploading a resume file (replace 'resume.pdf' with your actual file)
# In a real scenario, you'd loop through multiple resume files
file_path = 'path/to/your/resume.pdf' # Placeholder
operation = client.file_search_stores.upload_to_file_search_store(
    file=file_path,
    file_search_store_name=file_search_store.name,
    config={
        'display_name': 'John_Doe_Resume',
    }
)

print(f"Uploading file '{file_path}' to store...")
while not operation.done:
    time.sleep(5) # Wait for the upload and indexing to complete
    operation = client.operations.get(operation)

print(f"File uploaded and indexed. Operation status: {operation.status}")

Paso 2 — Búsqueda semántica y extracción. Una vez que los currículums están indexados, un reclutador (o un sistema automatizado) puede preguntar cosas como "Encuentra candidatos con experiencia en Python y Machine Learning que se hayan graduado después de 2020" o "Resume la experiencia laboral de John Doe". Gemini, con la herramienta File Search habilitada, ejecuta una búsqueda semántica en el almacén, extrae los fragmentos relevantes y responde fundamentándose en ellos.

# After files are uploaded and indexed, you can query
prompt = "Summarize the key skills and last two work experiences of candidates in the Resume_Data_Store."

response = client.models.generate_content(
    model="gemini-1.5-flash-latest", # Or another appropriate Gemini model
    contents=prompt,
    config=genai.types.GenerateContentConfig(
        tools=[
            genai.types.Tool(
                file_search=genai.types.FileSearch(
                    file_search_store_names=[file_search_store.name]
                )
            )
        ]
    )
)

print("\nGenerated Response:")
print(response.text)

# For better grounding, the response often includes citations
if response.candidates and response.candidates[0].grounding_metadata:
    print("\nCitations:")
    for citation in response.candidates[0].grounding_metadata.citations:
        print(f"- {citation.uri} (start_index: {citation.start_index}, end_index: {citation.end_index})")

# In a real application, you would parse the response to extract structured data.
# For example, you might instruct the LLM to output skills as a list or JSON.

Paso 3 — Integración de la aplicación. A partir de ahí, tomas lo que la API devolvió y lo alimentas al sistema que lo necesite: una base de datos de candidatos, una interfaz de reclutador o un chatbot interno. La extracción de texto difícil ya está hecha. El problema de obtener estructura a partir de información no estructurada está mayormente resuelto.

El resultado es una representación buscable y filtrable de lo que antes era una pila de PDFs imposibles de procesar. Más rápido de clasificar, más preciso que la extracción manual, y el índice sigue funcionando a medida que llegan nuevos currículums.

Conclusión

RAG libera a los LLMs del conjunto de entrenamiento estático. Combina la recuperación con la generación y el modelo podrá fundamentar sus respuestas en información real, actual y propietaria — que es la diferencia entre un demo y algo que realmente funciona para una empresa.

Herramientas como la API File Search de Gemini eliminan la mayor parte del trabajo de infraestructura. Te saltas el tener que gestionar tu propia base de datos vectorial, escribir la lógica de fragmentación (chunking) y mantener el pipeline de embeddings. En lo que puedes enfocarte es en la lógica de la aplicación: qué preguntar, cómo usar la respuesta y cómo citar la fuente. Para las organizaciones que tienen datos internos y quieren ponerlos frente a un LLM, este es el camino más directo que he encontrado. Vale la pena probarlo con tus propios datos antes de construir algo desde cero.