T5.Chat & RAG API: KI-gestützte Wissenserschließung für JEN

TensorFive GmbH ist ein deutsches KI-Technologieunternehmen mit Sitz in Mainz. Wir entwickeln DSGVO-konforme Enterprise-KI-Lösungen für Wissenssuche, Dokumentenanalyse und Anforderungsmanagement sowie „RAG-as-a-Service" – durchgängig On-Premises betreibbar, ohne Abhängigkeit von US-Cloud-Diensten. Unser Team verbindet KI-Forschung, Software-Engineering und Unternehmensberatung. Entstanden ist das Unternehmen aus Beratungsprojekten, in denen wiederkehrend dasselbe Problem sichtbar wurde: Wertvolles Wissen liegt verstreut, ist schwer auffindbar und an einzelne Personen gebunden.

Für den Anwendungsfall der JEN schlagen wir die Kombination zweier produktiv eingesetzter Komponenten vor:

• T5.Chat – die Anwendungs- und Dialogebene („Chat mit Dokumenten"): nutzerfreundliche Oberfläche, Single Sign-on über Microsoft Entra ID / Active Directory, rollen- und berechtigungsbasierter Zugriff, Quellen-/Konversationsanzeige, Datei-Upload, Vorschau von Office-/PDF-Dateien sowie Administration durch Eigenpersonal. T5.Chat läuft heute multimandantenfähig in rund zehn produktiven Kundeninstanzen (Kubernetes, je Kunde isoliert) und kann zusätzlich aus Microsoft Teams heraus genutzt werden.

• T5.Knowledge (öffentlich „RAG-API") – die RAG-Engine: Ingestion heterogener Dokumente (Textextraktion, OCR/Vision, Chunking, kontextuelle Anreicherung, Embedding, Wissensgraph), hybride semantische + klassische Suche, LLM-basiertes Reranking und – als technisches Kernstück – berechtigungsbewusstes Retrieval mit früher Filterung in Vektor- und Graph-Index.

Beide Ebenen sind über offene REST-Schnittstellen entkoppelt; sämtliche KI-Modelle (Sprachmodell, Embedding, Vision/OCR, Spracherkennung) werden über OpenAI-kompatible, lokal betreibbare Endpunkte angesprochen – es besteht kein Cloud-Zwang. Die Lösung beantwortet Fragen ausschließlich auf Basis freigegebener interner Quellen, mit nachvollziehbaren Fundstellen-Referenzen und unter Berücksichtigung bestehender Berechtigungen; fehlt belastbares Quellmaterial, wird dies transparent gemacht statt eine Antwort zu erfinden.

Damit adressieren wir genau die Anforderungen der JEN: sichere, lokale, nachvollziehbare Wissenserschließung über verteilte Quellsysteme, mit klarer Produkt- und Umsetzungsperspektive.

Lösungsansatz: ein produktives, modular aufgebautes RAG-System nach Hexagonal-Architektur (Ports & Adapters), das externe Systeme strikt über Adapter anbindet und so austauschbar hält.

Dokumente durchlaufen eine Ingestion-Pipeline: Textextraktion (u. a. PDF, DOCX, HTML, Markdown, CSV/JSON), OCR/Vision für gescannte Seiten und Bilder, token-bewusstes Chunking, kontextuelle Anreicherung, Embedding sowie optionale Wissensgraph-Extraktion (Entitäten/Relationen). Zur Beantwortung kombiniert das System dichte semantische Suche (Vektoren) mit klassischer (BM25/sparse) Suche, fusioniert beide per Reciprocal Rank Fusion und schärft das Ergebnis per LLM-Reranking. Antworten entstehen mit Quellenbezug; bei unzureichender Quellenlage greift ein Schwellwert-Mechanismus.

Technische Basis (alles lokal betreibbar): ein Go-Dienst; PostgreSQL (Metadaten/Berechtigungen), Qdrant (Vektoren, 2.560-dim, Payload-Filter für frühe Rechte-Filterung), Neo4j (Wissensgraph), Redis/SQLite (Cache); Modelle über OpenAI-kompatible Endpunkte (vLLM/Ollama). Mehrsprachiges Embedding (Qwen3-Embedding-4B, Apache-2.0) mit starker deutscher Qualität.

Reifegrad:

• Produktiv/ausgereift: berechtigungsbewusstes Retrieval (frühe Filterung in Vektor- UND Graph-Index), hybride Suche, LLM-Reranking, Mandanten-/Projekt-Isolation, Zitate/Quellenreferenzen, OCR/Vision-Pipeline, inkrementelle und dublettenarme Ingestion (Content-Hash, idempotent). T5.Chat ist bei Kunden produktiv im Einsatz; T5.Knowledge ist in einem realen Großkorpus-Einsatz erprobt (Frage 7). Echtzeit-Rechte-Rückprüfung.

• Solide, in laufender Validierung: kontextuelle Anreicherung, Chunking-Optimierung, Wissensgraph für Multi-Hop-/Beziehungsfragen.

• In Entwicklung / Ausbaupfad: native PPTX/XLSX-Extraktion, durchgängige Konnektoren für SMB/DMS/SQL (Frage 4), zertifizierter Audit-Trail, Output-Guardrails.

Wissenschaftliche Redlichkeit als Qualitätsmerkmal: Unsere Whitepaper weisen auf Nachfrage Wirksamkeit und Grenzen einzelner Komponenten anhand kontrollierter Benchmarks aus – z. B. dass Reranking der dominante Qualitätshebel ist, dass kontextuelle Anreicherung moderat wirkt und dass Graph-Retrieval von gängigen Single-Label-Metriken systematisch unterschätzt wird (die antwortbezogene Bewertung zeigt seinen Nutzen). Wir nennen Messwerte mit ihrem tatsächlichen Geltungsbereich. Für eine geschützte Unternehmensumgebung ist die Lösung damit produktiv einsetzbar; der Pilot (Frage 5) konkretisiert sie für die JEN-spezifischen Quellen.

Der Einsatzfall der JEN passt sehr genau zum Profil unserer Lösung. JEN bündelt als bundeseigenes Unternehmen den Rückbau und die Entsorgung kerntechnischer Altlasten in Jülich – ein Umfeld mit besonders anspruchsvollem Wissens- und Nachweismanagement:

• Heterogene, über Jahrzehnte gewachsene Bestände: Anlagen aus den 1960er-Jahren (AVR-Hochtemperaturreaktor, FRJ-2/DIDO) erzeugen gemischte analog-/digital-Bestände, sehr große technische Dokumente (Genehmigungsunterlagen, Sicherheitsberichte, As-built-Zeichnungen bis ~900 Seiten) und hohe Versionierungs-/Dublettenanteile. Unsere Ingestion verarbeitet text- und bildbasierte PDFs (OCR/Vision), Office-Dokumente, Tabellen und Bilder, behandelt Versionen/Dubletten content-hash-basiert und arbeitet inkrementell.

• Nachvollziehbarkeit und Nachweisführung: Rückbau erfordert belegbare, quellengestützte Auskünfte (IAEA-Record-Keeping, atomrechtliche Genehmigungslogik nach AtG). Unser System antwortet ausschließlich aus freigegebenen Quellen, referenziert die konkrete Fundstelle und macht eine unzureichende Quellenlage transparent, statt zu halluzinieren.

• Langzeit-/Strahlenschutzanforderungen: Daten mit jahrzehntelangen Aufbewahrungspflichten (StrlSchG/StrlSchV – z. B. Dosis­register bis Alter 75 und ≥ 30 Jahre nach Tätigkeit) profitieren von strukturierter, durchsuchbarer Erschließung. Die Lösung verdrängt keine Quellsysteme, sondern erschließt sie nachvollziehbar.

• Berechtigungen auf AD-Basis: Zugriff erfolgt rollen-/berechtigungsbasiert; bestehende Strukturen aus den Quellsystemen werden übernommen (Frage 4/5).

• Datensouveränität: vollständiger On-Premises-Betrieb, ausschließlich lokal betreibbare Modelle, kein unkontrollierter Datenabfluss – passend für eine geschützte, ggf. KRITIS-relevante und atomrechtlich regulierte Umgebung (die konkrete KRITIS-/AtG-Einordnung ist anlagenspezifisch und mit der JEN abzustimmen).

• Deutsch als Primärsprache: mehrsprachiges Embedding mit starker deutscher Qualität; ein deutschsprachiger Referenzeinsatz liegt vor (Frage 7).

Nicht alle Startquellen-Konnektoren sind „von der Stange" verfügbar (SharePoint ja; SMB/DMS/SQL als Integrationsleistung – Frage 4), und der Wissensgraph in 1-Mio-Dokumente-Skala erfordert ein gestaffeltes Vorgehen. Beides ist planbar und im Pilot adressierbar. In Summe: hohe fachliche und technische Passung mit klar benannten, kalkulierbaren Integrationsaufgaben.

Im Standard abgedeckt (produktiv):

• Lokaler Betrieb aller Verarbeitungsstufen; ausschließlich lokal betreibbare Modelle (Sprachmodell, Embedding, Vision/OCR, Spracherkennung) über OpenAI-kompatible Endpunkte.

• Semantische + klassische Suche mit RRF-Fusion und LLM-Reranking; quellenbasierte Antworten mit Fundstellen-Referenz; transparenter Umgang bei unzureichender Quellenlage (Schwellwert statt erfundener Antwort).

• Berechtigungsbewusstes Retrieval mit früher Filterung in Vektor- und Graph-Index; Mandanten-/Projekt-Isolation; Rollen (Leser/Bearbeiter/Eigentümer); reservierte Markierung für allgemein freigegebene Inhalte.

• Dokumenttypen: text- und bildbasierte PDFs (OCR/Vision), DOCX, HTML/Markdown/CSV/JSON, Bilder, Audio/Video (Transkription); Versionen/Dubletten/Inkrementell (content-hash, idempotent, Cascade-Delete/Re-Index).

• SSO via Entra ID/AD; Administration durch Eigenpersonal, Health-/Readiness-Checks, strukturiertes Logging, Nutzungs-/Query-Historie.

• SharePoint Online/OneDrive inkl. Berechtigungsübernahme und Echtzeit-Rechte-Rückprüfung, (Microsoft Graph; Auflösung von M365-Gruppen auf Nutzer-/E-Mail-Ebene, „fail-closed" bei Fehlern).

Erweiterte Konfiguration: hybride/sparse Suche und der zusätzliche Tenant-Index-Filter werden je Deployment aktiviert; das „Kein-Treffer"-Verhalten wird pro Domäne kalibriert; Confluence/Wiki ist vorhanden, weitere CMS über einen generischen REST-Konnektor.

Offene Punkte / Integrationsleistung:

• SMB-Fileshares (AD-ACL): kein fertiger Konnektor, aber technisch klar umsetzbar – Lesen von Inhalten + NTFS-Security-Descriptoren (DACL/ACE), SID-Auflösung und AD-Gruppen-Expansion (tokenGroups). Sauberster Konnektor-Zielfall.

• DMS nscale (Kyocera/Ceyoniq): über REST/CMIS bzw. das Java-„Advanced-Connector"-SDK; ACL-Modell (NCL ≈ Windows-ACL) vorhanden, exakte Rechte-Auslesung im Kunden-PoC zu verifizieren.

• DMS windream (dataglobal Group): über COM-/Web-Service-SDK; Objekt-ACLs inkl. Vererbung vorhanden, Rechte-Getter im PoC zu bestätigen.

• MS SQL Server: über einen zu erstellenden DB-Konnektor bzw. den generischen REST-/n8n-Konnektor.

• PPTX/XLSX-Extraktion, zertifizierter Audit-Trail, Output-Guardrails: auf der Roadmap.

Ausbau-Prinzip: Die Ingestion ist „push-basiert" und über einen schlanken Provider-Vertrag (Authentifizieren · Container/Items listen · Inhalt laden · erlaubte Identitäten liefern) erweiterbar; neue Quellen sind additiv anschließbar (inkl. n8n-Integrationsknoten).

Integrationsaufwand (gestaffelt):

• Gering: SharePoint Online, Datei-Upload, REST-Ingestion, SSO (Entra ID/AD), lokale Modelle, hybrides Retrieval + Reranking + Zitate.

• Mittel: SMB-Fileshares (AD-ACL→Identität), Confluence/Wiki, MS SQL, inkrementelle Sync-Planung.

• Höher (mit Vendor-PoC): DMS-Konnektoren nscale/windream (Inhalts- + Rechte-Auslesung), Wissensgraph in Großskala.

Pilotvorgehen (8–12 Wochen, kleines Test-/Expertenteam):

• Wo 1–2: Infrastruktur/GPU bereitstellen, Stack deployen, Entra-ID-/AD-Registrierung, Netz- und Sicherheits-Review.

• Wo 3–4: 1–2 Startquellen anbinden (SharePoint produktiv + begrenztes SMB-Subset), Pilotkorpus festlegen (z. B. eine Abteilung / ein Rückbauprojekt).

• Wo 5–8: Ingestion (inkl. OCR/Vision, optional Graph), Tuning von Retrieval/Reranking, deutschsprachige Qualitätssicherung, Berechtigungs-Validierung.

• Wo 9–10: Experten-Evaluation mit unserer belastbaren Methodik (LLM-Judge auf Beantwortbarkeit/Vollständigkeit/Korrektheit + RAGAS-Treue; handkuratiertes Testset), Kalibrierung von „Kein-Treffer"-Verhalten und Zitaten.

• Wo 11–12: Härtung, Logging/Monitoring, Admin-Übergabe, Ergebnisbericht inkl. Rollout- und Sizing-Empfehlung.

Mitwirkung Auftraggeber: Entra-/AD-App-Registrierung + SharePoint/Graph-Berechtigungen; SMB/DMS-Zugänge + Service-Accounts; Auswahl Pilotkorpus + Berechtigungsgruppen; 3–6 Fach-Experten für Testset/Bewertung; Infrastruktur/GPU + Netz; Freigaben Datenschutz/IT-Sicherheit (AVV + TOMs erstellen wir).

Betriebsmodell – drei souveräne Inferenz-Optionen (alle DE/EU, kein US-Cloud-Zwang, Modelle austauschbar):

• A) Souverän gehostet auf SambaNova-Infrastruktur (Partner Infercom, Equinix MU3 München, ISO-27001-Rechenzentrum) – z. B. MiniMax M2.7/ (perspektivisch) M3, sehr schnelle Inferenz.

• B) Souverän gehostet in TensorFive-eigener Colocation Mainz (ISO-27001-Rechenzentrum) auf H200 – z. B. Mistral Medium 3.5.

• C) Vollständig On-Premises bei JEN auf kundeneigener NVIDIA-Hardware – TensorFive übernimmt Modell-Deployment, Node-Einrichtung und den gesamten Applikations-Stack. Direkter Fit zur On-Prem-Vorgabe der JEN.

