Meeting-Transkription in Gemini 3.5 Transcribe: Sprecher, Zeitstempel und Vokabular in der Praxis

Die Umwandlung einer Audioaufnahme eines geschäftlichen Meetings in ein verlässliches Arbeitsdokument erfordert durchdachte architektonische Entscheidungen bei der Konfiguration der Spracherkennungsparameter. In Gemini 3.5 Transcribe existiert kein universeller „All-in-one“-Modus: tiefgreifende redaktionelle Normalisierung (smart), Sprechertrennung (diarization_mode), wortgenaue Zeitraster (timestamp_granularities) und domänenspezifisches Vokabular (custom_vocabulary) stellen voneinander isolierte API-Funktionen dar.

Jede Verarbeitungspipeline muss mit der Festlegung des eigentlichen Ziels beginnen: Benötigen Sie einen kompakten, flüssig lesbaren Fließtext zum schnellen Erfassen, eine strukturierte Arbeitsgrundlage für nachgelagerte Analysen oder ein Array exakter Zeitstempel für den Videoschnitt? Der Versuch, sich gegenseitig ausschließende Parameter zu kombinieren, führt bereits vor der eigentlichen Anfrageverarbeitung zu Schema-Validierungsfehlern.

Im Folgenden wird ein vollständiger praktischer Ablauf durchgespielt: wie Sie eine 45-minütige Aufnahme zweier Sprecher voller technischer Fachbegriffe vorbereiten, dokumentierte API-Limits einhalten, beide Segmente über das offizielle Python SDK verarbeiten, vorläufige Entwurfsdatenstrukturen aufbauen, diese anhand der Audioaufnahme verifizieren und korrigieren sowie geprüfte Kopien an Protokollanten oder Untertitel-Editoren übergeben.

---

Architektonische Einschränkungen und Parameterkonflikte

Um die Pipeline zu veranschaulichen, betrachten wir ein typisches Arbeitsmeeting: Alexey (Tech Lead) und Mikhail (Product Manager) diskutieren 45 Minuten lang über die Migrationsarchitektur und das Deployment von Diensten unter den internen Projektnamen DataPulse und CloudForge. Das Gespräch ist geprägt von Fachjargon, Anglizismen, schnellen Unterbrechungen und Neuansätzen.

Bei der Konzeption einer Integration mit Gemini 3.5 Transcribe müssen Sie drei strikte Regeln beachten:

• Inkompatibilität zwischen Custom Vocabulary und strukturellen Metadaten: Der Parameter custom_vocabulary (unterstützt bis zu 1.000 Begriffe, praktische Empfehlung: bis zu 100) kann nicht gemeinsam mit diarization_mode oder timestamp_granularities übergeben werden. Sie müssen einen architektonischen Kompromiss eingehen: Entweder überlassen Sie dem Modell die präzise Transkription seltener Markennamen (und verzichten dabei auf automatische Sprecherbezeichnungen und Zeitstempel) oder Sie fordern detaillierte Sprecher- und Zeitausrichtungen an und verifizieren Fachtermini während der Nachbearbeitung manuell.
• Inkompatibilität zwischen Smart-Modus und Zeitleistenausrichtung: Der smart-Modus führt eine Sprachnormalisierung durch: Er tilgt Füllwörter, Stottern und falsche Satzanfänge, während er die grammatikalische Syntax restrukturiert. Da Tokens entfernt, zusammengefasst oder umgestellt werden, kann das Modell den resultierenden Text nicht mehr auf die zeitliche Achse des zugrundeliegenden Audiostreams abbilden. Sprecherzuordnungen und wortgenaue Zeitstempel sind im smart-Modus daher nicht verfügbar. Zudem liefert dieser Modus lediglich unannotierten Fließtext (output_text) zurück und extrahiert nicht automatisch Action Items.
• 30-Minuten-Grenze für erweiterte Metadaten: Standard-Transkriptionsanfragen ohne detaillierte Annotationen akzeptieren Audiodateien mit einer Länge von bis zu 60 Minuten. Sobald Sie jedoch diarization_mode oder timestamp_granularities aktivieren, sinkt die dokumentierte maximale Dateidauer auf 30 Minuten. Das Einreichen von Dateien, die diesen Schwellenwert überschreiten, liegt außerhalb der unterstützten API-Spezifikation und sollte unterbleiben; langes Audiomaterial muss vor der Übermittlung clientseitig aufgeteilt werden.

