Gemini-Queries aus Interactions parsen: steps, Status und Quellenumfang

Lies offengelegte Strings aus google_search_call.arguments.queries im Interactions-steps-Array. Zitate aus model_output bleiben auf Laufebene. Das Offline-Kit übernimmt weder google_search_result noch Search Suggestions oder Gedanken-Payloads.

Für Interactions-JSON mit Google Search. Die Fixtures sind eigene synthetische Strukturen; reale Gemini-Grounding-Ausgaben werden hier nicht veröffentlicht.

Prüfe anschließend ein eigenes ErgebnisDas Offline-Kit braucht keinen API-Schlüssel. Im kostenlosen Tool kannst du später einen separaten, begrenzten Lauf prüfen.Kostenloses Tool öffnen

Den richtigen API-Vertrag auswählen

Der optionale direkte Gemini-Adapter verwendet /v1beta/interactions mit google_search. Dieses Lehrbeispiel beginnt deshalb bei steps. Die aktuelle Website nutzt dagegen Gemini über OpenRouter Chat Completions; dieser geprüfte Pfad liefert Suchzähler und Laufzitate, aber keine Query-Strings. Eine Antwort mit candidates und groundingMetadata gehört zu einer anderen API-Struktur; sie wird nicht ersatzweise in diesen Parser eingelesen. Entscheide zuerst, welche Oberfläche du tatsächlich aufrufst.

Jeder google_search_call wird zu einer Aktion mit den offengelegten Query-Strings. Fehlende IDs und Modelle bleiben im Lehrbeispiel null. Die fehlende Information wird nicht durch einen plausiblen Namen ersetzt. Sind mehrere Aufrufe vorhanden, bleibt die Mitgliedschaft ihrer Strings nachvollziehbar.

Entpacke das gemeinsame Kit und führe den Code unten im Ordner fanout-kit-v2 aus. Die beiden Strings stammen ausschließlich aus fixtures.mjs. Das Beispiel zeigt Parser-Verhalten ohne API-Zugriff, nicht die Suchentscheidungen einer Gemini-Endnutzersitzung. Für einen echten eigenen Aufruf brauchst du getrennte Fehlerbehandlung, aktuelle Modellfreigabe und deine private Konfiguration.

Vertiefe das mit ein Gemini-Ergebnis einordnen.

Synthetische Interactions-Antwort lesen

import { parseGeminiInteraction } from "./parsers.mjs";
import { fixtures } from "./fixtures.mjs";
const result = parseGeminiInteraction(fixtures.gemini);
console.log(result.queries); // two synthetic strings
console.log(result.actions[0].sources); // []
console.log(result.runSources[0].sourceScope); // run

Suchstrings und Grounding-Payloads getrennt behandeln

Die synthetische Antwort enthält bewusst einen Marker in google_search_result. Der Test verlangt, dass er im Parser-Ergebnis nicht auftaucht. Der Parser liest nur Suchaufrufe und URL-Annotationen am model_output. Er kopiert keine Search Suggestions und keine thought-Blöcke.

Die fiktive URL-Annotation bleibt in runSources. In den hier gezeigten Suchaufrufen fehlt ein belegter Query-Quellen-Join, daher haben ihre actions leere sources und sourceScope not_exposed. Eine übereinstimmende Domain ist kein Ersatz für die fehlende Beziehung. Das ist besonders wichtig, wenn du später CSV-Zeilen oder Reports erzeugst.

Das Weglassen bestimmter Felder beantwortet nicht automatisch jede Frage zu Speicherung und Weiterverwendung realer Daten. Das Website-Speicherformat entfernt bei Gemini die Grounding-Quellen und markiert sourceEvidenceScope als not_stored_google_grounded_results. Fehlende gespeicherte Quellen bedeuten deshalb nicht, dass der Live-Lauf ohne Quellen stattfand. Prüfe die aktuellen Anbieterbedingungen für deinen konkreten Gebrauch.

Vertiefe das mit den Speichervertrag validieren.

Unbekannter Status bleibt unbekannt

Der Lehr-Parser verwendet einen vorhandenen Status, setzt aber keinen fehlenden Status auf completed. Ein gültiges completed mit null sichtbaren Strings ist von einer failed-Antwort, einem unvollständigen Lauf oder einer fehlenden steps-Liste verschieden. Fehlerantworten ohne steps können failed zurückgeben; ein unpassender Container löst INVALID_RESPONSE aus.

Nur der optionale direkte Gemini-Pfad nutzt bei fehlendem Provider-Status einen Completed-Ersatz; der aktuelle OpenRouter-Pfad prüft den gelieferten Abschlussstatus. Auch begrenzt und dedupliziert der Website-Wrapper Strings. Das Kit dokumentiert diese Grenze ausdrücklich. Wenn dein Workflow vollständige Statusbelege braucht, musst du sie schon in der Aufrufschicht erhalten und separat speichern dürfen.

Teste Änderungen zuerst mit selbst erstellten Strukturen. Der Download enthält gültige Beispiele und absichtlich falsche Felder für negative Tests. Veröffentlichung realer Grounding-Antworten ist keine Voraussetzung für einen brauchbaren Parser-Test. Ein synthetischer Test kann Form und Zustandslogik prüfen, aber keine aktuelle Provider-Verfügbarkeit beweisen.

Vertiefe das mit das gemeinsame Testkit ausführen.

Verwendete Quellen

Diese Quellen stützen die beschriebenen Funktionen und Grenzen. Sie belegen keine darüber hinausgehenden Aussagen.

Gemini Interactions: Suchaufrufe und Step-Typen
Stützt Interactions-steps, Argumente von google_search_call und Output-Annotationen. Der Vertrag unterscheidet sich von GenerateContent-candidates. Synthetische Lehrdaten belegen keine Veröffentlichungsrechte für reale Grounding-Ausgaben.
Quelle öffnen
Gemini API Additional Terms
Restricts caching, syndication, analysis and reuse of Google Grounded Results and Search Suggestions; drives the Gemini local-save redaction and public-example boundary.
Quelle öffnen
Eigenes ausführbares Offline-Parser- und Randfall-Testkit
Eigener Lehrcode und 27 Offline-Prüfungen. Synthetische Antwortstrukturen sind keine Provider-Ausgaben. Geprüft werden Strings, Status, Quellenumfang und ausgeschlossene Payloads. Kein bezahlter Aufruf oder neues reales Grounding-Material; der Lehr-Parser unterscheidet sich ausdrücklich vom Website-Wrapper.
Quelle öffnen
Aktuelle Website-Exportverträge und Referenzvalidierung
Draft-2020-12-Referenz für aktuelle native/modellierte Vollruns, Query-Auswahlen und lokale Vergleiche. Geprüft gegen tatsächliche Service-/Exportfunktionen mit synthetischen Provider-Stubs und negativen Semantiktests. Vollruns erhalten keine erfundene root-schemaVersion; ältere Planner- und Handoff-Formate bleiben getrennt.
Quelle öffnen