Wissenszugriff über 30 Jahre Bestandsdokumente
Beispielprojekt. Es zeigt Aufbau und Vorgehen, beschreibt aber keinen erteilten Auftrag; Kunde, Zahlen und Zitat sind nicht belegt.
- Kunde
- Versicherer, 4.000 MitarbeitendeAuf Wunsch des Kunden ohne Namen.
- Branche
- Versicherung
- Jahr
- 2026
Ausgangslage
Der Stand vor dem Projekt
Bedingungswerke, Rundschreiben und Schadensrichtlinien lagen in vier Ablagen mit unterschiedlichen Berechtigungen. Wer wissen wollte, welche Fassung eines Tarifs 2011 galt, suchte im Schnitt zwölf Minuten. Oft war es am Ende die falsche Fassung, denn die Ordnerstruktur kannte keine Gültigkeitszeiträume.
Mitarbeitende
4.000
Beispielprojekt, nicht belegt
Suchzeit je Fall vorher
12 Minuten
Beispielprojekt, nicht belegt
Suchzeit je Fall nachher
2 Minuten
Beispielprojekt, nicht belegt
Lösung
Was das System tut
Das Retrieval läuft über den gesamten Bestand und filtert nach Gültigkeit. Jede Antwort nennt Dokument, Fassung und Gültigkeitszeitraum. Die Berechtigungen aus dem Verzeichnisdienst gelten weiter: Wer ein Dokument nicht öffnen darf, bekommt es auch nicht zitiert.
Der Weg einer Frage durch den Bestand. Die Frage wird in einen Vektor überführt, und Qdrant liefert die vierzig nächstgelegenen Abschnitte. Erst danach greifen zwei Filter: einer prüft, ob ein Dokument zum Stichtag überhaupt galt, der zweite das Leserecht des Anfragenden gegen Azure AD, und zwar bei jeder Anfrage neu. Das Reranking wählt aus dem Rest sechs Belege. Nur diese sechs sieht das Modell, und die Antwort nennt ihre Fundstellen. Die Berechtigungsprüfung sitzt damit hinter dem Retrieval und nicht davor.
›Dieselbe Architektur als Textfassung
Frage
│
↓
[Einbettung] ──→ Qdrant ──→ Kandidaten (Top 40)
│
↓
[Filter: Gültigkeit zum Stichtag]
│
↓
[Filter: Leserecht des Anfragenden]
└─ Azure AD, je Anfrage
│
↓
[Reranking] ──→ Belege (Top 6)
│
↓
[Modell] ──→ Antwort + FundstellenArchitektur
Wie es aufgebaut ist
Die Berechtigungsprüfung sitzt hinter dem Retrieval und nicht davor. Wer sie beim Indexieren auflöst, baut einen zweiten Berechtigungsbestand, der ab dem ersten Tag auseinanderläuft.
Die Aufbereitung des Bestands lief über Apache Tika. Gescannte Rundschreiben aus den Neunzigern mussten durch eine Texterkennung; ihre Trefferquote liegt sichtbar unter der des übrigen Bestands, und das steht in der Oberfläche an der Antwort und nicht in einer Fußnote.
Was das System nicht tut: es entscheidet keinen Schadensfall. Es zeigt, was gilt, und nennt die Stelle. Die Bewertung bleibt beim Sachbearbeiter.
Warum die Volltextsuche hier nicht reichte
Die Sachbearbeitung stellt keine Wortsuchen, sondern Fragen: „Ist ein Wasserschaden durch ein undichtes Aquarium gedeckt?“ In den Bedingungswerken steht dazu kein einziges Mal das Wort Aquarium. Es steht dort etwas über „Austritt von Leitungswasser“ und etwas über „Behältnisse“.
Eine Volltextsuche findet an dieser Stelle nichts und ist damit nicht kaputt. Sie beantwortet eine andere Frage. Retrieval sucht nach Bedeutung, und „Aquarium“ liegt darin nahe genug an „Behältnis mit Wasser“, dass die richtige Ziffer als Treffer kommt.
Der Schnitt entlang der Ziffern
Bedingungswerke haben eine Eigenschaft, die den Aufbau erleichtert: Sie sind bereits geschnitten. Jede Ziffer ist ein abgeschlossener Gedanke, und wer an Ziffern schneidet, bekommt Abschnitte, die für sich stehen.
Der Kontextkopf trägt Werk, Fassung, Kapitel und Ziffer. Das kostet wenige Prozent Speicher und ist der Grund, warum eine Antwort später sagen kann, woher sie stammt, nicht „laut den Bedingungen“, sondern „AVB Hausrat 2019, Ziffer 4.2“.
Schwieriger waren die Schadenakten. Sie enthalten Freitext, Scans und gelegentlich eine handschriftliche Notiz. Dort wird nach Absätzen geschnitten und die Texterkennung liefert erkennbar schlechtere Treffer. Auch das steht in der Oberfläche: Ein Treffer aus einem Scan ist als solcher gekennzeichnet.
Rechte bei jeder Anfrage, nicht beim Indexieren
Eine Schadenakte darf nicht jeder sehen. Der naheliegende Weg wäre, die Leserechte beim Indexieren aufzulösen und als Merkmal an den Abschnitt zu hängen.
Dieser Weg führt einen zweiten Rechtebestand ein. Er ist eine Kopie des Verzeichnisses, und er veraltet, sobald jemand die Abteilung wechselt. In einem Haus mit viertausend Mitarbeitenden passiert das täglich.
Geprüft wird deshalb bei jeder Anfrage gegen das Verzeichnis. Das Retrieval holt Kandidaten ohne Rechtekenntnis; erst danach fällt weg, was der Fragende nicht öffnen darf. Was wegfällt, steht als Verweigerung im Protokoll, und genau diese Zeile war es, die den Datenschutzbeauftragten überzeugt hat.
Was die Antwort tragen muss
Drei Dinge, und alle drei standen vor dem ersten Prototypen fest.
Die Fundstelle: Werk, Fassung, Ziffer. Nachprüfbar in zwei Klicks.
Die Gültigkeit: Ein Bedingungswerk, das für Verträge ab 2019 gilt, darf bei einem Vertrag von 2016 nicht zitiert werden. Der Filter dafür steht vor dem Modell und nicht dahinter.
Das Eingeständnis: Findet die Suche nichts, sagt die Antwort das. In einer Schadensachbearbeitung ist eine erfundene Deckungszusage der teuerste denkbare Fehler.
Was gemessen wurde
Eine Fragemenge aus der Sachbearbeitung: fünfzig echte Fragen, jede mit der Stelle, an der die Antwort steht. Sie entstand im Piloten und blieb danach das Maß: jede Änderung an der Zerlegung, am Einbettungsmodell oder am Reranking wird dagegen gefahren.
Ohne diese Menge lässt sich nicht sagen, ob eine Änderung getragen hat. Mit ihr ist es eine Zahl.
Ergebnis
Was sich geändert hat
- Suchzeit sinkt von zwölf auf unter zwei Minuten
- Niemand muss mehr wissen, in welcher Ablage ein Dokument liegt
- Berechtigungen werden bei jeder Anfrage neu geprüft, nicht beim Indexieren
Was im Einsatz ist
- InsideAI
- Qdrant
- Apache Tika
- Azure AD
- Mistral Large
Produkt- und Anbieternamen sind Marken der jeweiligen Inhaber. Ihre Nennung weist auf den Einsatz hin, nicht auf eine geschäftliche Verbindung.
Kontakt
Wir sehen uns Ihren Vorgang an
Wir gehen Ihren Vorgang durch und sagen, welche Schritte zuerst dran sind.