Decider V1.1 27B est la version actualisée du modèle de décision de Perplexity. Il évalue le contenu fourni au regard d’une question définie et produit des probabilités pour les réponses valides. Son artefact natif possède une tête de lecture des décisions plutôt qu’une tête de génération linguistique sur tout le vocabulaire. Le résultat utile est une distribution de décision délimitée et sa réponse interprétée, plutôt qu’une explication ouverte ou une réponse de chat général.
Perplexity présente ce modèle comme une mise à jour de Decider V1 27B qui conserve la même architecture de base, avec des changements dans la configuration de l’attention et davantage de données d’entraînement. Son architecture de base 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 de la version antérieure.
L’exemple publié fournit une ligne contenant un état et une question typée choice. 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 les probabilités, puis la fonction auxiliaire de réponse du producteur interprète ces probabilités pour la question. L’exemple d’inférence peut traiter une liste de lignes, avec une décision liée aux éléments et à la question de chaque ligne.
Pour l’orientation des demandes, fournissez le message réel et le contexte pertinent, puis définissez les services ou les catégories disponibles. Une tâche illustrative pourrait distinguer un échec d’intégration, un problème d’accès et une demande d’informations produit. Rendez chaque description assez précise pour trancher un cas limite et conservez les définitions des options avec le résultat. Une distribution entre catégories peut ensuite servir à une décision d’orientation ou à une étape de vérification lorsque les alternatives restent proches. Le résultat choisi par le modèle n’exécute pas lui-même l’action du processus.
L’implémentation native accepte des images avec l’état et la question, sous forme de fichiers image, d’images en mémoire ou de données d’image encodées. Pour une image documentaire ou une capture d’écran, fournissez les éléments visuels et posez une question fermée dont les options décrivent les issues pertinentes. Identifiez la caractéristique visible qui compte et fournissez le contexte textuel nécessaire à son interprétation. Par exemple, classez un objet représenté dans l’une des catégories produit fournies, plutôt que de demander au modèle de décision de rédiger une description produit complète.
Le processeur préserve le rapport d’aspect lors du redimensionnement et arrondit les côtés des images à 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 sur 2048. Chaque patch de 32 sur 32 contribue un token visuel ; ce réglage par défaut permet donc jusqu’à 4096 tokens visuels pour une image. Ces chiffres décrivent la préparation native des images du producteur, et non un contrat général de téléversement d’une application.
L’étape prepare documentée exige que le texte et toutes les images d’une même décision tiennent dans 8192 tokens. Une entrée trop volumineuse est rejetée, plutôt que tronquée silencieusement. Plusieurs images partagent ce budget avec l’état écrit et la question. 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 rapportée limitait les images à 512 sur 512, soit 262 144 pixels et jusqu’à 256 tokens visuels. Le plafond d’inférence configurable peut préserver davantage de détails, mais la fiche avertit qu’une résolution supérieure sort de cette distribution d’entraînement et utilise davantage de mémoire et de temps de traitement. Un réglage d’image plus grand ne garantit donc pas une meilleure décision. Gardez une préparation d’entrée cohérente avec la question et examinez si la caractéristique visuelle nécessaire est représentée clairement.
Les couches à attention complète de la version native utilisent un mode d’attention non causal enregistré, tandis que ses couches à attention linéaire conservent leur propre comportement. Le fabricant indique 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 actuels. 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 des décisions séparée distingue aussi 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 de l’attention. Préparez des questions fermées pour le profil natif de décision ; utilisez un modèle de génération adapté lorsque la tâche nécessite du chat, du code, des explications ou des demandes d’outils.
Un artefact final utile garde associés l’état, la question, les réponses autorisées et la distribution obtenue. Définissez la question autour d’éléments réellement présents, examinez les cas ambigus au regard de ces éléments et utilisez des exemples annotés issus de la tâche visée pour décider de l’effet des sorties numériques sur l’orientation 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 un libellé enregistré.
", "aboutText": "Decider V1.1 27B est la version actualisée du modèle de décision de Perplexity. Il évalue le contenu fourni au regard d’une question définie et produit des probabilités pour les réponses valides. Son artefact natif possède une tête de lecture des décisions plutôt qu’une tête de génération linguistique sur tout le vocabulaire. Le résultat utile est une distribution de décision délimitée et sa réponse interprétée, plutôt qu’une explication ouverte ou une réponse de chat général.\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 la même architecture de base, avec des changements dans la configuration de l’attention et davantage de données d’entraînement. Son architecture de base 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 de la version antérieure.\n\n### État, question et réponses valides\n\nL’exemple publié fournit une ligne contenant un état et une question typée choice. 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 les probabilités, puis la fonction auxiliaire de réponse du producteur interprète ces probabilités pour la question. L’exemple d’inférence peut traiter une liste de lignes, avec une décision liée aux éléments et à la question de chaque ligne.\n\nPour l’orientation des demandes, fournissez le message réel et le contexte pertinent, puis définissez les services ou les catégories disponibles. Une tâche illustrative pourrait distinguer un échec d’intégration, un problème d’accès et une demande d’informations produit. Rendez chaque description assez précise pour trancher un cas limite et conservez les définitions des options avec le résultat. Une distribution entre catégories peut ensuite servir à une décision d’orientation ou à une étape de vérification lorsque les alternatives restent proches. Le résultat choisi par le modèle n’exécute pas lui-même l’action du processus.\n\n### Éléments textuels et visuels\n\nL’implémentation native accepte des images avec l’état et la question, sous forme de fichiers image, d’images en mémoire ou de données d’image encodées. Pour une image documentaire ou une capture d’écran, fournissez les éléments visuels et posez une question fermée dont les options décrivent les issues pertinentes. Identifiez la caractéristique visible qui compte et fournissez le contexte textuel nécessaire à son interprétation. Par exemple, classez un objet représenté dans l’une des catégories produit fournies, plutôt que de demander au modèle de décision de rédiger une description produit complète.\n\nLe processeur préserve le rapport d’aspect lors du redimensionnement et arrondit les côtés des images à 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 sur 2048. Chaque patch de 32 sur 32 contribue un token visuel ; ce réglage par défaut permet donc jusqu’à 4096 tokens visuels pour une image. Ces chiffres décrivent la préparation native des images du producteur, et non un contrat général de téléversement d’une application.\n\n### Limites d’entrée combinées et périmètre de résolution\n\nL’étape prepare documentée exige que le texte et toutes les images d’une même décision tiennent dans 8192 tokens. Une entrée trop volumineuse est rejetée, plutôt que tronquée silencieusement. Plusieurs images partagent ce budget avec l’état écrit et la question. 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 rapportée limitait les images à 512 sur 512, soit 262 144 pixels et jusqu’à 256 tokens visuels. Le plafond d’inférence configurable peut préserver davantage de détails, mais la fiche avertit qu’une résolution supérieure sort de cette distribution d’entraînement et utilise davantage de mémoire et de temps de traitement. Un réglage d’image plus grand ne garantit donc pas une meilleure décision. Gardez une préparation d’entrée cohérente avec la question et examinez si la caractéristique visuelle nécessaire est représentée clairement.\n\n### Attention, tête de lecture et calibrage des probabilités\n\nLes couches à attention complète de la version native utilisent un mode d’attention non causal enregistré, tandis que ses couches à attention linéaire conservent leur propre comportement. Le fabricant indique 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 actuels. 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 des décisions séparée distingue aussi 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 de l’attention. Préparez des questions fermées pour le profil natif de décision ; utilisez un modèle de génération adapté lorsque la tâche nécessite du chat, du code, des explications ou des demandes d’outils.\n\nUn artefact final utile garde associés l’état, la question, les réponses autorisées et la distribution obtenue. Définissez la question autour d’éléments réellement présents, examinez les cas ambigus au regard de ces éléments et utilisez des exemples annotés issus de la tâche visée pour décider de l’effet des sorties numériques sur l’orientation 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 un libellé enregistré.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "703a247046e725a93dc34cac04f61c43cf901743865421699ff8a6ee98fb04e8", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "fr-be", "methods": [ { "html": "perplexity/pplx-decider-v1.1-27bDecider V1.1 27B de Perplexity évalue un état et une question fournis, puis renvoie les probabilités des réponses autorisées. Sa version native de décision 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 la version actualisée du modèle de décision de Perplexity. Il évalue le contenu fourni au regard d’une question définie et produit des probabilités pour les réponses valides. Son artefact natif possède une tête de lecture des décisions plutôt qu’une tête de génération linguistique sur tout le vocabulaire. Le résultat utile est une distribution de décision délimitée et sa réponse interprétée, plutôt qu’une explication ouverte ou une réponse de chat général.
Perplexity présente ce modèle comme une mise à jour de Decider V1 27B qui conserve la même architecture de base, avec des changements dans la configuration de l’attention et davantage de données d’entraînement. Son architecture de base 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 de la version antérieure.
L’exemple publié fournit une ligne contenant un état et une question typée choice. 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 les probabilités, puis la fonction auxiliaire de réponse du producteur interprète ces probabilités pour la question. L’exemple d’inférence peut traiter une liste de lignes, avec une décision liée aux éléments et à la question de chaque ligne.
Pour l’orientation des demandes, fournissez le message réel et le contexte pertinent, puis définissez les services ou les catégories disponibles. Une tâche illustrative pourrait distinguer un échec d’intégration, un problème d’accès et une demande d’informations produit. Rendez chaque description assez précise pour trancher un cas limite et conservez les définitions des options avec le résultat. Une distribution entre catégories peut ensuite servir à une décision d’orientation ou à une étape de vérification lorsque les alternatives restent proches. Le résultat choisi par le modèle n’exécute pas lui-même l’action du processus.
L’implémentation native accepte des images avec l’état et la question, sous forme de fichiers image, d’images en mémoire ou de données d’image encodées. Pour une image documentaire ou une capture d’écran, fournissez les éléments visuels et posez une question fermée dont les options décrivent les issues pertinentes. Identifiez la caractéristique visible qui compte et fournissez le contexte textuel nécessaire à son interprétation. Par exemple, classez un objet représenté dans l’une des catégories produit fournies, plutôt que de demander au modèle de décision de rédiger une description produit complète.
Le processeur préserve le rapport d’aspect lors du redimensionnement et arrondit les côtés des images à 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 sur 2048. Chaque patch de 32 sur 32 contribue un token visuel ; ce réglage par défaut permet donc jusqu’à 4096 tokens visuels pour une image. Ces chiffres décrivent la préparation native des images du producteur, et non un contrat général de téléversement d’une application.
L’étape prepare documentée exige que le texte et toutes les images d’une même décision tiennent dans 8192 tokens. Une entrée trop volumineuse est rejetée, plutôt que tronquée silencieusement. Plusieurs images partagent ce budget avec l’état écrit et la question. 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 rapportée limitait les images à 512 sur 512, soit 262 144 pixels et jusqu’à 256 tokens visuels. Le plafond d’inférence configurable peut préserver davantage de détails, mais la fiche avertit qu’une résolution supérieure sort de cette distribution d’entraînement et utilise davantage de mémoire et de temps de traitement. Un réglage d’image plus grand ne garantit donc pas une meilleure décision. Gardez une préparation d’entrée cohérente avec la question et examinez si la caractéristique visuelle nécessaire est représentée clairement.
Les couches à attention complète de la version native utilisent un mode d’attention non causal enregistré, tandis que ses couches à attention linéaire conservent leur propre comportement. Le fabricant indique 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 actuels. 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 des décisions séparée distingue aussi 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 de l’attention. Préparez des questions fermées pour le profil natif de décision ; utilisez un modèle de génération adapté lorsque la tâche nécessite du chat, du code, des explications ou des demandes d’outils.
Un artefact final utile garde associés l’état, la question, les réponses autorisées et la distribution obtenue. Définissez la question autour d’éléments réellement présents, examinez les cas ambigus au regard de ces éléments et utilisez des exemples annotés issus de la tâche visée pour décider de l’effet des sorties numériques sur l’orientation 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 un libellé enregistré.
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 : obligatoire ; noul : facultatif. Les critères choice forment un objet ; score est un tableau avec minItems1. | 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 et déclarée de l’état ou du document. La capacité image du fabricant ne suffit pas à établir un support d’image accepté pour ce modèle. |
Cycle de vie : synchronous
Envoyez l’ID 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 ID de question est conservée avec son type exact, sa valeur noul/choice/score, son niveau de confiance, ses probabilités et sa légende. L’intégralité du JSON d’origine est stockée et renvoyée uniquement après le règlement.
Conservez l’opération d’origine ainsi que 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 invalide | Étape suivanteCorrigez le champ indiqué de la requête. |
Ailoot Ultra perplexity/pplx-decider-v1.1-27b
Utilisez les chemins de méthode indiqués ci-dessus.