new struct md files
This commit is contained in:
team 1
42
patch_history/PATCH_README_EVENTSOURCE_SHOP_STATUS_FIX.md
Normal file
42
patch_history/PATCH_README_EVENTSOURCE_SHOP_STATUS_FIX.md
Normal file
@@ -0,0 +1,42 @@
|
||||
# RetrieX EventSource + Shop Status Fix
|
||||
|
||||
Patch-only package.
|
||||
|
||||
## Purpose
|
||||
|
||||
This patch extends the previous stream robustness fix and addresses two issues:
|
||||
|
||||
1. The chat now shows a visible reason when the Shopware shop/search API is unreachable or returns a system error.
|
||||
2. Reference-probe failures no longer block the actual primary Shopware search request.
|
||||
|
||||
## Files
|
||||
|
||||
- `public/assets/js/base.js`
|
||||
- Uses native `EventSource` instead of a manually parsed `fetch().body.getReader()` stream.
|
||||
- Starts a short-lived stream job with `POST /ask-jobs`, then opens `GET /ask-sse/{jobId}`.
|
||||
|
||||
- `src/Controller/AskSseController.php`
|
||||
- Adds `POST /ask-jobs`.
|
||||
- Adds `GET /ask-sse/{jobId}` for native EventSource streaming.
|
||||
- Keeps the old `POST /ask-sse` endpoint as backwards compatibility.
|
||||
- Stores short-lived stream jobs under `var/stream_jobs`.
|
||||
|
||||
- `src/Commerce/ShopSearchService.php`
|
||||
- Reference-probe Store API failures are logged but no longer stop the primary search.
|
||||
- The failure state is reset after a failed reference probe before the primary search starts.
|
||||
- Retry without commerce history is skipped only after a real primary Store API system failure.
|
||||
|
||||
- `src/Agent/AgentRunner.php`
|
||||
- If the primary shop search has a Store API system failure, the chat displays:
|
||||
`Shopsystem aktuell nicht erreichbar oder fehlerhaft. Grund: ...`
|
||||
- Repair search is skipped after primary Store API system failures.
|
||||
|
||||
## After installation
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
bin/console cache:clear
|
||||
```
|
||||
|
||||
If OPcache/PHP-FPM is active, reload PHP-FPM afterwards.
|
||||
37
patch_history/PATCH_README_EVENTSOURCE_STREAM_FIX.md
Normal file
37
patch_history/PATCH_README_EVENTSOURCE_STREAM_FIX.md
Normal file
@@ -0,0 +1,37 @@
|
||||
# RetrieX EventSource Stream Fix
|
||||
|
||||
Dieser Patch stabilisiert den Antwort-Stream bei Commerce-/Shop-Suchanfragen.
|
||||
|
||||
## Enthaltene Änderungen
|
||||
|
||||
- `public/assets/js/base.js`
|
||||
- Browser-Streaming von manuellem `fetch().body.getReader()` auf natives `EventSource` umgestellt.
|
||||
- Neuer Ablauf: `POST /ask-jobs` erstellt einen Stream-Job, anschließend `GET /ask-sse/{jobId}` per EventSource.
|
||||
- Abbruch-Button schließt nun EventSource sauber.
|
||||
|
||||
- `src/Controller/AskSseController.php`
|
||||
- Neuer Endpoint `POST /ask-jobs` zum Erstellen kurzlebiger Stream-Jobs.
|
||||
- Neuer Endpoint `GET /ask-sse/{jobId}` für natives SSE/EventSource.
|
||||
- Alter `POST /ask-sse` bleibt als Rückwärtskompatibilität erhalten.
|
||||
- Stream-Header erweitert um `no-transform`; Job-Dateien liegen kurzlebig unter `var/stream_jobs`.
|
||||
|
||||
- `src/Commerce/ShopSearchService.php`
|
||||
- Harte Shopware-Isolation bei Store-API-Systemfehlern.
|
||||
- Wenn ein Reference-Probe bereits einen Store-API-Systemfehler auslöst, wird keine weitere Shop-Suche in derselben Anfrage gestartet.
|
||||
- Retry ohne Commerce-History wird bei Store-API-Systemfehlern nicht mehr ausgeführt.
|
||||
|
||||
## Einspielen
|
||||
|
||||
ZIP im Projektroot entpacken, Dateien überschreiben, danach Symfony-Cache leeren.
|
||||
|
||||
Empfohlen:
|
||||
|
||||
```bash
|
||||
bin/console cache:clear
|
||||
```
|
||||
|
||||
Falls OPcache aktiv ist, PHP-FPM danach reloaden.
|
||||
|
||||
## Hinweis
|
||||
|
||||
Der Patch enthält bewusst nur geänderte Dateien und keine `var/cache`, Logs, Vendor-Dateien oder Wissensdaten.
|
||||
24
patch_history/PATCH_README_STREAM_SHOP_FIX.md
Normal file
24
patch_history/PATCH_README_STREAM_SHOP_FIX.md
Normal file
@@ -0,0 +1,24 @@
|
||||
# RetrieX Stream/Shop Fix Patch
|
||||
|
||||
This patch contains only the files changed for the Stream/Shop robustness fix.
|
||||
|
||||
Changed files:
|
||||
- public/assets/js/base.js
|
||||
- src/Agent/AgentRunner.php
|
||||
- src/Commerce/SearchRepairService.php
|
||||
- src/Commerce/ShopSearchService.php
|
||||
- src/Controller/AskSseController.php
|
||||
- src/Shopware/ShopwareCriteriaBuilder.php
|
||||
- src/Shopware/StoreApiClient.php
|
||||
- src/Shopware/StoreApiException.php
|
||||
|
||||
Not included:
|
||||
- var/cache
|
||||
- var/log
|
||||
- var/knowledge
|
||||
- full project/vendor/data files
|
||||
|
||||
Recommended after applying:
|
||||
- Clear Symfony cache
|
||||
- Restart PHP-FPM / web container if OPcache is active
|
||||
- Test the known 1.4.2 regression prompts and one shop-search prompt
|
||||
10
patch_history/README_ERROR_VISIBILITY_PATCH.md
Normal file
10
patch_history/README_ERROR_VISIBILITY_PATCH.md
Normal file
@@ -0,0 +1,10 @@
|
||||
# RetrieX error visibility patch
|
||||
|
||||
This patch makes Shopware Store API authentication/configuration failures visible in the chat stream and improves client-side display of SSE/job errors.
|
||||
|
||||
Changed files:
|
||||
- src/Shopware/StoreApiClient.php
|
||||
- src/Shopware/StoreApiException.php
|
||||
- src/Agent/AgentRunner.php
|
||||
- src/Controller/AskSseController.php
|
||||
- public/assets/js/base.js
|
||||
@@ -0,0 +1,17 @@
|
||||
# RetrieX Accessory Intent Role Precedence Fix
|
||||
|
||||
This patch fixes a side effect of the product-role and measurement-evidence guards.
|
||||
|
||||
Problem:
|
||||
- Queries such as "suche ph-indikatoren fuer messgeraete" contain both accessory wording (Indikatoren) and device wording (Messgeraete).
|
||||
- The previous role resolver prioritized main-device wording first, so the request was treated as a device suitability question.
|
||||
- This incorrectly triggered the pH measurement-capability guard and produced a no-match answer for pH-measuring Testomat devices.
|
||||
|
||||
Fix:
|
||||
- Explicit accessory/consumable intent now takes precedence over generic device wording.
|
||||
- Measurement-capability guards are skipped for accessory/consumable requests.
|
||||
- Shop-product measurement evidence lines are also skipped for accessory/consumable requests.
|
||||
- Additional indicator variants such as "indikatoren" and "ph-indikatoren" are added to the configurable accessory intent lists.
|
||||
|
||||
Scope:
|
||||
- No changes to SSE, jobs, retrieval, scoring, shop search, AgentRunner, or LLM timeouts.
|
||||
38
patch_history/RETRIEX_ACCESSORY_PRICE_FOLLOWUP_FIX_README.md
Normal file
38
patch_history/RETRIEX_ACCESSORY_PRICE_FOLLOWUP_FIX_README.md
Normal file
@@ -0,0 +1,38 @@
|
||||
# RetrieX accessory price follow-up precision fix
|
||||
|
||||
This patch hardens commerce follow-up handling for questions such as:
|
||||
|
||||
- "was kostet der indikator"
|
||||
- "was kostet indikatortyp 300"
|
||||
|
||||
Problem fixed:
|
||||
|
||||
- Technical RAG correctly resolves `0,02 °dH -> Testomat 808 -> Indikatortyp 300`.
|
||||
- The subsequent commerce follow-up generated the correct primary query (`indikatortyp 300 testomat 808`), but shop repair broadened the search again.
|
||||
- Repair queries could add model-only searches or nearby products, causing device prices or unrelated reagents to appear in the final answer.
|
||||
|
||||
Changes:
|
||||
|
||||
- Requested accessory codes are extracted with a configurable regex that also matches `indikatortyp 300`.
|
||||
- If a requested accessory/reagent code is present, shop repair is restricted to focused accessory-code queries.
|
||||
- Prompt-anchored models are preferred over proximity-only models for requested accessory-code repair.
|
||||
- Fallback accessory-code repair query templates are configurable.
|
||||
- Prompt grounding rules now explicitly forbid answering accessory price follow-ups with device prices or unrelated reagent prices.
|
||||
|
||||
No changes:
|
||||
|
||||
- No retrieval/scoring/vector logic changed.
|
||||
- No hard keyword list added to the retriever core.
|
||||
- No PromptBuilder text removed; only more precise shop grounding rules were added.
|
||||
|
||||
After applying:
|
||||
|
||||
```bash
|
||||
php bin/console cache:clear
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
|
||||
Expected behavior:
|
||||
|
||||
If the shop does not contain a clear product for `Indikatortyp 300`, RetrieX should say that the price is not available in the provided shop data and must not add the price of `Testomat 808`, `Testomat 2000`, or unrelated reagents.
|
||||
@@ -0,0 +1,25 @@
|
||||
# RetrieX Accessory Price Follow-up Hotfix
|
||||
|
||||
This patch fixes the Symfony parameter placeholder error introduced by the previous accessory price follow-up patch and keeps the repair logic generic.
|
||||
|
||||
## Fixes
|
||||
|
||||
- Replaces YAML templates using `%code%` with `{code}` / `{term}` placeholders so Symfony does not treat them as container parameters.
|
||||
- Keeps backward compatibility in PHP for legacy `%code%` / `%term%` templates if they are ever provided outside Symfony parameters.
|
||||
- Moves requested-accessory-code repair terms, proximity settings, model-reduction patterns, and model-exclusion terms into configuration.
|
||||
- Removes hard-coded product-family model patterns from `SearchRepairService`; model extraction now uses configurable generic patterns.
|
||||
- Keeps the focused accessory-code repair behavior: when the user asks for the price of a specific accessory/code, repair queries remain code-specific and do not broaden into device-only searches.
|
||||
|
||||
## Generic behavior
|
||||
|
||||
This patch does not add any fixed Testomat 808 / Testomat 2000 / Tritromat-specific branch. The model handling remains pattern/config driven so other product families and model variants can be handled through configuration.
|
||||
|
||||
## After applying
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
php bin/console cache:clear
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
32
patch_history/RETRIEX_AGENT_CONFIG_FIX_README.md
Normal file
32
patch_history/RETRIEX_AGENT_CONFIG_FIX_README.md
Normal file
@@ -0,0 +1,32 @@
|
||||
# RetrieX Agent Config Centralization Fix
|
||||
|
||||
This patch moves low-risk AgentRunner configuration values into `config/retriex/agent.yaml` while keeping the existing PHP fallback values in `AgentRunnerConfig`.
|
||||
|
||||
## Scope
|
||||
|
||||
Changed files:
|
||||
|
||||
- `config/retriex/agent.yaml`
|
||||
- `src/Config/AgentRunnerConfig.php`
|
||||
- `RETRIEX_AGENT_CONFIG_FIX_README.md`
|
||||
|
||||
## What was centralized
|
||||
|
||||
- user-visible progress/status messages
|
||||
- error messages
|
||||
- source labels
|
||||
- small HTML templates used by the agent stream/output
|
||||
- Shopware query optimizer prompt text and rules
|
||||
|
||||
## What was intentionally not changed
|
||||
|
||||
- `PromptBuilderConfig` prompt wording/rules
|
||||
- retrieval scoring logic
|
||||
- shop matching logic
|
||||
- vocabulary/intent/search-repair logic from the previous stable centralization step
|
||||
|
||||
## Safety notes
|
||||
|
||||
The YAML values mirror the existing PHP fallback values. `AgentRunnerConfig` still contains the old defaults as fallbacks, so missing or invalid YAML values should not break runtime behavior.
|
||||
|
||||
After applying the patch, clear the Symfony cache and re-run the known 1.4.2 regression prompts.
|
||||
@@ -0,0 +1,13 @@
|
||||
# RetrieX answer grounding strictness fix
|
||||
|
||||
Patch scope:
|
||||
- Strengthens prompt/grounding rules for technical product-selection answers.
|
||||
- Keeps Retrieval, Shop Search, AgentRunner, SSE, and scoring untouched.
|
||||
- Prevents confident suitability claims from weak shop hits or query wording.
|
||||
- Explicitly prevents treating p-Wert/m-Wert/minus m-Wert as pH/pH-Wert unless the same source says pH or pH-Wert.
|
||||
- Forces short, source-close answers when evidence is uncertain.
|
||||
|
||||
Expected effect for cases like:
|
||||
"suche einen testomat der ph messen kann"
|
||||
|
||||
RetrieX should not confidently turn p-Wert into pH-Wert, should not invent measurement principles/benefits/alternatives, and should say when technical suitability is not securely proven by the provided RAG/shop records.
|
||||
16
patch_history/RETRIEX_CONFIG_CENTRALIZATION_FIX_README.md
Normal file
16
patch_history/RETRIEX_CONFIG_CENTRALIZATION_FIX_README.md
Normal file
@@ -0,0 +1,16 @@
|
||||
# RetrieX configuration centralization fix
|
||||
|
||||
This patch centralizes additional low-risk word and pattern lists without changing their defaults.
|
||||
|
||||
## Changed areas
|
||||
|
||||
- `SearchRepairConfig` now reads repair vocabulary from `config/retriex/vocabulary.yaml` via `DomainVocabularyConfig`.
|
||||
- `CommerceIntentConfig`, `IntentLightConfig`, and `SalesIntentConfig` now read their lists from `config/retriex/intent.yaml`.
|
||||
- Existing PHP defaults remain in the classes as fallbacks.
|
||||
- Existing scalar thresholds and prompt wording are unchanged.
|
||||
|
||||
## Safety notes
|
||||
|
||||
The YAML values mirror the previous PHP defaults 1:1. The patch is meant to simplify maintenance and configuration, not to broaden or alter matching behavior.
|
||||
|
||||
After installing, clear the Symfony cache and run the known 1.4.2 regression prompts.
|
||||
35
patch_history/RETRIEX_CONFIG_FIX_README.md
Normal file
35
patch_history/RETRIEX_CONFIG_FIX_README.md
Normal file
@@ -0,0 +1,35 @@
|
||||
# RetrieX config hardening overlay
|
||||
|
||||
Scope:
|
||||
- Multi-tenant and configuration hardening only.
|
||||
- No retrieval logic rewrite.
|
||||
- No prompt logic rewrite.
|
||||
- No security/secrets cleanup in this round.
|
||||
|
||||
Install:
|
||||
1. Backup the current project.
|
||||
2. Extract this ZIP over the project root.
|
||||
3. Clear Symfony cache.
|
||||
4. Run:
|
||||
bin/console mto:agent:config:dump-effective --summary
|
||||
bin/console mto:agent:config:validate
|
||||
5. Run the existing 1.4.2 regression tests before deployment.
|
||||
|
||||
New config files:
|
||||
- config/retriex/runtime.yaml
|
||||
- config/retriex/index.yaml
|
||||
- config/retriex/vector.yaml
|
||||
- config/retriex/commerce.yaml
|
||||
- config/retriex/model.yaml
|
||||
- config/retriex/prompt.yaml
|
||||
- config/retriex/agent.yaml
|
||||
- config/retriex/retrieval.yaml
|
||||
|
||||
New commands:
|
||||
- mto:agent:config:dump-effective
|
||||
- mto:agent:config:validate
|
||||
|
||||
Notes:
|
||||
- Existing mto.* parameters remain for compatibility.
|
||||
- services.yaml imports config/retriex/*.yaml explicitly in stable order.
|
||||
- Retrieval constants are exposed as inventory and validation baseline, but are not dynamically changed in this round.
|
||||
44
patch_history/RETRIEX_CONFIG_SOURCE_AUDIT_PATCH_README.md
Normal file
44
patch_history/RETRIEX_CONFIG_SOURCE_AUDIT_PATCH_README.md
Normal file
@@ -0,0 +1,44 @@
|
||||
# RetrieX Config Source Audit Patch
|
||||
|
||||
This patch starts the YAML-only migration with a non-invasive diagnostic layer. It does not change retrieval, prompt generation, commerce parsing, shop matching, SSE behavior, or any answer logic.
|
||||
|
||||
## Added
|
||||
|
||||
- `App\Config\ConfigSourceAuditProvider`
|
||||
- `mto:agent:config:audit-source`
|
||||
|
||||
## Purpose
|
||||
|
||||
The audit makes remaining PHP defaults visible before we remove them. It scans:
|
||||
|
||||
- `config/retriex/*.yaml` parameter paths
|
||||
- `src/Config/*Config.php` constants
|
||||
- config helper calls with fallback arguments, for example `stringList('x', self::DEFAULT)` or `int('x', 3)`
|
||||
- constructor defaults that still act as PHP fallbacks
|
||||
|
||||
## Usage
|
||||
|
||||
```bash
|
||||
php bin/console mto:agent:config:audit-source
|
||||
php bin/console mto:agent:config:audit-source --details
|
||||
php bin/console mto:agent:config:audit-source --json
|
||||
```
|
||||
|
||||
## Interpretation
|
||||
|
||||
- `yaml_with_php_fallback`: the YAML path exists, but PHP still has a fallback argument. This is ready for a later conversion to required YAML access.
|
||||
- `php_fallback_if_yaml_missing_or_invalid`: PHP still supplies a default and no matching YAML path was found. This must be migrated before the fallback can be removed.
|
||||
- `php_only`: constants without an injected YAML config parameter. These must be classified as either technical guardrails or values that should move to YAML.
|
||||
|
||||
## Migration rule for the next patches
|
||||
|
||||
Do not remove PHP defaults yet. First migrate every still-needed value into YAML, then convert fallback helpers to required YAML accessors in small class groups.
|
||||
|
||||
## Validation performed for this patch
|
||||
|
||||
```bash
|
||||
php -l src/Config/ConfigSourceAuditProvider.php
|
||||
php -l src/Command/ConfigSourceAuditCommand.php
|
||||
```
|
||||
|
||||
Both files are syntactically valid. Full Symfony command execution was not performed in this ZIP workspace because `vendor/` is not included in the uploaded archive.
|
||||
@@ -0,0 +1,13 @@
|
||||
# RetrieX Device Component and Source UI Fix
|
||||
|
||||
This patch refines product-role handling for generic measuring-device requests and removes the visible duplicate Live-Shopdaten label from shop meta cards.
|
||||
|
||||
Changes:
|
||||
- Treat electrodes, probes, sensors, cables, adapters and similar components as accessories/components, not as complete measuring devices.
|
||||
- Expand main-device recognition for testers, pocket testers, handheld/lab measuring devices, monitoring devices, transmitters and controllers.
|
||||
- Suppress highlights for role-incompatible accessory/component records in main-device requests.
|
||||
- Add prompt rules to keep complete devices separate from components/accessories.
|
||||
- Rename shop meta card eyebrows from Live-Shopdaten to Shop-Suche / Shop-Ergebnisse so the data-basis chip is not visually duplicated.
|
||||
|
||||
Unchanged:
|
||||
- Retrieval, scoring, Shopware search, SSE/jobs and LLM settings.
|
||||
58
patch_history/RETRIEX_DIAGNOSTICS_REGRESSION_FIX_README.md
Normal file
58
patch_history/RETRIEX_DIAGNOSTICS_REGRESSION_FIX_README.md
Normal file
@@ -0,0 +1,58 @@
|
||||
# RetrieX Diagnostics & Regression Guard Fix
|
||||
|
||||
Patch-only package for the current `rag-inprogress.zip` baseline.
|
||||
|
||||
## Purpose
|
||||
|
||||
This patch adds safer operational checks around the already stabilized configuration centralization work.
|
||||
It does not change retrieval, prompt composition, shop search, intent scoring, or vocabulary semantics.
|
||||
|
||||
## Included changes
|
||||
|
||||
- Extends `RetriexEffectiveConfigProvider` so the effective config dump includes the newly centralized areas:
|
||||
- `vocabulary.yaml`
|
||||
- `intent.yaml`
|
||||
- `agent.yaml`
|
||||
- `prompt.yaml`
|
||||
- `query_enrichment.yaml`
|
||||
- `language.yaml`
|
||||
- effective shop/search-repair/commerce-query lists
|
||||
- Strengthens config validation for:
|
||||
- empty list items
|
||||
- duplicate list values
|
||||
- invalid regex patterns
|
||||
- protected stopword mistakes
|
||||
- protected decimal value handling for `0,02`
|
||||
- protected short model tokens `TH/TC/TP/TM/PH/RX`
|
||||
- Adds an offline regression guard command:
|
||||
|
||||
```bash
|
||||
php bin/console mto:agent:regression:test
|
||||
php bin/console mto:agent:regression:test --json
|
||||
```
|
||||
|
||||
- Enhances the summary view of the effective config dump:
|
||||
|
||||
```bash
|
||||
php bin/console mto:agent:config:dump-effective --summary
|
||||
```
|
||||
|
||||
## Included files
|
||||
|
||||
```text
|
||||
src/Config/RetriexEffectiveConfigProvider.php
|
||||
src/Command/ConfigDumpEffectiveCommand.php
|
||||
src/Command/RegressionBaselineCommand.php
|
||||
RETRIEX_DIAGNOSTICS_REGRESSION_FIX_README.md
|
||||
```
|
||||
|
||||
## After installing
|
||||
|
||||
Clear the Symfony cache and run:
|
||||
|
||||
```bash
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
|
||||
Then run the known manual 1.4.2 regression prompts again.
|
||||
@@ -0,0 +1,25 @@
|
||||
# RetrieX Diagnostics/Regression Hotfix
|
||||
|
||||
Patch-only hotfix for the diagnostics/regression tooling.
|
||||
|
||||
## Fixed
|
||||
|
||||
- `commerce_query.patterns.history_context` is now validated as a regex fragment, not as a full delimited regex.
|
||||
- `commerce_query.patterns.filter_search_tokens` is now validated as a normal token list, not as a list of regex patterns.
|
||||
- The regression check for the Shopware query optimizer prompt no longer expects a JSON instruction. The current stable prompt intentionally asks for a plain keyword search query, so the check now validates the actual output instruction.
|
||||
|
||||
## Not changed
|
||||
|
||||
- No retrieval logic changed.
|
||||
- No prompt wording changed.
|
||||
- No shop/search/runtime logic changed.
|
||||
- No YAML config changed.
|
||||
|
||||
## After applying
|
||||
|
||||
Clear Symfony cache, then run:
|
||||
|
||||
```bash
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
24
patch_history/RETRIEX_FOLLOWUP_PRECISION_FIX_README.md
Normal file
24
patch_history/RETRIEX_FOLLOWUP_PRECISION_FIX_README.md
Normal file
@@ -0,0 +1,24 @@
|
||||
# RetrieX Follow-up Precision Fix
|
||||
|
||||
This patch tightens direct numeric follow-up handling without changing retrieval, scoring, shop, vector or database logic.
|
||||
|
||||
## Why
|
||||
|
||||
The follow-up query `mit welchem indikator wird der wert gemessen` could be treated too weakly as a technical product/value question because only `indikator` was a strong keyword. As a result, the stricter technical follow-up prompt rules were not always applied.
|
||||
|
||||
## Changes
|
||||
|
||||
- Adds `gemessen` / `measured` as technical prompt keywords.
|
||||
- Adds explicit prompt rules to answer direct indicator/value follow-ups with the exact mapping first.
|
||||
- Tells the model not to expand into the full indicator table, measurement principle, applications or advisory notes unless explicitly requested.
|
||||
- Adds `gemessen` to the regression/effective-config keyword check.
|
||||
|
||||
## Expected behavior
|
||||
|
||||
Question: `mit welchem indikator wird der wert gemessen` after the 0,02 °dH / Testomat 808 answer.
|
||||
|
||||
Expected answer starts like:
|
||||
|
||||
`Der Wert 0,02 °dH wird beim Testomat 808 mit Indikatortyp 300 gemessen.`
|
||||
|
||||
The full indicator table should only be shown when the user asks for all indicators or detailed device information.
|
||||
@@ -0,0 +1,10 @@
|
||||
# RetrieX Generic Parameter Role Guard Fix
|
||||
|
||||
This patch keeps product-selection grounding generic while fixing parameter/accessory side effects.
|
||||
|
||||
Core idea:
|
||||
- Role guard stays generic: main-device requests must not be answered with accessories, and explicit accessory requests must not be turned into main-device requests.
|
||||
- Measurement evidence is context-sensitive: a parameter mention counts only when it is tied to measurement purpose such as measurement, measuring range, measurement parameter, determination, analysis, indicator/reagent for that parameter, sensor, or electrode.
|
||||
- Operating conditions, sample/environment limits, reagent-solution pH values, and pH values at a temperature are not sufficient evidence by themselves.
|
||||
|
||||
This patch does not touch retrieval, scoring, SSE, job lifecycle, or LLM timeout logic.
|
||||
@@ -0,0 +1,91 @@
|
||||
# RetrieX Patch 3: IntentLight + SalesIntent YAML-only
|
||||
|
||||
This patch continues the incremental YAML-source-of-truth migration.
|
||||
|
||||
## Scope
|
||||
|
||||
Only these intent areas are changed:
|
||||
|
||||
- `IntentLightConfig`
|
||||
- `SalesIntentConfig`
|
||||
- direct usages of their former PHP constants
|
||||
- the effective-config dump for these values
|
||||
- `config/retriex/intent.yaml`
|
||||
|
||||
No retrieval, prompt, shop, commerce-parser, SSE, or answer-generation logic is changed.
|
||||
|
||||
## What changed
|
||||
|
||||
### IntentLightConfig
|
||||
|
||||
Removed PHP defaults:
|
||||
|
||||
- `LIST_THRESHOLD`
|
||||
- `QUANTITY_WORDS`
|
||||
- `STRONG_PATTERNS`
|
||||
|
||||
Added required YAML-backed accessors:
|
||||
|
||||
- `getListThreshold()`
|
||||
- `getQuantityWords()`
|
||||
- `getStrongPatterns()`
|
||||
|
||||
The previous values now live in:
|
||||
|
||||
```yaml
|
||||
retriex.intent.light.config:
|
||||
list_threshold: 4
|
||||
quantity_words: [...]
|
||||
strong_patterns: [...]
|
||||
```
|
||||
|
||||
### SalesIntentConfig
|
||||
|
||||
Removed PHP defaults:
|
||||
|
||||
- `DOMINANCE_DELTA`
|
||||
- `MIN_SCORE_THRESHOLD`
|
||||
- `SALES_SIGNALS`
|
||||
- `COMPARISON_SIGNALS`
|
||||
- `OBJECTION_SIGNALS`
|
||||
- `IMPLEMENTATION_SIGNALS`
|
||||
- `ROI_SIGNALS`
|
||||
|
||||
Added required YAML-backed accessors:
|
||||
|
||||
- `getDominanceDelta()`
|
||||
- `getMinScoreThreshold()`
|
||||
- `getSalesSignals()`
|
||||
- `getComparisonSignals()`
|
||||
- `getObjectionSignals()`
|
||||
- `getImplementationSignals()`
|
||||
- `getRoiSignals()`
|
||||
|
||||
The previous values now live in:
|
||||
|
||||
```yaml
|
||||
retriex.intent.sales.config:
|
||||
dominance_delta: 2
|
||||
min_score_threshold: 3
|
||||
sales_signals: [...]
|
||||
comparison_signals: [...]
|
||||
objection_signals: [...]
|
||||
implementation_signals: [...]
|
||||
roi_signals: [...]
|
||||
```
|
||||
|
||||
## Validation performed
|
||||
|
||||
Static validation in the patch workspace:
|
||||
|
||||
```bash
|
||||
php -l src/Config/IntentLightConfig.php
|
||||
php -l src/Config/SalesIntentConfig.php
|
||||
php -l src/Intent/IntentLite.php
|
||||
php -l src/Intent/SalesIntentLite.php
|
||||
php -l src/Config/RetriexEffectiveConfigProvider.php
|
||||
```
|
||||
|
||||
YAML was parsed successfully with the new keys.
|
||||
|
||||
The full Symfony regression commands were not executed in the extracted ZIP workspace because `vendor/` is not part of the uploaded archive.
|
||||
77
patch_history/RETRIEX_LANGUAGE_CLEANUP_GUIDE.md
Normal file
77
patch_history/RETRIEX_LANGUAGE_CLEANUP_GUIDE.md
Normal file
@@ -0,0 +1,77 @@
|
||||
# RetrieX Language Cleanup Guide
|
||||
|
||||
Status: binding for RetrieX 1.5.3+ cleanup-profile work.
|
||||
|
||||
This guide defines where language, interaction, commerce and domain tokens belong. Its goal is to keep YAML maintenance simple and avoid duplicated keyword lists.
|
||||
|
||||
## 1. Central language cleanup lives in `language.yaml`
|
||||
|
||||
Use `config/retriex/language.yaml` for generic language noise only.
|
||||
|
||||
Allowed here:
|
||||
|
||||
- German function words: `der`, `die`, `das`, `ein`, `eine`, `mit`, `und`, `oder`, `ist`, `sind`, `kann`
|
||||
- conversation filler words: `bitte`, `mal`, `gerne`, `noch`, `dazu`, `also`
|
||||
- user instruction phrases: `ich suche`, `suche nach`, `zeige mir`, `gib mir`, `habt ihr`, `gibt es`
|
||||
- presentation/meta terms: `tabelle`, `liste`, `übersicht`, `tabellarisch`, `auflistung`
|
||||
- protected terms that must not be removed generically
|
||||
|
||||
Do not add product families, measurement parameters, intent terms or shop semantics here.
|
||||
|
||||
## 2. Use cleanup profiles instead of copying lists
|
||||
|
||||
Domain configs should reference a cleanup profile whenever they need generic language cleanup.
|
||||
|
||||
Current profiles:
|
||||
|
||||
- `commerce_query`: cleanup for shop/search query text
|
||||
- `rag_evidence`: cleanup for evidence/answer-consistency checks
|
||||
- `shop_context_fallback`: cleanup for history-based shop context fallback
|
||||
|
||||
Preferred pattern:
|
||||
|
||||
```yaml
|
||||
cleanup_profile: commerce_query
|
||||
```
|
||||
|
||||
Avoid adding the same generic words again to `commerce.yaml`, `agent.yaml`, `retrieval.yaml` or `intent.yaml`.
|
||||
|
||||
## 3. Keep domain semantics in domain configs
|
||||
|
||||
These belong outside `language.yaml`:
|
||||
|
||||
- commerce intent terms: `shop`, `produkt`, `artikel`, `preis`, `kosten`, `kaufen`, `bestellen`
|
||||
- measurement/domain terms: `wasserhärte`, `chlor`, `redox`, `leitfähigkeit`, `ph`, `rx`, `th`, `tc`
|
||||
- product-role terms: device, accessory, reagent, spare part and document-role vocabulary
|
||||
- routing and answer behavior rules
|
||||
- prompt-specific role or grounding rules
|
||||
|
||||
## 4. Protected terms are mandatory guardrails
|
||||
|
||||
Never remove these generically unless a later patch explicitly changes the guardrail:
|
||||
|
||||
- negations: `nicht`, `kein`, `keine`
|
||||
- core product/domain anchors: `testomat`, `indikator`, `indikatortyp`
|
||||
- short model/parameter tokens: `ph`, `rx`, `th`, `tc`
|
||||
- important numeric anchors: `0,02`
|
||||
|
||||
When in doubt, add terms to `protected_terms` rather than removing them through a broad stopword group.
|
||||
|
||||
## 5. Change process
|
||||
|
||||
Before adding a new token list:
|
||||
|
||||
1. Ask whether it is generic language noise.
|
||||
2. If yes, add it to `language.yaml` under the correct group/profile.
|
||||
3. If no, keep it in the owning domain YAML.
|
||||
4. Do not introduce PHP-only token lists.
|
||||
5. Run the required checks.
|
||||
|
||||
Required checks:
|
||||
|
||||
```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
|
||||
```
|
||||
@@ -0,0 +1,37 @@
|
||||
# RetrieX Measurement Evidence Guard Fix
|
||||
|
||||
This patch tightens technical product-selection answers for measurement-parameter questions.
|
||||
|
||||
## Problem
|
||||
|
||||
The LLM could still merge similar water-treatment terms, for example treating `p-Wert` as `pH-Wert`, and then generate unsupported measurement ranges, application areas or recommendations.
|
||||
|
||||
## Change
|
||||
|
||||
The patch adds a generated `MEASUREMENT PARAMETER EVIDENCE CHECK` block to the final prompt when the user asks for configured measurement parameters such as pH, Redox/ORP or free chlorine.
|
||||
|
||||
For each relevant question, the PromptBuilder now:
|
||||
|
||||
- detects the requested measurement parameter from configurable YAML terms,
|
||||
- scans RAG/URL context and each shop product record for explicit positive evidence,
|
||||
- marks every shop record with a same-record evidence line,
|
||||
- tells the model not to recommend a product when no explicit evidence exists,
|
||||
- explicitly treats similar but non-equivalent terms such as `p-Wert`, `m-Wert`, `minus m-Wert`, `mmol/l` and alkalinity as insufficient for pH suitability.
|
||||
|
||||
## Files changed
|
||||
|
||||
- `src/Agent/PromptBuilder.php`
|
||||
- `src/Config/PromptBuilderConfig.php`
|
||||
- `config/retriex/prompt.yaml`
|
||||
|
||||
## Intended behavior
|
||||
|
||||
For `suche einen testomat der ph messen kann`, if the provided RAG/shop records only contain `p-Wert` or related alkalinity values but no explicit `pH` / `pH-Wert` evidence in the same record, the answer should start with uncertainty, for example:
|
||||
|
||||
`Ich finde in den bereitgestellten Quellen keinen sicher belegten Testomat fuer pH-Messung.`
|
||||
|
||||
It may still list shop hits as commercial/search hits, but not as verified pH-suitable devices.
|
||||
|
||||
## Scope
|
||||
|
||||
This patch does not touch retrieval, scoring, shop search, AgentRunner, SSE or LLM settings.
|
||||
@@ -0,0 +1,14 @@
|
||||
# RetrieX Negative Wording and Source Chip Fix
|
||||
|
||||
This patch is a narrow finishing pass for answer wording and the production status UI.
|
||||
|
||||
## Changes
|
||||
|
||||
- Adds stricter prompt/config rules for scoped negative wording.
|
||||
- Discourages absolute statements such as "ausschließlich", "keines", "nicht geeignet" or "gibt es nicht" unless the sources explicitly support the full scope.
|
||||
- Requires neutral wording for options outside the provided sources instead of external recommendations.
|
||||
- Deduplicates production UI data-basis chips, especially repeated "Live-Shopdaten" labels.
|
||||
|
||||
## Unchanged
|
||||
|
||||
The patch does not change retrieval, scoring, shop querying, SSE/job handling, Ollama settings, or prompt/product role detection logic.
|
||||
@@ -0,0 +1,35 @@
|
||||
# RetrieX No-LLM Fallback & Eskalationslogik Fix
|
||||
|
||||
Patch-only ZIP auf Basis der aktuell hochgeladenen `rag-inprogress.zip`.
|
||||
|
||||
## Ziel
|
||||
|
||||
RetrieX soll auch ohne LLM bzw. bei fehlender LLM-Antwort keine harte oder falsche Negativaussage ausgeben, sondern den Datenzustand transparent und deterministisch darstellen.
|
||||
|
||||
## Enthaltene Änderungen
|
||||
|
||||
- deterministische No-LLM-Fallbackantworten in `AgentRunner`
|
||||
- Fallback greift nur, wenn das LLM keine Antworttokens liefert oder vor dem ersten Antworttoken ausfällt
|
||||
- keine Interpretation technischer Eignung aus Shopdaten im No-LLM-Modus
|
||||
- Shop-only Treffer werden als Shopdaten gekennzeichnet: technische Eignung bitte prüfen
|
||||
- keine harte Negativaussage bei leeren Shop-/RAG-Treffern
|
||||
- getrennte Meldungen für:
|
||||
- Shop-Treffer ohne RAG-Fachwissen
|
||||
- Shop-Treffer mit RAG-/Kontexttreffern
|
||||
- keine Shop-Treffer
|
||||
- Shop nicht erreichbar
|
||||
- RAG-Treffer vorhanden, aber keine No-LLM-Synthese
|
||||
- keine belastbaren Daten
|
||||
- No-concrete-Shop-Query-Meldung entschärft und in die History geschrieben
|
||||
- Prompt-Regeln für Unsicherheits-/Fallbackstufen bleiben zusätzlich für den LLM-Modus enthalten
|
||||
|
||||
## Sicherheitsentscheidung
|
||||
|
||||
Die No-LLM-Schicht synthetisiert bewusst keine fachlichen Aussagen aus RAG-Chunks und leitet keine technische Eignung aus Shopdaten ab. Sie listet nur belegte Shop-Metadaten und den sicheren nächsten Schritt.
|
||||
|
||||
## Validierung
|
||||
|
||||
- `php -l` für alle geänderten PHP-Dateien: OK
|
||||
- YAML-Parsing für `config/retriex/prompt.yaml` und `config/retriex/agent.yaml`: OK
|
||||
|
||||
Die Symfony-Regression kann in diesem Archiv nicht ausgeführt werden, weil `vendor/autoload.php` nicht im ZIP enthalten ist.
|
||||
@@ -0,0 +1,78 @@
|
||||
# RetrieX Numeric Extreme Retrieval Fix
|
||||
|
||||
## Purpose
|
||||
|
||||
This patch sharpens retrieval for direct numeric extreme questions such as the lowest hardness threshold.
|
||||
|
||||
The concrete regression was:
|
||||
|
||||
- User asks for the lowest water-hardness threshold monitored by a Testomat.
|
||||
- The correct answer is `0,02 °dH` / `Testomat 808`.
|
||||
- Retrieval still allowed neighbouring runner-up product context such as `Testomat 2000` / `0,05 °dH` into the prompt.
|
||||
|
||||
That made the model add unnecessary comparison details although the user asked only for the lowest value.
|
||||
|
||||
## Change
|
||||
|
||||
`src/Knowledge/Retrieval/NdjsonHybridRetriever.php` now adds a conservative numeric-extreme document selection step between focused-product selection and normal dominant/spread selection.
|
||||
|
||||
The new mode:
|
||||
|
||||
- detects minimum/maximum-style technical measurement questions,
|
||||
- extracts dH measurement values from the top retrieval window,
|
||||
- identifies the document containing the actual extreme value,
|
||||
- selects chunks from that document only,
|
||||
- avoids filling the remaining prompt slots with runner-up product chunks.
|
||||
|
||||
New debug selection mode:
|
||||
|
||||
```text
|
||||
sales_numeric_extreme_document
|
||||
```
|
||||
|
||||
## Safety
|
||||
|
||||
The fix is intentionally narrow:
|
||||
|
||||
- no PromptBuilder changes,
|
||||
- no prompt wording changes,
|
||||
- no Shopware logic changes,
|
||||
- no vector-service changes,
|
||||
- no scoring config changes,
|
||||
- no vocabulary changes.
|
||||
|
||||
It only affects technical numeric extreme questions containing measurement/context signals such as `Grenzwert`, `Messbereich`, `Wasserhärte`, `Resthärte`, `dH`, `threshold`, or `range`.
|
||||
|
||||
## Expected regression result
|
||||
|
||||
Question:
|
||||
|
||||
```text
|
||||
Was ist der niedrigste Grenzwert für die Wasserhärte, welcher mit einem Testomaten überwacht werden kann?
|
||||
```
|
||||
|
||||
Expected answer should stay focused on:
|
||||
|
||||
```text
|
||||
0,02 °dH / Testomat 808
|
||||
```
|
||||
|
||||
It should not add the runner-up product/value such as:
|
||||
|
||||
```text
|
||||
Testomat 2000 / 0,05 °dH
|
||||
```
|
||||
|
||||
unless the user explicitly asks for comparison, alternatives, or all available values.
|
||||
|
||||
## After applying
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
php bin/console cache:clear
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
|
||||
Then manually retest the known 1.4.2 baseline and the lowest-threshold prompt above.
|
||||
@@ -0,0 +1,18 @@
|
||||
# RetrieX p29 - Shop Result Dedupe Hardening
|
||||
|
||||
Purpose:
|
||||
- Prevent repeated shop product records from being passed into prompts or rendered in fallback output.
|
||||
- Treat product number as the strongest deduplication key, so SKU variants with slightly different display names do not appear repeatedly.
|
||||
- Keep the existing shop ranking and technical suitability logic unchanged.
|
||||
|
||||
Changed files:
|
||||
- `src/Commerce/ShopSearchService.php`
|
||||
- `src/Agent/PromptBuilder.php`
|
||||
|
||||
Validation:
|
||||
```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
|
||||
```
|
||||
@@ -0,0 +1,42 @@
|
||||
# RetrieX Patch 10.1 - Audit-Restbereinigung
|
||||
|
||||
## Ziel
|
||||
|
||||
Dieser Patch bereinigt die letzten rein technischen Audit-Reste nach der YAML-only-Migration der grossen Config-Bloecke.
|
||||
|
||||
## Enthalten
|
||||
|
||||
- `CommerceQueryParserConfig`: Die Normalisierungslisten `normalization.search` und `normalization.replace` verwenden jetzt eine eigene Methode `whitespacePreservingStringList()` statt `stringList(..., true)`. Dadurch werden sie nicht mehr als PHP-Fallback-Accessor fehlinterpretiert. Die Whitespace-erhaltende Wirkung bleibt unveraendert.
|
||||
- `AgentRunnerConfig`: Alte, nicht mehr verwendete PHP-Fallback-Helfer wurden entfernt:
|
||||
- `getInt()`
|
||||
- `getBool()`
|
||||
- `getString()`
|
||||
- `getStringList()`
|
||||
- `value()`
|
||||
|
||||
## Nicht enthalten
|
||||
|
||||
Keine Aenderungen an:
|
||||
|
||||
- Retrieval-Algorithmus
|
||||
- Prompt-Regeln
|
||||
- Shop-Matching
|
||||
- Commerce-Intent
|
||||
- AgentRunner-Laufzeitlogik
|
||||
- YAML-Werten
|
||||
- SSE / Frontend
|
||||
|
||||
## Nach dem Einspielen pruefen
|
||||
|
||||
```bash
|
||||
php bin/console cache:clear
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:config:audit-source --details
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
|
||||
## Erwartung
|
||||
|
||||
- Keine Regressionen.
|
||||
- `CommerceQueryParserConfig` sollte nicht mehr wegen `normalization.search` / `normalization.replace` als `yaml_with_php_fallback` erscheinen.
|
||||
- `AgentRunnerConfig` enthaelt keine ungenutzten PHP-Fallback-Helfer mehr.
|
||||
@@ -0,0 +1,60 @@
|
||||
# RetrieX Patch 10 - NdjsonHybridRetrieverConfig YAML-only
|
||||
|
||||
## Ziel
|
||||
|
||||
Dieser Patch entfernt die verbliebenen PHP-Defaults aus `NdjsonHybridRetrieverConfig`.
|
||||
|
||||
Die Retrieval-Werte liegen bereits in `config/retriex/retrieval.yaml`. PHP liest diese Werte jetzt als Pflichtkonfiguration und wirft bei fehlenden oder ungültigen Werten klare Exceptions, statt still auf PHP-Konstanten zurückzufallen.
|
||||
|
||||
## Geändert
|
||||
|
||||
- `src/Config/NdjsonHybridRetrieverConfig.php`
|
||||
|
||||
## YAML-only
|
||||
|
||||
Umgestellt wurden:
|
||||
|
||||
- Retrieval-Limits und Thresholds
|
||||
- RRF-/Keyword-Gewichte
|
||||
- Dominant-/Focused-Document-Werte
|
||||
- Retrieval-Tokenlisten:
|
||||
- `generic_product_tokens`
|
||||
- `important_short_model_tokens`
|
||||
- `family_descriptor_tokens`
|
||||
- `looks_like_reagent_tokens`
|
||||
- `looks_like_safety_docs`
|
||||
- `looks_like_reagent_words`
|
||||
- `looks_like_document_words`
|
||||
- `looks_like_safety_words`
|
||||
- `looks_like_device_words`
|
||||
|
||||
## Nicht geändert
|
||||
|
||||
- keine Änderung an `retrieval.yaml`
|
||||
- keine Änderung an Retrieval-Algorithmus oder Scoring-Logik
|
||||
- keine Änderung an PromptBuilder
|
||||
- keine Änderung an Commerce/Shop
|
||||
- keine Änderung an AgentRunner
|
||||
- keine Änderung an SSE/Frontend
|
||||
|
||||
## Wichtig
|
||||
|
||||
Die YAML-Werte waren bereits vorhanden. Der Patch entfernt nur die PHP-Fallback-Ebene.
|
||||
|
||||
## Nach dem Einspielen prüfen
|
||||
|
||||
```bash
|
||||
php bin/console cache:clear
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:config:audit-source --details
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
|
||||
Erwartung:
|
||||
|
||||
- `NdjsonHybridRetrieverConfig` taucht nicht mehr als `yaml_with_php_fallback` auf.
|
||||
- Die Regression bleibt grün, insbesondere:
|
||||
- `important_short_model_token_th/tc/tp/tm/ph/rx`
|
||||
- `retrieval_reagent_word_indikator`
|
||||
- `retrieval_device_word_geraet`
|
||||
- Testomat-808-/Indikator-300-Baseline
|
||||
@@ -0,0 +1,43 @@
|
||||
# RetrieX Patch 11.0a - Strict YAML Default Cleanup
|
||||
|
||||
This patch removes the remaining model-generation constructor defaults and cleans up two CommerceQueryParser audit false positives.
|
||||
|
||||
## Scope
|
||||
|
||||
Changed files:
|
||||
|
||||
- `src/Config/ModelGenerationDefaultsConfig.php`
|
||||
- `src/Config/CommerceQueryParserConfig.php`
|
||||
|
||||
## What changed
|
||||
|
||||
### ModelGenerationDefaultsConfig
|
||||
|
||||
The constructor no longer contains PHP fallback values for model defaults. All values must now come from the existing Symfony service parameters, which are backed by `config/retriex/model.yaml`:
|
||||
|
||||
- `retriex.model.default_name`
|
||||
- `retriex.model.default_stream`
|
||||
- `retriex.model.default_temperature`
|
||||
- `retriex.model.default_top_k`
|
||||
- `retriex.model.default_top_p`
|
||||
- `retriex.model.default_repeat_penalty`
|
||||
- `retriex.model.default_num_ctx`
|
||||
- `retriex.model.default_retrieval_max_chunks`
|
||||
- `retriex.model.default_retrieval_vector_top_k`
|
||||
|
||||
### CommerceQueryParserConfig
|
||||
|
||||
The whitespace-preserving normalization lists now use a dedicated helper instead of passing `true` as a second argument to `stringList()`. This keeps behavior unchanged, but prevents the source audit from interpreting the boolean argument as a PHP fallback.
|
||||
|
||||
## Intentional non-changes
|
||||
|
||||
No retrieval, prompt, shop, agent, SSE, or runtime behavior was changed.
|
||||
|
||||
## Recommended validation
|
||||
|
||||
```bash
|
||||
php bin/console cache:clear
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:config:audit-source --details
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
60
patch_history/RETRIEX_PATCH_12_DEVELOPER_POLICIES_README.md
Normal file
60
patch_history/RETRIEX_PATCH_12_DEVELOPER_POLICIES_README.md
Normal file
@@ -0,0 +1,60 @@
|
||||
# RetrieX Patch 12 - Developer Policies after YAML-only Migration
|
||||
|
||||
This patch does not continue the YAML-only migration and does not enable strict validation.
|
||||
|
||||
Patch 1 through 11.0a are treated as the completed YAML-only migration baseline. Patch 12 documents the developer rules that must be followed from now on to prevent regressions and new PHP-only configuration drift.
|
||||
|
||||
## Scope
|
||||
|
||||
Changed files:
|
||||
|
||||
- `DEVELOPER_POLICIES.md`
|
||||
- `README.md`
|
||||
- `COMMAND_REF.md`
|
||||
|
||||
## What changed
|
||||
|
||||
### Developer policies
|
||||
|
||||
Added a binding policy document with rules for:
|
||||
|
||||
- YAML as source of truth
|
||||
- no new PHP-only defaults
|
||||
- no hardcoded semantic lists in core code
|
||||
- fallback restrictions
|
||||
- mandatory pre-merge checks
|
||||
- protected regression baseline
|
||||
- deferred strict validation
|
||||
- PR checklist
|
||||
|
||||
### README
|
||||
|
||||
The README now points developers to `DEVELOPER_POLICIES.md` and lists the config-governance commands together with the other important commands.
|
||||
|
||||
The previously open final bash code block in the README was also closed while appending the policy section.
|
||||
|
||||
### Command reference
|
||||
|
||||
`COMMAND_REF.md` now includes the existing config/governance commands:
|
||||
|
||||
- `mto:agent:config:validate`
|
||||
- `mto:agent:config:audit-source`
|
||||
- `mto:agent:config:dump-effective`
|
||||
- `mto:agent:regression:test`
|
||||
|
||||
## Intentional non-changes
|
||||
|
||||
No PHP runtime behavior was changed.
|
||||
No retrieval, prompt, shop, agent, SSE, audit or validation logic was changed.
|
||||
Strict YAML validation remains deferred and disabled.
|
||||
|
||||
## Recommended validation
|
||||
|
||||
```bash
|
||||
php bin/console cache:clear
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:config:audit-source --details
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
|
||||
In this ZIP work environment, `vendor/` is not included, so Symfony console commands may need to be run in the real project checkout after dependencies are installed.
|
||||
@@ -0,0 +1,99 @@
|
||||
# RetrieX Patch 13 – Agent/Commerce Pattern Externalization
|
||||
|
||||
## Ziel
|
||||
|
||||
Patch 13 setzt die Developer Policies aus v1.5.1 weiter um und entfernt weitere fachliche Patterns,
|
||||
Signal-Listen und Produkt-/Fokuslisten aus PHP-Core-Klassen.
|
||||
|
||||
Die Änderung ist bewusst klein gehalten und soll das Laufzeitverhalten nicht fachlich verändern:
|
||||
Die bisherigen Werte wurden 1:1 nach YAML verschoben und die PHP-Klassen lesen sie nur noch aus der Konfiguration.
|
||||
|
||||
## Geänderte Bereiche
|
||||
|
||||
### AgentRunner
|
||||
|
||||
Dateien:
|
||||
|
||||
- `src/Agent/AgentRunner.php`
|
||||
- `src/Config/AgentRunnerConfig.php`
|
||||
- `config/retriex/agent.yaml`
|
||||
|
||||
Externalisiert wurden:
|
||||
|
||||
- starke Follow-up-Referenzpatterns, z. B. „der Wert“, „womit“, „welcher Indikator“
|
||||
- explizite Commerce-Follow-up-Signale, z. B. „shop“, „preis“, „kostet“, „sku“
|
||||
- History-/Follow-up-Strukturpatterns für `Question:`-Parsing
|
||||
- Referenzanker-Patterns für Testomat-Modellanker und Härtewerte in °dH
|
||||
|
||||
### CommerceQueryParser
|
||||
|
||||
Dateien:
|
||||
|
||||
- `src/Commerce/CommerceQueryParser.php`
|
||||
- `src/Config/CommerceQueryParserConfig.php`
|
||||
- `config/retriex/commerce.yaml`
|
||||
|
||||
Externalisiert wurden:
|
||||
|
||||
- Search-Control-Tokens wie `shop`, `store`, `produkt`, `artikel`, `kaufen`, `bestellen`, `online`
|
||||
|
||||
### CommerceReferenceResolver
|
||||
|
||||
Dateien:
|
||||
|
||||
- `src/Commerce/CommerceReferenceResolver.php`
|
||||
- `src/Config/CommerceReferenceResolverConfig.php`
|
||||
- `config/services.yaml`
|
||||
- `config/retriex/commerce.yaml`
|
||||
|
||||
Externalisiert wurden:
|
||||
|
||||
- Conversation-Produktpatterns für Testomat-Modelle
|
||||
- Fokus-Term-Patterns für Zubehör-/Reagenz-/Ersatzteilbegriffe
|
||||
|
||||
## Bewusst nicht geändert
|
||||
|
||||
Nicht alle technischen Normalisierungsregexe im `AgentRunner` wurden in diesem Patch angefasst.
|
||||
Bewusst unverändert bleiben zunächst rein technische Parser-/Sanitizer-Patterns wie Whitespace-Normalisierung,
|
||||
Tokenisierung oder HTML-/Output-Formatierung.
|
||||
|
||||
Diese können später in einem separaten, kleineren Follow-up-Patch geprüft werden, falls der Audit weiterhin zu viel
|
||||
Pattern-Logik im Core meldet.
|
||||
|
||||
## Prüfungen
|
||||
|
||||
In der Patch-Arbeitsumgebung wurde geprüft:
|
||||
|
||||
```bash
|
||||
php -l src/Config/AgentRunnerConfig.php
|
||||
php -l src/Agent/AgentRunner.php
|
||||
php -l src/Config/CommerceQueryParserConfig.php
|
||||
php -l src/Commerce/CommerceQueryParser.php
|
||||
php -l src/Config/CommerceReferenceResolverConfig.php
|
||||
php -l src/Commerce/CommerceReferenceResolver.php
|
||||
```
|
||||
|
||||
Alle geprüften PHP-Dateien waren syntaktisch valide.
|
||||
|
||||
Zusätzlich wurden die geänderten YAML-Dateien parserseitig geprüft:
|
||||
|
||||
- `config/retriex/agent.yaml`
|
||||
- `config/retriex/commerce.yaml`
|
||||
- `config/services.yaml`
|
||||
|
||||
## Nach dem Einspielen lokal ausführen
|
||||
|
||||
```bash
|
||||
bin/console mto:agent:config:validate
|
||||
bin/console mto:agent:regression:test
|
||||
bin/console mto:agent:config:audit-source --details
|
||||
```
|
||||
|
||||
Falls die Umgebung `vendor/` nicht enthält, vorher wie üblich Abhängigkeiten installieren.
|
||||
|
||||
## Erwartetes Ergebnis
|
||||
|
||||
- Keine fachliche Verhaltensänderung.
|
||||
- Keine neue Strict-Validation.
|
||||
- Weniger fachliche Pattern-/Keyword-Logik im PHP-Core.
|
||||
- Weitere Annäherung an die Developer Policies aus v1.5.1.
|
||||
@@ -0,0 +1,50 @@
|
||||
# RetrieX Patch 14 - Remaining Runtime Core Pattern Externalization
|
||||
|
||||
## Goal
|
||||
|
||||
Patch 14 continues the YAML-only governance work after v1.5.1 and p13b. It externalizes remaining runtime-relevant domain patterns from PHP core code into YAML without changing scoring semantics or enabling strict validation.
|
||||
|
||||
## Scope
|
||||
|
||||
Changed runtime areas:
|
||||
|
||||
- `src/Knowledge/Retrieval/NdjsonHybridRetriever.php`
|
||||
- Catalog-list shortcut patterns moved to `config/retriex/retrieval.yaml`.
|
||||
- Exact-document token variant prefixes moved to YAML.
|
||||
- Indicator/detail follow-up tokens, phrases and table-detection patterns moved to YAML.
|
||||
- Exact detail and generic exact-selection token lists moved to YAML.
|
||||
|
||||
- `src/Agent/PromptBuilder.php`
|
||||
- Direct main-device request patterns moved to `config/retriex/prompt.yaml`.
|
||||
|
||||
- `src/Intent/CommerceIntentLite.php`
|
||||
- Non-product commerce signals moved to `config/retriex/intent.yaml`.
|
||||
- Technical factual knowledge guard label and patterns moved to YAML.
|
||||
|
||||
## Intentionally not changed
|
||||
|
||||
- No strict YAML validation is enabled.
|
||||
- No governance/regression hardening terms from `RetriexEffectiveConfigProvider` are moved in this patch. That should remain a separate follow-up patch.
|
||||
- No scoring weights, top-k limits, retrieval thresholds or prompt rules are changed.
|
||||
- Technical regex such as number detection, whitespace handling, job id validation and markdown parsing is intentionally left in PHP.
|
||||
|
||||
## Required checks after applying
|
||||
|
||||
Run locally in the full project with dependencies installed:
|
||||
|
||||
```bash
|
||||
bin/console mto:agent:config:validate
|
||||
bin/console mto:agent:regression:test
|
||||
bin/console mto:agent:config:audit-source --details
|
||||
```
|
||||
|
||||
Recommended smoke checks:
|
||||
|
||||
- Lowest hardness threshold question still resolves to `0,02 °dH / Testomat 808`.
|
||||
- Follow-up indicator question still resolves to `Indikatortyp 300`.
|
||||
- Accessory price follow-up still resolves to the indicator product, not the device.
|
||||
- Product-selection shop fallback still works.
|
||||
|
||||
## Next step
|
||||
|
||||
The next isolated patch should externalize governance/regression guardrails from `RetriexEffectiveConfigProvider` into YAML, likely as p15.
|
||||
@@ -0,0 +1,27 @@
|
||||
# RetrieX Patch 15b - Governance Validation Warning Fix
|
||||
|
||||
## Ziel
|
||||
|
||||
Patch 15b behebt einen Folgefehler aus Patch 15: Die Regression-Baseline konnte durch eine falsch-positive Config-Validation-Warnung scheitern.
|
||||
|
||||
## Ursache
|
||||
|
||||
`retriex.retrieval.inventory` ist ein backwards-kompatibler Diagnoseparameter. Einige Retrieval-Listen sind inzwischen vocabulary-backed und werden ueber die aktive Config-Fassade aufgeloest. Der direkte Vergleich des rohen Inventory-Parameters mit der aktiven Retriever-Config kann deshalb bei vocabulary-backed Keys abweichen, ohne dass eine echte Fehlkonfiguration vorliegt.
|
||||
|
||||
Zusätzlich wird die Governance-Validation nicht mehr mit der generischen String-List-Map-Validierung geprueft, weil `governance.yaml` absichtlich auch strukturierte Guardrail-Gruppen enthaelt. Die eigentliche Validierung erfolgt ueber die typisierten Getter von `GovernanceConfig`.
|
||||
|
||||
## Geaendert
|
||||
|
||||
- `src/Config/RetriexEffectiveConfigProvider.php`
|
||||
- ueberspringt den Inventory-Direktvergleich fuer vocabulary-backed Retrieval-Keys
|
||||
- validiert Governance-Konfiguration ueber `GovernanceConfig` statt generischer String-List-Map-Pruefung
|
||||
|
||||
## Erwartete Checks
|
||||
|
||||
```bash
|
||||
bin/console mto:agent:config:validate
|
||||
bin/console mto:agent:regression:test
|
||||
bin/console mto:agent:config:audit-source --details
|
||||
```
|
||||
|
||||
Alle drei Checks muessen gruen sein.
|
||||
@@ -0,0 +1,29 @@
|
||||
# RetrieX Patch 15c - Governance Shape and Inventory Fix
|
||||
|
||||
## Ziel
|
||||
|
||||
Patch 15c behebt zwei Restprobleme aus Patch 15/15b.
|
||||
|
||||
## Ursache
|
||||
|
||||
1. `governance.regression_baseline.protected_retrieval_device_word_groups` war temporaer als Liste strukturierter Objekte modelliert. Bestehende generische Config-Validierungen erwarten bei Listen jedoch skalare Werte.
|
||||
2. Der Retrieval-Inventory-Vergleich konnte fuer vocabulary-backed Retrieval-Keys weiterhin eine falsch-positive Warnung ausgeben, wenn der rohe Inventory-Parameter von der aktiven Retriever-Config abweicht.
|
||||
|
||||
## Geaendert
|
||||
|
||||
- `config/retriex/governance.yaml`
|
||||
- `protected_retrieval_device_word_groups` ist jetzt eine Map von Gruppenname zu Stringliste.
|
||||
- `src/Config/GovernanceConfig.php`
|
||||
- liest die neue Map-Struktur und toleriert die temporaere p15/p15b-Listenstruktur defensiv.
|
||||
- `src/Config/RetriexEffectiveConfigProvider.php`
|
||||
- ueberspringt den Inventory-Direktvergleich fuer alle bekannten vocabulary-backed Retrieval-Keys explizit.
|
||||
|
||||
## Erwartete Checks
|
||||
|
||||
```bash
|
||||
bin/console mto:agent:config:validate
|
||||
bin/console mto:agent:regression:test
|
||||
bin/console mto:agent:config:audit-source --details
|
||||
```
|
||||
|
||||
Alle drei Checks muessen gruen sein.
|
||||
@@ -0,0 +1,44 @@
|
||||
# RetrieX Patch 15 - Governance Guardrail Config Externalization
|
||||
|
||||
## Ziel
|
||||
|
||||
Patch 15 verschiebt die verbliebenen fachlichen Regression-/Governance-Guardrail-Werte aus `RetriexEffectiveConfigProvider.php` in YAML. Damit bleiben die Checks aus `mto:agent:config:validate` und `mto:agent:regression:test` erhalten, ohne neue PHP-only Defaults oder harte fachliche Listen im Core zu pflegen.
|
||||
|
||||
## Geaenderte Bereiche
|
||||
|
||||
- Neue Datei: `config/retriex/governance.yaml`
|
||||
- enthaelt Regression-Baseline-Guardrails
|
||||
- enthaelt Vocabulary-Guardrails
|
||||
- enthaelt Language-/Stopword-Guardrails
|
||||
- Neue Config-Fassade: `src/Config/GovernanceConfig.php`
|
||||
- `src/Config/RetriexEffectiveConfigProvider.php`
|
||||
- nutzt `GovernanceConfig` fuer Regression-Baseline-Checks
|
||||
- nutzt `GovernanceConfig` fuer Commerce-Query-Messwertvalidierung
|
||||
- nutzt `GovernanceConfig` fuer Vocabulary-/Stopword-Guardrails
|
||||
- dump-effective enthaelt nun den Abschnitt `governance`
|
||||
- `config/services.yaml`
|
||||
- importiert `config/retriex/governance.yaml`
|
||||
- registriert `GovernanceConfig`
|
||||
- `src/Config/ConfigSourceAuditProvider.php`
|
||||
- kennt `GovernanceConfig` als YAML-backed Config-Klasse
|
||||
|
||||
## Bewusst nicht enthalten
|
||||
|
||||
- keine Strict YAML Validation
|
||||
- kein neuer Pattern-Audit-Command
|
||||
- keine Runtime-Verhaltensaenderung
|
||||
- keine Aenderung an Retrieval-, Commerce- oder Prompt-Scoring
|
||||
|
||||
## Erwartete Checks nach dem Einspielen
|
||||
|
||||
```bash
|
||||
bin/console mto:agent:config:validate
|
||||
bin/console mto:agent:regression:test
|
||||
bin/console mto:agent:config:audit-source --details
|
||||
```
|
||||
|
||||
Alle drei Checks muessen weiterhin gruen sein.
|
||||
|
||||
## Hinweis
|
||||
|
||||
Die fachlichen Guardrail-Werte bleiben bewusst erhalten. Der Patch aendert nur den Ort der Pflege: YAML ist ab jetzt Source of Truth, PHP liest diese Werte nur noch aus der Config-Fassade.
|
||||
@@ -0,0 +1,35 @@
|
||||
# RetrieX Patch 16b - Core Pattern Audit Noise Reduction
|
||||
|
||||
## Ziel
|
||||
|
||||
Patch 16b reduziert False Positives im neuen `mto:agent:config:audit-patterns` Command.
|
||||
|
||||
Der erste p16-Scanner bewertete die komplette PHP-Codezeile. Dadurch wurden Marker in Methodennamen oder Config-Getter-Namen wie `get...Shop...Pattern()` als harte fachliche Core-Patterns gewertet, obwohl die eigentlichen Werte bereits YAML-backed sind.
|
||||
|
||||
## Änderungen
|
||||
|
||||
- Domain-Marker werden nur noch in String-Literalen einer verdächtigen Call-Zeile gesucht.
|
||||
- Treffer außerhalb der konfigurierten `warning_path_prefixes` werden nicht mehr als WARN eskaliert.
|
||||
- Bekannte technische Markdown-Heading-Parser für `Produkt Titel` sind über `core_pattern_audit.allowed_literal_patterns` dokumentiert und allowlisted.
|
||||
- `GovernanceConfig` validiert die neue Allowlist-Struktur.
|
||||
|
||||
## Verhalten
|
||||
|
||||
Der Command bleibt nicht-blockierend und verändert keine Runtime-Logik.
|
||||
|
||||
Erwartung nach p16b:
|
||||
|
||||
```bash
|
||||
bin/console mto:agent:config:audit-patterns --details
|
||||
```
|
||||
|
||||
soll keine WARNs mehr für reine Config-Getter-/Methodennamen melden.
|
||||
|
||||
## Lokale Prüfung
|
||||
|
||||
```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
|
||||
```
|
||||
@@ -0,0 +1,30 @@
|
||||
# RetrieX Patch 16c - Core Pattern Audit Allowed Literal Fix
|
||||
|
||||
## Purpose
|
||||
|
||||
Patch 16c fixes the last two false-positive warnings from the warn-only core pattern audit.
|
||||
|
||||
The remaining warnings were technical markdown-heading regex parsers for product-title metadata, not hardcoded domain decision logic. The p16b allowlist used a semantic whitespace regex and therefore did not match the escaped PHP regex literal as it appears in source code.
|
||||
|
||||
## Changes
|
||||
|
||||
- Updates `config/retriex/governance.yaml`.
|
||||
- Adjusts the allowlist patterns for the technical `Produkt\s+Titel` markdown-heading parser so they match escaped PHP source literals.
|
||||
- Adds no runtime behavior change.
|
||||
- Adds no strict validation.
|
||||
- Changes no retrieval, prompt, commerce, scoring, or ranking logic.
|
||||
|
||||
## Expected result
|
||||
|
||||
`bin/console mto:agent:config:audit-patterns --details` should return `OK` unless new domain-sensitive string literals were introduced elsewhere.
|
||||
|
||||
## Validation
|
||||
|
||||
Run:
|
||||
|
||||
```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
|
||||
```
|
||||
@@ -0,0 +1,60 @@
|
||||
# RetrieX Patch 16 - Core Pattern Audit Guardrail
|
||||
|
||||
## Ziel
|
||||
|
||||
Patch 16 ergänzt einen nicht-blockierenden Audit-Command, der neue oder verbliebene fachliche Pattern-, Token- und Signal-Logik im PHP-Core sichtbar macht.
|
||||
|
||||
Der Patch ändert keine Runtime-Entscheidungen, aktiviert keinen Strict-Modus und externalisiert keine weiteren fachlichen Werte. Er dient als Review-Guardrail nach der abgeschlossenen YAML-only-Migration und den Patches p13b, p14 und p15c.
|
||||
|
||||
## Neuer Command
|
||||
|
||||
```bash
|
||||
bin/console mto:agent:config:audit-patterns --details
|
||||
```
|
||||
|
||||
Optionen:
|
||||
|
||||
```bash
|
||||
bin/console mto:agent:config:audit-patterns --json
|
||||
bin/console mto:agent:config:audit-patterns --details --all
|
||||
```
|
||||
|
||||
## Konfiguration
|
||||
|
||||
Die Audit-Regeln liegen in `config/retriex/governance.yaml` unter:
|
||||
|
||||
```yaml
|
||||
retriex.governance.config.core_pattern_audit
|
||||
```
|
||||
|
||||
Konfigurierbar sind:
|
||||
|
||||
- Source-Roots
|
||||
- ausgeschlossene Pfade
|
||||
- ausgeschlossene Pfad-Patterns
|
||||
- Review-Pfadpräfixe fuer sensible Bereiche
|
||||
- zu prüfende PHP-Calls
|
||||
- Domain-Marker-Terme
|
||||
- maximale Snippet-Länge
|
||||
|
||||
## Verhalten
|
||||
|
||||
- `WARN`: konfigurierte Domain-Marker sind beteiligt.
|
||||
- `REVIEW`: technische oder nicht eindeutig fachliche Treffer; nur mit `--all` sichtbar.
|
||||
- Der Command gibt auch bei WARN-Findings `SUCCESS` zurück, damit p16 keine bestehende Pipeline blockiert.
|
||||
|
||||
## Erwartete lokale Prüfung nach Einspielen
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
## Bewusst nicht enthalten
|
||||
|
||||
- keine Strict YAML Validation
|
||||
- keine Runtime-Pattern-Änderung
|
||||
- keine Scoring-/Retrieval-Änderung
|
||||
- keine automatische Blockade von Deployments
|
||||
@@ -0,0 +1,44 @@
|
||||
# RetrieX Patch 17b - Accuracy Prompt Guard Hotfix
|
||||
|
||||
## Scope
|
||||
|
||||
This patch tightens prompt-side grounding rules for two remaining accuracy issues after p17:
|
||||
|
||||
1. Product-specific threshold / indicator transfer
|
||||
- A value, indicator, reagent, measuring range, method, accessory code, or application claim must belong to the same explicitly named product or variant.
|
||||
- Indicator tables from another Testomat variant must not be transferred to Testomat 2000 CAL.
|
||||
- The rule explicitly prevents applying Testomat 808 indicator types such as 300, 300 S, 301, 302, 303, 305, 310, 320, 330, or 350 to Testomat 2000 CAL unless the same source states that mapping.
|
||||
|
||||
2. Parameter vs. application evidence
|
||||
- A shop result can support the requested measurement parameter, but application suitability such as Schwimmbad / Pool must be stated in the same source record.
|
||||
- User wording, generated shop query terms, search ranking, product family, and generic water-treatment wording are not application evidence.
|
||||
|
||||
## Files changed
|
||||
|
||||
- `config/retriex/prompt.yaml`
|
||||
|
||||
## Runtime impact
|
||||
|
||||
No PHP runtime code was changed. This is a prompt-governance hotfix only.
|
||||
|
||||
## Required checks
|
||||
|
||||
Run after applying:
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
## Manual regression cases
|
||||
|
||||
- `welche grenzwerte kann der testomat testomat cal messen`
|
||||
- Must not answer with Testomat 808 indicator/range mappings.
|
||||
- If CAL-specific TH mappings are present in the retrieved sources, use them.
|
||||
- If not present, say that the exact CAL mapping is not available in the provided sources.
|
||||
|
||||
- `ich würde gern chlor im schwinnbad messen`
|
||||
- May use shop results for products that explicitly support chlorine measurement.
|
||||
- Must not claim Schwimmbad/Pool suitability unless the same source record explicitly states it.
|
||||
@@ -0,0 +1,55 @@
|
||||
# RetrieX Patch 17c - Accuracy CAL / Pool Grounding Hotfix
|
||||
|
||||
## Ziel
|
||||
|
||||
Patch 17c korrigiert zwei nach Patch 17b verbliebene Accuracy-Probleme:
|
||||
|
||||
1. **Testomat CAL / Grenzwerte**
|
||||
- Prompts wie `welche grenzwerte kann der testomat cal messen` sollen den passenden Produktdatensatz `Testomat 2000 CAL` sicherer als exaktes Dokument auflösen, auch wenn der Nutzer die numerische Familienkennung `2000` nicht nennt.
|
||||
- Fehlübertragungen von Testomat-808-Indikatorbereichen auf Testomat CAL werden im Prompt-Grounding weiter untersagt.
|
||||
|
||||
2. **Chlor / Schwimmbad**
|
||||
- Chlor-Messfähigkeit und Schwimmbad-/Pool-Anwendung werden getrennt bewertet.
|
||||
- Ein Produkt darf nur dann als Schwimmbad-/Pool-Lösung empfohlen werden, wenn dieselbe RAG- oder Shop-Quelle diese Anwendung explizit nennt.
|
||||
|
||||
## Geänderte Dateien
|
||||
|
||||
- `src/Knowledge/Retrieval/NdjsonChunkLookup.php`
|
||||
- `config/retriex/prompt.yaml`
|
||||
|
||||
## Details
|
||||
|
||||
### Exact document lookup
|
||||
|
||||
`NdjsonChunkLookup` erhält einen zusätzlichen Fallback für Titelmatches mit fehlender numerischer Produktfamilie. Dadurch kann ein Prompt wie `Testomat CAL` auf einen Titel wie `Testomat 2000 CAL` matchen, wenn alle nicht-numerischen Titelanker übereinstimmen und kein widersprechender numerischer Promptanker vorhanden ist.
|
||||
|
||||
Beispiele:
|
||||
|
||||
- `Testomat CAL` -> darf `Testomat 2000 CAL` matchen.
|
||||
- `Testomat 808 CAL` -> darf nicht allein wegen `CAL` auf `Testomat 2000 CAL` springen, wenn ein widersprechender Zahlenanker vorhanden ist.
|
||||
|
||||
### Prompt-Grounding
|
||||
|
||||
Die Promptregeln wurden um zwei Guardrails ergänzt:
|
||||
|
||||
- CAL darf nicht mit Testomat-808-Indikatorbereichen oder generischen `0,02 °dH bis 5 °dH`-Bereichen beantwortet werden, außer ein CAL-Quellrecord belegt diese Zuordnung explizit.
|
||||
- Chlor-Messung ist kein automatischer Beleg für Schwimmbad-/Pool-Eignung. Diese Anwendung muss in derselben Quelle explizit stehen.
|
||||
|
||||
## Erwartete Checks
|
||||
|
||||
Nach dem Einspielen ausführen:
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
## Manuelle Regression
|
||||
|
||||
Erneut testen:
|
||||
|
||||
- `welche grenzwerte kann der testomat cal messen`
|
||||
- `ich würde gern chlor im schwinnbad messen`
|
||||
|
||||
@@ -0,0 +1,61 @@
|
||||
# RetrieX Patch 17d - CAL Exact Document Grounding Fix
|
||||
|
||||
## Ziel
|
||||
|
||||
Patch 17d korrigiert den nach Patch 17c weiterhin beobachteten Accuracy-Fehler bei Fragen wie:
|
||||
|
||||
```text
|
||||
welche grenzwerte kann der testomat cal messen
|
||||
```
|
||||
|
||||
Das System durfte weiterhin den generischen bzw. Testomat-808-nahen Bereich `0,02 °dH bis 5 °dH` auf `Testomat 2000 CAL` übertragen. Diese Übertragung ist fachlich falsch, wenn die CAL-spezifische Quelle diese Zuordnung nicht explizit belegt.
|
||||
|
||||
Zusätzlich werden die bereits begonnenen Chlor-/Schwimmbad-Grounding-Regeln erneut in den aktuellen Stand übernommen.
|
||||
|
||||
## Geänderte Dateien
|
||||
|
||||
- `src/Knowledge/Retrieval/NdjsonChunkLookup.php`
|
||||
- `config/retriex/prompt.yaml`
|
||||
|
||||
## Details
|
||||
|
||||
### Exact document lookup
|
||||
|
||||
`NdjsonChunkLookup` erhält einen konservativen Fallback für Titelmatches mit fehlender numerischer Produktfamilie:
|
||||
|
||||
- `Testomat CAL` darf `Testomat 2000 CAL` matchen, wenn alle nicht-numerischen Titelanker passen.
|
||||
- `Testomat 808 CAL` darf nicht allein wegen `CAL` auf `Testomat 2000 CAL` springen, wenn ein widersprechender Zahlenanker vorhanden ist.
|
||||
|
||||
Damit werden CAL-Fragen stärker auf das konkrete CAL-Dokument fokussiert, statt über breite semantische Treffer oder Testomat-808-nahe Indikatortabellen beantwortet zu werden.
|
||||
|
||||
### CAL-Grounding
|
||||
|
||||
Die Prompt-Regeln verbieten ausdrücklich:
|
||||
|
||||
- Übertragung von Testomat-808-Indikatortabellen auf Testomat CAL.
|
||||
- Ausgabe des generischen Bereichs `0,02 °dH bis 5 °dH`, wenn dieser nicht explizit in einem CAL-Quellrecord belegt ist.
|
||||
- Verwendung von 808-Indikatortypen wie `300`, `300 S`, `301`, `302`, `303`, `305`, `310`, `320`, `330`, `350` als CAL-Indikatoren.
|
||||
|
||||
Wenn keine CAL-spezifischen numerischen Grenzwerte belegt sind, muss das System das sagen, statt zu generalisieren.
|
||||
|
||||
### Chlor / Schwimmbad
|
||||
|
||||
Die Regeln unterscheiden weiterhin zwischen belegter Chlor-Messung und explizit belegter Schwimmbad-/Pool-Anwendung. Chlor-Messfähigkeit allein ist kein Beleg für Schwimmbad-Eignung.
|
||||
|
||||
## Erwartete Checks
|
||||
|
||||
Nach dem Einspielen ausführen:
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
## Manuelle Regression
|
||||
|
||||
Erneut testen:
|
||||
|
||||
- `welche grenzwerte kann der testomat cal messen`
|
||||
- `ich würde gern chlor im schwinnbad messen`
|
||||
@@ -0,0 +1,35 @@
|
||||
# RetrieX Patch 17e – Prompt Config Path Restore
|
||||
|
||||
## Zweck
|
||||
|
||||
Dieser Patch behebt einen technischen Konfigurationsfehler aus dem p17c/p17d-Zwischenstand.
|
||||
|
||||
Nach dem Einspielen konnte `PromptBuilderConfig::getDirectMainDeviceRequestPatterns()` den YAML-Pfad
|
||||
|
||||
`role_guard.direct_main_device_request_patterns`
|
||||
|
||||
nicht finden. Dadurch brach die Anfrageverarbeitung mit folgendem Fehler ab:
|
||||
|
||||
`Missing required RetrieX prompt config path "role_guard.direct_main_device_request_patterns".`
|
||||
|
||||
## Änderungen
|
||||
|
||||
- `config/retriex/prompt.yaml`
|
||||
- stellt `role_guard.direct_main_device_request_patterns` wieder her.
|
||||
- Die Patterns entsprechen der bereits YAML-backed externalisierten Device-Advisory-Erkennung aus p14/p17.
|
||||
|
||||
## Nicht geändert
|
||||
|
||||
- Keine PHP-Änderung.
|
||||
- Keine Runtime-Logikänderung.
|
||||
- Keine Änderung am CAL-Accuracy-Verhalten.
|
||||
- Keine neue Heuristik.
|
||||
|
||||
## Prüfung nach Einspielen
|
||||
|
||||
```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
|
||||
```
|
||||
46
patch_history/RETRIEX_PATCH_17_ACCURACY_HOTFIX_README.md
Normal file
46
patch_history/RETRIEX_PATCH_17_ACCURACY_HOTFIX_README.md
Normal file
@@ -0,0 +1,46 @@
|
||||
# RetrieX Patch 17 - Accuracy Hotfix
|
||||
|
||||
## Purpose
|
||||
|
||||
Patch 17 addresses the first concrete accuracy bug set after the YAML-only and governance cleanup.
|
||||
It keeps the YAML-only policy intact and does not introduce hard domain lists in PHP.
|
||||
|
||||
## Covered issue classes
|
||||
|
||||
1. Product title anchoring for prompts that mention a product family plus variant suffix but omit an intermediate numeric family token.
|
||||
This prevents variant-specific questions from falling back to broader semantic hits.
|
||||
2. RAG evidence confidence for aggregate/count-style portfolio questions.
|
||||
Semantic product hits are no longer enough to mark such answers as `fachlich belegt` unless aggregate evidence terms are present.
|
||||
3. Commerce intent detection for product-seeking measurement prompts such as wanting to measure a parameter in an application context.
|
||||
4. Commerce intent/shop query support for cable/accessory searches such as pH/Redox connection cables.
|
||||
5. Prompt guardrail reinforcement so the model does not transfer accessory roles between separate shop product records.
|
||||
|
||||
## Changed files
|
||||
|
||||
- `src/Knowledge/Retrieval/NdjsonChunkLookup.php`
|
||||
- `src/Agent/AgentRunner.php`
|
||||
- `src/Config/AgentRunnerConfig.php`
|
||||
- `src/Config/RetriexEffectiveConfigProvider.php`
|
||||
- `config/retriex/agent.yaml`
|
||||
- `config/retriex/intent.yaml`
|
||||
- `config/retriex/commerce.yaml`
|
||||
- `config/retriex/prompt.yaml`
|
||||
|
||||
## Local checks
|
||||
|
||||
Run after applying:
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
## Manual accuracy retests
|
||||
|
||||
- `qwelche grenzwerte kann der testomat testomat cal messen`
|
||||
- `wieviele testomat geräte haben wir`
|
||||
- `ich würde gern chlor im schwinnbad messen`
|
||||
- `zeige mir Anschlusskabel für pH/Redox` followed by `suche im shop`
|
||||
- `suche Messgeräte zur wasseranalyse mit dem parameter Carbonhärte (KH)`
|
||||
@@ -0,0 +1,112 @@
|
||||
# RetrieX Patch 18 – Evidence State / Aggregate Consistency Fix
|
||||
|
||||
## Zweck
|
||||
|
||||
Dieser Patch behebt die Status-/Antwort-Konsistenz für Aggregat- und Zählfragen wie:
|
||||
|
||||
`wieviele testomat geräte haben wir`
|
||||
|
||||
Bisher konnte RetrieX bei solchen Fragen semantisch passende RAG-Treffer finden und die Beleglage trotzdem als `fachlich belegt` anzeigen, obwohl die Antwort selbst keine belastbare Zählinformation nennen konnte.
|
||||
|
||||
## Fachliche Entscheidung
|
||||
|
||||
`fachlich belegt` wird nicht pauschal abgewertet. Stattdessen wird ein eigener Zwischenzustand eingeführt:
|
||||
|
||||
`aggregate_missing`
|
||||
|
||||
Dieser Zustand bedeutet:
|
||||
|
||||
- Es wurden Quellen geprüft.
|
||||
- Es gibt semantisch passende Quellen.
|
||||
- Die Quellen enthalten aber keine explizite Aggregat-/Zählinformation für die angefragte Anzahl.
|
||||
|
||||
Die Nutzeranzeige wird dadurch präziser:
|
||||
|
||||
`Beleglage: geprüfte Quellen, keine passende Zählinformation`
|
||||
|
||||
## Änderungen
|
||||
|
||||
### `src/Agent/AgentRunner.php`
|
||||
|
||||
- Erkennt Aggregatfragen weiterhin über YAML-konfigurierte Patterns.
|
||||
- Prüft bei Aggregatfragen zusätzlich auf explizite Aggregat-Antwortbelege.
|
||||
- Gibt bei fehlender Zählinformation den neuen Evidence-State `aggregate_missing` zurück.
|
||||
- Zeigt für diesen Zustand eine präzisere Beleglage an.
|
||||
- Übergibt den Evidence-State auch an die finale Production-UI-Confidence-Logik.
|
||||
|
||||
### `src/Agent/PromptBuilder.php`
|
||||
|
||||
- Behandelt `aggregate_missing` als eigenen Reliability-State.
|
||||
- Gibt dem LLM explizite Regeln, keine Produktfamilien-/Portfolio-Nennungen als konkrete Anzahl zu verkaufen.
|
||||
|
||||
### `src/Config/AgentRunnerConfig.php`
|
||||
|
||||
- Neuer YAML-backed Getter:
|
||||
|
||||
`getRagEvidenceAggregateAnswerEvidencePatterns()`
|
||||
|
||||
### `src/Config/RetriexEffectiveConfigProvider.php`
|
||||
|
||||
- Neuer Config-Pfad wird im Effective Config Output sichtbar.
|
||||
- Neuer Config-Pfad wird als Regex-Liste validiert.
|
||||
|
||||
### `config/retriex/agent.yaml`
|
||||
|
||||
- Neuer YAML-Pfad:
|
||||
|
||||
`rag_evidence_guard.aggregate_answer_evidence_patterns`
|
||||
|
||||
Diese Patterns beschreiben explizite Zähl-/Aggregatbelege, z. B. `Anzahl ... 12`, `insgesamt ... 12`, oder `Sortiment umfasst ... 12`.
|
||||
|
||||
### `config/retriex/prompt.yaml`
|
||||
|
||||
- Neuer Reliability-State:
|
||||
|
||||
`aggregatfrage_keine_belastbare_zaehlinformation`
|
||||
|
||||
## Nicht geändert
|
||||
|
||||
- Keine Shop-Follow-up-Logik.
|
||||
- Keine Produktrollen-Logik.
|
||||
- Kein allgemeines Retrieval-/Scoring-Tuning.
|
||||
- Keine harte neue PHP-Keywordliste im Core.
|
||||
- Keine Strict-YAML-Validation.
|
||||
|
||||
## Lokale Prüfung in dieser Umgebung
|
||||
|
||||
Durchgeführt:
|
||||
|
||||
```bash
|
||||
php -l src/Agent/AgentRunner.php
|
||||
php -l src/Agent/PromptBuilder.php
|
||||
php -l src/Config/AgentRunnerConfig.php
|
||||
php -l src/Config/RetriexEffectiveConfigProvider.php
|
||||
```
|
||||
|
||||
Zusätzlich:
|
||||
|
||||
- YAML-Parse für `config/retriex/agent.yaml` erfolgreich.
|
||||
- YAML-Parse für `config/retriex/prompt.yaml` erfolgreich.
|
||||
- Regex-Smoke-Test für die neuen Aggregat-Antwortpatterns erfolgreich.
|
||||
|
||||
Nicht vollständig ausführbar in dieser Umgebung:
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
Grund: Die ZIP enthält keine installierten Composer-Dependencies; `composer install` kann hier wegen fehlender PHP-Extensions und fehlendem Netzwerkzugriff nicht vollständig abgeschlossen werden.
|
||||
|
||||
## Pflichtprüfung nach Einspielen
|
||||
|
||||
Bitte nach dem Einspielen im Projekt ausführen:
|
||||
|
||||
```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
|
||||
```
|
||||
@@ -0,0 +1,83 @@
|
||||
# RetrieX Patch 19 - Typo-tolerant price follow-up intent
|
||||
|
||||
## Purpose
|
||||
|
||||
Patch 19 fixes the observed regression class where a short referential price follow-up with a typo does not trigger commerce/shop handling.
|
||||
|
||||
Observed conversation:
|
||||
|
||||
1. `Was ist der niedrigste Grenzwert für die Wasserhärte, welcher mit einem Testomaten überwacht werden kann?`
|
||||
2. `mit welchem indikator wird der wert gemessen`
|
||||
3. `was kpstet der indikator`
|
||||
|
||||
The third input should be treated like `was kostet der indikator` and must enter the shop/commerce path. Before this patch, `kpstet` was not recognized as a commerce signal, so RetrieX stayed in RAG-only mode and produced an unrelated RAG answer.
|
||||
|
||||
## Scope
|
||||
|
||||
YAML-only fix. No PHP runtime logic changed.
|
||||
|
||||
Changed files:
|
||||
|
||||
- `config/retriex/intent.yaml`
|
||||
- `config/retriex/commerce.yaml`
|
||||
|
||||
## What changed
|
||||
|
||||
### `config/retriex/intent.yaml`
|
||||
|
||||
Added common typo variants for `kostet`:
|
||||
|
||||
- `kpstet`
|
||||
- `ksotet`
|
||||
|
||||
The variants were added to:
|
||||
|
||||
- `strong_signals`
|
||||
- `non_product_commerce_signals`
|
||||
- `price_terms`
|
||||
- `explicit_commerce_intent_patterns`
|
||||
|
||||
This lets typo variants trigger the existing commerce intent path without introducing hard-coded logic in PHP.
|
||||
|
||||
### `config/retriex/commerce.yaml`
|
||||
|
||||
Added the typo variants to:
|
||||
|
||||
- `filter_search_tokens`
|
||||
- `search_token_corrections`
|
||||
|
||||
This prevents typo tokens from polluting the generated Store API search query. The parser normalizes:
|
||||
|
||||
- `kpstet` -> `kostet`
|
||||
- `ksotet` -> `kostet`
|
||||
|
||||
Then the existing `kostet` filter removes the price-control word from the product query.
|
||||
|
||||
## Expected result
|
||||
|
||||
`was kpstet der indikator` should now be detected as commerce intent and proceed to shop search. In the known flow, the existing history/anchor logic should be able to keep the `Indikatortyp 300` context and resolve toward a query such as:
|
||||
|
||||
`indikatortyp 300 indikator`
|
||||
|
||||
## Why this is intentionally small
|
||||
|
||||
This patch does not change retrieval, scoring, Shopware matching, prompt building or evidence-state logic. It only extends the YAML-configured vocabulary/corrections for one observed typo class.
|
||||
|
||||
## Required checks after applying
|
||||
|
||||
Run the standard checks:
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
Then manually retest the conversation flow:
|
||||
|
||||
1. `Was ist der niedrigste Grenzwert für die Wasserhärte, welcher mit einem Testomaten überwacht werden kann?`
|
||||
2. `mit welchem indikator wird der wert gemessen`
|
||||
3. `was kpstet der indikator`
|
||||
|
||||
Expected: third turn should request/shop-search indicator products, not answer from RAG-only indicator documents.
|
||||
@@ -0,0 +1,58 @@
|
||||
# RetrieX Patch 20b – Routing Normalization Fix
|
||||
|
||||
## Ziel
|
||||
|
||||
Patch 20b korrigiert den ersten LLM-Normalisierungsansatz aus p20. Die LLM-gestützte Eingabekorrektur bleibt erhalten, wird aber robuster und sauberer im Routing verwendet.
|
||||
|
||||
## Problem
|
||||
|
||||
Der Test `was kpstet der indikator` blieb nach p20 weiterhin RAG-only. Ursache: Wenn das LLM wegen strenger Guardrails unsicher war, konnte es den Originaltext unverändert zurückgeben. Dann erkannte die Commerce-/Shop-Intent-Logik das falsch geschriebene Routing-Wort nicht.
|
||||
|
||||
Zusätzlich darf die normalisierte Routing-Frage nicht die eigentliche Nutzerfrage in History und Antwortkontext ersetzen.
|
||||
|
||||
## Lösung
|
||||
|
||||
- Originalprompt bleibt erhalten.
|
||||
- Separater `routingPrompt` wird vor Intent-, RAG- und Shop-Routing verwendet.
|
||||
- LLM-Normalisierung bleibt der erste Schritt.
|
||||
- Danach generischer Fuzzy-Fallback gegen kanonische Routing-Terme aus YAML.
|
||||
- Keine Tippfehlerlisten wie manuell gepflegte Vertipper.
|
||||
- Fuzzy-Matching arbeitet nur gegen kanonische Signalwörter wie `kostet`, `suche`, `shop`, `messgerät`, `lösung`, `schwimmbad` usw.
|
||||
- Mehrdeutige oder unsichere Korrekturen werden verworfen.
|
||||
- Produktnamen, Zahlen und fachliche Ergänzungen werden nicht hinzugefügt.
|
||||
|
||||
## Zusätzliche Intent-Korrektur
|
||||
|
||||
Die Formulierung `ich suche eine preiswerte Lösung zur messung von pH & Chlor für mein schwimmbad` wird als beratende Produktsuche behandelt. Dafür wurde ein zusätzliches Advisory-Product-Selection-Pattern sowie Preiswert-/Günstig-Signale in YAML ergänzt.
|
||||
|
||||
## Geänderte Dateien
|
||||
|
||||
- `src/Agent/AgentRunner.php`
|
||||
- `src/Config/AgentRunnerConfig.php`
|
||||
- `src/Config/RetriexEffectiveConfigProvider.php`
|
||||
- `config/retriex/agent.yaml`
|
||||
- `config/retriex/intent.yaml`
|
||||
|
||||
## Pflichtchecks
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
## Manuelle Regressionen
|
||||
|
||||
1. `was kpstet der indikator`
|
||||
- Erwartung: interne Routing-Normalisierung zu `was kostet der indikator`
|
||||
- Shop-Suche wird angefragt
|
||||
|
||||
2. `ich suche eine preiswerte Lösung zur messung von pH & Chlor für mein schwimmbad`
|
||||
- Erwartung: beratende Shop-/Produktsuche wird ausgelöst
|
||||
- Chlor-/pH-Messfähigkeit darf genannt werden
|
||||
- Schwimmbad-Eignung nur vorsichtig formulieren, wenn nicht explizit belegt
|
||||
|
||||
3. Stabile 1.5.1-Baseline
|
||||
- `Was ist der niedrigste Grenzwert für die Wasserhärte, welcher mit einem Testomaten überwacht werden kann?`
|
||||
- `mit welchem indikator wird der wert gemessen`
|
||||
@@ -0,0 +1,61 @@
|
||||
# RetrieX Patch 20c – Commercial Table Follow-up Fix
|
||||
|
||||
## Ziel
|
||||
|
||||
Patch 20c korrigiert eine Regression aus dem p20/p20b-Normalisierungs- und Routing-Umfeld: kurze referenzielle Nachfragen wie `die tabelle mit preisen` müssen den letzten fachlichen Kontext übernehmen und eine Shop-Suche auslösen.
|
||||
|
||||
## Reproduzierter Problemfall
|
||||
|
||||
1. `welche grenzwerte kann der testomat 808 messen`
|
||||
2. RetrieX antwortet korrekt mit Testomat 808 und einer Grenzwert-/Indikatortyp-Tabelle.
|
||||
3. Folgefrage: `die tabelle mit preisen`
|
||||
|
||||
Vor p20c blieb die Folgefrage RAG-only bzw. ohne Shop-Suche. Das ist fachlich zu schwach, weil `die tabelle` klar auf die vorherige Indikatortyp-Tabelle referenziert und `mit preisen` aktuelle Shopdaten verlangt.
|
||||
|
||||
## Lösung
|
||||
|
||||
- LLM-Input-Normalisierung aus p20/p20b bleibt erhalten.
|
||||
- Es gibt eine zusätzliche, YAML-konfigurierbare Erkennung für kommerzielle Tabellen-Follow-ups.
|
||||
- Wenn der normale Commerce-Intent ausfällt, kann ein kurzer Tabellen-/Preis-Follow-up anhand vorhandener History-Anker gezielt zu `product_search` hochgestuft werden.
|
||||
- Für Preis-Tabellen-Follow-ups wird vor einer generischen optimierten Suchquery ein kontextueller Shop-Suchbegriff aus der letzten Antwort abgeleitet.
|
||||
- Beim Testomat-808-/Indikatortyp-Fall ergibt der Fallback generisch `Testomat 808 indikator` statt nur `die tabelle mit preisen` oder `Testomat 808`.
|
||||
- Es werden keine konkreten Tippfehlerlisten eingeführt.
|
||||
|
||||
## Geänderte Dateien
|
||||
|
||||
- `src/Agent/AgentRunner.php`
|
||||
- `src/Config/AgentRunnerConfig.php`
|
||||
- `src/Config/RetriexEffectiveConfigProvider.php`
|
||||
- `config/retriex/agent.yaml`
|
||||
- `config/retriex/intent.yaml`
|
||||
|
||||
## Pflichtchecks
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
## Manuelle Regressionen
|
||||
|
||||
1. `was kpstet der indikator`
|
||||
- Erwartung: LLM-/Fuzzy-Normalisierung bleibt wirksam.
|
||||
- Shop-Suche wird ausgelöst.
|
||||
|
||||
2. `ich suche eine preiswerte Lösung zur messung von pH & Chlor für mein schwimmbad`
|
||||
- Erwartung: beratende Shop-/Produktsuche wird ausgelöst.
|
||||
|
||||
3. `welche grenzwerte kann der testomat 808 messen` → `die tabelle mit preisen`
|
||||
- Erwartung: Folgefrage wird als kommerzieller Tabellen-Follow-up erkannt.
|
||||
- Shop-Suche wird ausgelöst.
|
||||
- Gesendete Suchquery sollte sinngemäß `Testomat 808 indikator` sein.
|
||||
- Antwort soll eine Preistabelle der passenden Indikatoren/Zubehörtreffer bilden, soweit Shopdaten vorhanden sind.
|
||||
|
||||
## Nicht geändert
|
||||
|
||||
- Kein Scoring-Umbau.
|
||||
- Keine harte Tippfehlerliste.
|
||||
- Keine Änderung an Retrieval-/Vectorlogik.
|
||||
- Keine Änderung an Shop-Service-Suche selbst.
|
||||
@@ -0,0 +1,91 @@
|
||||
# RetrieX Patch 20d - Commercial Table Follow-up Routing Fix
|
||||
|
||||
## Ziel
|
||||
|
||||
p20c hat referenzielle Tabellen-/Preisnachfragen noch zu spaet bzw. zu fragil behandelt. Der Fall
|
||||
|
||||
```text
|
||||
welche grenzwerte kann der testomat 808 messen
|
||||
|
||||
die tabelle mit preisen
|
||||
```
|
||||
|
||||
konnte weiterhin in den RAG-only-Pfad fallen, wenn der kurze Commerce-History-Kontext keinen passenden Anchor geliefert hat.
|
||||
|
||||
p20d sorgt dafuer, dass kommerzielle Tabellen-Follow-ups zuerst sicher als Shop-Intent geroutet werden. Die konkrete Shop-Query wird danach robuster aus erweitertem bzw. vollem Verlauf abgeleitet.
|
||||
|
||||
## Aenderungen
|
||||
|
||||
Geaendert:
|
||||
|
||||
- `src/Agent/AgentRunner.php`
|
||||
|
||||
## Technische Anpassungen
|
||||
|
||||
- `detectCommerceIntentForRouting()` stuft kommerzielle Tabellen-Follow-ups nun auch dann als `product_search` ein, wenn im kurzen History-Kontext kein Anchor gefunden wurde.
|
||||
- Die Anchor-Pruefung bleibt im Log sichtbar (`hasHistoryAnchor`), blockiert aber nicht mehr das Shop-Routing.
|
||||
- `resolveShopSearchQuery()` nutzt fuer kommerzielle Tabellen-Follow-ups einen dedizierten Resolver.
|
||||
- Der Resolver prueft zuerst den vorhandenen Commerce-History-Kontext, dann erweiterten History-Kontext, dann optional den Full-History-Kontext.
|
||||
- Die History wird newest-first durchsucht, damit auch nach einem fehlgeschlagenen Zwischen-Follow-up noch der vorherige fachliche Tabellenkontext gefunden werden kann.
|
||||
- Wenn ein Turn zwar Indikator-/Reagenz-Kontext enthaelt, aber kein Modell, wird nicht sofort generisch `indikator` genommen. Es wird weiter nach einem juengeren/aelteren Turn mit Modellanker gesucht. Erst danach wird auf die generische Query zurueckgefallen.
|
||||
|
||||
## Bewusst nicht geaendert
|
||||
|
||||
- Keine neue Tippfehlerliste.
|
||||
- Keine Scoring-Aenderung.
|
||||
- Keine Retrieval-/Vector-Aenderung.
|
||||
- Keine Aenderung an der LLM-Input-Normalisierung aus p20/p20b.
|
||||
- Keine neuen YAML-Pfade.
|
||||
|
||||
## Erwartete Wirkung
|
||||
|
||||
Der Flow
|
||||
|
||||
```text
|
||||
welche grenzwerte kann der testomat 808 messen
|
||||
|
||||
die tabelle mit preisen
|
||||
```
|
||||
|
||||
soll eine Shop-Suche ausloesen. Erwartete Shop-Query sinngemaess:
|
||||
|
||||
```text
|
||||
testomat 808 indikator
|
||||
```
|
||||
|
||||
Auch
|
||||
|
||||
```text
|
||||
die tabelle mit shop preisen
|
||||
```
|
||||
|
||||
soll in den Shop-Pfad gehen.
|
||||
|
||||
## Pflichtchecks nach Einspielen
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
## Manuelle Regressionstests
|
||||
|
||||
```text
|
||||
was kpstet der indikator
|
||||
```
|
||||
|
||||
```text
|
||||
ich suche eine preiswerte Loesung zur messung von pH & Chlor fuer mein schwimmbad
|
||||
```
|
||||
|
||||
```text
|
||||
welche grenzwerte kann der testomat 808 messen
|
||||
die tabelle mit preisen
|
||||
```
|
||||
|
||||
```text
|
||||
welche grenzwerte kann der testomat 808 messen
|
||||
die tabelle mit shop preisen
|
||||
```
|
||||
@@ -0,0 +1,87 @@
|
||||
# RetrieX Patch 20e - Force Commercial Table Follow-up Routing
|
||||
|
||||
## Ziel
|
||||
|
||||
Patch 20e behebt die weiterhin fehlschlagende referenzielle Shop-Nachfrage nach einer zuvor erzeugten Tabelle, z. B.:
|
||||
|
||||
```text
|
||||
welche grenzwerte kann der testomat 808 messen
|
||||
```
|
||||
|
||||
gefolgt von:
|
||||
|
||||
```text
|
||||
die tabelle mit preisen
|
||||
```
|
||||
|
||||
oder:
|
||||
|
||||
```text
|
||||
die tabelle mit shop preisen
|
||||
```
|
||||
|
||||
Diese Follow-ups duerfen nicht mehr in den RAG-only-Pfad fallen.
|
||||
|
||||
## Ursache
|
||||
|
||||
Die bisherigen p20b/p20c/p20d-Ansaetze waren noch zu fragil, weil die Shop-Promotion entweder zu spaet griff oder indirekt ueber den normalen Commerce-Intent- und History-Anchor-Pfad lief. Wenn diese Route nicht aktiv wurde, blieb der Status bei `Shop-Treffer: nicht angefragt`.
|
||||
|
||||
## Aenderungen
|
||||
|
||||
- Fuehrt in `AgentRunner` einen expliziten `forcedShopSearchQuery` ein.
|
||||
- Kommerzielle Tabellen-Follow-ups werden vor der normalen Commerce-Intent-Entscheidung erkannt.
|
||||
- Wenn ein passender Tabellen-/Preis-Follow-up erkannt wird, wird der Shop-Pfad erzwungen.
|
||||
- Die konkrete Shop-Query wird aus der Conversation-History abgeleitet.
|
||||
- Bei Testomat-808-Grenzwert-/Indikator-Tabellen wird bevorzugt eine Query wie `Testomat 808 indikator` erzeugt.
|
||||
- Wenn kein stabiler Kontext ableitbar ist, bleibt die Anfrage dennoch im Shop-Pfad und nutzt den konfigurierten Fallback `indikator` statt RAG-only.
|
||||
- Die LLM-Input-Normalisierung aus p20 bleibt erhalten.
|
||||
- Es werden keine konkreten Tippfehlerlisten eingefuehrt.
|
||||
- Keine Scoring-/Vector-/Retrieval-Aenderung.
|
||||
|
||||
## Geaenderte Dateien
|
||||
|
||||
- `src/Agent/AgentRunner.php`
|
||||
- `src/Config/AgentRunnerConfig.php`
|
||||
- `src/Config/RetriexEffectiveConfigProvider.php`
|
||||
- `config/retriex/agent.yaml`
|
||||
|
||||
## Pflichtchecks nach Einspielen
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
## Manuelle Regressionstests
|
||||
|
||||
```text
|
||||
was kpstet der indikator
|
||||
```
|
||||
|
||||
Erwartung: Shop-Suche wird ausgeloest.
|
||||
|
||||
```text
|
||||
ich suche eine preiswerte Lösung zur messung von pH & Chlor für mein schwimmbad
|
||||
```
|
||||
|
||||
Erwartung: beratende Shop-/Produktsuche wird ausgeloest.
|
||||
|
||||
```text
|
||||
welche grenzwerte kann der testomat 808 messen
|
||||
```
|
||||
|
||||
gefolgt von:
|
||||
|
||||
```text
|
||||
die tabelle mit preisen
|
||||
```
|
||||
|
||||
Erwartung: Shop-Suche wird ausgeloest, Query sinngemaess `Testomat 808 indikator` oder mindestens `indikator`.
|
||||
|
||||
```text
|
||||
die tabelle mit shop preisen
|
||||
```
|
||||
|
||||
Erwartung: Shop-Suche wird ebenfalls ausgeloest, nicht RAG-only.
|
||||
@@ -0,0 +1,75 @@
|
||||
# RetrieX Patch 20f - Explicit Shop Routing Guard
|
||||
|
||||
## Purpose
|
||||
|
||||
Patch 20f fixes a critical routing regression observed after the p20 series:
|
||||
|
||||
```text
|
||||
shop testomat 808
|
||||
```
|
||||
|
||||
This must always enter the Shop path. After p20e it could still fall back to RAG-only with `Shop-Treffer: nicht angefragt`.
|
||||
|
||||
## Root cause
|
||||
|
||||
The p20 series added LLM/fuzzy input normalization and several referential follow-up routing helpers. The follow-up fixes were too focused on table/price references and did not provide a hard safety net for explicit user routing terms such as `shop`, `preis`, `kostet`, `suche`, `kaufen`, etc.
|
||||
|
||||
If the normal commerce detector or a normalized routing prompt failed to preserve that signal, an explicit Shop request could still fall into the non-commerce/RAG-only branch.
|
||||
|
||||
## Change
|
||||
|
||||
`AgentRunner` now applies an explicit Shop routing guard before the normal Commerce intent decision:
|
||||
|
||||
- Checks the original user prompt and the routing prompt for configured commercial signal terms from YAML.
|
||||
- If the original prompt explicitly says `shop`/price/search/etc., the routing prompt is restored to the original prompt unless this is a commercial table follow-up.
|
||||
- Forces `CommerceIntentLite::PRODUCT_SEARCH` for explicit commercial routing signals.
|
||||
- Keeps the existing p20 LLM input normalization and p20e commercial table follow-up handling.
|
||||
- Adds logging for forced explicit Shop routing.
|
||||
|
||||
## Files changed
|
||||
|
||||
- `src/Agent/AgentRunner.php`
|
||||
|
||||
## Important design note
|
||||
|
||||
This is not a new typo list and not a scoring change. It is a routing invariant:
|
||||
|
||||
> Explicit Shop/commercial wording must never result in `Shop-Treffer: nicht angefragt`.
|
||||
|
||||
The signal terms are still read from existing YAML config (`follow_up_context.explicit_commercial_signal_terms`).
|
||||
|
||||
## Recommended checks
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
## Manual regression tests
|
||||
|
||||
```text
|
||||
shop testomat 808
|
||||
```
|
||||
|
||||
Expected: Shop search is requested.
|
||||
|
||||
```text
|
||||
was kpstet der indikator
|
||||
```
|
||||
|
||||
Expected: typo normalization/fuzzy routing still turns this into a price/shop follow-up.
|
||||
|
||||
```text
|
||||
welche grenzwerte kann der testomat 808 messen
|
||||
die tabelle mit preisen
|
||||
```
|
||||
|
||||
Expected: table-price follow-up is routed to Shop using the previous Testomat 808 / indicator context.
|
||||
|
||||
```text
|
||||
ich suche eine preiswerte Lösung zur messung von pH & Chlor für mein schwimmbad
|
||||
```
|
||||
|
||||
Expected: advisory product/shop routing is requested.
|
||||
@@ -0,0 +1,152 @@
|
||||
# RetrieX Patch 20h – Total Commerce Routing & Shop Status Fix
|
||||
|
||||
## Ziel
|
||||
|
||||
Dieser Patch ersetzt die fragmentierten p20d/p20e/p20f/p20g-Nachbesserungen durch einen kumulativen Fix gegen den aktuellen `rag-inprogress.zip`-Stand.
|
||||
|
||||
Er adressiert zwei zusammenhängende Fehlerklassen:
|
||||
|
||||
1. Explizite oder referenzielle Commerce-/Shop-Anfragen dürfen nicht im RAG-only-Pfad landen.
|
||||
2. Sobald ein Shop-/Commerce-Routing erkannt ist, darf die Statuskarte während des Ablaufs nicht weiter `Shop-Treffer: nicht angefragt` anzeigen.
|
||||
|
||||
## Behobene Fälle
|
||||
|
||||
### Expliziter Shop-Intent
|
||||
|
||||
Beispiel:
|
||||
|
||||
```text
|
||||
shop testomat 808
|
||||
```
|
||||
|
||||
Erwartung:
|
||||
|
||||
- Commerce-Intent wird abgesichert.
|
||||
- Shop-Pfad wird betreten.
|
||||
- Status springt nach der Intent-Erkennung auf `Shop-Treffer: wird geladen`.
|
||||
|
||||
### Tippfehler-Normalisierung bleibt erhalten
|
||||
|
||||
Beispiel:
|
||||
|
||||
```text
|
||||
was kpstet der indikator
|
||||
```
|
||||
|
||||
Erwartung:
|
||||
|
||||
- LLM-/Fuzzy-Normalisierung bleibt erhalten.
|
||||
- Die Anfrage kann intern als Preis-/Shop-Follow-up geroutet werden.
|
||||
- Es wird keine konkrete Tippfehlerliste eingeführt.
|
||||
|
||||
### Referenzieller Tabellen-/Preis-Follow-up
|
||||
|
||||
Beispiel:
|
||||
|
||||
```text
|
||||
welche grenzwerte kann der testomat 808 messen
|
||||
|
||||
die tabelle mit preisen
|
||||
```
|
||||
|
||||
Erwartung:
|
||||
|
||||
- `die tabelle mit preisen` wird als kommerzieller Tabellen-Follow-up in den Shop-Pfad gehoben.
|
||||
- Die Shop-Query wird aus dem Verlauf robuster abgeleitet, z. B. `Testomat 808 indikator`.
|
||||
- Die History wird newest-first durchsucht und nicht nur der letzte Turn betrachtet.
|
||||
|
||||
### Status-/Meta-Konsistenz
|
||||
|
||||
Sobald Commerce-Intent erkannt ist, wird `shopCountMode` zentral berechnet:
|
||||
|
||||
- vor Shop-Suche: `loading` → `Shop-Treffer: wird geladen`
|
||||
- nach Shop-Suche: `count` → echte Trefferzahl
|
||||
- Shop-Systemfehler: `unavailable` → `Shop-Treffer: nicht verfügbar`
|
||||
- Commerce erkannt, aber keine konkrete Suchquery lösbar: `not_resolved` → `Shop-Treffer: keine Suchquery`
|
||||
- nur Nicht-Commerce bleibt `not_requested`
|
||||
|
||||
Damit gibt es im Shop-/Commerce-Ablauf keine verstreuten harten `not_requested`-Zwischenstatus mehr.
|
||||
|
||||
## Geänderte Datei
|
||||
|
||||
- `src/Agent/AgentRunner.php`
|
||||
|
||||
## Technische Änderungen
|
||||
|
||||
- Initialisierung von `$commerceIntent` und `$shopSearchSkippedBecauseNoQuery` vor dem Try-Block.
|
||||
- Absicherung gegen Normalisierungsverluste: falls der normalisierte Routing-Prompt keinen Commerce-Intent ergibt, der Originalprompt aber schon, wird der Original-Commerce-Intent übernommen.
|
||||
- Frühes Meta-Event `Shop-Routing erkannt` bei Commerce-Intent.
|
||||
- RAG-Zwischenmeta nutzt bei Commerce-Intent `loading` statt `not_requested`.
|
||||
- `not_requested` wird nicht mehr an mehreren Stellen hart gesetzt, sondern über `resolveShopCountModeForMeta()` zentral berechnet.
|
||||
- Referenzielle Tabellen-Follow-ups werden ohne vorherige harte History-Anchor-Bedingung in den Shop-Pfad gehoben.
|
||||
- Tabellen-/Preis-Follow-up-Query sucht History-Kontext robuster über Commerce-Kontext, erweiterten Verlauf und optional Full-History.
|
||||
- History-Turns werden newest-first geprüft.
|
||||
- Wenn ein Indikator-/Tabellenkontext ohne Modell gefunden wird, bleibt ein Fallback erhalten; ein später gefundener Modellanker hat Vorrang.
|
||||
|
||||
## Lokale Prüfungen
|
||||
|
||||
Durchgeführt in der Container-Umgebung:
|
||||
|
||||
```bash
|
||||
php -l src/Agent/AgentRunner.php
|
||||
```
|
||||
|
||||
Ergebnis: OK.
|
||||
|
||||
Zusätzliche statische Checks:
|
||||
|
||||
- kein hartes `shopCountMode: 'not_requested'` mehr im AgentRunner
|
||||
- `not_requested` nur noch zentral in `resolveShopCountModeForMeta()`
|
||||
- `loading`, `not_resolved`, `unavailable` und `count` werden zentral unterschieden
|
||||
- keine konkreten Tippfehlerlisten wie `kpstet` / `ksotet`
|
||||
|
||||
Nicht vollständig ausführbar in dieser Umgebung:
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
Grund: Die ZIP enthält keine installierten Composer-/Runtime-Dependencies; die lokale Umgebung hat außerdem nicht alle benötigten PHP-Extensions.
|
||||
|
||||
## Pflichtprüfung nach Einspielen
|
||||
|
||||
```bash
|
||||
bin/console cache:clear
|
||||
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
|
||||
```
|
||||
|
||||
Falls OPcache/PHP-FPM aktiv ist, danach PHP-FPM bzw. Container neu laden.
|
||||
|
||||
## Manuelle Regressionstests
|
||||
|
||||
```text
|
||||
shop testomat 808
|
||||
```
|
||||
|
||||
Erwartung: Shop wird angefragt; nach Shop-Routing nicht mehr `Shop-Treffer: nicht angefragt`.
|
||||
|
||||
```text
|
||||
was kpstet der indikator
|
||||
```
|
||||
|
||||
Erwartung: Shop-/Preis-Follow-up greift weiterhin über Normalisierung/Fuzzy-Routing.
|
||||
|
||||
```text
|
||||
welche grenzwerte kann der testomat 808 messen
|
||||
|
||||
die tabelle mit preisen
|
||||
```
|
||||
|
||||
Erwartung: Shop-Suche wird ausgelöst; Query sinngemäß `Testomat 808 indikator`.
|
||||
|
||||
```text
|
||||
die tabelle mit shop preisen
|
||||
```
|
||||
|
||||
Erwartung: Shop-Suche wird ausgelöst, sofern Verlaufskontext vorhanden ist; sonst `Shop-Treffer: keine Suchquery` statt irreführend `nicht angefragt`.
|
||||
@@ -0,0 +1,124 @@
|
||||
# RetrieX Patch p20i – Standalone Shop Query History Isolation
|
||||
|
||||
## Ziel
|
||||
|
||||
Dieser Patch behebt die beobachtete Query-Kontamination bei expliziten Shop-Suchen wie:
|
||||
|
||||
```text
|
||||
shop testomat 808
|
||||
```
|
||||
|
||||
Vor p20i wurde der Shop-Query-Optimizer immer mit dem aktuellen Prompt **und** dem Commerce-Verlauf aufgerufen. Wenn im Verlauf zuvor eine Grenzwert-/Indikatortabelle vorkam, konnte das LLM die eigentlich neue, konkrete Shop-Suche fälschlich zu folgender Query erweitern:
|
||||
|
||||
```text
|
||||
testomat 808 indikator
|
||||
```
|
||||
|
||||
Erwartet ist bei einem expliziten neuen Shop-Prompt:
|
||||
|
||||
```text
|
||||
testomat 808
|
||||
```
|
||||
|
||||
## Ursache im Code
|
||||
|
||||
Die Ursache wurde im realen Codepfad verifiziert:
|
||||
|
||||
- `AgentRunner::buildCommerceHistoryContext()` baut immer den Commerce-Verlauf.
|
||||
- Dieser Verlauf wurde direkt an `buildOptimizedShopQuery()` übergeben.
|
||||
- `AgentRunnerConfig::getShopPrompt()` fügt den Verlauf als `RECENT CONVERSATION CONTEXT` in den LLM-Optimizer-Prompt ein.
|
||||
- Das LLM durfte dadurch alte Kontextanker wie `Indikator` übernehmen, obwohl der aktuelle Prompt mit `shop testomat 808` eine neue konkrete Suche startet.
|
||||
|
||||
## Lösung
|
||||
|
||||
p20i trennt den allgemeinen Commerce-Verlauf vom tatsächlich für die Shop-Query erlaubten Verlauf:
|
||||
|
||||
- Neuer interner Kontext: `$shopQueryHistoryContext`
|
||||
- Für referenzielle Follow-ups bleibt Verlauf erlaubt, z. B.:
|
||||
- `die tabelle mit preisen`
|
||||
- `suche im shop`
|
||||
- `was kostet der indikator`
|
||||
- Für explizite Standalone-Produktqueries mit Modellanker wird der Verlauf aus Optimizer, Preview, Search und Repair entfernt, z. B.:
|
||||
- `shop testomat 808`
|
||||
- `testomat 808 preis`
|
||||
- Zusätzlich schützt `guardStandaloneOptimizedShopQuery()` gegen LLM-Optimizer-Ausgaben, die bei einer Standalone-Modellquery einen nicht im aktuellen Prompt enthaltenen Kontextanker wie `indikator` hinzufügen.
|
||||
|
||||
## Geänderte Dateien
|
||||
|
||||
- `src/Agent/AgentRunner.php`
|
||||
- `src/Config/AgentRunnerConfig.php`
|
||||
- `src/Config/RetriexEffectiveConfigProvider.php`
|
||||
- `config/retriex/agent.yaml`
|
||||
|
||||
## Erwartete Tests
|
||||
|
||||
### Neuer Regressionsfall
|
||||
|
||||
```text
|
||||
shop testomat 808
|
||||
```
|
||||
|
||||
Erwartung:
|
||||
|
||||
- Shop wird angefragt.
|
||||
- Gesendete Suchquery: `testomat 808`
|
||||
- Nicht mehr: `testomat 808 indikator`
|
||||
- Quelle: nur Shopsystem, kein Chatverlauf als aktive Shop-Query-Quelle.
|
||||
|
||||
### Bestehende Follow-up-Fälle müssen weiterhin funktionieren
|
||||
|
||||
```text
|
||||
welche grenzwerte kann der testomat 808 messen
|
||||
die tabelle mit preisen
|
||||
```
|
||||
|
||||
Erwartung:
|
||||
|
||||
- Shop wird weiterhin angefragt.
|
||||
- Verlauf darf verwendet werden.
|
||||
- Query sinngemäß: `Testomat 808 indikator`
|
||||
|
||||
```text
|
||||
Was ist der niedrigste Grenzwert für die Wasserhärte, welcher mit einem Testomaten überwacht werden kann?
|
||||
mit welchem indikator wird der wert gemessen
|
||||
was kpstet der indikator
|
||||
```
|
||||
|
||||
Erwartung:
|
||||
|
||||
- LLM-/Routing-Normalisierung bleibt erhalten.
|
||||
- Referenzieller Indikator-Preis-Follow-up darf weiterhin Verlauf nutzen.
|
||||
|
||||
## Lokale Prüfungen in dieser Umgebung
|
||||
|
||||
Ausgeführt:
|
||||
|
||||
```bash
|
||||
php -l src/Agent/AgentRunner.php
|
||||
php -l src/Config/AgentRunnerConfig.php
|
||||
php -l src/Config/RetriexEffectiveConfigProvider.php
|
||||
python3 -c 'import yaml; yaml.safe_load(open("config/retriex/agent.yaml"))'
|
||||
```
|
||||
|
||||
Nicht ausführbar in dieser Umgebung:
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
Grund: Die hochgeladene ZIP enthält keine installierten Composer-Dependencies (`vendor/`).
|
||||
|
||||
## Pflichtchecks nach Einspielen
|
||||
|
||||
```bash
|
||||
bin/console cache:clear
|
||||
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
|
||||
```
|
||||
|
||||
Bei OPcache/PHP-FPM: PHP-FPM bzw. Container neu laden.
|
||||
@@ -0,0 +1,75 @@
|
||||
# RetrieX Patch p20j - Standalone Shop Optimizer Context Guard
|
||||
|
||||
## Ziel
|
||||
Verhindert, dass die LLM-gestützte Shop-Query-Optimierung bei eigenständigen neuen Shop-Suchen alten oder nicht im aktuellen Prompt enthaltenen Kontext in die Suchquery übernimmt.
|
||||
|
||||
## Reproduzierter Fehler
|
||||
Nach vorherigen Testomat-808-/Indikator-Kontexten wurde bei der neuen Anfrage:
|
||||
|
||||
```text
|
||||
zeige mir Anschlusskabel für pH/Redox
|
||||
```
|
||||
|
||||
als gesendete Shop-Suchquery fälschlich erzeugt:
|
||||
|
||||
```text
|
||||
testomat 808
|
||||
```
|
||||
|
||||
Dadurch lieferte der Shop Testomat-808- und Indikator-Produkte statt Anschlusskabeln für pH/Redox.
|
||||
|
||||
## Ursache
|
||||
Der Shop-Router selbst war nicht mehr das Problem: Shop wurde korrekt angefragt. Der Fehler entstand im Ausgang der LLM-Shop-Query-Optimierung. Bei einem eigenständigen neuen Prompt ohne zulässigen History-Kontext durfte der Optimizer eine Query erzeugen, die keine Token-Überschneidung mit dem aktuellen Prompt hatte und sogar eine Modellnummer enthielt, die im aktuellen Prompt nicht vorkam.
|
||||
|
||||
## Änderung
|
||||
Geändert wurde nur:
|
||||
|
||||
- `src/Agent/AgentRunner.php`
|
||||
|
||||
Neu abgesichert:
|
||||
|
||||
- Bei eigenständigen Shop-Suchen ohne History-Kontext wird die optimierte Query validiert.
|
||||
- Der Optimizer darf Suchbegriffe entfernen oder verdichten.
|
||||
- Er darf aber keine Modell-/Artikelnummern hinzufügen, die nicht im aktuellen Prompt stehen.
|
||||
- Wenn die optimierte Query keinerlei Token-Überschneidung mit dem aktuellen Prompt hat, wird sie als Kontextsubstitution verworfen.
|
||||
- In diesem Fall fällt RetrieX auf den aktuellen Prompt zurück; der vorhandene CommerceQueryParser bereinigt ihn anschließend regulär.
|
||||
|
||||
## Erwartung
|
||||
|
||||
```text
|
||||
zeige mir Anschlusskabel für pH/Redox
|
||||
```
|
||||
|
||||
soll nicht mehr zu `testomat 808` optimiert werden. Erwartbar ist eine Shop-Suchquery im Bereich:
|
||||
|
||||
```text
|
||||
anschlusskabel ph redox
|
||||
```
|
||||
|
||||
oder ein sauber aus dem aktuellen Prompt abgeleiteter äquivalenter Suchtext.
|
||||
|
||||
Bestehende Follow-ups bleiben erlaubt:
|
||||
|
||||
```text
|
||||
die tabelle mit preisen
|
||||
```
|
||||
|
||||
nutzt weiterhin History-Kontext, weil es explizit referenziell ist.
|
||||
|
||||
## Prüfungen lokal
|
||||
|
||||
- `php -l src/Agent/AgentRunner.php` OK
|
||||
|
||||
Symfony-Console-Checks konnten in der ChatGPT-Umgebung nicht vollständig ausgeführt werden, weil die Laufzeit-/Composer-Dependencies nicht installiert sind.
|
||||
|
||||
## Nach dem Einspielen prüfen
|
||||
|
||||
```bash
|
||||
bin/console cache:clear
|
||||
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
|
||||
```
|
||||
|
||||
Falls OPcache/PHP-FPM aktiv ist, PHP-FPM bzw. Container neu laden.
|
||||
@@ -0,0 +1,70 @@
|
||||
# RetrieX Patch p20k - Final Standalone Shop Query Guard
|
||||
|
||||
## Ziel
|
||||
Behebt den Fall, dass eine neue eigenständige Shop-Anfrage wie:
|
||||
|
||||
```text
|
||||
zeige mir Anschlusskabel für pH/Redox
|
||||
```
|
||||
|
||||
nach der Shop-Query-Optimierung fälschlich als alte Kontext-Query wie:
|
||||
|
||||
```text
|
||||
testomat 808 indikator
|
||||
```
|
||||
|
||||
an Shop-Suche und UI-Meta weitergegeben wird.
|
||||
|
||||
## Ursache
|
||||
Der bisherige Guard prüfte den Optimizer-Ausgang zwar im Optimizer-/Resolve-Pfad, aber nicht final direkt vor Preview und Shop-Suche. Wenn später dennoch eine kontextfremde Query in `$shopSearchQuery` landete, wurde sie ungeprüft an `buildSearchQueryPreview()` und `searchShop()` weitergereicht.
|
||||
|
||||
## Änderung
|
||||
Nur `src/Agent/AgentRunner.php` wurde geändert.
|
||||
|
||||
Neu:
|
||||
|
||||
- finale Validierung direkt nach `resolveShopSearchQuery()`
|
||||
- vor `buildSearchQueryPreview()` und `searchShop()`
|
||||
- Wiederverwendung der bestehenden Standalone-Guardlogik
|
||||
- bei erkannter Kontextverschmutzung wird die Query auf den aktuellen Routing-Prompt zurückgesetzt
|
||||
- `$optimizedShopQuery` wird geleert, damit UI/Meta nicht weiter „optimiert“ für eine verworfene Query anzeigen
|
||||
|
||||
## Erwartung
|
||||
|
||||
```text
|
||||
zeige mir Anschlusskabel für pH/Redox
|
||||
```
|
||||
|
||||
soll nicht mehr als `testomat 808 indikator` gesucht werden, sondern auf Basis des aktuellen Prompts, also sinngemäß:
|
||||
|
||||
```text
|
||||
anschlusskabel ph redox
|
||||
```
|
||||
|
||||
Referenzielle Follow-ups wie:
|
||||
|
||||
```text
|
||||
die tabelle mit preisen
|
||||
was kostet der indikator
|
||||
```
|
||||
|
||||
dürfen weiterhin Kontext verwenden.
|
||||
|
||||
## Checks
|
||||
Lokal möglich:
|
||||
|
||||
```bash
|
||||
php -l src/Agent/AgentRunner.php
|
||||
```
|
||||
|
||||
Pflichtchecks nach Einspielen:
|
||||
|
||||
```bash
|
||||
bin/console cache:clear
|
||||
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
|
||||
```
|
||||
|
||||
Falls OPcache/PHP-FPM aktiv ist: PHP-FPM bzw. Container neu laden.
|
||||
@@ -0,0 +1,61 @@
|
||||
# RetrieX Patch p20l - Original Prompt Shop History Guard
|
||||
|
||||
## Ziel
|
||||
Fix fuer die Regression, bei der eine neue Standalone-Shopfrage wie:
|
||||
|
||||
```text
|
||||
zeige mir Anschlusskabel fuer pH/Redox
|
||||
```
|
||||
|
||||
faelschlich mit altem Verlaufskontext optimiert wurde und dadurch als Shop-Suchquery z. B. `testomat 808 indikator` erzeugte.
|
||||
|
||||
## Ursache
|
||||
Der bisherige Guard pruefte die finale Shop-Suchquery gegen den `routingPrompt`. Dieser kann durch LLM-/Fuzzy-Normalisierung leicht vom Original abweichen. Dadurch konnte eine eigentlich neue Standalone-Anfrage intern wie eine referenzielle Anfrage behandelt werden, und alter Commerce-Verlauf durfte in Optimizer/Query einfliessen.
|
||||
|
||||
Besonders kritisch: Die Entscheidung, ob Verlauf fuer die Shop-Query benutzt werden darf, darf nicht von einer normalisierten Variante abhaengen, sondern vom originalen Nutzereingabetext.
|
||||
|
||||
## Aenderung
|
||||
Nur `src/Agent/AgentRunner.php` wurde geaendert.
|
||||
|
||||
1. `resolveShopQueryHistoryContext()` verwendet jetzt den `originalPrompt` als Autoritaet fuer die Entscheidung, ob Commerce-History genutzt werden darf.
|
||||
2. `guardFinalStandaloneShopSearchQuery()` prueft finale Shop-Suchqueries ebenfalls gegen den `originalPrompt`.
|
||||
3. Wenn eine Standalone-Query fremden Kontext einfuehrt, faellt RetrieX auf den aktuellen `routingPrompt` zurueck, nicht auf alten Verlaufskontext.
|
||||
|
||||
## Erwartetes Verhalten
|
||||
|
||||
```text
|
||||
zeige mir Anschlusskabel fuer pH/Redox
|
||||
```
|
||||
|
||||
Erwartete Suchquery sinngemaess:
|
||||
|
||||
```text
|
||||
anschlusskabel ph redox
|
||||
```
|
||||
|
||||
Nicht mehr:
|
||||
|
||||
```text
|
||||
testomat 808 indikator
|
||||
```
|
||||
|
||||
Weiterhin erlaubt:
|
||||
|
||||
```text
|
||||
welche grenzwerte kann der testomat 808 messen
|
||||
die tabelle mit preisen
|
||||
```
|
||||
|
||||
Dieser Follow-up bleibt referenziell und darf den Verlauf fuer `testomat 808 indikator` nutzen.
|
||||
|
||||
## Pflichtchecks nach Einspielen
|
||||
|
||||
```bash
|
||||
bin/console cache:clear
|
||||
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
|
||||
```
|
||||
|
||||
Bei aktivem OPcache/PHP-FPM bitte PHP-FPM bzw. Container neu laden.
|
||||
@@ -0,0 +1,75 @@
|
||||
# RetrieX Patch p20m – Standalone Shop History Authority Fix
|
||||
|
||||
## Ziel
|
||||
Dieser Patch behebt den Fall, dass eine neue eigenständige Shop-Anfrage wie:
|
||||
|
||||
```text
|
||||
zeige mir Anschlusskabel für pH/Redox
|
||||
```
|
||||
|
||||
trotz fehlender Ähnlichkeit zum aktuellen Prompt mit altem Verlaufskontext zu einer falschen Shop-Suchquery wie:
|
||||
|
||||
```text
|
||||
testomat 808 indikator
|
||||
```
|
||||
|
||||
optimiert wurde.
|
||||
|
||||
## Ursache
|
||||
Die Entscheidung, ob Chatverlauf für die Shop-Query-Optimierung verwendet werden darf, wurde im aktiven Codepfad weiterhin anhand des normalisierten/routing-orientierten Prompts getroffen. Dieser Prompt ist für Intent-Erkennung hilfreich, darf aber nicht die Autorität für History-Carry-over sein.
|
||||
|
||||
Zusätzlich konnte der fallback-basierte Query-Resolver nach einer Optimierung nicht konsequent zwischen aktueller Standalone-Anfrage und referenzieller Folgefrage unterscheiden.
|
||||
|
||||
## Änderung
|
||||
Geändert wurde nur:
|
||||
|
||||
- `src/Agent/AgentRunner.php`
|
||||
|
||||
Konkret:
|
||||
|
||||
1. `resolveShopQueryHistoryContext()` entscheidet jetzt anhand des unveränderten `originalPrompt`, ob Shop-History benutzt werden darf.
|
||||
2. `resolveShopSearchQuery()` nutzt den `originalPrompt` als Autorität für referenzielle History-Fallbacks.
|
||||
3. Der normalisierte `routingPrompt` bleibt als Current-Prompt-Fallback erhalten, damit Tippfehlerkorrektur/Normalisierung weiterhin für die aktuelle Suchanfrage genutzt werden kann.
|
||||
4. Der finale Standalone-Guard prüft gegen den `originalPrompt`, nicht gegen den normalisierten Routing-Prompt.
|
||||
|
||||
## Erwartetes Verhalten
|
||||
|
||||
```text
|
||||
zeige mir Anschlusskabel für pH/Redox
|
||||
```
|
||||
|
||||
muss eine Query wie:
|
||||
|
||||
```text
|
||||
anschlusskabel ph redox
|
||||
```
|
||||
|
||||
erzeugen, nicht mehr:
|
||||
|
||||
```text
|
||||
testomat 808 indikator
|
||||
```
|
||||
|
||||
Referenzielle Follow-ups wie:
|
||||
|
||||
```text
|
||||
die tabelle mit preisen
|
||||
```
|
||||
|
||||
behalten weiterhin History-Nutzung.
|
||||
|
||||
## Prüfungen lokal
|
||||
|
||||
- `php -l src/Agent/AgentRunner.php` OK
|
||||
|
||||
Symfony-Console-Checks müssen in der Zielumgebung ausgeführt werden:
|
||||
|
||||
```bash
|
||||
bin/console cache:clear
|
||||
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
|
||||
```
|
||||
|
||||
Bei OPcache/PHP-FPM bitte PHP-FPM bzw. Container neu laden.
|
||||
@@ -0,0 +1,70 @@
|
||||
# RetrieX Patch 20n - Deterministic Standalone Shop Query Fix
|
||||
|
||||
## Purpose
|
||||
Fixes the persistent context leak where a new standalone shop query such as:
|
||||
|
||||
`zeige mir Anschlusskabel für pH/Redox`
|
||||
|
||||
was incorrectly sent to the shop as:
|
||||
|
||||
`testomat 808 indikator`
|
||||
|
||||
## Root cause
|
||||
The issue was not the shop router itself. The route was already commerce/shop. The unsafe part was that standalone shop queries could still pass through the LLM shop-query optimizer. If the optimizer or later query handling revived previous conversation context, an old Testomat/Indikator topic could become the sent Shopware query even though the current prompt had no overlap with it.
|
||||
|
||||
## Fix
|
||||
For non-referential standalone shop queries with no allowed shop-query history context:
|
||||
|
||||
- Skip the LLM shop-query optimizer.
|
||||
- Use the normalized/current prompt deterministically as the shop search source.
|
||||
- Let `ShopSearchService` / `CommerceQueryParser` build the final Store API search text from the current prompt only.
|
||||
- Keep LLM/history optimization enabled for referential follow-ups such as `die tabelle mit preisen` or `was kostet der indikator`.
|
||||
|
||||
## Changed file
|
||||
|
||||
- `src/Agent/AgentRunner.php`
|
||||
|
||||
## Expected behavior
|
||||
|
||||
### Standalone shop query
|
||||
Input:
|
||||
|
||||
`zeige mir Anschlusskabel für pH/Redox`
|
||||
|
||||
Expected sent query:
|
||||
|
||||
`anschlusskabel ph redox` or equivalent current-prompt-only query.
|
||||
|
||||
Must not become:
|
||||
|
||||
`testomat 808 indikator`
|
||||
|
||||
### Explicit product query
|
||||
Input:
|
||||
|
||||
`shop testomat 808`
|
||||
|
||||
Expected sent query:
|
||||
|
||||
`testomat 808`
|
||||
|
||||
### Referential follow-up
|
||||
Input after a Testomat 808 indicator table:
|
||||
|
||||
`die tabelle mit preisen`
|
||||
|
||||
Expected behavior:
|
||||
|
||||
History is still allowed and may resolve to `testomat 808 indikator`.
|
||||
|
||||
## Checks to run after applying
|
||||
|
||||
```bash
|
||||
bin/console cache:clear
|
||||
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
|
||||
```
|
||||
|
||||
If OPcache/PHP-FPM is active, reload PHP-FPM or the container after applying.
|
||||
@@ -0,0 +1,75 @@
|
||||
# RetrieX Patch p20o – Standalone Shop Query Isolation Fix
|
||||
|
||||
## Ziel
|
||||
|
||||
Dieser Patch korrigiert die Fehlleitung neuer Standalone-Shopfragen wie:
|
||||
|
||||
```text
|
||||
zeige mir Anschlusskabel für pH/Redox
|
||||
```
|
||||
|
||||
Diese Anfrage durfte nicht aus altem Chatverlauf zu einer Shop-Suchquery wie `testomat 808 indikator` werden.
|
||||
|
||||
## Ursache
|
||||
|
||||
Der bisherige Schutz war zu indirekt. Sobald der Shop-Query-Pfad einen Verlaufskontext zuließ, konnte der LLM-Shop-Query-Optimizer oder der nachgelagerte Commerce-Parser ältere Kontextanker wieder in eine neue Suchfrage übernehmen.
|
||||
|
||||
Zusätzlich enthielt der Shop-Optimizer-Prompt konkrete Beispiele wie `Indikator 300`, `Testomat 808` und `Testomat 2000`. Diese Beispiele konnten den Optimizer in genau die falsche Richtung biasen.
|
||||
|
||||
Außerdem konnte der Input-Normalizer den Platzhaltertext `normalized user input` wörtlich zurückgeben. Dieser Patch schützt dagegen ebenfalls.
|
||||
|
||||
## Änderungen
|
||||
|
||||
### `src/Agent/AgentRunner.php`
|
||||
|
||||
- Neue Standalone-Shopfragen werden jetzt explizit von History/Optimizer-Kontext isoliert.
|
||||
- Die Entscheidung wird aus dem Originalprompt getroffen, nicht aus dem normalisierten Routing-Prompt.
|
||||
- Nicht-referenzielle Shopfragen verwenden deterministische Query-Erzeugung über den aktuellen Prompt.
|
||||
- Referenzielle Follow-ups wie `die tabelle mit preisen`, `suche im shop` oder `was kostet der indikator` dürfen weiterhin Verlauf nutzen.
|
||||
- Placeholder-Ausgaben des Normalizers wie `normalized user input` werden verworfen und auf den Originalprompt zurückgesetzt.
|
||||
|
||||
### `config/retriex/agent.yaml`
|
||||
|
||||
- Der Normalizer-Prompt enthält keinen `<normalized user input>`-Platzhalter mehr.
|
||||
- Die Normalizer-Regel verbietet, den Platzhaltertext wörtlich auszugeben.
|
||||
- Konkrete Shop-Optimizer-Beispiele `Indikator 300`, `Testomat 808`, `Testomat 2000` wurden aus dem Prompt entfernt.
|
||||
|
||||
## Erwartete manuelle Tests
|
||||
|
||||
```text
|
||||
zeige mir Anschlusskabel für pH/Redox
|
||||
```
|
||||
|
||||
Erwartung: Suchquery sinngemäß `anschlusskabel ph redox`, nicht `testomat 808 indikator`.
|
||||
|
||||
```text
|
||||
shop testomat 808
|
||||
```
|
||||
|
||||
Erwartung: Suchquery `testomat 808`, nicht `testomat 808 indikator`.
|
||||
|
||||
```text
|
||||
welche grenzwerte kann der testomat 808 messen
|
||||
|
||||
die tabelle mit preisen
|
||||
```
|
||||
|
||||
Erwartung: referenzieller Follow-up darf weiter Verlauf nutzen, sinngemäß `testomat 808 indikator`.
|
||||
|
||||
```text
|
||||
was kpstet der indikator
|
||||
```
|
||||
|
||||
Erwartung: Tippfehler-Normalisierung/Fuzzy-Routing bleibt aktiv und darf den vorherigen Indikator-Kontext nutzen.
|
||||
|
||||
## Pflichtchecks
|
||||
|
||||
```bash
|
||||
bin/console cache:clear
|
||||
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
|
||||
```
|
||||
|
||||
Bei OPcache/PHP-FPM bitte PHP-FPM bzw. Container neu laden.
|
||||
@@ -0,0 +1,55 @@
|
||||
# RetrieX Patch p20p - History Product Anchor Follow-up Fix
|
||||
|
||||
## Ziel
|
||||
|
||||
Behebt den Fall, dass kurze Shop-Follow-ups wie `suche im shop` den Produkt-/Modellanker aus dem vorherigen fachlichen Turn nicht mehr sicher übernehmen.
|
||||
|
||||
Beispiel:
|
||||
|
||||
1. `welche grenzwerte kann der testomat 2000 thcl messen`
|
||||
2. `suche im shop`
|
||||
|
||||
Vorher konnte die Shop-Suche mit `keine Suchquery` enden, obwohl der vorherige Turn einen klaren Produktanker enthält.
|
||||
|
||||
## Ursache
|
||||
|
||||
Die bisherige Shop-Follow-up-Auflösung nutzte primär extrahierte `Question:`-Zeilen. Wenn diese Extraktion nicht greift oder der stabile Produktanker nur in der Antwort bzw. im gesamten letzten Turn steht, wurde keine belastbare Shopquery erzeugt.
|
||||
|
||||
Außerdem erkannte der Testomat-Modellanker bisher numerische Testomat-Modelle ohne nachgestellten Varianten-/Parameter-Suffix. Dadurch wurde `Testomat 2000 THCL` nicht als kompletter Modellanker erfasst.
|
||||
|
||||
## Änderung
|
||||
|
||||
- `AgentRunner::extractContextualShopSearchQuery()` wurde gehärtet.
|
||||
- Wenn aus den letzten Nutzerfragen keine Query entsteht, werden die neuesten History-Turns selbst geprüft.
|
||||
- Pro Turn wird zuerst die Nutzerfrage ausgewertet.
|
||||
- Danach wird ein expliziter Testomat-Modellanker aus dem gesamten Turn extrahiert.
|
||||
- Das Modellanker-Pattern erlaubt nun numerische Testomat-Modelle mit Suffix, z. B. `Testomat 2000 THCL`.
|
||||
|
||||
## Dateien
|
||||
|
||||
- `src/Agent/AgentRunner.php`
|
||||
- `config/retriex/agent.yaml`
|
||||
|
||||
## Erwartung
|
||||
|
||||
`suche im shop` nach einem technischen Turn zu `Testomat 2000 THCL` soll eine Shopquery wie `testomat 2000 thcl` ableiten, statt mit `keine Suchquery` abzubrechen.
|
||||
|
||||
Der Fix ist generisch für History-Produktanker und enthält keine harte 808- oder THCL-Sonderquery.
|
||||
|
||||
## Prüfungen lokal
|
||||
|
||||
- `php -l src/Agent/AgentRunner.php`: OK
|
||||
- `config/retriex/agent.yaml` mit Python YAML Parser: OK
|
||||
- Regex-Smoke-Test für `Testomat 2000 THCL`, `Testomat 808`, `Testomat EVO TH`: OK
|
||||
|
||||
## Nach dem Einspielen prüfen
|
||||
|
||||
```bash
|
||||
bin/console cache:clear
|
||||
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
|
||||
```
|
||||
|
||||
PHP-FPM/OPcache danach neu laden, falls aktiv.
|
||||
173
patch_history/RETRIEX_PATCH_20_LLM_INPUT_NORMALIZATION_README.md
Normal file
173
patch_history/RETRIEX_PATCH_20_LLM_INPUT_NORMALIZATION_README.md
Normal file
@@ -0,0 +1,173 @@
|
||||
# RetrieX Patch 20 - LLM-assisted Input Normalization before Routing
|
||||
|
||||
## Ziel
|
||||
|
||||
Patch 20 ersetzt den p19-Symptom-Fix fuer einzelne Preis-Tippfehler (`kpstet`, `ksotet`) durch eine generische, LLM-gestuetzte Eingabe-Normalisierung vor der Intent-/Commerce-/Retrieval-Erkennung.
|
||||
|
||||
Der Ausloeser war der Flow:
|
||||
|
||||
1. `Was ist der niedrigste Grenzwert fuer die Wasserhaerte, welcher mit einem Testomaten ueberwacht werden kann?`
|
||||
2. `mit welchem indikator wird der wert gemessen`
|
||||
3. `was kpstet der indikator`
|
||||
|
||||
p19 konnte diesen konkreten Tippfehler per YAML-Liste auffangen, skaliert aber nicht. p20 normalisiert die Nutzereingabe vorher, z. B. `was kpstet der indikator` -> `was kostet der indikator`, ohne Produktkontext fachlich aufzufuellen.
|
||||
|
||||
## Architektur
|
||||
|
||||
Der Normalisierungsschritt sitzt in `AgentRunner::run()` direkt nach `analyze_request` und vor:
|
||||
|
||||
- URL-/Quellenpruefung
|
||||
- CommerceIntentLite-Erkennung
|
||||
- Knowledge-Retrieval-Prompt-Bau
|
||||
- Shop-Query-Optimierung
|
||||
- finalem PromptBuilder-Aufruf
|
||||
|
||||
Das LLM ist ueber den bereits vorhandenen `final class OllamaClient` angebunden und nutzt analog zur Shop-Query-Optimierung:
|
||||
|
||||
```php
|
||||
foreach ($this->ollamaClient->stream($normalizationPrompt) as $token) {
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
Die Originalfrage bleibt erhalten und wird weiterhin in die Conversation History geschrieben. Die normalisierte Frage wird nur als effektive Eingabe fuer Routing, Intent, Retrieval, Shop-Optimierung und Antwortgenerierung genutzt.
|
||||
|
||||
## Guardrails
|
||||
|
||||
Die Normalisierung darf nur offensichtliche Tippfehler korrigieren. Sie darf nicht fachlich interpretieren.
|
||||
|
||||
Konkrete Schutzmechanismen:
|
||||
|
||||
- YAML-konfigurierbarer Normalizer-Prompt in `config/retriex/agent.yaml`
|
||||
- keine fachliche Kontextauflösung im Normalizer
|
||||
- keine Produktnamen, Modellnummern, Messwerte, Artikelnummern oder Einsatzbereiche hinzufuegen
|
||||
- vage Referenzen wie `der indikator` bleiben vage und werden erst spaeter ueber bestehende Kontextlogik aufgeloest
|
||||
- URL-/Code-aehnliche Eingaben werden uebersprungen
|
||||
- maximale Eingabe-/Ausgabelaenge
|
||||
- maximale Laengenvergroesserung
|
||||
- maximale Token-Zunahme
|
||||
- neue Zahlen in der normalisierten Eingabe werden verworfen
|
||||
- bei Fehlern, leerer Ausgabe oder unsicherem Ergebnis faellt RetrieX auf die Originalfrage zurueck
|
||||
|
||||
## Geaenderte Dateien
|
||||
|
||||
- `src/Agent/AgentRunner.php`
|
||||
- `src/Config/AgentRunnerConfig.php`
|
||||
- `src/Config/RetriexEffectiveConfigProvider.php`
|
||||
- `config/retriex/agent.yaml`
|
||||
- `config/retriex/intent.yaml`
|
||||
- `config/retriex/commerce.yaml`
|
||||
|
||||
## Entfernt aus p19-Symptomlisten
|
||||
|
||||
Die expliziten Tippfehler `kpstet` und `ksotet` wurden entfernt aus:
|
||||
|
||||
- `intent.yaml` strong/non-product/price/explicit-commerce Listen
|
||||
- `commerce.yaml` stopword- und correction-Listen
|
||||
|
||||
Damit ist p20 nicht mehr auf diese konkreten Fehlerlisten angewiesen.
|
||||
|
||||
## Erwartetes Verhalten
|
||||
|
||||
Eingabe:
|
||||
|
||||
```text
|
||||
was kpstet der indikator
|
||||
```
|
||||
|
||||
Interne Normalisierung:
|
||||
|
||||
```text
|
||||
was kostet der indikator
|
||||
```
|
||||
|
||||
Danach sollte der bestehende Commerce-/Shop-Follow-up-Flow greifen:
|
||||
|
||||
- Commerce Intent wird erkannt
|
||||
- Shop-Suche wird angefragt
|
||||
- referenzieller Kontext `Indikatortyp 300` kann durch bestehende Shop-Query-Context-Anchor-Logik ergaenzt werden
|
||||
|
||||
## Lokal ausgefuehrte Pruefungen
|
||||
|
||||
Im Container ausgefuehrt:
|
||||
|
||||
```bash
|
||||
php -l src/Agent/AgentRunner.php
|
||||
php -l src/Config/AgentRunnerConfig.php
|
||||
php -l src/Config/RetriexEffectiveConfigProvider.php
|
||||
python3 - <<'PY'
|
||||
import yaml
|
||||
from pathlib import Path
|
||||
for rel in ['config/retriex/agent.yaml','config/retriex/intent.yaml','config/retriex/commerce.yaml']:
|
||||
with (Path('.') / rel).open() as f:
|
||||
yaml.safe_load(f)
|
||||
PY
|
||||
php -r '$patterns=["/^(?:normalisiert|korrigiert|corrected|normalized)\\s*:\\s*/iu","/https?:\\/\\//iu","/\\bwww\\./iu","/```/u"]; foreach($patterns as $p){ if(@preg_match($p, "was kpstet der indikator")===false){ exit(1); } } echo "OK\n";'
|
||||
grep -R "kpstet\|ksotet" -n config src || true
|
||||
```
|
||||
|
||||
Ergebnis:
|
||||
|
||||
- PHP-Syntax: OK
|
||||
- YAML-Parse: OK
|
||||
- Regex-Smoke-Test: OK
|
||||
- `kpstet` / `ksotet`: nicht mehr in `config` oder `src`
|
||||
|
||||
## Nicht lokal ausfuehrbar
|
||||
|
||||
Die Symfony-/Composer-basierten Pflichtchecks konnten im Container nicht ausgefuehrt werden, weil im ZIP keine installierten Vendor-Dependencies enthalten sind.
|
||||
|
||||
Bitte nach dem Einspielen ausfuehren:
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
## Empfohlene Regressionstests
|
||||
|
||||
1. Stabiler v1.5.1-Flow:
|
||||
|
||||
```text
|
||||
Was ist der niedrigste Grenzwert fuer die Wasserhaerte, welcher mit einem Testomaten ueberwacht werden kann?
|
||||
mit welchem indikator wird der wert gemessen
|
||||
was kostet der indikator
|
||||
```
|
||||
|
||||
2. Tippfehler-Flow:
|
||||
|
||||
```text
|
||||
Was ist der niedrigste Grenzwert fuer die Wasserhaerte, welcher mit einem Testomaten ueberwacht werden kann?
|
||||
mit welchem indikator wird der wert gemessen
|
||||
was kpstet der indikator
|
||||
```
|
||||
|
||||
Erwartung fuer beide Preisfragen:
|
||||
|
||||
- Shop-Suche wird angefragt
|
||||
- Shop-Treffer werden genutzt
|
||||
- keine Rueckkehr in RAG-only mit Testomat-2000-Indikatoren
|
||||
|
||||
3. Guardrail-Test:
|
||||
|
||||
```text
|
||||
was kpstet der indikator 300
|
||||
```
|
||||
|
||||
Erwartung:
|
||||
|
||||
- Normalisierung darf `300` erhalten
|
||||
- keine neue Modellnummer / Artikelnummer hinzufuegen
|
||||
|
||||
4. URL-Skip-Test:
|
||||
|
||||
```text
|
||||
pruefe https://example.com/test?x=kpstet
|
||||
```
|
||||
|
||||
Erwartung:
|
||||
|
||||
- Normalisierung wird uebersprungen
|
||||
- URL bleibt unveraendert
|
||||
@@ -0,0 +1,36 @@
|
||||
# RetrieX Patch 21 - Language Cleanup Profiles groundwork
|
||||
|
||||
## Goal
|
||||
|
||||
Prepare RetrieX 1.5.3 for simpler, centralized language cleanup without changing runtime behavior yet.
|
||||
|
||||
## Changes
|
||||
|
||||
- Extends `config/retriex/language.yaml` additively.
|
||||
- Keeps legacy `retriex.stopwords.config.words` unchanged.
|
||||
- Adds central groups for protected terms, German core stopwords, conversation noise, user instruction phrases, presentation/meta terms, and cleanup profiles.
|
||||
- Introduces initial profiles: `commerce_query`, `rag_evidence`, `shop_context_fallback`.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- No external stopword library.
|
||||
- No Commerce/Agent runtime wiring yet.
|
||||
- No removal of existing lists in `commerce.yaml`, `agent.yaml`, or `retrieval.yaml`.
|
||||
- No domain-specific special cases.
|
||||
|
||||
## Install
|
||||
|
||||
Copy the files from this patch over the current RetrieX root.
|
||||
|
||||
```bash
|
||||
unzip retriex-p21-language-cleanup-profiles-patch-only.zip -d /path/to/retriex
|
||||
cd /path/to/retriex
|
||||
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
|
||||
```
|
||||
|
||||
## Expected result
|
||||
|
||||
All checks should remain green. This patch should not change answers yet.
|
||||
@@ -0,0 +1,33 @@
|
||||
# RetrieX Patch p22 - Language Cleanup Config Resolver
|
||||
|
||||
## Ziel
|
||||
|
||||
p22 fuehrt die technische Zugriffsschicht fuer die in p21 angelegte zentrale Sprachbereinigung ein.
|
||||
|
||||
## Inhalt
|
||||
|
||||
- Neue Config-Fassade: `src/Config/LanguageCleanupConfig.php`
|
||||
- Service-Registrierung in `config/services.yaml`
|
||||
- Audit-Mapping in `ConfigSourceAuditProvider`
|
||||
- Resolver fuer:
|
||||
- Cleanup-Profile
|
||||
- Stopwords je Profil
|
||||
- Phrasen je Profil
|
||||
- Meta-Terms je Profil
|
||||
- Protected Terms je Profil
|
||||
|
||||
## Wichtig
|
||||
|
||||
- Keine Commerce-/Agent-Runtime-Umschaltung in diesem Patch.
|
||||
- Bestehende Stopword-Logik bleibt kompatibel.
|
||||
- Protected Terms werden bei Profil-Stopwords nicht entfernt/ausgegeben.
|
||||
- Keine externe Stopword-Library.
|
||||
|
||||
## Checks
|
||||
|
||||
```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
|
||||
```
|
||||
@@ -0,0 +1,26 @@
|
||||
# RetrieX Patch 23 - Commerce Cleanup Profile Wiring
|
||||
|
||||
## Ziel
|
||||
|
||||
Commerce nutzt erstmals das zentrale Language-Cleanup-Profil `commerce_query`.
|
||||
|
||||
## Änderungen
|
||||
|
||||
- `config/retriex/commerce.yaml` erhält `cleanup_profile: commerce_query`.
|
||||
- `CommerceQueryParserConfig` liest den Profilnamen aus YAML.
|
||||
- `CommerceQueryParser` kombiniert Profil-Phrasen/Stopwords mit den bestehenden Legacy-Listen.
|
||||
- `phrases_to_remove` und `filter_search_tokens` bleiben bewusst erhalten.
|
||||
- `RetriexEffectiveConfigProvider` validiert, dass das referenzierte Profil existiert.
|
||||
|
||||
## Wichtig
|
||||
|
||||
Dieser Patch entfernt noch keine alten Listen. Er verdrahtet nur die neue zentrale Struktur mit Commerce.
|
||||
|
||||
## Pflichtchecks
|
||||
|
||||
```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
|
||||
```
|
||||
@@ -0,0 +1,14 @@
|
||||
# RetrieX Patch p24 - Agent RAG Evidence Cleanup Profile
|
||||
|
||||
## Goal
|
||||
Wire the Agent RAG evidence guard to the central `rag_evidence` cleanup profile from `language.yaml`.
|
||||
|
||||
## Scope
|
||||
- Adds `rag_evidence_guard.cleanup_profile: rag_evidence` to `config/retriex/agent.yaml`.
|
||||
- Merges profile stopwords with existing legacy `rag_evidence_guard.stop_terms` at runtime.
|
||||
- Keeps all legacy stop terms in place.
|
||||
- Adds config validation for the referenced cleanup profile.
|
||||
|
||||
## Safety
|
||||
No legacy lists are removed in this patch.
|
||||
No Commerce, Shop fallback, Retrieval scoring, or Prompt logic is changed.
|
||||
@@ -0,0 +1,13 @@
|
||||
# RetrieX Patch p25b - Shop Context Fallback Cleanup Profile Hotfix
|
||||
|
||||
## Goal
|
||||
Fix p25 validation failure when `agent.shop_prompt.meta_query_guard.cleanup_profile` is missing in partially updated environments.
|
||||
|
||||
## Scope
|
||||
- Keeps `cleanup_profile: shop_context_fallback` in `config/retriex/agent.yaml`.
|
||||
- Adds a migration-safe fallback in `AgentRunnerConfig::getShopQueryContextFallbackCleanupProfile()`.
|
||||
- Keeps the actual value YAML-owned; the fallback only prevents failed intermediate states.
|
||||
|
||||
## Safety
|
||||
No legacy lists are removed.
|
||||
No Commerce, Retrieval scoring, Prompt wording, or shop matching logic is changed.
|
||||
@@ -0,0 +1,13 @@
|
||||
# RetrieX Patch p25c - Shop Context Fallback Cleanup Profile Validation Fix
|
||||
|
||||
## Goal
|
||||
Fix the p25/p25b validation failure for `agent.shop_prompt.meta_query_guard.cleanup_profile`.
|
||||
|
||||
## Scope
|
||||
- Keeps the YAML-owned value `shop_context_fallback` in `config/retriex/agent.yaml`.
|
||||
- Keeps the runtime wiring from p25.
|
||||
- Makes validation migration-safe: if the YAML value is missing in an already partially updated environment, validation uses the configured fallback from `AgentRunnerConfig` instead of failing with an empty-string error.
|
||||
|
||||
## Safety
|
||||
No legacy lists are removed.
|
||||
No Commerce, Retrieval scoring, Prompt wording, or shop matching logic is changed.
|
||||
@@ -0,0 +1,14 @@
|
||||
# RetrieX Patch p25 - Shop Context Fallback Cleanup Profile
|
||||
|
||||
## Goal
|
||||
Wire the Shop context fallback/meta guard to the central `shop_context_fallback` cleanup profile from `language.yaml`.
|
||||
|
||||
## Scope
|
||||
- Adds `shop_prompt.meta_query_guard.cleanup_profile: shop_context_fallback` to `config/retriex/agent.yaml`.
|
||||
- Merges central profile stopwords, user-instruction phrases and presentation meta terms with the existing legacy meta/fallback lists.
|
||||
- Keeps all legacy lists in place.
|
||||
- Adds config validation for the referenced cleanup profile.
|
||||
|
||||
## Safety
|
||||
No legacy lists are removed in this patch.
|
||||
No Commerce, Retrieval scoring, Prompt wording, or shop matching logic is changed.
|
||||
@@ -0,0 +1,25 @@
|
||||
# RetrieX Patch 26 - Language Cleanup YAML Dedup
|
||||
|
||||
Purpose: simplify the maintenance layer after p21-p25.
|
||||
|
||||
Changes:
|
||||
|
||||
- Removes duplicate generic language noise from legacy Commerce/Agent lists when the terms are already supplied by `language.yaml` cleanup profiles.
|
||||
- Keeps all domain-specific, commerce-specific and regression-sensitive tokens in their original domain configs.
|
||||
- Adds comments that mark remaining lists as legacy/domain override lists.
|
||||
- Does not change profile names, service wiring, routing or retrieval logic.
|
||||
|
||||
Guardrails:
|
||||
|
||||
- Do not move protected terms into generic removal logic.
|
||||
- Keep intent/domain terms in their domain YAML files.
|
||||
- Only remove a legacy term when it is covered by an active cleanup profile or clearly duplicated in the same list.
|
||||
|
||||
Required checks:
|
||||
|
||||
```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
|
||||
```
|
||||
@@ -0,0 +1,32 @@
|
||||
# RetrieX Patch 27 - Language Cleanup Regression Guards
|
||||
|
||||
## Ziel
|
||||
|
||||
Absicherung der neuen Language-Cleanup-Profile aus p21-p26, ohne weitere produktive Runtime-Logik umzubauen.
|
||||
|
||||
## Inhalt
|
||||
|
||||
- erweitert `governance.yaml` um prüfbare Language-Cleanup-Guardrails
|
||||
- prüft required Cleanup-Profile:
|
||||
- `commerce_query`
|
||||
- `rag_evidence`
|
||||
- `shop_context_fallback`
|
||||
- prüft repräsentative Pflichtbegriffe je Profil
|
||||
- schützt zentrale Begriffe vor generischem Entfernen, u. a. `nicht`, `kein`, `keine`, `testomat`, `indikator`, `indikatortyp`, `ph`, `rx`, `th`, `tc`, `0,02`
|
||||
- erweitert Config-Dump/Validation um Cleanup-Profile
|
||||
- erweitert `mto:agent:regression:test` um Language-Cleanup-Checks
|
||||
|
||||
## Einspielen
|
||||
|
||||
```bash
|
||||
unzip -o p27.zip -d /path/to/retriex
|
||||
cd /path/to/retriex
|
||||
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
|
||||
```
|
||||
|
||||
## Hinweis
|
||||
|
||||
Dieser Patch loescht keine Listen und aendert keine fachliche Runtime-Entscheidung. Er macht die neue Cleanup-Schicht regressionssicherer.
|
||||
@@ -0,0 +1,22 @@
|
||||
# RetrieX Patch 28 - Language Cleanup Documentation
|
||||
|
||||
Purpose: document the new Language Cleanup Profile ownership rules for RetrieX 1.5.3+.
|
||||
|
||||
Changes:
|
||||
|
||||
- adds `RETRIEX_LANGUAGE_CLEANUP_GUIDE.md`
|
||||
- extends `DEVELOPER_POLICIES.md` with language cleanup ownership rules
|
||||
- no runtime code changes
|
||||
- no YAML value changes
|
||||
- no list deletion
|
||||
|
||||
Install:
|
||||
|
||||
```bash
|
||||
unzip -o p28.zip -d /path/to/retriex
|
||||
cd /path/to/retriex
|
||||
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
|
||||
```
|
||||
@@ -0,0 +1,25 @@
|
||||
# RetrieX Patch p35 - Hardcoded List Externalization
|
||||
|
||||
Ziel: PHP-Code besitzt keine fachlichen, sprachlichen, Intent-, Commerce-, Prompt- oder UI-Aktionslisten mehr an den betroffenen Stellen. PHP fuehrt nur Logik aus; aenderbare Listen/Texte liegen in YAML.
|
||||
|
||||
## Externalisiert
|
||||
|
||||
- `config/retriex/language.yaml`
|
||||
- `normalization.ascii_transliteration`
|
||||
- `config/retriex/agent.yaml`
|
||||
- `input_normalization.placeholder_outputs`
|
||||
- `followup_actions.commerce`
|
||||
- `followup_actions.knowledge`
|
||||
- `config/retriex/retrieval.yaml`
|
||||
- `exact_selection_token_variant_suffixes`
|
||||
|
||||
## Angepasste PHP-Stellen
|
||||
|
||||
- `AgentRunner` liest Placeholder, Folgeaktionen und Transliteration aus Config.
|
||||
- `IntentLite`, `SalesIntentLite`, `FormatText` nutzen die YAML-Transliteration.
|
||||
- `NdjsonHybridRetriever` und `NdjsonChunkLookup` lesen Suffixvarianten aus Retrieval-Config.
|
||||
- Config-/Effective-Config-Provider wurden um die neuen Pfade erweitert.
|
||||
|
||||
## Bewusst nicht externalisiert
|
||||
|
||||
Technische Listen bleiben im Code, z. B. HTTP-Methoden, Statuswerte, DB-/API-Feldnamen, Zeilenumbrueche, interne Placeholder fuer String-Templates und reine Trennzeichenlisten.
|
||||
@@ -0,0 +1,36 @@
|
||||
# RetrieX Patch p38b - Language Cleanup Required Term Hotfix
|
||||
|
||||
## Zweck
|
||||
|
||||
Kleiner Hotfix auf p38. Die Config-/Regression-Validierung erwartet den Pflichtbegriff `dieser` in den effektiven Stopword-Listen der Cleanup-Profile:
|
||||
|
||||
- `commerce_query`
|
||||
- `rag_evidence`
|
||||
- `shop_context_fallback`
|
||||
|
||||
p38 hatte die YAML-Externalisierung korrekt umgesetzt, aber diesen Guardrail-Begriff nicht in einer von allen drei Profilen genutzten Stopword-Gruppe bereitgestellt.
|
||||
|
||||
## Änderung
|
||||
|
||||
`config/retriex/language.yaml`
|
||||
|
||||
- `dieser` wurde in `stopword_groups.de_core` ergänzt.
|
||||
- Dadurch ist der Begriff automatisch in allen drei betroffenen Profilen enthalten, weil sie `de_core` referenzieren.
|
||||
|
||||
## Nicht geändert
|
||||
|
||||
- Keine PHP-Runtime-Logik.
|
||||
- Keine neuen PHP-Core-Listen.
|
||||
- Keine Retrieval-/Ranking-/Prompt-Logik.
|
||||
- Keine fachliche Sonderlogik.
|
||||
|
||||
## Prüfhinweis
|
||||
|
||||
Nach Einspielen erneut ausführen:
|
||||
|
||||
```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
|
||||
```
|
||||
@@ -0,0 +1,123 @@
|
||||
# RetrieX Patch p38 - YAML Externalization Hardening
|
||||
|
||||
## Ziel
|
||||
|
||||
Dieser Patch schliesst die nach p37 verbliebenen sinnvollen YAML-Externalization-Luecken im PHP-Core. Fokus ist nicht technische Infrastruktur, sondern fachliche, sprachliche und UI-nahe Listen, Tokens, Vergleichswerte, Prompt-Regeln und Normalisierungsregeln.
|
||||
|
||||
Die Leitlinie bleibt:
|
||||
|
||||
- keine neuen Token-/Stringlisten im PHP-Core
|
||||
- fachliche, sprachliche und UI-nahe Werte ueber YAML
|
||||
- bestehende 1.5.3-Logik nicht fachlich veraendern
|
||||
- keine neuen Spezialfaelle fuer konkrete Produkte
|
||||
|
||||
## Geaenderte Dateien
|
||||
|
||||
- `config/retriex/agent.yaml`
|
||||
- `config/retriex/language.yaml`
|
||||
- `config/retriex/prompt.yaml`
|
||||
- `src/Config/AgentRunnerConfig.php`
|
||||
- `src/Config/LanguageCleanupConfig.php`
|
||||
- `src/Config/PromptBuilderConfig.php`
|
||||
- `src/Agent/AgentRunner.php`
|
||||
- `src/Agent/PromptBuilder.php`
|
||||
- `src/Knowledge/Retrieval/QueryCleaner.php`
|
||||
- `src/Knowledge/Retrieval/NdjsonLexicalIndexBuilder.php`
|
||||
- `src/Knowledge/Retrieval/NdjsonKeywordRetriever.php`
|
||||
- `src/Knowledge/Retrieval/NdjsonChunkLookup.php`
|
||||
- `src/Knowledge/Retrieval/NdjsonHybridRetriever.php`
|
||||
|
||||
## Inhalt
|
||||
|
||||
### AgentRunner
|
||||
|
||||
Externalisiert wurden insbesondere:
|
||||
|
||||
- Placeholder-Ausgaben der Query-/Input-Normalisierung
|
||||
- Shop-Repair-/Shop-Query-Heartbeat-Meldungen
|
||||
- No-LLM-Produktfeldtexte und Produktzeilen-Templates
|
||||
- Follow-up-Kontextlabels
|
||||
- Production-UI-Stage-Labels
|
||||
- Production-UI-Confidence-Labels
|
||||
- Production-UI-Texte, Templates und Shop-Meta-Labels
|
||||
- Follow-up-Action-Chips fuer Commerce und Knowledge
|
||||
|
||||
Zusaetzlich nutzt der Runner vorhandene Language-Cleanup-Konfiguration fuer ASCII-Transliteration, Separator-Normalisierung und Dash-Normalisierung.
|
||||
|
||||
### Language Cleanup
|
||||
|
||||
`language.yaml` enthaelt nun zusaetzlich zentrale Normalisierungsregeln fuer:
|
||||
|
||||
- Wortseparatoren (`-`, `/`, `_`)
|
||||
- Unicode-Dash-Aequivalente
|
||||
|
||||
`LanguageCleanupConfig` stellt dafuer zentrale Methoden bereit:
|
||||
|
||||
- `replaceWordSeparatorsWithSpace()`
|
||||
- `normalizeDashEquivalents()`
|
||||
|
||||
### PromptBuilder
|
||||
|
||||
Externalisiert wurden verbliebene Prompt-/Policy-Regeln rund um:
|
||||
|
||||
- Fallback-Escalation bei vorhandenen Shop-Ergebnissen
|
||||
- Measurement-Evidence-Guard-Templates
|
||||
- finale Measurement-Evidence-Regeln
|
||||
- Parameter-Split-Pattern
|
||||
- Parameter-Trim-Zeichen
|
||||
|
||||
Die Unicode-Dash-Normalisierung nutzt nun ebenfalls `LanguageCleanupConfig`.
|
||||
|
||||
### Retrieval-Normalisierung
|
||||
|
||||
Wiederholte Separatorlisten in Retrieval-Klassen wurden durch die zentrale Language-Cleanup-Methode ersetzt.
|
||||
|
||||
Betroffen:
|
||||
|
||||
- `QueryCleaner`
|
||||
- `NdjsonLexicalIndexBuilder`
|
||||
- `NdjsonKeywordRetriever`
|
||||
- `NdjsonChunkLookup`
|
||||
- `NdjsonHybridRetriever`
|
||||
|
||||
## Bewusst nicht externalisiert
|
||||
|
||||
Nicht Ziel dieses Patches waren rein technische Infrastrukturwerte, z. B.:
|
||||
|
||||
- Boolean-Parser-Werte wie `true`, `false`, `yes`, `no`, `on`, `off`
|
||||
- technische Statuscodes und interne State-Keys
|
||||
- DTO-/Array-Schluessel
|
||||
- Log-/HTTP-/Encoding-Infrastruktur
|
||||
- Zeilenumbruch-Normalisierung
|
||||
|
||||
Diese Werte sind keine fachlichen oder sprachlichen Matching-/Prompt-/UI-Listen.
|
||||
|
||||
## Lokale Validierung
|
||||
|
||||
Da im ZIP kein `vendor/` enthalten ist, konnten Symfony-Console-Checks nicht direkt ausgefuehrt werden.
|
||||
|
||||
Durchgefuehrt wurden:
|
||||
|
||||
- `php -l` fuer alle geaenderten PHP-Dateien: OK
|
||||
- YAML-Parse fuer geaenderte YAML-Dateien: OK
|
||||
- statische Greps auf die zuvor identifizierten Reststellen: OK
|
||||
|
||||
Gepruefte ehemalige Problemklassen:
|
||||
|
||||
- keine PHP-Funde mehr fuer `normalized user input` / `corrected user input`
|
||||
- keine PHP-Funde mehr fuer die harten Measurement-Evidence-Regeltexte
|
||||
- keine PHP-Funde mehr fuer die alten Separatorlisten `['-', '/', '_']`
|
||||
- keine PHP-Funde mehr fuer die alten Unicode-Dash-Listen
|
||||
- keine PHP-Funde mehr fuer die AgentRunner-UI-Labels wie `RetrieX-Status`, `Datenbasis`, `Folgeaktionen`, `Artikelnummer`, `Preis`, `Verfuegbarkeit`, `Relevanz`
|
||||
|
||||
## Empfohlene Checks nach Einspielen
|
||||
|
||||
Bitte im echten Projekt mit installiertem `vendor/` ausfuehren:
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
@@ -0,0 +1,96 @@
|
||||
# RetrieX Patch 4: Query Enrichment and Search Repair YAML-only
|
||||
|
||||
This patch continues the YAML-as-source-of-truth migration.
|
||||
|
||||
## Scope
|
||||
|
||||
Changed areas only:
|
||||
|
||||
- `src/Config/QueryEnricherConfig.php`
|
||||
- `src/Config/SearchRepairConfig.php`
|
||||
- `config/retriex/query_enrichment.yaml`
|
||||
- `config/retriex/search_repair.yaml`
|
||||
- `config/retriex/vocabulary.yaml`
|
||||
- `config/services.yaml`
|
||||
|
||||
No retrieval scoring, PromptBuilder, ShopService matching, AgentRunner, SSE, or answer-generation behavior was intentionally changed.
|
||||
|
||||
## QueryEnricherConfig
|
||||
|
||||
Removed the PHP fallback mapping `DEFAULT_ENRICH_QUERY_LIST`.
|
||||
|
||||
The existing values are now required in:
|
||||
|
||||
```yaml
|
||||
config/retriex/query_enrichment.yaml
|
||||
parameters:
|
||||
retriex.query_enrichment.config:
|
||||
max_expansions: 4
|
||||
rules: ...
|
||||
```
|
||||
|
||||
Missing, invalid, or empty YAML now fails closed via `InvalidArgumentException` instead of silently falling back to PHP defaults.
|
||||
|
||||
## SearchRepairConfig
|
||||
|
||||
Removed PHP fallback constants and hardcoded fallback values for:
|
||||
|
||||
- generic candidate tokens
|
||||
- accessory candidate terms
|
||||
- accessory/bundle terms
|
||||
- specificity boost terms
|
||||
- requested accessory-code behavior
|
||||
- model-candidate patterns
|
||||
- search-repair scoring values
|
||||
- normalization patterns
|
||||
- trim character set
|
||||
- product-key separator
|
||||
- top-product log limit
|
||||
|
||||
The active search-repair settings now live in:
|
||||
|
||||
```yaml
|
||||
config/retriex/search_repair.yaml
|
||||
```
|
||||
|
||||
Vocabulary-backed search-repair term views remain in:
|
||||
|
||||
```yaml
|
||||
config/retriex/vocabulary.yaml
|
||||
parameters:
|
||||
retriex.vocabulary.config:
|
||||
views:
|
||||
search_repair: ...
|
||||
```
|
||||
|
||||
`SearchRepairConfig` now resolves term lists from explicit per-service YAML keys first, otherwise from the configured vocabulary view. If neither exists, it fails closed.
|
||||
|
||||
## Validation performed in the artifact workspace
|
||||
|
||||
PHP syntax checks passed for:
|
||||
|
||||
```bash
|
||||
php -l src/Config/QueryEnricherConfig.php
|
||||
php -l src/Config/SearchRepairConfig.php
|
||||
php -l src/Config/RetriexEffectiveConfigProvider.php
|
||||
```
|
||||
|
||||
Full Symfony commands were not executed in this ZIP workspace because `vendor/` is not included.
|
||||
|
||||
Recommended runtime checks after applying the patch:
|
||||
|
||||
```bash
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:config:dump-effective --json
|
||||
php bin/console mto:agent:config:audit-source --details
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
|
||||
Regression focus:
|
||||
|
||||
- Testomat 808 / 0,02 °dH
|
||||
- Indikatortyp 300 follow-up
|
||||
- Indikator price follow-up
|
||||
- `welcher pockettester ist für Redox messung gut` → `suche im shop`
|
||||
- product-selection shop fallback for free chlorine
|
||||
- SSE completion watchdog behavior
|
||||
@@ -0,0 +1,28 @@
|
||||
# RetrieX Patch 4 Hotfix: SearchRepair pattern-template validation
|
||||
|
||||
This hotfix fixes an overly strict placeholder validation in `SearchRepairConfig`.
|
||||
|
||||
## Problem
|
||||
|
||||
Patch 4 moved SearchRepair patterns to YAML. The new validator rejected every rendered template that still contained a `{` character. This also rejected valid regex quantifiers such as `\d{1,5}`.
|
||||
|
||||
Symfony error example:
|
||||
|
||||
```text
|
||||
RetrieX search repair pattern template "patterns.accessory_candidate_template" contains unresolved placeholders.
|
||||
```
|
||||
|
||||
## Fix
|
||||
|
||||
The validator now only treats named placeholders like `{terms}` or `{model}` as unresolved. Regex quantifiers such as `{1,5}` remain valid.
|
||||
|
||||
No retrieval, prompt, shop, scoring, or SearchRepair behavior is changed.
|
||||
|
||||
## After applying
|
||||
|
||||
```bash
|
||||
php bin/console cache:clear
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:config:audit-source --details
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
@@ -0,0 +1,72 @@
|
||||
# RetrieX Patch 5: CommerceQueryParser YAML-only
|
||||
|
||||
Basis: aktualisierte `rag-inprogress.zip` nach Patch 4.
|
||||
|
||||
## Ziel
|
||||
|
||||
`CommerceQueryParserConfig` darf keine fachlichen PHP-Defaults mehr enthalten. Alle Commerce-Query-Parser-Werte liegen jetzt in YAML unter:
|
||||
|
||||
```yaml
|
||||
retriex.commerce_query.config
|
||||
```
|
||||
|
||||
## Geaenderte Dateien
|
||||
|
||||
- `config/retriex/commerce.yaml`
|
||||
- `config/retriex/vocabulary.yaml`
|
||||
- `config/services.yaml`
|
||||
- `src/Config/CommerceQueryParserConfig.php`
|
||||
- `src/Config/RetriexEffectiveConfigProvider.php`
|
||||
|
||||
## Inhalt
|
||||
|
||||
Nach YAML verschoben wurden:
|
||||
|
||||
- bekannte Marken
|
||||
- zu entfernende Commerce-Phrasen
|
||||
- Filter-/Stop-Tokens fuer Shop-Suchtexte
|
||||
- Suchtoken-Korrekturen
|
||||
- Canonical Maps
|
||||
- semantische Shop-Suchtokens
|
||||
- Normalisierung fuer `€` -> ` euro `
|
||||
- Trim-Zeichen fuer Query-Texte
|
||||
- Limits fuer Tokenlaengen und Suchtextaufbau
|
||||
- Regexe fuer History-Kontext, Preise, Modell-/Zubehoer-Erkennung, Messwerte
|
||||
- Regex-Templates fuer exakte Token-Entfernung und Brand/Model-Erkennung
|
||||
|
||||
## Wichtig
|
||||
|
||||
- `CommerceQueryParserConfig` enthaelt keine `private const` Defaults mehr.
|
||||
- Fehlende Pflichtwerte fallen nicht mehr still auf PHP zurueck, sondern erzeugen einen `InvalidArgumentException`.
|
||||
- Die alten `commerce_query`-Vocabulary-Views/Maps wurden aus `vocabulary.yaml` entfernt, damit nicht zwei YAML-Stellen scheinbar denselben Parser steuern.
|
||||
- `config/services.yaml` injiziert nur noch `%retriex.commerce_query.config%`; die alte Vocabulary-Abhaengigkeit im Parser-Config-Service ist entfernt.
|
||||
|
||||
## Nicht geaendert
|
||||
|
||||
- Retrieval-Scoring
|
||||
- PromptBuilder
|
||||
- AgentRunner
|
||||
- Shop-Matching
|
||||
- SSE/Job-Logik
|
||||
- CommerceIntentConfig
|
||||
|
||||
## Lokale Pruefung nach Einspielen
|
||||
|
||||
```bash
|
||||
php bin/console cache:clear
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:config:audit-source --details
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
|
||||
Besonders pruefen:
|
||||
|
||||
- Testomat 808 / 0,02 Grad dH
|
||||
- Folgefrage Indikatortyp 300
|
||||
- Preisfrage zum Indikator
|
||||
- `welcher pockettester ist fuer Redox messung gut` -> `suche im shop`
|
||||
- `mit welchem testomat kann ich freies chlor messen`
|
||||
|
||||
## Hinweis
|
||||
|
||||
Im ZIP-Arbeitsverzeichnis konnte ich Symfony-Kommandos nicht ausfuehren, weil `vendor/` nicht enthalten ist. PHP-Syntax der geaenderten PHP-Dateien wurde mit `php -l` geprueft.
|
||||
31
patch_history/RETRIEX_PATCH_6_1_AUDIT_GAP_CLEANUP_README.md
Normal file
31
patch_history/RETRIEX_PATCH_6_1_AUDIT_GAP_CLEANUP_README.md
Normal file
@@ -0,0 +1,31 @@
|
||||
# RetrieX Patch 6.1 - Audit Gap Cleanup
|
||||
|
||||
Scope: close the remaining config-source audit gaps that still reported `fallback_accessors_missing_yaml` after Patch 6.
|
||||
|
||||
This patch intentionally does not remove PHP fallbacks yet and does not change runtime logic. It only adds the missing YAML keys with values copied 1:1 from the current PHP defaults so the following accessors have an explicit YAML source:
|
||||
|
||||
- `AgentRunnerConfig::getOptimizedShopQueryTrimCharacters()`
|
||||
- `NdjsonHybridRetrieverConfig` retrieval vocabulary lists
|
||||
- `PromptBuilderConfig::getTechnicalProductKeywords()`
|
||||
- `PromptBuilderConfig::getAccessoryRequestKeywords()`
|
||||
|
||||
Changed files:
|
||||
|
||||
- `config/retriex/agent.yaml`
|
||||
- `config/retriex/retrieval.yaml`
|
||||
- `config/retriex/prompt.yaml`
|
||||
|
||||
Recommended checks after applying:
|
||||
|
||||
```bash
|
||||
php bin/console cache:clear
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:config:audit-source --details
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
|
||||
Expected audit improvement:
|
||||
|
||||
- `fallback_accessors_missing_yaml` should drop from `12` to `0`.
|
||||
|
||||
`constructor_defaults_without_yaml_mapping` may still remain and should be handled separately before strict validation is enabled.
|
||||
@@ -0,0 +1,76 @@
|
||||
# RetrieX Patch 6.2 – Constructor-Default-Audit-Cleanup
|
||||
|
||||
## Ziel
|
||||
|
||||
Dieser Patch bereinigt die verbleibende Audit-Warnung zu Constructor-Defaults, ohne Laufzeitlogik zu ändern.
|
||||
|
||||
Nach Patch 6.1 waren alle Fallback-Accessors YAML-gemappt, aber der Audit meldete weiterhin:
|
||||
|
||||
```text
|
||||
constructor_defaults_without_yaml_mapping: 9
|
||||
```
|
||||
|
||||
Diese 9 Defaults stammen aus `ModelGenerationDefaultsConfig`. Die Werte sind bereits in `config/retriex/model.yaml` vorhanden und werden in `config/services.yaml` als Service-Argumente injiziert. Der Audit kannte dieses Mapping bisher nur nicht.
|
||||
|
||||
## Änderung
|
||||
|
||||
Geändert wurde nur:
|
||||
|
||||
```text
|
||||
src/Config/ConfigSourceAuditProvider.php
|
||||
```
|
||||
|
||||
Ergänzt wurde das Audit-Mapping für:
|
||||
|
||||
```text
|
||||
ModelGenerationDefaultsConfig::$modelName
|
||||
ModelGenerationDefaultsConfig::$stream
|
||||
ModelGenerationDefaultsConfig::$temperature
|
||||
ModelGenerationDefaultsConfig::$topK
|
||||
ModelGenerationDefaultsConfig::$topP
|
||||
ModelGenerationDefaultsConfig::$repeatPenalty
|
||||
ModelGenerationDefaultsConfig::$numCtx
|
||||
ModelGenerationDefaultsConfig::$retrievalMaxChunks
|
||||
ModelGenerationDefaultsConfig::$retrievalVectorTopK
|
||||
```
|
||||
|
||||
auf die bestehenden YAML-Parameter:
|
||||
|
||||
```text
|
||||
retriex.model.default_name
|
||||
retriex.model.default_stream
|
||||
retriex.model.default_temperature
|
||||
retriex.model.default_top_k
|
||||
retriex.model.default_top_p
|
||||
retriex.model.default_repeat_penalty
|
||||
retriex.model.default_num_ctx
|
||||
retriex.model.default_retrieval_max_chunks
|
||||
retriex.model.default_retrieval_vector_top_k
|
||||
```
|
||||
|
||||
## Wichtig
|
||||
|
||||
Dieser Patch entfernt noch keine Constructor-Defaults aus `ModelGenerationDefaultsConfig`.
|
||||
|
||||
Er klassifiziert sie nur korrekt als YAML-/Service-Parameter-gemappt. Die eigentliche Entfernung von PHP-Defaults kann später in der finalen YAML-only-Phase erfolgen.
|
||||
|
||||
## Nach dem Einspielen testen
|
||||
|
||||
```bash
|
||||
php bin/console cache:clear
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:config:audit-source --details
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
|
||||
Erwartung im Audit:
|
||||
|
||||
```text
|
||||
constructor_defaults_without_yaml_mapping: 0
|
||||
```
|
||||
|
||||
Wenn Patch 6.1 bereits eingespielt ist, sollte außerdem weiterhin gelten:
|
||||
|
||||
```text
|
||||
fallback_accessors_missing_yaml: 0
|
||||
```
|
||||
@@ -0,0 +1,32 @@
|
||||
# RetrieX Patch 6 - ShopServiceConfig / Shop Matching YAML-only
|
||||
|
||||
Scope:
|
||||
- Converts `ShopServiceConfig` to YAML-only access.
|
||||
- Removes PHP keyword/scoring/presentation defaults from `ShopServiceConfig`.
|
||||
- Adds required YAML links for shop vocabulary views/maps in `config/retriex/commerce.yaml`.
|
||||
- Keeps existing shop matching behavior values identical to the previous effective defaults.
|
||||
|
||||
Changed files:
|
||||
- `src/Config/ShopServiceConfig.php`
|
||||
- `config/retriex/commerce.yaml`
|
||||
|
||||
Not changed:
|
||||
- PromptBuilder
|
||||
- Retrieval configuration
|
||||
- CommerceQueryParser
|
||||
- ShopSearchService logic
|
||||
- SSE/frontend behavior
|
||||
|
||||
After applying, run:
|
||||
```bash
|
||||
php bin/console cache:clear
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:config:audit-source --details
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
|
||||
Manual regression focus:
|
||||
- `was kostet der indikator`
|
||||
- `welcher pockettester ist für Redox messung gut` -> `suche im shop`
|
||||
- `mit welchem testomat kann ich freies chlor messen`
|
||||
- Testomat 808 / Indikatortyp 300 baseline
|
||||
@@ -0,0 +1,39 @@
|
||||
# RetrieX Patch 7.0a - AgentRunnerConfig basis values YAML-only
|
||||
|
||||
Scope: small first AgentRunnerConfig migration step.
|
||||
|
||||
Changed:
|
||||
- `AgentRunnerConfig` no longer uses PHP fallback defaults for the five simple basis values:
|
||||
- `commerce_history_budget_chars`
|
||||
- `product_search_knowledge_chunk_limit`
|
||||
- `advisory_product_search_knowledge_chunk_limit`
|
||||
- `optimized_shop_query_prefix_pattern`
|
||||
- `optimized_shop_query_trim_characters`
|
||||
- Added required typed accessors for these values.
|
||||
- Missing or invalid YAML values now raise a clear `InvalidArgumentException` instead of silently using PHP fallback defaults.
|
||||
|
||||
Not changed:
|
||||
- Agent messages
|
||||
- source labels
|
||||
- HTML templates
|
||||
- No-LLM fallback texts
|
||||
- shop prompt / meta guard rules
|
||||
- retrieval
|
||||
- PromptBuilder
|
||||
- CommerceQueryParser
|
||||
- Shop matching
|
||||
|
||||
Prerequisite:
|
||||
- Patch 6.1 must already be applied, because it adds `optimized_shop_query_trim_characters` to `config/retriex/agent.yaml`.
|
||||
|
||||
Recommended checks after applying:
|
||||
```bash
|
||||
php bin/console cache:clear
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:config:audit-source --details
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
|
||||
Expected audit direction:
|
||||
- `fallback_accessors` should decrease by 5.
|
||||
- The five basis keys above should no longer appear as `yaml_with_php_fallback` in `AgentRunnerConfig`.
|
||||
@@ -0,0 +1,44 @@
|
||||
# RetrieX Patch 7.0b - AgentRunner messages, labels and HTML YAML-only
|
||||
|
||||
## Scope
|
||||
|
||||
This patch keeps the AgentRunnerConfig migration small and focused. It converts only these AgentRunnerConfig areas from YAML-with-PHP-fallback to YAML-only:
|
||||
|
||||
- runtime/status messages
|
||||
- No-LLM fallback messages and product-role keyword lists
|
||||
- RAG evidence guard stop terms and synonyms
|
||||
- source labels
|
||||
- HTML templates
|
||||
|
||||
It does not change Shop-Prompt, Meta-Guard, context-anchor enrichment, PromptBuilder, Retrieval, CommerceQueryParser, ShopService or SSE logic.
|
||||
|
||||
## Changed file
|
||||
|
||||
- `src/Config/AgentRunnerConfig.php`
|
||||
|
||||
## Expected audit effect
|
||||
|
||||
The following AgentRunner fallback accessors should disappear from `mto:agent:config:audit-source --details`:
|
||||
|
||||
- `messages.*`
|
||||
- `no_llm_fallback.*`
|
||||
- `rag_evidence_guard.*`
|
||||
- `source_labels.*`
|
||||
- `html.*`
|
||||
|
||||
The remaining AgentRunner fallbacks should mostly be the `shop_prompt.*` group, which is intentionally left for Patch 7.0c.
|
||||
|
||||
## Validation
|
||||
|
||||
Run after applying:
|
||||
|
||||
```bash
|
||||
php bin/console cache:clear
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:config:audit-source --details
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
|
||||
## Notes
|
||||
|
||||
No YAML values were changed in this patch. It assumes the existing `config/retriex/agent.yaml` already contains the mapped values, which was confirmed by the previous audit state.
|
||||
@@ -0,0 +1,29 @@
|
||||
# RetrieX Patch 7.0c - AgentRunner Shop-Prompt YAML-only
|
||||
|
||||
Scope:
|
||||
- Converts the remaining AgentRunnerConfig `shop_prompt.*` accessors to required YAML values.
|
||||
- Covers shop prompt rules, labels, language preservation, meta-query guard, context fallback and context anchor enrichment.
|
||||
- Keeps unknown translation replacement languages optional and returns an empty map when a language is not configured.
|
||||
|
||||
Changed files:
|
||||
- src/Config/AgentRunnerConfig.php
|
||||
|
||||
Not changed:
|
||||
- PromptBuilder
|
||||
- Retrieval
|
||||
- CommerceQueryParser
|
||||
- ShopService / Shop matching
|
||||
- SSE / Frontend
|
||||
|
||||
After applying, run:
|
||||
|
||||
```bash
|
||||
php bin/console cache:clear
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:config:audit-source --details
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
|
||||
Expected effect:
|
||||
- AgentRunnerConfig should no longer report `shop_prompt.*` fallback accessors.
|
||||
- Regression baseline should remain green.
|
||||
@@ -0,0 +1,23 @@
|
||||
# RetrieX Patch 8 - CommerceIntentConfig YAML-only
|
||||
|
||||
Scope:
|
||||
- Move `CommerceIntentConfig` lists, regex patterns, labels, and score thresholds to YAML-only access.
|
||||
- Keep `CommerceQueryParser`, `ShopService`, `PromptBuilder`, Retrieval, SSE, and frontend unchanged.
|
||||
|
||||
Changed files:
|
||||
- `config/retriex/intent.yaml`
|
||||
- `src/Config/CommerceIntentConfig.php`
|
||||
- `src/Config/RetriexEffectiveConfigProvider.php`
|
||||
|
||||
After applying, run:
|
||||
|
||||
```bash
|
||||
php bin/console cache:clear
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:config:audit-source --details
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
|
||||
Expected:
|
||||
- `CommerceIntentConfig` fallback accessors disappear from the source audit.
|
||||
- Regression baseline remains green.
|
||||
@@ -0,0 +1,33 @@
|
||||
# RetrieX Patch 9.0a - PromptBuilder basis YAML-only
|
||||
|
||||
This patch converts only the simple PromptBuilder basis, budget and shop-result limit values to required YAML configuration access.
|
||||
|
||||
Changed file:
|
||||
|
||||
- `src/Config/PromptBuilderConfig.php`
|
||||
|
||||
Converted to required YAML-only access:
|
||||
|
||||
- `budget.chars_per_token`
|
||||
- `budget.history_padding_chars`
|
||||
- `budget.output_reserve_ratio`
|
||||
- `budget.output_reserve_min_tokens`
|
||||
- `budget.output_reserve_max_tokens`
|
||||
- `budget.safety_reserve_ratio`
|
||||
- `budget.safety_reserve_min_tokens`
|
||||
- `budget.safety_reserve_max_tokens`
|
||||
- `budget.min_prompt_budget_tokens`
|
||||
- `shop_results.max_results_in_prompt`
|
||||
- `shop_results.detailed_max_count`
|
||||
- `technical_product_keyword_match_threshold`
|
||||
|
||||
No prompt wording rules, fact-grounding rules, retrieval logic, shop logic, AgentRunner logic, or SSE/frontend code is changed.
|
||||
|
||||
After applying, run:
|
||||
|
||||
```bash
|
||||
php bin/console cache:clear
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:config:audit-source --details
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
@@ -0,0 +1,46 @@
|
||||
# RetrieX Patch 9.0b - PromptBuilder Labels and Shop Result Texts YAML-only
|
||||
|
||||
## Scope
|
||||
|
||||
This patch builds on Patch 9.0a.
|
||||
|
||||
It only removes PHP fallback defaults from small PromptBuilder text/label getters:
|
||||
|
||||
- section labels
|
||||
- conversation context intro lines
|
||||
- shop search source line
|
||||
- live shop result header lines
|
||||
- shop product record templates
|
||||
- shop result field labels
|
||||
- retrieved knowledge / URL content labels and source lines
|
||||
|
||||
## Not changed
|
||||
|
||||
This patch does not change:
|
||||
|
||||
- output priority rule texts
|
||||
- fallback escalation rules
|
||||
- response format rules
|
||||
- language rules
|
||||
- fact grounding rules
|
||||
- measurement evidence guard
|
||||
- role guard keyword lists
|
||||
- retrieval
|
||||
- commerce parser
|
||||
- shop matching
|
||||
- AgentRunner
|
||||
- SSE / frontend
|
||||
|
||||
## Expected audit effect
|
||||
|
||||
PromptBuilderConfig should lose the fallback accessor entries for the migrated labels/templates/lists.
|
||||
Remaining PromptBuilder fallback accessors are expected for the larger rule groups that will be handled in later 9.x patches.
|
||||
|
||||
## Test commands
|
||||
|
||||
```bash
|
||||
php bin/console cache:clear
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:config:audit-source --details
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
@@ -0,0 +1,37 @@
|
||||
# RetrieX Patch 9.0c - PromptBuilder Output Priority and Fallback Escalation YAML-only
|
||||
|
||||
Scope:
|
||||
- Converts the next small PromptBuilderConfig rule group to YAML-only.
|
||||
- Requires Patch 9.0b as the previous state.
|
||||
|
||||
Changed:
|
||||
- src/Config/PromptBuilderConfig.php
|
||||
|
||||
YAML-only paths:
|
||||
- output_priority.rules
|
||||
- output_priority.technical_rules
|
||||
- sections.fallback_escalation_label
|
||||
- fallback_escalation.state_line_template
|
||||
- fallback_escalation.base_rules
|
||||
- fallback_escalation.without_shop_check_rules
|
||||
|
||||
Optional path behavior:
|
||||
- fallback_escalation.states.<state> remains optional and returns an empty list when a specific state is not configured.
|
||||
- This is implemented without using the old getStringList(..., []) PHP fallback accessor.
|
||||
|
||||
Not changed:
|
||||
- response_format.*
|
||||
- language.rules
|
||||
- fact_grounding.*
|
||||
- role_guard.*
|
||||
- measurement_evidence_guard.*
|
||||
- Retrieval, Commerce, ShopService, AgentRunner, SSE/frontend
|
||||
|
||||
Validation performed in the patch workspace:
|
||||
- php -n -l src/Config/PromptBuilderConfig.php
|
||||
|
||||
Recommended checks after applying:
|
||||
- php bin/console cache:clear
|
||||
- php bin/console mto:agent:config:validate
|
||||
- php bin/console mto:agent:config:audit-source --details
|
||||
- php bin/console mto:agent:regression:test
|
||||
@@ -0,0 +1,53 @@
|
||||
# RetrieX Patch 9.0e - PromptBuilder Fact-Grounding YAML-only
|
||||
|
||||
## Scope
|
||||
|
||||
This patch builds on Patch 9.0d.
|
||||
|
||||
It only migrates the PromptBuilder fact-grounding rule group to YAML-only accessors:
|
||||
|
||||
- `sections.fact_grounding_rules_label`
|
||||
- `fact_grounding.base_rules`
|
||||
- `fact_grounding.with_shop_rules`
|
||||
- `fact_grounding.without_shop_rules`
|
||||
- `fact_grounding.technical_rules`
|
||||
|
||||
## Included changes
|
||||
|
||||
- `src/Config/PromptBuilderConfig.php`
|
||||
- Removes PHP fallback accessors for the fact-grounding section label and fact-grounding rule lists.
|
||||
- Uses required YAML accessors for the migrated paths.
|
||||
|
||||
- `config/retriex/prompt.yaml`
|
||||
- Adds two fact-grounding base rules that still existed as PHP fallback text but were not present in YAML.
|
||||
|
||||
## Not changed
|
||||
|
||||
This patch does not change:
|
||||
|
||||
- Measurement evidence guard logic
|
||||
- Role guard keywords
|
||||
- Technical product keywords
|
||||
- Accessory request keywords
|
||||
- Retrieval
|
||||
- Commerce
|
||||
- Shop matching
|
||||
- AgentRunner
|
||||
- Frontend/SSE behavior
|
||||
|
||||
## Validation
|
||||
|
||||
Run after applying:
|
||||
|
||||
```bash
|
||||
php bin/console cache:clear
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:config:audit-source --details
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
|
||||
Expected result:
|
||||
|
||||
- Configuration validation remains OK.
|
||||
- Regression baseline remains OK.
|
||||
- PromptBuilderConfig fallback accessors for `fact_grounding.*` disappear from the audit.
|
||||
@@ -0,0 +1,45 @@
|
||||
# RetrieX Patch 9.0f - PromptBuilder Role Guard & Measurement Evidence YAML-only
|
||||
|
||||
## Scope
|
||||
|
||||
This patch continues the PromptBuilder YAML-only migration after Patch 9.0e.
|
||||
|
||||
It converts these remaining PromptBuilder truth/product-role related areas to required YAML configuration:
|
||||
|
||||
- `role_guard.main_device_request_keywords`
|
||||
- `role_guard.main_device_product_keywords`
|
||||
- `role_guard.accessory_product_keywords`
|
||||
- `technical_product_keywords`
|
||||
- `accessory_request_keywords`
|
||||
- `sections.measurement_evidence_label`
|
||||
- `measurement_evidence_guard.intro_rules`
|
||||
- `measurement_evidence_guard.parameters`
|
||||
- `technical_product_model_pattern`
|
||||
|
||||
## Intent
|
||||
|
||||
PHP no longer provides fallback truth for these PromptBuilder areas. If a required YAML value is missing or invalid, `PromptBuilderConfig` now throws a clear `InvalidArgumentException`.
|
||||
|
||||
## Not changed
|
||||
|
||||
This patch does not change:
|
||||
|
||||
- Retrieval logic
|
||||
- Commerce logic
|
||||
- Shop matching
|
||||
- AgentRunner
|
||||
- SSE / frontend
|
||||
- Prompt wording content in YAML
|
||||
|
||||
## Notes
|
||||
|
||||
`measurement_evidence_guard.parameters` is now required to contain at least one valid parameter definition. Individual list fields inside a parameter are still normalized as before to preserve behavior.
|
||||
|
||||
## Recommended checks
|
||||
|
||||
```bash
|
||||
php bin/console cache:clear
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:config:audit-source --details
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
21
patch_history/RETRIEX_PRODUCTION_UI_V1_FIX2_README.txt
Normal file
21
patch_history/RETRIEX_PRODUCTION_UI_V1_FIX2_README.txt
Normal file
@@ -0,0 +1,21 @@
|
||||
RetrieX Production UI v1 - Fix 2
|
||||
|
||||
Zweck:
|
||||
- Behebt die Anzeige von HTML-Badge-Spans als Text in der Datenbasis-Zeile.
|
||||
- Behebt den visuellen Restzustand "Datenbasis wird geprüft" nach abgeschlossenen No-Treffer-Antworten.
|
||||
- Ergaenzt eine finale abgeschlossene RetrieX-Statuskarte nach der Antwortgenerierung.
|
||||
- Markiert die Statuskarte im Frontend beim Streamabschluss defensiv als abgeschlossen.
|
||||
- Markiert die Statuskarte bei Streamfehlern defensiv als unterbrochen.
|
||||
|
||||
Geaenderte Dateien:
|
||||
- src/Agent/AgentRunner.php
|
||||
- public/assets/js/base.js
|
||||
|
||||
Einspielen:
|
||||
- Dieses Hotfix-ZIP ueber den Stand mit Production-UI-v1 einspielen.
|
||||
- Es enthaelt nur die fuer den visuellen Fehler notwendigen Dateien.
|
||||
|
||||
Geprueft:
|
||||
- php -l src/Agent/AgentRunner.php
|
||||
- node --check public/assets/js/base.js
|
||||
- zip integrity test
|
||||
@@ -0,0 +1,19 @@
|
||||
RetrieX Production UI v1 - Fix 3 Card Toggle
|
||||
|
||||
Ziel:
|
||||
- Detail-/Meta-/Shopkarten werden nur angezeigt, wenn der Nutzer dies ueber eine Checkbox aktiviert.
|
||||
- Die Checkbox liegt direkt unter #chat und ist bewusst als Optionsbereich angelegt, damit spaeter weitere Checkboxen ergaenzt werden koennen.
|
||||
|
||||
Geaendert:
|
||||
- public/index.html: neuer Optionsbereich #retriex-chat-options mit Checkbox #toggle-retriex-cards.
|
||||
- public/assets/js/base.js: lokale Persistenz der Kartenanzeige per localStorage retriex:showDetailCards.
|
||||
- public/assets/styles/base.css: Detailkarten werden standardmaessig ausgeblendet und per body-Klasse retriex-show-detail-cards eingeblendet.
|
||||
|
||||
Bewusst nicht geaendert:
|
||||
- Kein Backend-Eingriff.
|
||||
- Keine Aenderung an Retrieval, Shop-Suche, Prompting, SSE, Job-Replay oder History.
|
||||
- Die Karten bleiben im DOM erhalten, werden aber visuell ausgeblendet. Dadurch bleiben Deduplizierung, Stream-Finalisierung und History stabil.
|
||||
|
||||
Hinweis:
|
||||
- Standard ist aus: Detailkarten sind ausgeblendet.
|
||||
- Aktiviert der Nutzer die Checkbox, bleibt diese Einstellung im Browser gespeichert.
|
||||
42
patch_history/RETRIEX_PRODUCTION_UI_V1_README.txt
Normal file
42
patch_history/RETRIEX_PRODUCTION_UI_V1_README.txt
Normal file
@@ -0,0 +1,42 @@
|
||||
RetrieX Production UI v1 Patch
|
||||
================================
|
||||
|
||||
Basis: aktualisierte rag-inprogess.zip aus dem Chat vom 28.04.2026.
|
||||
|
||||
Ziel:
|
||||
- Produktions-UI abrunden, ohne Retrieval-, Scoring-, Prompt-, Job- oder SSE-Replay-Architektur umzubauen.
|
||||
- Vorhandene Badges, Think-Statusmeldungen und Shop-Meta-Cards bleiben erhalten.
|
||||
- Neue UI-Informationen werden als vorhandene HTML-Meta-Cards über den bestehenden Stream ausgegeben.
|
||||
|
||||
Enthaltene Änderungen:
|
||||
- RetrieX-Statuskarte mit RAG-Treffern, Shop-Treffern, Beleglage und Datenbasis.
|
||||
- Laufende Statusstufen: Antwort wird vorbereitet, RAG-Wissen wurde durchsucht, Shop-Suche wird vorbereitet, Shop wird durchsucht, Shop-Suche abgeschlossen, Antwort wird generiert, abgeschlossen.
|
||||
- Deterministische Shopkarten aus ShopProductResult: Name, Artikelnummer, Preis, Verfügbarkeit, Hersteller, Link, Relevanz.
|
||||
- Folgeaktions-Chips: Im Shop suchen, Nur Zubehör anzeigen, Nur Geräte anzeigen, Preis anzeigen, Technische Details anzeigen.
|
||||
- Frontend-Deduplizierung aktualisiert bestehende Meta-Karten an ihrer ersten Position, statt die finale Karte ans Ende zu verschieben.
|
||||
- Context-Hint im Browser ignoriert Meta-/Produkt-/Statuskarten, damit Folgefragen nicht durch UI-Texte verschmutzt werden.
|
||||
- Loader-Text: Antwort wird vorbereitet...
|
||||
|
||||
Geänderte Dateien:
|
||||
- src/Agent/AgentRunner.php
|
||||
- public/assets/js/base.js
|
||||
- public/assets/styles/base.css
|
||||
- config/retriex/agent.yaml
|
||||
|
||||
Bewusst nicht geändert:
|
||||
- Retrieval-/Vector-Logik
|
||||
- Scoring
|
||||
- PromptBuilder-Fachlogik
|
||||
- Shop-Query-Repair-Logik
|
||||
- SSE-Job-Replay-Protokoll
|
||||
- Datenbank/Migrationen
|
||||
|
||||
Durchgeführte Prüfungen:
|
||||
- php -l src/Agent/AgentRunner.php
|
||||
- php -l src/Config/AgentRunnerConfig.php
|
||||
- node --check public/assets/js/base.js
|
||||
- YAML-Parse für config/retriex/agent.yaml
|
||||
- Reflection-Smoke-Test für Statuskarte und Shopproduktkarten
|
||||
|
||||
Hinweis:
|
||||
Der Patch enthält nur die geänderten Dateien. Zum Einspielen im Projektroot entpacken und bestehende Dateien überschreiben.
|
||||
14
patch_history/RETRIEX_PRODUCT_ROLE_GUARD_FIX_README.md
Normal file
14
patch_history/RETRIEX_PRODUCT_ROLE_GUARD_FIX_README.md
Normal file
@@ -0,0 +1,14 @@
|
||||
# RetrieX Product Role Guard Fix
|
||||
|
||||
This patch tightens answer behavior for product-selection questions where the user asks for a main device, Testomat, analyzer, measuring device, system, or similar product role.
|
||||
|
||||
## Goal
|
||||
|
||||
If the user asks for a main device:
|
||||
|
||||
- accessories, indicators, reagents, spare parts, kits, sets, services and consumables must not be used as the main answer heading;
|
||||
- if only accessory/consumable hits are present, the answer must start with a no-match statement for the requested main device;
|
||||
- incompatible accessory records are marked as such in the prompt and their commercial fields are suppressed;
|
||||
- alternative devices must not be suggested unless suitability is explicitly proven in the provided sources.
|
||||
|
||||
The patch does not change retrieval, scoring, Shopware search, SSE, job lifecycle, or AgentRunner orchestration.
|
||||
35
patch_history/RETRIEX_PROMPT_CONFIG_FIX_README.md
Normal file
35
patch_history/RETRIEX_PROMPT_CONFIG_FIX_README.md
Normal file
@@ -0,0 +1,35 @@
|
||||
# RetrieX Prompt Config Centralization Fix
|
||||
|
||||
This patch centralizes PromptBuilder wording and label configuration in `config/retriex/prompt.yaml` while keeping the previous PHP defaults as fallbacks.
|
||||
|
||||
Changed files:
|
||||
|
||||
- `config/retriex/prompt.yaml`
|
||||
- `src/Config/PromptBuilderConfig.php`
|
||||
|
||||
Scope:
|
||||
|
||||
- Section labels
|
||||
- Conversation context intro lines
|
||||
- Live shop result prompt rules
|
||||
- Output priority rules
|
||||
- Response format rules
|
||||
- Language rules
|
||||
- Fact grounding rules
|
||||
- Retrieved knowledge / URL source labels
|
||||
- Shop result field labels
|
||||
- Technical product model pattern
|
||||
|
||||
Intentionally unchanged:
|
||||
|
||||
- Main active system prompt from the database
|
||||
- Retrieval logic
|
||||
- Shop search logic
|
||||
- Vocabulary / intent / agent config logic
|
||||
- PromptBuilderConfig keyword detection, which remains backed by `vocabulary.yaml`
|
||||
|
||||
After applying:
|
||||
|
||||
1. Clear Symfony cache.
|
||||
2. Run the known 1.4.2 regression prompts.
|
||||
3. Verify that generated prompt sections remain identical to the previous behavior.
|
||||
@@ -0,0 +1,47 @@
|
||||
# RetrieX Prompt Precision Priority Fix
|
||||
|
||||
This patch intentionally avoids retrieval changes.
|
||||
|
||||
It does not add hard-coded keyword lists to the retriever and does not introduce a new core retrieval special case.
|
||||
|
||||
## Goal
|
||||
|
||||
For technical questions where the retrieved chunk already contains the exact answer plus nearby comparison values, the model should answer the requested fact first and avoid adding runner-up products or adjacent values unless the user explicitly asks for comparison or alternatives.
|
||||
|
||||
Example:
|
||||
|
||||
- Question: `Was ist der niedrigste Grenzwert fuer die Wasserhaerte, welcher mit einem Testomaten ueberwacht werden kann?`
|
||||
- Retrieved chunk may contain both `Testomat 808: 0,02 °dH` and `Testomat 2000: 0,05 °dH`.
|
||||
- Expected answer should focus on `0,02 °dH / Testomat 808` and should not add the runner-up value unless requested.
|
||||
|
||||
## Changed files
|
||||
|
||||
- `config/retriex/prompt.yaml`
|
||||
- `src/Agent/PromptBuilder.php`
|
||||
- `src/Config/PromptBuilderConfig.php`
|
||||
- `src/Config/RetriexEffectiveConfigProvider.php`
|
||||
|
||||
## What changed
|
||||
|
||||
- Added configurable `output_priority.technical_rules` in `prompt.yaml`.
|
||||
- `PromptBuilder` now emits the `OUTPUT PRIORITY` block for technical questions even when no shop results are present.
|
||||
- The technical priority rules are loaded through `PromptBuilderConfig` with PHP fallback defaults.
|
||||
- The effective config/regression provider now exposes and guards the technical output-priority rules.
|
||||
|
||||
## Not changed
|
||||
|
||||
- No retrieval logic changed.
|
||||
- No vector search logic changed.
|
||||
- No shop logic changed.
|
||||
- No core hard-coded domain keyword list added.
|
||||
- No scoring behavior changed.
|
||||
|
||||
## After applying
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
php bin/console cache:clear
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
@@ -0,0 +1,14 @@
|
||||
# RetrieX RAG Evidence Guard + Shop-Unavailable Fix
|
||||
|
||||
This patch separates vector retrieval hits from direct factual evidence.
|
||||
|
||||
## Changed behavior
|
||||
|
||||
- RAG hits are still counted as retrieved hits, but they are only shown as `fachlich belegt` when a salient user term or configured synonym appears in the retrieved RAG/URL content.
|
||||
- If retrieved chunks are only semantic nearest-neighbor hits, the UI confidence changes to `RAG-Näherungstreffer, kein direkter Fachbeleg`.
|
||||
- If the shop search fails, the shop meta card is finalized as unavailable instead of staying in a running/loading state.
|
||||
- Prompt rules now distinguish `semantic RAG hits without direct Fachbeleg` from reliable RAG facts.
|
||||
|
||||
## Scope
|
||||
|
||||
No retrieval, vector index, scoring, SSE, job, or shop-search request logic is changed. The patch only changes evidence classification, prompt instructions, fallback messages, and shop-unavailable meta status.
|
||||
64
patch_history/RETRIEX_SHOP_ADVISORY_INTENT_FIX_README.md
Normal file
64
patch_history/RETRIEX_SHOP_ADVISORY_INTENT_FIX_README.md
Normal file
@@ -0,0 +1,64 @@
|
||||
# RetrieX shop advisory intent fix
|
||||
|
||||
## Problem
|
||||
|
||||
The prompt
|
||||
|
||||
```text
|
||||
welcher pockettester ist für Redox messung gut
|
||||
```
|
||||
|
||||
was classified as a purely technical RAG question because the factual guard matched
|
||||
question wording such as `welcher` plus technical wording such as `Messung`.
|
||||
As a result no Shopware search was executed. The later follow-up
|
||||
|
||||
```text
|
||||
suche im shop
|
||||
```
|
||||
|
||||
then had to recover a shop query from history/client context, which remained fragile.
|
||||
|
||||
## Fix
|
||||
|
||||
This patch keeps the factual RAG guard for technical questions, but lets clear product
|
||||
advisory prompts pass into commerce detection when both conditions are true:
|
||||
|
||||
1. The prompt contains an advisory term such as `gut`, `geeignet`, `empfehl...`.
|
||||
2. The prompt contains a product/device class signal such as `pockettester`,
|
||||
`messgerät`, `handmessgerät`, etc.
|
||||
|
||||
This means:
|
||||
|
||||
- `Was ist der niedrigste Grenzwert ... Testomat ... Wasserhärte?` stays RAG-only.
|
||||
- `mit welchem indikator wird der wert gemessen` stays RAG-only.
|
||||
- `was kostet der indikator` stays commerce/product search.
|
||||
- `welcher pockettester ist für Redox messung gut` now triggers commerce search directly.
|
||||
|
||||
## Changed files
|
||||
|
||||
```text
|
||||
src/Intent/CommerceIntentLite.php
|
||||
src/Config/CommerceIntentConfig.php
|
||||
config/retriex/intent.yaml
|
||||
config/retriex/agent.yaml
|
||||
```
|
||||
|
||||
## Validation performed
|
||||
|
||||
```bash
|
||||
php -n -l src/Intent/CommerceIntentLite.php
|
||||
php -n -l src/Config/CommerceIntentConfig.php
|
||||
```
|
||||
|
||||
Additional local intent check:
|
||||
|
||||
```text
|
||||
Was ist der niedrigste Grenzwert ... => none
|
||||
mit welchem indikator ... => none
|
||||
was kostet der indikator => product_search
|
||||
welcher pockettester ist für Redox messung gut => product_search
|
||||
suche im shop => product_search
|
||||
suche im shop nach redox messung => product_search
|
||||
welcher Grenzwert kann mit dem Testomat 808 gemessen werden => none
|
||||
welches Messgerät ist für Redox Messung geeignet => product_search
|
||||
```
|
||||
@@ -0,0 +1,60 @@
|
||||
# RetrieX Shop Context + SSE Guard Hotfix
|
||||
|
||||
Patch-only hotfix for the Shopware query meta-command flow and duplicate SSE reconnect handling.
|
||||
|
||||
## Problem
|
||||
|
||||
After the user asked a domain question and then wrote a meta-command like `suche im shop`, the system could either:
|
||||
|
||||
- fail to recover the previous domain question from history,
|
||||
- ask for a concrete search query even though a relevant previous question existed,
|
||||
- continue with a misleading RAG-only final answer after the shop search was skipped,
|
||||
- append a misleading duplicate SSE reconnect message such as `Der Antwort-Stream läuft bereits...`.
|
||||
|
||||
## Changes
|
||||
|
||||
- The shop meta-command fallback now uses a larger history budget.
|
||||
- If the budgeted history is still polluted by repeated meta turns, the fallback checks the full recent context as a last resort.
|
||||
- The fallback still ignores meta-only turns such as `shop` / `suche im shop` and derives a compact shop query from the last non-meta domain question.
|
||||
- If no concrete shop query can be resolved, the agent now stops after the clarification message instead of generating a misleading final answer from RAG context.
|
||||
- Duplicate EventSource reconnects for already-running or completed jobs are silently closed with `done`, so the UI does not append a misleading stream error after the real stream already produced output.
|
||||
|
||||
## Expected behavior
|
||||
|
||||
Conversation:
|
||||
|
||||
```text
|
||||
mit welchem testomat kann ich freies chlor messen
|
||||
suche im shop
|
||||
```
|
||||
|
||||
Expected Shop query:
|
||||
|
||||
```text
|
||||
testomat freies chlor
|
||||
```
|
||||
|
||||
Not expected:
|
||||
|
||||
```text
|
||||
shop
|
||||
mit welchem testomat kann ich freies chlor messen
|
||||
```
|
||||
|
||||
## Notes
|
||||
|
||||
- No retrieval logic changed.
|
||||
- No scoring logic changed.
|
||||
- No product-family special case was added.
|
||||
- No Testomat 808 / Testomat 2000 / Tritromat special handling was added.
|
||||
- Existing config fallbacks remain intact.
|
||||
|
||||
## After applying
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
php bin/console cache:clear
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
@@ -0,0 +1,84 @@
|
||||
# RetrieX Shop-Meta-Context + SSE-Reconnect-Replay Fix
|
||||
|
||||
## Problem
|
||||
|
||||
Kurze referenzielle Shop-Befehle wie:
|
||||
|
||||
```text
|
||||
suche im shop
|
||||
```
|
||||
|
||||
konnten trotz vorheriger Antwort scheitern mit:
|
||||
|
||||
```text
|
||||
Ich habe keine konkrete Shop-Suchanfrage erkannt.
|
||||
```
|
||||
|
||||
Das passierte besonders nach langen oder reconnect-anfälligen SSE-Antworten, weil der Shop-Fallback vollständig von der serverseitig bereits geschriebenen History und einer stabilen Client-ID abhängig war.
|
||||
|
||||
Zusätzlich war das Job-ID-/SSE-Verhalten fragil: ein automatischer `EventSource`-Reconnect auf einen bereits laufenden Job konnte weiterhin als Duplicate-Stream behandelt werden.
|
||||
|
||||
## Lösung
|
||||
|
||||
### 1. SSE-Reconnect-Replay
|
||||
|
||||
- Antwort-Chunks werden pro Job mit fortlaufender SSE-`id` gesendet.
|
||||
- Chunks werden zusätzlich in `var/stream_jobs/*.stream.ndjson` gepuffert.
|
||||
- Reconnects mit `Last-Event-ID` replayen fehlende Chunks und tailen den laufenden Job.
|
||||
- Doppelte Events werden im Frontend defensiv ignoriert.
|
||||
- Completed/failed/interrupted Jobs werden sauber beendet.
|
||||
|
||||
### 2. Ephemeral Client Context Hint
|
||||
|
||||
- Das Frontend merkt sich den zuletzt vollständig abgeschlossenen Turn.
|
||||
- `/ask-jobs` sendet diesen Turn als `contextHint` mit.
|
||||
- Der Server speichert diesen Hint im Stream-Job und reicht ihn an `AgentRunner` weiter.
|
||||
- `AgentRunner` hängt den Hint nur temporär an den Commerce-History-Kontext an.
|
||||
- Der Hint wird nicht als eigener History-Eintrag persistiert.
|
||||
|
||||
Damit kann `suche im shop` auch dann auf die letzte Nutzerfrage/Antwort zurückfallen, wenn die serverseitige History gerade noch nicht zuverlässig greift oder die Client-ID-/Cookie-Situation im Browser wackelt.
|
||||
|
||||
### 3. Shop-Fallback-Tokenfilter geschärft
|
||||
|
||||
- `messung` wird im Shop-Context-Fallback nicht mehr entfernt, weil Begriffe wie `redox messung` fachlich relevant sind.
|
||||
- Zusätzliche Füllwörter wie `ist`, `sind`, `gut`, `geeignet` werden entfernt.
|
||||
|
||||
Beispiel aus dem Fehlerfall:
|
||||
|
||||
```text
|
||||
welcher pockettester ist für Redox messung gut
|
||||
suche im shop
|
||||
```
|
||||
|
||||
Der zweite Befehl kann nun aus dem Kontext wieder auf `pockettester redox messung` bzw. eine vergleichbare Shop-Query kommen, statt ohne konkrete Shop-Suchanfrage abzubrechen.
|
||||
|
||||
## Geänderte Dateien
|
||||
|
||||
```text
|
||||
src/Controller/AskSseController.php
|
||||
src/Agent/AgentRunner.php
|
||||
src/Config/AgentRunnerConfig.php
|
||||
config/retriex/agent.yaml
|
||||
public/assets/js/base.js
|
||||
```
|
||||
|
||||
## Prüfung
|
||||
|
||||
```bash
|
||||
php -n -l src/Controller/AskSseController.php
|
||||
php -n -l src/Agent/AgentRunner.php
|
||||
php -n -l src/Config/AgentRunnerConfig.php
|
||||
node --check public/assets/js/base.js
|
||||
```
|
||||
|
||||
`vendor/autoload.php` war in der ZIP-Arbeitskopie nicht enthalten, daher wurde `bin/console mto:agent:config:validate` hier nicht ausgeführt.
|
||||
|
||||
## Nach dem Einspielen
|
||||
|
||||
```bash
|
||||
php bin/console cache:clear
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
|
||||
Danach den Browser hart neu laden, weil `public/assets/js/base.js` geändert wurde.
|
||||
@@ -0,0 +1,62 @@
|
||||
# RetrieX Shop Meta Context Hint Frontend Fix
|
||||
|
||||
Patch-only fix for the referential shop follow-up flow:
|
||||
|
||||
```text
|
||||
welcher pockettester ist fuer Redox messung gut
|
||||
suche im shop
|
||||
```
|
||||
|
||||
## Problem
|
||||
|
||||
The backend fallback for meta-only shop prompts such as `suche im shop` can only resolve a concrete shop query when the previous turn is available through server history or through the frontend `contextHint`.
|
||||
|
||||
The previous frontend hint used only the in-memory `lastCompletedUserPrompt` / `lastCompletedAssistantText` state. If that state was empty, overwritten, or lost after a reload/reconnect sequence, the next `/ask-jobs` request sent an empty hint. The backend then had no concrete product/search context and returned:
|
||||
|
||||
```text
|
||||
Ich habe keine konkrete Shop-Suchanfrage erkannt. Bitte nenne das Produkt, Zubehör oder die Artikelnummer.
|
||||
```
|
||||
|
||||
A failed meta-only turn could also overwrite the frontend's last useful context, making immediate retries fragile.
|
||||
|
||||
## Fix
|
||||
|
||||
`public/assets/js/base.js` now builds the request `contextHint` more defensively:
|
||||
|
||||
1. Reconstruct the latest completed visible chat turn from the DOM before sending a new prompt.
|
||||
2. Persist the last completed turn in `sessionStorage` as a per-tab fallback.
|
||||
3. Do not overwrite the useful last turn with the generic no-concrete-shop-query response for meta-only prompts.
|
||||
4. Clear the stored fallback when the user clears the chat history.
|
||||
|
||||
## Scope
|
||||
|
||||
Changed file:
|
||||
|
||||
```text
|
||||
public/assets/js/base.js
|
||||
```
|
||||
|
||||
No changes to retrieval, scoring, PromptBuilder, AgentRunner, ShopSearchService, SSE job replay, or YAML prompt logic.
|
||||
|
||||
## Validation
|
||||
|
||||
```bash
|
||||
node --check public/assets/js/base.js
|
||||
```
|
||||
|
||||
Expected regression flow:
|
||||
|
||||
```text
|
||||
Was ist der niedrigste Grenzwert fuer die Wasserhaerte, welcher mit einem Testomaten ueberwacht werden kann?
|
||||
mit welchem indikator wird der wert gemessen
|
||||
was kostet der indikator
|
||||
```
|
||||
|
||||
Expected shop meta flow:
|
||||
|
||||
```text
|
||||
welcher pockettester ist fuer Redox messung gut
|
||||
suche im shop
|
||||
```
|
||||
|
||||
The second prompt should reuse the previous Redox/Pockettester context and no longer return the generic no-concrete-shop-query message.
|
||||
@@ -0,0 +1,63 @@
|
||||
# RetrieX Shop Query Context Anchor Fix
|
||||
|
||||
Patch-only fix for referential shop follow-up questions such as:
|
||||
|
||||
- `was kostet der indikator`
|
||||
- `was kostet das reagenz`
|
||||
- `suche im shop` after a prior product/parameter question
|
||||
|
||||
## Problem
|
||||
|
||||
The shop query optimizer could reduce a referential price follow-up to a too generic query, for example:
|
||||
|
||||
```text
|
||||
indikator
|
||||
```
|
||||
|
||||
Even when the previous RAG answer contained a precise anchor such as:
|
||||
|
||||
```text
|
||||
Indikatortyp 300
|
||||
```
|
||||
|
||||
The shop result could still be correct by chance, but the query was less robust than the previously confirmed stable behavior.
|
||||
|
||||
## Fix
|
||||
|
||||
The optimized query is now enriched generically from recent conversation context when all conditions match:
|
||||
|
||||
- the optimized shop query is short/generic,
|
||||
- the current prompt/query contains a configured accessory/reagent trigger term,
|
||||
- the recent context contains a configured type/code anchor such as `Indikatortyp 300`.
|
||||
|
||||
Expected example:
|
||||
|
||||
```text
|
||||
indikator + history anchor Indikatortyp 300
|
||||
=> indikatortyp 300 indikator
|
||||
```
|
||||
|
||||
## Design constraints
|
||||
|
||||
- No Retriever changes.
|
||||
- No vector/scoring changes.
|
||||
- No Testomat-808/Testomat-2000/Tritromat special case.
|
||||
- Product/type/code detection is configurable in `config/retriex/agent.yaml`.
|
||||
- PHP defaults remain as fallback.
|
||||
|
||||
## Files
|
||||
|
||||
- `config/retriex/agent.yaml`
|
||||
- `src/Agent/AgentRunner.php`
|
||||
- `src/Config/AgentRunnerConfig.php`
|
||||
- `src/Config/RetriexEffectiveConfigProvider.php`
|
||||
|
||||
## After applying
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
php bin/console cache:clear
|
||||
php bin/console mto:agent:config:validate
|
||||
php bin/console mto:agent:regression:test
|
||||
```
|
||||
@@ -0,0 +1,32 @@
|
||||
# RetrieX Shop Query Context Cleanup Hotfix
|
||||
|
||||
Purpose:
|
||||
- Keeps the existing language preservation and meta-query guard behavior.
|
||||
- Fixes the follow-up case where a meta command such as "suche im shop" reused the full previous user question as the Shopware search query.
|
||||
- The fallback now extracts a compact, generic shop query from recent context, e.g.:
|
||||
- "mit welchem testomat kann ich freies chlor messen" -> "testomat freies chlor"
|
||||
|
||||
Design constraints:
|
||||
- No retrieval changes.
|
||||
- No product-family-specific special cases.
|
||||
- No Testomat 808 / Testomat 2000 / Tritromat hardcoding.
|
||||
- Filtering terms are configurable in config/retriex/agent.yaml.
|
||||
- PHP defaults remain as safety fallback.
|
||||
|
||||
Changed files:
|
||||
- config/retriex/agent.yaml
|
||||
- src/Agent/AgentRunner.php
|
||||
- src/Config/AgentRunnerConfig.php
|
||||
- src/Config/RetriexEffectiveConfigProvider.php
|
||||
|
||||
Recommended after applying:
|
||||
- php bin/console cache:clear
|
||||
- php bin/console mto:agent:config:validate
|
||||
- php bin/console mto:agent:regression:test
|
||||
|
||||
Manual regression:
|
||||
1. Ask: mit welchem testomat kann ich freies chlor messen
|
||||
2. Then: suche im shop
|
||||
3. Expected shop query should be a compact product/parameter query such as:
|
||||
testomat freies chlor
|
||||
It must not be the full previous prompt.
|
||||
@@ -0,0 +1,34 @@
|
||||
# RetrieX Shop Query Context Fallback Hotfix
|
||||
|
||||
Patch-only hotfix for meta shop follow-ups such as `suche im shop`.
|
||||
|
||||
## Problem
|
||||
|
||||
After several shop meta follow-ups, the previous non-meta product/advisory question could fall outside the small context fallback window. The guard then correctly rejected `shop` as a query, but failed to derive a compact query from the last real topic.
|
||||
|
||||
## Fix
|
||||
|
||||
- Keep the language-preservation and meta-query guard behavior.
|
||||
- Increase the configurable fallback question window.
|
||||
- Add a separate configurable extended history budget for meta shop fallbacks.
|
||||
- If the normal commerce history does not provide a concrete query, scan a larger recent history window for the last non-meta user question.
|
||||
- Still compact the question into product/search tokens before sending it to Shopware.
|
||||
|
||||
## Expected example
|
||||
|
||||
`mit welchem testomat kann ich freies chlor messen` followed by `suche im shop` should resolve to a compact query such as:
|
||||
|
||||
```text
|
||||
testomat freies chlor
|
||||
```
|
||||
|
||||
It must not send:
|
||||
|
||||
```text
|
||||
shop
|
||||
mit welchem testomat kann ich freies chlor messen
|
||||
```
|
||||
|
||||
## Scope
|
||||
|
||||
No retrieval, vector, scoring, prompt-answering, product-family special case, Testomat-specific hardcoding or Shopware API changes.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user