Measure package and prompt redundancy in retained trials

docs/redundancy-audit-20261016.md

@@ -0,0 +1,160 @@
+# Redundanzbilanz vom 16.10.2026
+
+## Umfang und Methode
+
+Vier erhaltene, durch PackageReader validierte Case-Pakete untersucht: Bug 20 g108
+(alter investigation_v1-Stand) und Bug 17 g124 (v9), g110 (v10), g148 (v11).
+Keines ist ein abgeschlossenes OUTPUT_READY-Paket. Der neueste Stand dient als
+Hauptbeispiel; ältere Versionen sind keine gleichwertigen Qualitätsbenchmarks.
+Keine LLM-Aufrufe, kein Umbau oder Löschen von Paketinhalt.
+
+Reproduzierbares Werkzeug: `scripts/redundancy_audit.py`, Aufruf mit einem oder
+mehreren Paketpfaden und `--output <bericht.json>`.
+Aggregierte Messdaten ohne Quelltext-/Promptinhalte:
+`measurements/redundancy-audit-20261016.json`.
+Messstand: Code nach fa1a0ab, historische Pakete und Prompts unverändert.
+Alle MB/KB/GB dezimal, alle Textmessungen UTF-8-Bytes, keine Tokenzählung.
+
+## 1. Paketgröße und fehlende Kompression
+
+| Paket | Dateien | ZIP auf Platte | DEFLATE-6-Payload, simuliert |
+|---|---:|---:|---:|
+| Bug 20 g108 | 517 | 63,22 MB | 20,17 MB |
+| Bug 17 g124 | 576 | 34,61 MB | 9,97 MB |
+| Bug 17 g110 | 547 | 33,61 MB | 9,79 MB |
+| Bug 17 g148 | 658 | 36,56 MB | 10,32 MB |
+
+**Alle ZIP-Einträge verwenden ZIP_STORED, also keine ZIP-Kompression.** Die
+Simulation komprimiert jeden Eintrag separat mit raw DEFLATE, Stufe 6, und prüft
+für jeden Eintrag die byteidentische Dekompression. ZIP-Header/Verzeichnis kommen
+zur simulierten Payload hinzu. Beim jüngsten Paket ergeben sich damit ungefähr
+10,53 MB statt 36,56 MB, rund 71 % weniger Speicher. Dies ist keine Änderung am
+Format oder am Inhalt und reduziert keine LLM-Tokens. Laufzeitkosten und die
+Writer-/Sicherheitsprüfungen wären bei einer Implementierung zu testen.
+
+## 2. Zusammensetzung des neuesten Pakets
+
+| Inhalt Bug 17 g148 | Bytes in MB | Anteil an 36,34 MB Dateiinhalten |
+|---|---:|---:|
+| Entpackte Originaldateien | 18,576 | 51,1 % |
+| Ursprüngliche TAR.GZ-Archive | 5,224 | 14,4 % |
+| Investigation-Kontexte | 7,686 | 21,1 % |
+| Weitere Analyseartefakte | 2,104 | 5,8 % |
+| Gespeicherte LLM-Requests | 1,896 | 5,2 % |
+| Aufbereiteter Case | 0,406 | 1,1 % |
+| Sonstiges: Historie, Forschung, LLM-Ergebnisse, Manifest | 0,450 | 1,2 % |
+
+Die ZIP-Verzeichnis-/Headerdaten ergänzen weitere 0,214 MB.
+Die größte einzelne Datei ist das originale wowsrc `source/hits.json` mit
+5,015 MB. Weitere große Originaldateien sind Code-/SQL-Referenzsammlungen.
+Ihre fachliche Relevanz wurde hier nicht beurteilt.
+
+### Exakte Duplikate versus doppelte Repräsentationen
+
+- Byteidentische vollständige Dateien: nur **0,185 MB** zusätzliche Kopien im
+  neuesten Paket. Reines Deduplizieren ganzer Dateien löst das Hauptproblem nicht.
+- **225 entpackte Originaldateien mit 18,576 MB** sind zusätzlich byteidentisch
+  innerhalb der beiden archivierten TAR.GZ-Dateien vorhanden. Das ist eine
+  doppelte Repräsentation derselben Originaldaten. Die TAR.GZ-Dateien selbst
+  belegen 5,224 MB; diese Werte dürfen nicht als zwei unabhängige Einsparungen
+  addiert werden. Eine neue Referenz-/Lesestrategie wäre nötig, um eine Kopie
+  wegzulassen. Bestehende Originaldateien dürfen gemäß Architektur nicht gelöscht
+  werden. Bei neuen Paketen wäre eine bewusste Import-/Formatentscheidung nötig.
+- **5,097 MB kanonisch identische Feldwerte** werden allein durch wiederholte
+  Speicherung von `case`, `case_sources`, `tool_schema` und `interpretation` in
+  den 17 Investigation-Kontexten zusätzlich abgelegt. Das ist eine Untergrenze
+  für Kontextredundanz: wachsende Evidenzlisten enthalten weitere wiederholte
+  Unterobjekte. Neu entworfene Kontexte könnten auf unveränderliche Artefakte
+  innerhalb desselben Pakets verweisen, statt diese jedes Mal einzubetten.
+- Kontext-Snapshot und daraus erzeugter Request speichern teilweise dieselben
+  Inhalte in verschiedenen Darstellungen. Diese Überlappung ist nachweisbar,
+  aber hier nicht als zusätzliche unabhängige Einsparsumme quantifiziert.
+
+## 3. Aktuelle Investigation-Prompts
+
+17 gespeicherte v11-Requests ergeben **1,401 MB Nachrichteninhalt** (System und
+User, ohne äußere JSON-Transporthülle). Die einzelnen Aufrufe wachsen von
+54,1 KB auf 105,0 KB. Bei der bestehenden Cache-Partition wächst die separat
+gelieferte Live-Darstellung von 6,2 KB auf 63,2 KB; diese Transportmessung enthält
+eine andere JSON-Hülle und ist deshalb kein direkter Summand der 1,401 MB.
+
+### Wiederholung zwischen Aufrufen
+
+| Komponente | Insgesamt | Unterschiedliche vollständige Werte | Wiederholt |
+|---|---:|---:|---:|
+| Aufbereitete Quellen `sources` | 338,2 KB | 19,9 KB | 318,3 KB |
+| Output-Schema | 150,0 KB | 8,8 KB | 141,2 KB |
+| Interpretation | 63,8 KB | 3,8 KB | 60,0 KB |
+| Evidenzobjekte, einzeln verglichen | 218,8 KB | 29,5 KB | 189,3 KB |
+| Quellcodezeilen in `shared_sources` | 92,7 KB | 8,0 KB | 84,7 KB |
+
+Evidenzobjekte werden einzeln nach kanonischem JSON verglichen. Quellcodezeilen
+werden nach Quellmetadaten, Zeilennummer und Inhalt verglichen, nicht allein nach
+Zeilentext. 3.352 Zeilenvorkommen entsprechen 280 unterschiedlichen belegten
+Zeilen. Alle Werte enthalten weiterhin die notwendigen unterschiedlichen Daten;
+ein Übertragungsprotokoll benötigt zusätzlich IDs/Referenzen und Cache-Verwaltung.
+
+**Die statischen Wiederholungen sind zum großen Teil bereits durch den stabilen
+Fallcache abgedeckt.** Im zugehörigen vorangegangenen Live-Test meldeten alle
+17 Investigation-Antworten 19.987 gecachte Eingabetokens. Die gespeicherten
+Requests enthalten trotzdem die vollständige kanonische Anfrage für die
+Nachvollziehbarkeit. Ihre Größe darf nicht mit erneut ungecacht übertragenen
+oder voll berechneten Tokens gleichgesetzt werden.
+
+Die Evidenz und Codezeilen liegen dagegen in der veränderlichen Live-Darstellung.
+Ein weiterer Ansatz ist ein versionierter Recherche-Cache beziehungsweise eine
+exakt rekonstruierbare Aufteilung in bereits bekannte und neu hinzugekommene
+Belege. Nicht einfach Belege weglassen: Der frühere Versuch mit selektiver
+Historie führte zu Nachladeproblemen und wurde ausdrücklich zurückgenommen.
+
+### Wiederholung innerhalb eines Aufrufs und JSON-Struktur
+
+Exakt identische längere Stringwerte (ab 80 UTF-8-Bytes) wiederholen sich in den
+17 v11-User-Dokumenten zusammen um **10,5 KB**, entsprechend **0,75 %** des
+gesamten System-/User-Nachrichteninhalts. Der Wert ist kein vollständiges Maß
+aller Redundanz: kurze Codezeilen, ähnliche Texte und überlappende Strukturen
+werden nicht als identische lange Strings erkannt. Eine Ersetzung bräuchte
+Referenzen und würde weniger als diese Bruttosumme sparen.
+
+Zum Vergleich: Die alte Bug-20-Investigation v1 enthält 1,310 MB solcher
+wiederholter Strings bei 4,123 MB Nachrichteninhalt, rund 31,8 %. Dieser konkrete
+Mechanismus wurde in der aktuellen Darstellung also bereits stark reduziert.
+Die Fälle/Anzahl der Schritte sind verschieden; daraus folgt kein kontrollierter
+Qualitäts- oder Kostenvergleich.
+
+Allein die JSON-Schlüsselnamen samt Anführungszeichen und Doppelpunkt belegen
+bei v11 insgesamt **415,4 KB**, rund 29,7 % des Nachrichteninhalts. Das ist kein
+versprochenes Einsparpotenzial von 29,7 %: Schlüssel sind für Bedeutung und
+Schema nötig; Kürzungen benötigen ein verständliches gemeinsames Wörterbuch.
+Der Wert zeigt aber, dass noch erhebliche Strukturkosten existieren. Beispiele
+sind wiederkehrende Fakt-/Quellprovenienz und Evidenz-Records. Innerhalb aller
+übermittelten Evidenzobjekte belegen `record` 72,9 KB und `record_ref` 13,7 KB,
+während `content` 127,4 KB belegt (zzgl. Schlüssel/Struktur).
+
+## 4. Konsequenzen und Reihenfolge
+
+1. **ZIP-Kompression und Aufbewahrung vollständiger Generationen:** großer,
+   direkt messbarer Speichergewinn ohne Informationsverlust. Die 20-GB-Regel
+   gilt unabhängig davon weiter. Keine Auswirkung auf API-Tokenkosten.
+2. **Gespeicherte Kontexte referenzieren unveränderliche Paketartefakte:**
+   Fallbasis/Schemas einmal, je Schritt nur Änderungen und Referenzen. Eine
+   Rekonstruktion muss exakt sein und auch nach Transport/Neustart funktionieren.
+   Keine Abhängigkeit von einem externen Dienstgedächtnis.
+3. **Live-Recherchekontext effizienter übermitteln:** die 189,3 KB wiederholten
+   Evidenzobjekte und 84,7 KB wiederholten Quellzeilen sind konkrete Ansatzpunkte.
+   Diese Zahlen und die Strukturkosten überlappen teilweise; nicht addieren.
+   Zuerst verlustfreie Struktur-/Cache-Ansätze prüfen, erst danach inhaltliche
+   Auswahl mit nachgewiesener Qualität. Nicht den gesamten bisherigen Befund
+   erneut durch eine zusätzliche LLM zusammenfassen lassen.
+4. **Provenienz für das Modell reduzieren:** doppelt mitgesendete interne
+   Speicherpfade, ausführliche Records und technische Verwaltungsfelder anhand
+   ihrer tatsächlich nötigen Funktion prüfen. Die vollständige Provenienz bleibt
+   in der Akte; Beleg-ID, Quelle, Abfrageumfang und Versionsbezug müssen für die
+   LLM verständlich bleiben. Das ist eine Designentscheidung, keine bereits
+   validierte verlustfreie Ersetzung.
+
+Es gibt aktuell keine belastbare Grundlage, eine Einsparung in Euro für diese
+Schritte zu versprechen. Die vier vorhandenen Pakete erklären die Speicher- und
+Textredundanz; sie zeigen nicht, welche fachlichen Informationen gefahrlos
+entfallen dürfen. Ein nachfolgender Qualitätstest muss diese Frage getrennt
+prüfen. An produktivem Verhalten wurde für diese Bilanz nichts geändert.