Feedback-Loop: Scoring-Kalibrierung durch MR-Outcome-Tracking #19

Closed
opened 2026-03-30 19:29:01 +00:00 by David · 1 comment
Collaborator

Beschreibung

Einen Feedback-Loop implementieren, der die Ergebnisse abgeschlossener MRs (approved/changes_requested/closed) zurück zum Scoring-System führt. Damit wird sichtbar, ob der Score korrekt berechnet wurde und wo die Schwellwerte angepasst werden müssen.

Hintergrund

Das Scoring-System (Rule 0-40 + LLM 0-60 Punkte, 3 Dimensionen: klarheit_was, klarheit_wo, kontext) klassifiziert Tickets in Autopilot/Klärfall/Abgelehnt. Die Felder für MR-Outcomes (mr_outcome, mr_reviewed_at, mr_comments_count) existieren bereits im Ticket-Model, werden aber nie befüllt — es gibt weder GitLab-Webhooks noch Polling.

Die PROJEKT-SPEC.md beschreibt in Abschnitt 4.2 explizit eine "Scoring-Kalibrierung" nach 2 Wochen Betrieb:

  • Autopilot-Tickets mit "closed" oder >3 Kommentaren → Schwellwert war zu niedrig
  • Klärfälle mit Approval nach minimaler Anreicherung → Schwellwert war zu hoch

Akzeptanzkriterien

  • GitLab-Poller holt MR-Status (approved/changes_requested/closed) für alle mr_created-Tickets und befüllt mr_outcome, mr_reviewed_at, mr_comments_count
  • Neuer Service FeedbackLoopService berechnet Score-vs-Outcome-Korrelation (z.B. "Score 70-80: 85% approved, Score 50-60: 40% approved")
  • API-Endpoint /api/analytics/feedback-loop liefert Kalibrierungsmetriken: Erfolgsrate pro Score-Range, Effektivität der LLM-Dimensionen, Schwellwert-Empfehlungen
  • Analytics-Seite im Dashboard zeigt: Score-Verteilung vs. Approval-Rate, Trend über Zeit, Empfehlungspanel für Schwellwert-Anpassungen
  • Ticket-Detailseite zeigt MR-Outcome und Vergleich "vorhergesagt vs. tatsächlich"
  • Scoring-Gewichte (klarheit_was: 0.42, klarheit_wo: 0.33, kontext: 0.25) und Schwellwerte (70/30) werden bei jedem Ticket mitgespeichert, damit spätere Änderungen rückverfolgbar sind

Technische Hinweise

  • Neuer Service: backend/services/feedback_loop_service.py — MR-Polling + Kalibrierungsanalyse
  • Erweitern: backend/services/gitlab_service.pyget_mr_status(), get_mr_comments()
  • Erweitern: backend/models/ticket.py — Felder für calibration_weights_used (JSON), mr_review_comments (JSON)
  • Erweitern: backend/api/pipeline.py — neuer Endpoint /api/analytics/feedback-loop
  • Erweitern: backend/main.py — Background-Task für MR-Outcome-Polling registrieren
  • Erweitern: backend/config.pyFEEDBACK_LOOP_POLL_INTERVAL_MINUTES, FEEDBACK_LOOP_ENABLED
  • Neue Frontend-Seite: frontend/src/pages/Analytics.tsx — Charts mit Score-vs-Outcome
  • Erweitern: frontend/src/pages/TicketDetail.tsx — MR-Outcome-Tab
  • Migration nötig: ja (neue Felder in tickets-Tabelle)

Aufwand: XL

## Beschreibung Einen Feedback-Loop implementieren, der die Ergebnisse abgeschlossener MRs (approved/changes_requested/closed) zurück zum Scoring-System führt. Damit wird sichtbar, ob der Score korrekt berechnet wurde und wo die Schwellwerte angepasst werden müssen. ## Hintergrund Das Scoring-System (Rule 0-40 + LLM 0-60 Punkte, 3 Dimensionen: `klarheit_was`, `klarheit_wo`, `kontext`) klassifiziert Tickets in Autopilot/Klärfall/Abgelehnt. Die Felder für MR-Outcomes (`mr_outcome`, `mr_reviewed_at`, `mr_comments_count`) existieren bereits im Ticket-Model, werden aber **nie befüllt** — es gibt weder GitLab-Webhooks noch Polling. Die PROJEKT-SPEC.md beschreibt in Abschnitt 4.2 explizit eine "Scoring-Kalibrierung" nach 2 Wochen Betrieb: - Autopilot-Tickets mit "closed" oder >3 Kommentaren → Schwellwert war zu niedrig - Klärfälle mit Approval nach minimaler Anreicherung → Schwellwert war zu hoch ## Akzeptanzkriterien - [ ] GitLab-Poller holt MR-Status (approved/changes_requested/closed) für alle `mr_created`-Tickets und befüllt `mr_outcome`, `mr_reviewed_at`, `mr_comments_count` - [ ] Neuer Service `FeedbackLoopService` berechnet Score-vs-Outcome-Korrelation (z.B. "Score 70-80: 85% approved, Score 50-60: 40% approved") - [ ] API-Endpoint `/api/analytics/feedback-loop` liefert Kalibrierungsmetriken: Erfolgsrate pro Score-Range, Effektivität der LLM-Dimensionen, Schwellwert-Empfehlungen - [ ] Analytics-Seite im Dashboard zeigt: Score-Verteilung vs. Approval-Rate, Trend über Zeit, Empfehlungspanel für Schwellwert-Anpassungen - [ ] Ticket-Detailseite zeigt MR-Outcome und Vergleich "vorhergesagt vs. tatsächlich" - [ ] Scoring-Gewichte (`klarheit_was: 0.42`, `klarheit_wo: 0.33`, `kontext: 0.25`) und Schwellwerte (70/30) werden bei jedem Ticket mitgespeichert, damit spätere Änderungen rückverfolgbar sind ## Technische Hinweise - Neuer Service: `backend/services/feedback_loop_service.py` — MR-Polling + Kalibrierungsanalyse - Erweitern: `backend/services/gitlab_service.py` — `get_mr_status()`, `get_mr_comments()` - Erweitern: `backend/models/ticket.py` — Felder für `calibration_weights_used` (JSON), `mr_review_comments` (JSON) - Erweitern: `backend/api/pipeline.py` — neuer Endpoint `/api/analytics/feedback-loop` - Erweitern: `backend/main.py` — Background-Task für MR-Outcome-Polling registrieren - Erweitern: `backend/config.py` — `FEEDBACK_LOOP_POLL_INTERVAL_MINUTES`, `FEEDBACK_LOOP_ENABLED` - Neue Frontend-Seite: `frontend/src/pages/Analytics.tsx` — Charts mit Score-vs-Outcome - Erweitern: `frontend/src/pages/TicketDetail.tsx` — MR-Outcome-Tab - Migration nötig: **ja** (neue Felder in `tickets`-Tabelle) ## Aufwand: XL
Author
Collaborator

Superseded by #90 (MR-Outcome-Tracking & Scoring-Kalibrierung). Feedback-Loop und Scoring-Kalibrierung sind dort vollständig abgedeckt. Auch Duplikat von #15.

Superseded by #90 (MR-Outcome-Tracking & Scoring-Kalibrierung). Feedback-Loop und Scoring-Kalibrierung sind dort vollständig abgedeckt. Auch Duplikat von #15.
David closed this issue 2026-03-30 20:39:00 +00:00
Sign in to join this conversation.
No description provided.