Decider V1.1 27B est le checkpoint de décision mis à jour de Perplexity. Il évalue le contenu fourni au regard d’une question définie et produit des probabilités sur les réponses valides. Son artefact natif comporte une tête de lecture décisionnelle (readout) plutôt qu’une tête de génération de langage couvrant l’ensemble du vocabulaire. Le résultat utile est une distribution de décision bornée et la réponse qui en est interprétée, et non une explication ouverte ni une réponse de chat générale.
Perplexity présente ce modèle comme une mise à jour de Decider V1 27B qui conserve le même backbone, avec des modifications de la configuration d’attention et davantage de données d’entraînement. Son backbone est Qwen3.8-27B. L’édition V1.1 doit conserver son propre nom et sa propre configuration plutôt que d’être décrite comme une copie interchangeable du checkpoint précédent.
L’exemple publié fournit une ligne contenant un état et une question de choix typée. La question comprend des instructions et des critères dont les clés sont les réponses sémantiques et dont les descriptions définissent quand chacune s’applique. Le modèle prédit des probabilités, puis la fonction utilitaire de réponse de l’éditeur interprète ces probabilités pour la question. L’exemple d’inférence peut traiter une liste de lignes, chaque décision étant rattachée aux éléments probants et à la question de sa ligne.
Pour le routage des demandes, fournissez le message réel et le contexte pertinent, puis définissez les services ou catégories disponibles. Une tâche illustrative peut distinguer une panne d’intégration, un problème d’accès et une demande d’informations sur un produit. Rendez chaque description suffisamment précise pour trancher un cas limite, et conservez les définitions des options avec le résultat. Une distribution de catégories peut alors étayer une décision de routage ou une étape de revue lorsque les alternatives restent proches. Le résultat choisi par le modèle n’exécute pas lui-même l’action du flux de travail.
L’implémentation native accepte des images en plus de l’état et de la question, sous forme de fichiers image, d’images en mémoire ou de données d’image encodées. Pour l’image d’un document ou une capture d’écran, fournissez l’élément visuel et posez une question fermée dont les options décrivent les issues pertinentes. Indiquez la caractéristique visible qui compte et fournissez le contexte textuel nécessaire pour l’interpréter. Par exemple, déterminez si un article représenté appartient à l’une des catégories de produits fournies plutôt que de demander au modèle de décision de rédiger une description complète du produit.
Le processeur préserve les proportions lors du redimensionnement et arrondit les côtés de l’image à des multiples de 32 pixels. La surface traitée documentée commence à 65 536 pixels et est bornée par un maximum configurable ; sa valeur par défaut est de 4 194 304 pixels, soit 2048 par 2048. Chaque patch de 32 par 32 produit un token visuel, de sorte que cette valeur par défaut autorise jusqu’à 4 096 tokens visuels par image. Ces chiffres décrivent la préparation d’image native de l’éditeur, et non un contrat général de téléversement applicatif.
L’étape de préparation documentée exige que le texte et l’ensemble des images d’une même décision tiennent dans 8 192 tokens. Une entrée trop volumineuse est rejetée plutôt que tronquée silencieusement. Plusieurs images partagent ce budget avec l’état et la question rédigés. Réduisez le texte source non pertinent ou le plafond de taille des images lors de la préparation d’une décision combinée, tout en conservant le détail qui détermine la réponse.
La configuration d’entraînement et d’évaluation publiée plafonnait les images à 512 par 512, soit 262 144 pixels et jusqu’à 256 tokens visuels. Le plafond configurable à l’inférence peut conserver davantage de détails, mais la fiche du modèle avertit qu’une résolution plus élevée sort de cette distribution d’entraînement et consomme davantage de mémoire et de temps de traitement. Un réglage d’image plus grand ne garantit donc pas une meilleure décision. Maintenez une préparation des entrées cohérente avec la question et vérifiez que la caractéristique visuelle nécessaire est clairement représentée.
Les couches d’attention complète du checkpoint natif utilisent un mode d’attention non causal enregistré, tandis que ses couches d’attention linéaire conservent leur propre comportement. Le concepteur précise que l’inférence causale par défaut ne reproduit pas la configuration évaluée. Son implémentation de prédiction applique la température de calibrage enregistrée ; si les logits sont utilisés directement, cette température est appliquée une seule fois et les probabilités sont normalisées sur les candidats valides en cours. Ces détails appartiennent au profil de décision exact et doivent être préservés lors de l’interprétation de ses sorties numériques.
La tête de lecture décisionnelle distincte différencie également cet artefact d’un export génératif. Une conversion vers une interface de génération fondée sur le vocabulaire nécessite une correspondance explicite et doit préserver le comportement d’attention. Préparez des questions fermées pour le profil de décision natif ; utilisez un modèle de génération adapté lorsque la tâche requiert du chat, du code, des explications ou des requêtes d’outils.
Un artefact final utile maintient associés l’état, la question, les réponses autorisées et la distribution obtenue. Définissez la question autour des éléments réellement présents, examinez les cas ambigus au regard de ces éléments et utilisez des exemples étiquetés issus de la tâche visée pour décider de la manière dont les sorties numériques doivent influer sur le routage ou la classification. Le modèle fournit des probabilités de décision ; les critères et l’application environnante déterminent comment ces probabilités deviennent une action utile ou une étiquette enregistrée.
", "aboutText": "Decider V1.1 27B est le checkpoint de décision mis à jour de Perplexity. Il évalue le contenu fourni au regard d’une question définie et produit des probabilités sur les réponses valides. Son artefact natif comporte une tête de lecture décisionnelle (readout) plutôt qu’une tête de génération de langage couvrant l’ensemble du vocabulaire. Le résultat utile est une distribution de décision bornée et la réponse qui en est interprétée, et non une explication ouverte ni une réponse de chat générale.\n\n### Ce qui change dans l’édition V1.1\n\nPerplexity présente ce modèle comme une mise à jour de Decider V1 27B qui conserve le même backbone, avec des modifications de la configuration d’attention et davantage de données d’entraînement. Son backbone est Qwen3.8-27B. L’édition V1.1 doit conserver son propre nom et sa propre configuration plutôt que d’être décrite comme une copie interchangeable du checkpoint précédent.\n\n### État, question et réponses valides\n\nL’exemple publié fournit une ligne contenant un état et une question de choix typée. La question comprend des instructions et des critères dont les clés sont les réponses sémantiques et dont les descriptions définissent quand chacune s’applique. Le modèle prédit des probabilités, puis la fonction utilitaire de réponse de l’éditeur interprète ces probabilités pour la question. L’exemple d’inférence peut traiter une liste de lignes, chaque décision étant rattachée aux éléments probants et à la question de sa ligne.\n\nPour le routage des demandes, fournissez le message réel et le contexte pertinent, puis définissez les services ou catégories disponibles. Une tâche illustrative peut distinguer une panne d’intégration, un problème d’accès et une demande d’informations sur un produit. Rendez chaque description suffisamment précise pour trancher un cas limite, et conservez les définitions des options avec le résultat. Une distribution de catégories peut alors étayer une décision de routage ou une étape de revue lorsque les alternatives restent proches. Le résultat choisi par le modèle n’exécute pas lui-même l’action du flux de travail.\n\n### Éléments textuels et visuels\n\nL’implémentation native accepte des images en plus de l’état et de la question, sous forme de fichiers image, d’images en mémoire ou de données d’image encodées. Pour l’image d’un document ou une capture d’écran, fournissez l’élément visuel et posez une question fermée dont les options décrivent les issues pertinentes. Indiquez la caractéristique visible qui compte et fournissez le contexte textuel nécessaire pour l’interpréter. Par exemple, déterminez si un article représenté appartient à l’une des catégories de produits fournies plutôt que de demander au modèle de décision de rédiger une description complète du produit.\n\nLe processeur préserve les proportions lors du redimensionnement et arrondit les côtés de l’image à des multiples de 32 pixels. La surface traitée documentée commence à 65 536 pixels et est bornée par un maximum configurable ; sa valeur par défaut est de 4 194 304 pixels, soit 2048 par 2048. Chaque patch de 32 par 32 produit un token visuel, de sorte que cette valeur par défaut autorise jusqu’à 4 096 tokens visuels par image. Ces chiffres décrivent la préparation d’image native de l’éditeur, et non un contrat général de téléversement applicatif.\n\n### Limites d’entrée combinées et périmètre de résolution\n\nL’étape de préparation documentée exige que le texte et l’ensemble des images d’une même décision tiennent dans 8 192 tokens. Une entrée trop volumineuse est rejetée plutôt que tronquée silencieusement. Plusieurs images partagent ce budget avec l’état et la question rédigés. Réduisez le texte source non pertinent ou le plafond de taille des images lors de la préparation d’une décision combinée, tout en conservant le détail qui détermine la réponse.\n\nLa configuration d’entraînement et d’évaluation publiée plafonnait les images à 512 par 512, soit 262 144 pixels et jusqu’à 256 tokens visuels. Le plafond configurable à l’inférence peut conserver davantage de détails, mais la fiche du modèle avertit qu’une résolution plus élevée sort de cette distribution d’entraînement et consomme davantage de mémoire et de temps de traitement. Un réglage d’image plus grand ne garantit donc pas une meilleure décision. Maintenez une préparation des entrées cohérente avec la question et vérifiez que la caractéristique visuelle nécessaire est clairement représentée.\n\n### Attention, tête de lecture et calibrage des probabilités\n\nLes couches d’attention complète du checkpoint natif utilisent un mode d’attention non causal enregistré, tandis que ses couches d’attention linéaire conservent leur propre comportement. Le concepteur précise que l’inférence causale par défaut ne reproduit pas la configuration évaluée. Son implémentation de prédiction applique la température de calibrage enregistrée ; si les logits sont utilisés directement, cette température est appliquée une seule fois et les probabilités sont normalisées sur les candidats valides en cours. Ces détails appartiennent au profil de décision exact et doivent être préservés lors de l’interprétation de ses sorties numériques.\n\nLa tête de lecture décisionnelle distincte différencie également cet artefact d’un export génératif. Une conversion vers une interface de génération fondée sur le vocabulaire nécessite une correspondance explicite et doit préserver le comportement d’attention. Préparez des questions fermées pour le profil de décision natif ; utilisez un modèle de génération adapté lorsque la tâche requiert du chat, du code, des explications ou des requêtes d’outils.\n\nUn artefact final utile maintient associés l’état, la question, les réponses autorisées et la distribution obtenue. Définissez la question autour des éléments réellement présents, examinez les cas ambigus au regard de ces éléments et utilisez des exemples étiquetés issus de la tâche visée pour décider de la manière dont les sorties numériques doivent influer sur le routage ou la classification. Le modèle fournit des probabilités de décision ; les critères et l’application environnante déterminent comment ces probabilités deviennent une action utile ou une étiquette enregistrée.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "167ebcaf6f3c4be97363188489244367f11edbc7b876e04d60d5f1b5bc481a58", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "fr", "methods": [ { "html": "perplexity/pplx-decider-v1.1-27bDecider V1.1 27B de Perplexity évalue un état et une question fournis et renvoie des probabilités sur l’ensemble des réponses autorisées. Son checkpoint de décision natif prend en charge le texte et les images, avec une tête de lecture dédiée et des limites documentées de préparation des entrées, plutôt qu’un contrat de génération de texte libre.
Cette description présente les capacités du modèle. Les entrées, sorties et options disponibles dans Ailoot pour la méthode sélectionnée figurent ci-dessous.
Decider V1.1 27B est le checkpoint de décision mis à jour de Perplexity. Il évalue le contenu fourni au regard d’une question définie et produit des probabilités sur les réponses valides. Son artefact natif comporte une tête de lecture décisionnelle (readout) plutôt qu’une tête de génération de langage couvrant l’ensemble du vocabulaire. Le résultat utile est une distribution de décision bornée et la réponse qui en est interprétée, et non une explication ouverte ni une réponse de chat générale.
Perplexity présente ce modèle comme une mise à jour de Decider V1 27B qui conserve le même backbone, avec des modifications de la configuration d’attention et davantage de données d’entraînement. Son backbone est Qwen3.8-27B. L’édition V1.1 doit conserver son propre nom et sa propre configuration plutôt que d’être décrite comme une copie interchangeable du checkpoint précédent.
L’exemple publié fournit une ligne contenant un état et une question de choix typée. La question comprend des instructions et des critères dont les clés sont les réponses sémantiques et dont les descriptions définissent quand chacune s’applique. Le modèle prédit des probabilités, puis la fonction utilitaire de réponse de l’éditeur interprète ces probabilités pour la question. L’exemple d’inférence peut traiter une liste de lignes, chaque décision étant rattachée aux éléments probants et à la question de sa ligne.
Pour le routage des demandes, fournissez le message réel et le contexte pertinent, puis définissez les services ou catégories disponibles. Une tâche illustrative peut distinguer une panne d’intégration, un problème d’accès et une demande d’informations sur un produit. Rendez chaque description suffisamment précise pour trancher un cas limite, et conservez les définitions des options avec le résultat. Une distribution de catégories peut alors étayer une décision de routage ou une étape de revue lorsque les alternatives restent proches. Le résultat choisi par le modèle n’exécute pas lui-même l’action du flux de travail.
L’implémentation native accepte des images en plus de l’état et de la question, sous forme de fichiers image, d’images en mémoire ou de données d’image encodées. Pour l’image d’un document ou une capture d’écran, fournissez l’élément visuel et posez une question fermée dont les options décrivent les issues pertinentes. Indiquez la caractéristique visible qui compte et fournissez le contexte textuel nécessaire pour l’interpréter. Par exemple, déterminez si un article représenté appartient à l’une des catégories de produits fournies plutôt que de demander au modèle de décision de rédiger une description complète du produit.
Le processeur préserve les proportions lors du redimensionnement et arrondit les côtés de l’image à des multiples de 32 pixels. La surface traitée documentée commence à 65 536 pixels et est bornée par un maximum configurable ; sa valeur par défaut est de 4 194 304 pixels, soit 2048 par 2048. Chaque patch de 32 par 32 produit un token visuel, de sorte que cette valeur par défaut autorise jusqu’à 4 096 tokens visuels par image. Ces chiffres décrivent la préparation d’image native de l’éditeur, et non un contrat général de téléversement applicatif.
L’étape de préparation documentée exige que le texte et l’ensemble des images d’une même décision tiennent dans 8 192 tokens. Une entrée trop volumineuse est rejetée plutôt que tronquée silencieusement. Plusieurs images partagent ce budget avec l’état et la question rédigés. Réduisez le texte source non pertinent ou le plafond de taille des images lors de la préparation d’une décision combinée, tout en conservant le détail qui détermine la réponse.
La configuration d’entraînement et d’évaluation publiée plafonnait les images à 512 par 512, soit 262 144 pixels et jusqu’à 256 tokens visuels. Le plafond configurable à l’inférence peut conserver davantage de détails, mais la fiche du modèle avertit qu’une résolution plus élevée sort de cette distribution d’entraînement et consomme davantage de mémoire et de temps de traitement. Un réglage d’image plus grand ne garantit donc pas une meilleure décision. Maintenez une préparation des entrées cohérente avec la question et vérifiez que la caractéristique visuelle nécessaire est clairement représentée.
Les couches d’attention complète du checkpoint natif utilisent un mode d’attention non causal enregistré, tandis que ses couches d’attention linéaire conservent leur propre comportement. Le concepteur précise que l’inférence causale par défaut ne reproduit pas la configuration évaluée. Son implémentation de prédiction applique la température de calibrage enregistrée ; si les logits sont utilisés directement, cette température est appliquée une seule fois et les probabilités sont normalisées sur les candidats valides en cours. Ces détails appartiennent au profil de décision exact et doivent être préservés lors de l’interprétation de ses sorties numériques.
La tête de lecture décisionnelle distincte différencie également cet artefact d’un export génératif. Une conversion vers une interface de génération fondée sur le vocabulaire nécessite une correspondance explicite et doit préserver le comportement d’attention. Préparez des questions fermées pour le profil de décision natif ; utilisez un modèle de génération adapté lorsque la tâche requiert du chat, du code, des explications ou des requêtes d’outils.
Un artefact final utile maintient associés l’état, la question, les réponses autorisées et la distribution obtenue. Définissez la question autour des éléments réellement présents, examinez les cas ambigus au regard de ces éléments et utilisez des exemples étiquetés issus de la tâche visée pour décider de la manière dont les sorties numériques doivent influer sur le routage ou la classification. Le modèle fournit des probabilités de décision ; les critères et l’application environnante déterminent comment ces probabilités deviennent une action utile ou une étiquette enregistrée.
POST /v1/systemonetext, imagedecisions| Champ | Type | Exigence | Valeurs et limites | Par défaut |
|---|---|---|---|---|
Champmodel | Typestring | ExigenceObligatoire | Valeurs et limites perplexity/pplx-decider-v1.1-27b | Par défaut— |
Champprovider | Typeschema | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champquestions | Typeobject | ExigenceObligatoire | Valeurs et limites | Par défaut— |
Champsession_id | Typestring | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champstate | Typeschema | ExigenceObligatoire | Valeurs et limites | Par défaut— |
Champtrace | Typeschema | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champuser | Typestring | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champquestions.<id>.type | Typestring | ExigenceObligatoire | Valeurs et limites noul, choice, score | Par défaut— |
Champquestions.<id>.instructions | Typestring|object|array | ExigenceObligatoire | Valeurs et limites | Par défaut— |
Champquestions.<id>.criteria | Typeobject|array | ExigenceFacultatif | Valeurs et limites Conditions: choice/score : obligatoires ; noul : facultatif. Les critères de choice forment un objet ; score est un tableau avec minItems égal à 1. | Par défaut— |
Champquestions.<id>.criteria.true | Typestring|object|array | ExigenceObligatoire | Valeurs et limites S’applique lorsque: objet de critères noul fourni | Par défaut— |
Champquestions.<id>.criteria.false | Typestring|object|array | ExigenceObligatoire | Valeurs et limites S’applique lorsque: objet de critères noul fourni | Par défaut— |
noul · Obligatoire : state, questions.<id>.type=noul, questions.<id>.instructions
choice · Obligatoire : state, questions.<id>.type=choice, questions.<id>.instructions, criteria object
score · Obligatoire : state, questions.<id>.type=score, questions.<id>.instructions, criteria array with minItems1
| Paramètre | Contrat |
|---|---|
Paramètrecontent_type | Contratapplication/json |
Paramètrerequired | Contratmodel, state, questions |
Paramètrematerial_types | Contrattext, image |
Paramètreoptional_controls | Contratprovider, session_id, trace, user |
Paramètremultimodal_input_binding | ContratUtilisez uniquement la représentation exacte déclarée de l’état ou du document. La seule capacité du fabricant à traiter des images ne prouve pas l’existence d’un format d’entrée image accepté pour ce modèle. |
Cycle de vie : synchronous
Envoyez l’identifiant exact du modèle et conservez la réponse native complète.
Les tarifs n’ajoutent pas d’options de requête. Les paramètres pris en charge figurent dans la méthode sélectionnée.
Associez chaque coût aux conditions indiquées. Utilisez un seul tarif pour chaque ensemble de configurations alternatives.
| Configuration | Barème tarifaire | Tokens de contexte, plus de | Tokens de contexte, jusqu’à la limite incluse | Coût |
|---|---|---|---|---|
| ConfigurationTarifs de base des tokens | Barème tarifaireTarif de base | Tokens de contexte, plus de— | Tokens de contexte, jusqu’à la limite incluseSans borne supérieure | Coût Entrée · Tokens en entrée $0.00004 / 1K tokens Sortie · Tokens en sortie $0 / 1K tokens Entrée · Lecture du cache — / 1K tokens Entrée · Écriture dans le cache — / 1K tokens Entrée · Écriture dans le cache, 1 h — / 1K tokens |
| ConfigurationPalier 1 de longueur de requête | Barème tarifaire— | Tokens de contexte, plus de0 | Tokens de contexte, jusqu’à la limite incluseSans borne supérieure | Coût Entrée · Tokens en entrée $0.00004 / 1K tokens Sortie · Tokens en sortie $0 / 1K tokens Entrée · Lecture du cache — / 1K tokens Entrée · Écriture dans le cache — / 1K tokens Entrée · Écriture dans le cache, 1 h — / 1K tokens |
Ailoot réserve un montant estimé avant une requête. Après le résultat, le montant final est débité selon l’utilisation mesurée. Pour le streaming, le montant final à débiter est calculé à partir du relevé final d’utilisation. Fonctionnement de la réservation et du débit →
{\n "model": "perplexity/pplx-decider-v1.1-27b",\n "questions": {\n "is_bug": {\n "criteria": {\n "false": "The customer is asking a question or requesting a feature.",\n "true": "The customer describes broken or unexpected product behavior."\n },\n "instructions": "Is the customer reporting a software defect?",\n "type": "noul"\n },\n "team": {\n "criteria": {\n "account": "Login, permissions, or profile issues.",\n "frontend": "Rendering, layout, or browser compatibility issues.",\n "payments": "Checkout, billing, or payment processing issues."\n },\n "instructions": "Which team should own this ticket?",\n "type": "choice"\n },\n "urgency": {\n "criteria": [\n "Can wait for the next release",\n "Should be fixed this week",\n "Blocking revenue right now"\n ],\n "instructions": "How urgent is this ticket?",\n "type": "score"\n }\n },\n "state": {\n "customer_tier": "enterprise",\n "ticket": "My checkout page shows a blank screen after I click Pay. I have tried two browsers."\n }\n}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_REQUEST_FILE:?Set your actual JSON request file}"\nexport AILOOT_REQUEST_FILE\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads(Path(os.environ['AILOOT_REQUEST_FILE']).read_text(encoding='utf-8'))\nif not isinstance(p,dict): raise SystemExit('Request must be a JSON object')\np['model']='perplexity/pplx-decider-v1.1-27b'\nPath('request.json').write_text(json.dumps(p,ensure_ascii=False),encoding='utf-8')\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/systemone \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nprint(json.dumps(json.loads(Path('result.json').read_text()),ensure_ascii=False,indent=2))\nPY_RESULT\njson
Conservez chaque réponse, fichier et partie de contenu renvoyés dans leur intégralité.
Chaque réponse fournie pour un identifiant de question est conservée avec son type exact, sa valeur noul/choice/score, son degré de confiance, ses probabilités et sa légende. L’intégralité du JSON d’origine est enregistrée et renvoyée uniquement après le règlement.
Conservez l’opération d’origine et la réponse complète ou partielle ; ne rejouez pas le POST.
| Champ | Type |
|---|---|
Champmodel | Typestring |
Champid | Typestring |
Champprovider | Typestring |
Champanswers.<id>.type | Typestring |
Champanswers.<id>.noul | Typenumber |
Champanswers.<id>.choice | Typestring |
Champanswers.<id>.score | Typenumber |
Champanswers.<id>.confidence | Typenumber |
Champanswers.<id>.probabilities | Typeobject |
Champanswers.<id>.legend | Typeobject |
Champusage.input_tokens | Typeinteger |
Champusage.output_tokens | Typeinteger |
Champusage.cost | Typenumber |
| Réponse | Condition | Étape suivante |
|---|---|---|
Réponse400 · invalid_request_error | ConditionChamp obligatoire, représentation ou valeur non valide | Étape suivanteCorrigez le champ de requête indiqué. |
Ailoot Ultra perplexity/pplx-decider-v1.1-27b
Utilisez les chemins de méthode indiqués ci-dessus.