Construí una App de IA Premium con Gemini Embeddings y RAG

El PDF tenía diagramas. No descripciones textuales de diagramas — diagramas de flujo reales, visualizaciones de arquitectura, capturas de pantalla anotadas. Cada modelo de embeddings que había probado antes los habría ignorado por completo, indexando solo el texto circundante y dejando la información visual en el olvido. Así que cuando subí ese mismo PDF a un índice de Pinecone usando el modelo Gemini Embedding 2 de Google y le hice una pregunta sobre un diagrama específico tres páginas más adentro, esperaba las alucinaciones habituales.

En cambio, extrajo el contexto exacto del diagrama. Referenció las flechas. Entendió el flujo.

Me recliné y me quedé mirando mi terminal durante unos buenos diez segundos. Ese fue el momento en que supe que este proyecto iba a ser diferente de cada app RAG que había lanzado antes. No era algo incrementalmente mejor. Fundamentalmente diferente — porque el modelo de embeddings finalmente entendía más que solo palabras.

Lo que siguió fue un proceso de cinco pasos para construir una aplicación de IA premium, responsive para móviles, con chat dinámico, recuperación de conocimiento habilitada con memoria e ingesta de contenido en múltiples formatos. El tipo de app que le podrías entregar a un cliente y cobrar dinero real. Voy a recorrer cada paso, incluyendo las partes donde las cosas se rompieron y las decisiones que tomaría de forma diferente la próxima vez.

Pero primero, necesitas entender por qué Gemini Embedding 2 cambia las reglas de lo que es posible con RAG — y por qué construir este tipo de app era genuinamente doloroso antes de marzo de 2026.

Por qué Gemini Embedding 2 reescribe las reglas del RAG

RAG — Retrieval Augmented Generation — ha sido el patrón de trabajo pesado para darle memoria a las apps de IA. El concepto es sencillo: en lugar de meter toda una base de conocimiento en un prompt (caro, lento y limitado por las ventanas de contexto), divides los documentos en fragmentos, conviertes esos fragmentos en vectores numéricos, los almacenas en una base de datos vectorial y recuperas solo las piezas relevantes cuando un usuario hace una pregunta. La IA obtiene exactamente el contexto que necesita sin procesar todo.

El problema siempre fue el paso de embedding. Antes de Gemini Embedding 2, los modelos de embeddings solo procesaban texto. text-embedding-3-large de OpenAI, los modelos de Cohere, incluso el propio text-embedding-004 de Google — todos procesaban palabras e ignoraban todo lo demás. Si tu base de conocimiento contenía imágenes, diagramas de arquitectura, tutoriales en video o grabaciones de audio, tenías dos opciones: transcribir todo manualmente a texto (perdiendo matices y contexto visual), o aceptar que tu sistema RAG era ciego a la mitad de tus datos.

Gemini Embedding 2 entró en vista previa pública el 10 de marzo de 2026, y eliminó esa disyuntiva por completo. Construido nativamente sobre la arquitectura Gemini, mapea texto, imágenes, video, audio y PDFs en un único espacio vectorial de 3,072 dimensiones. Un modelo. Un espacio de embeddings. Todo buscable en conjunto.

Los benchmarks lo respaldan. En MTEB English, obtiene 68.32 — ocupando el primer puesto con un margen de 5.09 puntos sobre el siguiente competidor. Pero los benchmarks no construyen apps. Lo que importa es lo que pasa cuando le das un manual de producto de 40 páginas con capturas de pantalla, lo conectas a Pinecone y haces la pregunta de un usuario. Ahí es donde empieza la prueba real.

Así se ve un pipeline RAG multimodal comparado con el enfoque antiguo de solo texto:

Esa fila de búsqueda cross-modal es la que lo cambia todo. Una consulta de texto como "muéstrame el flujo de autenticación" ahora puede recuperar un diagrama, una marca de tiempo de un video o un fragmento de código — lo que sea más relevante — desde un único índice unificado. Sin pipelines separados. Sin unir resultados de diferentes modelos de embeddings.

El stack tecnológico en el que aterricé para este proyecto cuenta la historia de cómo encajan estas piezas. Y el orden importa — cada elección de herramienta restringió la siguiente de formas que no aprecié completamente hasta que estaba metido de lleno en la implementación.

