p86a-e
This commit is contained in:
@@ -0,0 +1,58 @@
|
||||
# RetrieX Patch p86b - Referential Product Links RAG Fallback
|
||||
|
||||
## Ziel
|
||||
|
||||
Referenzielle Shop-Follow-ups wie:
|
||||
|
||||
```text
|
||||
gebe mir links zu den produkten aus dem shop
|
||||
```
|
||||
|
||||
duerfen nicht als schwache Meta-Query wie `links zu aus` an Shopware gehen, wenn im vorherigen Kontext konkrete Produkte/Modelle genannt wurden.
|
||||
|
||||
## Problem in p86
|
||||
|
||||
p86 ersetzte schwache Produktlisten-Follow-up-Queries nur, wenn Produktanker im Commerce-History-Kontext gefunden wurden. In manchen Runs war dieser Kontext fuer diesen Follow-up-Pfad leer, gekuerzt oder nicht ausreichend nutzbar, obwohl die aktuelle RAG-Retrieval-Stufe passende Produktkontexte geladen hatte. Dadurch blieb die Query unveraendert bei `links zu aus`.
|
||||
|
||||
## Aenderung
|
||||
|
||||
`guardReferentialProductListShopQueryWithHistoryAnchors()` erhaelt nun zusaetzlich die aktuellen RAG-`knowledgeChunks`.
|
||||
|
||||
Reihenfolge:
|
||||
|
||||
1. Produkt-/Modellanker aus dem aktuellen Commerce-History-Kontext extrahieren.
|
||||
2. Falls dort keine Anker gefunden werden: Produkt-/Modellanker aus den aktuellen RAG-Knowledge-Chunks extrahieren.
|
||||
3. Nur bei referenziellen Produktlisten-Shop-Follow-ups und nur bei schwachen/noisy Shopqueries ersetzen.
|
||||
4. Produktlisten-Anker-Patterns werden auf einzelne Zeilen begrenzt, damit `Testomat 808` nicht versehentlich mit dem naechsten Satz/Wort zusammengezogen wird.
|
||||
|
||||
Damit bleibt der Fix generisch:
|
||||
|
||||
- keine Sonderlogik fuer medizinische Geraete
|
||||
- keine festen Produktnamen im PHP-Core
|
||||
- keine neue Ranking-/Retrieval-/Shop-Matching-Logik
|
||||
- keine automatische Shop-Ausloesung durch `geraet`
|
||||
|
||||
## Erwartetes Verhalten
|
||||
|
||||
```text
|
||||
geraet zur messung Prozesswasser in medizinischen Geraeten
|
||||
-> RAG-Antwort nennt z. B. Testomat 2000 self clean, Testomat 2000 CAL, Testomat 808
|
||||
|
||||
gebe mir links zu den produkten aus dem shop
|
||||
-> Shopquery wird aus Produktankern gebildet, nicht aus `links zu aus`
|
||||
```
|
||||
|
||||
## Geaenderte Dateien
|
||||
|
||||
- `src/Agent/AgentRunner.php`
|
||||
- `config/retriex/genre.yaml`
|
||||
|
||||
## Lokale Checks
|
||||
|
||||
- `php -l src/Agent/AgentRunner.php`
|
||||
- `php -l src/Config/AgentRunnerConfig.php`
|
||||
- `php -l src/Config/RetriexEffectiveConfigProvider.php`
|
||||
- YAML parse
|
||||
- p86b referential product-link fallback smoke
|
||||
|
||||
Symfony-Console-Checks muessen in der Zielumgebung mit vorhandenem `vendor/` ausgefuehrt werden.
|
||||
@@ -0,0 +1,65 @@
|
||||
# RETRIEX Patch 86C - Referential Product Links Empty-History Fallback
|
||||
|
||||
## Ziel
|
||||
|
||||
Behebt den Fall, dass referenzielle Shop-Follow-ups wie
|
||||
|
||||
```text
|
||||
gebe mir links zu den produkten aus dem shop
|
||||
```
|
||||
|
||||
weiterhin als schwache Meta-Query wie `links zu aus` an Shopware gesendet werden, wenn der vorherige fachliche Antwortkontext nicht im Commerce-History-Kontext vorhanden ist.
|
||||
|
||||
## Ursache
|
||||
|
||||
p86/p86b enthielten bereits die generische Produktlisten-Follow-up-Logik inklusive RAG-Fallback. Die Guard-Methode wurde jedoch zu früh verlassen, sobald der Commerce-History-Kontext leer war:
|
||||
|
||||
```php
|
||||
trim($commerceHistoryContext) === ''
|
||||
```
|
||||
|
||||
Damit konnte der RAG-Fallback nicht greifen, obwohl aktuelle Knowledge-Chunks passende Produkt-/Modellanker enthielten.
|
||||
|
||||
## Änderung
|
||||
|
||||
- `src/Agent/AgentRunner.php`
|
||||
- Entfernt den frühen Return bei leerem Commerce-History-Kontext in `guardReferentialProductListShopQueryWithHistoryAnchors()`.
|
||||
- Nutzt History-Anker nur, wenn History vorhanden ist.
|
||||
- Fällt sonst auf Produktanker aus aktuellen Knowledge-Chunks zurück.
|
||||
- Log-Meldung präzisiert: History **oder RAG** Product Anchors.
|
||||
|
||||
## Erwartetes Verhalten
|
||||
|
||||
Vorher:
|
||||
|
||||
```text
|
||||
Follow-up: gebe mir links zu den produkten aus dem shop
|
||||
Gesendete Suchquery: links zu aus
|
||||
```
|
||||
|
||||
Nachher, wenn die vorherige/fachliche RAG-Antwort Produktanker wie Testomat-Modelle enthält:
|
||||
|
||||
```text
|
||||
Follow-up: gebe mir links zu den produkten aus dem shop
|
||||
Gesendete Suchquery: testomat 2000 self clean testomat 2000 cal testomat 808
|
||||
```
|
||||
|
||||
Die Logik bleibt generisch:
|
||||
|
||||
- keine Sonderlogik für medizinische Geräte
|
||||
- keine feste Produktliste im Core
|
||||
- kein pauschales `gerät => testomat`
|
||||
- nur bei bereits aktivem Shop-/Commerce-Follow-up
|
||||
- nur bei schwacher/noisy Meta-Query
|
||||
|
||||
## Lokale Checks
|
||||
|
||||
```text
|
||||
php -l src/Agent/AgentRunner.php
|
||||
php -l src/Config/AgentRunnerConfig.php
|
||||
php -l src/Config/RetriexEffectiveConfigProvider.php
|
||||
YAML parse OK
|
||||
p86c smoke OK
|
||||
```
|
||||
|
||||
Symfony-Console-Checks müssen in einer Umgebung mit installiertem `vendor/` ausgeführt werden.
|
||||
@@ -0,0 +1,70 @@
|
||||
# RETRIEX Patch 86D - Referential Product Links Deep Context Anchors
|
||||
|
||||
## Ziel
|
||||
|
||||
Behebt den weiterhin fehlerhaften Flow:
|
||||
|
||||
```text
|
||||
gerät zur messung Prozesswasser in medizinischen Geräten
|
||||
→ gebe mir links zu den produkten aus dem shop
|
||||
```
|
||||
|
||||
Die Shopquery durfte nicht als schwache Meta-/Noise-Query an Shopware gehen:
|
||||
|
||||
```text
|
||||
links zu aus
|
||||
```
|
||||
|
||||
sondern muss bei einem referenziellen Produktlisten-Follow-up die zuvor genannten Produkt-/Modellanker aus dem Verlauf verwenden.
|
||||
|
||||
## Tiefenanalyse
|
||||
|
||||
p86/p86b/p86c lagen am richtigen Themenbereich, aber der Hebel war noch nicht robust genug:
|
||||
|
||||
1. Die finale Shopquery entsteht in diesem Flow über den Standalone-/Fallback-Pfad und wird durch Stopword-/Positive-Filterung zu `links zu aus` reduziert.
|
||||
2. Der Produktlisten-Guard sitzt zwar vor der Shop-Suche, war aber zu abhängig vom direkt übergebenen `commerceHistoryContext`.
|
||||
3. In der aktuellen Basis war außerdem noch der frühe Return bei leerem `commerceHistoryContext` vorhanden, wodurch der RAG-/History-Fallback nicht zuverlässig erreicht wurde.
|
||||
4. Selbst bei History-Treffern konnten Produktanker wie `Testomat 2000 CAL-Version bietet` zu breit extrahiert werden, weil die vorhandenen Patterns mit `iu` arbeiten und dadurch Großbuchstabenklassen case-insensitiv wirken.
|
||||
|
||||
## Änderung
|
||||
|
||||
- `src/Agent/AgentRunner.php`
|
||||
- Der Produktlisten-Follow-up-Guard erhält jetzt zusätzlich die `userId`.
|
||||
- Der Guard verlässt die Methode nicht mehr nur wegen leerem `commerceHistoryContext`.
|
||||
- Er durchsucht mehrere Kontextkandidaten:
|
||||
- direkt übergebenen Commerce-History-Kontext
|
||||
- erweiterten Verlauf innerhalb des bestehenden Context-Fallback-Budgets
|
||||
- Full-History-Kontext, wenn in der bestehenden Config erlaubt
|
||||
- danach weiterhin aktuelle Knowledge-Chunks als Fallback
|
||||
- Produktlisten-Anker werden kanonisiert:
|
||||
- `Testomat 2000 self clean` bleibt erhalten.
|
||||
- `Testomat 2000 CAL-Version bietet` wird zu `testomat 2000 cal` gekürzt.
|
||||
- `Testomat 808-Version` wird zu `testomat 808` gekürzt.
|
||||
- Die Kanonisierung nutzt die bereits YAML-gepflegte `adjacent_variant_terms`-Liste aus `genre.yaml`; keine neue harte Produktliste im PHP-Core.
|
||||
|
||||
## Erwartetes Verhalten
|
||||
|
||||
```text
|
||||
Follow-up: gebe mir links zu den produkten aus dem shop
|
||||
Vorher: links zu aus
|
||||
Nachher: testomat 2000 self clean testomat 2000 cal testomat 808
|
||||
```
|
||||
|
||||
Die Logik bleibt generisch:
|
||||
|
||||
- keine Sonderlogik für medizinische Geräte
|
||||
- keine feste Produktliste im Core
|
||||
- kein pauschales `gerät => testomat`
|
||||
- nur bei bereits aktivem Shop-/Commerce-Follow-up
|
||||
- nur bei schwacher/noisy Meta-Query
|
||||
- Produktanker kommen aus Verlauf/RAG und werden gegen vorhandene YAML-Variantentokens normalisiert
|
||||
|
||||
## Lokale Checks
|
||||
|
||||
```text
|
||||
php -l src/Agent/AgentRunner.php
|
||||
YAML parse OK
|
||||
p86d anchor canonicalization smoke OK
|
||||
```
|
||||
|
||||
Symfony-Console-Checks müssen in einer Umgebung mit installiertem `vendor/` ausgeführt werden.
|
||||
@@ -0,0 +1,66 @@
|
||||
# RetrieX Patch p86e - Referential Product Links Early Context Resolution
|
||||
|
||||
## Problem
|
||||
|
||||
Referential shop follow-ups such as:
|
||||
|
||||
```text
|
||||
gebe mir links zu den produkten aus dem shop
|
||||
```
|
||||
|
||||
could still be converted into a weak/noisy Shopware query such as:
|
||||
|
||||
```text
|
||||
links zu aus
|
||||
```
|
||||
|
||||
In the affected flow, the previous RAG answer listed concrete products such as `Testomat® 2000 self clean`, `Testomat® 2000 CAL` and `Testomat® 808`, but the shop-query resolver treated the current follow-up as a standalone/current-input query before the product-list history anchor guard could reliably replace it.
|
||||
|
||||
## Root cause
|
||||
|
||||
The prompt is referential and commerce-related, but it is not covered by the older `meta-only` fallback path. Therefore `resolveShopSearchQuery()` could return the current cleaned prompt before consulting product anchors from recent history or the frontend context hint.
|
||||
|
||||
The later p86 guard existed, but this flow showed that relying only on a late correction after standalone cleanup was not robust enough.
|
||||
|
||||
## Change
|
||||
|
||||
p86e moves product-list follow-up resolution into the early shop-query resolution path:
|
||||
|
||||
- product-list follow-up prompts now explicitly require commerce history/context usage;
|
||||
- they are no longer isolated as standalone shop queries;
|
||||
- deterministic standalone query generation is disabled for this prompt class;
|
||||
- before returning optimized/current prompt fallback queries, `resolveShopSearchQuery()` tries to replace weak product-list meta queries with product/model anchors from history/context/RAG fallback;
|
||||
- product-list meta prompts whose tokens are all configured noise terms are treated as weak even when the raw prompt is longer than the normal weak-query term limit.
|
||||
|
||||
Expected behavior:
|
||||
|
||||
```text
|
||||
gerät zur messung Prozesswasser in medizinischen Geräten
|
||||
-> RAG answer lists products
|
||||
|
||||
gebe mir links zu den produkten aus dem shop
|
||||
-> testomat 2000 self clean testomat 2000 cal testomat 808
|
||||
```
|
||||
|
||||
## Guardrails
|
||||
|
||||
- No hardcoded medical-device rule.
|
||||
- No fixed product list in PHP.
|
||||
- No `gerät => testomat` shortcut.
|
||||
- Active only for referential product-list shop follow-ups.
|
||||
- Still requires weak/noisy shop query detection before replacing the query.
|
||||
- No changes to retrieval, ranking, scoring or Shopware matching.
|
||||
|
||||
## Local checks
|
||||
|
||||
```text
|
||||
php -l src/Agent/AgentRunner.php
|
||||
```
|
||||
|
||||
Additional reflection smoke test verified that the product-list guard and the early resolver return:
|
||||
|
||||
```text
|
||||
testomat 2000 self clean testomat 2000 cal testomat 808
|
||||
```
|
||||
|
||||
for the failing product-link follow-up when the previous turn contains the listed Testomat products.
|
||||
@@ -0,0 +1,70 @@
|
||||
# RetrieX Patch p86 - Referential Product List Shop Anchors
|
||||
|
||||
## Ziel
|
||||
|
||||
Referenzielle Shop-Follow-ups wie:
|
||||
|
||||
```text
|
||||
gebe mir links zu den produkten aus dem shop
|
||||
```
|
||||
|
||||
durften nicht mehr zu schwachen Meta-/Noise-Queries wie `links zu aus` werden, wenn die vorherige Antwort bereits konkrete Produkte oder Gerätemodelle genannt hat.
|
||||
|
||||
## Problem
|
||||
|
||||
Der bestehende History-/Shopquery-Repair war auf Zubehör-/Indikator-Referenzen und einzelne Hauptgeräte-Follow-ups fokussiert. Eine generische Nachfrage nach Links/Preisen zu "den Produkten" wurde zwar als Shop-Intent geroutet, verlor aber die zuvor genannten Produktanker und sendete eine nutzlose Query wie `links zu aus` an die Shopsuche.
|
||||
|
||||
## Lösung
|
||||
|
||||
p86 ergänzt einen generischen Product-List-Follow-up-Guard:
|
||||
|
||||
- erkennt referenzielle Produktlisten-Follow-ups über YAML-gepflegte `product_terms` + `shop_terms`
|
||||
- greift nur bei schwachen Shopqueries, deren Tokens vollständig aus YAML-gepflegten `noise_terms` bestehen
|
||||
- extrahiert Produkt-/Modellanker aus der neuesten Assistant-Antwort über YAML-gepflegte `anchor_patterns`
|
||||
- ersetzt die schwache Query durch die extrahierten Produktanker
|
||||
- bleibt auf Shopquery-Reparatur beschränkt und erzeugt keinen neuen Shop-Intent
|
||||
|
||||
Beispiel:
|
||||
|
||||
```text
|
||||
Vorherige Antwort nennt:
|
||||
- Testomat 2000 self clean
|
||||
- Testomat 2000 CAL
|
||||
- Testomat 808
|
||||
|
||||
Follow-up:
|
||||
gebe mir links zu den produkten aus dem shop
|
||||
|
||||
Vor p86:
|
||||
links zu aus
|
||||
|
||||
Nach p86:
|
||||
testomat 2000 self clean testomat 2000 cal testomat 808
|
||||
```
|
||||
|
||||
## Guardrails
|
||||
|
||||
- Keine harte Branchenlogik fuer "medizinische Geräte".
|
||||
- Keine Änderung an Retrieval, Ranking, Scoring oder Shop-Matching.
|
||||
- Kein pauschales `produkt => testomat` oder `gerät => testomat`.
|
||||
- Der Guard greift nur, wenn bereits Commerce-/Shop-Intent aktiv ist.
|
||||
- Bereits konkrete Shopqueries mit Produkt-/Modellanker werden nicht überschrieben.
|
||||
|
||||
## Dateien
|
||||
|
||||
- `config/retriex/genre.yaml`
|
||||
- `src/Agent/AgentRunner.php`
|
||||
- `src/Config/AgentRunnerConfig.php`
|
||||
- `src/Config/RetriexEffectiveConfigProvider.php`
|
||||
|
||||
## Lokale Checks
|
||||
|
||||
```text
|
||||
php -l src/Agent/AgentRunner.php
|
||||
php -l src/Config/AgentRunnerConfig.php
|
||||
php -l src/Config/RetriexEffectiveConfigProvider.php
|
||||
YAML parse OK
|
||||
p86 smoke OK: referential product-list prompt + weak query + product-anchor extraction
|
||||
```
|
||||
|
||||
Die Symfony-Console-Checks muessen in der Zielumgebung mit installiertem `vendor/` ausgefuehrt werden.
|
||||
Reference in New Issue
Block a user