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

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.
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.
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.
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.

9.2 KiB Raw Permalink Blame History