El framework de cinco pasos: de la pantalla en blanco al SaaS desplegado

Adapté un framework de Jack Roberts que divide el desarrollo de apps de IA en cinco fases distintas. No porque me encantan los frameworks — he visto demasiados que añaden proceso sin añadir valor — sino porque este se mapea limpiamente a las decisiones reales que enfrentarás. Cada paso produce un entregable que alimenta el siguiente.

Aquí está el stack antes de empezar a construir:

Ahora déjame recorrer cada paso como realmente sucedió — no la versión limpia, la real.

Paso 1: Fundación y arquitectura — Construyendo la UI con Lovable

Empecé con Lovable porque quería priorizar la calidad del diseño desde el principio. La mayoría de tutoriales de apps de IA producen apps que parecen hechas por un ingeniero de backend a las 2 de la mañana — funcionales pero visualmente dolorosas. Para un producto SaaS dirigido a clientes, la UI necesita sentirse premium desde la primera interacción.

Lovable genera aplicaciones full-stack a partir de prompts en lenguaje natural. Describes lo que quieres y produce componentes React con Tailwind CSS, conectados a un backend de Supabase. El tier gratuito te da 5 mensajes por día (30 mensuales máximo), que es ajustado pero funcional para un build inicial. El plan Starter a $25/mes por 100 créditos es donde aterriza la mayoría de los constructores serios.

Mi prompt inicial fue específico — no "constrúyeme una app de chat" sino una descripción detallada del layout del dashboard, incluyendo una pantalla de login con transiciones animadas, una interfaz de chat principal para consultar la base de conocimiento, y una sección de notas estilo Kanban para guardar y organizar insights. Especifiqué soporte para modo claro y oscuro, efectos de confetti en el primer login, y contrastes de color específicos para accesibilidad.

La primera generación me dio aproximadamente el 80% de lo que quería. La interfaz de chat estaba limpia. El tablero Kanban funcionaba. El flujo de login tenía transiciones suaves. Pero el espaciado estaba mal en móvil, el modo oscuro tenía problemas de contraste en dos componentes, y la animación de confetti se disparaba en cada carga de página en lugar de solo en el primer login.

Esto es lo que aprendí sobre hacer prompts efectivos en Lovable: trata cada refinamiento como una instrucción enfocada, no como una solicitud de rediseño. En lugar de "arregla el layout móvil", dije "reduce el padding del contenedor de mensajes del chat de 24px a 16px en pantallas por debajo de 640px, y apila las columnas del Kanban verticalmente en móvil con 12px de gap." Los prompts específicos producen correcciones específicas. Los prompts vagos producen problemas nuevos.

Después de cuatro rondas de iteración — cada una apuntando a un solo problema — tenía una UI que genuinamente le mostraría a un cliente. La exportación a GitHub fue un clic. En ese punto, la capa visual estaba lista y no había tocado un editor de código.

Pero una UI hermosa sin cerebro detrás es solo un mockup. El siguiente paso — conectar Gemini embeddings y Pinecone al backend — es donde este proyecto se pone interesante. Y donde las cosas empezaron a romperse.

Paso 2: Conectando embeddings y construyendo el cerebro de conocimiento

Este es el paso que separa una demo de un producto. Cloné el repositorio generado por Lovable desde GitHub en Anti-Gravity IDE, que es el entorno de desarrollo agent-first de Google construido sobre el trabajo del antiguo equipo de Windsurf. Anti-Gravity mantiene dieciséis agentes especializados — especialistas en frontend, arquitectos de backend, auditores de seguridad — pero el que importa aquí es Claude Code, que se ejecuta en la terminal integrada con acceso completo al sistema de archivos.

¿Por qué Claude Code dentro de Anti-Gravity en lugar de solo Claude Code independiente? Dos razones. Primero, el navegador integrado de Anti-Gravity te permite verificar visualmente los cambios en tiempo real sin cambiar de ventana. Segundo, el sistema de habilidades de agentes significa que Claude Code maneja la conexión del backend mientras el agente de frontend de Anti-Gravity detecta regresiones visuales. Se complementan en lugar de duplicar esfuerzo.

