Upstage Solar Decide est un modèle de décision structurée fondé sur Solar Mini 4. Il lit un état fourni et des questions typées, puis renvoie une décision pour chaque question avec des informations de probabilité calibrées. Le fabricant décrit un processus de décision en une seule passe avant, sans génération de texte. Ses applications visées comprennent l’orientation, la classification et les vérifications de règles, la compréhension du coréen étant mise en avant comme une composante de sa base Solar Mini 4.
Préparez l’état comme une chaîne de caractères ou du JSON structuré décrivant les faits à évaluer. L’interface du fabricant sérialise les valeurs JSON dans le prompt. Un schéma de questions définit séparément ce qu’il faut décider, les options autorisées et l’interprétation d’une évaluation ordonnée. Utilisez des noms stables pour les questions : leurs réponses reviennent sous les mêmes noms, ce qui permet d’associer facilement le résultat à la condition d’origine du processus. Gardez l’état factuel distinct des instructions et des critères définissant la décision.
Les trois types de questions ont des sorties différentes. Une question choice renvoie l’option sélectionnée, les probabilités des alternatives nommées et une valeur de confiance. Une question noul renvoie la probabilité qu’une condition oui/non soit vraie. Une question score renvoie un score pondéré par les probabilités, une légende indexée, des probabilités et la confiance. Un score ordonné peut être fractionnaire, car il reflète la distribution entre les critères. Préservez ces champs, plutôt que de réduire chaque résultat à un simple libellé ou de traiter la confiance comme une phrase explicative.
Pour l’orientation des demandes d’assistance, fournissez le message réel et l’historique pertinent, puis posez des questions séparées sur l’intention, l’urgence et une condition définie, telle que l’expression d’une insatisfaction dans le message. Décrivez les catégories par leur sens et donnez un ordre délibéré à l’échelle d’urgence. Un schéma d’exemple peut distinguer une demande de suivi de livraison, un problème d’accès au compte et une question sans rapport, tandis que les critères d’urgence vont de l’absence d’action immédiate à la vérification immédiate. Le résultat observable est une évaluation typée de ces choix, et non une réponse rédigée au client.
Pour les vérifications de règles, incluez ensemble dans l’état la règle pertinente et les faits du dossier. Définissez chaque condition assez précisément pour pouvoir examiner sa réponse. Un processus documentaire pourrait demander si les informations requises sont présentes, quelle catégorie de vérification s’applique et dans quelle mesure le dossier satisfait une norme de complétude ordonnée. Un score ou une probabilité ne vérifie pas de manière indépendante les faits du dossier. Si des informations décisives manquent, l’application doit prévoir délibérément comment traiter cette incertitude, plutôt que d’interpréter une option sélectionnée comme une preuve concluante.
Le fabricant spécifie une fenêtre de contexte de 512K tokens pour Solar Decide. Préparez les grands documents sous la forme du texte ou de l’état structuré requis pour la décision ; un contexte volumineux n’implique pas l’analyse automatique d’un fichier arbitraire. Préservez les limites des sources et les passages pertinents pour les critères. Utilisez des questions ciblées, plutôt que d’attendre un résumé libre du document. La sortie du modèle reste délimitée par les types de questions et les options, quelle que soit la quantité de matériau incluse dans l’état.
Une question choice accepte de deux à 26 options dans l’interface documentée du producteur. Le fabricant explique que cette voie lit les décisions à partir des libellés A à Z, chacun constitué d’un seul token ; plus de 26 candidats doivent donc être réduits ou répartis entre plusieurs questions. Cette limite s’applique aux options choice ; ce n’est ni une limite générale de longueur documentaire, ni une limite reprise d’une autre famille de modèles de décision. Définissez les descriptions des candidats afin que leurs sens soient distincts et utilisez une décision hiérarchique uniquement lorsque cette hiérarchie correspond au processus réel.
Pour les dossiers en coréen, gardez intacts le sens de la source, les noms et les identifiants, et décrivez clairement les critères de décision. Le résultat typé peut utiliser des libellés stables de l’application tout en évaluant des éléments en langue naturelle. Lorsqu’un dossier mélange les langues ou utilise une terminologie spécialisée, conservez les définitions pertinentes dans l’état. Une interprétation fluide d’un terme ne suffit pas à établir que les critères de classification correspondent à la règle métier ; examinez donc des cas ambigus représentatifs ainsi que des cas simples.
Utilisez les probabilités et la confiance renvoyées selon la politique de décision du processus. Préservez la distribution et la légende ordonnée lorsqu’une évaluation se situe entre des catégories. Définissez le traitement des résultats incertains à partir d’exemples vérifiés de la tâche, plutôt que d’inventer un seuil de probabilité universel. L’application effectue toute action d’orientation, d’escalade ou de vérification qui en découle et enregistre son résultat. Solar Decide fournit l’évaluation délimitée du modèle utilisée pour envisager cette action ; sélectionner une voie n’établit pas qu’une action ultérieure a été exécutée.
L’artefact final utile est l’objet de réponses, accompagné de l’état et des définitions des questions qui l’ont produit. Ces enregistrements permettent d’examiner une classification surprenante, de distinguer des éléments manquants de critères ambigus et de comparer l’évaluation à un cas vérifié. Si un utilisateur a besoin d’une explication écrite ou d’une réponse conversationnelle, la décision et les sources peuvent alimenter une étape de rédaction distincte. Le rôle spécifique de Solar Decide consiste à produire des décisions typées assorties de probabilités à partir du texte fourni, plutôt qu’à générer cette explication lui-même.
", "aboutText": "Upstage Solar Decide est un modèle de décision structurée fondé sur Solar Mini 4. Il lit un état fourni et des questions typées, puis renvoie une décision pour chaque question avec des informations de probabilité calibrées. Le fabricant décrit un processus de décision en une seule passe avant, sans génération de texte. Ses applications visées comprennent l’orientation, la classification et les vérifications de règles, la compréhension du coréen étant mise en avant comme une composante de sa base Solar Mini 4.\n\nPréparez l’état comme une chaîne de caractères ou du JSON structuré décrivant les faits à évaluer. L’interface du fabricant sérialise les valeurs JSON dans le prompt. Un schéma de questions définit séparément ce qu’il faut décider, les options autorisées et l’interprétation d’une évaluation ordonnée. Utilisez des noms stables pour les questions : leurs réponses reviennent sous les mêmes noms, ce qui permet d’associer facilement le résultat à la condition d’origine du processus. Gardez l’état factuel distinct des instructions et des critères définissant la décision.\n\nLes trois types de questions ont des sorties différentes. Une question choice renvoie l’option sélectionnée, les probabilités des alternatives nommées et une valeur de confiance. Une question noul renvoie la probabilité qu’une condition oui/non soit vraie. Une question score renvoie un score pondéré par les probabilités, une légende indexée, des probabilités et la confiance. Un score ordonné peut être fractionnaire, car il reflète la distribution entre les critères. Préservez ces champs, plutôt que de réduire chaque résultat à un simple libellé ou de traiter la confiance comme une phrase explicative.\n\nPour l’orientation des demandes d’assistance, fournissez le message réel et l’historique pertinent, puis posez des questions séparées sur l’intention, l’urgence et une condition définie, telle que l’expression d’une insatisfaction dans le message. Décrivez les catégories par leur sens et donnez un ordre délibéré à l’échelle d’urgence. Un schéma d’exemple peut distinguer une demande de suivi de livraison, un problème d’accès au compte et une question sans rapport, tandis que les critères d’urgence vont de l’absence d’action immédiate à la vérification immédiate. Le résultat observable est une évaluation typée de ces choix, et non une réponse rédigée au client.\n\nPour les vérifications de règles, incluez ensemble dans l’état la règle pertinente et les faits du dossier. Définissez chaque condition assez précisément pour pouvoir examiner sa réponse. Un processus documentaire pourrait demander si les informations requises sont présentes, quelle catégorie de vérification s’applique et dans quelle mesure le dossier satisfait une norme de complétude ordonnée. Un score ou une probabilité ne vérifie pas de manière indépendante les faits du dossier. Si des informations décisives manquent, l’application doit prévoir délibérément comment traiter cette incertitude, plutôt que d’interpréter une option sélectionnée comme une preuve concluante.\n\nLe fabricant spécifie une fenêtre de contexte de 512K tokens pour Solar Decide. Préparez les grands documents sous la forme du texte ou de l’état structuré requis pour la décision ; un contexte volumineux n’implique pas l’analyse automatique d’un fichier arbitraire. Préservez les limites des sources et les passages pertinents pour les critères. Utilisez des questions ciblées, plutôt que d’attendre un résumé libre du document. La sortie du modèle reste délimitée par les types de questions et les options, quelle que soit la quantité de matériau incluse dans l’état.\n\nUne question choice accepte de deux à 26 options dans l’interface documentée du producteur. Le fabricant explique que cette voie lit les décisions à partir des libellés A à Z, chacun constitué d’un seul token ; plus de 26 candidats doivent donc être réduits ou répartis entre plusieurs questions. Cette limite s’applique aux options choice ; ce n’est ni une limite générale de longueur documentaire, ni une limite reprise d’une autre famille de modèles de décision. Définissez les descriptions des candidats afin que leurs sens soient distincts et utilisez une décision hiérarchique uniquement lorsque cette hiérarchie correspond au processus réel.\n\nPour les dossiers en coréen, gardez intacts le sens de la source, les noms et les identifiants, et décrivez clairement les critères de décision. Le résultat typé peut utiliser des libellés stables de l’application tout en évaluant des éléments en langue naturelle. Lorsqu’un dossier mélange les langues ou utilise une terminologie spécialisée, conservez les définitions pertinentes dans l’état. Une interprétation fluide d’un terme ne suffit pas à établir que les critères de classification correspondent à la règle métier ; examinez donc des cas ambigus représentatifs ainsi que des cas simples.\n\nUtilisez les probabilités et la confiance renvoyées selon la politique de décision du processus. Préservez la distribution et la légende ordonnée lorsqu’une évaluation se situe entre des catégories. Définissez le traitement des résultats incertains à partir d’exemples vérifiés de la tâche, plutôt que d’inventer un seuil de probabilité universel. L’application effectue toute action d’orientation, d’escalade ou de vérification qui en découle et enregistre son résultat. Solar Decide fournit l’évaluation délimitée du modèle utilisée pour envisager cette action ; sélectionner une voie n’établit pas qu’une action ultérieure a été exécutée.\n\nL’artefact final utile est l’objet de réponses, accompagné de l’état et des définitions des questions qui l’ont produit. Ces enregistrements permettent d’examiner une classification surprenante, de distinguer des éléments manquants de critères ambigus et de comparer l’évaluation à un cas vérifié. Si un utilisateur a besoin d’une explication écrite ou d’une réponse conversationnelle, la décision et les sources peuvent alimenter une étape de rédaction distincte. Le rôle spécifique de Solar Decide consiste à produire des décisions typées assorties de probabilités à partir du texte fourni, plutôt qu’à générer cette explication lui-même.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "05039b58dbfe59085122434d693d0c92c2ad3c08c660aaf1d732ef384167ed34", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "fr-ca", "methods": [ { "html": "upstage/solar-decideUpstage Solar Decide est un modèle de décision textuelle fondé sur Solar Mini 4. Il évalue un état fourni et des questions typées, puis renvoie des choix nommés, des probabilités que les conditions soient vraies ou des scores pondérés, avec des informations de probabilité. Sa sortie délimitée sert à la classification, à l’orientation et aux vérifications de règles, plutôt qu’à la génération de texte.
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.
Upstage Solar Decide est un modèle de décision structurée fondé sur Solar Mini 4. Il lit un état fourni et des questions typées, puis renvoie une décision pour chaque question avec des informations de probabilité calibrées. Le fabricant décrit un processus de décision en une seule passe avant, sans génération de texte. Ses applications visées comprennent l’orientation, la classification et les vérifications de règles, la compréhension du coréen étant mise en avant comme une composante de sa base Solar Mini 4.
Préparez l’état comme une chaîne de caractères ou du JSON structuré décrivant les faits à évaluer. L’interface du fabricant sérialise les valeurs JSON dans le prompt. Un schéma de questions définit séparément ce qu’il faut décider, les options autorisées et l’interprétation d’une évaluation ordonnée. Utilisez des noms stables pour les questions : leurs réponses reviennent sous les mêmes noms, ce qui permet d’associer facilement le résultat à la condition d’origine du processus. Gardez l’état factuel distinct des instructions et des critères définissant la décision.
Les trois types de questions ont des sorties différentes. Une question choice renvoie l’option sélectionnée, les probabilités des alternatives nommées et une valeur de confiance. Une question noul renvoie la probabilité qu’une condition oui/non soit vraie. Une question score renvoie un score pondéré par les probabilités, une légende indexée, des probabilités et la confiance. Un score ordonné peut être fractionnaire, car il reflète la distribution entre les critères. Préservez ces champs, plutôt que de réduire chaque résultat à un simple libellé ou de traiter la confiance comme une phrase explicative.
Pour l’orientation des demandes d’assistance, fournissez le message réel et l’historique pertinent, puis posez des questions séparées sur l’intention, l’urgence et une condition définie, telle que l’expression d’une insatisfaction dans le message. Décrivez les catégories par leur sens et donnez un ordre délibéré à l’échelle d’urgence. Un schéma d’exemple peut distinguer une demande de suivi de livraison, un problème d’accès au compte et une question sans rapport, tandis que les critères d’urgence vont de l’absence d’action immédiate à la vérification immédiate. Le résultat observable est une évaluation typée de ces choix, et non une réponse rédigée au client.
Pour les vérifications de règles, incluez ensemble dans l’état la règle pertinente et les faits du dossier. Définissez chaque condition assez précisément pour pouvoir examiner sa réponse. Un processus documentaire pourrait demander si les informations requises sont présentes, quelle catégorie de vérification s’applique et dans quelle mesure le dossier satisfait une norme de complétude ordonnée. Un score ou une probabilité ne vérifie pas de manière indépendante les faits du dossier. Si des informations décisives manquent, l’application doit prévoir délibérément comment traiter cette incertitude, plutôt que d’interpréter une option sélectionnée comme une preuve concluante.
Le fabricant spécifie une fenêtre de contexte de 512K tokens pour Solar Decide. Préparez les grands documents sous la forme du texte ou de l’état structuré requis pour la décision ; un contexte volumineux n’implique pas l’analyse automatique d’un fichier arbitraire. Préservez les limites des sources et les passages pertinents pour les critères. Utilisez des questions ciblées, plutôt que d’attendre un résumé libre du document. La sortie du modèle reste délimitée par les types de questions et les options, quelle que soit la quantité de matériau incluse dans l’état.
Une question choice accepte de deux à 26 options dans l’interface documentée du producteur. Le fabricant explique que cette voie lit les décisions à partir des libellés A à Z, chacun constitué d’un seul token ; plus de 26 candidats doivent donc être réduits ou répartis entre plusieurs questions. Cette limite s’applique aux options choice ; ce n’est ni une limite générale de longueur documentaire, ni une limite reprise d’une autre famille de modèles de décision. Définissez les descriptions des candidats afin que leurs sens soient distincts et utilisez une décision hiérarchique uniquement lorsque cette hiérarchie correspond au processus réel.
Pour les dossiers en coréen, gardez intacts le sens de la source, les noms et les identifiants, et décrivez clairement les critères de décision. Le résultat typé peut utiliser des libellés stables de l’application tout en évaluant des éléments en langue naturelle. Lorsqu’un dossier mélange les langues ou utilise une terminologie spécialisée, conservez les définitions pertinentes dans l’état. Une interprétation fluide d’un terme ne suffit pas à établir que les critères de classification correspondent à la règle métier ; examinez donc des cas ambigus représentatifs ainsi que des cas simples.
Utilisez les probabilités et la confiance renvoyées selon la politique de décision du processus. Préservez la distribution et la légende ordonnée lorsqu’une évaluation se situe entre des catégories. Définissez le traitement des résultats incertains à partir d’exemples vérifiés de la tâche, plutôt que d’inventer un seuil de probabilité universel. L’application effectue toute action d’orientation, d’escalade ou de vérification qui en découle et enregistre son résultat. Solar Decide fournit l’évaluation délimitée du modèle utilisée pour envisager cette action ; sélectionner une voie n’établit pas qu’une action ultérieure a été exécutée.
L’artefact final utile est l’objet de réponses, accompagné de l’état et des définitions des questions qui l’ont produit. Ces enregistrements permettent d’examiner une classification surprenante, de distinguer des éléments manquants de critères ambigus et de comparer l’évaluation à un cas vérifié. Si un utilisateur a besoin d’une explication écrite ou d’une réponse conversationnelle, la décision et les sources peuvent alimenter une étape de rédaction distincte. Le rôle spécifique de Solar Decide consiste à produire des décisions typées assorties de probabilités à partir du texte fourni, plutôt qu’à générer cette explication lui-même.
POST /v1/systemonetextdecisions| Champ | Type | Exigence | Valeurs et limites | Par défaut |
|---|---|---|---|---|
Champmodel | Typestring | ExigenceObligatoire | Valeurs et limites upstage/solar-decide | 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 : requis; noul : facultatif. Les critères de 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 |
Paramètreoptional_controls | Contratprovider, session_id, trace, user |
Paramètremultimodal_input_binding | Contratnull |
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 | Jetons de contexte, plus de | Jetons de contexte, jusqu’à la limite incluse | Coût |
|---|---|---|---|---|
| ConfigurationTarifs de base des jetons | Barème tarifaireTarif de base | Jetons de contexte, plus de— | Jetons de contexte, jusqu’à la limite incluseSans borne supérieure | Coût Entrée · Jetons en entrée $0.0002 / 1K jetons Sortie · Jetons en sortie $0 / 1K jetons Entrée · Lecture du cache $0.0002 / 1K jetons Entrée · Écriture dans le cache — / 1K jetons Entrée · Écriture dans le cache, 1 h — / 1K jetons |
| ConfigurationPalier 1 de longueur de requête | Barème tarifaire— | Jetons de contexte, plus de0 | Jetons de contexte, jusqu’à la limite incluseSans borne supérieure | Coût Entrée · Jetons en entrée $0.0002 / 1K jetons Sortie · Jetons en sortie $0 / 1K jetons Entrée · Lecture du cache $0.0002 / 1K jetons Entrée · Écriture dans le cache — / 1K jetons Entrée · Écriture dans le cache, 1 h — / 1K jetons |
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": "upstage/solar-decide",\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']='upstage/solar-decide'\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, sa confiance, ses probabilités et sa légende. Le JSON d’origine complet est stocké et retourné uniquement après le règlement.
Conservez l’opération d’origine et la réponse complète ou partielle; ne rejouez pas la demande 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 requis, représentation ou valeur invalide | Étape suivanteCorrigez le champ de demande indiqué. |
Ailoot Ultra upstage/solar-decide
Utilisez les chemins de méthode indiqués ci-dessus.