161 lines
9.2 KiB
Markdown
161 lines
9.2 KiB
Markdown
# 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.
|