RichardandClaude Opus 4.8
c5f0b1d188
Root aufgeraeumt: alle Konzept-/Plan-/Fach-Dokumente nach docs/ verschoben, organisiert nach Typ (wie fuer ein separates Docs-Repo vorgeschlagen, aber bewusst in diesem Repo, damit Plan->umsetzende-Commits nachvollziehbar bleiben): - docs/konzepte/ (KONZEPT-*) - docs/umsetzungsplaene/ (UMSETZUNGSPLAN-*) - docs/ideen/ (fruehe Ideen, Platzhalter) - docs/pruefplaene/ (PRUEFPLAN-*) - docs/steuer/ (Steuer-/Buchhaltungs-Doks, z.B. US-CPA-Fragebogen) - docs/README.md (Index/Konventionen) Getrackte Plaene als Rename verschoben (History erhalten); zuvor untracked Konzept-/ Plan-Dateien jetzt versioniert. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
127 lines
6.2 KiB
Markdown
127 lines
6.2 KiB
Markdown
# 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.
|