Ich habe eine Premium-KI-App mit Gemini Embeddings und RAG gebaut

Das PDF enthielt Diagramme. Keine Textbeschreibungen von Diagrammen – echte Flussdiagramme, Architektur-Visualisierungen, kommentierte Screenshots. Jedes Embedding-Modell, das ich vorher getestet hatte, hätte sie komplett ignoriert, nur den umgebenden Text indexiert und die visuellen Informationen einfach liegen gelassen. Als ich also dasselbe PDF in einen Pinecone-Index mit Googles Gemini Embedding 2 Modell hochlud und eine Frage zu einem bestimmten Diagramm auf Seite drei stellte, erwartete ich den üblichen halluzinierten Unsinn.

Stattdessen holte es den exakten Kontext aus dem Diagramm. Bezog sich auf die Pfeile. Verstand den Ablauf.

Ich lehnte mich zurück und starrte gute zehn Sekunden auf mein Terminal. Das war der Moment, in dem ich wusste, dass dieser Build anders werden würde als jede RAG-App, die ich vorher ausgeliefert hatte. Nicht schrittweise besser. Grundlegend anders – weil das Embedding-Modell endlich mehr verstand als nur Wörter.

Was folgte, war ein Fünf-Schritte-Prozess zum Bau einer Premium-KI-Anwendung – mobil-responsiv, mit dynamischem Chat, speichergestütztem Wissensabruf und Multi-Format-Content-Einspeisung. Die Art von App, die du einem Kunden übergeben und für die du echtes Geld verlangen kannst. Ich werde jeden Schritt durchgehen, einschließlich der Stellen, an denen Dinge kaputtgegangen sind, und der Entscheidungen, die ich beim nächsten Mal anders treffen würde.

Aber zuerst musst du verstehen, warum Gemini Embedding 2 die Mathematik dessen verändert, was mit RAG möglich ist – und warum der Bau einer solchen App vor März 2026 wirklich schmerzhaft war.

Warum Gemini Embedding 2 das RAG-Spielbuch umschreibt

RAG – Retrieval Augmented Generation – war das Arbeitspferd-Muster, um KI-Apps ein Gedächtnis zu geben. Das Konzept ist unkompliziert: Anstatt eine gesamte Wissensdatenbank in einen Prompt zu stopfen (teuer, langsam und durch Kontextfenster begrenzt), zerlegst du Dokumente in Chunks, wandelst diese Chunks in numerische Vektoren um, speicherst sie in einer Vektordatenbank und rufst nur die relevanten Teile ab, wenn ein Nutzer eine Frage stellt. Die KI bekommt genau den Kontext, den sie braucht, ohne alles zu verarbeiten.

Das Problem war immer der Embedding-Schritt. Vor Gemini Embedding 2 waren Embedding-Modelle rein textbasiert. OpenAIs text-embedding-3-large, Coheres Modelle, sogar Googles eigenes text-embedding-004 – sie alle verarbeiteten Wörter und ignorierten alles andere. Wenn deine Wissensdatenbank Bilder, Architekturdiagramme, Video-Walkthroughs oder Audioaufnahmen enthielt, hattest du zwei Optionen: alles manuell in Text transkribieren (wobei Nuancen und visueller Kontext verloren gehen) oder akzeptieren, dass dein RAG-System für die Hälfte deiner Daten blind war.

Gemini Embedding 2 ging am 10. März 2026 in die öffentliche Preview, und es beseitigte diesen Kompromiss vollständig. Nativ auf der Gemini-Architektur aufgebaut, bildet es Text, Bilder, Video, Audio und PDFs in einen einzigen 3.072-dimensionalen Vektorraum ab. Ein Modell. Ein Embedding-Raum. Alles gemeinsam durchsuchbar.

Die Benchmarks untermauern das. Auf MTEB English erzielt es 68,32 – und hält den Spitzenplatz mit einem Vorsprung von 5,09 Punkten vor dem nächsten Konkurrenten. Aber Benchmarks bauen keine Apps. Was zählt, ist, was passiert, wenn du ein 40-seitiges Produkthandbuch mit Screenshots einspeist, es mit Pinecone verdrahtest und eine Nutzerfrage stellst. Da beginnt der echte Test.

So sieht eine multimodale RAG-Pipeline im Vergleich zum alten, rein textbasierten Ansatz aus:

