add multi model

patch_history/RETRIEX_PATCH_97_PER_LLM_CALL_MODEL_OVERRIDE_README.md

@@ -0,0 +1,182 @@
+# RetrieX Patch 97 - Per-LLM-Call Model Override
+
+## Ziel
+
+Dieser Patch ergaenzt eine minimale YAML-Konfiguration, mit der fuer jeden bestehenden LLM-Call optional ein anderes Ollama-Modell angegeben werden kann.
+
+Der Patch aendert bewusst keine fachliche Logik:
+
+- keine Aenderung an Retrieval, Scoring oder Ranking
+- keine Aenderung an Shopquery-Guards oder Shop-Matching
+- keine Aenderung an PromptBuilder-Regeln
+- keine neue Admin-Pflege fuer Modellprofile
+- keine neue Routing- oder Multi-Agent-Logik
+
+Wenn fuer einen Call kein Modell gesetzt ist, nutzt der Call wie bisher das aktive Standardmodell aus `ModelGenerationConfig`.
+
+## Neue YAML-Konfiguration
+
+Datei: `config/retriex/model.yaml`
+
+```yaml
+retriex.llm.call_models:
+  input_normalization: null
+  shop_query_optimization: null
+  final_answer: null
+```
+
+Beispiel, um Normalisierung und Shopquery-Optimierung ueber ein schnelleres Modell laufen zu lassen:
+
+```yaml
+retriex.llm.call_models:
+  input_normalization: 'llama3.1'
+  shop_query_optimization: 'llama3.1'
+  final_answer: null
+```
+
+`null` oder ein leerer Wert bedeutet: Standardmodell verwenden.
+
+## Geaenderte Dateien
+
+- `config/retriex/model.yaml`
+- `config/services.yaml`
+- `src/Agent/AgentRunner.php`
+- `src/Infrastructure/OllamaClient.php`
+- `src/Config/RetriexEffectiveConfigProvider.php`
+
+## Technische Umsetzung
+
+### 1. OllamaClient unterstuetzt optionalen Modellnamen pro Call
+
+Die bestehenden Methoden akzeptieren nun optional einen Modellnamen:
+
+```php
+public function stream(string $prompt, ?string $modelName = null): Generator
+public function generate(string $prompt, ?string $modelName = null): string
+```
+
+Der Request-Payload nutzt dann:
+
+- den uebergebenen Modellnamen, wenn er nicht leer ist
+- sonst das bestehende Standardmodell aus `ModelGenerationConfig`
+
+Alle sonstigen Optionen wie Temperatur, `top_k`, `top_p`, `repeat_penalty`, `num_ctx` und `num_predict` bleiben unveraendert.
+
+### 2. AgentRunner reicht nur den konfigurierten Override weiter
+
+Die drei bestehenden LLM-Calls wurden minimal erweitert:
+
+- `input_normalization`
+- `shop_query_optimization`
+- `final_answer`
+
+Die fachliche Verarbeitung vor und nach diesen Calls bleibt unveraendert.
+
+### 3. Effective Config Dump zeigt die Werte an
+
+`RetriexEffectiveConfigProvider` gibt die neue Konfiguration unter `llm.call_models` aus und validiert sie grob:
+
+- `llm.call_models` muss eine Map sein
+- Werte muessen `null` oder String sein
+- unbekannte Call-Namen erzeugen nur eine Warnung, keinen Fehler
+
+## Bewusst nicht geaendert
+
+- Keine separaten Modellparameter pro Call.
+- Keine getrennten Timeouts pro Call.
+- Kein JSON-Schema-Output fuer Shopquery.
+- Keine Aenderung daran, wann welcher LLM-Call ausgefuehrt wird.
+- Keine Aenderung an bestehenden Follow-up-, Accessory-, Code- oder Product-Identity-Guards.
+
+## Lokale Checks
+
+Im Patch-Arbeitsverzeichnis ausgefuehrt:
+
+```bash
+php -l src/Infrastructure/OllamaClient.php
+php -l src/Agent/AgentRunner.php
+php -l src/Config/RetriexEffectiveConfigProvider.php
+python3 - <<'PY'
+import yaml, pathlib
+for path in pathlib.Path('config/retriex').glob('*.yaml'):
+    with path.open(encoding='utf-8') as f:
+        yaml.safe_load(f)
+print('all retriex yaml OK')
+PY
+```
+
+Nicht lokal ausfuehrbar, weil `vendor/` im ZIP nicht enthalten ist:
+
+```bash
+bin/console mto:agent:config:validate
+bin/console mto:agent:regression:test
+bin/console mto:agent:config:audit-source --details
+bin/console mto:agent:config:audit-patterns --details
+```
+
+## Test nach Einspielen
+
+### Default-Verhalten
+
+Mit der ausgelieferten Konfiguration:
+
+```yaml
+retriex.llm.call_models:
+  input_normalization: null
+  shop_query_optimization: null
+  final_answer: null
+```
+
+Erwartung:
+
+- Alle LLM-Calls nutzen weiterhin das aktive Standardmodell.
+- Bestehende Regressionen muessen unveraendert gruen bleiben.
+
+### Schnelles Modell fuer Shopquery testen
+
+Konfiguration:
+
+```yaml
+retriex.llm.call_models:
+  input_normalization: null
+  shop_query_optimization: 'llama3.1'
+  final_answer: null
+```
+
+Erwartung:
+
+- Nur die Shopquery-Optimierung sendet `model: llama3.1` an Ollama.
+- Die finale Antwort nutzt weiterhin das aktive Standardmodell.
+- Shopquery-Guards und Shop-Ergebnislogik bleiben identisch.
+
+### Schnelles Modell fuer Normalisierung und Shopquery testen
+
+Konfiguration:
+
+```yaml
+retriex.llm.call_models:
+  input_normalization: 'llama3.1'
+  shop_query_optimization: 'llama3.1'
+  final_answer: null
+```
+
+Erwartung:
+
+- Input-Normalisierung und Shopquery-Optimierung verwenden `llama3.1`.
+- Die finale Antwort verwendet weiterhin das aktive Standardmodell.
+
+### Finalantwort testweise umstellen
+
+Konfiguration:
+
+```yaml
+retriex.llm.call_models:
+  input_normalization: null
+  shop_query_optimization: null
+  final_answer: 'llama3.1'
+```
+
+Erwartung:
+
+- Nur der finale Antwortstream nutzt `llama3.1`.
+- Die restliche Pipeline bleibt unveraendert.