Modellvergleich beim Ingest unter GitHub Copilot – Messung und Bericht: Gold prüfen, P0–P6 mit 50-USD-Deckel, Folgerung für #21 #240

New Issue

2026-10-21T04:48:18Z

torben commented

2026-10-21 04:48:18 +00:00

Zweiter Teil des Ingest-Modellvergleichs, am 2026-10-21 aus #228 abgespalten (Betreiber). #228 baut das Werkzeug in torben/chemenu-testfiles/harness/ingest-bench/: Runner, Goldinventar-Herstellung, Kennzahlen, Richter, Bericht und den Claude-Entwurf des Goldinventars A. Dieses Issue betreibt es: Gold fertigstellen und prüfen, bezahlte Läufe, Bewertung, Bericht. Ändert den Stack nicht; es liefert die Daten, auf denen #21 entscheidet.

War blockiert durch #228, weil ohne Runner, gold.py und judge.py nichts davon läuft. #228 ist seit 2026-10-21 geschlossen (chemenu-testfiles ba1eb95). Werkzeug, Warteschlange, Deckelregel, Methode des Goldinventars und Bewertungsregeln stehen in #228 und gelten hier unverändert. Drei Korrekturen und Ergänzungen am Werkzeug stehen in § Stand: Der GPT-Prompt geht über stdin, die Kosten werden aus der echten usage.json gelesen, und merge nimmt Hinweise für den Prüfbogen an. Dieses Issue sagt, wer was in welcher Reihenfolge tut und was am Ende im Bericht steht.

Fragen