Die Zeile zur cross-modalen Suche ist die, die alles verändert. Eine Textanfrage wie „zeig mir den Authentifizierungsablauf" kann jetzt ein Diagramm, einen Video-Timestamp oder einen Code-Snippet abrufen – was auch immer am relevantesten ist – aus einem einzigen vereinheitlichten Index. Keine separaten Pipelines. Kein Zusammenstückeln von Ergebnissen aus verschiedenen Embedding-Modellen.

Der Tech-Stack, bei dem ich für diesen Build gelandet bin, erzählt die Geschichte, wie diese Teile zusammenpassen. Und die Reihenfolge ist wichtig – jede Tool-Entscheidung schränkte die nächste auf Weisen ein, die ich erst voll verstand, als ich tief in der Implementierung steckte.

Das Fünf-Schritte-Framework: Vom leeren Bildschirm zum deployton SaaS

Ich habe ein Framework von Jack Roberts adaptiert, das die KI-App-Entwicklung in fünf verschiedene Phasen unterteilt. Nicht weil ich Frameworks liebe – ich habe zu viele gesehen, die Prozess hinzufügen, ohne Wert zu liefern – sondern weil dieses sauber auf die tatsächlichen Entscheidungen abbildet, vor denen du stehen wirst. Jeder Schritt produziert ein Ergebnis, das den nächsten speist.

Hier ist der Stack, bevor wir anfangen zu bauen:

Lass mich jetzt jeden Schritt so durchgehen, wie er tatsächlich passiert ist – nicht die aufgeräumte Version, die echte.

Schritt 1: Fundament und Architektur – Die UI mit Lovable bauen

Ich habe mit Lovable angefangen, weil ich die Designqualität vorziehen wollte. Die meisten KI-App-Tutorials produzieren Apps, die aussehen, als hätte sie ein Backend-Ingenieur um 2 Uhr nachts gebaut – funktional, aber visuell schmerzhaft. Für ein kundenorientiertes SaaS-Produkt muss sich die UI ab der ersten Interaktion premium anfühlen.

Lovable generiert Full-Stack-Anwendungen aus natürlichsprachlichen Prompts. Du beschreibst, was du willst, und es produziert React-Komponenten mit Tailwind CSS, verdrahtet mit einem Supabase-Backend. Der kostenlose Tarif gibt dir 5 Nachrichten pro Tag (maximal 30 monatlich), was knapp, aber machbar für einen initialen Build ist. Der Starter-Plan für 25$/Monat mit 100 Credits ist, wo die meisten ernsthaften Builder landen.

Mein initialer Prompt war spezifisch – nicht „bau mir eine Chat-App", sondern eine detaillierte Beschreibung des Dashboard-Layouts, einschließlich eines Login-Screens mit animierten Übergängen, einer Haupt-Chat-Oberfläche zum Abfragen der Wissensdatenbank und einer Kanban-Notizen-Sektion zum Speichern und Organisieren von Erkenntnissen. Ich spezifizierte Light- und Dark-Mode-Unterstützung, Konfetti-Effekte beim ersten Login und bestimmte Farbkontraste für Barrierefreiheit.

Die erste Generation brachte mir etwa 80% von dem, was ich wollte. Die Chat-Oberfläche war sauber. Das Kanban-Board funktionierte. Der Login-Flow hatte flüssige Übergänge. Aber die Abstände stimmten auf dem Handy nicht, der Dark Mode hatte Kontrastprobleme bei zwei Komponenten, und die Konfetti-Animation wurde bei jedem Seitenaufruf ausgelöst statt nur beim ersten Login.

Was ich über effektives Prompting mit Lovable gelernt habe: Behandle jede Verfeinerung als fokussierte Anweisung, nicht als Redesign-Anfrage. Statt „fix das mobile Layout" sagte ich „reduziere das Padding des Chat-Message-Containers von 24px auf 16px bei Bildschirmen unter 640px und staple die Kanban-Spalten vertikal auf dem Handy mit 12px Abstand." Spezifische Prompts produzieren spezifische Fixes. Vage Prompts produzieren neue Probleme.

Nach vier Iterationsrunden – jede auf ein einzelnes Problem fokussiert – hatte ich eine UI, die ich einem Kunden wirklich zeigen würde. Der Export zu GitHub war ein Klick. An diesem Punkt war die visuelle Schicht fertig, und ich hatte keinen Code-Editor angefasst.

Aber eine schöne UI ohne Gehirn dahinter ist nur ein Mockup. Der nächste Schritt – Gemini Embeddings und Pinecone ins Backend verdrahten – ist, wo dieser Build interessant wird. Und wo Dinge angefangen haben zu brechen.

Schritt 2: Embeddings verbinden und das Wissens-Gehirn bauen