A/B sind in deutschen/EU-ISO-27001-Rechenzentren souverän betrieben (AVV/TOMs, kein Training auf Kundendaten); die strikte Lesart „On-Premises ohne Abfluss an Dritte" erfüllt Option C.

Empfehlung: Pilot schnell und ohne Hardware-Beschaffungsverzug auf A/B starten, Produktion On-Premises (C) – der Modellwechsel bleibt durch eine Abstraktionsschicht wie z.B. LiteLLM transparent. Betrieb durch JEN-Eigenpersonal über die Admin-Oberfläche; TensorFive liefert Einrichtung, Integration, Wartung/Updates und Support (Remote-Service). Zum Betriebsstandard gehören Netzsegmentierung (Default-Deny), Secrets-Management, Monitoring/Alerting, Backup/Restore (3-2-1, definierte RPO/RTO) und Zero-Trust-Admin-Zugang (VPN→Bastion→MFA); optionale Telemetrie ist abschaltbar (air-gap-tauglich).

Grobe Annahmen (im Pilot zu verifizieren) für 350 Nutzer, ~30 gleichzeitige interaktive Anfragen, ~50 TB / ~1 Mio. Dokumente, Deutsch:

GPU/Inferenz (dominanter Faktor):

• Generierungsmodell als Qualitätstreiber: ein leistungsfähiges Open-Weight-Modell (30–70B-Klasse). Für ~30 gleichzeitige Anfragen sind – je nach Modellgröße, Quantisierung und Kontextlänge – etwa 2–4 GPUs der 80–141-GB-Klasse (NVIDIA H100/H200) realistisch. Quantisierung (FP8/INT4) ist der größte Hebel. Als Orientierung bedient ein 70B-Modell auf 2×80 GB grob ~8–16 gleichzeitige In-Flight-Anfragen bei ~4–8k Kontext – konsistent mit 30 typischerweise stoßweise aktiven Nutzern; horizontale Skalierung via vLLM.