---

Vorbereitung und Aufteilung der 45-minütigen Aufnahme

Um Diarisierung und wortgenaue Zeitstempel aus einer 45-minütigen Aufnahme zu gewinnen, muss die Quelldatei in Segmente von strikt unter 30 Minuten unterteilt werden. In unserem hypothetischen Szenario teilen wir die Aufnahme in zwei Abschnitte:

• Teil 1: 00:00–25:00 (angenommen als exakt 1500.0 Sekunden);
• Teil 2: 25:00–45:00 (die verbleibenden 20 Minuten bzw. 1200.0 Sekunden).

Die Grenze von 1500.0 Sekunden wurde hier rein zur rechnerischen Veranschaulichung gewählt. In Produktionsumgebungen sollten Schnitte in natürlichen Gesprächspausen zwischen Wortbeiträgen gesetzt werden, und die exakte physische Dauer des ersten Segments muss über ein Analysetool wie ffprobe direkt aus den Metadaten der Mediendatei ausgelesen werden.

Das Aufteilen des Audiomaterials bringt zwei kritische Herausforderungen für die Kontinuität mit sich:

1. Zeitstempel-Reset im zweiten Segment: Die API verarbeitet das zweite Segment als vollständig eigenständige Datei, sodass deren interne Wort-Offsets wieder bei 0.000s beginnen. Um eine durchgehende Zeitleiste für das gesamte Meeting zu rekonstruieren, muss die tatsächliche Dauer des ersten Segments programmatisch zu jedem Wort-Zeitstempel des zweiten Segments addiert werden.
2. Lokalität von Sprecher-Labels: Das Modell weist Sprecherkennungen wie spk_1 und spk_2 isoliert innerhalb jedes einzelnen API-Aufrufs zu. Der Sprecher, der im ersten Abschnitt als spk_1 geführt wird, kann im zweiten Abschnitt als spk_2 deklariert sein. Ein unreflektiertes Zusammenführen identischer technischer Bezeichnungen über separate Anfragen hinweg führt unweigerlich zu fehlerhafter Sprecherzuweisung. Für jedes Segment ist eine unabhängige Lookup-Tabelle erforderlich, die durch stichprobenartiges Gegenhören mit den realen Teilnehmern abgeglichen wird.

---

Konfigurationsvarianten für unterschiedliche Aufgaben

Transkriptionsparameter werden innerhalb des Feldes transcription_config im Dictionary generation_config konfiguriert. Nachfolgend finden Sie Basiskonfigurationen für unterschiedliche operative Anforderungen.

Für kohärente, normalisierte Meeting-Notizen ohne Sprecherzuordnung oder Zeitstempel (geeignet für vollständige Dateien unter 60 Minuten):

generation_config = {
    "transcription_config": {
        "mode": "smart"
    }
}

Für Diskussionen mit speziellem Fachwortschatz oder geschützten Markennamen, bei denen die fehlerfreie Schreibweise oberste Priorität hat:

generation_config = {
    "transcription_config": {
        "custom_vocabulary": ["DataPulse", "CloudForge", "ClickHouse", "gRPC"]
    }
}

Für die Erstellung von Gesprächsprotokollen und Zeitrastern für Untertitel (unter Beachtung des 30-Minuten-Audiolimits):