La primera tarea: conectar Pinecone como la base de datos vectorial. El tier serverless de Pinecone maneja las 3,072 dimensiones que produce Gemini Embedding 2, y su filtrado por metadatos te permite acotar consultas a tipos de documentos específicos o fechas de carga — fundamental para una base de conocimiento que crece con el tiempo.

Le pedí a Claude Code que configurara el cliente de Pinecone, creara un índice con las dimensiones correctas y métrica de similitud coseno, y lo conectara a una ruta API en la app de Next.js. El código que generó fue funcional en el primer intento. Aquí está el núcleo del flujo de embedding y upsert:

// lib/embeddings.ts
import { GoogleGenerativeAI } from "@google/generative-ai";
import { Pinecone } from "@pinecone-database/pinecone";

const genAI = new GoogleGenerativeAI(process.env.GEMINI_API_KEY!);
const pinecone = new Pinecone({ apiKey: process.env.PINECONE_API_KEY! });

// Gemini Embedding 2 model - supports text, images, video, audio, PDFs
const embeddingModel = genAI.getGenerativeModel({
  model: "gemini-embedding-exp-03-07"
});

export async function embedAndStore(
  content: string,
  metadata: Record<string, any>,
  namespace: string = "default"
) {
  const index = pinecone.index(process.env.PINECONE_INDEX!);

  // Generate embedding - 3,072 dimensions
  const result = await embeddingModel.embedContent(content);
  const embedding = result.embedding.values;

  // Upsert to Pinecone with metadata for filtering
  await index.namespace(namespace).upsert([{
    id: `doc_${Date.now()}_${Math.random().toString(36).slice(2)}`,
    values: embedding,
    metadata: {
      ...metadata,
      timestamp: new Date().toISOString(),
      contentPreview: content.slice(0, 200)
    }
  }]);
}

export async function queryKnowledge(
  query: string,
  topK: number = 5,
  filter?: Record<string, any>
) {
  const index = pinecone.index(process.env.PINECONE_INDEX!);

  const queryEmbedding = await embeddingModel.embedContent(query);

  const results = await index.namespace("default").query({
    vector: queryEmbedding.embedding.values,
    topK,
    includeMetadata: true,
    filter
  });

  return results.matches?.map(match => ({
    score: match.score,
    content: match.metadata?.contentPreview,
    source: match.metadata?.source,
    type: match.metadata?.contentType
  }));
}

La estrategia de fragmentación importa más de lo que la mayoría de tutoriales reconocen. Dividí los documentos en fragmentos de 512 tokens con 50 tokens de solapamiento. Muy pequeños y pierdes contexto. Muy grandes y desperdicias tokens en contenido irrelevante durante la recuperación. El solapamiento de 50 tokens asegura que no dividas accidentalmente una oración crítica entre dos fragmentos y pierdas su significado por completo.

Para PDFs específicamente, usé un enfoque de dos pasadas. Primera pasada: extraer contenido de texto por página. Segunda pasada: extraer imágenes y diagramas, hacer embedding por separado con metadatos del número de página, y almacenar tanto los fragmentos de texto como los visuales en el mismo namespace de Pinecone. Aquí es donde la capacidad multimodal de Gemini Embedding 2 rinde frutos — los fragmentos visuales viven en el mismo espacio vectorial que los fragmentos de texto, así que una sola consulta puede traer ambos.

La primera prueba real: subí un manual de producto de 40 páginas que incluía diagramas de arquitectura, capturas de pantalla de la UI y tablas de referencia de API. Luego le pregunté a la interfaz de chat, "¿Cómo funciona el flujo de autenticación?" El sistema recuperó tres fragmentos de texto describiendo el proceso OAuth y — aquí está la parte que me sorprendió — un fragmento de imagen que contenía el diagrama real del flujo de autenticación de la página 12. La recuperación multimodal funcionó en el primer intento.

No voy a pretender que todo fue sobre ruedas. El componente de scraping de YouTube tomó tres intentos para quedar bien. Mi primer enfoque usaba youtube-transcript-api para obtener transcripciones, pero fallaba silenciosamente en videos que solo tenían subtítulos autogenerados en idiomas no ingleses. El segundo intento añadió detección de idioma y lógica de fallback. El tercero añadió una verificación de deduplicación contra los metadatos de Pinecone para evitar volver a hacer embedding de videos que ya estaban en la base de conocimiento.

