Compatibilité des fournisseurs LLM

​

Détection du fournisseur

1. Fournisseur explicite (champ DB ModelConfig.provider) — priorité la plus élevée. Si le fournisseur correspond à un domaine connu dans l’URL, aucun api_base n’est renvoyé (LiteLLM achemine nativement). Sinon, api_base est défini sur l’URL de relais.
2. Correspondance de domaine par rapport à KNOWN_DOMAINS — les points de terminaison API officiels sont reconnus par nom d’hôte.
3. Indice de chemin d’URL par rapport à PATH_PROVIDER_HINTS — courant sur les plateformes de relais comme UniAPI où /claude ou /anthropic dans le chemin indique le protocole en amont.
4. Secours — préfixe openai/ (générique OpenAI-compatible).

​

tool_choice — les quatre modes

​

Où tool_choice est utilisé

​

Moteur ReAct — tool_choice=“auto”

​

structured_llm_call — tool_choice=forced

​

Le piège du prefill Bedrock

{"role": "assistant", "content": "{"}

ValidationException: This model does not support assistant message prefill.
The conversation must end with a user message.

1. Le modèle est résolu avec le préfixe anthropic/ (via correspondance de domaine ou indice de chemin URL).
2. response_format={"type":"json_object"} est transmis (le chemin de code json_mode dans structured_llm_call).
3. Le backend réel est AWS Bedrock (qui rejette le prefill).

​

Le correctif : json_mode_enabled

• Modèles configurés via BD : basculer dans Admin → Models → Advanced settings. L’indicateur est stocké sur ModelProviderModel.json_mode_enabled (par défaut TRUE).
• Modèles configurés via ENV : définir LLM_JSON_MODE_ENABLED=false dans votre environnement.
• Effet : lorsque désactivé, abilities["json_mode"] retourne False → response_format n’est jamais passé → pas de prefill → Bedrock fonctionne. La chaîne de dégradation devient native_fc → plain_text, en ignorant entièrement l’appel json_mode voué à l’échec.
• Aucune perte de qualité : le modèle retourne toujours du JSON valide car le system prompt l’impose. Le niveau plain_text utilise extract_json() pour analyser le JSON à partir de contenu libre, ce qui fonctionne de manière fiable avec les modèles modernes.

​

Modèles de réflexion + forced tool_choice

tool_choice 'specified' is incompatible with thinking enabled

​

Le correctif : tool_choice_enabled

• Modèles configurés en BD : basculer dans Admin → Models → Advanced → “Native Function Calling”. Le drapeau est stocké sur ModelProviderModel.tool_choice_enabled (par défaut TRUE).
• Modèles configurés par ENV : définissez LLM_TOOL_CHOICE_ENABLED=false dans votre environnement.
• Effet : lorsque désactivé, abilities["tool_choice"] retourne False → la chaîne de dégradation commence au Niveau 2 (json_mode) ou Niveau 3 (plain_text), en ignorant complètement native_fc. Cela élimine la pénalité d’~10s par appel structuré pour les modèles incompatibles.
• Agent ReAct non affecté : tool_choice_enabled contrôle uniquement la sélection d’outil forcée dans structured_llm_call. Le moteur ReAct utilise tool_choice="auto" (le modèle décide librement), qui fonctionne avec tous les modèles indépendamment de ce paramètre.

​

Référence rapide : ce qui fonctionne où

​

Configuration recommandée par modèle

# Disable native_fc globally (for thinking-model-only deployments)
LLM_TOOL_CHOICE_ENABLED=false

# Disable json_mode globally (for Bedrock relay deployments)
LLM_JSON_MODE_ENABLED=false

​

Effort de raisonnement et configuration de la réflexion

1. La température est forcée à 1.0. Bedrock rejette temperature != 1.0 lorsque la réflexion est activée. FIM One gère cela automatiquement — aucune action utilisateur nécessaire.
2. GPT-5.x avec outils : reasoning_effort est silencieusement supprimé lorsque des tools sont présents, car le point de terminaison GPT-5 /v1/chat/completions rejette la combinaison. Cela n’affecte que la boucle d’outil ReAct ; les appels structured_llm_call qui manquent d’un paramètre tools ne sont pas affectés.

​

Analyse défensive pour la sortie structurée