generation_config = {
    "transcription_config": {
        "mode": {
            "type": "verbatim",
            "diarization_mode": "speaker",
            "timestamp_granularities": ["word"],
        }
    }
}

---

Vollständige Pipeline mit dem Python SDK: Verarbeitung beider Teile

Dieses Skript wird ausgeführt, bevor die Audioaufnahme abgehört oder eine manuelle Prüfung vorgenommen wird. Es lädt beide Segmente über die Files API hoch, sendet Anfragen an die Interactions API, extrahiert wortgenaue Annotationen, validiert Zeitstempel sowie Sprecherkennungen, verschiebt die Zeitleiste des zweiten Teils um 1500.0 Sekunden und schreibt vorläufige Entwurfsdateien:

• meeting_transcript.txt — ein vorläufiger UTF-8-Dialogentwurf, strukturiert nach Wortbeiträgen der Sprecher;
• word_timestamps.json — ein vorläufiges Array kontinuierlicher Wort-Zeitstempel für die spätere Segmentierung von Untertiteln.

Die von diesem Skript erzeugten Dateien sind ausdrücklich ungeprüfte Entwürfe (Drafts) und keine finalen Dokumente. Der Anwender muss die Aufnahme anhören, die technischen Sprecher-Tokens den echten Stimmen zuordnen (Speaker Mapping), die Fachterminologie verifizieren (Terms) und die Zeitversätze auditieren (Time Offsets). Erst nach diesem Audit werden die Konfigurationsparameter im Code angepasst und die Pipeline erneut ausgeführt oder die generierten Textdateien direkt überarbeitet. Erst nach Abschluss dieses Prüfprotokolls dürfen finale Kopien an Protokollanten oder Untertitel-Editoren übergeben werden.

Das Skript liefert Zwischendatenstrukturen für Analysten und Cutter; es erzeugt weder automatisch Action Items noch formatierte .srt-Untertiteldateien. Die Sprechernamen und die 1500.0-Sekunden-Grenze dienen in diesem hypothetischen Szenario lediglich Demonstrationszwecken.

import json
from google import genai

client = genai.Client()

audio_part1 = client.files.upload(file="meeting_part1.mp3")
audio_part2 = client.files.upload(file="meeting_part2.mp3")

transcription_mode_config = {
    "transcription_config": {
        "mode": {
            "type": "verbatim",
            "diarization_mode": "speaker",
            "timestamp_granularities": ["word"],
        }
    }
}

interaction_part1 = client.interactions.create(
    model="gemini-3.5-transcribe",
    input=[
        {
            "type": "audio",
            "uri": audio_part1.uri,
            "mime_type": audio_part1.mime_type,
        }
    ],
    generation_config=transcription_mode_config,
)

interaction_part2 = client.interactions.create(
    model="gemini-3.5-transcribe",
    input=[
        {
            "type": "audio",
            "uri": audio_part2.uri,
            "mime_type": audio_part2.mime_type,
        }
    ],
    generation_config=transcription_mode_config,
)

def extract_word_annotations(interaction):
    words = []
    for step in getattr(interaction, "steps", []) or []:
        for content in getattr(step, "content", []) or []:
            for annotation in getattr(content, "annotations", []) or []:
                if getattr(annotation, "type", None) == "word_info":
                    words.append(annotation)
    return words

def parse_offset_seconds(offset_val, word_text):
    if offset_val is None or offset_val == "":
        raise ValueError(f"Отсутствует таймкод для слова '{word_text}'. Требуется проверка аудиозаписи.")
    val_str = str(offset_val)
    if val_str.endswith("s"):
        val_str = val_str[:-1]
    try:
        return float(val_str)
    except ValueError:
        raise ValueError(f"Некорректный формат таймкода '{offset_val}' для слова '{word_text}'. Требуется проверка аудиозаписи.")

words_part1 = extract_word_annotations(interaction_part1)
words_part2 = extract_word_annotations(interaction_part2)

