+220 XP

Capstone: ein echter End-to-End-Workflow mit Gemini

# Capstone: ein echter End-to-End-Workflow mit Gemini

Bauen wir eine realistische Sache komplett durch: einen Competitive-Intelligence-Assistenten, der jeden Morgen Ihre Branche liest, Ihre Wettbewerber beobachtet und ein grounded Briefing in ein Google Doc legt, bevor Sie Ihren Kaffee ausgetrunken haben. Wir treffen die Architekturentscheidungen laut hörbar, damit Sie die Domäne austauschen können (Legal, Sales, Research, Recruiting) und das Skelett weiterverwenden.

Der Sinn eines Capstone ist nicht die Demo. Es ist das Set an Entscheidungen: welche Modellklasse, wo die Arbeit läuft, wie Fakten aktuell bleiben und was das Ganze auslöst. Wenn die stimmen, übersteht der Workflow den Kontakt mit der Realität.

Das Szenario und die Rahmenbedingungen

Der Assistent hat an jedem Werktag um 7:00 Uhr vier Aufgaben:

1. Die neuesten News und Ankündigungen zu drei namentlich genannten Wettbewerbern ziehen.

2. Alle PDFs oder Slide Decks lesen, die Sie gestern in einen Drive-Ordner gelegt haben (Preislisten, Analystenberichte).

3. Ein einseitiges Briefing mit Quellen synthetisieren.

4. Es an ein laufendes „Competitive Intel“-Doc anhängen und Ihnen die Highlights per Mail schicken.

Rahmenbedingungen, die das Design bestimmen:

  • Fakten müssen aktuell und zitierbar sein, nicht halluziniert. Das erzwingt Grounding.
  • Die Inputs sind gemischt: Webtext, PDFs, Bilder von Charts. Das erzwingt native Multimodalität.
  • Es muss unbeaufsichtigt nach Zeitplan laufen. Damit fällt die Chat-App als Engine weg.
  • Eine Person ohne Engineering-Hintergrund in Ihrem Team soll den Prompt anpassen können. Das verschiebt Logik in Richtung Workspace.

Entscheidung 1: Wo läuft das?

Sie haben drei echte Heimaten für Gemini-Arbeit, und die sind nicht austauschbar.

  • Die Gemini-App und Gems sind für interaktive Nutzung. Ein Gem ist eine gespeicherte, instruierte Version von Gemini (denken Sie an eine wiederverwendbare Persona mit stehenden Anweisungen und Dateien). Super für „stell meinem Research-Assistenten eine Frage“, nutzlos als Cron-Job um 7 Uhr, weil niemand da ist, um Enter zu drücken.
  • Gemini in Google Workspace läuft *innerhalb* von Docs, Sheets, Gmail und Drive. Hier lebt der Output, und hier kann Apps Script ihn unter Ihrem Workspace-Konto kostenlos automatisieren.
  • Die Gemini API (über Google AI Studio für Prototypen oder Vertex AI für Produktion) ist die programmierbare Engine: Modellaufrufe, Grounding, Structured Output, Scheduling.

Der klare Schnitt für dieses Capstone: Apps Script ist der Orchestrator und die Workspace-Integrationsschicht; die Gemini API macht das schwere Reasoning und das Grounding. Apps Script gibt Ihnen einen eingebauten Scheduler (zeitgesteuerte Trigger), nativen Zugriff auf Drive/Docs/Gmail und einen Ort, an dem Teamkollegen den Prompt lesen können. Die API gibt Ihnen Modellkontrolle, die die Workspace-UI nicht offenlegt, etwa Grounding-Konfiguration und JSON-Schemas.

Wäre das ein größerer, mehrstufiger Agent mit Tool-Nutzung und Memory, würden Sie stattdessen zum Agent Development Kit (ADK) auf Vertex AI greifen. Auf diese Grenzlinie kommen wir zurück.

Entscheidung 2: Welche Modellklasse?

