Execuções gerenciadas

Uma execução gerenciada executa sua suíte nos workers do Oloproof em vez da sua máquina, e você a acompanha pela página Jobs ou pelo terminal. Você precisa apenas de oloproof login; nenhuma conexão com banco de dados e nenhum runner próprio.

O que um worker executa

Um worker chama seu sistema por HTTP. Declare-o com http: em oloproof.yaml (Configuração):

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

Um worker recusa:

• Um sistema callable: ou rag:, antes de o job entrar na fila. Isso é o seu código, e os workers do Oloproof não executam código de clientes; execute-o na sua própria máquina (oloproof run) e envie a execução, ou em um runner que você opera.
• Um arquivo de respostas recorded:. Ele fica na sua máquina; execute-o localmente com oloproof run.
• Um endereço que não está na internet pública: localhost, um nome de rótulo único, um endereço privado, link-local ou de metadados de nuvem. Cada chamada é verificada no momento em que é feita, então um caso assim dá erro em vez de alcançá-lo; um worker só alcança o que qualquer pessoa na internet alcança.
• Casos de ataque gerados, a menos que oloproof.yaml declare adversarial: {sandboxed: true} (Gerando ataques). --allow-adversarial cobre apenas uma execução local.

Executar uma

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

run --cloud envia os casos da sua suíte ao workspace (uma execução gerenciada não pode executar casos que não tem), depois coloca o job na fila e mostra onde acompanhá-lo. Uma suíte que o workspace já tem inteira não é enviada de novo.

O worker confere cada caso com o seu digest antes de guardar a suíte, e recusa a que não confere. Por isso run --cloud calcula os digests dos casos sem chave, como o worker faz, mesmo em um projeto que usa digests com chave para reter conteúdo (egress:, Resultados e execução): os casos são enviados inteiros de qualquer forma, então uma chave não esconderia nada. A suíte da execução gerenciada é, portanto, uma suíte diferente da que uma execução local do mesmo projeto registra. Um projeto cujo workspace já tem evidência com chave (de um push) é recusado: execute-o com oloproof run e faça o push da execução.

--max-runtime é o prazo do job em segundos, até um dia, ou o limite do seu plano se for menor. Um budget: em oloproof.yaml vale em um worker como vale localmente.

Quem pode executar uma: um Owner, Admin ou Member do workspace. Um Reviewer não pode.

Acompanhar

A página Jobs do projeto mostra os casos de cada job à medida que chegam: quantos foram executados e julgados, uma contagem de aprovações e falhas por verificação, e os casos mais recentes. A contagem é parcial, não um resultado. As decisões são tomadas quando a execução inteira está armazenada, e a página dela então as mostra.

No terminal:

oloproof job JOB_ID --follow

mostra as mesmas contagens a cada poucos segundos, depois o gate da execução, e termina com o código de saída do gate, então um pipeline pode esperar uma execução gerenciada como espera uma local (CI). Sem --follow, job informa uma vez; um job ainda em execução sai com 2, porque ainda não é uma decisão. --cancel interrompe um job na fila imediatamente e um em execução antes da próxima chamada, mantendo os casos que terminaram.

Chaves para um juiz

Um juiz ou um sistema que chama um provedor de modelos precisa da chave no worker. Armazene-a uma vez:

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

A chave é lida do ambiente ou da entrada padrão, nunca da linha de comando. Ela é criptografada pelo worker e só pode ser lida por um worker que executa os jobs deste workspace; ninguém pode lê-la de volta, e credentials list mostra apenas nomes. O api_key_env: OPENAI_API_KEY de um avaliador então a encontra. Um job gerenciado não lê nenhuma outra variável de ambiente. Apenas um Owner ou Admin pode armazenar uma chave.

O que isto não pode dizer

• Se o seu sistema se comporta da mesma forma a partir da rede do Oloproof e da sua. Um worker chama seu endpoint pela internet pública; limites de taxa, regiões e listas de permissão que o tratam de forma diferente mudam o que ele mede.
• Nada sobre código que um worker não executou. Uma execução gerenciada mede o endpoint que você indicou, não o código por trás dele.

Todos os outros limites em O que uma avaliação não pode dizer valem aqui também.