// lib/youtube-ingestion.ts
async function ingestYouTubeVideo(videoUrl: string) {
  const videoId = extractVideoId(videoUrl);

  // Check if already ingested
  const existing = await queryKnowledge("", 1, {
    videoId: { $eq: videoId }
  });

  if (existing && existing.length > 0) {
    console.log(`Video ${videoId} already in knowledge base, skipping.`);
    return;
  }

  const transcript = await fetchTranscript(videoId);
  const chunks = chunkText(transcript, 512, 50);

  for (const chunk of chunks) {
    await embedAndStore(chunk.text, {
      source: videoUrl,
      videoId,
      contentType: "youtube_transcript",
      chunkIndex: chunk.index
    });
  }
}

Esa verificación de deduplicación — consultar los metadatos de Pinecone antes de hacer embedding — me salvó de un problema que habría sido invisible al principio y catastrófico a escala: vectores duplicados diluyendo la calidad de búsqueda. Cada vez que el auto-actualizador se ejecuta, verifica qué ya existe antes de añadir algo nuevo. Lógica simple, fácil de olvidar, costosa de arreglar después del hecho.

En este punto, la app tenía una UI funcional, una base de conocimiento conectada con RAG multimodal, y la capacidad de ingerir PDFs y contenido de YouTube. Lo que no tenía era una forma de mantenerse actualizada sin que yo ejecutara scripts de ingesta manualmente. Eso es lo que resuelve el Paso 3 — y es el paso que la mayoría de tutoriales se saltan por completo.

Paso 3: El sistema de auto-actualización que mantiene fresca la base de conocimiento

Una base de conocimiento que deja de crecer el día que la lanzas es un pasivo, no una característica. Los usuarios esperan información actualizada. Si tu app RAG sigue devolviendo resultados de datos que subiste hace dos meses mientras el mundo ha avanzado, la confianza se erosiona rápido.

Usé Railway para la capa de automatización. Railway soporta tres tipos de cómputo: servicios persistentes, cron jobs y funciones serverless. La capacidad de cron jobs es lo que importa aquí — te permite ejecutar un script en un horario, pagar solo por el tiempo de ejecución y apagarse limpiamente entre ejecuciones.

La configuración: un servicio Node.js en Railway que se ejecuta diariamente a las 3 AM UTC. Verifica una lista configurada de canales de YouTube en busca de nuevos videos publicados desde la última ejecución, extrae transcripciones, las fragmenta y hace upsert a Pinecone. Todo el proceso toma aproximadamente 90 segundos para el contenido nuevo de un día típico, lo que cuesta fracciones de centavo en los precios por uso de Railway.

// workers/daily-ingestion.ts
import { CronJob } from "cron";

async function dailyIngestion() {
  const channels = process.env.YOUTUBE_CHANNELS!.split(",");
  let newVideos = 0;

  for (const channelId of channels) {
    const recentVideos = await fetchRecentVideos(channelId, {
      publishedAfter: getLastRunTimestamp()
    });

    for (const video of recentVideos) {
      await ingestYouTubeVideo(video.url);
      newVideos++;
    }
  }

  console.log(`Ingested ${newVideos} new videos.`);
  await updateLastRunTimestamp();

  // Railway cron jobs expect the process to exit cleanly
  process.exit(0);
}

dailyIngestion();

El plan Hobby de Railway incluye $5 de uso por mes. Para un cron job diario que se ejecuta durante 90 segundos, usarás aproximadamente $0.50-$1.00/mes en cómputo — bien dentro de la asignación incluida. El intervalo más corto que Railway soporta es 5 minutos entre ejecuciones, y los horarios se ejecutan en UTC, así que planifica tu timing en consecuencia.

Una decisión de diseño que haría diferente: inicialmente almacené la marca de tiempo de "última ejecución" en un archivo local en el servicio de Railway. Eso es frágil — si el servicio se redespliega, el archivo desaparece y la siguiente ejecución reprocesa todo. Moví la marca de tiempo a una tabla de Supabase, que persiste entre despliegues y me da un log consultable de cada ejecución de ingesta. Cambio pequeño, gran mejora en confiabilidad.

