Eine Roadmap statt fuenfzehn Plandokumente; Altbestand ins Archiv
Der Status des Projekts stand verstreut in elf Umsetzungsplaenen, drei Konzepten, der Linux-Analyse und dem Projektstand - teils widersprechend, teils wochenlang veraltet. Ab jetzt gibt es genau eine Statusquelle. docs/ROADMAP.md (neu): - Alle Vorhaben in vier Stufen A bis D, plus technische Schuld und Verlauf. Die Stufen sind eine Reihenfolge, keine Termine: jede schafft die Voraussetzung fuer die naechste. - Statuszeichen: erledigt / offen / blockiert (mit Ursache) / bewusst zurueckgestellt / Idee, nicht beschlossen. Damit ist das, was wir NICHT bauen wollen, sichtbar vorgehalten statt unauffindbar in einem Plan zu schlummern. - Inhaltlich getragen, nicht nur verlinkt: je Vorhaben Ziel, Phasen, Akzeptanzkriterien, offene Entscheidungen und Leitplanken aus den Quelldokumenten. - Sichtbar gemacht, was vorher zwischen den Dokumenten verborgen lag: CopyTrading Phase 1 ist der Engpass der gesamten Roadmap (MarketMaking und BundleArbitrage haben harte Voraussetzungen darauf), und die Sniper-Metriken aus Phase 3.2 sind ein Spezialfall des StrategieDrift-Fingerprints - zusammen bauen statt doppelt. Archiv (docs/archiv/): - 15 Dokumente verschoben (11 Umsetzungsplaene, 3 Konzepte, ANALYSE-Linux-Portierung). Sie bleiben die Bauanleitungen mit Code-Bezuegen, Risikotabellen und Begruendungen - eingefroren ist nur ihr Status. - archiv/README.md ordnet jedes Dokument seinem Roadmap-Punkt zu. Verweise nachgezogen - der eigentliche Aufwand: - 25 Markdown-Links repariert. 15 davon verschiebungsbedingt (eine Ebene tiefer), der Rest war schon vorher falsch: die Ideensammlung verlinkte Quellcode relativ zum Repo-Wurzelverzeichnis statt zu docs/. - 12 Dateien ausserhalb von docs/ verwiesen in Kommentaren auf die Plaene (csproj, props, setup.json, sechs Quelldateien) - alle auf archiv/ umgebogen. - Verweise auf Dateien, die der Fruehjahrsputz geloescht hat (Ui/, Program.cs, WindowMenuBar), zu Klartext entschaerft statt tote Links zu lassen. - Gegenprobe: 85 Links geprueft, 0 kaputt. Build gruen, 476 Tests gruen. PROJEKTSTAND.md entdoppelt: Abschnitt "Offen" verweist jetzt auf die Roadmap. Arbeitsteilung ist damit klar - Projektstand sagt was IST, Roadmap was KOMMT. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Richard
@@ -0,0 +1,126 @@
|
||||
# Umsetzungsplan: AI-Bewertung der Auflösequalität (C-S4)
|
||||
|
||||
> Stand: 2026-07-11
|
||||
> Ziel: Ein LLM (via OpenRouter) bewertet je Markt das RESOLUTION-Risiko (subjektive
|
||||
> Auflösequellen, Regeltext-Fallen, UMA-Dispute-Muster). Die Bewertung wird beim
|
||||
> Markt-Import in der DB gespeichert und dient als Entry-Gate — zuerst im
|
||||
> ResolutionFarming, perspektivisch auch im Copytrading.
|
||||
> Einordnung: Core-Baustein (beide Module profitieren), kein eigenes Strategiemodul.
|
||||
|
||||
---
|
||||
|
||||
## 1. Abgrenzung (wichtig für die Umsetzung)
|
||||
|
||||
Das LLM prognostiziert NICHT den Markt-Ausgang. Es beantwortet ausschließlich:
|
||||
**„Wie sauber/objektiv wird dieser Markt aufgelöst werden?"** — Input ist der
|
||||
Regeltext, nicht das Weltgeschehen. Das hält die Aufgabe eng, billig und testbar.
|
||||
|
||||
## 2. Architektur
|
||||
|
||||
### 2.1 Core-Service `IMarketRiskRater` (PolyTrader.Core)
|
||||
|
||||
```csharp
|
||||
public interface IMarketRiskRater
|
||||
{
|
||||
/// Liefert die (ggf. gecachte) Bewertung; null wenn (noch) keine vorliegt.
|
||||
Task<MarketRiskRating?> GetOrRateAsync(MarketData market, CancellationToken ct);
|
||||
}
|
||||
|
||||
public class MarketRiskRating // Tabelle core_market_risk_ratings
|
||||
{
|
||||
public string ConditionId { get; set; } // PK — Regeltexte ändern sich nicht → dauerhaft cachebar
|
||||
public int Score { get; set; } // 0–100 (100 = völlig objektiv auflösbar)
|
||||
public string Flags { get; set; } // CSV: SUBJECTIVE_SOURCE, DEADLINE_AMBIGUITY,
|
||||
// MENTIONS_TYPE, DISPUTE_PATTERN, MISSING_RULES
|
||||
public string Reason { get; set; } // Einzeiler-Begründung des Modells
|
||||
public string Model { get; set; } // verwendetes Modell (Nachvollziehbarkeit)
|
||||
public DateTime RatedAt { get; set; }
|
||||
}
|
||||
```
|
||||
|
||||
### 2.2 `OpenRouterClient` (Core, dünn)
|
||||
|
||||
- HTTP-Client gegen https://openrouter.ai/api/v1/chat/completions, API-Key aus
|
||||
appsettings (`OpenRouter:ApiKey`, gitignoriert wie andere Secrets).
|
||||
- **Modellwahl:** günstiges Modell reicht (Haiku-Klasse, z. B.
|
||||
`anthropic/claude-haiku-4.5` via OpenRouter; Modell-ID als Setting, nicht
|
||||
hartkodieren). Kosten je Markt: Bruchteile eines Cents; mit Cache je ConditionId
|
||||
einmalig pro Markt.
|
||||
- **Structured Output:** Antwort als JSON erzwingen (Schema im Prompt + JSON-Mode);
|
||||
bei Parse-Fehler 1 Retry, danach „kein Rating" (fail-closed, siehe 3.3).
|
||||
- Timeout kurz (~15 s), Fehler loggen, NIE den aufrufenden Scanner blockieren.
|
||||
|
||||
### 2.3 Prompt (Kern, bei Umsetzung feinjustieren)
|
||||
|
||||
Input je Markt: `Question`, `Description`/Resolution-Kriterien (Gamma-API liefert
|
||||
den Regeltext am Markt-Objekt — Feld bei Umsetzung verifizieren), Kategorie, EndDate.
|
||||
|
||||
Bewertungsauftrag an das Modell (sinngemäß):
|
||||
1. Gibt es eine EINDEUTIGE, öffentlich prüfbare Auflösequelle (offizielles
|
||||
Endergebnis, behördliche Zahl, On-Chain-Fakt)?
|
||||
2. Sind Randfälle geregelt (Verschiebung, Abbruch, Unentschieden, Definitionsfragen
|
||||
wie „offiziell angekündigt")?
|
||||
3. Ähnelt der Markt bekannten Streit-Mustern (Mentions-/„sagt X"-Märkte, vage
|
||||
Deadlines, Definitions-Ambiguität, mehrdeutige Quellen)?
|
||||
Output: `{ "score": 0-100, "flags": [...], "reason": "…" }`.
|
||||
|
||||
## 3. Integration
|
||||
|
||||
### 3.1 Wann wird bewertet?
|
||||
|
||||
Beim Markt-Import bzw. beim ersten Kontakt: Der **RF-Scanner** ruft
|
||||
`GetOrRateAsync` für jeden Kandidaten auf, der alle billigen Filter passiert hat
|
||||
(NACH Preisband/Kategorie/Fenster, VOR dem Accept — kein LLM-Call für offensichtliche
|
||||
Rejects). Cache macht Wiederholungs-Scans kostenlos.
|
||||
|
||||
### 3.2 Entry-Gate im ResolutionFarming
|
||||
|
||||
Neue `RfSettings`:
|
||||
- `MinResolutionScore` (Default 70): Kandidaten mit Score darunter → Reject mit
|
||||
Grund `"AI-Resolution-Score {score} < {min}: {reason}"` (landet wie alle Rejects
|
||||
in rf_candidates → die Kalibrierung kann später prüfen, ob das Gate Geld spart!).
|
||||
- `RequireRating` (Default true): fail-closed-Schalter (siehe 3.3).
|
||||
|
||||
### 3.3 Fail-Closed-Regeln (Sicherheitskern)
|
||||
|
||||
1. Kein Rating verfügbar (API down, Parse-Fehler, kein Regeltext) → Kandidat gilt
|
||||
als riskant und wird abgelehnt — AUSSER die Kategorie steht auf einer
|
||||
Objektiv-Whitelist (Default: Sports-Endergebnisse), dann Durchlass mit Log.
|
||||
2. Das Rating **ersetzt die harte Blacklist nicht**: bekannte Giftmuster
|
||||
(Mentions-Märkte etc.) bleiben in `BlacklistCsv` hart geblockt. Das LLM ist die
|
||||
zweite Verteidigungslinie für den Long Tail, nicht die erste.
|
||||
3. **Post-Mortem-Pflicht:** Jeder real erlebte Dispute → Muster in Blacklist/Prompt
|
||||
aufnehmen. Dafür Flag-Feld in rf_closed_trades (`ResolutionDisputed`) vorsehen.
|
||||
|
||||
### 3.4 Copytrading (zweiter Schritt, optional)
|
||||
|
||||
Gleicher Service: Vor einem BUY den Score prüfen; unter Schwelle → Trade
|
||||
verwerfen mit TradeReasoning-Log. Als Per-Account-Setting (`MinResolutionScore`,
|
||||
0 = aus), Default zunächst AUS, um das Copy-Verhalten nicht zu verändern, bis der
|
||||
Rater validiert ist.
|
||||
|
||||
## 4. Validierung VOR dem Scharfschalten (Pflicht-Phase)
|
||||
|
||||
1. **Retrospektiv-Test:** ~15–20 öffentlich bekannte, umstrittene UMA-Resolutions
|
||||
(Recherche-Aufgabe: bekannte Dispute-Fälle) + ~30 unstrittig aufgelöste
|
||||
Vergleichsmärkte durch den Rater schicken. Messen: erwischt er die Streitfälle
|
||||
(niedriger Score), ohne die sauberen zu blockieren?
|
||||
2. **Akzeptanz:** ≥ 80 % der Streitfälle unter der Schwelle, ≤ 10 % der sauberen
|
||||
fälschlich blockiert. Sonst Prompt/Schwelle iterieren.
|
||||
3. Ergebnisse als Testdaten einfrieren (Golden-File-Test, läuft ohne API gegen
|
||||
gespeicherte Antworten — kein LLM-Call in der CI).
|
||||
|
||||
## 5. Phasen
|
||||
|
||||
| Phase | Inhalt | Akzeptanz |
|
||||
|---|---|---|
|
||||
| AR-1 | OpenRouterClient + IMarketRiskRater + Tabelle/Migration + Unit-Tests (Parsing, Fail-Closed) | Build grün; Rater liefert für einen Beispiel-Regeltext strukturiertes Rating |
|
||||
| AR-2 | Retrospektiv-Validierung (4.) | Akzeptanzquoten erreicht, dokumentiert |
|
||||
| AR-3 | RF-Integration (3.1/3.2/3.3) + UI-Spalte (Score in Kandidaten-Tab) | Rejects mit AI-Grund sichtbar; Kalibrierung kann Gate-Wirkung auswerten |
|
||||
| AR-4 | Copytrading-Integration (3.4), Default aus | Setting vorhanden, dokumentiert |
|
||||
|
||||
## 6. Leitplanken
|
||||
|
||||
- API-Key nie committen; Kosten-Deckel (max. Ratings/Tag als Setting, Default 500).
|
||||
- Der Rater beeinflusst NIE Exits, nur Entries (keine Panik-Verkäufe durch LLM).
|
||||
- Score/Reason immer mitloggen — Entscheidungen müssen im Log nachvollziehbar sein.
|
||||
Reference in New Issue
Block a user