Le modèle o3 d'open ai limite maintenant le nombre de pages de pdf à 10 max via l'api /responses

Question

A chaque fois que j'interroge l'api /responses avec le modèle o3 et que je joins un ou plusieurs fichiers pdf, si l'ensemble des pages de pdf dépasse 10, j'obtiens l'erreur 400 suivante : Too many images in request: XX, maximum allowed: 10. Cette limitation n'est pas du tout documentée. Peut-on contourner cette erreur ?

Answer 1

Page David Delplanque,

Bienvenue dans la section Questions-Réponses de Microsoft et merci de nous avoir contactés.

Lorsque vous envoyez des PDF à l'API /responses avec le modèle o3, chaque page est traitée en interne comme une image. Le système impose actuellement une limite stricte de 10 images/pages par requête. Si votre PDF comporte plus de 10 pages, vous obtiendrez une erreur 400 : Trop d'images dans la requête. Ce comportement a été observé par plusieurs utilisateurs, même s'il n'est pas clairement documenté.

La limitation du nombre maximal de pages PDF que vous rencontrez avec le modèle o3 n'est pas explicitement documentée. À titre de comparaison, il est à noter que les modèles GPT-4o et GPT-4.1 autorisent jusqu'à 50 images par requête, mais la limite plus stricte de 10 pages du modèle o3 n'est pas officiellement publiée. C'est pourquoi vous constatez un comportement différent de celui attendu.

Cette restriction ne concerne pas les jetons ni la taille du fichier, mais le nombre d'objets visuels que le pipeline de vision peut traiter en une seule requête. Chaque page compte comme une image. Cette limite permet de gérer les performances et la fiabilité du système ; vous ne pouvez donc pas la contourner en compressant ou en redimensionnant le PDF.

La solution la plus simple consiste à diviser votre PDF en lots plus petits, chacun contenant 10 pages maximum. Vous appelez ensuite l'API /responses séparément pour chaque lot. Après avoir traité toutes les parties, vous pouvez combiner les résultats ou réutiliser le modèle pour synthétiser et consolider les résultats.

Si votre PDF est textuel (ou numérisé), une autre option consiste à extraire le texte au préalable à l'aide d'outils OCR tels qu'Azure Document Intelligence, Adobe PDF Extract ou Tesseract. Une fois extrait, envoyez le texte directement au modèle par blocs gérables (en fonction de la taille du jeton). Cela permet d'éviter complètement la limitation du nombre d'images par page.

Certains utilisateurs signalent que l'API de complétion de chat autorise des limites plus élevées que le point de terminaison /responses (plus proche de la limite de 50 pages/image de GPT-4o/4.1). Bien que cela ne soit pas garanti, il est conseillé de tester si votre cas d'utilisation nécessite plus de 10 pages dans une seule requête.

Pour les PDF très volumineux, la meilleure pratique consiste à créer un pipeline RAG (Récupération-Génération Augmentée). Divisez et incorporez le document, stockez les incorporations dans une base de données vectorielle et récupérez les sections pertinentes au moment de la requête. Cette méthode est bien plus évolutive que l'envoi simultané de PDF entiers.

Malheureusement, il n'est pas possible de contourner directement la limite de 10 pages pour o3 via les paramètres d'API. Cette restriction est appliquée au niveau du service. Les seules options pratiques sont le fractionnement, l'extraction de texte ou d'autres approches d'ingestion.

Si votre flux de travail nécessite la gestion de PDF volumineux, la meilleure approche consiste à prétraiter et segmenter les documents avant de les envoyer au modèle. Cela permet non seulement d'éviter les erreurs, mais aussi d'améliorer la fiabilité et l'évolutivité.

J'espère que cela vous sera utile. N'hésitez pas à me contacter si vous avez d'autres questions.

---

Si cela répond à votre question, cliquez sur Accepter la réponse, puis sur Oui pour confirmer votre réponse.

Merci!