Das ist der Schritt, der eine Demo von einem Produkt unterscheidet. Ich habe das von Lovable generierte Repo von GitHub in Anti-Gravity IDE geklont, Googles Agent-first-Entwicklungsumgebung, die auf der Arbeit des ehemaligen Windsurf-Teams aufbaut. Anti-Gravity unterhält sechzehn spezialisierte Agenten – Frontend-Spezialisten, Backend-Architekten, Sicherheits-Auditoren – aber der, der hier zählt, ist Claude Code, der im integrierten Terminal mit vollem Dateisystemzugriff läuft.

Warum Claude Code innerhalb von Anti-Gravity statt nur Claude Code standalone? Zwei Gründe. Erstens lässt dich Anti-Gravitys eingebauter Browser Änderungen in Echtzeit visuell verifizieren, ohne Fenster zu wechseln. Zweitens bedeutet das Agent-Skill-System, dass Claude Code das Backend-Wiring übernimmt, während Anti-Gravitys Frontend-Agent visuelle Regressionen abfängt. Sie ergänzen sich, statt Arbeit zu duplizieren.

Die erste Aufgabe: Pinecone als Vektordatenbank anbinden. Pinecones Serverless-Tier unterstützt die 3.072 Dimensionen, die Gemini Embedding 2 produziert, und ihre Metadaten-Filterung ermöglicht es, Abfragen auf bestimmte Dokumenttypen oder Upload-Daten einzugrenzen – entscheidend für eine Wissensdatenbank, die mit der Zeit wächst.

Ich habe Claude Code angewiesen, den Pinecone-Client einzurichten, einen Index mit den richtigen Dimensionen und der Cosine-Similarity-Metrik zu erstellen und ihn mit einer API-Route in der Next.js-App zu verdrahten. Der generierte Code funktionierte beim ersten Versuch. Hier ist der Kern des Embedding-und-Upsert-Flows:

// 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
  }));
}

Die Chunking-Strategie ist wichtiger, als die meisten Tutorials zugeben. Ich habe Dokumente in 512-Token-Chunks mit 50-Token-Überlappung aufgeteilt. Zu klein und du verlierst Kontext. Zu groß und du verschwendest Tokens auf irrelevante Inhalte beim Retrieval. Die 50-Token-Überlappung stellt sicher, dass du nicht versehentlich einen kritischen Satz über zwei Chunks aufteilst und seine Bedeutung komplett verlierst.

Für PDFs im Speziellen habe ich einen Zwei-Durchlauf-Ansatz verwendet. Erster Durchlauf: Textinhalte pro Seite extrahieren. Zweiter Durchlauf: Bilder und Diagramme extrahieren, sie separat mit Seitennummer-Metadaten embedden und sowohl Text- als auch visuelle Chunks im selben Pinecone-Namespace speichern. Hier zahlt sich die multimodale Fähigkeit von Gemini Embedding 2 aus – die visuellen Chunks leben im selben Vektorraum wie die Text-Chunks, sodass eine einzige Abfrage beides hervorbringen kann.

Der erste echte Test: Ich habe ein 40-seitiges Produkthandbuch hochgeladen, das Architekturdiagramme, UI-Screenshots und API-Referenztabellen enthielt. Dann fragte ich die Chat-Oberfläche: „Wie funktioniert der Authentifizierungsablauf?" Das System holte drei Text-Chunks, die den OAuth-Prozess beschrieben, und – hier ist der Teil, der mich beeindruckt hat – einen Bild-Chunk mit dem tatsächlichen Auth-Flow-Diagramm von Seite 12. Das multimodale Retrieval funktionierte beim ersten Versuch.

Ich werde nicht behaupten, dass alles glatt lief. Die YouTube-Scraping-Komponente brauchte drei Versuche, bis sie richtig funktionierte. Mein erster Ansatz nutzte youtube-transcript-api, um Transkripte zu ziehen, aber es schlug stillschweigend bei Videos fehl, die nur automatisch generierte Untertitel in nicht-englischen Sprachen hatten. Der zweite Versuch fügte Spracherkennung und Fallback-Logik hinzu. Der dritte fügte eine Deduplizierungsprüfung gegen Pinecones Metadaten hinzu, um zu vermeiden, dass Videos, die bereits in der Wissensdatenbank waren, erneut eingebettet werden.

// 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
    });
  }
}

