La meilleure architecture de prompt pour les robots FX en 2026

Auteur: Équipe FXMacroData
Publié: 21 mai 2026

La plupart des robots FX ne tombent pas parce qu'ils utilisent le mauvais modèle. Ils échouent parce qu 'ils utilisant une architecture de prompt faible. Dans le trading en direct, un prompt n'est pas un paragraphe. C'est une surface de contrôle qui décide comment votre système interprète le contexte, applique la politique de risque et forme les décisions.

Si votre robot surveille USD/JPY, gère des décharges comme PNFPCe guide vous donne une architecture pratique qui fait exactement cela.

Pourquoi les signaux de bloc unique éclatent sur les marchés en direct

Une seule longue invite mélange généralement le contexte, la politique et le format souhaité dans un seul point. Cela rend le comportement instable lorsque la taille des entrées change ou que les conditions du marché augmentent.

Symptômes courants:

• JSON propre dans les sessions calmes, sortie malformée dans les séances volatiles.
• Un récit confiant avec des niveaux d'invalidation manquants.
• Les hypothèses de risque implicites qui dérivent au fil du temps.

La solution est l'architecture, pas plus d'adjectifs.

Couche 1: demande d'état (seulement des faits)

La couche d'état ne doit contenir que le contexte objectif tiré des API.

{
  "asof_utc": "2026-05-21T20:00:00Z",
  "pairs": {
    "EUR/USD": { "last": 1.0872, "change_24h_pct": 0.42 },
    "USD/JPY": { "last": 156.81, "change_24h_pct": -0.35 }
  },
  "events": [
    { "currency": "USD", "indicator": "core_pce", "time_utc": "2026-05-22T12:30:00Z" },
    { "currency": "GBP", "indicator": "unemployment", "time_utc": "2026-05-22T06:00:00Z" }
  ]
}

Construisez ceci à partir de points de terminaison stables, par exemple:

curl "https://fxmacrodata.com/api/v1/announcements/usd/core_pce?api_key=YOUR_API_KEY"
curl "https://fxmacrodata.com/api/v1/announcements/gbp/unemployment?api_key=YOUR_API_KEY"
curl "https://fxmacrodata.com/api/v1/forex?base=EUR&quote=USD&api_key=YOUR_API_KEY"

Couche 2: Les règles sont claires (limites raisonnables)

La couche de règles définit comment le modèle peut penser et ce qu'il ne peut pas faire.

You are an FX research assistant.

Allowed:
- Infer directional bias from supplied macro + price context.
- Mention uncertainty explicitly.

Not allowed:
- Invent missing data.
- Give broker execution instructions.
- Output fields outside contract.

Behavior:
- If data is insufficient, return action=flat with reason="insufficient_context".
- Prefer concise causal chains over broad narratives.

Cela sépare la politique d'inférence des données brutes, ce qui facilite beaucoup le débogage.

Couche 3: risque immédiat (restrictions difficiles)

Le risque n'est pas un style, traitez-le comme des termes de contrat immuables.

Risk policy v1:
- max_size_pct = 0.50
- min_confidence = 0.60
- invalidation is mandatory
- no new risk inside +/- 15 minutes of high-impact calendar events
- if any rule fails, return action=flat and policy_status=reject

Lorsque la communication de la banque centrale à partir de la Réserve fédérale ou ... Banque du Japon Cette couche empêche l'inflation de la confiance de se transformer en transactions surdimensionnées.

Couche 4: Contrat de sortie (interface déterministe)

Le contrat de sortie est ce que votre gardien ou moteur d'exécution consomme réellement.

{
  "action": "long|short|flat",
  "pair": "string",
  "confidence": 0.0,
  "thesis": "string",
  "invalidation": "string",
  "size_pct": 0.0,
  "policy_status": "approve|reject",
  "next_data_to_watch": ["string"]
}

Rejetez toute réponse qui échoue à la validation du schéma.

Montage de la pile complète

Dans la mise en œuvre, gardez chaque couche versionnée indépendamment et combinez à l'exécution:

PROMPT = {
    "state": state_payload,            # dynamic JSON
    "rules": rules_block_v3,           # static text
    "risk": risk_policy_v1,            # static text
    "output_contract": contract_json,  # static schema
}

final_prompt = f"""
STATE:\n{PROMPT['state']}

RULES:\n{PROMPT['rules']}

RISK:\n{PROMPT['risk']}

OUTPUT CONTRACT:\n{PROMPT['output_contract']}

Return JSON only.
"""

Cette structure rend les autopsies claires. Si le comportement change, vous pouvez identifier si les données de l'État ont changé, les règles ont changé ou si le risque a changé ou l'application du contrat a changé.

Un modèle de production rapide que vous pouvez réutiliser

Si vous voulez un comportement prévisible, passez des modifications de prompt ad-hoc aux modèles explicites.

{
  "prompt_id": "fx_agent_v6",
  "state_version": "state_schema_v2",
  "rules_version": "rules_v3",
  "risk_version": "risk_v1_2",
  "contract_version": "decision_contract_v4",
  "fallback_mode": "flat_on_error"
}

Connectez-le à votre runtime pour que chaque journal de décision stocke les quatre versions. Cela vous donne une comparabilité instantanée lorsque vous exécutez des tests de répétition ou enquêtez sur la dérive après une semaine à fort impact.

L'ordre de blocage suggéré dans les instructions finales:

1. Identité et portée du système (courte, stable).
2. État de la charge utile (uniquement des données JSON).
3. Blocage des règles (comportement autorisé/interdit).
4. Bloc de risques (obligations non négociables)
5. Contrats de sortie (schéma JSON + instruction de retour uniquement).
6. Instruction de récupération d'erreur (flat sur l'incertitude).

Ne placez pas de longs conseils narratifs avant les instructions du contrat.

Routage rapide au niveau du régime

Une seule architecture de commande a encore besoin d'un routage de régime. Vos règles de "sessions calmes" ne devraient pas être identiques à vos règles de choc d'événement. Utilisez un routeur léger avant l'inférence:

def select_prompt_profile(next_event_minutes: int, realized_vol_pct: float) -> str:
    if abs(next_event_minutes) <= 20:
        return "event_profile"
    if realized_vol_pct >= 1.1:
        return "high_vol_profile"
    return "normal_profile"

Chaque profil peut partager le même contrat tout en modifiant les seuils de risque et les contraintes de style de raisonnement.

Gestion des défaillances et conception de la reprise

La qualité de l'architecture instantanée est visible lorsque les choses vont mal, pas quand elles vont bien.

• Échec du schéma: Si la sortie est rejetée, le routeur réessaye une fois avec un contexte compact.
• Conflit de politique: l' action est forcée de flat avec policy_status=rejectJe suis désolé .
• Insuffisance des données: aucun candidat commercial n'est produit et une alerte est émise.

Bloc de politique de réserve minimum:

Fallback policy:
- If contract parse fails -> return flat candidate from deterministic fallback template.
- If policy_status != approve -> do not call execution adapter.
- If data freshness check fails -> skip inference and publish "no-decision" note.

C'est ce qui sépare un assistant FX robuste d'un robot démo fragile.

Liste de vérification de la validation avant utilisation active

1. Le taux de réussite du schéma est supérieur au seuil cible dans les essais de répétition.
2. La conformité à la politique est proche de 100% dans les fenêtres à forte intensité d'événements de la calendrier de sortieJe suis désolé .
3. Aucun champ hallucinant sur les charges utiles de contexte mixte.
4. Un comportement stable à travers les séances suivie par Sessions de changeJe suis désolé .
5. Les versions de l'instructeur et du portier sont verrouillées et auditables.

Résumé

L'architecture de la demande est la couche d'ingénierie manquante dans de nombreuses piles de trading d'IA. Divisez votre demande en couches d'état, de règles, de risque et de contrat, puis appliquez chacune avec une validation déterministe. C'est ainsi que vous transformez l'intelligence du modèle en comportement répétable.

L'étape suivante: exécuter des replay mensuels et suivre la dérive par couche.