Basti/Bruno
1
0
Fork 0
Code Issues 63 Pull requests Projects Releases Packages Wiki Activity Actions

Knowledge Base, Similarity, Operator Feedback, Anomaly Detection & Cost Tracking #89

New issue
Open
opened 2026-03-30 20:28:34 +00:00 by David · 0 comments
David commented 2026-03-30 20:28:34 +00:00
Collaborator
Copy link

Beschreibung

Bruno um die Fähigkeit erweitern, aus vergangenen Tickets zu lernen und
Wissen aufzubauen: Ähnliche Tickets erkennen, Lösungen wiederverwenden,
Operator-Feedback sammeln, Anomalien erkennen und Kosten tracken.
Aktuell ist jedes Ticket eine Insel — kein Wissenstransfer.

Hintergrund

Bruno verarbeitet Tickets völlig isoliert. Wenn dasselbe Problem zum
dritten Mal auftritt, wird es komplett neu gelöst. Operatoren können
nicht signalisieren ob eine Lösung gut oder schlecht war. Es gibt
keinen Überblick über API-Kosten. Und wenn die Failure-Rate plötzlich
steigt, bemerkt es niemand automatisch.

Akzeptanzkriterien

Ticket-Similarity & Duplikat-Erkennung

  • Embeddings für Ticket-Titel + Beschreibung generieren (via Claude Embedding oder lokales Modell)
  • Bei neuem Ticket: Top-3 ähnliche vergangene Tickets anzeigen
  • Similarity-Score (0-1) pro Match mit Schwellwert für "wahrscheinliches Duplikat"
  • Ähnliche Tickets werden in kontext.md als Referenz eingefügt
  • Dashboard: "Ähnliche Tickets"-Sidebar auf TicketDetail-Seite

Knowledge Base / FAQ

  • Neue Tabelle knowledge_entries: Problem-Pattern, Lösung, zugehöriges Repo, Erfolgsrate
  • Automatische Extraktion: Wenn Ticket erfolgreich → Lösung als KB-Entry vorschlagen
  • KB-Entries werden bei Scoring und Preparation berücksichtigt
  • API: GET /api/knowledge (Liste), POST /api/knowledge (manuell anlegen)
  • API: GET /api/tickets/{id}/related-knowledge (passende Einträge)
  • Frontend: Knowledge-Base-Verwaltungsseite
  • kontext.md enthält Abschnitt "Relevante Lösungen aus der Knowledge Base"

Operator Feedback

  • API: POST /api/tickets/{id}/feedback mit Rating (1-5), Tags, Kommentar
  • Feedback-Tags: code_quality, incomplete, wrong_approach, excellent, efficient, etc.
  • Frontend: Feedback-Widget auf TicketDetail-Seite (nach MR-Erstellung sichtbar)
  • Stats-API: Durchschnittliches Rating, häufigste Tags, Trend über Zeit
  • Feedback fließt in Scoring-Kalibrierung ein (negatives Feedback = False Positive Signal)
  • Neue DB-Tabelle ticket_feedback (ticket_id, user_id, rating, tags, comment, created_at)

Anomaly Detection

  • Rolling-Average für Failure-Rate, Processing-Time, Score-Verteilung berechnen
  • Alert wenn Failure-Rate >2x Baseline (z.B. 10% → 25%)
  • Alert wenn durchschnittliche Processing-Time >2x Baseline
  • Alert wenn Scoring-Verteilung sich signifikant verschiebt (Drift-Detection)
  • Neue DB-Tabelle anomaly_alerts (timestamp, type, severity, description, resolved)
  • API: GET /api/alerts (aktuelle Anomalien)
  • Frontend: Alert-Banner im Dashboard bei aktiven Anomalien
  • Optional: Pipeline pausieren bei kritischen Anomalien