Sie haben die Klassen Pro und Flash. Der Reflex, überall das größte Modell zu nehmen, ist teuer und langsam. Teilen Sie nach Aufgabe.

  • Flash für Arbeit mit hohem Volumen, Latenzsensibilität und „lesen und extrahieren“: jedes News-Item überfliegen, Kernfakten aus einem PDF ziehen. Günstig und schnell, und die Aufgabe ist kein schweres Reasoning.
  • Pro für den letzten Syntheseschritt: Quellen abwägen, Widersprüche erkennen, das Briefing schreiben. Das ist ein Aufruf pro Tag, also kostet das stärkere Modell fast nichts und der Qualitätssprung zählt.

Dieses Zwei-Klassen-Muster (Flash für den Fan-out, Pro für das abschließende Urteil) ist der nützlichste Kostenhebel in produktiver Gemini-Arbeit. Entscheiden Sie die Klasse pro *Aufgabe*, nicht pro *Projekt*.

Entscheidung 3: Wie bleiben Fakten frisch?

Ihr Wissen aus den Trainingsdaten ist per Definition veraltet, deshalb nutzt der Schritt mit den Wettbewerber-News Grounding mit Google Search. Grounding sagt dem Modell, echte Suchen abzusetzen und Antworten zu liefern, die an live Ergebnisse gebunden sind, mit Zitations-Metadaten, die Sie als Links darstellen können.

Sie aktivieren es als Tool im Request. Hier der zentrale Synthese-Aufruf in Python mit dem google-genai SDK, mit aktiviertem Search-Grounding:

python
from google import genai
from google.genai import types

client = genai.Client()  # liest GEMINI_API_KEY aus der Umgebung

grounding = types.Tool(google_search=types.GoogleSearch())

resp = client.models.generate_content(
    model="gemini-2.5-pro",
    contents=(
        "Summarize this week's announcements, pricing changes, and "
        "product launches for Acme, Globex, and Initech. Flag anything "
        "that affects our positioning. Cite every claim."
    ),
    config=types.GenerateContentConfig(
        tools=[grounding],
        temperature=0.3,
    ),
)

print(resp.text)
# resp.candidates[0].grounding_metadata enthält die Quell-URLs

Niedrige Temperature, weil das Analyse ist und kein Brainstorming. Die grounding_metadata in der Response trägt die belegenden Links, damit Ihr Briefing jede Aussage mit einer Fußnote versehen kann. Diese Zitationsspur macht den Output vertrauenswürdig genug, um ihn an eine Führungskraft weiterzuleiten. Prüfen Sie die Grounding-Dokumentation für die aktuelle Form der Metadaten.

Entscheidung 4: Die multimodalen Inputs behandeln

Der Drive-Ordner enthält vielleicht die PDF-Preisliste eines Wettbewerbers und einen Screenshot einer Preistabelle aus einem Webinar. Die OCRn Sie nicht separat. Gemini ist nativ multimodal: Geben Sie die PDF-Bytes und das Bild direkt im selben Request mit, und das lange Kontextfenster erlaubt es, mehrere vollständige Dokumente auf einmal einzuschließen statt sie zu chunken.

Das ist der Teil des Workflows, wo Sie wirklich *kein* RAG brauchen. RAG verdient sich seinen Platz, wenn Ihr Korpus weit größer ist als das Kontextfenster. Für „die drei Dateien, die jemand gestern abgelegt hat“ ist es einfacher, günstiger zu bauen und verliert keine Genauigkeit, sie direkt in einen Long-Context-Prompt zu stopfen. Zu wissen, wann man die Retrieval-Schicht überspringt, ist eine Architektur-Fähigkeit.

python
from pathlib import Path

pdf = client.files.upload(file="reports/globex_pricing.pdf")
chart = client.files.upload(file="reports/webinar_chart.png")

extract = client.models.generate_content(
    model="gemini-2.5-flash",
    contents=[
        pdf, chart,
        "Extract every price, tier name, and feature change. "
        "Return JSON: {items: [{vendor, tier, price, note}]}.",
    ],
    config=types.GenerateContentConfig(
        response_mime_type="application/json",
    ),
)