Diese Deduplizierungsprüfung – Pinecones Metadaten abzufragen, bevor man embeddet – hat mich vor einem Problem bewahrt, das anfangs unsichtbar und bei Skalierung katastrophal gewesen wäre: doppelte Vektoren, die die Suchqualität verwässern. Jedes Mal, wenn der Auto-Updater läuft, prüft er, was bereits vorhanden ist, bevor er etwas Neues hinzufügt. Einfache Logik, leicht zu vergessen, teuer nachträglich zu beheben.

An diesem Punkt hatte die App eine funktionierende UI, eine verbundene Wissensdatenbank mit multimodalem RAG und die Fähigkeit, PDFs und YouTube-Inhalte einzuspeisen. Was sie nicht hatte, war eine Möglichkeit, aktuell zu bleiben, ohne dass ich manuell Ingestion-Skripte ausführe. Das löst Schritt 3 – und es ist der Schritt, den die meisten Tutorials komplett überspringen.

Schritt 3: Das Auto-Update-System, das die Wissensdatenbank frisch hält

Eine Wissensdatenbank, die am Tag der Auslieferung aufhört zu wachsen, ist eine Belastung, kein Feature. Nutzer erwarten aktuelle Informationen. Wenn deine RAG-App immer noch Ergebnisse von Daten liefert, die du vor zwei Monaten hochgeladen hast, während die Welt sich weitergedreht hat, schwindet das Vertrauen schnell.

Ich habe Railway für die Automatisierungsschicht verwendet. Railway unterstützt drei Arten von Compute: persistente Services, Cron-Jobs und Serverless Functions. Die Cron-Job-Fähigkeit ist hier entscheidend – sie lässt dich ein Skript nach Zeitplan ausführen, nur für die Ausführungszeit bezahlen und zwischen den Läufen sauber herunterfahren.

Das Setup: ein Node.js-Service auf Railway, der täglich um 3 Uhr UTC läuft. Er prüft eine konfigurierte Liste von YouTube-Kanälen auf neue Videos, die seit dem letzten Lauf veröffentlicht wurden, scrapt Transkripte, chunked sie und upserted zu Pinecone. Der ganze Prozess dauert etwa 90 Sekunden für den typischen Inhalt eines Tages, was bei Railways nutzungsbasierter Abrechnung Bruchteile eines Cents kostet.

// 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();

Railways Hobby-Plan beinhaltet 5$ Nutzung pro Monat. Für einen täglichen Cron-Job, der 90 Sekunden läuft, verbrauchst du ungefähr 0,50-1,00$/Monat an Compute – gut innerhalb des inkludierten Budgets. Das kürzeste Intervall, das Railway unterstützt, sind 5 Minuten zwischen Ausführungen, und Zeitpläne laufen in UTC, also plane dein Timing entsprechend.

Eine Design-Entscheidung, die ich anders treffen würde: Ich habe anfänglich den „letzter Lauf"-Timestamp in einer lokalen Datei auf dem Railway-Service gespeichert. Das ist fragil – wenn der Service redeployed wird, verschwindet die Datei, und der nächste Lauf verarbeitet alles erneut. Ich habe den Timestamp in eine Supabase-Tabelle verschoben, die über Deploys hinweg persistiert und mir ein abfragbares Protokoll jedes Ingestion-Laufs gibt. Kleine Änderung, große Zuverlässigkeitsverbesserung.

Die Hintergrund-Automatisierung eröffnete auch einen Workflow, den ich nicht geplant hatte. Weil sich die Wissensdatenbank selbst aktualisiert, konnte ich die Ingestion-Pipeline auf Konkurrenz-Kanäle, Branchennachrichtenquellen oder Dokumentations-Repositories richten. Das Wissen der App wuchs, während ich schlief. Für einen Kunden, der dies als SaaS-Produkt ausliefert, ist diese selbst-aktualisierende Fähigkeit ein echtes Differenzierungsmerkmal – die Erfahrung ihrer Nutzer verbessert sich täglich ohne manuelles Eingreifen.

Wenn du lieber jemanden hättest, der diese gesamte Automatisierungspipeline von Grund auf baut, nehme ich KI-App-Entwicklungsaufträge und RAG-System-Builds an. Du kannst sehen, was ich gebaut habe, unter fiverr.com/s/EgxYmWD.

Aber eine App, die funktioniert, ist nicht dasselbe wie eine App, die für Nutzer bereit ist. Die Lücke zwischen „es funktioniert auf meinem Rechner" und „es funktioniert auf jedem Gerät, jedem Browser, jeder Bildschirmgröße" ist genau der Bereich, in dem Schritt 4 lebt. Und es ist der Schritt, den die meisten Solo-Entwickler überspringen – auf eigene Gefahr.

Schritt 4: Qualitätskontrolle, die Probleme wirklich findet

