KI-Orchestrierung via LiteLLM
Entkopplung von KI-Modellen, logische Rollen (Router, Writer) und Google Gemini Anbindung
KI-Orchestrierung via LiteLLM
Um das Backend herstellerunabhängig und zukunftssicher zu halten, spricht LoreKeeper nicht direkt mit proprietären Provider-APIs, sondern nutzt den Open-Source LiteLLM Proxy.
graph LR
Backend[LoreKeeper Backend] -->|OpenAI SDK Standard| LiteLLM[LiteLLM Proxy :4000]
LiteLLM -->|router-model| GeminiFlash[Google Gemini 2.5 Flash]
LiteLLM -->|writer-model| GeminiPro[Google Gemini 2.5 Pro]
LiteLLM -->|vision-model| GeminiVision[Google Gemini 3.5 Flash (Vision)]Logische Modelle vs. Physische Modelle
Das Backend adressiert ausschließlich logische Rollen:
| Logischer Bezeichner | Physisches Modell | Zweck | Begründung & Tuning |
|---|---|---|---|
router-model | gemini/gemini-2.5-flash | Prompt-Analyse & Abfrageplanung | Extrem schnell (< 500ms), kostengünstig, ideal für strukturierte JSON-Extraktion. |
writer-model | gemini/gemini-2.5-pro | Narrative Prosa, Kontinuitäts-Audit | Großes Kontextfenster, hohe literarische Ausdruckskraft und präzise Regeltreue. |
vision-model | gemini/gemini-3.5-flash | Visuelle Entitätserkennung & Segmentierung | Schnelle multimodale Analyse mit Gemini 3 Flash. Optimiert mit thinking: { budget_tokens: 0 } zur Vermeidung von Token-Erschöpfung bei Wimmelszenen. |
Konfiguration (litellm_config.yaml)
model_list:
- model_name: vision-model
litellm_params:
model: gemini/gemini-3.5-flash
api_key: os.environ/GEMINI_API_KEY
temperature: 0.1
max_tokens: 8192
- model_name: router-model
litellm_params:
model: gemini/gemini-2.5-flash
api_key: os.environ/GEMINI_API_KEY
temperature: 0.1
max_tokens: 4096
- model_name: writer-model
litellm_params:
model: gemini/gemini-2.5-pro
api_key: os.environ/GEMINI_API_KEY
temperature: 0.7
max_tokens: 8192
litellm_settings:
drop_params: true
request_timeout: 120Vision-Optimierungen: Token-Budget & Adaptive Auflösung
Multimodale Frontier-Modelle (wie Gemini 2.5) nutzen internes Reasoning ("Thinking"). Bei komplexen Panoramaseiten führt unbegrenztes Thinking zum Verbrauch von bis zu 8.000 Reasoning-Tokens, wodurch das Antwort-JSON abgeschnitten werden kann.
- Thinking-Budget-Steuerung: Für reine Objekterkennung wird
thinking: { budget_tokens: 0 }übergeben. Das Modell generiert Bounding Boxes ohne Reasoning-Verzögerung in unter 10 Sekunden. - Adaptive Auflösungskappe:
- Einzelseiten: max. 1.024 px.
- Doppelseiten/Panoramen (Aspect Ratio > 1,35): max. 1.536 px, sodass selbst Miniaturen > 46 px Detailschärfe behalten.
- Resilienter JSON-Parser (
robustParseEntityJson): Sollte eine extrem dichte Szene dennoch abgeschnitten werden, schließt der Parser die Datenstruktur am letzten vollständigen Objekt ab und rettet alle bis dahin generierten Bounding Boxes. - Verlustfreier Master-Crop: Die Bounding Boxes nutzen relative Promille-Koordinaten ($0 \dots 1000$). Das physikalische Cropping durch Sharp erfolgt stets auf dem unkomprimierten Original-Masterbild.
Modellaustausch ohne Code-Änderung
Soll beispielsweise das Writer-Modell durch ein anderes Modell (z. B. Claude 3.5 Sonnet oder GPT-4o) ersetzt werden, muss keine einzige Zeile TypeScript im Backend geändert werden:
- model_name: writer-model
litellm_params:
model: anthropic/claude-3-5-sonnet-20241022
api_key: os.environ/ANTHROPIC_API_KEYNach einem Reload des LiteLLM-Containers nutzt das Backend automatisch das neue Modell über dieselbe OpenAI-kompatible Schnittstelle.