Zum Inhalt springen

Anleitungen

Unter Kandidaten wählen

oloproof select wählt unter mehreren Versionen eines Systems die beste, die jede Anforderung erfüllt, und sagt gesondert, ob sie wirklich vor der nächsten liegt. Nutzen Sie es, wenn Sie etwa drei Agenten, zwei Prompts oder vier Retrieval-Einstellungen haben und einen Satz Anforderungen.

Warum nicht die besten Zahlen nehmen

Den billigsten Kandidaten zu nehmen, dessen Zahlen die Schwellen überschreiten, hat zwei Probleme. Gemessene 91 % gegen eine Schwelle von 90 % liegen einen Punkt darüber, im Rauschen von tausend Fällen. Und wenn Sie mehrere Kandidaten ansehen, ist der, der die Schwelle durch Glück überschritt, genau der, den Sie wählen. Deshalb muss jeder Kandidat zuerst jede Regel für sich belegen, mit einem strengeren Konfidenzniveau, weil mehrere betrachtet werden: Bei drei Kandidaten und einer Policy mit 95 % wird jeder bei 98.33% (1 - 0.05/3) entschieden. Nur die Kandidaten, die jede Regel bestehen, werden gereiht, und ein billigerer kann nie eine Sicherheitsregel gegen seine Kosten tauschen.

Eine Auswahl deklarieren

Schreiben Sie eine Auswahldatei neben Ihr Projekt und entscheiden Sie sie unter der release.yaml des Projekts:

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

Ein Kandidat ist eine gespeicherte Run-ID oder eine Projektdatei, die oloproof select zuerst ausführt. Ein Run, den es wiederverwenden kann, kostet nichts Neues. Die Policy darf nur Run-Regeln enthalten, und das frühe Stoppen muss aus sein.

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

--save schreibt die Auswahl außerdem für die lokale Workbench, unter Candidates.

Die Antwort lesen

Es gibt drei Ergebnisse:

  • Ein Kandidat wird ausgewählt und sein Vorsprung vor dem Zweitplatzierten ist belegt: Der gepaarte Vergleich der beiden beim Ziel ist PASS.
  • Ein Kandidat wird ausgewählt und sein Vorsprung ist nicht belegt: Der Zweitplatzierte wäre auf dieser Evidenz eine ebenso vertretbare Wahl gewesen.
  • Kein Kandidat qualifiziert sich: Die Regeln jedes Kandidaten werden mit ihren Antworten aufgelistet, sodass Sie sehen, was fehlt.

Der Befehl endet mit 0, wenn ein Kandidat ausgewählt wird, und mit 3, wenn sich keiner qualifiziert.

Ein durchgerechnetes Beispiel

Drei Agenten müssen eine Erfolgsrate von mindestens 90 % und eine Verstoßrate von höchstens 1 % erreichen; das Ziel sind die niedrigsten Kosten pro Aufgabe.

AgentErfolgVerstößeKosten pro Aufgabe
A94%0.5%$18
B91%0.1%$12
C96%2%$30

Jeder wird bei 98.33% entschieden. Bei 1,000 Fällen qualifiziert sich kein Agent: Die Verstoßrate von A ist noch nicht als unter 1 % gezeigt, die 91 % von B liegen zu nah an 90 %, um belegt zu sein, und C überschreitet die Obergrenze für Verstöße. Die Antwort lautet „kein Kandidat qualifiziert sich“, mit dem, was jedem fehlt. Bei 3,000 Fällen belegt A beide Regeln und wird ausgewählt. B ist billiger, aber sein Erfolg ist weiterhin nicht belegt, daher wird er nie gereiht: B nach seinen Zahlen zu wählen, würde eine Anforderung ausliefern, die niemand gezeigt hat.

Eine Auswahl teilen

oloproof select select.yaml --save bewahrt die Auswahl für die Workbench auf. oloproof push --selection ID sendet sie mit dem Run jedes Kandidaten an den gehosteten Workspace, durch die Egress-Richtlinie des Projekts; ID ist der Ordnername unter .oloproof/bundles/ oder der Digest der Auswahl. Bevor der Workspace die Auswahl behält, trifft er sie erneut aus den Runs, die er hält, unter der Richtlinie, unter der diese Runs entschieden wurden, und behält sie nur, wenn das Ergebnis gleich ist: Eine Auswahl, deren Ergebnis oder Sätze verändert wurden, die einen Run nennt, den das Projekt nicht hält, oder die die Engine aus diesen Runs nicht trifft, wird abgelehnt, und nichts wird gespeichert. Entscheiden Sie die Runs der Kandidaten also unter der Richtlinie der Auswahl, bevor Sie sie pushen. Die Seite Candidates des Projekts listet sie auf, und ihre Seite zeigt sie genau so wie die lokale Workbench.

Ein Owner oder Admin kann auf der Seite der Auswahl eine Evidenzseite daraus machen: das Ergebnis, das Niveau und für jeden Kandidaten Name, Run-ID und Regeln auf dem korrigierten Niveau, mit dem Hinweis "Reported by the developer", nie Inhalte eines Falls.

Weiter

  • Vergleichsregeln behandelt den gepaarten Vergleich, der den Vorsprung entscheidet.
  • Gating behandelt die Regeln, an die jeder Kandidat gebunden ist.