Cost Tracking

  • Pro Ticket: API-Calls zählen, Token-Verbrauch erfassen, Kosten berechnen
  • Neue Felder: ticket.api_calls_count, ticket.tokens_used, ticket.estimated_cost
  • Instrumentation in: claude_runner (Claude API), scoring_engine (Claude CLI), gitlab_service (GitLab API)
  • Stats-API: Gesamtkosten, Kosten pro erfolgreichem Ticket, Kosten-Trend
  • Dashboard: Kosten-Übersicht mit Trend-Chart
  • Budget-Alert bei Überschreitung eines konfigurierbaren Tageslimits
  • Vereint Teile von #26 (Token-Budget)

Model Routing

  • Konfigurierbar: Welches Claude-Model für welche Aufgabe (Scoring, Execution, Review)
  • Routing-Logik: Einfache Tickets (Score > 85, S-Komplexität) → schnelleres/günstigeres Model
  • Komplexe Tickets (Score < 70, L/XL-Komplexität) → leistungsfähigstes Model
  • Fallback: Bei Failure mit kleinem Model → Retry mit großem Model
  • ticket.model_used tracken für Performance-Vergleich
  • Vereint #24 (Model Routing)

Technische Hinweise

  • Betroffene Dateien:
    • Neu: backend/services/similarity_engine.py (Embedding-Generierung, Similarity-Matching)
    • Neu: backend/services/knowledge_service.py (KB-Verwaltung, Auto-Extraktion)
    • Neu: backend/services/anomaly_detector.py (Rolling-Stats, Drift-Detection, Alerts)
    • Neu: backend/services/cost_tracker.py (Token/API-Call Tracking)
    • Neu: backend/models/knowledge.py (KnowledgeEntry, TicketFeedback, AnomalyAlert)
    • Neu: backend/api/knowledge.py (KB + Feedback Endpoints)
    • Neu: backend/api/alerts.py (Anomaly-Alert Endpoints)
    • Neu: frontend/src/pages/KnowledgeBase.tsx
    • Neu: frontend/src/components/SimilarTickets.tsx
    • Neu: frontend/src/components/FeedbackWidget.tsx
    • Neu: frontend/src/components/AlertBanner.tsx
    • Ändern: backend/models/ticket.py (+ embedding, similar_tickets, api_calls_count, tokens_used, estimated_cost, model_used)
    • Ändern: backend/services/scoring_engine.py (KB-Lookup, Cost-Tracking)
    • Ändern: backend/services/claude_runner.py (Model Routing, Cost-Tracking)
    • Ändern: backend/services/preparation_engine.py (KB + Similar Tickets in kontext.md)
    • Ändern: backend/templates/kontext_template.md (neue Sections: KB, Similar Tickets)
    • Ändern: backend/main.py (Anomaly-Detection Scheduler, neue Router)
    • Ändern: backend/api/pipeline.py (Stats um Kosten + Feedback erweitern)
    • Ändern: frontend/src/App.tsx (neue Routes + AlertBanner)
    • Ändern: frontend/src/pages/TicketDetail.tsx (Similar Tickets, Feedback, KB)
    • Ändern: frontend/src/pages/Dashboard.tsx (Cost-Chart, Alert-Banner)
  • Ansatz: Schrittweise — erst Feedback + Cost Tracking (schneller Wert), dann
    Knowledge Base + Similarity (braucht Daten), dann Anomaly Detection + Model Routing.
  • Migration nötig: Ja (3 neue Tabellen + Ticket-Felder)

Aufwand: XL