• Embedding (4B, ~3–8 GB) und Reranking teilen sich GPU-Kapazität; Vision/OCR und Transkription sind v. a. bei der Ingestion lastrelevant.

Storage:

• Originaldokumente (50 TB) verbleiben in den Quellsystemen; das RAG-Backend speichert abgeleitete Daten (Chunks/Vektoren/Graph/Metadaten), nicht zwingend Kopien aller Originale.

• Vektorindex (Qdrant): bei hohen Dublettenanteilen effektiv < 1 Mio. Dokumente; grob 20–50 Mio. Chunks → mit Quantisierung ~1–2 TB schnelles NVMe (skalierbar).

• Wissensgraph (Neo4j): wächst mit dem Korpus; bei Voll-Skala zweistellige Mio. Entitäten → hierarchische Partitionierung; daher initial auf hochwertige Teilkorpora. Metadaten/Cache (PostgreSQL/Redis): überschaubar (10er–100er GB).

CPU/RAM & Ingestion: Extraktion/Chunking sind CPU-stark und horizontal skalierbar (Worker-Flotte). Die Erst-Ingestion von ~1 Mio. Dokumenten (inkl. OCR der Scans, Anreicherung, Graph) ist eine gestaffelte Kampagne (wichtigste Korpora zuerst), GPU-gebunden über mehrere Wochen Wall-Clock, durch Parallelisierung und Dedup verkürzbar; der Steady-State ist günstig (idempotent).

