Spracherkennung im Besprechungsraum

Wir haben vier Wochen lang jede interne Besprechung mitschreiben lassen, auf einem Rechner im Raum, ohne dass etwas an einen Anbieter geht. Danach haben wir gefragt, ob jemand die Mitschriften überhaupt liest. Die Antwort war aufschlussreicher als die Technik. Dieser Beitrag beschreibt, womit wir mitgeschrieben haben, was gut lief, an welchen drei Stellen es geklemmt hat und welche Entscheidung am Ende stand.

Werkzeug, Zeitraum, Aufgabe

Das Werkzeug ist Whisper, das offene Spracherkennungsmodell von OpenAI, in der Fassung faster-whisper. Die läuft auf dem Prozessor eines normalen Laptops, braucht keine Grafikkarte und lädt das Modell einmal herunter. Danach ist sie ohne Netz nutzbar. Das ist der Grund, warum wir sie überhaupt genommen haben: Interne Besprechungen enthalten Kundennamen, Zahlen und Personalthemen, und die wollten wir nicht an einen Dienst schicken, dessen Auftragsverarbeitungsvertrag wir erst hätten lesen müssen. Der Beitrag zu lokalen Modellen beschreibt, was dieser Unterschied im Alltag bedeutet.

Der Aufbau ist klein: Ein Laptop im Besprechungsraum nimmt mit dem eingebauten Mikrofon oder einem Tischmikrofon auf. Nach der Besprechung wandelt afconvert die Aufnahme in eine wav-Datei, und ein Python-Skript macht daraus den Rohtext. Der Rohtext landet im Projektordner, benannt nach der Konvention aus dem Beitrag zur Ordnerstruktur, also mit Datum vorn. In den ersten zwei Wochen lief zusätzlich ein zweiter Schritt: Ein lokales Sprachmodell über Ollama fasste die Mitschrift zusammen und schrieb eine Aufgabenliste. Den haben wir nach zwei Wochen abgeschaltet, dazu unten mehr.

Vorher gesagt haben wir allen, die im Raum sitzen, dass mitgeschnitten wird. Das ist keine Höflichkeit, sondern § 201 StGB: Wer das nichtöffentlich gesprochene Wort ohne Einwilligung aufnimmt, macht sich strafbar. Bei uns hängt ein Zettel an der Tür, und wer eine Besprechung nicht aufgenommen haben will, sagt das, und dann bleibt der Laptop zu.

Voraussetzungen für den Nachbau:

• Python 3.12 und faster-whisper (pip3 install faster-whisper), geprüft mit Version 1.2.1
• das Whisper-Modell small, rund 480 MB, das beim ersten Lauf geladen wird. Für medium sind es rund 1,5 GB
• für die Zusammenfassung: Ollama mit einem lokalen Modell, bei uns llama3.2 mit drei Milliarden Parametern
• ein Rechner, auf dem die Aufnahme liegen darf. Kosten: keine, außer der Zeit

Was gut lief

Die reine Worterkennung ist kein Thema mehr. Bei einer Person am Mikrofon und ruhigem Raum ist der Text so genau, dass Korrekturlesen sich nicht lohnt. Wer die Mitschrift eine Woche später öffnet, um nachzusehen, was zum Thema Serverspeicher gesagt wurde, findet die Stelle über die Suchfunktion und liest den Satz, wie er gefallen ist.

Um das für diesen Beitrag nachvollziehbar zu machen, haben wir am 18. September 2026 eine Aufnahme mit einer Sprecherin erzeugt und durch dasselbe Skript geschickt, das im Besprechungsraum läuft. 42 Sekunden Aufnahme, drei Themen, ein offener Punkt. Das Modell small brauchte dafür 6,8 Sekunden auf dem Prozessor. Von 108 Wörtern war jedes richtig erkannt, bis auf die Eigennamen. Das ist der Punkt, an dem es klemmt.

Wo es klemmt

Drei Stellen, jede mit einem Vorfall.

Sobald zwei Leute durcheinanderreden, verschwimmt die Zuordnung

Whisper schreibt einen Textstrom, keine Sprecher. Solange nacheinander gesprochen wird, ist das erträglich, weil man aus dem Inhalt schließt, wer gerade redet. Sobald zwei Leute gleichzeitig anfangen, was in einer Besprechung mit fünf Personen alle paar Minuten passiert, entsteht ein Satz, der aus den Hälften von zwei Sätzen besteht. Der ist grammatisch oft in Ordnung und inhaltlich falsch. In unseren Mitschriften standen so Sätze, die niemand gesagt hatte, zusammengesetzt aus zwei Gesprächen, die gleichzeitig liefen. Das fällt nur auf, wenn jemand dabei war.