La automatización en segundo plano también abrió un flujo de trabajo que no había planeado. Como la base de conocimiento se actualiza sola, podía apuntar el pipeline de ingesta a canales de la competencia, fuentes de noticias de la industria o repositorios de documentación. El conocimiento de la app crecía mientras yo dormía. Para un cliente que entrega esto como producto SaaS, esa capacidad de auto-actualización es un diferenciador real — la experiencia de sus usuarios mejora diariamente sin intervención manual.

Si prefieres que alguien construya todo este pipeline de automatización desde cero, acepto proyectos de desarrollo de apps de IA y construcción de sistemas RAG. Puedes ver lo que he construido en fiverr.com/s/EgxYmWD.

Pero una app que funciona no es lo mismo que una app lista para usuarios. La brecha entre "funciona en mi máquina" y "funciona en cada dispositivo, cada navegador, cada tamaño de pantalla" es exactamente donde vive el Paso 4. Y es el paso que la mayoría de desarrolladores individuales se saltan — bajo su propio riesgo.

Paso 4: Control de calidad que realmente detecta problemas

Yo solía lanzar proyectos después de probarlos en Chrome en mi laptop y darlos por terminados. Ese enfoque falló tan estrepitosamente tantas veces que ahora trato el testing cross-device como innegociable. La herramienta que hizo esto práctico es Test UI (anteriormente LambdaTest), específicamente su función Kane AI.

Kane AI es un agente de IA que simula el comportamiento real de usuarios en diferentes dispositivos y navegadores. Describes un flujo de usuario en lenguaje natural — "inicia sesión con credenciales de prueba, haz una pregunta en el chat, guarda la respuesta en una nota del Kanban, cambia a modo oscuro y luego verifica el layout en iPhone 15 Pro" — y Kane lo ejecuta, señalando regresiones visuales, interacciones rotas y problemas de rendimiento.

Los tres problemas que Kane detectó y que yo habría lanzado sin él:

1. El bug de scroll del chat. En Safari iOS, el contenedor del chat no hacía scroll hasta el último mensaje después de que la IA respondía. El chat funcionaba perfectamente en Chrome de escritorio e incluso en Chrome móvil. Safari manejaba el comportamiento de scrollIntoView de forma diferente, y el mensaje aparecía debajo del fold. Los usuarios habrían pensado que la app estaba rota.

2. El fallo de contraste en modo oscuro. Dos elementos de texto en el componente de tarjeta Kanban tenían una relación de contraste de 3.2:1 en modo oscuro — por debajo del mínimo WCAG AA de 4.5:1. Invisible para mí en mi monitor de alta gama. Ilegible en un teléfono Android económico bajo la luz del sol.

3. La condición de carrera en la autenticación. En conexiones más lentas (3G simulado), la app ocasionalmente renderizaba el dashboard antes de que Supabase confirmara la sesión de auth, mostrando la pantalla de login durante 200ms antes de redirigir. No era un problema de seguridad — los datos no eran accesibles — pero se sentía roto y poco profesional.

Cada uno de estos habría generado tickets de soporte. Cada uno era invisible en mi entorno de desarrollo normal. El testing automatizado encontró los tres en menos de diez minutos.

La revisión de seguridad fue una pasada separada. Usé la capacidad de revisión de código de Claude Code para escanear vulnerabilidades — verificando específicamente claves de API expuestas, vectores de inyección SQL en las consultas de Supabase, y configuración incorrecta de CORS en las rutas de la API. Claude detectó un problema: la clave de API de Gemini se estaba enviando al bundle del lado del cliente porque había nombrado la variable de entorno sin seguir la convención del prefijo NEXT_PUBLIC_ al revés — la había incluido accidentalmente donde no debería haber estado. Las llamadas API que son solo del servidor deberían usar claves que nunca tocan el navegador. Detectado antes del despliegue. Podría haber sido una filtración costosa.

Para cualquiera que esté construyendo una app de producción, aquí está mi checklist de testing:

