Harness vs. Standalone-Chat-LLM

Neutrale Zusammenfassung der OME-Diskussion (Topic "Ich, der DAU und sein Bot LOGBUCH", 28.08.–05.09.2026). Interpretation und Einordnung siehe Wiki-Seiten.

1. Laufzeitumgebung der Gemini-App (geschlossen)

Gemini (App) besitzt eine eigene, aber vollständig geschlossene, von Google vorkonfigurierte Laufzeitumgebung mit drei Komponenten:

Agenten- & Kontext-Laufzeit — Konversationsverlauf, Session-State, Profil-Info ("Gemerkte Informationen"), serverseitiges Modell-Routing, Quotas, Token-Limits.
Werkzeug- & Erweiterungs-Laufzeit — Function Calling/Tool Use übersetzt Freitext in strukturierte API-Aufrufe nur an das Google-Universum (Kalender, Gmail, Maps, YouTube).
Ausführungs-Sandbox — isolierte Python-Laufzeit auf Google-Cloud-Servern für Rechenaufgaben; Ergebnis wird abgefangen und zurückgereicht.

Fazit laut Gemini: "goldener Käfig" (Walled Garden) — optimiert für Alltagsaufgaben im Google-Ökosystem, nicht erweiterbar um eigene Daemons, externe Gateways oder harte Ausführungs-Workflows.

2. Faktencheck der Gemini-Notiz (Korrekturen)

Scheduled Actions (seit 2025): wiederkehrende Aufgaben in der Gemini-App laufen serverseitig, mit Push-Notification, verwaltbar in Settings — zeitgesteuerte Trigger existieren also doch; nur ohne eigene Daemons/Webhooks/externe Gateways.
Gems: erlauben eigene Custom Instructions pro Bot (quasi System-Prompt auf App-Niveau), aber nicht hart fixierbar wie im API-Harness.
⚠️ Modellnamen "Gemini 3.6/3.7 Flash" in der Notiz nicht verifizierbar (Halluzinations-Muster der Selbstbeschreibung).

3. Definition: Harness ≠ Laufzeitumgebung

Laufzeitumgebung (Runtime): rein technische Ausführungsebene — Sandbox, Prozesse, Speicher, API-Schnittstellen, Tool-Aufrufe. Das Wo und Wie der Ausführung.
Harness: übergeordnete Steuerungsarchitektur um das Modell — System-Prompt, Skills/Prozeduren, Agenten-Schleifen (ReAct), Guardrails, Memory, Evaluierung. Das Was und Warum.
Merksatz: Runtime = Motor, Harness = komplettes Fahrzeug inkl. Fahrerregeln, Navi, Checkliste. Ein Modell ohne Harness ist ein nackter LLM-Endpoint; ein Harness ohne Runtime nur ein Plan. Erst zusammen ergibt das einen Agenten.

4. Attribut-Fusions-Halluzination: der K1-Fall

Kontext: Leistungstest — "Wo in Niedersachsen spielt heute eine AC/DC-Revival-Band?"

Hermans verifizierte Antwort (2 Treffer, gegen Offizial-Quellen): 1) Nordhorn, Alte Weberei — Powerage (AC/DC Tribute) + Beast of Maiden, 20:00. 2) Wetschen, Rock and More Festival — BLACK ICE (AC/DC Tribute) als Headliner, 23:00 (rsk-event.de, meinestadt.de/Reservix).
Geminis Antwort inkl. Halluzination: Nordhorn korrekt; aber "K1 Theater (Hannover), Herrenstraße, 19:00 — Highway to Hell AC/DC-Tribute-Show" — das Event existiert real, spielt aber im K1 des Kammertheaters Karlsruhe (Baden-Württemberg, ~350 km entfernt), Quelle kammertheater-karlsruhe.de + pretix.eu/ktk/acdc. Zusätzlich: Black Ice/Wetschen verpasst, Celle-Tipp (CD-Kaserne) als Kontext.
Fehlerklasse: reale Datenpunkte (K1, Herrenstraße, 19:00, Highway to Hell) falsch verknüpft — die Attention verschmolz die Zielregion "Hannover" mit dem echten Karlsruhe-Event. Das Modell hat nicht frei erfunden, sondern Attribute vertauscht (Entity Blending).
Warum Grounding nicht schützt: Suchanbindung (Grounding) liefert Such-Snippets als Kontext, macht das Modell aber nicht zur deterministischen Datenbank (SQL); es bleibt ein probabilistisches Sprachmodell.

5. Hermans Recherche-Methode (concert-finder)

Keine Skills, keine Subagenten — fünf direkte Tool-Calls in drei Runden: zwei parallele web_search mit Datums-Kombinationen (Kandidatenliste aus Aggregatoren), zwei parallele web_extract auf aussichtsreichste Kandidaten (StubHub = 2027-Folgejahr → verworfen; meinestadt/Reservix und rsk-event = echt), danach gezielte Check-Runde gegen die K1-Behauptung.
Zwei Kernregeln: 1) Aggregatoren liefern Kandidaten, nie Antworten — Antworten nur von Offizial-Quellen. 2) Dreifeld-Check: Datum (inkl. Jahr) + Uhrzeit + Location hart belegen; eines unbestätigt → raus.
Daraus entstanden: der concert-finder-Skill (Kategorie research) und Hermans 7 Prefill-Guardrails (u.a. Regel 4 Hypothese ≠ Fakt, Regel 7 belegen oder "weiß ich nicht", Regel 2 kein Mind-Reading, Regel 3 Wenn-dann statt Du-hast).

6. Geminis Selbstanalyse des K1-Fehlers

Suchanbindung ≠ deterministische Datenbank — bleibt probabilistisch.
Entity Blending (Attribut-Vertauschung) — reale Datenpunkte falsch verknüpft; Attention verschmolz echte Namen (K1, Herrenstraße, 19:00) mit der angefragten Zielregion (Hannover).
Verifikations-Architektur (von Gemini behauptet): Reasoning-Modelle wie DeepSeek R1 liefen vor der Antwort explizite CoT-Logikprüfungen ("K1 → Karlsruhe → in Niedersachsen? Nein → verwerfen"); Standard-Generierung ohne diese Schleife lasse flüssige, plausibel klingende Textstruktur über die geografische Abgleichslogik siegen.

⚠️ Hermans Einordnung: Die Erklärung selbst ist ein Meta-Beispiel des Fehlers — der Attention-Mechanismus ist eine erzählte Ursache ohne beobachtbaren Trace, und die R1-Dichotomie ("Reasoning-Modelle verifizieren explizit") ist als Garantie empirisch falsch: CoT-Modelle halluzinieren nachweislich auch; CoT begründet, verifiziert nicht.

7. Epistemische Hygiene (Ausgangspunkt der Debatte)

Auslöser war die Patientenrechte-Diskussion (Arztbesuch, "zweite Meinung Gemini"). Kritik an Bots: hypothetische Annahmen wurden als reale Fakten über eine Person formuliert ("du hast Symptome, Angst und keine Ahnung"), ohne im Raum gewesen zu sein. Lehre: Chat-Text ist die einzige Evidenz; kein Mind-Reading; Wenn-dann statt Du-hast; Person und Argument trennen; Demut vor dem Nicht-Gesehenen.

6.1 KiB Raw Permalink Blame History Unescape Escape