Stimmverhalten: Auto-Verknüpfung Plenum-Vote ↔ Bewertung #172

New Issue

tobias · 2026-05-03T13:43:39+02:00

tobias commented

2026-05-03 13:43:39 +02:00

Problem

Das Stimmverhalten-Feature aus #165 zeigt aktuell wenig Daten. Stand 2026-05-03 auf dev:

Metric	Wert
Bewertungen mit GWÖ-Score	77
Plenum-Votes ingestiert	7234
Schnittmenge (beides vorhanden)	19
Davon NRW	16
BUND	0 (Bewertungen aus WP21, Votes aus WP19/20 — Lücke)
Andere BL	je 0–3

Ursache

Bewertung und Vote-Ingest sind heute orthogonal:

Bewertung schreibt in assessments (manuell ausgelöst, oder via Cron-Bewerter)
Vote-Ingest schreibt in plenum_vote_results (täglich aus Plenarprotokollen, app/protokoll_parsers/)
app/auswertungen.py:_load_assessments_with_votes() joint sie passiv beim Lesen

Es gibt keinen Punkt im System, der beim Eingang einer neuen Drucksache prüft "ist die andere Seite auch schon da?".

Vorschläge

A) Bei jedem neuen Vote-Ingest: Auto-Bewertung anstoßen?

Wenn Vote-Ingest eine Drucksache findet, die noch keine Bewertung hat → automatisch eine Bewertung anstoßen. Aber: 7234 Votes × LLM-Call à ~2 Cent = ~145 € für Backfill. Das ist die teure Option.

B) Hinweis-System ohne Auto-Trigger

Auswertungs-Dashboard zeigt Banner: "X Drucksachen mit Plenum-Vote haben keine Bewertung — willst du Top-N davon bewerten lassen?". User entscheidet pro Charge (z.B. 10 Anträge à 20 Cent).

C) Bewertungs-Pipeline schaut nach Vote-Result

Beim Bewerten einer neuen Drucksache (manuell via UI oder Cron) wird im Hintergrund nachgeschaut, ob Plenum-Vote existiert. Wenn nein: Notiz "noch nicht abgestimmt" im Assessment. Wenn ja: kein extra Action — der Vote ist schon da. Das ist günstig (kein extra LLM), aber löst die Sparse-Daten-Lücke nicht.

D) Cron-Bewerter erweitern: "alle Anträge mit Vote priorisiert bewerten"

app/cron_bewerter.py (oder ähnliches) bekommt einen neuen Modus: "Bewerte primär Drucksachen, die einen Plenum-Vote haben aber keine Bewertung". Pro Tag z.B. Top-20 nach Datum-Aktualität → ~40 Cent/Tag. In 6 Monaten wäre der Backlog abgearbeitet.

Empfehlung

B + D kombinieren:

Banner im Auswertungs-Dashboard mit Anzahl Lücken (kostenlos)
Cron-Bewerter erweitern um Vote-Priorisierung (begrenzt teuer, aber kontinuierlich)
Manueller "Auto-Bewerten"-Button auf der Stimmverhalten-Seite für gezielte Top-N

Out of Scope

Vote → Bewertung-Trigger sofort beim Vote-Ingest (zu teuer, blockiert Cron)

Aufwand

