Cas d'usage

Decisions API pour le routage de requêtes

Router est une décision finie : quelle file, quelle priorité, humain ou automatisation. Un appel de décision renvoie le choix plus une probabilité pour chaque option — assignez automatiquement les cas sûrs et envoyez le reste au triage.

Mis à jour

Pourquoi le routage est un cas naturel

Router pose une question finie — laquelle de mes files prend ceci — et c'est exactement ce qu'un endpoint de décisions répond nativement. Pas de nom de file à extraire d'un texte généré, pas d'ingénierie de prompt pour empêcher le modèle d'inventer une cinquième file.

Le même appel peut porter plusieurs questions sur le même ticket : file, urgence et un indicateur de revue se résolvent en un aller-retour pour 1 crédit.

  • Assignation de file : billing, platform, account, other
  • Priorité : un score ordonné de faible à bloquant
  • Escalade : un check noul pour savoir si un humain doit regarder d'abord

Écrivez les criteria comme des descriptions de file

Chaque option d'une question choice porte une courte description de ce qui lui appartient. Rédigez-les comme un brief pour un nouvel analyste de triage — ces descriptions sont votre politique de routage.

Incluez toujours une option 'other' ou 'unclear'. Donner au modèle une sortie honnête évite qu'un ticket ambigu finisse dans la mauvaise file avec une assurance trompeuse.

Un appel : file plus urgence

Envoyez le texte du ticket en state et posez deux questions : un choice pour l'équipe responsable et un score pour l'urgence. La réponse donne answers.team.choice, answers.urgency.score et une probabilité pour chaque option des deux.

Choice + score en une requête

// Route a ticket: ask for team + urgency in one call,
// then gate the automation on confidence.
const res = await fetch("https://decisions-api.net/api/v1/decisions", {
  method: "POST",
  headers: {
    Authorization: "Bearer YOUR_KEY",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "decisions-1",
    state: "Payments fail with a 500 since your last deploy. Enterprise plan customer.",
    questions: {
      team: {
        type: "choice",
        instructions: "Which queue should handle this request?",
        criteria: {
          payments: "Billing, charges, or payment failures.",
          platform: "Deploys, infrastructure, or API errors.",
          account: "Login, SSO, or permissions.",
          other: "Unclear or out of scope.",
        },
      },
      urgency: {
        type: "score",
        instructions: "How urgent is this for the customer?",
        criteria: ["can wait", "normal queue", "needs attention today", "blocking revenue"],
      },
    },
  }),
});
const { answers } = await res.json();

// Illustrative response: answers.team -> { choice: "payments", confidence: 0.84 }
//                        answers.urgency -> { score: 3, confidence: 0.79 } (0 = lowest level)
if (answers.team.confidence >= 0.8 && answers.team.choice !== "other") {
  assignToQueue(answers.team.choice, { priority: answers.urgency.score });
} else {
  assignToQueue("human_triage", { note: "low confidence" });
}

Conditionnez l'auto-assignation à la confiance

La distribution de probabilités rend le routage sûr à automatiser. Un point de départ raisonnable : appliquez le routage quand la confiance est ≥ 0,8, et envoyez tout le reste à une file de triage humain.

Réglez le seuil sur votre propre historique de tickets — la bonne valeur dépend du coût d'un ticket mal routé par rapport à un ticket retardé.

Router les requêtes entre modèles

Le même pattern choisit quel modèle doit répondre. Posez une question choice avec des options comme fast_model (requêtes factuelles courtes ou de formatage), strong_model (raisonnement en plusieurs étapes, code, long contexte) et human (juridique, remboursements, ou tout ce qu'un modèle ne devrait pas traiter seul). Chaque option revient avec une probabilité — vous voyez à quel point le choix était disputé.

Appliquez le même garde-fou : quand la confiance est basse, routez la requête vers une personne ou un chemin plus sûr plutôt que de faire confiance à l'option en tête — la probabilité du second choix indique à quel point la décision était serrée.

Coût et volume

Un appel réussi coûte 1 crédit, pour 1 ou 6 questions. Pour un backlog de tickets historiques, l'outil batch du tableau de bord exécute la même forme de requête sur un CSV ou un JSONL.

FAQ

Vers combien de files puis-je router ?

Une question choice accepte de 2 à 8 options. Si vous routez vers plus de files, divisez la décision : un premier appel choisit le département, un second choisit l'équipe à l'intérieur.

Puis-je router sur l'urgence dans le même appel ?

Oui — ajoutez une question score avec des descriptions de niveaux ordonnées. Un appel peut porter jusqu'à 6 questions : file, urgence et un indicateur d'escalade se résolvent ensemble.

Que se passe-t-il pour un ticket ambigu ?

La réponse inclut une probabilité par option. Quand les deux premières sont proches — disons 0,45 contre 0,42 — traitez le ticket comme ambigu et routez-le vers le triage humain plutôt que de faire confiance au gagnant.

Ça marche pour des tickets non anglais ?

Écrivez le state et les descriptions d'options dans la langue de vos tickets, et gardez les clés d'options en ASCII pour que votre code de routage reste lisible.

Peut-il choisir quel LLM répond à une requête ?

Oui — faites des modèles les options d'une question choice et décrivez les points forts de chacun. Routez les cas à faible confiance vers le modèle le plus puissant.

Routez un ticket maintenant

Une décision d'essai gratuite pour les nouveaux visiteurs — collez un vrai ticket dans le bac à sable et lisez les probabilités.