프론티어 AI 학습 안전 사례를 위한 OpenAI 프레임워크

OpenAI는 프론티어 강화 학습(RL) 학습 실행을 지속하기 위한 전제 조건으로 "안전 사례(safety cases)"라고 불리는 구조화된 안전 문서 도입을 옹호하고 있습니다. 이러한 안전 사례는 AI 기능의 복잡성 증가에 대응하기 위해 항공 및 원자력과 같은 안전 필수 산업을 모델로 삼아 위험에 관한 포괄적이고 증거 기반의 논거를 제시하도록 설계되었습니다.

AI 학습을 위한 기술적 안전장치

안전 사례는 정렬 학습(alignment training), 격리(containment), 모니터링(monitoring)이라는 기술 스택의 세 가지 주요 계층을 다루어야 합니다. 이러한 다층적 접근 방식은 모델이 신뢰할 수 있도록 학습되고, 정렬이 어긋날 경우 격리되며, 피해를 입히기 전에 문제를 감지하도록 모니터링되도록 보장합니다.

모델 정렬

정렬 학습은 모델이 의도한 대로 작동하도록 보장하는 첫 번째 방어선 역할을 합니다. OpenAI는 다음과 같은 관행을 권장합니다.

• 학습 환경 및 채점: "보상 해킹(reward hacks)" 및 정렬되지 않은 행동의 강화를 방지하기 위해, 연구소는 자동화된 에이전트를 사용하여 손상된 RL 환경을 찾아 수정하고, 이를 수동 데이터셋 검토로 보완하며, 악용 사례에 페널티를 주도록 채점기를 조정해야 합니다. 실험 추적에 분류기를 사용하는 이전 실행 분석을 통해 채점기의 효능을 검증할 수 있습니다.
• 정렬 측정: 효과는 프론티어 실행 중 오프라인 정렬 평가, 과적합을 방지하기 위한 이전 사고에 대한 백테스팅 평가, 그리고 "평가 게임(eval gaming)"(모델이 자신이 테스트받고 있음을 인식하는 경우) 모니터링을 통해 추적됩니다. 최악의 상황을 가정한 스트레스 테스트는 잘못된 행동을 유도하고 감지하는 데 사용됩니다.
• 사고의 연쇄(Chain-of-Thought) 제한: 자동화된 채점기가 RL 중에 모델의 사고의 연쇄를 보지 못하도록 차단하여, 모델이 모니터를 회피하는 기술을 개발하는 것을 방지해야 합니다.

격리

격리 전략은 인프라 보안을 통해 유해한 행동을 방지함으로써 모델의 정렬이 어긋날 경우를 대비한 안전장치를 제공합니다:

• 인프라 강화: 이는 모델 샌드박스와 호스팅 연구 인프라 모두에 대한 다중 보안 계층을 포함합니다.
• 격리 레드팀(Containment Red-Teaming): 프론티어 실행의 체크포인트를 사용하여 샌드박스, 경계 보안 및 모델이 액세스할 수 있는 모든 서비스(예: 인터넷 캐시)에 대한 반복적인 레드팀 활동을 수행합니다.
• 통신 제한: 발견 가능한 인프라 사이드 채널을 차단하기 위해 고대역폭 샘플 간 통신은 승인된 경로(예: 멀티 에이전트 도구)로 제한되어야 합니다.
• 변경 불가능한 기록: 모든 RL 학습, 평가 및 내부 배포 기록은 신뢰할 수 있는 사고 조사를 보장하고 편집을 방지하기 위해 쓰기 전용 저장소에 저장되어야 합니다.

모니터링

실시간 모니터링 시스템은 정렬되지 않은 행동을 신속하게 포착하도록 설계되었습니다:

• 모니터링 가능성: 모델은 모니터 회피 평가를 위한 명확한 임계값과 함께 모니터링 가능한 상태를 유지해야 합니다.
• 높은 재현율: 모니터링 시스템은 보류된 평가를 사용하여 과거 사고에 대해 높은 재현율을 입증해야 합니다.
• 평가 최신성: 모니터의 정밀도와 재현율이 저하되지 않도록 각 실행마다 새로운 평가 데이터 포인트를 생성해야 합니다.
• 신속한 대응: 우선순위 알림은 온콜 담당자에게 호출하거나 자동으로 실행을 일시 중지하는 등 정의된 SLA 내에서 조치를 트리거해야 합니다.

안전 사례를 위한 운영 지침

OpenAI는 안전 사례가 엄격하게 검토되고 시행되도록 보장하기 위한 운영 모범 사례를 다음과 같이 제시합니다:

• 거버넌스 및 승인: 안전 사례는 연구 조직 책임자/부사장, 안전 책임자, 최고 과학자를 포함한 고위 경영진의 검토 및 거부권을 필요로 합니다. 실행을 책임지는 고위 리더는 성과 검토 시 안전 사례 및 사고 대응에 대한 책임을 집니다.
• 위험 완화 및 통제:
  • 반대 의견(사전 부검): 외부 팀원은 안전 사례의 허점을 파악하기 위해 반대 의견을 작성해야 합니다.
  • 기술적 통제: 시스템은 "실패 시 폐쇄(fail closed)"되도록 설계되어야 하며, 규정을 준수하지 않는 실행을 시작하거나 학습 과정 내에서 모니터를 비활성화하기 어렵게 만들어야 합니다.
  • 일시 중지 및 롤백: 실행을 일시 중지하기 위한 명확한 런북과 SLA가 존재해야 하며, 정렬되지 않은 출력의 영향을 식별하고 되돌릴 수 있는 능력(예: 데이터 생성 시)이 유지되어야 합니다.
• 투명성 및 감사: 안전 사례는 내부 감독 그룹(예: 안전 및 보안 위원회)이 이용할 수 있어야 하며, 감사자는 주장을 검증할 수 있는 충분한 액세스 권한을 가져야 합니다.
• 에스컬레이션: 정렬 불일치 심각도 수준에 대한 정의된 프로세스가 존재해야 하며, 심각도가 높은 사고의 경우 CEO를 포함한 경영진에게 호출할 수 있는 온콜 시스템이 있어야 합니다.
• 잔여 위험: 안전 사례는 위험 수용 결정을 알리기 위해 현재 완화 조치로 다루어지지 않는 모든 잔여 위험을 명시적으로 나열해야 합니다.

정렬 불일치 사고 조사

심각한 정렬 불일치 사고가 발생한 후, OpenAI는 재발 방지를 위해 다음과 같은 엄격한 조사 프로세스를 권장합니다:

• 근본 원인 분석: 연구자는 표적 절제(targeted ablations) 또는 재샘플링 실험을 사용하여 정렬되지 않은 행동을 유발한 학습 역학을 이해해야 합니다.
• 사후 분석(Postmortems): 운영 및 문화적 사후 분석을 통해 문제가 감지되지 않았거나 에스컬레이션되지 않은 이유를 파악해야 합니다.
• 감지 개선: 사고의 특정 데이터에만 의존하지 않고 사고의 경향을 발견할 수 있는 새로운 정렬 테스트 방법을 개발해야 합니다. 사고에서 파생된 평가는 "회귀 테스트" 역할을 합니다.
• 투명성: 조사는 주기적인 내부 업데이트를 제공하고 결과, 사후 분석 및 운영 변경 사항에 대한 공개 발표로 마무리되어야 하며, 영향을 받는 제3자에게 즉시 통지해야 합니다.