Früher habe ich Projekte ausgeliefert, nachdem ich sie in Chrome auf meinem Laptop getestet und es als erledigt betrachtet hatte. Dieser Ansatz ist oft genug schiefgegangen, dass ich Cross-Device-Testing jetzt als unverzichtbar behandle. Das Tool, das dies praktikabel gemacht hat, ist Test UI (ehemals LambdaTest), speziell deren Kane AI Feature.

Kane AI ist ein KI-Agent, der echtes Nutzerverhalten über Geräte und Browser hinweg simuliert. Du beschreibst einen Userflow in natürlicher Sprache – „melde dich mit Test-Credentials an, stelle eine Frage im Chat, speichere die Antwort als Kanban-Notiz, wechsle in den Dark Mode und prüfe dann das Layout auf dem iPhone 15 Pro" – und Kane führt es aus, wobei es visuelle Regressionen, defekte Interaktionen und Performance-Probleme meldet.

Die drei Probleme, die Kane gefunden hat und die ich ohne es ausgeliefert hätte:

1. Der Chat-Scroll-Bug. Auf Safari iOS scrollte der Chat-Container nicht zur neuesten Nachricht, nachdem die KI geantwortet hatte. Der Chat funktionierte perfekt auf Chrome Desktop und sogar Chrome Mobile. Safari handhabte das scrollIntoView-Verhalten anders, und die Nachricht erschien unterhalb des sichtbaren Bereichs. Nutzer hätten gedacht, die App sei kaputt.

2. Der Dark-Mode-Kontrastfehler. Zwei Textelemente in der Kanban-Card-Komponente hatten ein Kontrastverhältnis von 3,2:1 im Dark Mode – unter dem WCAG-AA-Minimum von 4,5:1. Auf meinem High-End-Monitor unsichtbar. Auf einem günstigen Android-Handy bei hellem Sonnenlicht unlesbar.

3. Die Authentifizierungs-Race-Condition. Bei langsameren Verbindungen (simuliertes 3G) renderte die App gelegentlich das Dashboard, bevor Supabase die Auth-Session bestätigt hatte, und zeigte den Login-Screen für 200ms, bevor sie weiterleitete. Kein Sicherheitsproblem – die Daten waren nicht zugänglich – aber es fühlte sich kaputt und unprofessionell an.

Jedes dieser Probleme hätte Support-Tickets generiert. Jedes war in meiner normalen Entwicklungsumgebung unsichtbar. Automatisiertes Testing fand alle drei in unter zehn Minuten.

Die Sicherheitsüberprüfung war ein separater Durchgang. Ich nutzte Claude Codes Code-Review-Fähigkeit, um nach Schwachstellen zu scannen – speziell nach exponierten API-Keys, SQL-Injection-Vektoren in den Supabase-Abfragen und fehlerhafter CORS-Konfiguration auf den API-Routen. Claude markierte ein Problem: Der Gemini API Key wurde ans Client-Side-Bundle gesendet, weil ich die Umgebungsvariable versehentlich ohne die NEXT_PUBLIC_-Präfix-Konvention benannt hatte – genau andersherum – ich hatte ihn dort inkludiert, wo er nicht hätte sein sollen. Server-seitige API-Aufrufe sollten Keys verwenden, die niemals den Browser berühren. Vor dem Deploy entdeckt. Hätte ein kostspieliges Leck sein können.

Für alle, die eine Produktions-App bauen, hier ist meine Test-Checkliste:

1. Cross-Browser-Testing auf Chrome, Safari, Firefox und Edge (Kane AI oder manuell)
2. Mobile Testing auf mindestens einem iOS- und einem Android-Gerät in verschiedenen Bildschirmgrößen
3. Langsame-Netzwerk-Simulation, um Race Conditions und Lücken bei Ladezuständen zu finden
4. Barrierefreiheits-Audit für Kontrastverhältnisse, Tastaturnavigation und Screenreader-Kompatibilität
5. Sicherheits-Scan für exponierte Credentials, Injection-Vektoren und fehlkonfiguriertes CORS
6. Lasttest der RAG-Pipeline – was passiert, wenn 50 gleichzeitige Nutzer die Wissensdatenbank abfragen?

Ich schätze, die Testphase hat dem Build 3 Stunden hinzugefügt. Diese 3 Stunden haben mindestens 10 Stunden Post-Launch-Feuerlöschen verhindert. Die Rechnung ist nicht mal knapp.