1. Objet unique au lieu de tableau. Certains modèles retournent {"steps": {"id": "1", "task": "..."}} (un objet d’étape unique) au lieu de {"steps": [{"id": "1", "task": "..."}]} (un tableau). L’analyseur détecte cela en vérifiant la présence de clés id ou task et enveloppe l’objet dans une liste.
2. Chaîne JSON double-encodée. Lorsque la sortie structurée revient à json_mode (qui manque d’application de schéma), certains fournisseurs retournent la valeur steps comme chaîne JSON plutôt que comme tableau natif — par exemple, {"steps": "[{\"id\": \"1\", ...}]"}. Cette chaîne peut également contenir des sauts de ligne littéraux (du formatage du modèle) qui cassent le json.loads standard. L’analyseur utilise extract_json_value() (qui inclut _repair_json_strings) pour gérer :
   • Les sauts de ligne littéraux à l’intérieur des valeurs de chaîne JSON
   • Les séquences d’échappement invalides (courantes avec le contenu LaTeX ou de code)
   • Autres particularités de sérialisation des couches de compatibilité
3. Enveloppe steps manquante. Le modèle peut retourner une seule étape comme objet de niveau supérieur sans la clé d’enveloppe steps. L’analyseur détecte id et task au niveau racine et enveloppe en conséquence.

​

Mise en cache des prompts (multi-fournisseur)

​

Architecture

• PromptSection — un fragment nommé avec soit un content: str statique, soit un content: Callable dynamique
• PromptRegistry — un magasin mémoïsé (les sections statiques se rendent une fois, les sections dynamiques se re-rendent par appel)
• DYNAMIC_BOUNDARY — un marqueur sentinel que le registre insère entre la dernière section statique et la première dynamique, afin que les appelants puissent diviser le prompt rendu au point de rupture du cache

• Préfixe statique (~95% du prompt) — identité, directives principales, descriptions d’outils
• Suffixe dynamique — date/heure actuelle, directive de langue par requête, contexte de transfert

​

Détection des capacités

​

Couverture multi-fournisseurs

​

Observabilité

"cache": {
  "read_tokens": 1067,
  "creation_tokens": 0
}

​

ROI du cache multi-tour

​

Politique de relecture du raisonnement (exactitude sans modèle)

​

Trois politiques

• anthropic_thinking — Famille Claude (y compris anthropic/, bedrock/anthropic, vertex_ai/claude). Les blocs de réflexion DOIVENT être rejoués avec signature attachée ; Anthropic rejette les tours suivants si la signature est manquante ou modifiée.
• informational_only — modèles qui émettent CoT mais n’attendent PAS de rejouer : DeepSeek R1 / R1-Distill, Qwen QwQ, Gemini 2.x thinking, OpenAI o1 / o3 / o4. Leur documentation dit explicitement « n’envoyez pas reasoning_content dans l’historique des messages ». L’envoyer quand même :
  • Viole le contrat du fournisseur (peut commencer à rejeter dans les versions futures)
  • Invalide silencieusement leur cache de préfixe automatique — les octets du message mutent à chaque tour, cassant le hash
• unsupported — modèles sans capacité de réflexion (GPT-4o, GPT-4 Turbo, Gemini 1.5, Mistral, Llama). Pas de CoT à rejouer ; le champ ne devrait jamais apparaître. Cette politique est aussi le défaut sûr pour les identifiants de modèle inconnus.

​

Application

​

Pour les utilisateurs

• Si vous basculez entre les agents Claude et DeepSeek dans la même conversation, l’historique est stocké avec les blocs de réflexion intacts ; au tour suivant, la forme du message sortant s’adapte selon le modèle actuel.
• Si vous utilisez un proxy / une sous-classe BaseLLM personnalisée, assurez-vous que son identifiant de modèle est reconnaissable (contient l’un des fragments) ou la politique unsupported par défaut s’appliquera — ce qui est sûr mais signifie que Claude derrière un proxy inhabituel pourrait perdre la relecture de la réflexion. Ajoutez le fragment d’identifiant de modèle à _CACHE_CAPABLE_MODEL_FRAGMENTS (dans core/prompt/caching.py) et/ou à la recherche de politique de réflexion.

​

Dépannage