Glossar

Agent

Ein Service, der autonom oder semi-autonom eine Aufgabe erfüllt. Die Aufgaben-Steuerung kann entweder durch eine SOP (Standard Operating Procedure) vorgegeben werden oder mittels LLM in einem Planungs-Task erzeugt werden. Ein Agent kann sich je nach Aufgabe anderer Services bedienen und verfügt über ein Kontext-Gedächtnis, geeignete Tools und weitere kognitive Fähigkeiten.

API-Gateway

Zentrale Schnittstelle, die als Load Balancer für Service-Aufrufe fungiert und eine Service-Registry integriert. Alle Frontends können über das API-Gateway auf die verschiedenen Services zugreifen.

Embedding

Eine mathematische Repräsentation von Texten, Bildern oder Daten als Vektor (Zahlenreihe). Embeddings ermöglichen es, die semantische Ähnlichkeit zwischen Inhalten berechenbar zu machen, was die Grundlage für die Suche in Vektordatenbanken bildet.

F13

Ein modularer, auf Mikroservices basierender KI-Chat-Dienst des Landes Baden-Württemberg. F13 fungiert als Client-Anwendung, die über das LLM-Gateway mit verschiedenen Modellen kommuniziert.

GitOps

Ein Betriebsmodell für die Verwaltung von Infrastruktur und Anwendungen. Im KIVA-Projekt erfolgen Updates und Deployments (z. B. via Helmfile) deklarativ über Git-Repositories, was Audit-Trails und Wiederherstellbarkeit sicherstellt.

Guardrails (Leitplanken)

Sicherheitsmechanismen, die in Input-Guardrails und Output-Guardrails unterschieden werden. Input-Guardrails schützen vor unbeabsichtigter Veröffentlichung privater Informationen, Model-Jailbreaking und gefährlichen Prompts. Output-Guardrails verhindern toxische Antworten, Halluzinationen und die Preisgabe sensitiver Informationen.

Halluzination

Phänomen bei LLMs, bei dem das Modell aufgrund statistischer Unsicherheiten falsche oder erfundene Informationen generiert. Tritt auf, wenn der Prompt "out-of-distribution" liegt oder im Training nicht gesehene Tokens enthält, wodurch das LLM in eine Pfad-Abhängigkeit abdriftet, d. h. plausibel klingende, aber falsche Fakten erfindet.

Hybrid-Authentifizierung

Ein Sicherheitsmodell, das technische Identitäten und Benutzeridentitäten kombiniert. Dabei authentifiziert ein Service Account die Anwendung gegenüber dem Gateway (technischer Zugriff), während ein Keycloak JWT den Endbenutzer identifiziert (für Berechtigungen und Audit).

Inference Engine

Komponente, die sich um das Laden von Modellen, den Aufruf für Next-Token-Prediction und das Stapeln von Anfragen (Batching) kümmert. Beispiele sind Server-Frameworks wie vLLM, llama.cpp oder Runtimes wie Ollama (Wrapper für llama.cpp).

KIVA JWT

Standard JWT-Token mit organisatorischen Claims (user_id, team_id, org_id, cost_center), der optionalen Kontext für Monitoring und Kostenzuordnung liefert und nicht-blockierend funktioniert – das System arbeitet auch ohne gültiges JWT. Es wird im Header X-Kiva-JWT übertragen und enthält organisatorische Claims (z. B. user_id, team_id), die primär für das Monitoring und die Kostenzuordnung genutzt werden.

Kong Gateway

Ein optionales API-Gateway, das vor dem LLM-Gateway platziert werden kann, um Enterprise-Funktionen wie erweitertes Rate-Limiting, IP-Whitelisting und DDoS-Schutz bereitzustellen.

Large Language Model (LLM)

Ein auf neuronalen Netzwerken basierendes KI-Modell, das darauf trainiert wurde, menschliche Sprache zu verstehen und zu generieren. Es sagt basierend auf statistischen Wahrscheinlichkeiten das nächste Wort (Token) in einer Sequenz vorher. In der KIVA-Architektur werden sowohl proprietäre (z. B. via OpenAI-Schnittstelle) als auch offene Modelle (via Inference Engine) eingesetzt.

LiteLLM (KIVA Fork)

Die Basis-Software für das LLM-Gateway. KIVA nutzt einen speziellen Fork (Version v1.74.4), bei dem Enterprise-Komponenten entfernt wurden, um eine reine MIT-Lizenzierung und volle Datensouveränität zu gewährleisten.

LLM-Gateway

Einheitliche Schnittstelle zu LLMs, die das OpenAI-API unterstützt. Übernimmt Routing der Anfragen, Load Balancing, Berechtigungsverwaltung, Token-Tracking, Rate-Limits, Callbacks und Post-Processing. In KIVA wird das LLM-Gateway durch LiteLLM implementiert und fungiert als zentrale Komponente der Architektur. Es dient als Proxy zwischen Anwendungen (wie F13) und den Inference Engines und verwaltet Authentifizierung, Routing, Budgets und Logging.

MCP (Model Context Protocol)

