This commit significantly improves the robustness and determinism of the Meeting Lab processing pipeline and establishes the first Release Candidate baseline for end-to-end evaluation. Highlights - BUG-009 - Implement deterministic responsible-party validation - Normalize participant aliases using Meeting Context - Reject invalid responsible values (dates, locations, technical terms, projects, products, unknown entities) - Record structured responsibility validation metadata - Add focused regression tests - BUG-010 - Implement adaptive num_predict estimation for Semantic Consolidator - Eliminate JSON truncation caused by fixed output limits - Add deterministic source coverage repair - Preserve strict post-repair validation - Add regression tests - BUG-011 - Implement Working Protocol V2 renderer contract enforcement - Preserve raw renderer responses - Reject invalid protocol output instead of accepting malformed documents - Add deterministic cleanup for harmless formatting deviations - Add focused renderer regression tests - Meeting Context - Validate Meeting Context V1 - Integrate authoritative participant alias normalization - Documentation - Update architecture documentation - Update output documentation - Update regression bug tracker The pipeline now fails safely instead of silently accepting invalid intermediate or final artifacts. Remaining work focuses primarily on extraction quality and semantic classification (decisions, action items, protocol faithfulness), rather than pipeline robustness.
Meeting Lab
Experimentierumgebung zur Entwicklung eines lokalen Diskussionsanalyzers für Meetingtranskripte.
Ziel
Das Meeting Lab dient dazu, Verfahren zur Analyse realer Meetingtranskripte zu entwickeln und zu evaluieren.
Im Mittelpunkt steht nicht die Softwarearchitektur, sondern die Frage:
Wie lässt sich aus einem realen Meeting möglichst zuverlässig strukturiertes Wissen extrahieren?
Neue Ideen werden zunächst hier experimentell umgesetzt. Erst wenn sich ein Ansatz bewährt hat, wird er in den eigentlichen Meeting Assistant übernommen.
Grundidee
Klassische Meeting-Zusammenfassungen versuchen, das gesamte Transkript in einem einzigen Schritt zu verstehen und zusammenzufassen.
Das funktioniert bei realen Diskussionen nur eingeschränkt, da Themen häufig
- begonnen,
- unterbrochen,
- später wieder aufgenommen,
- ergänzt oder
- relativiert
werden.
Deshalb verfolgt das Meeting Lab einen mehrstufigen Analyseansatz.
Meeting
↓
Normalisierung
↓
Diskussionsblöcke
↓
Themensegmentierung
↓
Extraktion
↓
Deterministic Canonicalizer
↓
Semantic Consolidator
↓
Canonical Meeting Knowledge
↓
Arbeitsprotokoll / Verteilerprotokoll / Knowledge Objects
Jeder Verarbeitungsschritt löst genau eine klar definierte Aufgabe.
Entwicklungsprinzipien
- Kleine, klar abgegrenzte Verarbeitungsschritte
- Ein Modul = eine Aufgabe
- Deterministische Vorverarbeitung
- Nachvollziehbare Ergebnisse
- Reproduzierbare Experimente
- Lokale Ausführung ohne Cloud-Abhängigkeit
Repository-Struktur
meeting-lab/
├── src/ # Quellcode
├── prompts/ # LLM-Prompts
├── experiments/ # Reproduzierbare Experimente
├── samples/ # Beispieltranskripte
├── tests/ # Tests
├── docs/ # Dokumentation
└── pyproject.toml
Aktuelle Pipeline
Whisper
↓
normalize_transcript.py
↓
chunk_transcript.py
↓
(segment_topics.py)
↓
Extraktoren
↓
Deterministic Canonicalizer
↓
Semantic Consolidator
↓
Canonical Meeting Knowledge
↓
Output-Ansichten
Der aktuelle Architekturmeilenstein trennt deterministische Kanonisierung der Chunk-Extraktionen von semantischer Konsolidierung. Die Kanonisierung validiert und normalisiert Extraktionsobjekte ohne LLM. Semantic Consolidator V0 nutzt das lokale LLM nur fuer konservative facts-only Duplikaterkennung, erhaelt Evidenz und erzeugt noch keine Canonical Meeting Knowledge.
Meeting Context V1 ist als manuell gepflegtes YAML-Geruest dokumentiert und fuer die Chunk-Extraktion implementiert. Die Extraktion kann den Kontext optional validieren, als autoritative Metadaten in den Prompt aufnehmen und minimale Kontext-Provenienz im Extraction JSON speichern. Konsolidierung, Canonical Meeting Knowledge und Rendering sind noch nicht daran angeschlossen.
Als akzeptierte, aber noch nicht implementierte Architektur soll Meeting
Context V2 kuenftig nicht mehr primaer manuell geschrieben werden. Nach Whisper
soll ein Entity-Detection- und User-Confirmation-Schritt unbekannte Namen und
Begriffe sichtbar machen. Bestaetigte Entitaeten werden in einer persistenten
Entity Registry als cross-meeting Wissensquelle mit stabilen internen IDs,
Anzeigenamen und Aliasen gepflegt. Aus Registry, Nutzerbestaetigungen und
Meeting-Metadaten erzeugt ein Meeting Context Builder dann das
meeting-spezifische meeting_context.yaml. Diese YAML-Datei bleibt der
authoritative meeting-spezifische Point of Truth und ein reproduzierbares
Input-Artefakt fuer den jeweiligen Pipeline-Lauf.
Der gemeinsame Extraktionsprompt besteht aktuell aus common.md,
decisions.md und todos.md. Die Todo-Regeln verlangen explizite Zuweisung,
Freiwilligenmeldung oder Annahme, bevor eine verantwortliche Person gesetzt
wird. Meeting Context kann Identitaet, Rolle, Abteilung und Anwesenheit
validieren, begruendet aber niemals Verantwortung. Entscheidungen und Todos
werden nicht aus derselben Proposition doppelt extrahiert; beides wird nur
ausgegeben, wenn eine gruppenweite Entscheidung und eine davon getrennte
Folgeaufgabe vorliegen.
Das Meeting Lab behandelt "das Protokoll" nicht mehr als ein einzelnes Endprodukt. Das konsolidierte Meeting-Wissen ist die Canonical Meeting Knowledge, also die kanonische semantische Repräsentation eines Meetings und die Single Source of Truth für alle nachgelagerten Ausgaben.
Aus dieser Canonical Meeting Knowledge entstehen drei unabhängige Output-Ansichten:
- Working Protocol (
working_protocol.md, Arbeitsprotokoll): relativ vollständig, mit Kontext, Begründungen, Entscheidungen, Aufgaben und offenen Fragen. - Distribution Protocol (
distribution_protocol.md, Verteilerprotokoll): deutlich kürzer, ergebnisorientiert und für Kolleginnen, Management oder Stakeholder geeignet. - Knowledge Objects, dargestellt zum Beispiel als Knowledge-base Entry
(
knowledge_entry.md) oder später strukturiert gespeichert, zum Beispiel alsknowledge_entry.json(Wissensdatenbankeintrag).
Diese Ausgaben sind parallele Renderings desselben semantischen Modells. Das Arbeitsprotokoll ist nicht die Quelle des Verteilerprotokolls, und das Verteilerprotokoll ist nicht die Quelle der Knowledge Objects.
Gerenderte Protokolle sollen normalerweise in der dominanten Sprache des Quelltranskripts beziehungsweise der konsolidierten Meeting Knowledge erstellt werden, sofern keine explizite Ausgabesprache angefordert wurde.
Projektstatus
Aktuell liegt der Schwerpunkt auf der Entwicklung eines modularen Diskussionsanalyzers. Implementiert sind Vorverarbeitung, technisches Chunking, lokale Chunk-Extraktion, Meeting Context V1 fuer die Extraktionsstufe, Canonicalizer V1 als deterministische Vorbereitung der Extraktionsergebnisse und Semantic Consolidator V0 fuer facts-only Duplikaterkennung. Canonical Meeting Knowledge, breitere semantische Synthese, Meeting-Context-Integration in spaetere Stufen und finale Output-View-Renderer sind geplante naechste Schritte.
Canonicalizer V1 kann aus dem Repository heraus so ausgeführt werden:
PYTHONPATH=src .venv/bin/python -m meeting_lab.consolidation.canonicalize \
samples/whisper/meeting_speech_cleaned_chunks \
-o /tmp/canonicalized_extractions.json
Semantic Consolidator V0 kann auf dem Canonicalizer-Output ausgefuehrt werden:
PYTHONPATH=src .venv/bin/python -m meeting_lab.consolidation.consolidate_facts \
samples/benchmarks/canonicalizer_v1/canonicalized_extractions.json \
-o samples/benchmarks/semantic_consolidator_v0 \
--model qwen3.5:9B \
--endpoint http://127.0.0.1:11434/api/generate \
--no-think
Die eigentliche Ausgabeerzeugung ist bewusst der letzte Verarbeitungsschritt.
Lizenz
Noch nicht festgelegt.