Beachten Sie response_mime_type="application/json". Structured Output statt Prosa anzufordern ist das, was den nächsten Schritt (den Apps-Script-Writer) in die Lage versetzt, das Ergebnis zuverlässig zu konsumieren. Zwei weitere Gründe, warum das Flash und nicht Pro ist: es läuft einmal pro Datei, und Extraktion ist mechanisch.

Multimodal prompting with the Gemini API

Watch on YouTube

Entscheidung 5: Orchestrierung und Zeitplan

Jetzt verdrahten wir es. Der Scheduler ist ein zeitgesteuerter Trigger in Apps Script, der günstigste zuverlässige Cron, den Sie in Workspace ohnehin schon besitzen. Das Skript ruft Ihren API-Endpunkt auf (oder ruft Gemini direkt über UrlFetchApp) und schreibt die Ergebnisse dann mit nativen Services in Docs und Gmail.

Hier lebt der Orchestrator in Apps Script. Er läuft um 7 Uhr, ruft Ihren Synthese-Service und hängt das Briefing an:

javascript
function dailyBriefing() {
  const payload = { date: new Date().toISOString().slice(0, 10) };
  const res = UrlFetchApp.fetch("https://your-service/brief", {
    method: "post",
    contentType: "application/json",
    payload: JSON.stringify(payload),
  });
  const brief = JSON.parse(res.getContentText());

  const doc = DocumentApp.openById("YOUR_DOC_ID").getBody();
  doc.appendParagraph(brief.title).setHeading(DocumentApp.ParagraphHeading.HEADING2);
  doc.appendParagraph(brief.summary);
  brief.sources.forEach(s => doc.appendListItem(s.url));

  GmailApp.sendEmail("you@company.com", "Daily Intel: " + brief.title, brief.summary);
}

Den 7-Uhr-Trigger setzen Sie einmal in der Apps-Script-UI unter Triggers, oder programmatisch mit ScriptApp.newTrigger. Kein Server, den man betreuen muss, keine separate Scheduler-Rechnung. Wenn Sie das rein serverseitig wollen, lassen Sie das Python auf Cloud Run mit Cloud Scheduler laufen; der Trade-off ist mehr Infra-Kontrolle für mehr Setup.

Wissenscheck

1. Was ist laut Lektion der eigentliche Wert eines Capstone-Projekts wie des Competitive-Intelligence-Assistenten?

2. Warum prägt die Anforderung, dass Fakten „aktuell und zitierbar“ sein müssen, das Design des Assistenten?

3. Wie ist in der Architektur des Capstone die Verantwortung zwischen Apps Script und der Gemini API aufgeteilt?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Gründe, die die Lektion dafür nennt, dass die Gemini-Chat-App (oder ein Gem) die falsche Engine für diesen geplanten Workflow ist.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Aussagen, die die drei in der Lektion besprochenen „Heimaten“ für Gemini-Arbeit korrekt beschreiben.

Wählen Sie alle richtigen Antworten aus.

Die vollständige Architektur, zusammengesetzt

Lesen Sie den Datenfluss einmal von oben nach unten:

1. 7:00-Uhr-Trigger (zeitgesteuerter Apps-Script-Trigger) löst dailyBriefing aus.

2. Ingest (Flash, multimodal): jede neue Drive-Datei wird hochgeladen und zu JSON extrahiert.

3. Research (Pro, grounded): ein search-grounded Aufruf sammelt frische Wettbewerber-News mit Zitationen.

4. Synthese (Pro): ein Aufruf kombiniert die extrahierten Datei-Fakten und die grounded News zu einem einseitigen Briefing, JSON raus ({title, summary, sources}).

5. Delivery (Workspace): Apps Script hängt an das laufende Doc an und mailt die Summary.

Beachten Sie, wie die Modellklassen sauber auf die Schritte abbilden: Flash fächert über viele kleine Inputs aus, Pro macht die zwei Aufrufe, die Urteilsvermögen brauchen. Beachten Sie außerdem, dass Grounding auf genau einen Schritt begrenzt ist. Den Extraktionsschritt grounden Sie nicht, weil diese Fakten aus den Dokumenten vor Ihnen kommen, nicht aus dem Web. Den falschen Schritt zu grounden erhöht die Latenz und kann irrelevante Suchergebnisse hereinziehen.

