Beheerde runs

Een beheerde run voert je suite uit op de workers van Oloproof in plaats van op je eigen machine, en je volgt hem op de pagina Jobs of in je terminal. Je hebt alleen oloproof login nodig; geen databaseverbinding en geen eigen runner.

Wat een worker uitvoert

Een worker roept je systeem aan over HTTP. Declareer het met http: in oloproof.yaml (Configuratiereferentie):

system:
  name: support-bot
  version: v3
  http:
    url: https://support-bot.example.com/answer
    output_path: answer

Een worker weigert:

• Een systeem callable: of rag:, voordat de job in de wachtrij komt. Dat is jouw code, en de workers van Oloproof voeren geen klantcode uit; voer het uit op je eigen machine (oloproof run) en push de run, of op een runner die je zelf beheert.
• Een antwoordbestand recorded:. Dat blijft op je machine; voer het lokaal uit met oloproof run.
• Een adres dat niet op het publieke internet staat: localhost, een naam met één label, een privé-, link-local- of cloudmetadata-adres. Elke aanroep wordt gecontroleerd op het moment dat hij gebeurt, zodat zo'n case met een fout eindigt in plaats van het te bereiken; een worker bereikt alleen wat iedereen op internet kan bereiken.
• Gegenereerde aanvalscases, tenzij oloproof.yaml adversarial: {sandboxed: true} declareert (Aanvallen genereren). --allow-adversarial geldt alleen voor een lokale run.

Er een starten

oloproof login
oloproof run --cloud --max-runtime 900

run --cloud stuurt de cases van je suite naar de workspace (een beheerde run kan geen cases uitvoeren die hij niet heeft), zet dan de job in de wachtrij en meldt waar je hem volgt. Een suite die de workspace al volledig heeft, wordt niet opnieuw gestuurd.

De worker controleert elke case tegen zijn digest voordat hij de suite bewaart, en weigert een suite die niet overeenkomt. Daarom berekent run --cloud de digests van de cases zonder sleutel, zoals de worker dat doet, ook in een project dat zijn digests met een sleutel maakt om inhoud achter te houden (egress:, Resultaten en uitvoering): de cases worden toch volledig gestuurd, dus een sleutel zou niets verbergen. De suite van de beheerde run is daardoor een andere suite dan die een lokale run van hetzelfde project vastlegt. Een project waarvan de workspace al bewijs met sleutel heeft (uit een push) wordt geweigerd: voer het uit met oloproof run en push de run.

--max-runtime is de deadline van de job in seconden, tot een dag, of de limiet van je abonnement als die kleiner is. Een budget: in oloproof.yaml geldt op een worker net als lokaal.

Wie er een mag starten: een Owner, Admin of Member van de workspace. Een Reviewer mag dat niet.

Hem volgen

De pagina Jobs van het project toont de cases van elke job zodra ze binnenkomen: hoeveel er zijn uitgevoerd en beoordeeld, een telling van geslaagd en mislukt per controle, en de nieuwste cases. De telling is een tussenstand, geen resultaat. De beslissingen vallen zodra de hele run is opgeslagen, en zijn pagina toont ze dan.

In de terminal:

oloproof job JOB_ID --follow

toont om de paar seconden dezelfde tellingen, dan de gate van de run, en stopt met de exitcode van de gate, zodat een pipeline op een beheerde run kan wachten zoals op een lokale (Draaien in CI). Zonder --follow rapporteert job één keer; een job die nog loopt stopt met 2, omdat het nog geen beslissing is. --cancel stopt een wachtende job meteen en een lopende vóór zijn volgende aanroep, waarbij de afgeronde cases behouden blijven.

Sleutels voor een judge

Een judge of een systeem dat een modelaanbieder aanroept, heeft zijn sleutel op de worker nodig. Sla hem één keer op:

export OPENAI_API_KEY=...
oloproof credentials set OPENAI_API_KEY
oloproof credentials list

De sleutel wordt gelezen uit de omgeving of de standaardinvoer, nooit van de opdrachtregel. Hij wordt door de worker versleuteld en is alleen leesbaar voor een worker die de jobs van deze workspace uitvoert; niemand kan hem teruglezen, en credentials list toont alleen namen. De api_key_env: OPENAI_API_KEY van een evaluator vindt hem dan. Een beheerde job leest geen andere omgevingsvariabele. Alleen een Owner of Admin mag een sleutel opslaan.

Wat dit je niet kan vertellen

• Of je systeem zich vanaf het netwerk van Oloproof hetzelfde gedraagt als vanaf het jouwe. Een worker roept je endpoint aan vanaf het publieke internet; rate limits, regio's en allowlists die hem anders behandelen, veranderen wat hij meet.
• Iets over code die een worker niet heeft uitgevoerd. Een beheerde run meet het endpoint dat je hebt genoemd, niet de code erachter.

Elke andere grens op Wat een evaluatie je niet kan vertellen geldt hier ook.