Guides

Choisir parmi des candidats

oloproof select choisit, parmi plusieurs versions d’un système, la meilleure qui satisfait chaque exigence, et dit à part si elle devance vraiment la suivante. Utilisez-le quand vous avez, par exemple, trois agents, deux prompts ou quatre réglages de recherche, et un seul ensemble d’exigences.

Pourquoi ne pas prendre les meilleurs chiffres

Prendre le candidat le moins cher dont les chiffres franchissent les seuils pose deux problèmes. Un 91 % mesuré face à un seuil de 90 % n’est qu’un point au-dessus, dans le bruit de mille cas. Et quand vous regardez plusieurs candidats, celui qui a franchi le seuil par chance est celui que vous choisissez. Chaque candidat doit donc d’abord établir chaque règle à lui seul, à un niveau de confiance plus strict parce que plusieurs sont examinés : avec trois candidats et une politique à 95 %, chacun est décidé à 98.33% (1 - 0.05/3). Seuls les candidats qui passent toutes les règles sont classés, et un candidat moins cher ne peut jamais échanger une règle de sécurité contre son coût.

Déclarer une sélection

Écrivez un fichier de sélection à côté de votre projet, et décidez-le sous le release.yaml du projet :

select:
  candidates:
    agent_a: run_01JC8Q2X7D
    agent_b: agent_b.yaml
    agent_c: agent_c.yaml
  objective:
    metric: cost_per_task
    direction: minimize

Un candidat est un identifiant d’exécution stocké, ou un fichier de projet que oloproof select exécute d’abord. Une exécution qu’il peut réutiliser ne coûte rien de nouveau. La politique ne peut contenir que des règles d’exécution, et l’arrêt anticipé doit être désactivé.

oloproof select select.yaml
oloproof select select.yaml --save

--save écrit aussi la sélection pour le workbench local, sous Candidates.

Lire la réponse

Il y a trois issues :

Un candidat est sélectionné et son avance sur le suivant est établie : la comparaison appariée des deux sur l’objectif donne PASS.
Un candidat est sélectionné et son avance n’est pas établie : le suivant aurait été un choix tout aussi défendable sur ces preuves.
Aucun candidat ne se qualifie : les règles de chaque candidat sont listées avec leurs réponses, pour que vous voyiez ce qui manque.

La commande sort avec 0 quand un candidat est sélectionné et 3 quand aucun ne se qualifie.

Un exemple détaillé

Trois agents doivent atteindre un taux de succès d’au moins 90 % et un taux de violations d’au plus 1 % ; l’objectif est le coût par tâche le plus bas.

Agent	Succès	Violations	Coût par tâche
A	94%	0.5%	$18
B	91%	0.1%	$12
C	96%	2%	$30

Chacun est décidé à 98.33%. À 1,000 cas, aucun agent ne se qualifie : le taux de violations de A n’est pas encore montré sous 1 %, le 91 % de B est trop proche de 90 % pour être établi, et C dépasse le plafond de violations. La réponse est « aucun candidat ne se qualifie », avec ce qui manque à chacun. À 3,000 cas, A établit les deux règles et est sélectionné. B est moins cher, mais son succès n’est toujours pas établi, donc il n’est jamais classé : choisir B sur ses chiffres livrerait une exigence que personne n’a démontrée.

oloproof select select.yaml --save garde la sélection pour le workbench. oloproof push --selection ID l’envoie à l’espace de travail hébergé avec l’exécution de chaque candidat, à travers la politique d’egress du projet ; ID est le nom du dossier sous .oloproof/bundles/ ou le digest de la sélection. Avant de garder la sélection, l’espace de travail la refait à partir des exécutions qu’il détient, sous la politique sous laquelle ces exécutions ont été décidées, et ne la garde que si le résultat est le même : une sélection dont le résultat ou les phrases ont été modifiés, qui nomme une exécution que le projet ne détient pas, ou que le moteur ne fait pas à partir de ces exécutions, est refusée, et rien n’est stocké. Décidez donc les exécutions des candidats sous la politique de la sélection avant de les envoyer. La page Candidates du projet la liste, et sa page l’affiche exactement comme le workbench local.

Un Owner ou un Admin peut en faire une page de preuves depuis la page de la sélection : le résultat, le niveau, et pour chaque candidat son nom, l’identifiant de son exécution et ses règles au niveau corrigé, avec la mention « Reported by the developer », jamais le contenu d’un cas.

Ensuite