Erste Ausbaustufe (gemäß Vorgabe JEN): Single-/Multi-Node + Backup, keine Hochverfügbarkeit zwingend. Datenfluss: vollständig on-prem; alle Modell-Endpunkte lokal gepinnt; optionale Telemetrie deaktiviert → kein unkontrollierter Abfluss. Bei Option C stellt JEN die GPU-/Server-Hardware; TensorFive übernimmt Dimensionierung, Deployment und Node-Setup. Belastbare Endwerte (Latenz, Durchsatz, Speicher-/GPU-Auslastung) liefert der Pilot am realen Korpus.

Wir verfügen über produktive Referenzeinsätze mit hoher Übertragbarkeit auf den JEN-Fall. Ein direkt vergleichbares nuklearspezifisches Projekt benennen wir bewusst nicht, da uns ein solches nicht vorliegt – der nächste Analogfall ist jedoch sehr aussagekräftig:

• Öffentlich-rechtlicher Rundfunk / Bildungsmedien (Deutschland): produktiver RAG-Einsatz über einen großen, heterogenen Medien- und Dokumentbestand (Video-Transkripte, PDFs, Hintergrundtexte; ~2.900 Dokumente, ~27.000 Chunks; Wissensgraph mit ~86.000 Entitäten / ~306.000 Relationen). Evaluation mit 250 handkuratierten deutschsprachigen Fragen über zehn Fragetypen, hybridem Retrieval und LLM-Reranking; gemessene RAGAS-Treue („faithfulness") 0,91. Verarbeitung ausschließlich in Deutschland, DSGVO-konform. Dieser Fall ist öffentlich-rechtlich, deutschsprachig, rechenschaftsorientiert und großkorpusbasiert – strukturell nahe an der JEN.

• Wissenschaftliche Fundierung: Aus der Arbeit sind zwei Whitepaper entstanden (auf Anfrage) – zur Architektur des berechtigungsbewussten Hybrid-Retrievals sowie zur belastbaren Bewertung von RAG-Qualität (u. a. der Nachweis, dass gängige Single-Label-Metriken Graph-Retrieval systematisch unterschätzen). Das belegt methodische Tiefe und die Ehrlichkeit unserer Leistungsaussagen.

• Enterprise-Dokumentenerschließung: produktive SharePoint-Online-Anbindung inkl. Berechtigungsübernahme; T5.Chat läuft multimandantenfähig in rund zehn produktiven Kundeninstanzen.

• Sektorerfahrung: Finanz-/Versicherungswesen, Industrie/Fertigung, Professional Services sowie öffentlicher Sektor (Bürgerservice, Aktenverarbeitung, interne Wissenssuche). Öffentlich referenzierbarer Kunde u. a. ING.

Für die JEN besonders relevant: In allen Einsätzen stehen Datensouveränität (DE/EU, On-Premises-Option), Übernahme bestehender Quellsystem-Berechtigungen und quellengestützte, nachvollziehbare Antworten im Vordergrund – exakt die hier geforderten Eigenschaften. Konkrete, vertrauliche Referenzauskünfte (inkl. Nennung des Rundfunk-Kunden und Ansprechpartner) geben wir im geschützten Rahmen weiter (Frage 9).

Modularität: Hexagonal-Architektur mit klar abgegrenzten Komponenten hinter Ports/Adaptern. Sprachmodell, Embedding, Reranker, Vision/OCR, Vektor-Store, Wissensgraph und Konnektoren sind einzeln austauschbar. Modellwechsel/-Upgrades laufen über eine Abstraktionsschicht (LiteLLM mit stabilen Modell-Aliassen): Ein neues oder besseres Modell wird per Konfigurationsänderung eingebunden – ohne Anpassung der Anwendungen, mit Fallback-Ketten. So lassen sich neue Open-Weight-Generationen (z. B. künftige MiniMax-/Mistral-/Llama-Modelle) zeitnah und transparent übernehmen.

Offene Standards / kein Lock-in:

• Offene, dokumentierte REST-Schnittstellen (OpenAI-kompatible Modell-Endpunkte; n8n-Integrationsknoten); Konfigurationen sind exportierbar.

• Infrastruktur auf Open-Source-Basis (Qdrant, Neo4j, PostgreSQL, Redis); Modelle mit kommerziell nutzbaren Lizenzen (z. B. Apache-2.0-Embeddings). Keine Abhängigkeit von einer proprietären Cloud-API.

• Das Produkt selbst ist proprietär (Closed Source). Das Lock-in-Risiko wird jedoch durch offene Schnittstellen, exportierbare Daten/Konfigurationen und austauschbare Standardbausteine gering gehalten; Quell- und Index-Daten verbleiben bei JEN.

Skalierbarkeit: zustandsloser API-Dienst (horizontal skalierbar), unabhängig skalierende Datenspeicher, GPU-seitige Skalierung via vLLM; für sehr große Wissensgraphen ist hierarchische Partitionierung der Pfad (Frage 6).

Souveränität: drei DE/EU-Betriebsoptionen (souverän gehostet auf SambaNova/Infercom in München; in TensorFive-Colocation Mainz auf H200; oder vollständig On-Premises bei JEN). JEN wählt den Souveränitätsgrad und kann später wechseln.

Roadmap: native PPTX/XLSX-Extraktion; durchgängige SMB-/DMS-/SQL-Konnektoren; validierter Multi-Hop-Wissensgraph in Großskala; End-to-End-RAGAS-Evaluation; zertifizierter Audit-Trail; Echtzeit-Rechte-Rückprüfung und Output-Guardrails.

Wirtschaftlichkeit (Lebenszyklus): planbare Lizenz-/Betriebskosten, Wiederverwendung der Standardbausteine, Investitionsschutz durch Austauschbarkeit statt Neukauf. Unsere veröffentlichte Forschung belegt, dass wir Weiterentwicklung evidenzbasiert betreiben – Wirksamkeit und Grenzen werden gemessen, nicht behauptet.