Banner: kurz
Cron-Bewerter-Erweiterung: mittel (neuer Mode, kostendisziplinierte Implementierung)
Manueller Bulk-Bewerter-Button: mittel (Queue-System nutzen, das schon für #44 da ist)

## Problem Das Stimmverhalten-Feature aus #165 zeigt aktuell wenig Daten. Stand 2026-05-03 auf dev: | Metric | Wert | |---|---| | Bewertungen mit GWÖ-Score | 77 | | Plenum-Votes ingestiert | 7234 | | **Schnittmenge (beides vorhanden)** | **19** | | Davon NRW | 16 | | BUND | 0 (Bewertungen aus WP21, Votes aus WP19/20 — Lücke) | | Andere BL | je 0–3 | ## Ursache Bewertung und Vote-Ingest sind heute orthogonal: - Bewertung schreibt in `assessments` (manuell ausgelöst, oder via Cron-Bewerter) - Vote-Ingest schreibt in `plenum_vote_results` (täglich aus Plenarprotokollen, app/protokoll_parsers/) - `app/auswertungen.py:_load_assessments_with_votes()` joint sie passiv beim Lesen Es gibt keinen Punkt im System, der beim Eingang einer neuen Drucksache prüft "ist die andere Seite auch schon da?". ## Vorschläge ### A) Bei jedem neuen Vote-Ingest: Auto-Bewertung anstoßen? Wenn Vote-Ingest eine Drucksache findet, die noch keine Bewertung hat → automatisch eine Bewertung anstoßen. Aber: 7234 Votes × LLM-Call à ~2 Cent = **~145 €** für Backfill. Das ist die teure Option. ### B) Hinweis-System ohne Auto-Trigger Auswertungs-Dashboard zeigt Banner: "X Drucksachen mit Plenum-Vote haben keine Bewertung — willst du Top-N davon bewerten lassen?". User entscheidet pro Charge (z.B. 10 Anträge à 20 Cent). ### C) Bewertungs-Pipeline schaut nach Vote-Result Beim Bewerten einer neuen Drucksache (manuell via UI oder Cron) wird im Hintergrund nachgeschaut, ob Plenum-Vote existiert. Wenn nein: Notiz "noch nicht abgestimmt" im Assessment. Wenn ja: kein extra Action — der Vote ist schon da. Das ist günstig (kein extra LLM), aber löst die Sparse-Daten-Lücke nicht. ### D) Cron-Bewerter erweitern: "alle Anträge mit Vote priorisiert bewerten" `app/cron_bewerter.py` (oder ähnliches) bekommt einen neuen Modus: "Bewerte primär Drucksachen, die einen Plenum-Vote haben aber keine Bewertung". Pro Tag z.B. Top-20 nach Datum-Aktualität → ~40 Cent/Tag. In 6 Monaten wäre der Backlog abgearbeitet. ## Empfehlung **B + D kombinieren:** 1. Banner im Auswertungs-Dashboard mit Anzahl Lücken (kostenlos) 2. Cron-Bewerter erweitern um Vote-Priorisierung (begrenzt teuer, aber kontinuierlich) 3. Manueller "Auto-Bewerten"-Button auf der Stimmverhalten-Seite für gezielte Top-N ## Out of Scope - Vote → Bewertung-Trigger sofort beim Vote-Ingest (zu teuer, blockiert Cron) ## Aufwand - Banner: kurz - Cron-Bewerter-Erweiterung: mittel (neuer Mode, kostendisziplinierte Implementierung) - Manueller Bulk-Bewerter-Button: mittel (Queue-System nutzen, das schon für #44 da ist)

tobias referenced this issue from a commit

2026-05-06 02:03:24 +02:00

feat(#172): Vote-Orphans-Banner + Bulk-Auto-Bewerten-Endpoint

tobias commented

2026-05-06 02:03:41 +02:00

Implementiert in commit 8136a1a (Variante B aus dem Issue + zusätzlich D).

Variante B (Banner) live: Stimmverhalten-Tab zeigt jetzt einen orange-getönten Banner mit:

Anzahl Drucksachen mit Plenum-Vote, aber ohne Bewertung
Verteilung pro BL
Button "Top-N bewerten lassen" mit Limit-Selector (5/10/20)

Variante D (gezielte Auto-Bewertung) live: Endpoint POST /api/auswertungen/vote-orphans/auto-rate (Admin-only, rate-limited 3/min, Default-Limit 10, Max 50). Iteriert über Top-N Vote-Orphans nach parsed_at desc, lädt Antragstext per Adapter, enqueued einen Bewertungs-Job pro Drucksache. Skipped-Reasons (no_adapter, empty_text, queue_full) sind in der Response sichtbar.

Variante A (Auto-Trigger bei Vote-Ingest) bewusst nicht umgesetzt — wäre bei 7281 Votes × ~2 Cent ein 145 €-Backfill auf einmal. Stattdessen kontrollierter Pull-Modus über den Banner-Button.

Variante C (Bewertung schaut nach Vote) ebenfalls nicht — würde nichts ändern, weil Vote-Lücke auf der Bewertungs-Seite klar sichtbar ist (Banner zeigt's).

Endpoint zum Inspizieren: GET /api/auswertungen/vote-orphans?bundesland=NRW&limit=200

Closing.

Implementiert in commit 8136a1a (Variante B aus dem Issue + zusätzlich D). **Variante B (Banner) live:** Stimmverhalten-Tab zeigt jetzt einen orange-getönten Banner mit: - Anzahl Drucksachen mit Plenum-Vote, aber ohne Bewertung - Verteilung pro BL - Button "Top-N bewerten lassen" mit Limit-Selector (5/10/20) **Variante D (gezielte Auto-Bewertung) live:** Endpoint `POST /api/auswertungen/vote-orphans/auto-rate` (Admin-only, rate-limited 3/min, Default-Limit 10, Max 50). Iteriert über Top-N Vote-Orphans nach parsed_at desc, lädt Antragstext per Adapter, enqueued einen Bewertungs-Job pro Drucksache. Skipped-Reasons (no_adapter, empty_text, queue_full) sind in der Response sichtbar. **Variante A (Auto-Trigger bei Vote-Ingest)** bewusst nicht umgesetzt — wäre bei 7281 Votes × ~2 Cent ein 145 €-Backfill auf einmal. Stattdessen kontrollierter Pull-Modus über den Banner-Button. **Variante C (Bewertung schaut nach Vote)** ebenfalls nicht — würde nichts ändern, weil Vote-Lücke auf der Bewertungs-Seite klar sichtbar ist (Banner zeigt's). **Endpoint zum Inspizieren:** `GET /api/auswertungen/vote-orphans?bundesland=NRW&limit=200` Closing.

tobias closed this issue

2026-05-06 02:03:41 +02:00

Sign in to join this conversation.