Jetzt – die App funktioniert, sie ist getestet, sie ist sicher. Das Einzige, was zwischen diesem Projekt und echten Nutzern steht, ist das Deployment. Und dank der Vercel + GitHub Pipeline ist das der einfachste Schritt im gesamten Prozess.

Schritt 5: Deployment – Vom lokalen Build zum Live-Produkt

Die Deployment-Pipeline ist nach der Komplexität der Schritte 2-4 fast antiklimaktisch. Das ist beabsichtigt – wenn dein Deploy-Prozess stressig ist, stimmt etwas Vorgelagertes nicht.

Ich habe die finalen Änderungen in das GitHub-Repository committed, das Lovable ursprünglich erstellt hatte. Dann habe ich das Repo mit Vercel verbunden, was etwa zwei Minuten gedauert hat: die GitHub-Integration autorisieren, das Repository auswählen, die Framework-Erkennung bestätigen (Next.js) und die Umgebungsvariablen hinzufügen.

Die Umgebungsvariablen sind der einzige Teil, der Sorgfalt erfordert:

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

Achte auf das Muster: Variablen mit dem Präfix NEXT_PUBLIC_ sind sicher für die Client-seitige Exponierung (Supabase URL und Anon Key sind dafür designed, öffentlich zu sein). Alles andere – Gemini API Key, Pinecone API Key, Supabase Service Role Key – bleibt nur auf der Serverseite. Das durcheinanderzubringen ist einer der häufigsten Sicherheitsfehler bei Next.js-Deployments, und es ist genau das Problem, das Claude Code bei der Sicherheitsüberprüfung gefunden hat.

Vercels erstes Deploy dauerte 47 Sekunden. Nachfolgende Pushes auf den main-Branch lösen automatische Redeployments aus. Ich habe eine Custom Domain über Vercels Dashboard hinzugefügt – DNS-Eintrag setzen, auf SSL-Provisionierung warten (normalerweise unter 5 Minuten), und die App ist live auf einer professionellen URL.

Die finale Architektur sieht so aus:

Für eine SaaS-App, die du Kunden für 50-200$/Monat pro Platz verkaufen kannst, ist diese Kostenstruktur extrem gesund. Selbst die Gesamtkosten der bezahlten Tarife von 95$/Monat lassen erhebliche Marge.

Was ich falsch gemacht habe und was ich ändern würde

Ich möchte ehrlich sein über die Teile dieses Builds, die nicht reibungslos liefen, weil die polierte Version jedes Tutorials die Entscheidungen versteckt, die wirklich wichtig sind.

Die Chunking-Strategie braucht Feintuning pro Inhaltstyp. Meine 512-Token-Chunks mit 50-Token-Überlappung funktionierten gut für Textdokumente und Transkripte. Für PDFs mit dichtem technischem Inhalt stellte ich später fest, dass 768-Token-Chunks vollständigere Konzepte erfassten. Für Video-Transkripte – die tendenziell gesprächiger und weniger informationsdicht sind – reduzierten 384-Token-Chunks das Rauschen in den Retrieval-Ergebnissen. Es gibt keine universelle Chunk-Größe. Du musst mit deinen tatsächlichen Daten testen.

Gemini Embedding 2 ist noch in der Preview. Der Modell-Identifier gemini-embedding-exp-03-07 enthält „exp" aus gutem Grund. Während meines Builds bin ich zweimal auf Rate Limits während der Bulk-Ingestion gestoßen, die in der API-Referenz nicht dokumentiert waren. Der Workaround war, exponentielles Backoff mit maximal 5 Retries hinzuzufügen, was Claude Code in etwa 30 Sekunden implementierte, als ich das Problem beschrieb. Aber sich für Produktions-Workloads auf ein experimentelles Modell zu verlassen, birgt Risiken. Beobachte die Ankündigung der allgemeinen Verfügbarkeit, bevor du auf Tausende von Nutzern skalierst.

Lovables kostenloser Tarif ist zu knapp für Iteration. Fünf tägliche Nachrichten klingen vernünftig, bis du bei deinem dritten Verfeinerungsdurchgang bist und dein Kontingent um 10 Uhr morgens aufgebraucht hast. Ich habe am zweiten Tag auf Starter (25$/Monat) aufgestockt. Wenn du diesen Workflow ernst meinst, kalkuliere den bezahlten Tarif von Anfang an ein.

Die YouTube-Scraping-Pipeline ist fragil. YouTube hat keine offizielle Transkript-API – die existierenden Tools reverse-engineeren undokumentierte Endpunkte. Google könnte morgen etwas ändern und die gesamte Ingestion-Pipeline brechen. Für eine Produktions-App würde ich einen Fallback bauen, der Whisper oder Geminis Audio-Fähigkeiten nutzt, um direkt aus dem Audiostream zu transkribieren, statt sich auf YouTubes Untertiteldaten zu verlassen.

