Accueil → Aide

Réponse vide avec finish_reason content_filter

Une couche de modération a arrêté la génération. La requête s'est exécutée, c'est donc une réponse normale et non une erreur, et les tokens produits avant l'arrêt sont facturés.

Ce que vous voyez

Pourquoi cela arrive

Le filtrage peut s'appliquer au prompt ou à la sortie au fur et à mesure de sa production. Un arrêt en cours de route signifie que la sortie l'a déclenché ; une réponse vide immédiate signifie généralement que c'est l'entrée.

Les seuils varient selon le modèle et le fournisseur, donc le même texte peut passer sur l'un et être arrêté sur l'autre. C'est pourquoi changer de modèle semble « corriger » le problème.

On le confond facilement avec une troncature. La différence est dans finish_reason : length signifie que vous avez manqué de tokens, content_filter que le contenu a été refusé.

Comment le corriger

  1. Faites une branche selon finish_reasonTraitez content_filter comme un cas à part avec un message pour l'utilisateur. Relancer la même entrée produit le même résultat et ne fait que coûter de l'argent.
  2. Vérifiez quel côté l'a déclenchéEnvoyez le prompt avec un max_tokens minimal. S'il s'arrête toujours immédiatement, le déclencheur est l'entrée, pas la sortie.
  3. Reformulez au lieu de relancerSi la tâche est légitime, retirer la formulation précise qui déclenche le filtre suffit généralement. Le contenu utilisateur cité en est une cause fréquente.
Une réponse filtrée est une requête terminée, donc les tokens générés avant l'arrêt apparaissent dans votre journal d'utilisation APICLAN et sont facturés. Une réponse vide avec un nombre de tokens de sortie non nul, c'est exactement ce cas.

Voir aussi

Unexpected token '<' lors d'un appel à une API compatible OpenAI401 invalid API key : quand la clé semble correcte mais échoue quand même

Dernière vérification le 2026-10-01. Rédigé à partir de problèmes diagnostiqués sur une passerelle compatible OpenAI en production, pas compilé à partir d'autres sites.