Wo sich jedes Tool seinen Platz verdient

  • API + AI Studio: Prompts und Grounding in AI Studio prototypisiert, dann in SDK-Code exportiert. Der „Get code“-Button in AI Studio ist der schnellste Weg von einem funktionierenden Prompt zu einem Skript.
  • Apps Script: der Scheduler, der Workspace-Kleber und die eine Datei, die ein Teamkollege ohne Engineering-Hintergrund sicher bearbeiten kann (der Briefing-Prompt und die Empfängerliste).
  • Vertex AI / ADK: hier absichtlich nicht genutzt. An dem Tag, an dem Sie Tools hinzufügen, zwischen denen das Modell wählt (Search *und* ein internes CRM-Lookup *und* eine Kalenderaktion), heben Sie den Orchestrator auf ADK und deployen auf Vertex AI. Das ist die Schwelle: Multi-Tool-, mehrstufige Entscheidungen gehören in ein Agent-Framework, nicht in handgeschriebene if-Statements.

Die Build-Reihenfolge, die wirklich funktioniert

Bauen Sie nicht von oben nach unten. Bauen Sie zuerst die riskante Mitte.

1. Bringen Sie in AI Studio den grounded Synthese-Prompt von Hand in Ordnung. Hier lebt oder stirbt die Qualität.

2. Machen Sie die JSON-Extraktion auf Ihren echten PDFs zuverlässig. Echte Dateien brechen naive Prompts.

3. Erst dann wickeln Sie beides in Apps Script und fügen den Trigger hinzu.

Scheduling und Doc-Schreiben sind langweilig und zuverlässig. Bei den Modell-Prompts werden Sie zehnmal iterieren, also belegen Sie die zuerst.

Worauf Sie im Produktivbetrieb achten

  • Zitationen, die nicht auflösen. Stellen Sie Grounding-URLs immer dar und klicken Sie wöchentlich ein paar an. Ein Briefing mit toten Quellen ist schlimmer als kein Briefing.
  • Stille Dateityp-Fehler. Stellen Sie sicher, dass der Ingest-Schritt mit einem leeren Drive-Ordner und einer nicht lesbaren Datei umgeht, ohne den ganzen Lauf zu killen. Wickeln Sie jede Datei in ihr eigenes try/catch.
  • Prompt-Drift. Wenn ein Teamkollege den Prompt in Apps Script bearbeitet, kann das Ausgabeformat den Doc-Writer brechen. Behalten Sie die JSON-Schema-Anforderung im Prompt und validieren Sie vor dem Schreiben.

Key Takeaways

  • Nach Aufgabe teilen, nicht nach Projekt. Nutzen Sie Flash für Extraktion mit hohem Volumen und Pro für die ein bis zwei Aufrufe, die echtes Urteilsvermögen brauchen. Das ist Ihr größter Hebel bei Kosten und Latenz.
  • Grounding auf den Schritt begrenzen, der frische Fakten braucht. Grounden Sie den Web-Research-Aufruf; grounden Sie nie Schritte, deren Fakten aus Dokumenten kommen, die Sie bereits mitgeliefert haben.
  • RAG überspringen, wenn Long Context reicht. Bei einer Handvoll Dokumente pro Lauf stopfen Sie sie in einen multimodalen Long-Context-Prompt statt eine Retrieval-Schicht zu bauen.
  • Apps Script soll Workspace orchestrieren, die API soll das Reasoning machen. Sie bekommen einen kostenlosen Scheduler, nativen Docs/Gmail-Zugriff und einen editierbaren Prompt für Nicht-Engineers, mit voller Modellkontrolle dort, wo sie zählt.
  • Wechseln Sie erst zu ADK auf Vertex AI, wenn Sie echte Multi-Tool-Agency brauchen. Handgeschriebene Schritte sind in Ordnung, bis das Modell zwischen mehreren Tools wählen und sich über Läufe hinweg erinnern muss.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

  • Standardmäßig eine Flash-first-Kaskade nutzen und nur dort auf Pro eskalieren, wo Entscheidungen zählen
Vollständiges Action Playbook ansehen