Die Qualität des cross-modalen Retrievals variiert. Text-zu-Text-Retrieval mit Gemini Embedding 2 ist ausgezeichnet. Text-zu-Bild-Retrieval ist gut, aber nicht perfekt – etwa 80% der Zeit liefert es das richtige Diagramm. Die restlichen 20% liefern nur entfernt verwandte Bilder. Für kritische Anwendungsfälle habe ich einen Relevanz-Score-Threshold (0,75) hinzugefügt, unter dem Ergebnisse herausgefiltert werden. Das brachte die Genauigkeit auf ein Niveau, mit dem ich mich beim Ausliefern wohlgefühlt habe.

Das sind keine Dealbreaker. Es ist die Art von Feintuning, die einen Wochenend-Prototypen von einem Produktionsprodukt unterscheidet. Und wenn du vorher davon weißt, kannst du dafür planen, statt es um 23 Uhr am Abend vor einer Kundendemo zu entdecken.

Was dieser Stack ermöglicht

Die Kombination von Gemini Embedding 2, Pinecone und automatisierter Ingestion ermöglicht eine Kategorie von Anwendungen, die vor sechs Monaten nicht praktikabel war. Ein paar konkrete Beispiele:

Interne Unternehmens-Wissensdatenbanken, die deine Dokumentation wirklich verstehen. Keine Keyword-Suche – semantische Suche über Text, Diagramme, Schulungsvideos und aufgezeichnete Meetings hinweg. Ein Ingenieur fragt „wie funktioniert die Payment-Retry-Logik?" und bekommt den relevanten Code-Snippet, das Architekturdiagramm UND den Timestamp aus der Erklärung des Tech Leads im All-Hands-Video vom letzten Monat.

Kundenorientierte Research-Assistenten, die sich automatisch aktuell halten. Anwaltskanzleien, Beratungsfirmen, Forschungsorganisationen – jedes Unternehmen, in dem Fachleute Stunden damit verbringen, Dokumente nach relevanten Präzedenzfällen oder Datenpunkten zu durchsuchen. Die Auto-Update-Pipeline bedeutet, dass die Wissensdatenbank täglich wächst, ohne manuelle Kuratierung.

Bildungsplattformen, auf denen Studenten Kursmaterial formatübergreifend abfragen können. Lade Vorlesungsvideos, PDF-Lehrbücher und Foliendecks hoch. Studenten stellen Fragen in natürlicher Sprache und bekommen Antworten aus dem relevantesten Format – manchmal ein Textabschnitt, manchmal ein bestimmter Moment in einem Vorlesungsvideo.

Jedes davon war vorher in der Theorie möglich. In der Praxis machte die Integrationskomplexität – separate Embedding-Modelle für Text und Bilder, separate Retrieval-Pipelines, manuelle Transkriptionsschritte – sie für kleine Teams impraktikabel. Gemini Embedding 2 komprimiert diese Komplexität in einen einzigen API-Aufruf. Pinecone übernimmt die Speicherung und den Abruf. Claude Code verdrahtet alles schneller, als du den Boilerplate-Code manuell schreiben würdest.

Die Frage ist nicht, ob dieser Tech-Stack funktioniert. Ich habe bewiesen, dass er es tut. Die Frage ist, was du damit bauen wirst.

Das Playbook, komprimiert

Für die Builder, die die kompakte Version ohne die Kriegsgeschichten wollen:

1. Designe die UI in Lovable. Sei spezifisch in deinen Prompts. Iteriere in fokussierten Durchgängen, die einzelne Probleme angehen. Exportiere zu GitHub, wenn du 80% Qualität erreicht hast.

2. Verdrahte das Backend in Anti-Gravity + Claude Code. Verbinde Pinecone (3.072 Dimensionen, Cosine Similarity). Integriere Gemini Embedding 2 für multimodales Chunking und Embedding. Baue den Query-Endpunkt mit Metadaten-Filterung und Relevanz-Score-Thresholds.

3. Automatisiere die Ingestion mit Railway. Tägliche Cron-Jobs für neue Inhalte. Deduplizierungsprüfungen gegen Pinecone-Metadaten. Speichere Lauf-Timestamps in Supabase, nicht in lokalen Dateien.