Werkzeuge zur Sprechertrennung gibt es, sie brauchen aber ein zweites Modell, meist eine Anmeldung bei Hugging Face und deutlich mehr Rechenzeit. Wir haben sie nicht eingesetzt und behaupten deshalb nichts über ihre Qualität.

Eigennamen und Projektkürzel werden geraten, jedes Mal anders

Das Modell kennt unsere Kunden nicht. Es hört einen Namen und schreibt das Wort, das am ähnlichsten klingt. Das wäre erträglich, wenn es wenigstens immer dasselbe falsche Wort wäre, dann könnte man es per Suchen und Ersetzen korrigieren. Ist es aber nicht. In unserem Lauf vom 18. September kam der Name Özdemir in zwei Aufnahmen zweimal verschieden heraus:

Aufnahme 1, 12 Sekunden, ohne Initial-Prompt:
[   0.0s] Wir besprechen heute den Stand beim Projekt Lindgruber.
[   3.2s] Die Bauertechnik hat die Unterlagen für das Angebot noch nicht geschickt.
[   8.1s] Andreas kümmert sich bis Freitag um die Rückfrage bei Frau Öztemehr.

Aufnahme 2, 42 Sekunden, ohne Initial-Prompt, Auszug:
[   4.4s] Die Bauerelektrotechnik hat die Unterlagen für das Angebot noch nicht geschickt, deshalb
[  12.6s] Andreas fragt bis Freitag bei Frau Oeste mehr nach.
[  18.9s] Da ist die Frage offen, ob wir die E-Rechnung über den N8N-Aplauf laufen lassen oder

„Öztemehr“ und „Oeste mehr“ für dieselbe Person, „Bauertechnik“ und „Bauerelektrotechnik“ für dieselbe Firma. Im Besprechungsraum war es über vier Wochen genauso: Derselbe Kunde tauchte in den Mitschriften unter mehreren Schreibweisen auf. Wer nach ihm sucht, findet nur einen Teil der Stellen.

Die Zusammenfassung nennt Aufgaben, die niemand übernommen hat

Das ist der Vorfall, der zur Entscheidung geführt hat. In den ersten zwei Wochen lief nach der Mitschrift ein lokales Sprachmodell mit dem Auftrag, zusammenzufassen und die Aufgaben mit Verantwortlichem und Frist aufzulisten. Die Liste sah jedes Mal ordentlich aus. Und jedes Mal stand etwas darin, das niemand zugesagt hatte.

Wir haben das am 18. September mit der 42-Sekunden-Aufnahme nachgestellt. Gesagt wurde darin genau eine Zusage: Andreas fragt bis Freitag bei Frau Özdemir nach. Zwei Themen blieben ausdrücklich offen. Das Modell llama3.2 mit dem Auftrag „Fasse zusammen und liste alle Aufgaben mit Verantwortlichem und Frist auf“ lieferte diese Aufgabenliste:

* Andreas: Sich bei Frau Özdemir bis Freitag erkundigen, ob die Unterlagen
  für das Angebot der Bauer Elektrotechnik eingegangen sind.
* Frau Özdemir: Die Unterlagen für das Angebot der Bauer Elektrotechnik
  weiterleiten.
* Nächstes Wochenende: Die Frage nach der E-Rechnung in der
  Kernhausverwaltung nochmal besprechen.
* Nächstes Wochenende: Die Frage nach dem Server für Ollama nochmal
  besprechen und eine Entscheidung treffen.

Die erste Zeile stimmt. Die zweite ist erfunden: Frau Özdemir saß nicht im Raum und hat nichts zugesagt. Die dritte macht aus „nächste Woche“ ein „nächstes Wochenende“. Die vierte hängt an ein Thema, das ohne Termin vertagt wurde, einen Termin und eine Entscheidung. Eine Aufgabe von vier ist richtig. Wer so eine Liste an das Team schickt, erzeugt drei Nachfragen und eine verärgerte Kundin.

Man kann einwenden, dass ein größeres Modell weniger erfindet. Das haben wir in den zwei Wochen probiert, und die Listen wurden besser, aber nicht verlässlich. Das Problem ist nicht die Modellgröße, sondern die Aufgabe: Aus einer Mitschrift, in der Leute laut denken, soll eine Maschine entscheiden, was eine Zusage war. Das können die Leute im Raum manchmal selbst nicht.

