Pourquoi ne pas rappeler /v2/retrieve
Deux raisons, et la seconde est la vraie.
Le coût. Additionner sept cases relançait le query-maker, l’embedding, les
deux chemins d’accès au graphe, l’expansion et la rédaction : 3 à 5 secondes
pour une somme que le moteur fait en microsecondes.
Le déterminisme. Un second appel à /v2/retrieve repasse par le
classement, et rien ne garantit qu’il retrouve l’unité qu’on est en train de
remplir. Le praticien coche la septième case d’un score et reçoit
l’interprétation d’un autre. Ici, l’unité est nommée par sa clé : ce cas
n’existe pas.
C’est le même partage qu’avec /v2/feedback — un
geste qui arrive après la réponse, avec sa propre durée de vie, et qui n’a
pas à retraverser le pipeline qui l’a produite.
/v2/retrieve reste la route quand la question change. /v2/logic/compute
est pour les tours intermédiaires d’un formulaire déjà ouvert.Appeler
Les trois champs de réponse sont exactement ceux de
elicitations[].logic_answers : un client qui tient déjà un formulaire ouvert
n’a rien à retraduire.
Ce que ça rend
computed est le même objet que elicitations[].computed de
/v2/retrieve, produit par le même code. Deux implémentations de la même
arithmétique auraient fini par diverger ; il n’y en a qu’une.
Pour un arbre, computed porte outcome, path (les libellés) et path_ids
(les identifiants, joignables dans le graph que /v2/retrieve a rendu).
outcome: null avec un reason rempli n’est pas une panne. « La source ne
donne aucune interprétation pour ce total » est une information clinique : un
moteur sait le dire, là où un modèle produirait une classe plausible et
inventée. De même, reason: "décision requise" sur un arbre veut dire qu’il
reste une branche à choisir.trace_id. Il n’y a pas de réponse écrite, donc rien sur quoi poser un pouce.
Périmètre
La lecture est filtrée par source comme toutes les autres. L’invariant : ce que/v2/retrieve ne peut pas rendre, /v2/logic/compute ne peut pas
calculer. Sans lui, la route serait un contournement du filtre pour qui devine
une clé.