1. Testing cross-browser en Chrome, Safari, Firefox y Edge (Kane AI o manual)
2. Testing móvil en al menos un dispositivo iOS y uno Android en diferentes tamaños de pantalla
3. Simulación de red lenta para detectar condiciones de carrera y vacíos en estados de carga
4. Auditoría de accesibilidad para relaciones de contraste, navegación por teclado y compatibilidad con lectores de pantalla
5. Escaneo de seguridad para credenciales expuestas, vectores de inyección y CORS mal configurado
6. Testing de carga en el pipeline RAG — ¿qué pasa cuando 50 usuarios concurrentes consultan la base de conocimiento?

Calculo que la fase de testing añadió 3 horas al proyecto. Esas 3 horas previnieron al menos 10 horas de apagar incendios post-lanzamiento. Las cuentas no son ni remotamente parejas.

Ahora — la app funciona, está probada, está segura. Lo único que se interpone entre este proyecto y usuarios reales es el despliegue. Y gracias al pipeline de Vercel + GitHub, ese es el paso más fácil de todo el proceso.

Paso 5: Despliegue — Del build local al producto en vivo

El pipeline de despliegue es casi anticlimático después de la complejidad de los Pasos 2-4. Eso es por diseño — si tu proceso de deploy es estresante, algo aguas arriba está mal.

Hice commit de los cambios finales al repositorio de GitHub que Lovable había creado originalmente. Luego conecté el repositorio a Vercel, lo cual tomó unos dos minutos: autorizar la integración con GitHub, seleccionar el repositorio, confirmar la detección del framework (Next.js) y añadir las variables de entorno.

Las variables de entorno son la única parte que requiere cuidado:

GEMINI_API_KEY=your-gemini-api-key
PINECONE_API_KEY=your-pinecone-api-key
PINECONE_INDEX=your-index-name
NEXT_PUBLIC_SUPABASE_URL=your-supabase-url
NEXT_PUBLIC_SUPABASE_ANON_KEY=your-supabase-anon-key
SUPABASE_SERVICE_ROLE_KEY=your-service-role-key

Observa el patrón: las variables con prefijo NEXT_PUBLIC_ son seguras para exposición del lado del cliente (la URL de Supabase y la clave anon están diseñadas para ser públicas). Todo lo demás — la clave de API de Gemini, la clave de API de Pinecone, la clave de service role de Supabase — se queda solo en el servidor. Confundir esto es uno de los errores de seguridad más comunes en despliegues de Next.js, y es exactamente el problema que Claude Code detectó durante la revisión de seguridad.

El primer deploy de Vercel tomó 47 segundos. Los pushes posteriores a la rama main disparan redespliegues automáticos. Añadí un dominio personalizado a través del dashboard de Vercel — apuntar el DNS, esperar el aprovisionamiento de SSL (generalmente menos de 5 minutos), y la app está en vivo con una URL profesional.

La arquitectura final se ve así:

Para una app SaaS que puedes vender a clientes por $50-200/mes por puesto, esa estructura de costos es extremadamente saludable. Incluso el total del tier de pago de $95/mes deja un margen significativo.

Lo que hice mal y lo que cambiaría

Quiero ser honesto sobre las partes de este proyecto que no salieron bien, porque la versión pulida de cualquier tutorial esconde las decisiones que realmente importan.

La estrategia de fragmentación necesita ajuste por tipo de contenido. Mis fragmentos de 512 tokens con 50 tokens de solapamiento funcionaron bien para documentos de texto y transcripciones. Para PDFs con contenido técnico denso, después me di cuenta de que fragmentos de 768 tokens capturaban conceptos más completos. Para transcripciones de video — que tienden a ser más conversacionales y menos densas en información — fragmentos de 384 tokens redujeron el ruido en los resultados de recuperación. No hay un tamaño de fragmento universal. Necesitas probar con tus datos reales.

Gemini Embedding 2 todavía está en vista previa. El identificador del modelo gemini-embedding-exp-03-07 incluye "exp" por una razón. Durante mi build, toqué límites de tasa dos veces durante la ingesta masiva que no estaban documentados en la referencia de la API. La solución fue añadir backoff exponencial con un máximo de 5 reintentos, que Claude Code implementó en unos 30 segundos cuando describí el problema. Pero depender de un modelo experimental para cargas de trabajo de producción conlleva riesgo. Está pendiente el anuncio de disponibilidad general antes de escalar a miles de usuarios.

