Interne KI mit RAG: Ein praxistaugliches Konzept für FM-Dienstleister
Mike Adler
Projektleiter Baseline & Digital PM @ Wisag
Letzte Woche hat mich ein Objektleiter angerufen. Er suchte seit 40 Minuten die Wartungsanleitung für eine RLT-Anlage. Das Dokument lag irgendwo auf dem Fileserver – vergraben zwischen 2.000 anderen PDFs, in einem Ordner, den vor drei Jahren jemand angelegt hat, dessen Namenslogik niemand mehr versteht. Am Ende hat er den Hersteller angerufen.
Das ist der Alltag im Facility Management. Und genau hier setzt eine Technologie an, die ich seit Monaten teste: Retrieval-Augmented Generation, kurz RAG – eine KI, die nicht im Internet sucht, sondern in euren eigenen Dokumenten.
Was RAG bedeutet – und was nicht
RAG – Retrieval-Augmented Generation – klingt kompliziert, ist im Kern aber simpel: Bevor die KI eine Antwort generiert, durchsucht sie zuerst eure internen Dokumente. Wartungsanleitungen, Verträge, Betriebshandbücher, Ticket-Historien – alles, was ihr in die Datenbank einspeist. Die KI antwortet dann auf Basis eurer Daten, nicht auf Basis ihres allgemeinen Trainings.
Der entscheidende Unterschied zu ChatGPT oder Claude im Browser: Die Daten verlassen euer Netzwerk nicht. Eine selfhosted RAG-Lösung läuft auf eurer eigenen Hardware. Das ist keine Spielerei – für einen FM-Dienstleister mit Kundendaten, Vertragsinformationen und Wartungsprotokollen ist das eine Grundvoraussetzung.
Was RAG nicht ist: eine magische Lösung, die ab Tag eins perfekt funktioniert. Die Qualität steht und fällt mit der Qualität eurer Dokumente und wie ihr sie aufbereitet. Dazu gleich mehr.
Die Architektur: Was ihr wirklich braucht
Nach monatelangem Testen verschiedener Setups ist das meine Empfehlung für einen mittelgroßen FM-Dienstleister:
LLM-Ebene – das Sprachmodell: Ollama als Inference-Server, darauf ein Llama 3 mit 8 Milliarden Parametern. Ollama ist Open Source, läuft stabil und braucht keine DevOps-Experten für die Einrichtung. Für den Einstieg reicht eine einzelne Grafikkarte – eine NVIDIA RTX 4060 Ti mit 16 GB Grafikspeicher kostet um die 500 Euro und liefert ausreichend Geschwindigkeit für 50 bis 100 gleichzeitige Nutzer.
RAG-Ebene – die Dokumentensuche: LlamaIndex für die Indexierung eurer Dokumente, kombiniert mit Qdrant als Vektor-Datenbank. LlamaIndex zerlegt eure PDFs, Word-Dokumente und Handbücher in sinnvolle Abschnitte und wandelt sie in numerische Repräsentationen um – sogenannte Embeddings. Qdrant speichert diese Embeddings und kann blitzschnell die relevantesten Dokumentenstellen finden, wenn eine Frage gestellt wird.
Alternative für den schnellen Start: Wer es erstmal ausprobieren will, nimmt Chroma statt Qdrant. Chroma läuft embedded, braucht keinen eigenen Server und ist in 30 Minuten einsatzbereit. Für einen Proof-of-Concept mit 50 bis 100 Dokumenten absolut ausreichend.
Benutzeroberfläche: Eine einfache Web-Oberfläche, über die Objektleiter, Techniker und Projektleiter ihre Fragen stellen können – ohne Kommandozeile, ohne technisches Vorwissen. Open-Source-Frameworks wie Open WebUI machen das möglich.
Der entscheidende Faktor: Dokumentenaufbereitung
Hier passieren 80 Prozent aller Fehler. Die meisten RAG-Projekte scheitern nicht am Sprachmodell oder an der Hardware – sie scheitern daran, wie Dokumente zerteilt werden.
Ein Beispiel: Ihr speist ein 50-seitiges Wartungshandbuch für eine Kälteanlage ein. Wenn das System das Dokument einfach alle 500 Wörter zerschneidet, landen zusammengehörige Informationen in verschiedenen Fragmenten. Die KI findet dann bei der Frage „Wie tausche ich den Kältemittelfilter?” einen Abschnitt über allgemeine Wartungsprinzipien – aber nicht die konkrete Anleitung auf Seite 34.
Die Lösung heißt semantisches Chunking: Dokumente werden nicht nach Zeichenzahl, sondern nach inhaltlichen Einheiten zerlegt. Jedes Kapitel, jeder Arbeitsschritt, jede Checkliste wird ein eigenes Fragment. LlamaIndex bietet dafür einen semantischen Splitter, der Überschriften und Absatzstrukturen erkennt.
Dazu kommt Metadaten-Filterung: Jedes Dokumentenfragment bekommt Tags – Anlagentyp, Standort, Hersteller, Dokumentenart. Wenn ein Techniker nach dem Kältemittelfilter fragt, durchsucht das System nicht 2.000 Dokumente, sondern nur die mit dem Tag „Kältetechnik”. Das verbessert die Trefferquote drastisch.
Kosten und ehrliche Einschätzung
Für einen Proof-of-Concept mit 50 bis 100 Dokumenten braucht ihr: einen Rechner mit Grafikkarte (ab 500 Euro Hardware), Ollama und LlamaIndex (kostenlos, Open Source), und einen halben Tag Einrichtungszeit, wenn jemand im Team sich mit Linux und Docker auskennt.
Für eine produktive Lösung mit 500 und mehr Nutzern sieht die Rechnung anders aus: Hardware für circa 5.000 bis 8.000 Euro, plus laufende Kosten von 500 bis 800 Euro im Monat für Strom und Wartung, plus – und das ist der größte Posten – eine halbe bis ganze Stelle für jemanden, der das System pflegt, Dokumente aktualisiert und die Qualität überwacht.
Das klingt nach viel. Aber rechnet dagegen: Wenn eure Techniker täglich zwei Stunden mit Dokumentensuche verbringen und ihr 20 Techniker habt, sind das 40 Personenstunden pro Tag. Selbst wenn das RAG-System nur die Hälfte davon einspart, rechnet sich die Investition in unter sechs Monaten.
Was ich ehrlich dazu sage: Die ersten drei Monate sind frustrierend. Die Antwortqualität ist anfangs mittelmäßig, weil die Dokumentenaufbereitung Zeit braucht. Techniker vertrauen dem System nicht sofort – zu Recht, denn Halluzinationen kommen vor. Es dauert sechs bis zwölf Monate, bis ein RAG-System wirklich rund läuft.
Datenschutz: Der eigentliche Trumpf
Für FM-Dienstleister mit Kundendaten ist Selfhosting nicht optional, sondern Pflicht. Verträge, Wartungsprotokolle, Kostendaten, Mitarbeiterinformationen – das darf nicht über externe Server laufen. Eine selfhosted RAG-Lösung verarbeitet alles lokal. Kein Datenabfluss, volle DSGVO-Konformität, komplette Kontrolle.
Wichtig ist trotzdem: Anonymisiert personenbezogene Daten vor dem Einspeisen. Mitarbeiternamen raus aus Incident Reports, E-Mail-Adressen ersetzen, Standortdaten codieren. Das ist nicht nur DSGVO-Pflicht, sondern verbessert auch die Antwortqualität, weil das Modell sich auf Sachinformationen konzentriert.
Mein Fazit: Anfangen, aber realistisch bleiben
Interne KI mit RAG ist keine Zukunftsmusik mehr – die Technologie ist da, die Kosten sind überschaubar, und die Vorteile für FM-Dienstleister sind real. Aber es ist auch kein Plug-and-Play-Produkt. Es braucht jemanden im Team, der sich reinfuchst, es braucht saubere Dokumente, und es braucht Geduld.
Mein konkreter Tipp: Startet mit einem überschaubaren Pilotprojekt. Nehmt 20 eurer wichtigsten Dokumente – die Wartungsanleitungen, die am häufigsten gesucht werden. Setzt Ollama mit Llama 3 auf einem Testrechner auf, füttert die Dokumente über LlamaIndex in Chroma, und lasst fünf Kollegen zwei Wochen damit arbeiten. Die Ergebnisse werden euch zeigen, ob und wie ihr weitermachen solltet.
Wer hat bereits Erfahrung mit internen KI-Systemen im FM? Oder steht gerade vor der Entscheidung? Ich bin gespannt auf eure Erfahrungen.
Ähnliche Beiträge
DigitalisierungMCP im FM-Konzern: Wie ein offenes Protokoll Datensilos überbrücken kann
Das Model Context Protocol (MCP) verbindet KI-Anwendungen mit CAFM, ERP und Ticketsystemen. Warum MCP für FM-Konzerne mit fragmentierten Systemlandschaften relevant ist und wie eine konkrete Architektur aussehen kann.
29. Jan. 2026
Weiterlesen →
KI & AutomatisierungAusschreibungen automatisieren mit KI und n8n – was wirklich geht und was nicht
FM-Ausschreibungen mit n8n und KI beschleunigen – von der Eingangsanalyse über strukturierte Leistungsverzeichnisse bis zu Textbausteinen. Was sich automatisieren lässt und wo menschliche Expertise unverzichtbar bleibt.
06. Nov. 2025
Weiterlesen →
CAFMCAFM-Realität vs. CAFM-Versprechen: Was die Hochglanzbroschüre verschweigt
Ehrlicher Blick auf CAFM-Einführungen: typische Lücken bei Laufzeit, Datenqualität und Integration. Wann CAFM sinnvoll ist, welche Alternativen es gibt und fünf Fragen vor der CAFM-Entscheidung.
08. Okt. 2025
Weiterlesen →