## KI ### Ground truth berücksichtigen ### Closed-World-Aufgabe beim Reranking ```text Erlaubtes Wissen ├── SourceValue ├── Context └── Candidates Nicht erlaubt └── parametrisches Wissen des LLM Weiteres: Business Case für Ministral: Qdrant findet den richtigen Candidate häufig schon, aber das Ranking bzw. die semantische Rollenbewertung braucht eine zweite Stufe. ``` ### Nachweise für sichere und souveräne KI-Anwendungen weitere Infos: /docs/KI/ki_provenance.md #### kryptografische Attestierung = Hardware-Attestation - läuft der Dienst auf eigener Hardware -> On-Premises - Trusted Execution Environments TEE: Moderne Prozessoren und Grafikkarten (z. B. von Intel, AMD oder NVIDIA Blackwell/Hopper-GPUs) besitzen sogenannte Trusted Execution Environments (TEEs). Diese TEEs stellen digitale, hardware-signierte Zertifikate (sogenannte Attestation Reports) aus. - Bei kommerziellen APIs wie Anthropic (Claude) oder Mistral AI haben Sie keinen direkten Zugriff auf deren Hardware-TEEs. Sie können TEEs hier jedoch als "Sicherheits-Proxy" (Confidential Proxy) dazwischenschalten. - Ihre Anwendung sendet die Vokabulardaten verschlüsselt an Ihre eigene TEE-Enklave in der Cloud. - Erst innerhalb dieser sicheren Enklave werden die Daten entschlüsselt. - Die Enklave bereitet den API-Request für Claude/Mistral vor und erfasst gleichzeitig die Metadaten für Ihre Run-Ebene (vollständig isoliert und manipulationssicher). - Die Enklave sendet den Request über eine verschlüsselte TLS-Verbindung (Transport Layer Security) an die Cloud-API. - Eine geschützte Enklave (oft auch einfach Hardware-Enklave genannt) ist ein isolierter, hardwareverschlüsselter Bereich im Arbeitsspeicher (RAM) und Prozessor eines Computers. ##### Architektur-Übersicht für Ihre Run-Ebene | Komponente | Ohne TEE (Aktuell) | Mit TEE-Integration | Sicherheitsgewinn | |---|---|---|---| | Lokales Ollama | Läuft im normalen RAM; Admin/Root kann Daten & Modell auslesen. | Läuft in Hardware-Enklave (z. B. AMD SEV-SNP). | Speicher ist hardwareverschlüsselt. | | API-Metadaten | Werden von einem Skript auf Betriebssystemebene erfasst. | Werden innerhalb einer geschützten Enklave geschrieben und signiert. | Metadaten sind fälschungssicher (Audit-Trail). | | Cloud-API Daten | Werden direkt vom Host an die API gesendet. | Werden über einen Confidential Proxy geschleust. | Keine Datenleckage auf dem Weg zur API-Schnittstelle. | ##### Konkrete nächste Schritte für die Umsetzung 1. Nutzen Sie bestehende Frameworks: Versuchen Sie nicht, TEE-Code (wie Intel SGX SDK) selbst in C/C++ zu schreiben. Nutzen Sie stattdessen Frameworks wie Gramine oder Anjuna. Diese erlauben es, bestehende Anwendungen (wie Ihre Python-Skripte, Node.js oder Ollama) ohne Code-Änderungen in einer TEE-Enklave auszuführen. 2. Krypto-Verankerung für Metadaten: Lassen Sie die TEE-Enklave, die Ihre Metadaten erfasst, einen kryptografischen Schlüssel erzeugen. Jeder Metadaten-Eintrag wird von der Enklave signiert. So können Sie später mathematisch beweisen, dass die Metadaten auf der Run-Ebene nicht nachträglich verändert wurden (Attestation). #### Organisatorisch - **BSI AIC4** (Kriterienkatalog für KI-Cloud-Dienste -> Bundesamt für Sicherheit in der Informationstechnik (BSI): https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Kuenstliche-Intelligenz/AIC4/aic4.html - Artificial Intelligence Cloud Service Compliance Criteria Catalogue - C5: Der C5 formuliert allgemeine Mindestanforderungen an sicheres Cloud Computing, welche für jeden Cloud-Dienst relevant sind. Der AIC4 hingegen ergänzt spezielle Kriterien, die zusätzlich relevant sind, falls Methoden des maschinellen Lernens verwendet werden. Der AIC4 ist damit eine inhaltliche Erweiterung des C5. Die C5-Kriterien werden innerhalb des AIC4 nicht repliziert, sondern es werden lediglich die KI-spezifischen Kriterien dargestellt. Hierbei kommt es auch vor, dass Kriterien aus dem C5 inhaltlich erweitert werden. - **ISO/IEC 42001**: Der weltweite Standard für KI-Managementsysteme verpflichtet Anbieter zur Offenlegung und Zertifizierung ihrer Systemarchitektur (inklusive Dokumentation der Datenflüsse zwischen Lokal- und Cloud-Komponenten ## Orte Ich sehe in den fünf Beispielen bereits mindestens vier unterschiedliche Typen von Ortsinformationen. | Beispiel | Typ | Bemerkung | | ------------------------------- | --------------------------- | ------------------------------------- | | Theaterplatz 14, Aachen | vollständige Adresse | klassischer Geocoder | | Unter den Birken 221a, Hahnwald | vollständige Adresse | ebenfalls einfach | | Bismarckstr. 28 + Mülheim | Straße aus dem Titel | muss vorher erkannt werden | | Brauweiler Straße + Sinthern | Straßenname ohne Hausnummer | Mittelpunkt? Straßengeometrie? | | Schloss Burg an der Wupper | Objektname | Gazetteer-Suche, kein Adress-Geocoder | ### zu RAG #### Ziel Das LLM soll nicht die Wissensquelle ersetzen, sondern die aus einer kontrollierten Wissensquelle gelieferten Candidates beurteilen. Bei Reconcilix wäre es allerdings eine sehr kontrollierte RAG-Variante. Ihr wollt Mistral ja gerade nicht frei Wissen abrufen oder neue Zielbegriffe generieren lassen. Qdrant bestimmt zunächst den Kandidatenraum, beispielsweise zehn MCT-Concepts. Mistral soll anschließend innerhalb dieses Kandidatenraums argumentieren. ```text SourceValue + Context │ ▼ Retrieval Vector Search / Qdrant │ ▼ relevante Candidates │ ▼ Augmentation Candidates + SourceValue + Context werden dem LLM übergeben │ ▼ Generation / Reasoning Mistral bewertet die Candidates │ ▼ Plausibilisierung / Entscheidungsunterstützung ``` Das ist für Rx ein wichtiger Unterschied zu einem offenen RAG-System: ``` klassisches RAG Retrieval → Kontext → LLM erzeugt Antwort Rx Candidate Discovery → Candidate Re-Ranking → LLM Candidate Assessment → strukturierte Entscheidung ``` Vector Search = Retrieval → Reranker = Retrieval-Optimierung → Mistral = kontextbezogenes Candidate Assessment. ### #### Datensouveränität Kulturerbedaten müssen für KI-Verarbeitung nicht unkontrolliert an kommerzielle Clouds übertragen werden. #### Nachvollziehbarkeit Discovery, Reranking, LLM-Assessment und Expert:innenentscheidung sollen mit ihren Inputs, Outputs und Konfigurationen nachvollziehbar bleiben. #### Code-Transparenz Die technische Umsetzung soll überprüfbar sein; die Einsicht in den Quellcode wird dabei von den Rechten zur kommerziellen Nutzung getrennt. ### Beispiel Marienkapelle 20260902 SourceValue: Marienkapelle ``` Qdrant 1. Marienkapelle 0.99919409 2. Mariensäule 0.15421087 3. Votivkapelle 0.05236159 ... xTree 1. Marienkapelle 0.80000000 LocalStore 1. Marienkapelle 1.00000000 GND 1. Marienkapelle 2. Würzburg / Marienkapelle ``` ### Matching ``` DISCOVERY → findet Candidates MATCHING → entscheidet über Candidates ``` Fokus Score ``` CandidateItem.score = Evidenz/Score aus Discovery MatchDecision.confidence = Vertrauen in eine konkrete Matching-Entscheidung ``` ### Discovery-Familien xTree / MySQL → einfache lexikalische Discovery Solr → indexed lexical / fuzzy retrieval QLever → Knowledge-Graph-/SPARQL-basierte Discovery Qdrant → Vector Discovery ### Recall Natural Fulltext erweitert Recall, aber erzeugt ohne weitere Kontrolle auch erheblichen False-Positive-Anteil. - Recall (Vollständigkeit): Finden wir alles? (Es ist egal, wie viel Müll bei den Ergebnissen dabei ist, solange kein relevanter Treffer vergessen wird). - Precision (Genauigkeit): Ist das, was gefunden wurde, korrekt? (Es ist egal, ob wir Ergebnisse vergessen haben, aber die angezeigten Treffer müssen exakt stimmen).