El tier gratuito de Lovable es demasiado limitado para iterar. Cinco mensajes diarios suena razonable hasta que estás en tu tercera ronda de refinamiento y has quemado tu asignación para las 10 de la mañana. Me pasé al plan Starter ($25/mes) en el segundo día. Si vas en serio con este flujo de trabajo, presupuesta el tier de pago desde el inicio.

El pipeline de scraping de YouTube es frágil. YouTube no tiene una API oficial de transcripciones — las herramientas que existen están haciendo ingeniería inversa de endpoints no documentados. Google podría cambiar algo mañana y romper todo el pipeline de ingesta. Para una app de producción, construiría un fallback que use Whisper o las capacidades de audio de Gemini para transcribir directamente desde el stream de audio en lugar de depender de los datos de subtítulos de YouTube.

La calidad de recuperación cross-modal varía. La recuperación texto-a-texto con Gemini Embedding 2 es excelente. La recuperación texto-a-imagen es buena pero no perfecta — aproximadamente el 80% de las veces trae el diagrama correcto. El 20% restante devuelve imágenes tangencialmente relacionadas. Para casos de uso críticos, añadí un umbral de puntuación de relevancia (0.75) por debajo del cual los resultados se filtran. Eso llevó la precisión a un nivel con el que me sentía cómodo para lanzar.

Estos no son problemas que maten el proyecto. Son el tipo de ajustes que separan un prototipo de fin de semana de un producto de producción. Y conocerlos antes de empezar significa que puedes planificar para ellos en lugar de descubrirlos a las 11 de la noche antes de una demo con un cliente.

Lo que este stack hace posible

La combinación de Gemini Embedding 2, Pinecone e ingesta automatizada habilita una categoría de aplicación que no era práctica hace seis meses. Algunos ejemplos concretos:

Bases de conocimiento internas de empresa que realmente entienden tu documentación. No búsqueda por palabras clave — búsqueda semántica a través de texto, diagramas, videos de capacitación y reuniones grabadas. Un ingeniero pregunta "¿cómo funciona la lógica de reintento de pagos?" y obtiene el fragmento de código relevante, el diagrama de arquitectura Y la marca de tiempo de la explicación del tech lead en el video del all-hands del mes pasado.

Asistentes de investigación para clientes que se mantienen actualizados automáticamente. Bufetes de abogados, agencias de consultoría, organizaciones de investigación — cualquier negocio donde los profesionales pasan horas buscando en documentos precedentes relevantes o datos. El pipeline de auto-actualización significa que la base de conocimiento crece diariamente sin curación manual.

Plataformas educativas donde los estudiantes pueden consultar material de curso en todos los formatos. Sube videos de conferencias, libros de texto en PDF y presentaciones. Los estudiantes hacen preguntas en lenguaje natural y obtienen respuestas provenientes del formato más relevante — a veces un pasaje de texto, a veces un momento específico en un video de clase.

Cada una de estas era posible antes en teoría. En la práctica, la complejidad de integración — modelos de embeddings separados para texto e imágenes, pipelines de recuperación separados, pasos de transcripción manual — las hacía imprácticas para equipos pequeños. Gemini Embedding 2 colapsa esa complejidad en una sola llamada de API. Pinecone maneja el almacenamiento y la recuperación. Claude Code conecta todo más rápido de lo que escribirías el boilerplate manualmente.

La pregunta no es si este stack tecnológico funciona. Ya he demostrado que sí. La pregunta es qué vas a construir tú con él.

El playbook, condensado

Para los constructores que quieren la versión resumida sin las historias de guerra:

1. Diseña la UI en Lovable. Sé específico en tus prompts. Itera en pasadas enfocadas apuntando a problemas individuales. Exporta a GitHub cuando llegues al 80% de calidad.

2. Conecta el backend en Anti-Gravity + Claude Code. Conecta Pinecone (3,072 dimensiones, similitud coseno). Integra Gemini Embedding 2 para fragmentación y embedding multimodal. Construye el endpoint de consulta con filtrado por metadatos y umbrales de puntuación de relevancia.

