
text_rag_detect_ambiguity = You are an expert at analyzing database queries for ambiguity. Your task is to analyze the user's query to identify any lack of clarity before SQL generation.
Analyze this query and determine if it is ambiguous (could have multiple valid interpretations).

Query: {{QUERY}}

**CRITICAL RULE - CHECK FIRST BEFORE ANYTHING ELSE**:
If the query contains ANY of these temporal expressions, IMMEDIATELY return is_ambiguous: false and STOP analysis:
    * "this month", "this year", "this week", "this quarter", "this day"
    * "last month", "last year", "last week", "last quarter", "last 30 days"
    * "today", "yesterday", "tomorrow"
    * "monthly", "yearly", "weekly", "daily", "quarterly"
    * "ce mois", "cette année", "cette semaine", "ce trimestre"
    * "le mois dernier", "l'année dernière", "la semaine dernière"
    * "aujourd'hui", "hier", "demain"
    * "mensuellement", "annuellement", "hebdomadairement", "quotidiennement"

These are CLEAR temporal specifications. DO NOT proceed to check other ambiguity types if ANY temporal expression is present.

**SECOND CRITICAL RULE - ALSO CHECK FIRST**:
If the query contains QUANTITATIVE/STATISTICAL language, IMMEDIATELY return is_ambiguous: false:
    * Counting: "how many", "number of", "count of", "total number", "combien de", "nombre de"
    * Summing: "total", "sum of", "total amount", "combined"
    * Averaging: "average", "mean", "average of"
    * Extremes: "minimum", "maximum", "lowest", "highest", "least", "most", "smallest", "largest"

**IMPORTANT**: If BOTH temporal expression AND quantitative language are present, this is DOUBLY NOT ambiguous. Return is_ambiguous: false immediately.

ONLY if the query does NOT contain temporal expressions OR quantitative language, then consider these types of ambiguity:
    1. Quantification: COUNT (distinct items) vs SUM (total quantity/value)
    2. Scope: All items vs Recent items vs Active/Visible items
    3. Metric: Average vs Minimum vs Maximum vs Simple List
    4. Time period: ONLY when time range is COMPLETELY ABSENT (e.g., "sales" with no time reference)
    5. When generating SQL hints involving product names (e.g., in a WHERE clause), if the name consists of multiple words (e.g., "iPhone 17 Pro"), you MUST decompose the search term using separate LIKE '%word%' AND operators for each term, instead of using a single LIKE '%multi word%' pattern.

**THIRD CRITICAL RULE - MULTI-FIELD QUERIES ARE NOT AMBIGUOUS**:
If the query requests MULTIPLE SPECIFIC FIELDS (e.g., "price and SKU", "model and price", "prix et quantité"), this is NOT ambiguous:
    * "price and SKU" → NOT ambiguous (clear request for 2 fields)
    * "model and price" → NOT ambiguous (clear request for 2 fields)
    * "modèle et prix" → NOT ambiguous (clear request for 2 fields)
    * "prix et quantité" → NOT ambiguous (clear request for 2 fields)
    * "Show model and price" → NOT ambiguous (display verb + 2 fields)
    * "Affiche le modèle et le prix" → NOT ambiguous (display verb + 2 fields)

Multi-field queries are EXPLICIT about what data is needed. Return is_ambiguous: false immediately.

**FOURTH CRITICAL RULE - GROUP BY QUERIES ARE NOT AMBIGUOUS**:
If the query contains "by [dimension]" pattern (e.g., "sales by category", "revenue by month", "orders by status"), this is NOT ambiguous:
    * "sales by category" → NOT ambiguous (SUM sales grouped by category)
    * "revenue by month" → NOT ambiguous (SUM revenue grouped by month)
    * "orders by status" → NOT ambiguous (COUNT orders grouped by status)
    * "ventes par catégorie" → NOT ambiguous (SUM ventes grouped by catégorie)
    * "commandes par statut" → NOT ambiguous (COUNT commandes grouped by statut)
    * "chiffre d'affaires par trimestre" → NOT ambiguous (SUM revenue grouped by quarter)

GROUP BY queries have CLEAR aggregation intent with explicit grouping dimension. Return is_ambiguous: false immediately.
Default interpretation: SUM for financial metrics (sales, revenue, turnover), COUNT for entities (orders, customers, products).

Respond ONLY with valid JSON in this exact format:
{
"is_ambiguous": true/false,
"ambiguity_type": "quantification|scope|metric|time|null",
"confidence": 0.0-1.0,
"interpretations": [
 {
   "type": "count|sum|all|recent|active|average|min|max|list",
   "label": "Short label for interpretation",
   "description": "Clear description of the SQL interpretation.",
   "sql_hint": "SQL operation hint (COUNT, SUM, AVG, etc.)",
   "sql_field_reference": "Hint for the specific SQL field (e.g., p.products_status = 1, a.products_quantity)"
 }
],
"recommendation": "generate_both|use_default|clarify",
"default_interpretation": "type from interpretations",
"reasoning": "Brief explanation of the ambiguity level and recommendation."
}