if not words_part1 or not words_part2:
    raise ValueError("Один из аудиосегментов не содержит пословных аннотаций. Пустой результат не может считаться успешным.")

part1_offset_seconds = 0.0
part2_offset_seconds = 1500.0

manual_mapping_part1 = {
    "spk_1": "Алексей",
    "spk_2": "Михаил",
}

manual_mapping_part2 = {
    "spk_1": "Михаил",
    "spk_2": "Алексей",
}

unified_word_stream = []

for word in words_part1:
    text = getattr(word, "text", "")
    raw_speaker = getattr(word, "speaker", None)
    if not raw_speaker or raw_speaker not in manual_mapping_part1:
        raise ValueError(f"Неизвестный спикер '{raw_speaker}' в части 1. Требуется ручная верификация по аудио.")
    resolved_speaker = manual_mapping_part1[raw_speaker]
    word_start = parse_offset_seconds(getattr(word, "start_offset", None), text) + part1_offset_seconds
    word_end = parse_offset_seconds(getattr(word, "end_offset", None), text) + part1_offset_seconds
    unified_word_stream.append({
        "text": text,
        "speaker": resolved_speaker,
        "start_seconds": word_start,
        "end_seconds": word_end,
        "part": 1,
    })

for word in words_part2:
    text = getattr(word, "text", "")
    raw_speaker = getattr(word, "speaker", None)
    if not raw_speaker or raw_speaker not in manual_mapping_part2:
        raise ValueError(f"Неизвестный спикер '{raw_speaker}' в части 2. Требуется ручная верификация по аудио.")
    resolved_speaker = manual_mapping_part2[raw_speaker]
    word_start = parse_offset_seconds(getattr(word, "start_offset", None), text) + part2_offset_seconds
    word_end = parse_offset_seconds(getattr(word, "end_offset", None), text) + part2_offset_seconds
    unified_word_stream.append({
        "text": text,
        "speaker": resolved_speaker,
        "start_seconds": word_start,
        "end_seconds": word_end,
        "part": 2,
    })

dialogue_turns = []
current_turn = None

for item in unified_word_stream:
    if current_turn is None or current_turn["speaker"] != item["speaker"] or current_turn["part"] != item["part"]:
        if current_turn is not None:
            dialogue_turns.append(current_turn)
        current_turn = {
            "part": item["part"],
            "speaker": item["speaker"],
            "start_seconds": item["start_seconds"],
            "end_seconds": item["end_seconds"],
            "words": [item["text"]],
        }
    else:
        current_turn["end_seconds"] = item["end_seconds"]
        current_turn["words"].append(item["text"])

if current_turn is not None:
    dialogue_turns.append(current_turn)