3. Automatiza la ingesta con Railway. Cron jobs diarios para contenido nuevo. Verificaciones de deduplicación contra metadatos de Pinecone. Almacena las marcas de tiempo de ejecución en Supabase, no en archivos locales.

4. Prueba en múltiples dispositivos y escanea problemas de seguridad. Kane AI para testing cross-browser y móvil. Claude Code para revisión de seguridad. Presupuesta 3 horas — te ahorra 10.

5. Despliega en Vercel. Conecta GitHub, configura variables de entorno (las claves del servidor se quedan en el servidor), configura el dominio personalizado. Primer deploy en menos de un minuto.

Tiempo total de construcción para alguien siguiendo esta guía: 2-3 días para la primera iteración. Apps posteriores usando el mismo patrón: 4-8 horas.

Si has estado construyendo apps RAG con embeddings de solo texto y te preguntas por qué la calidad de recuperación se estanca, Gemini Embedding 2 es la mejora que rompe ese techo. Si has estado programando UIs a mano para apps de IA en lugar de usar herramientas como Lovable, estás gastando horas en trabajo que un prompt puede manejar en minutos. Si has estado actualizando bases de conocimiento manualmente en lugar de automatizar la ingesta, tu app ya se está quedando atrás.

Las herramientas se han puesto al nivel de la visión. El framework de cinco pasos funciona. La única variable que queda es qué decides construir — y si empiezas hoy o esperas a que alguien más lo construya primero.

Preguntas frecuentes

¿Qué es Gemini Embedding 2 y en qué se diferencia de modelos de embeddings anteriores?

Gemini Embedding 2 es el primer modelo de embeddings nativamente multimodal de Google DeepMind, lanzado en vista previa pública el 10 de marzo de 2026. A diferencia de sus predecesores de solo texto, mapea texto, imágenes, video, audio y PDFs en un único espacio vectorial de 3,072 dimensiones. Obtiene 68.32 en MTEB English, liderando por 5.09 puntos. Para un desglose detallado de la arquitectura, consulta la sección sobre por qué Gemini Embedding 2 reescribe las reglas del RAG más arriba.

¿Cuánto cuesta construir y ejecutar una app RAG con este stack?

Usando los tiers gratuitos de Vercel, Supabase, Pinecone y la Gemini API, el único costo requerido es Railway a $5/mes para la ingesta automatizada. Los tiers de pago de todos los servicios suman aproximadamente $95/mes. Para el desglose completo de costos por servicio, consulta la sección de despliegue más arriba.

¿Qué tamaño de fragmento debería usar para Gemini Embedding 2 con Pinecone?

Empieza con fragmentos de 512 tokens y 50 tokens de solapamiento para contenido general. Ajusta según el tipo de contenido: 768 tokens para PDFs técnicos densos, 384 tokens para transcripciones conversacionales. No hay un tamaño óptimo universal — prueba con tus datos reales y mide la precisión de recuperación. Consulta la sección "Lo que hice mal" para más detalles sobre el ajuste.

¿Puede Gemini Embedding 2 reemplazar pipelines separados de embeddings de texto e imagen?

Sí — esa es su ventaja principal. Una sola llamada de API hace embedding de texto, imágenes, video, audio y documentos en un espacio vectorial unificado, eliminando la necesidad de modelos de embeddings separados y pipelines de recuperación separados. La búsqueda cross-modal (consulta de texto recuperando imágenes relevantes) funciona con aproximadamente 80% de precisión con un umbral de relevancia de 0.75.

¿Está Gemini Embedding 2 listo para producción?

A marzo de 2026, el modelo está en vista previa pública con el identificador gemini-embedding-exp-03-07. Funciona de manera confiable para aplicaciones de escala moderada pero tiene límites de tasa no documentados durante la ingesta masiva. Añade backoff exponencial a tu pipeline y monitorea el anuncio de disponibilidad general antes de escalar a miles de usuarios concurrentes.

Trabajemos juntos

¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudarte.

• Fiverr (builds personalizados e integraciones): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluciones empresariales): ramlit.com
• ColorPark (diseño y branding): colorpark.io
• xCyberSecurity (servicios de seguridad): xcybersecurity.io