AI-Chat & Analyse¶
Vesana hat zwei AI-Features:
- AI-Chat — frei stellbare IT-Fragen, mit RAG aus dem Wiki und Web-Suche-Fallback
- AI-Service-Analyse — automatische Diagnose eines Service-Problems, mit reichhaltigem Kontext
Beides nutzt dieselbe Pipeline und denselben Provider.
Provider¶
Drei Möglichkeiten:
| Provider | Privatsphäre | Qualität (subjektiv) | Kosten |
|---|---|---|---|
| Ollama lokal | Daten bleiben im Stack | mit llama3.1:8b ok |
Hardware (GPU empfohlen) |
| Anthropic | Daten gehen zu Anthropic API | sehr hoch (Claude) | API-Tokens |
| OpenAI-kompatibel extern | je nach Anbieter | je nach Modell | je nach Anbieter |
Setup: AI-Provider einrichten.
Embeddings brauchen separates Modell
Anthropic hat keine Embedding-API. Wenn du Anthropic nutzt, brauchst du Ollama zusätzlich für Embeddings (nomic-embed-text). Der Embedding-Pfad ist im Provider-Setup separat konfigurierbar.
Such-Pipeline¶
Sowohl Chat als auch Service-Analyse durchlaufen die gleichen 4 Quellen-Pfade:
flowchart LR
Q[Anfrage] --> RAG[1. RAG: pgvector]
RAG --> FTS_DE[2. FTS Deutsch]
FTS_DE --> FTS_EN[3. FTS Englisch]
FTS_EN --> ILIKE[4. ILIKE Fallback]
ILIKE --> WEB[5. Web-Suche DuckDuckGo]
WEB --> CTX[Kontext für LLM]
CTX --> LLM[Provider]
LLM --> RESP[Antwort + Quellen]
| Schritt | Was er macht |
|---|---|
| RAG | Vector-Cosine-Similarity gegen Wiki-Embeddings, Top-N Artikel |
| FTS | PostgreSQL-Volltext-Index Deutsch, dann Englisch |
| ILIKE | partielle Substring-Suche als letzter Wiki-Anker |
| Web | DuckDuckGo HTML-Scraper (kein API-Key nötig), Top-3 Snippets |
Pro Quelle wird der Kontext aufaddiert, bis ein Token-Budget (~2000 Zeichen) gefüllt ist.
AI-Chat¶
Floating-Widget unten rechts (AiChatWidget).
Bedienung¶
- Frage tippen, Enter
- Antwort streamt rein (Server-Sent-Events)
- Conversation-History bleibt erhalten (letzte 10 Messages)
- Neuer Chat-Button löscht die History
Wissensquellen-Toggles¶
Pro Chat-Session kannst du wählen:
- 📖 Wiki — RAG aus dem eigenen Wiki
- 🌐 Internet — Web-Suche
- 💡 Eigenes Wissen — ohne externe Quelle, nur LLM
Default: alle drei an. Für sensible Diskussionen: nur Wiki + eigenes Wissen.
Quellen-Badges¶
Die Antwort enthält Marker:
- 📖 zitierte Wiki-Artikel mit Klick-Link
- 🌐 Web-Quellen mit URL
- 💡 wenn der LLM aus eigenem Wissen heraus antwortet
So siehst du, woher die Information kommt.
Tenant-Scope¶
Die Suche respektiert den Tenant-Scope:
- Super-Admin: über alle Tenants
- Tenant-User: nur eigener Tenant
Der Server liest tenant_scope aus dem JWT — nichts ist clientseitig manipulierbar.
AI-Service-Analyse¶
Auf der Error-Overview oder Host-Detail-Seite gibt es pro Service einen Analyse-Button.
sequenceDiagram
participant U as User
participant API
participant CTX as ai_context.py
participant DB
participant RAG
participant LLM
U->>API: POST /api/v1/ai/analyze/{service_id}
API->>CTX: get_service_context()
CTX->>DB: JOIN host_services + profile_checks + hosts + current_status + agent_tokens + collectors
CTX-->>API: reichhaltiger Kontext
API->>RAG: Wiki-Suche zum Service-Display-Name + Check-Type
API->>LLM: System-Prompt + Kontext + RAG
LLM-->>API: Streaming-Antwort mit Quellen
API-->>U: Slide-In-Panel
Reichhaltiger Kontext¶
Was die Analyse als Kontext bekommt:
- Status (OK/WARN/CRIT/NO_DATA)
- State-Type (SOFT/HARD), Versuch X/Y
- Status-Dauer
- Letzter Wert + perfdata
- Agent-/Collector-Status (online/offline + Version)
- Acknowledged-Flag, Downtime-Flag
- Check-Intervall, Schwellwerte
Damit kann der LLM substanziell antworten („Disk auf 96% seit 4 h, Trend +0,3% pro Stunde, Eltern-Switch ist OK").
Cache¶
Analysen werden in ai_analysis_cache gespeichert mit Status-Hash als Key. Bei gleichem Status: gleiche Antwort, keine erneute LLM-Anfrage. Bei Status-Änderung: Cache invalidiert.
force=true als Query-Parameter erzwingt Neu-Analyse mit höherer Temperature — sinnvoll wenn die erste Antwort nicht half.
Datenschutz¶
Was geht zum LLM?¶
| Feature | Was geht raus |
|---|---|
| Chat (eigenes Wissen) | nur deine Frage + Conversation-History |
| Chat (Wiki an) | + Top-Wiki-Artikel-Auszüge |
| Chat (Internet an) | + Web-Snippets (deine Frage geht zur Web-Suche!) |
| Analyse | Service-Kontext (Hostname maskiert? Nein!) + Wiki + Web |
Hostname und Wiki-Inhalt verlassen den Server
Wenn Provider = Anthropic / OpenAI-kompat. extern, geht der Inhalt zu deren API. Hostname wird nicht maskiert. Bei Datenschutz-Bedenken Provider auf Ollama lokal setzen — dann verlässt nichts den Stack.
Was geht NICHT zum LLM?¶
- Keine Passwörter, Tokens, API-Keys
- Keine SNMP-Communities
- Keine Audit-Log-Einträge
- Keine Tenant-fremden Daten
- Keine User-Liste
- Keine SLA-Reports
Prompt-Injection-Schutz: System-Prompts sind versionierter Code, nicht user-konfigurierbar.
Sichtbarkeit¶
flowchart LR
A[AI sichtbar?]
A --> S{Server enabled?}
S -->|nein| H1[Hidden]
S -->|ja| P{Permission ai.query?}
P -->|nein| H2[Hidden]
P -->|ja| U{User-Pref hide_ai?}
U -->|true| H3[Hidden]
U -->|false| Y[Sichtbar]
Pro User in Settings → Präferenzen kann das Chat-Widget komplett ausgeblendet werden, auch wenn Server und Rolle es erlauben.
Implementierung: useAiVisible() in frontend/src/hooks.ts kombiniert Server-Status, Permission, User-Pref.
Modell-Wahl¶
| Anwendungsfall | Empfehlung |
|---|---|
| Schnell, keine GPU | Ollama llama3.1:8b (CPU-only ok mit ~5 s Antwortzeit) |
| Hochwertig, lokal | Ollama llama3.1:70b mit GPU |
| Höchstwertig, kostenpflichtig | Anthropic claude-sonnet-4-6 |
| Spezial-Tuning | externer OpenAI-kompat. mit eigenem fine-getunten Modell |
Für Embeddings immer nomic-embed-text über Ollama — Default und Performance/Qualität-Balance.
Permissions¶
| Permission | Wirkung |
|---|---|
ai.query |
Chat öffnen, Anfragen stellen |
ai.analyze |
Service-Analyse starten |
ai.config |
Provider und Modell konfigurieren (Admin) |
Anschluss¶
- AI-Provider einrichten — Setup
- Wiki — RAG-Quelle, je besser desto besser die Antworten