## Beschreibung Bruno um die Fähigkeit erweitern, aus vergangenen Tickets zu lernen und Wissen aufzubauen: Ähnliche Tickets erkennen, Lösungen wiederverwenden, Operator-Feedback sammeln, Anomalien erkennen und Kosten tracken. Aktuell ist jedes Ticket eine Insel — kein Wissenstransfer. ## Hintergrund Bruno verarbeitet Tickets völlig isoliert. Wenn dasselbe Problem zum dritten Mal auftritt, wird es komplett neu gelöst. Operatoren können nicht signalisieren ob eine Lösung gut oder schlecht war. Es gibt keinen Überblick über API-Kosten. Und wenn die Failure-Rate plötzlich steigt, bemerkt es niemand automatisch. ## Akzeptanzkriterien ### Ticket-Similarity & Duplikat-Erkennung - [ ] Embeddings für Ticket-Titel + Beschreibung generieren (via Claude Embedding oder lokales Modell) - [ ] Bei neuem Ticket: Top-3 ähnliche vergangene Tickets anzeigen - [ ] Similarity-Score (0-1) pro Match mit Schwellwert für "wahrscheinliches Duplikat" - [ ] Ähnliche Tickets werden in kontext.md als Referenz eingefügt - [ ] Dashboard: "Ähnliche Tickets"-Sidebar auf TicketDetail-Seite ### Knowledge Base / FAQ - [ ] Neue Tabelle `knowledge_entries`: Problem-Pattern, Lösung, zugehöriges Repo, Erfolgsrate - [ ] Automatische Extraktion: Wenn Ticket erfolgreich → Lösung als KB-Entry vorschlagen - [ ] KB-Entries werden bei Scoring und Preparation berücksichtigt - [ ] API: `GET /api/knowledge` (Liste), `POST /api/knowledge` (manuell anlegen) - [ ] API: `GET /api/tickets/{id}/related-knowledge` (passende Einträge) - [ ] Frontend: Knowledge-Base-Verwaltungsseite - [ ] kontext.md enthält Abschnitt "Relevante Lösungen aus der Knowledge Base" ### Operator Feedback - [ ] API: `POST /api/tickets/{id}/feedback` mit Rating (1-5), Tags, Kommentar - [ ] Feedback-Tags: code_quality, incomplete, wrong_approach, excellent, efficient, etc. - [ ] Frontend: Feedback-Widget auf TicketDetail-Seite (nach MR-Erstellung sichtbar) - [ ] Stats-API: Durchschnittliches Rating, häufigste Tags, Trend über Zeit - [ ] Feedback fließt in Scoring-Kalibrierung ein (negatives Feedback = False Positive Signal) - [ ] Neue DB-Tabelle `ticket_feedback` (ticket_id, user_id, rating, tags, comment, created_at) ### Anomaly Detection - [ ] Rolling-Average für Failure-Rate, Processing-Time, Score-Verteilung berechnen - [ ] Alert wenn Failure-Rate >2x Baseline (z.B. 10% → 25%) - [ ] Alert wenn durchschnittliche Processing-Time >2x Baseline - [ ] Alert wenn Scoring-Verteilung sich signifikant verschiebt (Drift-Detection) - [ ] Neue DB-Tabelle `anomaly_alerts` (timestamp, type, severity, description, resolved) - [ ] API: `GET /api/alerts` (aktuelle Anomalien) - [ ] Frontend: Alert-Banner im Dashboard bei aktiven Anomalien - [ ] Optional: Pipeline pausieren bei kritischen Anomalien ### Cost Tracking - [ ] Pro Ticket: API-Calls zählen, Token-Verbrauch erfassen, Kosten berechnen - [ ] Neue Felder: `ticket.api_calls_count`, `ticket.tokens_used`, `ticket.estimated_cost` - [ ] Instrumentation in: claude_runner (Claude API), scoring_engine (Claude CLI), gitlab_service (GitLab API) - [ ] Stats-API: Gesamtkosten, Kosten pro erfolgreichem Ticket, Kosten-Trend - [ ] Dashboard: Kosten-Übersicht mit Trend-Chart - [ ] Budget-Alert bei Überschreitung eines konfigurierbaren Tageslimits - [ ] Vereint Teile von #26 (Token-Budget) ### Model Routing - [ ] Konfigurierbar: Welches Claude-Model für welche Aufgabe (Scoring, Execution, Review) - [ ] Routing-Logik: Einfache Tickets (Score > 85, S-Komplexität) → schnelleres/günstigeres Model - [ ] Komplexe Tickets (Score < 70, L/XL-Komplexität) → leistungsfähigstes Model - [ ] Fallback: Bei Failure mit kleinem Model → Retry mit großem Model - [ ] `ticket.model_used` tracken für Performance-Vergleich - [ ] Vereint #24 (Model Routing) ## Technische Hinweise - Betroffene Dateien: - Neu: `backend/services/similarity_engine.py` (Embedding-Generierung, Similarity-Matching) - Neu: `backend/services/knowledge_service.py` (KB-Verwaltung, Auto-Extraktion) - Neu: `backend/services/anomaly_detector.py` (Rolling-Stats, Drift-Detection, Alerts) - Neu: `backend/services/cost_tracker.py` (Token/API-Call Tracking) - Neu: `backend/models/knowledge.py` (KnowledgeEntry, TicketFeedback, AnomalyAlert) - Neu: `backend/api/knowledge.py` (KB + Feedback Endpoints) - Neu: `backend/api/alerts.py` (Anomaly-Alert Endpoints) - Neu: `frontend/src/pages/KnowledgeBase.tsx` - Neu: `frontend/src/components/SimilarTickets.tsx` - Neu: `frontend/src/components/FeedbackWidget.tsx` - Neu: `frontend/src/components/AlertBanner.tsx` - Ändern: `backend/models/ticket.py` (+ embedding, similar_tickets, api_calls_count, tokens_used, estimated_cost, model_used) - Ändern: `backend/services/scoring_engine.py` (KB-Lookup, Cost-Tracking) - Ändern: `backend/services/claude_runner.py` (Model Routing, Cost-Tracking) - Ändern: `backend/services/preparation_engine.py` (KB + Similar Tickets in kontext.md) - Ändern: `backend/templates/kontext_template.md` (neue Sections: KB, Similar Tickets) - Ändern: `backend/main.py` (Anomaly-Detection Scheduler, neue Router) - Ändern: `backend/api/pipeline.py` (Stats um Kosten + Feedback erweitern) - Ändern: `frontend/src/App.tsx` (neue Routes + AlertBanner) - Ändern: `frontend/src/pages/TicketDetail.tsx` (Similar Tickets, Feedback, KB) - Ändern: `frontend/src/pages/Dashboard.tsx` (Cost-Chart, Alert-Banner) - Ansatz: Schrittweise — erst Feedback + Cost Tracking (schneller Wert), dann Knowledge Base + Similarity (braucht Daten), dann Anomaly Detection + Model Routing. - Migration nötig: Ja (3 neue Tabellen + Ticket-Felder) ## Aufwand: XL
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
detached
feature/ui-redesign
No results found.
Labels
Clear labels   
api

API Endpoints betroffen

  
backend

Backend/Python betroffen

  
bug

Fehler/Bug

  
database

Datenbank/Migration betroffen

  
doku

Dokumentation nötig

  
feature

Neues Feature

  
frontend

Frontend/React betroffen

  
improvement

Verbesserung bestehender Funktion

  
in work

Issue wird gerade bearbeitet

  
kritisch

Höchste Priorität

  
L

Large: 1+ Tag, > 5 Dateien

  
M

Medium: halber Tag, 3-5 Dateien

  
niedrig

Niedrige Priorität

  
normal

Normale Priorität

  
review

In Review

  
S

Small: < 1h, 1-2 Dateien

  
service

Service/Pipeline betroffen

  
wichtig

Hohe Priorität

  
XL

Extra Large: mehrere Tage

No labels
api
backend
bug
database
doku
feature
frontend
improvement
in work
kritisch
L
M
niedrig
normal
review
S
service
wichtig
XL
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Basti/Bruno#89
No description provided.