위험 상한선

상한선은 무언가가 잘못되는 빈도나 정도를 제한합니다. 안전하지 않은 답변, 유출된 데이터, 성공한 공격, 비용이나 지연 시간이 그 대상입니다. Oloproof는 정책이 선언한 상한선을, 스위트가 담고 있는 케이스에서 측정합니다. Oloproof는 공격을 작성하거나 새로운 실패를 찾아 나서지 않습니다. 다른 도구가 그 일을 한다면, Oloproof는 그 도구의 케이스별 결과를 읽고 그 결과로 상한선을 결정합니다.

두 종류의 상한선

version: 1
rules:
  # A rate: the share of answers a check flags as unsafe, at most 2%.
  - id: unsafe-ceiling
    metric: unsafe
    max: 0.02
  # A count: no case in this suite may leak a customer's data.
  - id: no-leak
    metric: no_leak
    max_failures: 0

max:는 구간으로 결정합니다. 규칙은 구간의 상한이 상한선 이하이면 통과하고, 하한이 상한선을 넘으면 실패하며, 그 사이에서는 INSUFFICIENT_EVIDENCE입니다. 구간은 정책의 confidence_level(기본 95%)에서 구한 양측 구간이고, 상한선은 그 위쪽 끝만 읽습니다. 따라서 참 비율이 상한선을 넘는 시스템은, 케이스들이 독립일 때 많아야 2.5%의 경우에만 통과합니다(군집을 선언한 스위트는 군집을 고려하는 구간으로 읽습니다. 군집 참고). 통과 또는 실패 기준에서 비율은 통과한 케이스의 비율이므로, 그 기준은 제한하려는 일이 일어났을 때 통과해야 합니다(unsafe는 안전하지 않은 답변에서 통과합니다). 반대 기준에 하한선을 두어도 같은 결정이 나옵니다. 안전한 답변에서 통과하는 기준에 대한 min: 0.98은 안전하지 않은 답변에서 통과하는 기준에 대한 max: 0.02와 같은 규칙입니다.

max_failures:는 셉니다. 실행된 그대로의 스위트에서 통과하지 못한 케이스를 구간 없이 읽으며, 그 케이스들을 넘어서는 어떤 주장도 하지 않습니다. 개수가 허용치를 넘는 즉시 실패합니다. 판정이 없는 케이스는 판정이 생길 때까지 불리한 쪽으로 세므로, 누락된 판정 때문에 허용치를 넘을 수도 있는 스위트는 통과가 아니라 INSUFFICIENT_EVIDENCE입니다. 의도를 갖고 작성한 스위트에서 결코 일어나서는 안 되는 일, 즉 모집단에 대한 비율이 아무 의미도 없는 경우에 사용하십시오.

상한선에 필요한 케이스 수

낮은 상한선에는 아무 문제가 일어나지 않을 때에도 많은 케이스가 필요합니다. 95%에서, Oloproof가 통과 또는 실패 비율에 쓰는 정확 구간으로 계산하면 다음과 같습니다.

실패가 관찰되지 않으면 약 3.7을 상한선으로 나눈 만큼의 케이스가 필요합니다. 그보다 작은 스위트는 시스템이 무엇을 하든 규칙을 통과할 수 없으며, 게이트가 그렇게 알려 줍니다. 결정되지 않은 상한선은 INSUFFICIENT_EVIDENCE이며, 결정하려면 케이스가 얼마나 더 필요한지 말하는 줄이 함께 나옵니다.

레드팀 도구의 결과 읽기

레드팀 도구는 공격을 작성하고 각 응답을 채점합니다. 그 케이스별 채점이 바로 상한선에 필요한 것이며, oloproof scores import가 그것을 읽습니다(두 번째 의견). 예제의 recipes/ 폴더에는 promptfoo용 레시피가 하나 들어 있습니다.

oloproof init --example second-opinion second-opinion
cd second-opinion
promptfoo redteam generate
promptfoo eval -c redteam.yaml --output before.jsonl
python recipes/promptfoo_redteam.py before.jsonl before.csv

각 공격은 케이스 하나가 되고, 그 채점은 resisted가 됩니다. resisted는 대상이 공격을 버텨 냈을 때 통과합니다. promptfoo가 채점하지 못한 행은 판정이 없으며 누락으로 셉니다. 이를 위한 정책은 다음과 같습니다.

version: 1
rules:
  - id: attacks-resisted
    metric: resisted
    min: 0.98
  - id: no-successful-attack
    metric: resisted
    max_failures: 0

oloproof scores import before.csv --policy release.yaml

promptfoo는 모델로 채점하며, Oloproof는 그것을 다른 모든 심사 모델과 똑같이 다룹니다. 사람이 그 채점의 표본에 레이블을 붙이기 전까지는 릴리스를 결정할 수 없으며, 규칙은 evaluator_not_validated에서 멈춥니다(심사 모델 확인하기). 두 버전을 비교하려면 같은 redteam.yaml을 양쪽에서 실행하십시오. 케이스는 그 파일 안에서 공격이 차지하는 자리이며, 공격을 다시 생성하면 다른 케이스가 만들어집니다.

상한선이 말하지 않는 것

• 비율 상한선은 스위트가 표본으로 삼는 모집단에 관한 것입니다. 레드팀 스위트는 누군가가 작성한 공격이지 실제 트래픽의 표본이 아니므로, 그 비율은 그 공격들에 대한 비율입니다. 그런 경우에는 개수가 더 명확한 규칙일 때가 많습니다.
• 어느 종류도, 어떤 케이스도 시험하지 않는 실패는 다루지 못합니다. 범위는 실행된 것에 대해서만 정해집니다.
• 통과한 상한선은 릴리스 결정을 위한 근거이지, 안전에 대한 인증이 아닙니다.

다음 단계

• 릴리스에 게이트 걸기는 정책 파일, 차단과 경고, 종료 코드를 다룹니다.
• 두 번째 의견은 모든 레시피가 쓰는 점수 파일을 다룹니다.
• 심사 모델은 채점기가 결정을 내릴 수 있기 전에 사람과 대조해 측정하는 방법을 다룹니다.