ML-Modelle schnell in LLM-Agenten integrieren: Das Predikit-Framework für LLM-abrufbare Modelle

von Denis Shokhirev, Enterprise AI Architect aus Erlangen. In den letzten sechs Monaten habe ich für DACH-B2B-Kunden 14 produktive LLM-Agenten mit einem Stack aus Claude, Supabase, n8n, Doppler und selbst gehostetem Postgres bereitgestellt. Die größte Hürde im Produktivbetrieb: Eigene ML-Modelle sicher, auditierbar und schnell in LLM-Agenten einzubinden – nicht als Demo, sondern für reale B2B-Prozesse.

Das Problem: ML-Modelle in LLM-Agenten – Risiken und Reibungsverluste

Gerade in regulierten Branchen wie Fintech, Logistik oder industrieller Automatisierung sind maßgeschneiderte ML-Modelle unverzichtbar: Scoring, Ereignisklassifikation, Prognosen und Validierungen. LLMs können jedoch keinen fremden Python-Code direkt ausführen. Ohne standardisierte Schnittstelle werden Integrationen zum Flickenteppich: jeder Dienst anders, fehlende Auditierbarkeit, verschiedene Authentifizierungskonzepte – ein Risiko für Compliance und Wartbarkeit.

Das Muster: ML-Modelle als LLM-abrufbare Endpunkte kapseln

Predikit-Framework: Prinzip und Nutzen

Ich setze ein Muster ein, das ich Predikit nenne: Jedes ML-Modell wird über einen standardisierten HTTP/gRPC-Endpunkt verfügbar gemacht. Feste Input/Output-Schemata, Authentifizierung, Ratenbegrenzung und Logging sind obligatorisch. Der LLM-Agent ruft diesen Endpunkt als Tool oder Funktion auf, verarbeitet das strukturierte Ergebnis und bleibt so konform zu Compliance-Anforderungen (DSGVO, BSI Grundschutz, EU AI Act).

Ihre Vorteile

• Jedes ML-Modell (Python, Torch, ONNX, CatBoost) wird zum produktionsfähigen Dienst mit eindeutigem Vertrag.
• Zentrale Steuerung von Zugriff, Validierung, Audit und Skalierung.
• Backend-Wechsel oder Upgrade ohne Anpassung der LLM-Prompts oder Agenten-Logik möglich.

Technische Umsetzung: FastAPI & Function Calling

ML-Modell als FastAPI-Service

Schnellster Einstieg: Das Modell wird über FastAPI mit validierten Pydantic-Schemata bereitgestellt. Beispiel: Ein Fraud-Detection-Modell erhält eine Transaktion und gibt eine Betrugswahrscheinlichkeit zurück. Jeder Aufruf wird mit Authentifizierung und Logging versehen.

from fastapi import FastAPI, HTTPException, Request
from pydantic import BaseModel
import joblib

app = FastAPI()
model = joblib.load("fraud_model.pkl")

class Transaction(BaseModel):
    amount: float
    sender_id: str
    receiver_id: str

class Prediction(BaseModel):
    is_fraud: bool
    score: float

@app.post("/predict", response_model=Prediction)
async def predict(tx: Transaction, request: Request):
    api_key = request.headers.get("x-api-key")
    if api_key != "ihr-geheimer-key": raise HTTPException(401, "Unauthorized")
    features = [tx.amount, hash(tx.sender_id), hash(tx.receiver_id)]
    score = float(model.predict_proba([features])[0][1])
    # Logging in Postgres (Pseudocode)
    # log_prediction(tx, score, request.client.host)
    return {"is_fraud": score > 0.7, "score": score}

LLM-Function-Calling: Schema und Prompt

Moderne LLMs unterstützen Funktionsaufrufe mit Schema (OpenAI, Claude). Das Modell wird als Tool mit explizitem JSON-Schema definiert. Beispiel:

{
  "name": "predict_transaction",
  "description": "Klassifiziert eine Transaktion hinsichtlich Betrugsverdacht.",
  "parameters": {
    "type": "object",
    "properties": {
      "amount": {"type": "number"},
      "sender_id": {"type": "string"},
      "receiver_id": {"type": "string"}
    },
    "required": ["amount", "sender_id", "receiver_id"]
  }
}

Der LLM-Agent ruft den Endpunkt exakt mit diesen Parametern auf – keine Inkonsistenzen, keine Copy-Paste-Fehler.

Sicherheit und Audit: Pflicht im DACH-Markt

Unverzichtbar sind Authentifizierung (API-Key, JWT) und umfassendes Logging der Aufrufe in einer dedizierten Audit-Tabelle (Postgres). Das ist nicht nur “Best Practice”, sondern regulatorisch gefordert (DSGVO, ISO 27001). Konkrete Patterns finden Sie in den FastAPI Security Docs.

Vergleich: Drei Ansätze zur Integration

Typische Fehlerquellen aus der Praxis

• Öffentliche Endpunkte ohne Authentifizierung – immer vermeiden.
• Fehlende Input-Validierung – LLMs erzeugen oft fehlerhafte Parameter.
• Ungeprüfte Speicherung sensibler Rohdaten – nur Hashes/IDs loggen.
• Unsichere Serialisierung (pickle) – joblib oder ONNX bevorzugen (siehe scikit-learn.org).

FAQ

Können Sie dieses Muster auch für Modelle in Java oder C++ anwenden?

Ja. Entscheidend ist die Bereitstellung einer stabilen HTTP/gRPC-API mit klaren Schemata – die Programmiersprache ist nachrangig.

Wie testen Sie die Integration zwischen LLM-Agent und ML-Endpunkt?

Unit-Tests für den FastAPI-Endpunkt (pytest) plus End-to-End-Tests mit echten LLM-Calls via n8n-Workflow.

Was tun, wenn das Modell GPU benötigt?

Predikit-Endpunkt auf GPU-fähigem Server bereitstellen oder Queue/Worker (Celery, Redis) verwenden.

Wie funktioniert das Audit-Logging?

Eigene Audit-Tabelle in Postgres: Zeitstempel, gehashte Parameter, User-ID, Ergebnis, Endpunkt-Name.

Ist das auch mit selbst gehosteten LLMs einsetzbar?

Ja – entscheidend ist die Unterstützung von Tool/Funktionsaufrufen auf Seiten des LLM-Frameworks. Die API bleibt gleich.

In Ihrer Systemarchitektur: Binden Sie ML-Modelle direkt per Code ein oder über dedizierte Services? An welcher Stelle im Prozess treten die meisten Fehler im Produktivbetrieb auf – Input-Validierung, Zugriffskontrolle oder Logging? Ich biete einen kostenlosen 30-minütigen Stack-Audit für DACH-Unternehmen mit KI-Projekten im regulierten Umfeld an. Kontaktieren Sie mich auf LinkedIn oder schreiben Sie an @ger_dennis_ai.