This commit is contained in:
team 1
2026-05-10 16:34:00 +02:00
parent 6e72dfb2e5
commit 36485027e6
3 changed files with 586 additions and 0 deletions

View File

@@ -0,0 +1,73 @@
# RetrieX Patch p86f - Multi Product Link Lookup
## Goal
Fix the remaining weakness after p86e for referential product-list follow-ups such as:
```text
gebe mir links zu den produkten aus dem shop
```
p86e correctly resolves product anchors from the previous answer, but several anchors can still be collapsed into one strict Shopware query. If that combined query returns no hits, p86f retries the already-resolved product anchors separately and merges the results.
## Scope
Changed file:
- `src/Agent/AgentRunner.php`
No YAML/config changes are required.
## Behavior
Before p86f, a follow-up could resolve to one combined query such as:
```text
<product anchor A> <product anchor B> <product anchor C>
```
This may be too strict for Shopware because it looks like one single product identity. p86f keeps the p86e context resolution, but when that search plus normal repair still yields no products, it performs separate safe lookups for the extracted product anchors.
## Guardrails
The new repair step is intentionally narrow:
- only runs for configured referential product-list follow-ups
- only runs when the current primary/repair result set is empty
- only uses product anchors extracted by the existing product-list-follow-up logic
- reuses the existing referenced-product-anchor result guard for every separate lookup
- deduplicates merged products by product number, id, URL or name
- does not change intent detection
- does not change Retrieval, Scoring, Ranking or Shop-Matching
- does not add hard-coded product names or domain-specific product lists
## Regression notes
The following flows should remain unaffected because the new method is gated behind `isReferentialProductListShopFollowUpPrompt()` and empty shop results:
- direct technical/RAG questions
- direct product searches
- p84 model acronym preservation, e.g. `Testomat LAB CL`
- p85b generic device exact-parameter anchor, e.g. device plus a configured measurement parameter
- accessory/indicator price follow-ups
- `Nur Zubehör anzeigen` / `Nur Geräte anzeigen` action flows unless they are explicitly product-list + shop-link/price follow-ups and have empty results
## Local checks
Executed locally in the ZIP workspace:
```text
php -l src/Agent/AgentRunner.php
find src -name '*.php' -print0 | xargs -0 -n1 php -l
YAML files readable smoke
p86f smoke OK
```
Symfony console checks were not executable in the ZIP workspace because `vendor/` is not included. Please run in the target environment:
```bash
php bin/console mto:agent:config:validate
php bin/console mto:agent:regression:test
php bin/console mto:agent:config:audit-source --details
php bin/console mto:agent:config:audit-patterns --details
```

View File

@@ -0,0 +1,106 @@
# RetrieX Patch p86g - Product List Follow-up Identity Link Guard
## Ziel
Referenzielle Shop-Follow-ups wie:
```text
gebe mir links zu den produkten aus dem shop
```
duerfen nach p86e/p86f zwar Produktanker aus dem Verlauf nutzen, sollen aber nicht auf Zubehoer-/Indikator-Treffer abdriften, nur weil diese Treffer in Beschreibung, Highlights oder Custom Fields kompatible Geraetenamen erwaehnen.
Beispielproblem:
```text
Vorherige Antwort nennt:
Testomat 2000 CAL, Testomat EVO TH, Testomat 808
Follow-up:
gebe mir links zu den produkten aus dem shop
Query:
testomat 2000 cal evo th 808
Problem:
Shop liefert Indikatoren/Zubehoer, weil diese in Metadaten zu Testomat passen.
```
## Ansatz
p86g erweitert den p86f-Repair von "nur bei leerer Trefferliste" auf "Trefferliste ist nicht als Produktidentitaet zum Verlaufanker passend".
Der Fix bleibt generisch:
- keine Sonderlogik fuer medizinische Geraete
- keine feste Produktliste im PHP-Core
- kein pauschales `geraet => testomat`
- kein Eingriff in Intent, Retrieval, Scoring, Ranking oder Shop-Matching
- greift nur bei referenziellen Produktlisten-/Shoplink-Follow-ups
## Technische Umsetzung
Geaendert:
- `src/Agent/AgentRunner.php`
Neue/angepasste Logik:
1. `repairProductListFollowUpShopResultsWithAnchorLookups()` ersetzt die bisherige reine Empty-Repair-Variante.
2. Bei referenziellen Produktlisten-Follow-ups werden vorhandene Shop-Treffer zuerst gegen die erkannten Produktanker gefiltert.
3. Ein Treffer gilt nur dann als Identitaetsmatch, wenn Produktname oder URL-Slug mit dem Produktanker beginnt.
4. Treffer, deren Name/Slug zusaetzliche Zubehoer-Rollenbegriffe enthalten, werden fuer reine Produktidentitaets-Link-Follow-ups nicht als Hauptprodukt akzeptiert.
5. Falls die vorhandenen Treffer keine Identitaetsmatches enthalten, werden die Produktanker einzeln gesucht.
6. Auch diese Einzel-Lookups behalten nur Identitaetsmatches, nicht Treffer, die den Geraetenamen nur in Beschreibung/Kompatibilitaet nennen.
## Erwartetes Verhalten
```text
gebe mir links zu den produkten aus dem shop
```
nach einer Antwort mit:
```text
Testomat 2000 CAL
Testomat EVO TH
Testomat 808
```
soll nicht mehr Indikator-/Zubehoerlisten auf Basis einer kombinierten Query ausgeben, sondern nur Produktidentitaeten behalten oder getrennte Anker-Lookups versuchen:
```text
testomat 2000 cal
testomat evo th
testomat 808
```
## Regression Guardrails
Nicht betroffen sein sollen:
- direkte Shop-Suchen
- reine RAG-Fragen
- p84 LAB-CL-Kuerzel-Erhalt
- p85b Silikat/SIO2-Geräteanker
- Indikator-/Zubehoer-Follow-ups, wenn der Nutzer explizit Zubehoer/Indikator/Reagenz anfragt
- bestehende Shop-Matching-/Ranking-Logik
## Lokale Checks
Ausgefuehrt im Patch-Arbeitsverzeichnis:
```text
find src -name '*.php' -print0 | xargs -0 -n1 php -l
YAML parse OK
p86g identity smoke OK
```
Nicht lokal ausgefuehrt, weil `vendor/` im ZIP nicht enthalten ist:
```text
php bin/console mto:agent:config:validate
php bin/console mto:agent:regression:test
php bin/console mto:agent:config:audit-source --details
php bin/console mto:agent:config:audit-patterns --details
```