Gemini File Search permite montar un RAG en Go sin base de datos vectorial

Google incluye en su API de Gemini una herramienta llamada File Search que asume la parte pesada de un RAG: parte los documentos en fragmentos, genera los embeddings y resuelve la recuperacion en su propia infraestructura. Con eso, quien monta el sistema se ahorra levantar y mantener una base de datos vectorial para consultar un corpus de documentos sin estructurar. Un articulo tecnico firmado por un desarrollador explica como encajar esa pieza desde Go.

No es un anuncio de Google ni una version nueva de nada. Es una guia de arquitectura, y conviene leerla con esa vara de medir. Lo que describe, eso si, es un cambio de reparto de trabajo: en lugar de que el cliente calcule embeddings y consulte un indice por similitud de coseno, es el modelo el que interpreta la pregunta, la reformula si hace falta y busca dentro de los ficheros. El emparejamiento semantico deja de ser codigo tuyo.

Los formatos que admite son PDF, DOCX, TXT y HTML, y los ficheros tienen que estar en un directorio de Google Cloud Storage con permisos para la cuenta de servicio que usa la API. El autor lo plantea como alternativa a la pila clasica de canalizacion de ingesta, base vectorial dedicada y capa de orquestacion.

Que se gana y que no

Las ventajas que enumera son de operacion, no de rendimiento bruto. No hay cola de generacion de embeddings ni deriva del modelo de embeddings que vigilar. Tampoco hay arranque en frio esperando a que los vectores se carguen en memoria, ni campos de metadatos que mantener sincronizados entre la aplicacion y el motor de busqueda: el fichero es la fuente de verdad. Y desaparece el trabajo de indexado, que pasa a la infraestructura de Google en segundo plano.

Los limites tambien van en el texto. File Search esta pensado para corpus medianos o grandes de texto sin estructurar, no para sustituir a una base de datos relacional. Si tu RAG depende de uniones entre tablas o de filtrado numerico fino, una base vectorial o un motor SQL siguen siendo mejores. Es recuperacion de documentos, no consulta de datos.

La parte de Go

La arquitectura propuesta es convencional: Go 1.21 o superior, el paquete net/http de la biblioteca estandar, el cliente google.golang.org/genai y viper para la configuracion por variables de entorno. Tres capas, manejador, servicio y datos, con la logica de RAG en la del medio y las llamadas a Gemini y a Cloud Storage en la de abajo. Nada exotico.

El codigo que acompana al articulo, en cambio, hay que tomarlo como boceto. La funcion que construye la herramienta de busqueda devuelve una declaracion vacia y el propio autor avisa de que las definiciones cambian segun la version del SDK. El texto, ademas, se corta a media frase al final. No hay repositorio ni ejemplo que se pueda ejecutar tal cual.

Aun asi, la idea es la que importa: si el mecanismo funciona como se describe, buena parte de los RAG internos sobre contratos, manuales o normativa no necesitan el montaje de una base vectorial. Queda por ver que pasa con el precio, los cupos de uso y la latencia de indexado, que la guia no toca, y si hay filtrado por metadatos, algo que tampoco aparece.