Standardisiertes Protokoll zur Anbindung verschiedener Datenquellen, Tools und Templates an KI-Anwendungen. Ermöglicht bidirektionale Kommunikation zwischen KI-Anwendungen und MCP-Servern für gezielte Informationsbereitstellung und wird in KIVA genutzt, um z. B. RAG (Retrieval-Augmented Generation) oder Agenten-Systeme zu ermöglichen.

Observability

Fähigkeit, Aktionen von KI-Systemen in realen Umgebungen zu überwachen und zu verstehen. Umfasst die kontinuierliche Sammlung und Analyse von Metriken, Logging-Einträgen und Traces zur Identifikation von Problemen und kontinuierlichen Verbesserung.

OpenTelemetry

Open-Source-Initiative, die APIs, SDKs und Tools als Observability-Framework bereitstellt. Ermöglicht standardisierte Instrumentalisierung, Erzeugung, Sammlung und Export von Telemetrie-Daten (Logs, Metriken, Traces).

Organisatorische Claims

Attribute innerhalb eines Tokens (z. B. im KIVA JWT), die Informationen zur Organisationsstruktur enthalten. Dazu gehören Benutzer-IDs, Team-IDs oder Kostenstellen-Tags, die für die Spend-Log-Auswertung wichtig sind.

OSS Review Toolkit (ORT)

Ein Werkzeug zur automatisierten Compliance-Prüfung in der CI/CD-Pipeline. Es analysiert Abhängigkeiten (Dependencies) des Projekts, um Lizenzen zu identifizieren und sicherzustellen, dass keine rechtlichen Risiken durch inkompatible oder proprietäre Lizenzen entstehen.

Prompt-Store

System zum Teilen und Verwalten von Prompts zwischen Benutzern und Nutzergruppen. Ermöglicht Versionierung und Wiederverwendung von Prompt-Templates über MCP-Anbindung.

RAG (Retrieval-Augmented Generation)

Ein Architekturmuster, das die Textgenerierung eines LLMs mit einer Informationsabfrage aus externen Quellen kombiniert. Bevor das Modell antwortet, durchsucht das System eine Wissensbasis (z. B. Vektordatenbank) nach relevanten Fakten und fügt diese dem Kontext hinzu. Dies reduziert Halluzinationen und ermöglicht Antworten auf Basis interner, nicht-öffentlicher Daten.

Rate-Limiting

Mechanismus zur Begrenzung der Anfragen an das System. Limits können auf Basis von "Requests per Minute" (RPM), "Tokens per Minute" (TPM) oder Budget-Obergrenzen definiert werden, um Überlastung und Kostenexplosionen zu verhindern.

REUSE-Standard

Ein Standard, der im Projekt verwendet wird, um Lizenz- und Copyright-Informationen maschinenlesbar und eindeutig direkt im Quellcode zu hinterlegen. Dies erleichtert die automatisierte Compliance-Prüfung.

Service Account

Zweckgebundene Authentifizierungseinheit mit eigenen Budgets, Modellzugriffen und Rate-Limits. Ersetzt individuelle Benutzerverwaltung durch funktionale Accounts (z. B. "f13-chatbot", "oracle-forms-migration") und vereinfacht die Verwaltung erheblich. Als technische Identität (im Gegensatz zu einer personenbezogenen Identität) wird der Service Account für die Kommunikation zwischen Diensten (Service-to-Service) genutzt. Die Authentifizierung erfolgt über einen API-Schlüssel (Bearer Token sa-xxxxxxxx) und stellt die primäre Sicherheitsebene dar.

Spend-Log

Ein Protokoll, das die Nutzung und Kosten der KI-Modelle aufzeichnet. Die Daten werden aggregiert (z. B. LiteLLM_DailyTeamSpend), um eine genaue Kostenkontrolle und Weiterverrechnung auf Team- oder Organisationsebene zu ermöglichen.

Task

Model-Task-driven Service, bei dem eine spezifische Aufgabe mit einem dafür optimierten Modell ausgeführt wird. Die Optimierung erfolgt durch verschiedene Trainingsmethoden wie Supervised Finetuning oder Reinforcement Learning.

Tool

Service ohne Modellzugriff, der mit der Außenwelt (Environment) des Systems interagiert. Typische Environments sind das Internet, Fachverfahren oder Sandbox-Umgebungen zur Code-Ausführung.

TTFT (Time to First Token)

Latenz-Metrik, die die Zeit vom API-Aufruf bis zur Erzeugung des ersten Tokens misst. Wichtige Kennzahl für die Benutzererfahrung beim Streaming von LLM-Antworten.

Vektordatenbank

Spezialisierte Datenbank zur Verwaltung von Embeddings (Vektordarstellungen von Texten) für semantische Suche. In KIVA implementiert durch ChromaDB für RAG-Anwendungen.

vLLM

Eine hochperformante Open-Source-Bibliothek für LLM-Inferenz und -Bereitstellung. Im KIVA-Projekt wird vLLM als Standard-Backend für das lokale Hosting von Modellen (wie Llama 3) auf eigener GPU-Hardware verwendet.