Handleidingen
Kiezen tussen kandidaten
oloproof select kiest uit meerdere versies van een systeem de beste die aan elke eis voldoet, en zegt apart of die echt voor ligt op de volgende. Gebruik het als u bijvoorbeeld drie agents, twee prompts of vier retrieval-instellingen hebt, en één set eisen.
Waarom niet de beste cijfers kiezen
De goedkoopste kandidaat kiezen waarvan de cijfers de drempels halen, heeft twee problemen. Een gemeten 91% tegen een drempel van 90% ligt één punt erboven, binnen de ruis van duizend cases. En als je naar meerdere kandidaten kijkt, is degene die de drempel door geluk haalde precies degene die je kiest. Daarom moet elke kandidaat eerst elke regel op eigen kracht vaststellen, met een strenger betrouwbaarheidsniveau omdat er meerdere bekeken worden: met drie kandidaten en een policy van 95% wordt elk beslist op 98.33% (1 - 0.05/3). Alleen de kandidaten die elke regel halen worden gerangschikt, en een goedkopere kan nooit een veiligheidsregel inruilen voor zijn kosten.
Een selectie declareren
Schrijf een selectiebestand naast je project en beslis het onder de release.yaml van het project:
select:
candidates:
agent_a: run_01JC8Q2X7D
agent_b: agent_b.yaml
agent_c: agent_c.yaml
objective:
metric: cost_per_task
direction: minimizeEen kandidaat is een opgeslagen run-id, of een projectbestand dat oloproof select eerst uitvoert. Een run die het kan hergebruiken kost niets nieuws. De policy mag alleen run-regels bevatten, en vroegtijdig stoppen moet uit staan.
oloproof select select.yaml
oloproof select select.yaml --save--save schrijft de selectie ook voor de lokale workbench, onder Candidates.
Het antwoord lezen
Er zijn drie uitkomsten:
- Een kandidaat wordt gekozen en zijn voorsprong op de tweede is vastgesteld: de gepaarde vergelijking van de twee op het doel is PASS.
- Een kandidaat wordt gekozen en zijn voorsprong is niet vastgesteld: de tweede was op dit bewijs een even verdedigbare keuze geweest.
- Geen kandidaat kwalificeert zich: de regels van elke kandidaat worden met hun antwoorden opgesomd, zodat je ziet wat ontbreekt.
Het commando eindigt met 0 als een kandidaat gekozen is en met 3 als er geen kwalificeert.
Een uitgewerkt voorbeeld
Drie agents moeten een succespercentage van minstens 90% halen en een overtredingspercentage van hoogstens 1%; het doel is de laagste kosten per taak.
| Agent | Succes | Overtredingen | Kosten per taak |
|---|---|---|---|
| A | 94% | 0.5% | $18 |
| B | 91% | 0.1% | $12 |
| C | 96% | 2% | $30 |
Elk wordt beslist op 98.33%. Bij 1,000 cases kwalificeert geen agent: het overtredingspercentage van A is nog niet onder 1% aangetoond, de 91% van B ligt te dicht bij 90% om vastgesteld te zijn, en C doorbreekt het plafond voor overtredingen. Het antwoord is "geen kandidaat kwalificeert zich", met wat elk ontbreekt. Bij 3,000 cases stelt A beide regels vast en wordt gekozen. B is goedkoper, maar zijn succes is nog steeds niet vastgesteld, dus hij wordt nooit gerangschikt: B kiezen op zijn cijfers zou een eis uitbrengen die niemand heeft aangetoond.
Een selectie delen
oloproof select select.yaml --save bewaart de selectie voor de workbench. oloproof push --selection ID stuurt haar met de run van elke kandidaat naar de gehoste workspace, via het egressbeleid van het project; ID is de mapnaam onder .oloproof/bundles/ of de digest van de selectie. Voordat de workspace de selectie bewaart, maakt hij haar opnieuw uit de runs die hij heeft, onder het beleid waaronder die runs zijn beslist, en bewaart haar alleen als het resultaat hetzelfde is: een selectie waarvan het resultaat of de zinnen zijn bewerkt, die een run noemt die het project niet heeft, of die de engine uit die runs niet maakt, wordt geweigerd, en er wordt niets opgeslagen. Beslis de runs van de kandidaten dus onder het beleid van de selectie voordat u ze pusht. De pagina Candidates van het project toont haar, en haar pagina laat haar precies zo zien als de lokale workbench.
Een Owner of Admin kan er vanaf de pagina van de selectie een bewijspagina van maken: de uitkomst, het niveau en per kandidaat de naam, het run-id en de regels op het gecorrigeerde niveau, met het label "Reported by the developer", nooit de inhoud van een case.
Verder
- Vergelijkingsregels behandelt de gepaarde vergelijking die de voorsprong beslist.
- Gating behandelt de regels waaraan elke kandidaat gehouden wordt.