KI-Assistent mit Retrieval für die Fahrzeugdiagnose

In einem Projekt unseres Gründers bei einem Premium-Automobilhersteller ging ein KI-Assistent mit Retrieval (RAG) für einen Diagnose-Service mit über 15.000 Nutzern pro Monat in Produktion. Die Antwortqualität wird mit definierten Kennzahlen in Grafana und Kibana gemessen.

Ausgangslage

Der Diagnose-Service ist microservice-basiert, läuft auf Google Cloud und wird in den Werken, in Remote-Update-Services und im Aftersales genutzt. Die Diagnoseinhalte sind umfangreich und über viele Quellen verteilt. Wer eine konkrete Frage zu einem Fehlerbild hat, muss die passende Stelle erst finden. Das kostet Zeit, besonders bei seltenen Fällen und bei neuen Kolleginnen und Kollegen.

Große Sprachmodelle (Large Language Models, LLM) machten einen Assistenten möglich. Offen war, wie er diese Inhalte erschließt, ohne Antworten zu erfinden.

Aufgabe

Die Diagnoseinhalte sollten über einen LLM-Assistenten zugänglich werden, bei gesicherter Antwortqualität. Der Assistent musste sich in die bestehende Plattform einfügen und mit den Datenschutzvorgaben des Herstellers vereinbar sein. Ein Assistent, der plausibel klingt, aber falsch liegt, ist in der Fahrzeugdiagnose nicht tragbar.

Lösung

Als Product Owner und Solution Architect verantwortete unser Gründer das Vorhaben und leitete das internationale 14-köpfige Team technisch. Die Kernentscheidungen:

• Retrieval statt reines Modellwissen. Der Assistent arbeitet mit Retrieval-Augmented Generation (RAG). Zu jeder Anfrage sucht das System zunächst die relevanten Diagnoseinhalte per Vektorsuche und übergibt sie dem Sprachmodell als Kontext. Das Modell antwortet auf Basis dieser Inhalte, nicht aus dem Gedächtnis.
• Build vs. Buy systematisch bewertet. Bevor die Entscheidung für einen KI-Service fiel, wurden die Kandidaten nach vier Kriterien verglichen: Antwortqualität, Kosten, Latenz und Datenschutz. Wie sich diese Abwägung im Mittelstand strukturieren lässt, zeigt der Artikel KI Build vs. Buy.
• Teil des Diagnose-Service. Der Assistent fügt sich in den microservice-basierten Diagnose-Service ein, entwickelt mit Node.js und Vue.js. Wie wir Oberflächen dieser Art heute umsetzen, beschreibt die Leistung Vue.js- und Nuxt-Entwicklung.
• Qualität messbar gemacht. Für die Antwortqualität wurden Kennzahlen (KPIs) definiert und in Grafana und Kibana sichtbar gemacht. So lässt sich erkennen, wie sich Änderungen an Prompts, Retrieval oder Modell auf die Ergebnisse auswirken.

Ergebnis

Der Assistent ist produktiv im Einsatz. Nutzer des Diagnose-Service können Diagnoseinhalte über eine Frage in natürlicher Sprache abrufen. Die Antwortqualität wird laufend gemessen, nicht einmalig zum Go-Live. Fachbereich und Entwicklung haben damit eine gemeinsame Grundlage, um über Änderungen an Retrieval, Prompts oder Modell zu entscheiden. Die Plattform selbst entstand im Shift-to-Cloud des Legacy-Diagnosesystems.

Erkenntnisse aus dem Projekt

• Retrieval ist für Fachinhalte die Voraussetzung. Ein Sprachmodell ohne Zugriff auf die eigenen Dokumente liefert in der Diagnose keine belastbaren Antworten.
• Die Bewertung von KI-Services gehört an den Anfang, mit echten Fragen aus dem Fachbereich. Qualität, Kosten, Latenz und Datenschutz lassen sich nur gemeinsam beurteilen.
• Antwortqualität ist eine Kennzahl, kein Gefühl. Wer sie nicht misst, erkennt Verschlechterungen nicht und kann Verbesserungen nicht belegen.

Übertragbar auf Ihr Vorhaben

Assistenten mit Retrieval über eigene Fachinhalte bauen wir heute als KI-Chatbot für Unternehmen. Für Diagnoseplattformen, Update-Prozesse und Aftersales-Software in der Automobilbranche gibt es unsere Automotive-Software-Entwicklung. Wie sich die Antwortqualität eines solchen Systems mit Kennzahlen belegen lässt, zeigt der Artikel RAG-Antwortqualität messen. Wenn Sie prüfen möchten, ob ein RAG-Assistent zu Ihren Inhalten passt, sprechen Sie uns an.