LoreKeeper
Architektur

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 BezeichnerPhysisches ModellZweckBegründung & Tuning
router-modelgemini/gemini-2.5-flashPrompt-Analyse & AbfrageplanungExtrem schnell (< 500ms), kostengünstig, ideal für strukturierte JSON-Extraktion.
writer-modelgemini/gemini-2.5-proNarrative Prosa, Kontinuitäts-AuditGroßes Kontextfenster, hohe literarische Ausdruckskraft und präzise Regeltreue.
vision-modelgemini/gemini-3.5-flashVisuelle Entitätserkennung & SegmentierungSchnelle multimodale Analyse mit Gemini 3 Flash. Optimiert mit thinking: { budget_tokens: 0 } zur Vermeidung von Token-Erschöpfung bei Wimmelszenen.

Konfiguration (litellm_config.yaml)

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: 120

Vision-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.

  1. 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.
  2. 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.
  3. 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.
  4. 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_KEY

Nach einem Reload des LiteLLM-Containers nutzt das Backend automatisch das neue Modell über dieselbe OpenAI-kompatible Schnittstelle.

On this page