Rules:
    - If query explicitly mentions SQL aggregation functions (COUNT, DISTINCT, SUM, TOTAL, AVG, MIN, MAX) -> NOT ambiguous.
    - If query requests a SINGLE NUMERIC RESULT with clear aggregation intent -> NOT ambiguous.
    - If query mentions REVENUE, TURNOVER, INCOME, SALES REVENUE -> NOT ambiguous (always SUM).
    - If query is vague about WHAT to calculate or HOW to aggregate -> IS ambiguous.
    - Provide 2-4 interpretations if ambiguous.
    - Recommend "generate_both" for quantification ambiguity (COUNT vs SUM).
    - Recommend "use_default" for scope/metric ambiguity, prioritizing the most common interpretation.
    - Recommend "clarify" ONLY for queries with COMPLETE absence of time reference (e.g., "show sales" with no time indicator).
    - IMPORTANT: All queries are translated to English before analysis. Focus on English quantitative language.
    - CRITICAL: Financial terms that mean "revenue" are NEVER ambiguous - they always mean SUM of monetary values, NOT COUNT of transactions.

Examples:
    - "How many products in stock?" -> AMBIGUOUS (count distinct models vs sum total quantity).
    - "Count distinct products" -> NOT ambiguous (explicit COUNT).
    - "How many orders this month?" -> NOT ambiguous (quantitative "how many" + temporal expression "this month").
    - "Number of orders this month" -> NOT ambiguous (quantitative "number of" + temporal expression "this month").
    - "How many customers" -> NOT ambiguous (quantitative language "how many", default: COUNT all customers).
    - "Number of customers" -> NOT ambiguous (quantitative language "number of", default: COUNT all customers).
    - "Total number of orders" -> NOT ambiguous (quantitative language "total number").
    - "Combien de commandes ce mois" -> NOT ambiguous (quantitative "combien de" + temporal "ce mois").
    - "Combien de clients" -> NOT ambiguous (quantitative language "combien de", default: COUNT all clients).
    - "Revenue this month" -> NOT ambiguous (financial term "revenue" = SUM + temporal "this month").
    - "Sales this year" -> NOT ambiguous (financial term "sales" = SUM + temporal "this year").
    - "Orders today" -> NOT ambiguous (temporal expression "today" provides clear time filter).
    - "Monthly revenue" -> NOT ambiguous (temporal grouping "monthly" + financial term "revenue").
    - "Average price of products" -> NOT ambiguous (statistical language "average").
    - "Highest revenue this year" -> NOT ambiguous (extreme language "highest" + temporal "this year").
    - "price and SKU" -> NOT ambiguous (multi-field query with 2 specific fields).
    - "model and price" -> NOT ambiguous (multi-field query with 2 specific fields).
    - "modèle et prix" -> NOT ambiguous (multi-field query with 2 specific fields).
    - "prix et quantité" -> NOT ambiguous (multi-field query with 2 specific fields).
    - "Show model and price" -> NOT ambiguous (display verb + multi-field query).
    - "Affiche le modèle et le prix" -> NOT ambiguous (display verb + multi-field query).
    - "sales by category" -> NOT ambiguous (GROUP BY query with clear aggregation: SUM sales grouped by category).
    - "revenue by month" -> NOT ambiguous (GROUP BY query with clear aggregation: SUM revenue grouped by month).
    - "orders by status" -> NOT ambiguous (GROUP BY query with clear aggregation: COUNT orders grouped by status).
    - "ventes par catégorie" -> NOT ambiguous (GROUP BY query: SUM ventes grouped by catégorie).
    - "commandes par statut" -> NOT ambiguous (GROUP BY query: COUNT commandes grouped by statut).
    - "chiffre d'affaires par trimestre" -> NOT ambiguous (GROUP BY query: SUM revenue grouped by quarter).
    - "Show orders" -> AMBIGUOUS (all vs recent vs active, NO time reference).
    - "Show all orders" -> NOT ambiguous (explicit scope "all").
    - "Show sales" -> AMBIGUOUS (no time reference, no quantification, no scope).


text_rag_clarify_query_for_interpretation = Rewrite this ambiguous query to be explicit about the intent.
    Original query: {{original_query}}
    Interpretation: {{interpretation}}
    SQL hint: {{sql_hint}}
Rewrite the query to clearly indicate this specific interpretation.
If the query contains multiple words, rewrite the query for each word like that %word%.
Use explicit keywords like COUNT, SUM, AVG, DISTINCT, ALL, RECENT, etc.
Respond with ONLY the rewritten query, nothing else.

Examples:
    - "How many products?" + COUNT -> "Count the number of distinct products"
    - "How many products?" + SUM -> "Sum the total quantity of all products"
    - "Show orders" + RECENT -> "Show orders from the last 30 days"



text_rag_clarify_query_for_interpretation = Rewrite this ambiguous query to be explicit about the intent.
    Original query: {{original_query}}
    Interpretation: {{interpretation}}
    SQL hint: {{sql_hint}}
Rewrite the query to clearly indicate this specific interpretation.
Use explicit keywords like COUNT, SUM, AVG, DISTINCT, ALL, RECENT, etc.
Respond with ONLY the rewritten query, nothing else.

Examples:
    - "How many products?" + COUNT -> "Count the number of distinct products"
    - "How many products?" + SUM -> "Sum the total quantity of all products"
    - "Show orders" + RECENT -> "Show orders from the last 30 days"


