Irgendwo auf dem Büro-Server liegt die Vorlage für das Besprechungsprotokoll. Oder war es der freigegebene Ordner? Und wie hieß die Datei nochmal — „Protokoll_Vorlage_NEU_v3_final.docx“?
Wer kennt das nicht: Die Suche findet zwar Wörter im Dokumentinhalt – aber keine Synonyme. Wer „Auto“ eintippt, findet kein Dokument, das nur „Dienstwagen“ enthält. Auf Netzlaufwerken funktioniert die Suche zudem oft nur eingeschränkt, weil der Windows-Suchindex dort in der Standardeinstellung nicht greift.
Ich habe dieses Problem zum Anlass genommen, ein eigenes Tool zu bauen – per Vibe-Coding, also mit KI-Unterstützung und ohne Programmierkenntnisse.
Per Vibe-Coding erstellt: eine lokale Webapp, die Dokumente einliest, per KI einen Index erstellt und dann per Volltextsuche durchsuchbar macht (Symbolbild; Collage: Internet für Architekten)
Das Ergebnis ist der Dokument-Indexer: eine lokale Webapp, die einen Ordner mit Dokumenten einliest, per KI einen intelligenten Index erstellt und dann per Volltextsuche durchsuchbar macht. Vollständig lokal, datenschutzfreundlich, kostenlos.
Dieser Artikel beschreibt, wie das Tool funktioniert, wie es entstanden ist – und wie Sie sich etwas Ähnliches selbst bauen können.
Das Prinzip: KI beim Indexieren, klassische Suche beim Finden
Der Dokument-Indexer teilt seine Arbeit klar auf.
- Tab 1 ist für die Indexierung zuständig: Sie ziehen einen Ordner in die Webapp, und die KI liest jedes Dokument und erstellt einen kompakten Eintrag mit Dokumenttyp, Kurzbeschreibung und Schlagworten.
- Tab 2 ist für die Suche zuständig – und dort kommt keine KI mehr zum Einsatz, sondern klassische Volltextsuche.
Das ist eine bewusste Entscheidung. KI ist gut darin, Inhalte zu verstehen, Synonyme zu erkennen und Schlagworte zu vergeben. Klassische Suche ist gut darin, zuverlässig, schnell und deterministisch zu arbeiten. Beide Stärken kombiniert ergeben ein Tool, das besser funktioniert als jeder der beiden Ansätze allein.
In Tab 1 wird die Indexierung durchgeführt: Ordner in die Webapp ziehen, und die KI liest jedes Dokument (Screenshot: Internet für Architekten)
Ein Beispiel: Das Dokument „Besprechungsraum_Fahrzeugordnung.docx“ enthält Regeln zu Besprechungsräumen und Dienstfahrzeugen. Die KI vergibt beim Indexieren unter anderem die Schlagworte Besprechung, Raum, Meeting, Konferenz, Fahrzeug, Auto, PKW, Dienstwagen, Buchung, Reservierung. Wer später „Meeting buchen“ sucht, findet dieses Dokument — obwohl das Wort „Meeting“ im Originaldokument gar nicht vorkommt.
Zwei Suchwege, ein Ergebnis
Die App durchsucht parallel zwei Quellen: den KI-erstellten Index und den vollständigen Originaltext jedes Dokuments.
Beim Indexieren speichert die App den von MarkItDown (Microsoft) extrahierten Text als JSON-Datei neben dem Index. Bei der Suche werden beide Quellen ausgewertet.
Das löst ein strukturelles Problem: Selbst der beste KI-Prompt kann nicht garantieren, dass jedes relevante Schlagwort im Index landet.
In Tab 2 wird gesucht: sowohl über den von der KI erstellten Index als auch per Volltextsuche (Screenshot: Internet für Architekten)
Was die KI vergisst, findet die Volltextsuche trotzdem – weil das Wort im Originaldokument steht. Volltext-Treffer werden in den Ergebnissen mit einem eigenen Badge gekennzeichnet, damit erkennbar ist, woher der Treffer stammt.
Die Suche normalisiert außerdem Umlaute (ä/ö/ü), arbeitet mit Stammformen („buchen“ findet „Buchung“) und unterstützt Multi-Wort-Anfragen: Wer „raum buchen“ eintippt, bekommt nur Dokumente, in denen beide Begriffe vorkommen.
Für Planungsbüros: Projektnummern und Leistungsphasen
Der Dokument-Indexer ist kein generischer Filesearch-Klon. Er enthält zwei Features, die speziell für Architektinnen und Architekten gedacht sind.
Projektnummer-Erkennung: Die App erkennt beim Indexieren automatisch Projektnummer-Muster im Dateipfad – Formate wie „2024-187″, „24-042″, „187_Schulneubau“ oder „P-201″. Das Schlagwort „Projekt 2024-187″ wird automatisch zum Index-Eintrag hinzugefügt. Wer nach dieser Nummer sucht, findet alle indizierten Dokumente des Projekts.
LPH-Filter: In Tab 2 erscheint unterhalb des Suchfelds eine Leiste mit den Leistungsphasen LPH 1 bis LPH 9. Die Zuordnung erkennt die App aus dem Dateipfad – „LPH5 Ausführungsplanung“, „03 Entwurf“ oder „08 Bauüberwachung“ werden automatisch ausgewertet. Treffer zeigen ein blaues LPH-Badge. Wer gezielt nur Ausführungsunterlagen durchsuchen möchte, wählt LPH 5 und die Ergebnisliste zeigt ausschließlich Dokumente aus dieser Phase.
Hilfreiche Zusatzfunktion für den Einsatz im Planungsbüro: Über den „LPH-Filter“ können Dokumente je nach HOAI-Leistungsphase gefiltert werden (fiktive Projektdaten; Screenshot: Internet für Architekten)
Was unter der Haube steckt
Das Tool besteht aus drei Komponenten, die lokal zusammenarbeiten:
- MarkItDown (Microsoft, Open Source): Extrahiert den reinen Text aus PDF, Word, Excel, PowerPoint und weiteren Formaten.
- Ollama: Die Laufzeitumgebung für lokale KI-Modelle. Nach der Installation läuft sie im Hintergrund.
- Gemma 3:4b (Google, Open Weights): Das Sprachmodell, das die Indexeinträge erstellt. Es läuft vollständig lokal, keine Daten verlassen den Rechner.
Die Webapp selbst ist in Python mit Flask geschrieben und läuft auf localhost:5050. Wichtig für die Einordnung: Gemma 3 wird von Google als „Open Weights“ veröffentlicht, nicht als vollständig quelloffene Software. Die Modellgewichte sind frei verfügbar und für kommerzielle Nutzung freigegeben – Einblick in den vollständigen Trainingsprozess besteht jedoch nicht.
Eine Erkenntnis zwischendurch: Ein neueres LLM ist nicht unbedingt besser geeignet
Während der Entwicklung des Tools habe ich auch Gemma 4 getestet, das Google am 02. April 2026 veröffentlicht hat. Das Ergebnis war bei meinem Anwendungsszenario aber durchwachsen: Gemma 4 brauchte deutlich länger als Gemma 3, und die Indexqualität war schlechter – der von der KI für jede Datei vergebene Dokumenttyp beispielsweise lautete bei mehreren Einträgen schlicht „Index-Eintrag“, die vergebenen Schlagworte blieben abstrakt statt konkret.
Für kurze, präzise Indexeinträge ist Gemma 3:4b in meinem Setup dem größeren Nachfolger derzeit überlegen. Das zeigt: Beim Vibe Coding gehört Testen zur Methode. Man beschreibt nicht nur, was man will – man prüft, ob das Ergebnis wirklich liefert.
Was das Tool (noch) nicht kann
Drei Einschränkungen des von mir erstellten Dokument-Indexer sollten klar benannt werden:
Gescannte PDFs: MarkItDown extrahiert Text aus digitalen PDFs, nicht aus eingescannten Dokumenten ohne Texterkennung. Altpläne oder eingescannte Verträge werden dadurch z. B. nicht indexiert.
GAEB-Dateien: Das im deutschen Bauwesen verbreitete Austauschformat für Leistungsverzeichnisse wird von MarkItDown nicht unterstützt.
Excel mit komplexer Struktur: Tabellenblätter mit verschachtelten Ebenen oder PivotTables werden manchmal nur unvollständig extrahiert.
Aber: Dass das in meiner Version des Indexer-Tools nicht funktioniert, heisst natürlich nicht, dass es unmöglich ist. Sicher lässt sich z. B. mit OCR-fähigen Komponenten auch eine Lösung zum Extrahieren von PDFs mit eingescannten Inhalten realisieren.
Vibe-Coding: So ist das Tool entstanden
Der Dokument-Indexer ist in enger Zusammenarbeit mit Claude (Anthropic) entstanden, ohne dass ich eine Zeile Code selbst geschrieben hätte. Das Konzept, die Architektur, alle Versionen von 1.0 bis 1.7: entstanden im Dialog. Ich habe beschrieben, was ich will, die KI hat Code vorgeschlagen, ich habe getestet, Fehler gemeldet, nachgesteuert.
Vibe-Coding bezeichnet genau diesen Ansatz: Software entwickeln durch beschreiben statt durch programmieren. Es ist kein Ersatz für Programmierkenntnisse bei komplexen Systemen. Aber für klar umrissene Werkzeuge, die einen konkreten Bürobedarf lösen, funktioniert es überraschend gut.
Selbst ausprobieren: So gehen Sie vor
Wenn Sie sich von diesem Artikel inspirieren lassen und etwas Ähnliches selbst bauen möchten, brauchen Sie keine Vorkenntnisse – aber eine klare Vorstellung davon, was Ihr Tool können soll.
Genau das ist beim Vibe-Coding die eigentliche Arbeit: nicht das Programmieren, sondern das präzise Beschreiben.
Wichtig: Zwei der im Folgenden vorgestellten vier Schritte erfolgen im Terminal – einem mächtigen Werkzeug, mit dem man bei falschen Befehlen auch Schaden anrichten kann. Führen Sie daher nur Befehle aus, die Sie verstehen und nachvollziehen können. Wer damit nicht vertraut ist, sollte diesen Teil gemeinsam mit einer fachlich versierten Person oder anhand einer Schritt-für-Schritt-Anleitung durchführen.
Als Einstieg empfehle ich folgenden Ablauf:
1. Voraussetzungen installieren. Sie benötigen Ollama mit einem lokalen Modell (für diese Aufgabe empfehle ich Gemma 3:4b) sowie Python 3 mit Flask. Beides ist kostenlos und für Mac und Windows verfügbar.
2. Das Gespräch beginnen. Öffnen Sie Claude, ChatGPT oder einen anderen Chatbot Ihrer Wahl und beschreiben Sie, was Sie bauen möchten. Konkret und ohne Fachbegriffe – so als würden Sie es einem neuen Mitarbeitenden erklären. Ein guter Einstieg könnte so aussehen:
„Ich möchte eine einfache lokale Webapp bauen, die einen Ordner mit Bürodokumenten einliest. Für jedes Dokument soll ein KI-Modell (Gemma 3:4b via Ollama) eine kurze Beschreibung und Schlagworte erstellen. Die Ergebnisse sollen in einer Textdatei gespeichert werden, die ich durchsuchen kann. Die App soll im Browser laufen und möglichst einfach zu starten sein. Ich habe keine Programmierkenntnisse.“
3. Iterieren, nicht perfektionieren. Die erste Version wird nicht fertig sein – und das ist in Ordnung. Lassen Sie die App laufen, testen Sie sie mit echten Dokumenten, und beschreiben Sie dem Chatbot dann, was nicht funktioniert oder was Sie noch brauchen. „Die Suche findet ‚Raum‘ nicht wenn das Wort in ‚Besprechungsraum‘ steckt“ ist eine präzise Fehlerbeschreibung, mit der ein KI-Modell gut arbeiten kann.
4. Schritt für Schritt erweitern. Fangen Sie mit dem Kern an: Dokument einlesen, Index erstellen, speichern. Fügen Sie dann eine Suchfunktion hinzu. Dann vielleicht eine bessere Oberfläche. Jede Erweiterung ist ein neuer Austausch mit dem Chatbot.
Was Sie dabei lernen, ist nicht Python. Es ist das Denken in Anforderungen: Was soll das Tool genau tun? Was ist ein Treffer, was nicht? Welche Grenzfälle gibt es?
Diese Klarheit ist die eigentliche Kompetenz beim Vibe-Coding – und sie ist im Büroalltag von Planenden ohnehin gefragt.
Aktuelle Webinare, Online-Seminare und Livestreams
« Zurück zum Webinar-Kalender
Wichtige Hinweise: Die Vollständigkeit und Richtigkeit der hier aufgeführten Daten können wir leider nicht garantieren. Bitte überprüfen Sie alle Angaben immer auf den Seiten der jeweiligen Anbieter. Und: „Internet für Architekten“ ist NICHT der Veranstalter der hier genannten Webinare. Wir weisen hier lediglich auf diese Veranstaltungen hin.