799 lines
31 KiB
Plaintext
799 lines
31 KiB
Plaintext
###############################################################################
|
||
# GLPI AI STACK - GEMEINSAME .ENV
|
||
#
|
||
# Diese Datei hat zwei Aufgaben:
|
||
#
|
||
# 1. Docker Compose verwendet sie zur Variablenersetzung:
|
||
# ${KB_DATA_PATH:-./knowledge}
|
||
# ${AGENT_PORT:-7080}
|
||
# usw.
|
||
#
|
||
# 2. Der GLPI AI Agent lädt sie über:
|
||
# env_file:
|
||
# - .env
|
||
#
|
||
# Hinweise:
|
||
# - Boolean: true | false
|
||
# - Zeitangaben: 30s, 5m, 2h, 72h
|
||
# - Scores: 0.0 bis 1.0
|
||
# 0.70 = 70 %
|
||
# - Listen: komma-separiert, möglichst ohne Leerzeichen
|
||
#
|
||
# relative Host-Pfade wie ./knowledge2 beziehen sich auf das Compose-Projekt.
|
||
# Pfade innerhalb des Agent-Containers sollten absolut angegeben werden.
|
||
###############################################################################
|
||
|
||
###############################################################################
|
||
# 01. DOCKER COMPOSE - PORTS
|
||
###############################################################################
|
||
# WebUI / API / Diagnose-Cockpit des GLPI AI Agents.
|
||
# Aufruf normalerweise:
|
||
# http://<docker-host>:7080
|
||
AGENT_PORT=7080
|
||
# Knowledge-Base-Suchoberfläche.
|
||
KB_SEARCH_PORT=7081
|
||
# Knowledge-Base-Administration.
|
||
KB_EDITOR_PORT=7082
|
||
###############################################################################
|
||
# 02. DOCKER COMPOSE - GEMEINSAME DATENVERZEICHNISSE
|
||
###############################################################################
|
||
# Zentrale Knowledge Base auf dem Docker-Host.
|
||
#
|
||
# Dieses Verzeichnis wird gemeinsam verwendet von:
|
||
# - Agent read-only
|
||
# - KB Editor read-write
|
||
# - KB Search read-only
|
||
#
|
||
# Wichtig:
|
||
# In der compose.yml sollten ALLE drei Dienste KB_DATA_PATH verwenden.
|
||
KB_DATA_PATH=./knowledge
|
||
# Backups des Knowledge-Base-Editors.
|
||
KB_BACKUP_PATH=./backups
|
||
# Staging-Bereich für neue bzw. KI-unterstützt erzeugte KB-Artikel.
|
||
KB_STAGING_PATH=./staging
|
||
###############################################################################
|
||
# 03. KNOWLEDGE-BASE WEBANWENDUNGEN
|
||
###############################################################################
|
||
# ---------------------------------------------------------------------------
|
||
# KB EDITOR
|
||
# ---------------------------------------------------------------------------
|
||
EDITOR_TITLE=KB Administration
|
||
EDITOR_SUBTITLE=Wissensbasis verwalten
|
||
# Optionaler Basic-Auth-Zugang des Editors.
|
||
#
|
||
# Leer bedeutet je nach Anwendungskonfiguration keine Basic-Auth-Anmeldung.
|
||
# Für produktiven Betrieb sollten Benutzername und Passwort gesetzt werden.
|
||
EDITOR_AUTH_USER=
|
||
EDITOR_AUTH_PASSWORD=<SECRET>
|
||
# ---------------------------------------------------------------------------
|
||
# KB SEARCH
|
||
# ---------------------------------------------------------------------------
|
||
SEARCH_TITLE=Stadt Hilden - KB-Datenbank
|
||
SEARCH_SUBTITLE=Interne Lösungsdatenbank
|
||
SEARCH_AUTH_USER=
|
||
SEARCH_AUTH_PASSWORD=<SECRET>
|
||
# Intervall, in dem die Suchanwendung die KB-Dateien erneut einliest.
|
||
#
|
||
# Beispiele:
|
||
# 30s
|
||
# 60s
|
||
# 5m
|
||
AUTO_RELOAD_INTERVAL=60s
|
||
###############################################################################
|
||
# 04. KNOWLEDGE-BASE WEBANWENDUNGEN - OLLAMA
|
||
###############################################################################
|
||
# KI-Fallback der KB-Anwendungen.
|
||
#
|
||
# HINWEIS:
|
||
# Diese Einstellung betrifft kb-editor / kb-search.
|
||
# Der GLPI AI Agent besitzt unabhängig davon seine eigene Ollama-Konfiguration.
|
||
AI_FALLBACK_ENABLED=true
|
||
# Ollama-Adresse für kb-editor / kb-search innerhalb des Compose-Netzwerks.
|
||
#
|
||
# Nicht mit OLLAMA_URL des Agents verwechseln.
|
||
OLLAMA_BASE_URL=http://ollama:11434
|
||
# Chat-Modell.
|
||
#
|
||
# Diese Variable wird aktuell sowohl von den KB-Anwendungen als auch vom
|
||
# Agenten verwendet. Dadurch verwenden alle Anwendungen dasselbe Modell.
|
||
OLLAMA_MODEL=qwen3:8b
|
||
# Gemeinsamer Timeout.
|
||
OLLAMA_TIMEOUT=10m
|
||
# Maximale parallele Ollama-Aufrufe.
|
||
#
|
||
# Bei einer einzelnen GPU bzw. begrenzten Ressourcen ist 1 ein guter
|
||
# Ausgangswert.
|
||
OLLAMA_MAX_CONCURRENT=1
|
||
# Soll ein vom KB-System erzeugter Staging-Artikel automatisch mit
|
||
# auto_reply=true erzeugt werden?
|
||
#
|
||
# Sicherer Ausgangswert:
|
||
# false
|
||
OLLAMA_STAGING_AUTO_REPLY=false
|
||
# min_score für erzeugte Staging-Artikel.
|
||
OLLAMA_STAGING_MIN_SCORE=0.70
|
||
###############################################################################
|
||
# 05. GLPI AI AGENT - ALLGEMEINER BETRIEB
|
||
###############################################################################
|
||
# true:
|
||
# Der Agent analysiert vollständig, schreibt aber keine Änderungen nach GLPI.
|
||
#
|
||
# false:
|
||
# Durch die Policy freigegebene Aktionen werden tatsächlich ausgeführt.
|
||
#
|
||
# Für Tests / Einführung:
|
||
# true
|
||
DRY_RUN=true
|
||
# Mögliche Werte:
|
||
# debug
|
||
# info
|
||
# warn
|
||
# error
|
||
LOG_LEVEL=info
|
||
# HTTP-Listener INNERHALB des Agent-Containers.
|
||
#
|
||
# AGENT_PORT oben bestimmt dagegen den veröffentlichten Host-Port.
|
||
HTTP_ADDR=:7080
|
||
# Persistentes Verzeichnis IM Container.
|
||
#
|
||
# Compose mountet:
|
||
# agent-data:/app/data
|
||
#
|
||
# Enthält unter anderem:
|
||
# - Knowledge-Index
|
||
# - Audit/Run-Daten
|
||
# - Category Learning
|
||
# - Managed Knowledge
|
||
# - GLPI-KB-Cache
|
||
DATA_DIR=/app/data
|
||
###############################################################################
|
||
# 06. AGENT WEBUI / API / DIAGNOSE
|
||
###############################################################################
|
||
# Benutzer für Agent-Dashboard, Knowledge-Verwaltung und Diagnose-Cockpit.
|
||
WEB_USERNAME=admin
|
||
WEB_PASSWORD=<SECRET>
|
||
# false:
|
||
# Anmeldung erforderlich.
|
||
#
|
||
# true:
|
||
# Weboberfläche ohne Authentifizierung erreichbar.
|
||
#
|
||
# In Produktion normalerweise false.
|
||
WEB_ALLOW_ANONYMOUS=false
|
||
# TrustedNet-Kennzeichnung vor automatisch ausgewählten Antworten.
|
||
#
|
||
# true:
|
||
# TrustedNet-KI-Badge wird vor Anrede und Antwort eingefügt.
|
||
#
|
||
# false:
|
||
# keine KI-Kennzeichnung.
|
||
AI_CONTENT_LABEL_ENABLED=true
|
||
###############################################################################
|
||
# 07. OPTIONALER GLPI-WEBHOOK
|
||
###############################################################################
|
||
# Optionales Shared Secret für eingehende GLPI-Webhooks.
|
||
#
|
||
# Der Absender muss dasselbe Secret z. B. über:
|
||
# X-Webhook-Secret
|
||
# übertragen.
|
||
#
|
||
# Leer lassen, falls kein Webhook verwendet wird.
|
||
WEBHOOK_SECRET=<SECRET>
|
||
###############################################################################
|
||
# 08. GLPI 11 / HIGH-LEVEL API / OAUTH2
|
||
###############################################################################
|
||
GLPI_URL=https://glpi.example.com
|
||
# Verwendete GLPI High-Level API.
|
||
GLPI_API_VERSION=v2.3
|
||
# OAuth2 Service Account.
|
||
GLPI_CLIENT_ID=<SECRET>
|
||
GLPI_CLIENT_SECRET=<SECRET>
|
||
GLPI_USERNAME=ai
|
||
GLPI_PASSWORD=<SECRET>
|
||
# Numerische GLPI-Benutzer-ID des Service-Accounts.
|
||
#
|
||
# Wird unter anderem benötigt, um Agent-Followups von menschlichen
|
||
# Followups unterscheiden zu können.
|
||
GLPI_AGENT_USER_ID=999
|
||
# Nur für lokale Testsysteme ohne TLS.
|
||
#
|
||
# Produktion:
|
||
# false
|
||
GLPI_ALLOW_INSECURE_HTTP=false
|
||
###############################################################################
|
||
# 09. GLPI TICKET-POLLING
|
||
###############################################################################
|
||
# Fail-closed Whitelist erlaubter GLPI-Ticketstatus.
|
||
#
|
||
# Beispiel:
|
||
# 1
|
||
# 1,2
|
||
#
|
||
# Status 1 entspricht typischerweise "Neu".
|
||
GLPI_ALLOWED_STATUS_IDS=1
|
||
# Polling-Intervall.
|
||
GLPI_POLL_INTERVAL=30s
|
||
# Maximale Anzahl Tickets pro Poll.
|
||
GLPI_POLL_LIMIT=50
|
||
# Optionale serverseitige Vorfilterung.
|
||
#
|
||
# Die Agent-Policy prüft GLPI_ALLOWED_STATUS_IDS anschließend trotzdem selbst.
|
||
#
|
||
# Änderungen der Syntax immer gegen /api.php/doc der eigenen GLPI-Instanz
|
||
# prüfen.
|
||
GLPI_TICKET_FILTER=status.id==1
|
||
# HTTP-Timeout für GLPI-Aufrufe.
|
||
GLPI_TIMEOUT=20s
|
||
###############################################################################
|
||
# 10. GLPI AI AGENT - OLLAMA-POOL
|
||
###############################################################################
|
||
# Einzelnode-Kompatibilität. Wird nur verwendet, wenn OLLAMA_URLS leer ist.
|
||
OLLAMA_URL=http://ollama:11434
|
||
|
||
# Mehrere Ollama-Instanzen, durch Komma getrennt. Alle Nodes sollten dieselbe
|
||
# Ollama-Version, dasselbe Chat-Modell und dasselbe Embedding-Modell besitzen.
|
||
# Beispiel für vorhandene Lenovo-Nodes:
|
||
# OLLAMA_URLS=http://10.20.30.21:11434,http://10.20.30.22:11434,http://10.20.30.23:11434
|
||
OLLAMA_URLS=
|
||
|
||
# Optionale lesbare Namen; Anzahl muss exakt zu OLLAMA_URLS passen.
|
||
# OLLAMA_NODE_NAMES=lenovo-01,lenovo-02,lenovo-03
|
||
OLLAMA_NODE_NAMES=
|
||
|
||
# Optionale Gewichte 1..100; nur für OLLAMA_ROUTING_MODE=weighted relevant.
|
||
# OLLAMA_NODE_WEIGHTS=1,1,1
|
||
OLLAMA_NODE_WEIGHTS=
|
||
|
||
# Routing-Modi:
|
||
# least_inflight = Node mit den wenigsten laufenden Requests (empfohlen)
|
||
# round_robin = zyklische Verteilung
|
||
# weighted = Verteilung anhand OLLAMA_NODE_WEIGHTS und Auslastung
|
||
# fastest_recent = bevorzugt die zuletzt schnellsten Nodes
|
||
OLLAMA_ROUTING_MODE=least_inflight
|
||
|
||
# Maximale parallele Requests JE Node. Für integrierte GPUs/RAM-Sharing 1.
|
||
OLLAMA_NODE_MAX_INFLIGHT=1
|
||
|
||
# Regelmäßige Prüfung von /api/tags.
|
||
OLLAMA_NODE_HEALTH_INTERVAL=15s
|
||
|
||
# Nach einem retryfähigen Netzwerk-/HTTP-Fehler wird der Node so lange nicht
|
||
# für neue Requests verwendet.
|
||
OLLAMA_NODE_FAILURE_COOLDOWN=30s
|
||
|
||
# Maximalzeit für einen einzelnen Request an genau einen Node. Der übergeordnete
|
||
# Analyse-Timeout kann kürzer sein und hat dann Vorrang.
|
||
OLLAMA_NODE_REQUEST_TIMEOUT=10m
|
||
|
||
# Bei Netzwerkfehlern, HTTP 408/429/5xx oder ungültigem Response-JSON auf einen
|
||
# anderen kompatiblen Node wechseln.
|
||
OLLAMA_FAILOVER_ENABLED=true
|
||
|
||
# Maximale Anzahl verschiedener Nodes je logischem Request. 0 bedeutet:
|
||
# automatisch alle konfigurierten Nodes. Ein positiver Wert darf höchstens der
|
||
# Zahl der OLLAMA_URLS-Einträge entsprechen.
|
||
OLLAMA_FAILOVER_ATTEMPTS=0
|
||
|
||
# Bei abweichenden Chat-/Embedding-Modelldigests wird der Pool vollständig
|
||
# fail-closed. Für reproduzierbare Entscheidungen unbedingt true lassen.
|
||
OLLAMA_REQUIRE_SAME_MODEL_DIGEST=true
|
||
|
||
# true: Jeder Node muss auch OLLAMA_EMBEDDING_MODEL installiert haben.
|
||
# Bei RAG empfohlen. false erlaubt Chat-only-Nodes; Embedding-Requests werden
|
||
# trotzdem nur an Nodes mit erkanntem Embedding-Modell gesendet.
|
||
OLLAMA_REQUIRE_EMBEDDING_MODEL=true
|
||
|
||
# OLLAMA_MODEL ist bereits oben im gemeinsamen Compose-/Ollama-Bereich gesetzt:
|
||
# OLLAMA_MODEL=qwen3:8b
|
||
# Embedding-Modell für RAG.
|
||
OLLAMA_EMBEDDING_MODEL=embeddinggemma
|
||
|
||
# Modellspezifisches Retrieval-Prompting.
|
||
# auto = Modell automatisch erkennen; für embeddinggemma empfohlen.
|
||
# plain = keine modellspezifischen Retrieval-Prompts.
|
||
KNOWLEDGE_EMBEDDING_PROFILE=auto
|
||
|
||
# Gesamtbudget für Ollama-Aufrufe und Fallback für Node-Request-Timeouts.
|
||
# OLLAMA_TIMEOUT ist bereits oben gesetzt.
|
||
# OLLAMA_MAX_CONCURRENT bleibt als Legacy-Alias für
|
||
# OLLAMA_NODE_MAX_INFLIGHT erhalten, falls der neue Wert nicht gesetzt ist.
|
||
|
||
# Maximale Anzahl generierter Tokens für strukturierte Antworten.
|
||
OLLAMA_NUM_PREDICT=768
|
||
# Wiederholungen bei semantisch/strukturell fehlerhaftem Modell-JSON.
|
||
# Diese Wiederholungen sind von Netzwerk-Failover getrennt.
|
||
OLLAMA_JSON_RETRIES=1
|
||
# Ollama-Modell nach Benutzung im Speicher halten.
|
||
OLLAMA_KEEP_ALIVE=10m
|
||
# Thinking bei unterstützten Modellen deaktivieren.
|
||
OLLAMA_THINK=false
|
||
###############################################################################
|
||
# 11. KNOWLEDGE BASE / RAG - BASIS
|
||
###############################################################################
|
||
# Knowledge-Verzeichnis IM Agent-Container.
|
||
#
|
||
# Compose sollte hierhin KB_DATA_PATH mounten:
|
||
# ${KB_DATA_PATH:-./knowledge}:/app/knowledge:ro
|
||
KNOWLEDGE_DIR=/app/knowledge
|
||
# Gesamtes Retrieval-System aktivieren.
|
||
RAG_ENABLED=true
|
||
###############################################################################
|
||
# 12. EXTERNE KNOWLEDGE-KATEGORIEN
|
||
###############################################################################
|
||
# Verhalten bei String-/Fremdkategorien, z. B.:
|
||
#
|
||
# "AI-Staging"
|
||
# "Outlook"
|
||
# "E-Mail"
|
||
# "Signatur"
|
||
#
|
||
# Mögliche Werte:
|
||
#
|
||
# unscoped
|
||
# Artikel bleibt nutzbar.
|
||
# Fremdkategorien können als Retrieval-Metadaten dienen.
|
||
#
|
||
# skip
|
||
# Artikel mit unbekannten Kategorien überspringen.
|
||
#
|
||
# strict
|
||
# unbekannte Kategorie als Fehler behandeln.
|
||
#
|
||
# Für eine gemeinsam mit anderen Anwendungen verwendete KB:
|
||
# unscoped
|
||
KNOWLEDGE_CATEGORY_MODE=unscoped
|
||
# Optionales Mapping von Fremdkategorien auf GLPI-ITIL-Kategorie-IDs.
|
||
#
|
||
# Beispiel knowledge-category-map.json:
|
||
#
|
||
# {
|
||
# "Outlook": 12,
|
||
# "E-Mail": 12,
|
||
# "Active Directory": 2,
|
||
# "Security": [20,21]
|
||
# }
|
||
KNOWLEDGE_CATEGORY_MAP_FILE=/app/data/knowledge-category-map.json
|
||
# Optional bestimmte KB-Dateien ignorieren.
|
||
#
|
||
# Beispiele:
|
||
# KB-SEC-ATTCK-*.json
|
||
# legacy-*.json,external-only-*.json
|
||
#
|
||
# Leer:
|
||
# keine zusätzlichen Ignore-Regeln.
|
||
KNOWLEDGE_IGNORE_GLOBS=
|
||
###############################################################################
|
||
# 13. PERSISTENTER KNOWLEDGE-INDEX
|
||
###############################################################################
|
||
# Mögliche Werte:
|
||
#
|
||
# incremental
|
||
# Persistent gespeicherten Index sofort verwenden.
|
||
# Neue/geänderte Dateien anschließend inkrementell nachziehen.
|
||
# Für Produktion empfohlen.
|
||
#
|
||
# rebuild
|
||
# vollständigen Index neu erzeugen.
|
||
#
|
||
# readonly
|
||
# nur bestehenden Index verwenden, keine Änderungen übernehmen.
|
||
KNOWLEDGE_INDEX_MODE=incremental
|
||
# Anzahl Texte pro Embedding-Batch.
|
||
KNOWLEDGE_EMBED_BATCH_SIZE=64
|
||
# Intervall für neue/geänderte/gelöschte Dateien.
|
||
#
|
||
# Beispiele:
|
||
# 30s
|
||
# 1m
|
||
# 5m
|
||
#
|
||
# 0:
|
||
# keinen automatischen Hintergrundscan durchführen.
|
||
KNOWLEDGE_INDEX_SCAN_INTERVAL=5m
|
||
###############################################################################
|
||
# 14. RETRIEVAL / DYNAMISCHE KANDIDATENAUSWAHL
|
||
###############################################################################
|
||
# Unterhalb dieses Retrieval-Scores wird eine KB nicht als geeigneter
|
||
# Kandidat betrachtet.
|
||
#
|
||
# Der Wert ist KEINE Wahrscheinlichkeit.
|
||
KNOWLEDGE_RETRIEVAL_FLOOR=0.30
|
||
# Maximale Differenz zum besten Treffer.
|
||
#
|
||
# Beispiel:
|
||
#
|
||
# bester Treffer 0.82
|
||
# MAX_GAP 0.20
|
||
# dynamischer Cutoff 0.62
|
||
#
|
||
# Ein Kandidat mit 0.55 würde dann nicht an die KI gesendet.
|
||
KNOWLEDGE_CANDIDATE_MAX_GAP=0.20
|
||
# Maximale Anzahl Knowledge-Kandidaten, die tatsächlich an Ollama gehen.
|
||
KNOWLEDGE_TOP_K=6
|
||
# Anzahl Kandidaten für Audit / Diagnose.
|
||
#
|
||
# Kann größer als KNOWLEDGE_TOP_K sein.
|
||
KNOWLEDGE_AUDIT_TOP_K=10
|
||
###############################################################################
|
||
# 15. HYBRID-RETRIEVAL - RANKING-GEWICHTE
|
||
###############################################################################
|
||
# Die Werte beschreiben die Gewichtung beim KB-Ranking.
|
||
#
|
||
# Summe aktuell:
|
||
# 1.0
|
||
#
|
||
# Fehlende Metadaten sollen nicht automatisch negativ bewertet werden.
|
||
# Embedding-/Chunk-Semantik.
|
||
KNOWLEDGE_WEIGHT_SEMANTIC=0.45
|
||
# Ticket-Betreff gegenüber KB-Titel.
|
||
KNOWLEDGE_WEIGHT_TITLE=0.20
|
||
# Lexikalische / sprachliche Übereinstimmung.
|
||
KNOWLEDGE_WEIGHT_LEXICAL=0.20
|
||
# KB-Keywords.
|
||
KNOWLEDGE_WEIGHT_KEYWORDS=0.075
|
||
# Kategorie-/Lernsignal.
|
||
KNOWLEDGE_WEIGHT_CATEGORY=0.075
|
||
###############################################################################
|
||
# 16. FINALE EVIDENZ FÜR AUTO-REPLY
|
||
###############################################################################
|
||
# Mindestwert der FINALEN Evidenz.
|
||
#
|
||
# WICHTIG:
|
||
# Das ist nicht der reine Retrieval-Score.
|
||
#
|
||
# Die finale Evidenz kombiniert:
|
||
# - Retrieval
|
||
# - AI Confidence
|
||
# - Kategorieübereinstimmung
|
||
KNOWLEDGE_MIN_SCORE=0.70
|
||
# Gewicht Retrieval.
|
||
KNOWLEDGE_EVIDENCE_WEIGHT_RETRIEVAL=0.45
|
||
# Gewicht KI-Auswahl / KI-Confidence.
|
||
KNOWLEDGE_EVIDENCE_WEIGHT_AI=0.35
|
||
# Gewicht Kategorieübereinstimmung.
|
||
KNOWLEDGE_EVIDENCE_WEIGHT_CATEGORY=0.20
|
||
###############################################################################
|
||
# 17. KNOWLEDGE-CHUNKING
|
||
###############################################################################
|
||
# Ungefähre Anzahl Wörter pro Dokument-Chunk.
|
||
KNOWLEDGE_CHUNK_WORDS=160
|
||
# Überlappung benachbarter Chunks.
|
||
KNOWLEDGE_CHUNK_OVERLAP_WORDS=30
|
||
# Maximale Anzahl Chunks pro KB-Dokument.
|
||
KNOWLEDGE_MAX_CHUNKS_PER_DOC=24
|
||
# Maximale Anzahl Query-Chunks bei sehr langen Tickets.
|
||
KNOWLEDGE_MAX_QUERY_CHUNKS=64
|
||
# Maximale Anzahl Kategorien im Kategorie-Prompt.
|
||
CATEGORY_PROMPT_LIMIT=80
|
||
###############################################################################
|
||
# 18. KNOWLEDGE-QUELLEN / TRUST POLICY
|
||
###############################################################################
|
||
# Quellen für normale Knowledge-Suche und mögliche Antwortkandidaten.
|
||
# Indexiert wird die Vereinigung mit KNOWLEDGE_CATEGORY_SOURCES.
|
||
#
|
||
# Beispiele:
|
||
# internal-kb
|
||
# glpi-kb
|
||
# runbook
|
||
# vendor-docs
|
||
KNOWLEDGE_ALLOWED_SOURCES=internal-kb,glpi-kb,vendor-docs,vendor-docs-ms,vendor-docs-linux,vendor-docs-sec
|
||
# Quellen, die ausschließlich die Kategorieentscheidung unterstützen.
|
||
# Ohne explizite Angabe wird aus Kompatibilitätsgründen KNOWLEDGE_ALLOWED_SOURCES verwendet.
|
||
# Mit "none" wird Knowledge-Einfluss auf die Kategorisierung deaktiviert.
|
||
KNOWLEDGE_CATEGORY_SOURCES=internal-category
|
||
# Nur diese Quellen dürfen grundsätzlich automatische Antworten liefern.
|
||
#
|
||
# Muss eine Teilmenge von KNOWLEDGE_ALLOWED_SOURCES sein.
|
||
#
|
||
# Beispiel zum kompletten Abschalten:
|
||
# KNOWLEDGE_AUTO_REPLY_SOURCES=none
|
||
KNOWLEDGE_AUTO_REPLY_SOURCES=internal-kb,glpi-kb,vendor-docs,vendor-docs-ms,vendor-docs-linux,vendor-docs-sec
|
||
# Webbasierte Bearbeitung von Agent-eigenen Knowledge-Artikeln.
|
||
#
|
||
# Diese werden unter:
|
||
# DATA_DIR/knowledge-managed
|
||
# gespeichert.
|
||
#
|
||
# Das statische KNOWLEDGE_DIR bleibt read-only.
|
||
KNOWLEDGE_WEB_EDIT_ENABLED=true
|
||
###############################################################################
|
||
# 19. GLPI KNOWLEDGE BASE CONNECTOR
|
||
###############################################################################
|
||
# GLPI-interne Knowledge Base synchronisieren.
|
||
GLPI_KB_ENABLED=true
|
||
# auto:
|
||
# Agent ermittelt die KnowbaseItem-Route aus /api.php/doc.json.
|
||
GLPI_KB_PATH=auto
|
||
# Optionaler serverseitiger GLPI-Filter.
|
||
#
|
||
# Leer:
|
||
# alle für den Service Account sichtbaren Artikel, begrenzt durch LIMIT.
|
||
GLPI_KB_FILTER=
|
||
# Maximale Anzahl GLPI-KB-Artikel.
|
||
GLPI_KB_LIMIT=500
|
||
# Synchronisationsintervall.
|
||
GLPI_KB_SYNC_INTERVAL=10m
|
||
# source-Wert importierter GLPI-KB-Artikel.
|
||
GLPI_KB_SOURCE=glpi-kb
|
||
# true:
|
||
# GLPI-KB-Artikel können grundsätzlich Auto-Replies auslösen.
|
||
#
|
||
# Zusätzlich gelten weiterhin alle anderen Policy-Gates wie Retrieval,
|
||
# KI-Auswahl, Evidenz, Sprache, Stil und vorhandene Antworten.
|
||
GLPI_KB_AUTO_REPLY=true
|
||
# Whitelist der GLPI KNOWLEDGE-BASE-Kategorie-IDs.
|
||
#
|
||
# WICHTIG:
|
||
# Dies sind NICHT die ITIL-/Ticketkategorie-IDs. Ein kategorisierter Artikel
|
||
# ist genau dann grundsätzlich für Auto-Reply freigegeben, wenn mindestens
|
||
# eine seiner GLPI-KB-Kategorien hier enthalten ist.
|
||
#
|
||
# Mehrere Werte:
|
||
# 1,2,7
|
||
GLPI_KB_AUTO_REPLY_CATEGORY_IDS=1
|
||
# VERALTET / WIRD IGNORIERT:
|
||
# Ticket-/ITIL-Kategorien geben einen GLPI-Wissensartikel nicht mehr für
|
||
# Auto-Reply frei. Die Variable bleibt nur erhalten, damit alte .env-Dateien
|
||
# verständlich migriert werden können. Wert bitte leeren oder entfernen.
|
||
GLPI_KB_AUTO_REPLY_ITIL_CATEGORY_IDS=
|
||
# GLPI-KB-Artikel ohne Knowledge-Base-Kategorie bleiben standardmäßig gesperrt.
|
||
#
|
||
# true:
|
||
# Solche Artikel dürfen ausschließlich dann Auto-Reply verwenden, wenn ihre
|
||
# konkrete GLPI-KnowbaseItem-ID zusätzlich in
|
||
# GLPI_KB_AUTO_REPLY_UNCATEGORIZED_ARTICLE_IDS steht.
|
||
GLPI_KB_AUTO_REPLY_ALLOW_UNCATEGORIZED=false
|
||
# Explizite GLPI-KnowbaseItem-IDs für unkategorisierte Artikel.
|
||
# Beispiel: Das synchronisierte Dokument GLPI-KB-1 entspricht Artikel-ID 1.
|
||
# Diese Liste ist bei ALLOW_UNCATEGORIZED=true verpflichtend.
|
||
GLPI_KB_AUTO_REPLY_UNCATEGORIZED_ARTICLE_IDS=
|
||
###############################################################################
|
||
# 20. HUMAN-IN-THE-LOOP / KATEGORIE-LERNEN
|
||
###############################################################################
|
||
# Menschlich bestätigte/korrigierte Entscheidungen als Lernbeispiele verwenden.
|
||
#
|
||
# Der Agent lernt NICHT automatisch aus seinen eigenen unbestätigten
|
||
# Entscheidungen.
|
||
LEARNING_ENABLED=true
|
||
# Maximale Anzahl gespeicherter Beispiele.
|
||
LEARNING_MAX_EXAMPLES=500
|
||
# Maximale Beispiele pro Kategorie im Prompt.
|
||
LEARNING_EXAMPLES_PER_CATEGORY=5
|
||
###############################################################################
|
||
# 21. KOMMUNIKATIONSPOLICY
|
||
###############################################################################
|
||
# Erwartete Sprache von Auto-Reply-KBs.
|
||
COMMUNICATION_LANGUAGE=de-DE
|
||
# Erwarteter Kommunikationsstil.
|
||
COMMUNICATION_STYLE=formal
|
||
# Wird vor die Knowledge-Antwort gesetzt.
|
||
COMMUNICATION_SALUTATION=Guten Tag,
|
||
# Abschluss.
|
||
COMMUNICATION_CLOSING=Mit freundlichen Grüßen
|
||
COMMUNICATION_SIGNATURE=IT-Service
|
||
###############################################################################
|
||
# 22. OPERATIONAL CONTEXT - GLOBAL
|
||
###############################################################################
|
||
# Globaler Schalter für zusätzliche Betriebsinformationen:
|
||
# - Changes
|
||
# - Major Incidents
|
||
# - Requester-Geräte
|
||
# - Uptime Kuma
|
||
CONTEXT_ENABLED=true
|
||
# Timeout für Kontextabfragen.
|
||
CONTEXT_TIMEOUT=12s
|
||
# Mindestscore, ab dem Incident/Outage als für das Ticket relevant gilt.
|
||
CONTEXT_RELEVANCE_MIN_SCORE=0.20
|
||
# true:
|
||
# Fehler einer aktivierten Kontextquelle blockieren Auto-Reply.
|
||
#
|
||
# Fail-closed und für Produktion empfohlen.
|
||
CONTEXT_BLOCK_AUTO_REPLY_ON_ERRORS=true
|
||
# true:
|
||
# relevante zentrale Störung blockiert individuelle Standardantwort.
|
||
CONTEXT_BLOCK_AUTO_REPLY_ON_INCIDENT=true
|
||
###############################################################################
|
||
# 23. GLPI CHANGE CALENDAR
|
||
###############################################################################
|
||
CHANGE_CALENDAR_ENABLED=true
|
||
# API-Route.
|
||
GLPI_CHANGE_PATH=/Assistance/Change
|
||
# Optionaler serverseitiger GLPI-Filter.
|
||
GLPI_CHANGE_FILTER=
|
||
# Maximale Anzahl geladener Changes.
|
||
GLPI_CHANGE_LIMIT=100
|
||
# Betrachteter Zeitraum in der Vergangenheit.
|
||
CHANGE_LOOKBACK=72h
|
||
# Betrachteter Zeitraum in der Zukunft.
|
||
CHANGE_LOOKAHEAD=24h
|
||
###############################################################################
|
||
# 24. MAJOR INCIDENTS
|
||
###############################################################################
|
||
# Major Incidents über GLPI-Tickets ermitteln.
|
||
#
|
||
# Erst aktivieren, wenn GLPI_MAJOR_INCIDENT_FILTER getestet wurde.
|
||
MAJOR_INCIDENTS_ENABLED=false
|
||
# Expliziter Filter für Tickets, die als Major Incident gelten.
|
||
GLPI_MAJOR_INCIDENT_FILTER=
|
||
GLPI_MAJOR_INCIDENT_LIMIT=20
|
||
###############################################################################
|
||
# 25. REQUESTER -> GERÄT / ASSET CONTEXT
|
||
###############################################################################
|
||
# Zusätzlich zu direkt verknüpften Ticket-Assets Geräte des Requesters suchen.
|
||
USER_DEVICE_CONTEXT_ENABLED=true
|
||
# Asset-Routen.
|
||
GLPI_USER_DEVICE_PATHS=/Assets/Computer
|
||
# {{user_id}} wird vom Agenten ersetzt.
|
||
GLPI_USER_DEVICE_FILTER_TEMPLATE=user.id=={{user_id}}
|
||
# Maximale Anzahl Geräte je Suche.
|
||
GLPI_USER_DEVICE_LIMIT=20
|
||
###############################################################################
|
||
# 26. UPTIME KUMA
|
||
###############################################################################
|
||
# Globaler Schalter für Uptime-Kuma-Kontext.
|
||
UPTIME_KUMA_ENABLED=false
|
||
UPTIME_KUMA_URL=https://uptime.example.com
|
||
# Mögliche Werte:
|
||
#
|
||
# metrics
|
||
# authentifizierte Prometheus-Metrics.
|
||
#
|
||
# status_page
|
||
# öffentliche/publizierte Statusseiten.
|
||
UPTIME_KUMA_MODE=metrics
|
||
# Nur in metrics erforderlich.
|
||
UPTIME_KUMA_API_KEY=<SECRET>
|
||
# Nur in status_page erforderlich.
|
||
#
|
||
# Mehrere Slugs:
|
||
# it-services,network,applications
|
||
UPTIME_KUMA_STATUS_PAGES=it-services
|
||
UPTIME_KUMA_TIMEOUT=10s
|
||
# Maximale Anzahl gleichzeitig berücksichtigter Probleme.
|
||
UPTIME_KUMA_MAX_ISSUES=20
|
||
# Maintenance ebenfalls als Kontext berücksichtigen.
|
||
UPTIME_KUMA_INCLUDE_MAINTENANCE=true
|
||
|
||
# Optional: bei eindeutig passender Uptime-Kuma-Störung oder Wartung einen
|
||
# ausschließlich vom Betreiber vorgegebenen Text senden. Die KI erzeugt keinen
|
||
# Antworttext; sie wählt nur einen aktiven Kandidaten und liefert eine Confidence.
|
||
CONTEXT_STATUS_REPLY_ENABLED=false
|
||
CONTEXT_STATUS_REPLY_MIN_RELEVANCE=0.50
|
||
CONTEXT_STATUS_REPLY_MIN_AI_CONFIDENCE=0.80
|
||
# Finaler Score = Relevanz × KI-Confidence.
|
||
CONTEXT_STATUS_REPLY_MIN_FINAL_SCORE=0.45
|
||
# Literal \n wird als Zeilenumbruch interpretiert. Verfügbare Platzhalter:
|
||
# {{service_name}}, {{status}}, {{status_page}}, {{message}},
|
||
# {{incident_title}}, {{incident_content}}, {{last_heartbeat}}
|
||
CONTEXT_INCIDENT_REPLY_TEXT=Zu Ihrer Meldung liegt derzeit wahrscheinlich eine zentrale Störung bei {{service_name}} vor. Die Einschränkung kann damit zusammenhängen. Wir beobachten den Status.
|
||
CONTEXT_MAINTENANCE_REPLY_TEXT=Für {{service_name}} läuft derzeit eine Wartung. Die von Ihnen beschriebene Einschränkung kann damit zusammenhängen. Bitte testen Sie den Dienst nach Abschluss der Wartung erneut.
|
||
###############################################################################
|
||
# 27. POLICY-GATES
|
||
###############################################################################
|
||
# Automatische Kategorisierung zulassen.
|
||
AUTO_CATEGORY=true
|
||
# Automatische Antworten grundsätzlich zulassen.
|
||
#
|
||
# DRY_RUN=true verhindert trotzdem das tatsächliche Schreiben nach GLPI.
|
||
AUTO_REPLY=true
|
||
# Mindestconfidence der KI für Kategorieänderungen.
|
||
CATEGORY_CONFIDENCE=0.90
|
||
# Mindestconfidence der KI für Antwortauswahl.
|
||
#
|
||
# Dies allein reicht NICHT für Auto-Reply.
|
||
# Zusätzlich gelten unter anderem:
|
||
#
|
||
# - Knowledge-Evidenz
|
||
# - Retrieval-Regeln
|
||
# - Source Policy
|
||
# - KB auto_reply
|
||
# - Kommunikationspolicy
|
||
# - Followup-Prüfung
|
||
# - Kontext-/Incident-Regeln
|
||
# - zweite Followup-Prüfung unmittelbar vor dem Schreiben
|
||
REPLY_CONFIDENCE=0.97
|
||
###############################################################################
|
||
# 28. KI-PRIORISIERUNG
|
||
###############################################################################
|
||
# Separater KI-Lauf zur Empfehlung der GLPI-Priorität. Der Lauf wird im
|
||
# Diagnose-Cockpit unabhängig von Kategorie, Status und Antwort gespeichert.
|
||
PRIORITY_ENABLED=true
|
||
# Standardmäßig Shadow Mode: Empfehlung und Policy-Gates werden protokolliert,
|
||
# GLPI wird nicht verändert. Für Live-Schreibzugriffe zusätzlich DRY_RUN=false.
|
||
AUTO_PRIORITY=false
|
||
PRIORITY_CONFIDENCE=0.88
|
||
# Eigener Fail-open-Timeout für diesen optionalen KI-Lauf. Kategorie und Antwort laufen danach weiter.
|
||
PRIORITY_ANALYSIS_TIMEOUT=45s
|
||
# Automatische Erhöhung je Ticketlauf; Herabstufungen sind grundsätzlich gesperrt.
|
||
PRIORITY_MAX_INCREASE=1
|
||
# Nur kontrollierte, kommaseparierte Grundcodes dürfen eine Empfehlung tragen.
|
||
PRIORITY_ALLOWED_REASON_CODES=multiple_users_affected,site_affected,organization_affected,core_service_unavailable,security_incident_suspected,data_loss_possible,legal_or_regulatory_risk,business_deadline,no_workaround,safety_relevant,exam_or_event_critical
|
||
###############################################################################
|
||
# 29. ZEITGESTEUERTE KI-ESKALATION
|
||
###############################################################################
|
||
# Unabhängiger Scheduler. Er prüft offene Tickets auch ohne Änderung von date_mod.
|
||
ESCALATION_ENABLED=false
|
||
# Standardmäßig werden nur Diagnose-/Shadow-Läufe erzeugt.
|
||
# Live-Ausführung benötigt zusätzlich DRY_RUN=false und GLPI_AGENT_USER_ID.
|
||
AUTO_ESCALATION=false
|
||
ESCALATION_SCAN_INTERVAL=15m
|
||
# Mindestalter des Tickets seit date_creation, bevor es in den Eskalationsscan gelangt.
|
||
ESCALATION_MIN_AGE=4h
|
||
# Mindestdauer seit der letzten menschlichen Aktivität für den Grund
|
||
# no_human_response. SLA-, Security- und Major-Incident-Gründe können unabhängig
|
||
# davon greifen. Agent-Followups werden über GLPI_AGENT_USER_ID ausgenommen.
|
||
ESCALATION_MIN_INACTIVITY=2h
|
||
# Eigenes KI-Zeitbudget; blockiert die normalen Ticketläufe nicht unbegrenzt.
|
||
ESCALATION_ANALYSIS_TIMEOUT=45s
|
||
ESCALATION_CONFIDENCE=0.88
|
||
ESCALATION_MAX_LEVEL=3
|
||
# Zeitfenster vor time_to_resolve, in dem sla_at_risk deterministisch wahr wird.
|
||
ESCALATION_SLA_RISK_WINDOW=2h
|
||
# Aktionsspezifische Mindeststufen.
|
||
ESCALATION_SERVICE_OWNER_MIN_LEVEL=2
|
||
ESCALATION_MANAGER_REVIEW_MIN_LEVEL=3
|
||
# Mindest-Relevanz eines vom Kontextkollektor gelieferten Major Incidents.
|
||
ESCALATION_MAJOR_INCIDENT_MIN_RELEVANCE=0.50
|
||
ESCALATION_ALLOWED_REASON_CODES=no_human_response,sla_at_risk,sla_breached,business_deadline,no_workaround,security_incident_suspected,unassigned,major_incident_candidate
|
||
# Jede Aktion muss einzeln freigegeben werden. Sichere Einführung: zunächst nur
|
||
# none,raise_priority; weitere Aktionen erst nach Konfiguration der Ziele aktivieren.
|
||
# Verfügbar: none,raise_priority,assign_second_level,assign_security_team,
|
||
# notify_service_owner,link_major_incident,request_manager_review
|
||
ESCALATION_ALLOWED_ACTIONS=none,raise_priority
|
||
|
||
# Zielgruppen/-benutzer für Zuweisungs- und Benachrichtigungsaktionen.
|
||
# Es handelt sich um numerische GLPI-IDs.
|
||
ESCALATION_SECOND_LEVEL_GROUP_ID=0
|
||
ESCALATION_SECURITY_GROUP_ID=0
|
||
ESCALATION_SERVICE_OWNER_GROUP_ID=0
|
||
ESCALATION_SERVICE_OWNER_USER_ID=0
|
||
ESCALATION_MANAGER_REVIEW_GROUP_ID=0
|
||
ESCALATION_MANAGER_REVIEW_USER_ID=0
|
||
|
||
# Zu jeder ausgeführten Aktion kann ein privater GLPI-Followup geschrieben werden.
|
||
ESCALATION_ADD_PRIVATE_FOLLOWUP=true
|
||
# Platzhalter: {{ticket_id}}, {{ticket_name}}, {{level}}, {{action}}, {{reason}},
|
||
# {{reason_codes}}, {{major_incident_id}}, {{major_incident_name}},
|
||
# {{major_incident_score}}.
|
||
wird als Zeilenumbruch expandiert.
|
||
ESCALATION_SECOND_LEVEL_NOTE=Automatische Eskalation Stufe {{level}}: Übergabe an den Second-Level-Support. Gründe: {{reason_codes}}. KI-Begründung: {{reason}}
|
||
ESCALATION_SECURITY_NOTE=Automatische Eskalation Stufe {{level}}: Übergabe an das Security-Team. Gründe: {{reason_codes}}. KI-Begründung: {{reason}}
|
||
ESCALATION_SERVICE_OWNER_NOTE=Automatische Eskalation Stufe {{level}}: Service Owner wurde zur Prüfung einbezogen. Gründe: {{reason_codes}}. KI-Begründung: {{reason}}
|
||
ESCALATION_MAJOR_INCIDENT_NOTE=Automatische Eskalation Stufe {{level}}: Verknüpfung mit Major Incident #{{major_incident_id}} ({{major_incident_name}}). Relevanz: {{major_incident_score}}. Gründe: {{reason_codes}}.
|
||
ESCALATION_MANAGER_REVIEW_NOTE=Automatische Eskalation Stufe {{level}}: Management-Review angefordert. Gründe: {{reason_codes}}. KI-Begründung: {{reason}}
|
||
|
||
# Optionaler ausgehender Webhook für Service-Owner- und Management-Benachrichtigungen.
|
||
# Das Token wird nie über die Status-API ausgegeben.
|
||
ESCALATION_WEBHOOK_URL=
|
||
ESCALATION_WEBHOOK_BEARER_TOKEN=
|
||
ESCALATION_WEBHOOK_TIMEOUT=10s
|
||
# Nur für isolierte Testnetze; HTTPS ist der sichere Standard.
|
||
ESCALATION_WEBHOOK_ALLOW_INSECURE_HTTP=false
|
||
|
||
# GLPI-Adapter für Zuweisungen. Die Feldnamen müssen zur OpenAPI-Beschreibung der
|
||
# konkreten GLPI-Installation passen. Unterstützte Payload-Formen:
|
||
# assigned_groups/assigned_users = Liste von {"id":...};
|
||
# group/group_tech/user/user_tech = einzelnes {"id":...}.
|
||
GLPI_ESCALATION_GROUP_PATCH_FIELD=assigned_groups
|
||
GLPI_ESCALATION_USER_PATCH_FIELD=assigned_users
|
||
|
||
# Installationsspezifischer Adapter für link_major_incident. Beide Werte sind
|
||
# erforderlich. Platzhalter im Pfad/JSON: {{ticket_id}}, {{source_ticket_id}},
|
||
# {{major_incident_id}}, {{target_ticket_id}}.
|
||
GLPI_ESCALATION_ITIL_LINK_PATH=
|
||
GLPI_ESCALATION_ITIL_LINK_BODY=
|
||
|
||
# Leer = GLPI_TICKET_FILTER verwenden. Für Produktion ausdrücklich auf offene,
|
||
# eskalierbare Status und die gewünschte Einheit beschränken.
|
||
GLPI_ESCALATION_FILTER=
|
||
GLPI_ESCALATION_LIMIT=100
|
||
###############################################################################
|
||
# 30. WORKER / PRIORITÄTSQUEUE
|
||
###############################################################################
|
||
# Maximale Anzahl wartender Jobs.
|
||
QUEUE_SIZE=256
|
||
# Parallele Ticket-Worker. Der Ollama-Pool kann nur so viele unabhängige
|
||
# Ticketpipelines gleichzeitig verteilen, wie Worker aktiv sind. Für drei
|
||
# gleichartige Nodes ist WORKERS=3 ein sinnvoller Lasttest; jeder Node bleibt
|
||
# zusätzlich durch OLLAMA_NODE_MAX_INFLIGHT begrenzt.
|
||
WORKERS=2 |