Uruchomienia zarządzane

Uruchomienie zarządzane wykonuje Twój zestaw na workerach Oloproof zamiast na Twojej maszynie, a Ty obserwujesz je na stronie Jobs lub w terminalu. Potrzebujesz tylko oloproof login; żadnego połączenia z bazą danych i żadnego własnego runnera.

Co uruchomi worker

Worker wywołuje Twój system przez HTTP. Zadeklaruj go za pomocą http: w oloproof.yaml (Konfiguracja):

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

Worker odmawia:

• Systemu callable: lub rag:, zanim job trafi do kolejki. To Twój kod, a workery Oloproof nie uruchamiają kodu klientów; uruchom go na własnej maszynie (oloproof run) i wyślij uruchomienie albo na runnerze, który sam obsługujesz.
• Pliku odpowiedzi recorded:. Zostaje on na Twojej maszynie; uruchom go lokalnie przez oloproof run.
• Adresu, który nie jest w publicznym internecie: localhost, nazwy jednoczłonowej, adresu prywatnego, link-local lub adresu metadanych chmury. Każde wywołanie jest sprawdzane w chwili wykonania, więc taki przypadek kończy się błędem, zamiast do niego dotrzeć; worker dociera tylko tam, gdzie może dotrzeć każdy w internecie.
• Wygenerowanych przypadków ataków, chyba że oloproof.yaml deklaruje adversarial: {sandboxed: true} (Generowanie ataków). --allow-adversarial dotyczy tylko uruchomienia lokalnego.

Uruchom jedno

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

run --cloud wysyła przypadki Twojego zestawu do workspace'u (uruchomienie zarządzane nie może wykonać przypadków, których nie ma), następnie umieszcza job w kolejce i wypisuje, gdzie go obserwować. Zestaw, który workspace ma już w całości, nie jest wysyłany ponownie.

Worker sprawdza każdy przypadek względem jego skrótu, zanim zachowa zestaw, i odrzuca taki, który się nie zgadza. Dlatego run --cloud liczy skróty przypadków bez klucza, tak jak worker, nawet w projekcie, który kluczuje swoje skróty, aby wstrzymać treść (egress:, Wyniki i wykonanie): przypadki i tak są wysyłane w całości, więc klucz niczego by nie ukrył. Zestaw uruchomienia zarządzanego jest więc innym zestawem niż ten, który rejestruje lokalne uruchomienie tego samego projektu. Projekt, którego workspace ma już dowody z kluczem (z pusha), jest odrzucany: uruchom go przez oloproof run i wypchnij uruchomienie.

--max-runtime to termin joba w sekundach, do jednej doby, lub limit Twojego planu, jeśli jest mniejszy. budget: w oloproof.yaml obowiązuje na workerze tak samo jak lokalnie.

Kto może je uruchomić: Owner, Admin lub Member workspace'u. Reviewer nie może.

Obserwuj je

Strona Jobs projektu pokazuje przypadki każdego joba w miarę ich napływania: ile zostało uruchomionych i ocenionych, liczbę zaliczeń i niepowodzeń dla każdego sprawdzenia oraz najnowsze przypadki. Ta liczba to stan na teraz, a nie wynik. Decyzje zapadają, gdy całe uruchomienie zostanie zapisane, i wtedy pokazuje je jego strona.

W terminalu:

oloproof job JOB_ID --follow

wypisuje te same liczby co kilka sekund, potem gate uruchomienia, i kończy się kodem wyjścia gate'u, więc pipeline może czekać na uruchomienie zarządzane tak jak na lokalne (CI). Bez --follow polecenie job raportuje raz; job wciąż działający kończy się kodem 2, bo nie jest jeszcze decyzją. --cancel zatrzymuje job w kolejce od razu, a działający przed jego następnym wywołaniem, zachowując zakończone przypadki.

Klucze dla sędziego

Sędzia lub system wywołujący dostawcę modeli potrzebuje swojego klucza na workerze. Zapisz go raz:

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

Klucz jest odczytywany ze środowiska lub ze standardowego wejścia, nigdy z wiersza poleceń. Jest szyfrowany przez workera i czytelny tylko dla workera wykonującego joby tego workspace'u; nikt nie może go odczytać z powrotem, a credentials list pokazuje tylko nazwy. api_key_env: OPENAI_API_KEY ewaluatora następnie go znajduje. Job zarządzany nie odczytuje żadnej innej zmiennej środowiskowej. Klucz może zapisać tylko Owner lub Admin.

Czego to nie powie

• Czy Twój system zachowuje się tak samo z sieci Oloproof jak z Twojej. Worker wywołuje Twój endpoint z publicznego internetu; limity zapytań, regiony i listy dozwolonych adresów, które traktują go inaczej, zmieniają to, co mierzy.
• Niczego o kodzie, którego worker nie uruchomił. Uruchomienie zarządzane mierzy wskazany endpoint, a nie kod za nim.

Każde inne ograniczenie ze strony Czego ewaluacja nie powie obowiązuje także tutaj.