Unser Fazit

Wir lassen weiter mitschreiben. Die Zusammenfassung mit den Aufgaben haben wir abgeschaltet. Eine Liste, der man nicht trauen kann, ist schlechter als gar keine, weil sie so aussieht, als könnte man ihr trauen.

Was bleibt, ist der Rohtext mit Zeitmarken, unter Datum und Thema im Projektordner. Wer nach einer Woche wissen will, was zum Speicher des Ollama-Servers gesagt wurde, sucht das Wort und liest die Stelle. Das ist der Nutzen, und er ist real: Nach unserer Umfrage hat die Mitschrift geöffnet, wer einen konkreten Satz nachlesen wollte. Von vorn bis hinten gelesen hat sie niemand. Das muss sie auch nicht.

Die Zusagen schreibt seither wieder ein Mensch auf, während der Besprechung, in drei Zeilen: Wer, was, bis wann. Den Ablauf, der aus so einer Mitschrift ein Protokoll mit Zusagen macht, beschreibt der Beitrag zum Protokoll aus der Besprechung, und dort steht auch, warum der Schritt von der Mitschrift zur Zusage der schwierige ist.

Eine Zusammenfassung ohne Aufgabenliste haben wir als Prompt behalten, für den Fall, dass jemand einen Überblick will. Ehrlich gesagt hat sie in unserem Lauf vom 18. September auch nicht sauber funktioniert: Trotz der Anweisung, keine Zuweisungen zu nennen, stand „Andreas fragt bis Freitag bei Frau Özdemir nach“ in der Zusammenfassung, und aus dem zu kleinen Speicher wurde ein Server, der „nicht ins Modell passt“. Bei einem Modell mit drei Milliarden Parametern ist das zu erwarten. Der Prompt liegt im Paket, weil er die Regeln festhält, die wir für richtig halten. Verlassen würden wir uns auf die Ausgabe nicht.

Zum Nachbauen

Das Paket zu diesem Beitrag enthält das Mitschrift-Skript, die Vorlage für die Projektnamen-Liste, den Prompt für die Zusammenfassung ohne Aufgaben und den Auswertungsbogen, mit dem wir die vier Wochen bewertet haben. Entpacken, faster-whisper installieren, dann:

• mitschrift.py: Aufnahme zu Rohtext mit Zeitmarken. Mit --projektnamen projektnamen.txt wird die Liste zum Initial-Prompt, mit --zusammenfassen läuft danach Ollama mit dem Prompt aus dem Paket. Modell über WHISPER_MODELL und MODELL wählbar
• projektnamen.beispiel.txt: nach projektnamen.txt kopieren, eigene Kunden, Projekte, Kürzel eintragen, ein Name je Zeile
• prompts/zusammenfassung_ohne_aufgaben.md: die Systemanweisung, ausdrücklich ohne Aufgaben, Fristen und Zuweisungen
• auswertungsbogen.md: ein Bogen je Besprechung. Nach vier Wochen steht darauf, ob jemand die Mitschrift gebraucht hat, und das ist die Frage, die zählt

Eine Testaufnahme für den ersten Lauf erzeugt ihr auf dem Mac mit say und afconvert, die zwei Befehle stehen in der README. So sind auch die Aufnahmen in diesem Beitrag entstanden.

Stand dieses Artikels

Die vier Wochen im Besprechungsraum liegen vor diesem Beitrag; die Beobachtungen daraus (Durcheinanderreden, wechselnde Schreibweisen der Kunden, erfundene Aufgaben in den ersten zwei Wochen) sind Erfahrung, keine Messung. Die Zahlen und Ausgaben im Beitrag stammen aus Läufen am 18. September 2026 mit Python 3.12.2, faster-whisper 1.2.1, Whisper-Modell small auf dem Prozessor eines Mac (compute_type int8), Ollama mit llama3.2 (3B). Die Aufnahmen sind mit der Systemstimme Anna aus say erzeugt, also eine einzelne, saubere Sprecherin ohne Raumhall. Das ist der beste Fall; echte Besprechungen sind schlechter. Nicht geprüft am 18. September: das Modell medium, mehrere Sprecher, Aufnahmen mit Hintergrundgeräusch. Nicht eingesetzt: Sprechertrennung.

Häufige Fragen