fix shop research intent fix 3
This commit is contained in:
@@ -263,8 +263,9 @@ final class PromptBuilderConfig
|
||||
{
|
||||
return $this->getStringList('shop_results.header_lines', [
|
||||
'LIVE SHOP RESULTS (authoritative for current commercial details):',
|
||||
'Use these results as the primary source for current price, availability, URL, and current shop-visible product naming.',
|
||||
'If retrieved documents conflict with shop data on price, availability, URL, or current naming, prefer the shop data.',
|
||||
'Use these results as the primary source for current price, availability, URL, current shop-visible product naming, and explicitly shop-visible product suitability when the user asks which product/device can measure or monitor something.',
|
||||
'If retrieved documents conflict with shop data on price, availability, URL, current naming, or explicitly shop-visible product suitability, prefer the shop data for those fields.',
|
||||
'If retrieved documents do not identify a matching product, but a live shop result explicitly names the requested measurement parameter or application, do not conclude that no matching product exists.',
|
||||
'Output real URL values exactly as provided in the shop results. Do not replace them with placeholders, link labels, or product names.',
|
||||
'Do not infer undocumented technical specifications from shop data.',
|
||||
'Commercial fields from shop data may only be assigned to a product if the shop item clearly matches the same product identity.',
|
||||
@@ -291,6 +292,7 @@ final class PromptBuilderConfig
|
||||
{
|
||||
return $this->getStringList('output_priority.rules', [
|
||||
'- Use retrieved knowledge first to determine the technically matching product or answer.',
|
||||
'- For product-selection questions such as which device can measure or monitor a parameter, use relevant live shop results as a fallback when retrieved knowledge does not identify a matching product.',
|
||||
'- If shop results are present, use them afterwards to add current price, availability, and the actual URL.',
|
||||
'- Do not let bundles, accessories, or service items override a better technical match unless the user explicitly asks for them.',
|
||||
]);
|
||||
@@ -434,8 +436,9 @@ final class PromptBuilderConfig
|
||||
public function getFactGroundingWithShopRules(): array
|
||||
{
|
||||
return $this->getStringList('fact_grounding.with_shop_rules', [
|
||||
'- Use shop data as highest priority only for current commercial fields: price, availability, URL, and current shop-visible naming.',
|
||||
'- Use retrieved knowledge as highest priority for technical matching, thresholds, measurement principles, and technical explanation.',
|
||||
'- Use shop data as highest priority for current commercial fields: price, availability, URL, current shop-visible naming, and explicitly shop-visible product suitability for product-selection questions.',
|
||||
'- Use retrieved knowledge as highest priority for technical matching, thresholds, measurement principles, and technical explanation when it contains a matching product or fact.',
|
||||
'- If retrieved knowledge is silent or only contains unrelated products, but live shop results explicitly match the requested parameter/application, use the shop results and do not answer with a negative RAG-only conclusion.',
|
||||
'- When shop results are present and relevant, include current price and the actual URL if available.',
|
||||
'- If the shop data does not provide a positive price for a result, do not output any price for that result.',
|
||||
'- Do not let accessories, bundles, or service items override a technically better product match unless the user explicitly asks for them.',
|
||||
|
||||
Reference in New Issue
Block a user