Wie viel Information verliert ein Ingest abhängig von Modell × Effort? Schon bei kleinen Eingaben, und bei langen im kapitelweisen Pfad?
Auto: Der Betreiber hat unter Copilot Auto ein subjektives Qualitätsproblem beim Ingest. Die Vermutung: Das Routing schätzt die Komplexität am Anfang ein („ingest X“ sieht einfach aus) und wählt deshalb ein zu kleines Modell. Stimmt das, und wechselt Auto im Lauf das Modell? Laut GitHub routet Auto auch während einer Unterhaltung um (#228 § Was über Copilot feststeht). Gemessen ist das hier noch nicht.
Wo liegt die Pareto-Front Recall gegen Kosten? Welches Modell ist für Ingest „gut genug“ zum niedrigsten Preis? Und holt ein günstiges Modell mit mehr Effort ein mittleres ein?
Seitenlänge: Der Betreiber hat bei Luna den Eindruck, dass die KB-Seiten zu kurz ausfallen. Das ist ein Eindruck, nicht gemessen. Schreiben günstige Modelle kürzer, und vor allem: Verlieren sie dadurch Fakten, oder schreiben sie nur dichter?

Ablauf

Das geht über mehrere Sitzungen und Tage, und ein Teil davon hängt am Betreiber. Wo die Arbeit gerade steht, steht in § Stand, nicht in den Kommentaren.

Alles läuft auf dem Windows-Desktop des Betreibers (Entscheidung 2026-10-23): Stack-Checkout mit tools\.venv und bestandenem Preflight, chemenu-testfiles als testfiles\ darin, copilot per Chocolatey (Shim auf das native c:\tools\githubcopilotcli\copilot.exe, kein cmd.exe dazwischen), claude angemeldet. Wo eine Session nur Dateien bearbeitet (Paare zuordnen, Auswertung), kann sie auch unter Linux laufen, nach git pull in testfiles.

Wer die Goldinventare macht: Beide Extraktionen laufen als eigene Aufrufe (claude -p, copilot) mit festem Prompt, nicht in der Session. Die Session kennt die Fragen und Kandidaten, und ihre Extraktion wäre davon gefärbt. Zwei Hersteller verhindern, dass das Gold Claude-Kandidaten bevorzugt. Die Session ordnet nur die Paare zu. Was als wahr gilt, entscheidet die Prüfung durch den Betreiber.

#	Schritt	Wer
1	Gold A fertigstellen: zweite Extraktion mit GPT-6.1 Sol (`gold.py`, Budgetzeile „Gold“), Zusammenführung, Abdeckungsprüfung, Prüfbogen erzeugen	Session, Betreiber startet den Copilot-Teil
2	Prüfbogen A vollständig prüfen und einfrieren	Betreiber im Editor oder in der Gitea-Weboberfläche von `chemenu-testfiles`, danach Session (`gold.py apply`)
3	P0 Kalibrierung	Betreiber startet `bench.py`, Session wertet aus
4	Nach P0: Der Runner ersetzt die Schätzungen durch gemessene Kosten. Hat er angehalten, weil P0 mehr als doppelt so viel kostete wie geschätzt, wird die Warteschlange neu geschnitten.	Session schlägt im Chat vor, Betreiber entscheidet
5	P1, P2, Richter 1 auf diesen Läufen	`bench.py`; Session
6	Der Runner hält nach P2 an: beste Konfigurationen für P4–P6 festlegen	Session schlägt anhand der Urteile vor, Betreiber bestätigt
7	Gold B und IHF-Kapitel: Kapitelwahl, beide Extraktionen, Prüfung im Stichprobenumfang (#228 § Goldinventar), einfrieren, bevor P4 bzw. P6 starten	Session und Betreiber
8	P3–P6; Desktop App × 2 von Hand (P3)	`bench.py`; Betreiber für die App-Läufe
9	Bewertung fertig: Richter 1 für alle Läufe, Richter 2 für Claude-Kandidaten, Betreiber entscheidet Widersprüche und prüft die geschichtete Stichprobe	Session und Betreiber
10	Bericht als Kommentar hier; Folgerung als Body-Update in #21	Session

Ergebnisse, Inventare und Prüfbögen werden per git in chemenu-testfiles committet und gepusht (#228 § Abschluss der Bauphase sagt, warum dort nicht wikitool publish gilt). Ins Chemenu-Repo geht nichts.

Stand

Letzte Sitzung: 2026-10-23 (Linux; Stack 10.1.1-beta.2, chemenu-testfiles f2c7133).

Verbraucht (Copilot): 0,1639 USD von 50 (Arbeitsgrenze 45). Davon 0,1614 für die GPT-Extraktion von Gold A und 0,0025 für zwei Prüfaufrufe auf Luna (results/ledger.json).
Werkzeug: 43 Tests des Harness grün gegen Stack 10.1.1-beta.2. Ein Trockenlauf bis zum Halt nach P0 geht durch die neue Kostenrechnung. bench.py plan schätzt bis P6 47,06 USD; nach P0 neu ansehen (Kommentar vom 2026-10-21).
Korrektur 1 – GPT-Prompt über stdin (8b1f36c): [llm.gpt] übergab den Prompt als Argument von copilot -p. Eine Windows-Kommandozeile endet bei 32 767 Zeichen. Der Extraktionsprompt für Gold A hat 29 139 Zeichen, und Richter 2 liegt immer darüber. Jetzt geht der Prompt über stdin, ohne -p. Auf dem Rechner des Betreibers geprüft: Die CLI beantwortet einen über die Pipe übergebenen Prompt und beendet sich. Die Antwort steht auf stdout, die Statuszeilen auf stderr. Umlaute kommen über stdin unversehrt an; die GPT-Extraktion hat es gezeigt.
Korrektur 2 – Kosten aus der echten usage.json (8b1f36c): Die erste echte Datei (testdata/usage-copilot.json) wurde 360-mal zu teuer gerechnet. Der Modellname wurde als „usage“ gelesen und zum Opus-Preis gerechnet, die Zahlen dreifach gezählt (modelMetrics, agentMetrics, providerModelMetrics), und inputTokens enthält die Cache-Tokens schon. Jetzt gilt: Kosten = totalNanoAiu / 10⁹ Credits. Tokens je Modell kommen aus modelMetrics.<modell>.tokenDetails. Die Preistabelle in queue.toml trifft diese Datei genau auf ihren totalNanoAiu; für Luna ist sie damit bestätigt. Der Stub schreibt dieselbe Form. Die Feldnamen der usage.json sind damit vor P0 geprüft; für P0 bleiben Flags, Modellliste, Effort-Matrix und Standard-Effort.
Ergänzung 3 – Hinweise beim Zusammenführen (f2c7133): merge kennt nur 1:1-Paare. Wo eine Seite aufteilt, was die andere zusammenfasst, bleiben beide Fassungen ungepaart; die Altersklassen-Tabelle ist der Hauptfall, weil GPT F und E bei gleichem Wert verbindet. Neben paare: nimmt die Paardatei jetzt hinweise: an. Das sind Notizen je Extraktions-Id, die mit den Fakten umnummeriert werden. Im Prüfbogen stehen sie als „hinweis (Session, keine Entscheidung)“. Die Richter sehen sie nicht.
Gold A – Schritt 1 erledigt: GPT-Extraktion mit 109 Fakten, davon 51 kritisch. Zusammengeführt mit Claudes 116 Fakten über 81 Paare (gold/bhv-dfb-2026-teil3.pairs.yaml). Inventar: 144 Fakten, davon 81 von beiden, 35 nur von Claude und 28 nur von GPT; 45 mit strittigem Feld (bedingung 29, zahl 17, modalitaet 12, kritisch 5, ausnahme 5); 57 mit Hinweis; 31 kein_fakt; Abdeckungsprüfung grün. Die Session empfiehlt dem Betreiber die Regel „atomar gewinnt“: Von zwei Fassungen bleibt die mit je einer Aussage pro Fakt. Nächster Schritt: Der Betreiber prüft gold/bhv-dfb-2026-teil3.review.md vollständig; danach gold.py apply.
Gold B / IHF-Kapitel: nicht begonnen
P0–P6, Richter 2: offen
Bericht: offen

Jede Sitzung bringt diesen Abschnitt auf den Stand, den sie verlässt: Verbrauch laut usage.json-Summe, gelaufene Einträge, Hashes der eingefrorenen Inventare und Entscheidungen zur Warteschlange.

Auswertung

Je Lauf, aus report.py: Recall gesamt und kritisch, absolut und relativ zu Opus 5.5; kritische Verfälschungen nach Art; Seitenbild; Seitenlänge und Faktendichte; Lauf vollständig ja/nein; erreichte Gates; Kosten in Credits; Tokens je Position; Laufzeit; angewendete Effort-Stufe; Modellfolge bei Auto und HydraFusion.

Die Auto-Frage (2): Auto-Läufe werden gegen fest eingestellte Läufe derselben Modelle gelegt. Läuft Auto fast nur auf Luna und liegt sein Recall auf Luna-Niveau, ist die Vermutung bestätigt. Ob das Routing auf einen Prompt reagiert, der den Umfang benennt, zeigt dann der P7-Lauf, falls der Rest des Budgets reicht. Sonst steht das als offene Folgefrage im Bericht. Erfasst die CLI das Modell nicht je Anfrage, wird die Frage über modelMetrics der usage.json oder die Modellanzeige je Antwort im JSON-Protokoll beantwortet, oder als nicht messbar festgehalten.

Die Längenfrage (4): ein Streudiagramm Wörter gesamt gegen Recall über alle Läufe. Der Bericht nennt genau einen der drei Befunde:

kurz und verlustreich: Der Eindruck stimmt, die Länge ist das Symptom.
kurz und dicht: Der Eindruck stimmt, kostet aber keine Fakten.
nicht kürzer: Der Eindruck stimmt nicht.

Opus 5.5 ist die obere Referenz, nicht das Maß. Gemessen wird gegen das Goldinventar, berichtet wird beides.

Invarianten

origin/main des Chemenu-Repos ist unverändert. Kein Lauf hat gepusht, kein Seiteninhalt aus einem Lauf liegt in kb/ des Ursprungs-Repos oder einer echten Instanz des Betreibers.
Die CLI- und App-Konfiguration des Betreibers (Modell, Effort, Auto-Tier) ist nach dem Vergleich dieselbe wie davor.
Der Copilot-Verbrauch bleibt unter 50 USD, gemessen an der Summe aus usage.json und am Ende gegengeprüft mit /usage. Kein Lauf startet über der Deckelregel aus #228. Läufe darüber hinaus gibt nur der Betreiber frei, mit einem neuen Deckel in diesem Body. Jeder Copilot-Aufruf außerhalb des Runners, auch ein Prüfaufruf, steht im Ledger.
Ein eingefrorenes Inventar ändert sich nur durch eine erneute Prüfung des Betreibers. Jede Messung nennt den Hash, gegen den sie bewertet wurde.
Fixtures, Inventare, Prüfbögen und Rohergebnisse verlassen chemenu-testfiles nicht, auch nicht als claude.ai-Artifact. In diesem öffentlichen Tracker stehen nur Zahlen und Folgerungen.
Ein Harness-Abbruch (Zeitlimit) wird nur mit Zustimmung des Betreibers wiederholt.

Akzeptanzkriterien

Goldinventar A vom Betreiber vollständig geprüft und eingefroren. Regel 16 und die zwei weiteren Kapitel im Stichprobenumfang aus #228 geprüft und eingefroren; Kapitelwahl samt Begründung im Kopf von gold/ihf-kapitel.yaml.
P0 belegt mit tatsächlichen Kommandos und Ausgaben vom Rechner des Betreibers: Flags, Modellliste, Effort-Matrix, Standard-Effort je Modell, gemessene Kosten für Luna und Sonnet 5.5, und ob das Modell je Anfrage erfasst wird.
P1–P6 gelaufen, soweit der Deckel reicht. Was er abgeschnitten hat, steht im Bericht.
Die Übereinstimmung Richter ↔ Betreiber auf der Stichprobe steht im Bericht.
Bericht als Kommentar hier: Tabelle Modell × Effort × Fixture mit Recall (gesamt/kritisch), Verfälschungen, Seitenlänge, Faktendichte und Kosten; Pareto-Diagramm Recall/Kosten; Streudiagramm Länge/Recall mit dem Befund zu Frage 4; Befunde zu Auto, HydraFusion und Desktop App.
Folgerung als Body-Update in #21. status/blocked auf #21 aufgehoben.
Jeder Harness-Abbruch unter Windows ist mit Protokoll in #167 eingetragen.
Die Invarianten oben halten, insbesondere: Gesamtverbrauch unter 50 USD, Konfiguration des Betreibers unverändert.
Kein Versions-Bump im Stack.

Versionsteil

Keiner. Es ändert sich keine Datei des Stacks. Zeigt ein Lauf einen Defekt im Stack, bekommt er ein eigenes Issue oder geht in das passende Themen-Issue.

Verwandt

#228 (Werkzeug, Vorgänger), #224 (Ursprung), #21 (Abnehmer, wartet mit status/blocked auf dieses Issue), #167 (Windows-Dialog unter Copilot CLI: Die Läufe hier liefern die Reproduktion), #175 (leere Template-Abschnitte im Demo-Korpus).

Kette

Kette „Ingest-Modellvergleich“

Vorgänger: Modellvergleich beim Ingest unter GitHub Copilot – Werkzeug: Runner, Goldinventar und Bewertung in chemenu-testfiles, Trockenlauf unter Linux (#228)
Nachfolger: keiner - letztes Glied

Zweiter Teil des Ingest-Modellvergleichs, am 2026-10-21 aus #228 abgespalten (Betreiber). **#228 baut das Werkzeug** in `torben/chemenu-testfiles/harness/ingest-bench/`: Runner, Goldinventar-Herstellung, Kennzahlen, Richter, Bericht und den Claude-Entwurf des Goldinventars A. **Dieses Issue betreibt es:** Gold fertigstellen und prüfen, bezahlte Läufe, Bewertung, Bericht. **Ändert den Stack nicht**; es liefert die Daten, auf denen #21 entscheidet. **War blockiert durch #228**, weil ohne Runner, `gold.py` und `judge.py` nichts davon läuft. #228 ist seit 2026-10-21 geschlossen (`chemenu-testfiles` `ba1eb95`). Werkzeug, Warteschlange, Deckelregel, Methode des Goldinventars und Bewertungsregeln stehen in #228 und gelten hier unverändert. Drei Korrekturen und Ergänzungen am Werkzeug stehen in § Stand: Der GPT-Prompt geht über stdin, die Kosten werden aus der echten `usage.json` gelesen, und `merge` nimmt Hinweise für den Prüfbogen an. Dieses Issue sagt, wer was in welcher Reihenfolge tut und was am Ende im Bericht steht. ## Fragen 1. Wie viel Information verliert ein Ingest abhängig von **Modell × Effort**? Schon bei kleinen Eingaben, und bei langen im kapitelweisen Pfad? 2. **Auto:** Der Betreiber hat unter Copilot Auto ein subjektives Qualitätsproblem beim Ingest. Die Vermutung: Das Routing schätzt die Komplexität am Anfang ein („ingest X“ sieht einfach aus) und wählt deshalb ein zu kleines Modell. Stimmt das, und wechselt Auto im Lauf das Modell? Laut GitHub routet Auto auch während einer Unterhaltung um (#228 § Was über Copilot feststeht). Gemessen ist das hier noch nicht. 3. Wo liegt die **Pareto-Front Recall gegen Kosten**? Welches Modell ist für Ingest „gut genug“ zum niedrigsten Preis? Und holt ein günstiges Modell mit mehr Effort ein mittleres ein? 4. **Seitenlänge:** Der Betreiber hat bei Luna den Eindruck, dass die KB-Seiten zu kurz ausfallen. Das ist ein Eindruck, nicht gemessen. Schreiben günstige Modelle kürzer, und vor allem: **Verlieren sie dadurch Fakten**, oder schreiben sie nur dichter? ## Ablauf Das geht über mehrere Sitzungen und Tage, und ein Teil davon hängt am Betreiber. Wo die Arbeit gerade steht, steht in § Stand, nicht in den Kommentaren. **Alles läuft auf dem Windows-Desktop des Betreibers** (Entscheidung 2026-10-23): Stack-Checkout mit `tools\.venv` und bestandenem Preflight, `chemenu-testfiles` als `testfiles\` darin, `copilot` per Chocolatey (Shim auf das native `c:\tools\githubcopilotcli\copilot.exe`, kein `cmd.exe` dazwischen), `claude` angemeldet. Wo eine Session nur Dateien bearbeitet (Paare zuordnen, Auswertung), kann sie auch unter Linux laufen, nach `git pull` in `testfiles`. **Wer die Goldinventare macht:** Beide Extraktionen laufen als eigene Aufrufe (`claude -p`, `copilot`) mit festem Prompt, nicht in der Session. Die Session kennt die Fragen und Kandidaten, und ihre Extraktion wäre davon gefärbt. Zwei Hersteller verhindern, dass das Gold Claude-Kandidaten bevorzugt. Die Session ordnet nur die Paare zu. Was als wahr gilt, entscheidet die Prüfung durch den Betreiber. | # | Schritt | Wer | |---|---|---| | 1 | **Gold A fertigstellen:** zweite Extraktion mit GPT-6.1 Sol (`gold.py`, Budgetzeile „Gold“), Zusammenführung, Abdeckungsprüfung, Prüfbogen erzeugen | Session, Betreiber startet den Copilot-Teil | | 2 | **Prüfbogen A vollständig prüfen** und einfrieren | Betreiber im Editor oder in der Gitea-Weboberfläche von `chemenu-testfiles`, danach Session (`gold.py apply`) | | 3 | **P0 Kalibrierung** | Betreiber startet `bench.py`, Session wertet aus | | 4 | Nach P0: Der Runner ersetzt die Schätzungen durch gemessene Kosten. Hat er angehalten, weil P0 mehr als doppelt so viel kostete wie geschätzt, wird die Warteschlange neu geschnitten. | Session schlägt im Chat vor, Betreiber entscheidet | | 5 | **P1, P2**, Richter 1 auf diesen Läufen | `bench.py`; Session | | 6 | Der Runner hält nach P2 an: **beste Konfigurationen** für P4–P6 festlegen | Session schlägt anhand der Urteile vor, Betreiber bestätigt | | 7 | **Gold B und IHF-Kapitel:** Kapitelwahl, beide Extraktionen, Prüfung im Stichprobenumfang (#228 § Goldinventar), einfrieren, bevor P4 bzw. P6 starten | Session und Betreiber | | 8 | **P3–P6**; Desktop App × 2 von Hand (P3) | `bench.py`; Betreiber für die App-Läufe | | 9 | **Bewertung fertig:** Richter 1 für alle Läufe, Richter 2 für Claude-Kandidaten, Betreiber entscheidet Widersprüche und prüft die geschichtete Stichprobe | Session und Betreiber | | 10 | **Bericht** als Kommentar hier; **Folgerung** als Body-Update in #21 | Session | Ergebnisse, Inventare und Prüfbögen werden per `git` in `chemenu-testfiles` committet und gepusht (#228 § Abschluss der Bauphase sagt, warum dort nicht `wikitool publish` gilt). Ins Chemenu-Repo geht nichts. ## Stand Letzte Sitzung: 2026-10-23 (Linux; Stack `10.1.1-beta.2`, `chemenu-testfiles` `f2c7133`). - **Verbraucht (Copilot):** 0,1639 USD von 50 (Arbeitsgrenze 45). Davon 0,1614 für die GPT-Extraktion von Gold A und 0,0025 für zwei Prüfaufrufe auf Luna (`results/ledger.json`). - **Werkzeug:** 43 Tests des Harness grün gegen Stack `10.1.1-beta.2`. Ein Trockenlauf bis zum Halt nach P0 geht durch die neue Kostenrechnung. `bench.py plan` schätzt bis P6 47,06 USD; nach P0 neu ansehen (Kommentar vom 2026-10-21). - **Korrektur 1 – GPT-Prompt über stdin** (`8b1f36c`): `[llm.gpt]` übergab den Prompt als Argument von `copilot -p`. Eine Windows-Kommandozeile endet bei 32 767 Zeichen. Der Extraktionsprompt für Gold A hat 29 139 Zeichen, und Richter 2 liegt immer darüber. Jetzt geht der Prompt über stdin, ohne `-p`. Auf dem Rechner des Betreibers geprüft: Die CLI beantwortet einen über die Pipe übergebenen Prompt und beendet sich. Die Antwort steht auf stdout, die Statuszeilen auf stderr. Umlaute kommen über stdin unversehrt an; die GPT-Extraktion hat es gezeigt. - **Korrektur 2 – Kosten aus der echten `usage.json`** (`8b1f36c`): Die erste echte Datei (`testdata/usage-copilot.json`) wurde 360-mal zu teuer gerechnet. Der Modellname wurde als „usage“ gelesen und zum Opus-Preis gerechnet, die Zahlen dreifach gezählt (`modelMetrics`, `agentMetrics`, `providerModelMetrics`), und `inputTokens` enthält die Cache-Tokens schon. Jetzt gilt: Kosten = `totalNanoAiu` / 10⁹ Credits. Tokens je Modell kommen aus `modelMetrics.<modell>.tokenDetails`. Die Preistabelle in `queue.toml` trifft diese Datei genau auf ihren `totalNanoAiu`; für Luna ist sie damit bestätigt. Der Stub schreibt dieselbe Form. Die Feldnamen der `usage.json` sind damit vor P0 geprüft; für P0 bleiben Flags, Modellliste, Effort-Matrix und Standard-Effort. - **Ergänzung 3 – Hinweise beim Zusammenführen** (`f2c7133`): `merge` kennt nur 1:1-Paare. Wo eine Seite aufteilt, was die andere zusammenfasst, bleiben beide Fassungen ungepaart; die Altersklassen-Tabelle ist der Hauptfall, weil GPT F und E bei gleichem Wert verbindet. Neben `paare:` nimmt die Paardatei jetzt `hinweise:` an. Das sind Notizen je Extraktions-Id, die mit den Fakten umnummeriert werden. Im Prüfbogen stehen sie als „hinweis (Session, keine Entscheidung)“. Die Richter sehen sie nicht. - **Gold A – Schritt 1 erledigt:** GPT-Extraktion mit 109 Fakten, davon 51 kritisch. Zusammengeführt mit Claudes 116 Fakten über 81 Paare (`gold/bhv-dfb-2026-teil3.pairs.yaml`). Inventar: 144 Fakten, davon 81 von beiden, 35 nur von Claude und 28 nur von GPT; 45 mit strittigem Feld (`bedingung` 29, `zahl` 17, `modalitaet` 12, `kritisch` 5, `ausnahme` 5); 57 mit Hinweis; 31 `kein_fakt`; Abdeckungsprüfung grün. Die Session empfiehlt dem Betreiber die Regel „atomar gewinnt“: Von zwei Fassungen bleibt die mit je einer Aussage pro Fakt. **Nächster Schritt:** Der Betreiber prüft `gold/bhv-dfb-2026-teil3.review.md` vollständig; danach `gold.py apply`. - **Gold B / IHF-Kapitel:** nicht begonnen - **P0–P6, Richter 2:** offen - **Bericht:** offen Jede Sitzung bringt diesen Abschnitt auf den Stand, den sie verlässt: Verbrauch laut `usage.json`-Summe, gelaufene Einträge, Hashes der eingefrorenen Inventare und Entscheidungen zur Warteschlange. ## Auswertung **Je Lauf**, aus `report.py`: Recall gesamt und kritisch, absolut und relativ zu Opus 5.5; kritische Verfälschungen nach Art; Seitenbild; Seitenlänge und Faktendichte; Lauf vollständig ja/nein; erreichte Gates; Kosten in Credits; Tokens je Position; Laufzeit; angewendete Effort-Stufe; Modellfolge bei Auto und HydraFusion. **Die Auto-Frage (2):** Auto-Läufe werden gegen fest eingestellte Läufe derselben Modelle gelegt. Läuft Auto fast nur auf Luna und liegt sein Recall auf Luna-Niveau, ist die Vermutung bestätigt. Ob das Routing auf einen Prompt reagiert, der den Umfang benennt, zeigt dann der P7-Lauf, falls der Rest des Budgets reicht. Sonst steht das als offene Folgefrage im Bericht. Erfasst die CLI das Modell nicht je Anfrage, wird die Frage über `modelMetrics` der `usage.json` oder die Modellanzeige je Antwort im JSON-Protokoll beantwortet, oder als nicht messbar festgehalten. **Die Längenfrage (4):** ein Streudiagramm Wörter gesamt gegen Recall über alle Läufe. Der Bericht nennt genau einen der drei Befunde: - *kurz und verlustreich:* Der Eindruck stimmt, die Länge ist das Symptom. - *kurz und dicht:* Der Eindruck stimmt, kostet aber keine Fakten. - *nicht kürzer:* Der Eindruck stimmt nicht. **Opus 5.5 ist die obere Referenz, nicht das Maß.** Gemessen wird gegen das Goldinventar, berichtet wird beides. ## Invarianten - `origin/main` des Chemenu-Repos ist unverändert. Kein Lauf hat gepusht, kein Seiteninhalt aus einem Lauf liegt in `kb/` des Ursprungs-Repos oder einer echten Instanz des Betreibers. - Die CLI- und App-Konfiguration des Betreibers (Modell, Effort, Auto-Tier) ist nach dem Vergleich dieselbe wie davor. - **Der Copilot-Verbrauch bleibt unter 50 USD**, gemessen an der Summe aus `usage.json` und am Ende gegengeprüft mit `/usage`. Kein Lauf startet über der Deckelregel aus #228. Läufe darüber hinaus gibt nur der Betreiber frei, mit einem neuen Deckel in diesem Body. Jeder Copilot-Aufruf außerhalb des Runners, auch ein Prüfaufruf, steht im Ledger. - Ein eingefrorenes Inventar ändert sich nur durch eine erneute Prüfung des Betreibers. Jede Messung nennt den Hash, gegen den sie bewertet wurde. - Fixtures, Inventare, Prüfbögen und Rohergebnisse verlassen `chemenu-testfiles` nicht, auch nicht als claude.ai-Artifact. In diesem öffentlichen Tracker stehen nur Zahlen und Folgerungen. - Ein Harness-Abbruch (Zeitlimit) wird nur mit Zustimmung des Betreibers wiederholt. ## Akzeptanzkriterien - [ ] Goldinventar A vom Betreiber vollständig geprüft und eingefroren. Regel 16 und die zwei weiteren Kapitel im Stichprobenumfang aus #228 geprüft und eingefroren; Kapitelwahl samt Begründung im Kopf von `gold/ihf-kapitel.yaml`. - [ ] P0 belegt mit tatsächlichen Kommandos und Ausgaben vom Rechner des Betreibers: Flags, Modellliste, Effort-Matrix, Standard-Effort je Modell, gemessene Kosten für Luna und Sonnet 5.5, und ob das Modell je Anfrage erfasst wird. - [ ] P1–P6 gelaufen, soweit der Deckel reicht. Was er abgeschnitten hat, steht im Bericht. - [ ] Die Übereinstimmung Richter ↔ Betreiber auf der Stichprobe steht im Bericht. - [ ] Bericht als Kommentar hier: Tabelle Modell × Effort × Fixture mit Recall (gesamt/kritisch), Verfälschungen, Seitenlänge, Faktendichte und Kosten; Pareto-Diagramm Recall/Kosten; Streudiagramm Länge/Recall mit dem Befund zu Frage 4; Befunde zu Auto, HydraFusion und Desktop App. - [ ] Folgerung als Body-Update in #21. `status/blocked` auf #21 aufgehoben. - [ ] Jeder Harness-Abbruch unter Windows ist mit Protokoll in #167 eingetragen. - [ ] Die Invarianten oben halten, insbesondere: Gesamtverbrauch unter 50 USD, Konfiguration des Betreibers unverändert. - [ ] Kein Versions-Bump im Stack. ## Versionsteil Keiner. Es ändert sich keine Datei des Stacks. Zeigt ein Lauf einen Defekt im Stack, bekommt er ein eigenes Issue oder geht in das passende Themen-Issue. ## Verwandt #228 (Werkzeug, Vorgänger), #224 (Ursprung), #21 (Abnehmer, wartet mit `status/blocked` auf dieses Issue), #167 (Windows-Dialog unter Copilot CLI: Die Läufe hier liefern die Reproduktion), #175 (leere Template-Abschnitte im Demo-Korpus). ## Kette Kette „Ingest-Modellvergleich“ - Vorgänger: #228 - Nachfolger: keiner - letztes Glied

torben added the prio/planned size/L area/process kind/build status/blocked labels 2026-10-21 04:48:18 +00:00

torben referenced this issue

2026-10-21 04:50:13 +00:00

Modellvergleich beim Ingest unter GitHub Copilot – Werkzeug: Runner, Goldinventar und Bewertung in chemenu-testfiles, Trockenlauf unter Linux #228

torben referenced this issue

2026-10-21 04:50:42 +00:00

Model/effort-selection guidance for non-Claude-Code harnesses #21

torben referenced this issue

2026-10-21 04:50:42 +00:00

Copilot CLI unter Windows: `tools/wikitool doctor` öffnet „App auswählen“ statt `wikitool.ps1` zu starten #167

torben removed the status/blocked label 2026-10-21 11:23:32 +00:00

torben commented

2026-10-21 11:23:32 +00:00

Changelog (2026-10-21): status/blocked entfernt, weil #228, der einzige Blocker, geschlossen ist. Das Werkzeug liegt als chemenu-testfiles ba1eb95 vor, der Claude-Entwurf von Gold A ebenso. Im Body ist der Blocker-Satz auf „war blockiert“ umgestellt.

Vor dem ersten bezahlten Lauf gilt aus #228: Die Runner-Schätzung bis P6 liegt bei ≈ 47 USD statt 44,50. Nach P0 deshalb bench.py plan ansehen.

**Changelog (2026-10-21):** `status/blocked` entfernt, weil #228, der einzige Blocker, geschlossen ist. Das Werkzeug liegt als `chemenu-testfiles` `ba1eb95` vor, der Claude-Entwurf von Gold A ebenso. Im Body ist der Blocker-Satz auf „war blockiert“ umgestellt. Vor dem ersten bezahlten Lauf gilt aus #228: Die Runner-Schätzung bis P6 liegt bei ≈ 47 USD statt 44,50. Nach P0 deshalb `bench.py plan` ansehen.

torben commented

2026-10-23 10:47:44 +00:00

Changelog (2026-10-23): Neu im Ablauf: Alles läuft auf dem Windows-Desktop des Betreibers; die Spalte „Wo“ ist entfallen. Am Werkzeug zwei Korrekturen in chemenu-testfiles 8b1f36c. Erstens: Der GPT-Prompt geht über stdin statt -p, wegen der Grenze von 32 767 Zeichen je Windows-Kommandozeile. Zweitens: Die Kosten werden aus der echten usage.json gelesen; vorher kam ein Luna-Aufruf 360-mal zu teuer heraus. Zwei Prüfaufrufe stehen mit 0,0025 USD im Ledger (3c2a7bc). Der offene Punkt zur Kommandozeilenlänge ist damit erledigt. Nächster Schritt: GPT-Extraktion für Gold A durch den Betreiber.

**Changelog (2026-10-23):** Neu im Ablauf: Alles läuft auf dem Windows-Desktop des Betreibers; die Spalte „Wo“ ist entfallen. Am Werkzeug zwei Korrekturen in `chemenu-testfiles` `8b1f36c`. Erstens: Der GPT-Prompt geht über stdin statt `-p`, wegen der Grenze von 32 767 Zeichen je Windows-Kommandozeile. Zweitens: Die Kosten werden aus der echten `usage.json` gelesen; vorher kam ein Luna-Aufruf 360-mal zu teuer heraus. Zwei Prüfaufrufe stehen mit 0,0025 USD im Ledger (`3c2a7bc`). Der offene Punkt zur Kommandozeilenlänge ist damit erledigt. Nächster Schritt: GPT-Extraktion für Gold A durch den Betreiber.

torben commented

2026-10-23 11:13:04 +00:00

Changelog (2026-10-23, Nachtrag): Schritt 1 ist erledigt. Gold A ist aus beiden Extraktionen zusammengeführt (144 Fakten, 81 Paare), der Prüfbogen liegt beim Betreiber (chemenu-testfiles f2c7133). Neu im Ablauf: ein Absatz, warum die Extraktionen nicht in der Session laufen. Am Werkzeug ist eine Ergänzung dazugekommen: merge nimmt Hinweise für den Prüfbogen an, und zwar dort, wo eine Extraktion aufteilt, was die andere zusammenfasst. Verbrauch jetzt 0,1639 USD.

**Changelog (2026-10-23, Nachtrag):** Schritt 1 ist erledigt. Gold A ist aus beiden Extraktionen zusammengeführt (144 Fakten, 81 Paare), der Prüfbogen liegt beim Betreiber (`chemenu-testfiles` `f2c7133`). Neu im Ablauf: ein Absatz, warum die Extraktionen nicht in der Session laufen. Am Werkzeug ist eine Ergänzung dazugekommen: `merge` nimmt Hinweise für den Prüfbogen an, und zwar dort, wo eine Extraktion aufteilt, was die andere zusammenfasst. Verbrauch jetzt 0,1639 USD.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: torben/chemenu#240