Fix research pipeline budget tracking
This commit is contained in:
37
HANDOFF.md
37
HANDOFF.md
@@ -7,6 +7,40 @@
|
||||
|
||||
## Aktueller Stand — 2026-09-07
|
||||
|
||||
### Browser-E2E: Fehlerpfade und Quick-Budgets weiter repariert — 2026-09-07
|
||||
|
||||
Die nachfolgenden echten Browser-/Proxy-Tests erreichten erstmals die Crawler-
|
||||
und Analysephasen. Drei weitere Fehler sind lokal repariert, durch gezielte
|
||||
Regressionstests abgedeckt und mit `docker compose up -d --build nsct-api`
|
||||
deployed:
|
||||
|
||||
1. Der Crawler erzeugte für einzelne Fetch-Fehler ein `NormalizedDocument` mit
|
||||
leerem `content_hash`. Der Fehlerpfad verwendet nun `from_text()`, das auch
|
||||
für leeren Inhalt einen gültigen SHA-256-Hash erzeugt. Einzelne kaputte
|
||||
Quellen brechen damit nicht mehr die gesamte Recherche ab.
|
||||
2. Quick-Runs buchten beim Start einen nicht existierenden Planner-Request und
|
||||
anschließend eine Claim-LLM-Anfrage für jede Quelle, einschließlich
|
||||
Fehlerquellen. Bei 15 Quellen standen so vor der Analyse 17 statt maximal
|
||||
15 Requests im Budget. Der Phantom-Eintrag entfällt; nur erfolgreiche
|
||||
Quellen werden für Claims verarbeitet und ein Request bleibt für die
|
||||
Synthese reserviert. Ein voll ausgelasteter Quick-Run nutzt damit höchstens
|
||||
`1 Planung + 13 Claims + 1 Synthese = 15` LLM-Requests.
|
||||
3. `BudgetTracker.record_time_elapsed()` addierte bei jedem Aufruf erneut die
|
||||
gesamte Zeit seit Run-Start. Der Tracker verbucht nun ausschließlich das
|
||||
Intervall seit der letzten Messung. Für das lokale 35B-Modell mit ca.
|
||||
8 Tokens/s gelten jetzt Zeitlimits von 30 Minuten (Quick), 60 Minuten
|
||||
(Normal) und 120 Minuten (Deep).
|
||||
|
||||
Validierung: 68 gezielte Tests (`test_backend_pipeline_repairs.py`,
|
||||
`test_crawler.py`, `test_search.py`) erfolgreich; Backend-Container neu
|
||||
gebaut und `/health` liefert HTTP 200. Der vollständige neue Research-Run
|
||||
wurde nicht abgewartet, weil die lokale 35B-Inferenz absichtlich mehrere
|
||||
Minuten dauern kann. Beim nächsten Test eine frische Recherche starten und
|
||||
insbesondere Quellen, Claims und Bericht nach Abschluss prüfen.
|
||||
|
||||
Für die laufende Testphase ist es akzeptiert, dass Research-Runs nur im
|
||||
Arbeitsspeicher liegen und ein API-Neubau vorhandene Run-IDs verwirft.
|
||||
|
||||
### Browser-E2E: Such- und Crawler-Pipeline repariert — 2026-09-07
|
||||
|
||||
Während des Browser-E2E-Tests traten drei aufeinanderfolgende Backend-Fehler
|
||||
@@ -26,7 +60,8 @@ auf. Alle sind lokal repariert, durch gezielte Tests abgedeckt und mit
|
||||
die tatsächlichen Downloads deutlich kleiner waren. Abrufe werden jetzt auf
|
||||
verbleibende Quellen- und Bytebudgets begrenzt; die Buchung erfolgt nach
|
||||
tatsächlich abgerufenen Response-Bytes. Budgetobergrenzen sind inklusiv.
|
||||
Das Quick-Zeitlimit beträgt nun 300 Sekunden (API-Dokumentation angepasst).
|
||||
Das Quick-Zeitlimit betrug in diesem Zwischenstand 300 Sekunden und wurde
|
||||
im späteren Budget-Fix für die lokale 35B-Inferenz auf 30 Minuten erhöht.
|
||||
|
||||
Validierung: 63 gezielte Tests (`test_backend_pipeline_repairs.py`,
|
||||
`test_crawler.py`, `test_search.py`) erfolgreich; Docker-Container und
|
||||
|
||||
Reference in New Issue
Block a user