4. Teste geräteübergreifend und scanne auf Sicherheitsprobleme. Kane AI für Cross-Browser- und Mobile-Testing. Claude Code für die Sicherheitsüberprüfung. Plane 3 Stunden ein – es spart 10.

5. Deploye auf Vercel. Verbinde GitHub, setze Umgebungsvariablen (Server-seitige Keys bleiben server-seitig), konfiguriere die Custom Domain. Erstes Deploy in unter einer Minute.

Gesamte Build-Zeit für jemanden, der dieser Anleitung folgt: 2-3 Tage für die erste Iteration. Nachfolgende Apps mit demselben Muster: 4-8 Stunden.

Wenn du RAG-Apps mit reinen Text-Embeddings gebaut hast und dich fragst, warum die Retrieval-Qualität stagniert, ist Gemini Embedding 2 das Upgrade, das diese Decke durchbricht. Wenn du UIs für KI-Apps von Hand codiert hast, statt Tools wie Lovable zu verwenden, verbringst du Stunden mit Arbeit, die ein Prompt in Minuten erledigen kann. Wenn du Wissensdatenbanken manuell aktualisiert hast, statt die Ingestion zu automatisieren, fällt deine App bereits zurück.

Die Tools haben mit der Vision aufgeholt. Das Fünf-Schritte-Framework funktioniert. Die einzige verbleibende Variable ist, was du zu bauen beschließt – und ob du heute anfängst oder darauf wartest, dass jemand anderes es zuerst baut.

Häufig gestellte Fragen

Was ist Gemini Embedding 2 und wie unterscheidet es sich von früheren Embedding-Modellen?

Gemini Embedding 2 ist Google DeepMinds erstes nativ multimodales Embedding-Modell, veröffentlicht in der öffentlichen Preview am 10. März 2026. Anders als rein textbasierte Vorgänger bildet es Text, Bilder, Video, Audio und PDFs in einen einzigen 3.072-dimensionalen Vektorraum ab. Es erzielt 68,32 auf MTEB English und führt mit 5,09 Punkten Vorsprung. Für eine detaillierte Aufschlüsselung der Architektur siehe den Abschnitt oben darüber, warum Gemini Embedding 2 das RAG-Spielbuch umschreibt.

Wie viel kostet es, eine RAG-App mit diesem Stack zu bauen und zu betreiben?

Bei Nutzung der kostenlosen Tarife von Vercel, Supabase, Pinecone und der Gemini API sind die einzigen erforderlichen Kosten Railway mit 5$/Monat für die automatisierte Ingestion. Bezahlte Tarife für alle Services summieren sich auf ungefähr 95$/Monat. Für die vollständige Kostenaufschlüsselung nach Service siehe den Deployment-Abschnitt oben.

Welche Chunk-Größe sollte ich für Gemini Embedding 2 mit Pinecone verwenden?

Beginne mit 512-Token-Chunks und 50-Token-Überlappung für allgemeine Inhalte. Passe basierend auf dem Inhaltstyp an: 768 Token für dichte technische PDFs, 384 Token für gesprächige Transkripte. Es gibt keine universelle optimale Größe – teste mit deinen tatsächlichen Daten und miss die Retrieval-Genauigkeit. Siehe den Abschnitt „Was ich falsch gemacht habe" für weitere Details zum Feintuning.

Kann Gemini Embedding 2 separate Text- und Bild-Embedding-Pipelines ersetzen?

Ja – das ist sein Hauptvorteil. Ein einziger API-Aufruf embeddet Text, Bilder, Video, Audio und Dokumente in einen vereinheitlichten Vektorraum, wodurch separate Embedding-Modelle und Retrieval-Pipelines überflüssig werden. Cross-modale Suche (Textanfrage ruft relevante Bilder ab) funktioniert mit etwa 80% Genauigkeit bei einem 0,75-Relevanz-Threshold.

Ist Gemini Embedding 2 produktionsreif?

Stand März 2026 befindet sich das Modell in der öffentlichen Preview mit dem Identifier gemini-embedding-exp-03-07. Es funktioniert zuverlässig für Anwendungen mittlerer Größenordnung, hat aber undokumentierte Rate Limits bei Bulk-Ingestion. Füge exponentielles Backoff zu deiner Pipeline hinzu und beobachte die Ankündigung der allgemeinen Verfügbarkeit, bevor du auf Tausende gleichzeitiger Nutzer skalierst.

Lass uns zusammenarbeiten

Du möchtest KI-Systeme bauen, Workflows automatisieren oder deine Tech-Infrastruktur skalieren? Ich helfe gerne.

• Fiverr (individuelle Builds & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienstleistungen): xcybersecurity.io