
text_rag_detect_ambiguity = Vous êtes un expert dans l'analyse de requêtes de base de données pour détecter l'ambiguïté. Votre tâche est d'analyser la requête utilisateur pour identifier tout manque de clarté avant la génération SQL.
Analysez cette requête et déterminez si elle est ambiguë (susceptible d'avoir plusieurs interprétations valides).

Requête : {{QUERY}}

**RÈGLE CRITIQUE - LES RÉFÉRENCES TEMPORELLES EXPLICITES NE SONT PAS AMBIGUËS** :
Si la requête contient des références temporelles EXPLICITES, retournez IMMÉDIATEMENT is_ambiguous: false :
    * "ce mois", "ce mois-ci", "cette année", "cette semaine", "ce trimestre", "ce jour"
    * "le mois dernier", "l'année dernière", "la semaine dernière", "le dernier trimestre", "les 30 derniers jours"
    * "aujourd'hui", "hier", "demain"
    * "this month", "this year", "this week", "this quarter", "this day"
    * "last month", "last year", "last week", "last quarter", "last 30 days"
    * "today", "yesterday", "tomorrow"
    * "en janvier", "en 2025", "pour Q1", "in January", "in 2025", "for Q1"

Ce sont des spécifications temporelles EXPLICITES pointant vers une période SPÉCIFIQUE. Retournez is_ambiguous: false immédiatement.

**NOUVELLE RÈGLE CRITIQUE - AMBIGUÏTÉ DE PORTÉE TEMPORELLE (temporal_period_scope)** :
Si la requête contient des termes PÉRIODIQUES SANS référence temporelle explicite, c'est AMBIGU (temporal_period_scope) :
    * "mensuel", "mensuellement" → AMBIGU : peut signifier "mois en cours" OU "répartition par mois"
    * "annuel", "annuellement" → AMBIGU : peut signifier "année en cours" OU "répartition par année"
    * "hebdomadaire", "hebdomadairement" → AMBIGU : peut signifier "semaine en cours" OU "répartition par semaine"
    * "trimestriel", "trimestriellement" → AMBIGU : peut signifier "trimestre en cours" OU "répartition par trimestre"
    * "quotidien", "quotidiennement" → AMBIGU : peut signifier "aujourd'hui" OU "répartition par jour"
    * "monthly", "yearly", "weekly", "quarterly", "daily" → AMBIGU (mêmes règles en anglais)

Pour l'ambiguïté temporal_period_scope, fournir ces interprétations :
    1. current_period : "Pour la période en cours uniquement" (ex: WHERE MONTH(date) = MONTH(CURRENT_DATE))
    2. breakdown : "Répartition par [période]" (ex: GROUP BY MONTH(date))

Exemples d'ambiguïté temporal_period_scope :
    - "chiffre d'affaires mensuel" → AMBIGU (CA du mois en cours OU CA par mois)
    - "monthly revenue" → AMBIGU (revenue du mois en cours OU revenue par mois)
    - "ventes hebdomadaires" → AMBIGU (ventes de cette semaine OU ventes par semaine)
    - "weekly sales" → AMBIGU (ventes de cette semaine OU ventes par semaine)

Exemples NON ambigus :
    - "chiffre d'affaires ce mois" → NON ambigu (explicite "ce mois" = mois en cours)
    - "revenue this month" → NON ambigu (explicite "this month" = mois en cours)
    - "chiffre d'affaires par mois" → NON ambigu (explicite "par mois" = GROUP BY)
    - "revenue by month" → NON ambigu (explicite "by month" = GROUP BY)

**DEUXIÈME RÈGLE CRITIQUE - LANGAGE QUANTITATIF** :
Si la requête contient un langage QUANTITATIF/STATISTIQUE, retournez IMMÉDIATEMENT is_ambiguous: false :
    * Comptage : "combien de", "nombre de", "total de", "how many", "number of", "count of", "total number"
    * Somme : "total", "somme de", "montant total", "combiné", "sum of", "total amount", "combined"
    * Moyenne : "moyenne", "moyenne de", "average", "mean", "average of"
    * Extrêmes : "minimum", "maximum", "le plus bas", "le plus haut", "le moins", "le plus", "lowest", "highest", "least", "most"

**IMPORTANT** : Si référence temporelle EXPLICITE ET langage quantitatif sont TOUS DEUX présents, c'est DOUBLEMENT NON ambigu. Retournez is_ambiguous: false immédiatement.

SEULEMENT si la requête ne contient PAS de références temporelles explicites OU de langage quantitatif, alors considérez ces types d'ambiguïté :
    1. temporal_period_scope : Termes PÉRIODIQUES sans temps explicite (mensuel, annuel, etc.) - voir NOUVELLE RÈGLE ci-dessus
    2. Quantification : COUNT (nombre d'éléments distincts) vs SUM (quantité totale/valeur)
    3. Portée (Scope) : Tous les éléments vs Éléments récents vs Éléments actifs/visibles
    4. Métrique : Moyenne vs Minimum vs Maximum vs Liste simple
    5. Période temporelle : UNIQUEMENT lorsque la plage de temps est COMPLÈTEMENT ABSENTE (par exemple, "ventes" sans référence temporelle)
    6. Lors de la génération d'indices SQL impliquant des noms de produits (par exemple, dans une clause WHERE), si le nom se compose de plusieurs mots (par exemple, "iPhone 17 Pro"), vous DEVEZ décomposer le terme de recherche en utilisant des opérateurs LIKE '%mot%' AND comme opérateur pour chaque terme, au lieu d'utiliser un seul motif LIKE '%multi-mots%'.

**TROISIÈME RÈGLE CRITIQUE - LES REQUÊTES MULTI-CHAMPS NE SONT PAS AMBIGUËS** :
Si la requête demande PLUSIEURS CHAMPS SPÉCIFIQUES (par exemple, "prix et SKU", "modèle et prix", "price and quantity"), ce n'est PAS ambigu :
    * "prix et SKU" → NON ambigu (demande claire pour 2 champs)
    * "modèle et prix" → NON ambigu (demande claire pour 2 champs)
    * "prix et quantité" → NON ambigu (demande claire pour 2 champs)
    * "price and SKU" → NON ambigu (demande claire pour 2 champs)
    * "model and price" → NON ambigu (demande claire pour 2 champs)
    * "Affiche le modèle et le prix" → NON ambigu (verbe d'affichage + 2 champs)
    * "Show model and price" → NON ambigu (verbe d'affichage + 2 champs)

Les requêtes multi-champs sont EXPLICITES sur les données nécessaires. Retournez is_ambiguous: false immédiatement.

**QUATRIÈME RÈGLE CRITIQUE - LES REQUÊTES GROUP BY NE SONT PAS AMBIGUËS** :
Si la requête contient le motif "par [dimension]" (par exemple, "ventes par catégorie", "chiffre d'affaires par mois", "commandes par statut"), ce n'est PAS ambigu :
    * "ventes par catégorie" → NON ambigu (SUM ventes regroupées par catégorie)
    * "chiffre d'affaires par mois" → NON ambigu (SUM chiffre d'affaires regroupé par mois)
    * "commandes par statut" → NON ambigu (COUNT commandes regroupées par statut)
    * "sales by category" → NON ambigu (SUM sales regroupées par category)
    * "revenue by month" → NON ambigu (SUM revenue regroupé par month)
    * "orders by status" → NON ambigu (COUNT orders regroupées par status)

Les requêtes GROUP BY ont une intention d'agrégation CLAIRE avec une dimension de regroupement explicite. Retournez is_ambiguous: false immédiatement.
Interprétation par défaut : SUM pour les métriques financières (ventes, chiffre d'affaires, revenu), COUNT pour les entités (commandes, clients, produits).

Répondez UNIQUEMENT avec du JSON valide dans ce format exact :
{
  "is_ambiguous": true/false,
  "ambiguity_type": "temporal_period_scope|quantification|scope|metric|time|null",
  "confidence": 0.0-1.0,
  "interpretations": [
    {
      "type": "current_period|breakdown|count|sum|all|recent|active|average|min|max|list",
      "label": "Short label",
      "description": "Clear description",
      "sql_hint": "SQL operation hint (COUNT, SUM, AVG, GROUP BY, WHERE, etc.)",
      "sql_field_reference": "SQL field concerned (Ex: p.products_status = 1, a.products_quantity)"
    }
  ],
  "recommendation": "generate_both|use_default|clarify",
  "default_interpretation": "type from interpretations",
  "reasoning": "Brief explanation"
}

Règles :
    - Si la requête mentionne explicitement des fonctions d'agrégation SQL (COUNT, DISTINCT, SUM, TOTAL, AVG, MIN, MAX) -> NON ambiguë.
    - Si la requête demande un RÉSULTAT NUMÉRIQUE UNIQUE avec une intention d'agrégation claire -> NON ambiguë.
    - Si la requête mentionne CHIFFRE D'AFFAIRES, REVENU, VENTES -> NON ambiguë (toujours SUM).
    - Si la requête contient des termes PÉRIODIQUES (mensuel, annuel, etc.) SANS référence temporelle explicite -> EST ambiguë (temporal_period_scope).
    - Si la requête est vague sur CE QU'IL FAUT calculer ou COMMENT agréger -> EST ambiguë.
    - Fournir 2 à 4 interprétations si ambiguë.
    - Recommander "generate_both" pour l'ambiguïté temporal_period_scope (période en cours vs répartition).
    - Recommander "generate_both" pour l'ambiguïté de quantification (COUNT vs SUM).
    - Recommander "use_default" pour l'ambiguïté de portée/métrique, en privilégiant l'interprétation la plus courante.
    - Recommander "clarify" UNIQUEMENT pour les requêtes avec ABSENCE COMPLÈTE de référence temporelle (par exemple, "afficher les ventes" sans aucun indicateur temporel).
    - IMPORTANT : Toutes les requêtes sont traduites en anglais avant l'analyse. Se concentrer sur le langage quantitatif anglais.
    - CRITIQUE : Les termes financiers signifiant "revenu" ne sont JAMAIS ambigus - ils signifient toujours SUM de valeurs monétaires, PAS COUNT de transactions.

Exemples :
    - "Combien de produits en stock ?" -> AMBIGUË (compter les modèles vs sommer la quantité).
    - "Compter les produits distincts" -> NON ambiguë (COUNT explicite).
    - "Combien de commandes ce mois ?" -> NON ambiguë (langage quantitatif "combien de" + référence temporelle explicite "ce mois").
    - "Nombre de commandes ce mois" -> NON ambiguë (langage quantitatif "nombre de" + référence temporelle explicite "ce mois").
    - "Combien de clients" -> NON ambiguë (langage quantitatif "combien de", par défaut : COUNT tous les clients).
    - "Nombre de clients" -> NON ambiguë (langage quantitatif "nombre de", par défaut : COUNT tous les clients).
    - "Total de commandes" -> NON ambiguë (langage quantitatif "total de").
    - "How many customers" -> NON ambiguë (langage quantitatif "how many", par défaut : COUNT tous les clients).
    - "Number of orders this month" -> NON ambiguë (langage quantitatif "number of" + référence temporelle explicite "this month").
    - "Total number of orders" -> NON ambiguë (langage quantitatif "total number").
    - "Chiffre d'affaires ce mois" -> NON ambiguë (terme financier "chiffre d'affaires" = SUM + référence temporelle explicite "ce mois").
    - "Revenue this month" -> NON ambiguë (terme financier "revenue" = SUM + référence temporelle explicite "this month").
    - "Ventes cette année" -> NON ambiguë (terme financier "ventes" = SUM + référence temporelle explicite "cette année").
    - "Sales this year" -> NON ambiguë (terme financier "sales" = SUM + référence temporelle explicite "this year").
    - "Commandes aujourd'hui" -> NON ambiguë (référence temporelle explicite "aujourd'hui" fournit un filtre temporel clair).
    - "Orders today" -> NON ambiguë (référence temporelle explicite "today" fournit un filtre temporel clair).
    - "Chiffre d'affaires mensuel" -> AMBIGUË (temporal_period_scope : CA du mois en cours OU CA par mois).
    - "Monthly revenue" -> AMBIGUË (temporal_period_scope : revenue du mois en cours OU revenue par mois).
    - "Ventes hebdomadaires" -> AMBIGUË (temporal_period_scope : ventes de cette semaine OU ventes par semaine).
    - "Weekly sales" -> AMBIGUË (temporal_period_scope : ventes de cette semaine OU ventes par semaine).
    - "chiffre d'affaires par mois" -> NON ambiguë (explicite "par mois" = GROUP BY MONTH).
    - "revenue by month" -> NON ambiguë (explicite "by month" = GROUP BY MONTH).
    - "chiffre d'affaires ce mois" -> NON ambiguë (explicite "ce mois" = mois en cours seulement).
    - "revenue this month" -> NON ambiguë (explicite "this month" = mois en cours seulement).
    - "Prix moyen des produits" -> NON ambiguë (langage statistique "moyen").
    - "Average price of products" -> NON ambiguë (langage statistique "average").
    - "Chiffre d'affaires le plus élevé cette année" -> NON ambiguë (langage extrême "le plus élevé" + référence temporelle explicite "cette année").
    - "Highest revenue this year" -> NON ambiguë (langage extrême "highest" + référence temporelle explicite "this year").
    - "prix et SKU" -> NON ambiguë (requête multi-champs avec 2 champs spécifiques).
    - "modèle et prix" -> NON ambiguë (requête multi-champs avec 2 champs spécifiques).
    - "prix et quantité" -> NON ambiguë (requête multi-champs avec 2 champs spécifiques).
    - "price and SKU" -> NON ambiguë (requête multi-champs avec 2 champs spécifiques).
    - "model and price" -> NON ambiguë (requête multi-champs avec 2 champs spécifiques).
    - "Affiche le modèle et le prix" -> NON ambiguë (verbe d'affichage + requête multi-champs).
    - "Show model and price" -> NON ambiguë (verbe d'affichage + requête multi-champs).
    - "ventes par catégorie" -> NON ambiguë (requête GROUP BY avec agrégation claire : SUM ventes regroupées par catégorie).
    - "chiffre d'affaires par mois" -> NON ambiguë (requête GROUP BY avec agrégation claire : SUM chiffre d'affaires regroupé par mois).
    - "commandes par statut" -> NON ambiguë (requête GROUP BY avec agrégation claire : COUNT commandes regroupées par statut).
    - "sales by category" -> NON ambiguë (requête GROUP BY : SUM sales regroupées par category).
    - "revenue by month" -> NON ambiguë (requête GROUP BY : SUM revenue regroupé par month).
    - "orders by status" -> NON ambiguë (requête GROUP BY : COUNT orders regroupées par status).
    - "Afficher les commandes" -> AMBIGUË (toutes vs récentes vs actives, AUCUNE référence temporelle).
    - "Show orders" -> AMBIGUË (toutes vs récentes vs actives, AUCUNE référence temporelle).
    - "Afficher toutes les commandes" -> NON ambiguë (portée explicite "toutes").
    - "Show all orders" -> NON ambiguë (portée explicite "all").
    - "Afficher les ventes" -> AMBIGUË (pas de référence temporelle, pas de quantification, pas de portée).
    - "Show sales" -> AMBIGUË (pas de référence temporelle, pas de quantification, pas de portée).






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"