def format_timestamp(seconds):
    minutes = int(seconds // 60)
    remaining_seconds = seconds % 60
    return f"{minutes:02d}:{remaining_seconds:06.3f}"

with open("meeting_transcript.txt", "w", encoding="utf-8") as f_transcript:
    for turn in dialogue_turns:
        start_str = format_timestamp(turn["start_seconds"])
        end_str = format_timestamp(turn["end_seconds"])
        speech_text = " ".join(turn["words"])
        f_transcript.write(f"[{start_str} - {end_str}] {turn['speaker']}: {speech_text}\n")

with open("word_timestamps.json", "w", encoding="utf-8") as f_json:
    json.dump(unified_word_stream, f_json, ensure_ascii=False, indent=2)

---

Anschauliches Beispiel der Wortstruktur und Prüfzonen

Nachfolgend ist eine synthetische Darstellung des extrahierten Datenstroms an der Schnittstelle eines Sprecherwechsels aufgeführt.

Hinweis: Dieser Ausschnitt dient ausschließlich der Veranschaulichung der zurückgegebenen Objektstruktur, nicht als realer Log eines API-Aufrufs. Die tatsächliche Transkriptionsqualität hängt von Raumakustik, Mikrofonen und Artikulation ab.

[Строка 1] [spk_1] (0.100s -> 0.420s) Мы
[Строка 2] [spk_1] (0.450s -> 0.810s) переносим
[Строка 3] [spk_1] (0.830s -> 1.250s) ДатаПульс
[Строка 4] [spk_1] (1.300s -> 1.550s) на
[Строка 5] [spk_1] (1.600s -> 2.100s) CloudForge.
[Строка 6] [spk_1] (2.300s -> 2.600s) Да,
[Строка 7] [spk_2] (2.650s -> 2.900s) согласен,
[Строка 8] [spk_2] (2.950s -> 3.400s) э-э-э,
[Строка 9] [spk_2] (3.420s -> 3.900s) логично.

Kritische Checkliste für die manuelle Prüfung:

1. Zuordnung der Labels zu realen Teilnehmern (Zeilen 1–5 und 7–9): Die Bezeichner spk_1 und spk_2 sind willkürliche positionsbezogene Stimm-Tokens. Ein Editor muss die ersten Momente jedes Segments anhören, um die tatsächlichen Identitäten festzustellen: beispielsweise um sicherzustellen, dass in Teil 1 spk_1 Alexey entspricht und spk_2 Mikhail.
2. Sprecherwechsel und kurze Einwürfe (Zeile 6): Das Wort „Да,“ ist dem Turn von spk_1 zugeordnet. In einem dynamischen Gespräch kann es sich dabei jedoch um ein bestätigendes Nicken oder eine zustimmende Rückmeldung des Zuhörers (spk_2) handeln. Die Schnittstellen von Sprecherwechseln erfordern gezielte auditive Kontrollen.
3. Phonetische Schreibweise nicht erkannter Markennamen (Zeile 3): Bei deaktiviertem custom_vocabulary können englische Fachbegriffe oder Markennamen phonetisch transkribiert werden (z. B. ДатаПульс). Ein Editor muss solche Vorkommen auf ihre kanonische Schreibweise anpassen: DataPulse.
4. Verbot blindem globalen Ersetzens: Terminologische Korrekturen müssen stets punktuell und kontextbezogen vorgenommen werden. Globale „Suchen-und-Ersetzen“-Operationen im gesamten Dokument bergen die Gefahr, ähnlich klingende alltägliche Wörter, Redewendungen oder Zitate zu verfälschen.
5. Verzögerungslaute und Füllwörter (Zeile 8): Im verbatim-Modus werden Zögerlaute wie „э-э-э“ explizit erfasst. In einem bereinigten Meeting-Protokoll werden diese gestrichen. Für Videountertitel hingegen muss deren Timing beibehalten werden, wenn die Untertitelung synchron zur sichtbaren Lippenbewegung auf dem Bildschirm erfolgen soll.

---

Protokoll für Stichprobenprüfungen vor der Weitergabe

Aus der programmatischen Zusammenführung resultierende Rohdaten müssen ein fokussiertes Qualitätsaudit an drei Prüfpunkten durchlaufen:

1. Sprecher und Gesprächsgrenzen verifizieren: Hören Sie stichprobenartig 15–20 Sekunden Audio an 2–3 Sprecherwechseln ab. Vergewissern Sie sich, dass unterschiedliche Stimmen nicht zu einem einzelnen Sprecher verschmolzen sind und zusammenhängende Monologe nicht in Phantom-Labels zerlegt wurden. Laut offizieller Dokumentation ist die Diarisierung bei Meetings mit drei oder mehr Teilnehmern experimentell und erfordert eine deutlich strengere Überprüfung.
2. Terminologie, Zahlenwerte und benannte Entitäten prüfen: Erstellen Sie eine gezielte Checkliste wichtiger Projektnamen (DataPulse, CloudForge, Versionsnummern, Budgetzuweisungen). Suchen Sie nach diesen Begriffen im Text und gleichen Sie unklare Stellen direkt mit der Audioaufnahme ab, ohne pauschale Massenersetzungen vorzunehmen.
3. Kontinuität der Zeitleiste über Segmentgrenzen hinweg validieren: Vergleichen Sie die erste Minute von Teil 1 mit dem Übergang zu Teil 2 (unmittelbar nach der Marke von 25:00 bzw. 1500.0 Sekunden). Stellen Sie sicher, dass die Zeitstempel des zweiten Segments die Zeitleiste nahtlos fortführen, statt wieder bei null zu beginnen.

---

Weitergabe an Folgesysteme und Abbruchbedingungen

Die vom Skript erzeugten Dateien meeting_transcript.txt und word_timestamps.json entstehen vor dem prüfenden Abhören und müssen strikt als vorläufige Entwürfe behandelt werden. Übergeben Sie diese niemals im Rohzustand. Führen Sie zunächst das manuelle Prüfprotokoll durch, gleichen Sie Sprecheridentitäten, Begriffe und Zeitversätze mit der Audioaufnahme ab, korrigieren Sie die Daten (durch Aktualisieren der Code-Parameter und erneuten Durchlauf oder durch direkte Bearbeitung der Dateien) und geben Sie erst dann verifizierte Kopien weiter:

• Für Protokollanten oder LLM-Zusammenfassungen (Note Taker / LLM Summarization): Übergeben Sie eine verifizierte Kopie des Meeting-Transkripts — ein geprüftes Dokument mit bestätigter Sprecherzuordnung und bereinigten Fachbegriffen. Dieses dient als Fundament für Management-Zusammenfassungen und Beschlussprotokolle, stellt für sich allein jedoch noch keine automatisierte Liste von Action Items dar.
• Für Video-Cutter oder Untertitel-Spezialisten (Caption Editor): Übergeben Sie eine verifizierte Kopie des Wort-Zeitstempel-Arrays — eine geprüfte Sequenz von Wörtern mit durchgehenden Zeitstempeln. Spezifische Gestaltungsregeln (maximale Anzeigedauer, Zeilenlängenbegrenzungen, Lesegeschwindigkeit) hängen von Zielplattform, Videoplayer und Sprache ab, woraufhin ein dediziertes Konvertierungstool die finalen .srt- oder .vtt-Untertiteldateien generiert.

Abbruchbedingungen des Prozesses (Stop Conditions)

Unterbrechen Sie den Arbeitsablauf und leiten Sie keine Dateien an nachgelagerte Teams weiter, wenn mindestens eine der folgenden Bedingungen zutrifft:

1. Eine Audiodatei mit mehr als 30 Minuten Länge wurde ohne vorherige Segmentierung für Diarisierung oder Wort-Zeitstempel eingereicht (dies überschreitet die dokumentierten API-Limits und darf nicht übermittelt werden).
2. Vorläufige Entwurfsdateien (meeting_transcript.txt oder word_timestamps.json) wurden unmittelbar nach Ausführung des Skripts ohne stichprobenartiges Gegenhören und manuelle Prüfung an nachgelagerte Abnehmer weitergeleitet.
3. Sprecher-Labels im zweiten Segment wurden blind anhand der Label-Nummern des ersten Segments zugeordnet, ohne die Audioaufnahme anzuhören, oder es verbleiben unaufgelöste Sprecherkennungen im Datensatz.
4. Die tatsächliche physische Dauer des ersten Segments wurde nicht zur Zeitleiste des zweiten Segments addiert oder es wurden fehlende Wort-Zeitstempel festgestellt.
5. Es wurden wahllose globale „Suchen-und-Ersetzen“-Aktionen auf Begrifflichkeiten angewendet, ohne den Kontext zu validieren, oder kritische Konfigurationsparameter und numerische Angaben wurden nicht anhand der Aufnahme gegengeprüft.