프론티어 AI 훈련을 위한 안전 사례 구축 방향
요약
본 문서는 프론티어 AI 훈련을 위해 '안전 사례(safety cases)' 구축의 필요성을 강조합니다. 이는 항공이나 원자력 발전처럼 구조화되고 증거 기반의 접근 방식을 요구하며, 모델이 잘못된 행동을 하는 것을 막기 위한 기술적 안전장치 마련에 초점을 맞춥니다.
핵심 포인트
- AI 역량 단계별 '안전 사례' 구축 필요성 제기
- 기술적 안전장치는 정렬 훈련, 격리, 모니터링 세 축으로 구성
- 자동화/수동 데이터셋 검토를 통해 잘못된 행동 강화 방지
- 오프라인 평가 및 백테스팅을 통한 정렬 측정 중요성 강조
우리는 구조화된 안전 문서가 필요한 새로운 시대에 진입하고 있다고 믿습니다. 프론티어 강화학습(RL) 훈련을 계속하기 전에 이러한 문서가 요구되어야 합니다. 이상적으로는, 이러한 문서는 다른 안전 필수 산업에서 사용되는 위험에 대한 포괄적이고 구조화되며 증거 기반의 주장인 '안전 사례(safety cases)' 수준에 도달해야 합니다. 우리는 안전 사례를 우리가 나아가고자 하는 지향점(aspirational north star)으로 간주하며, AI 역량의 새로운 단계마다 나타나는 출현적 복잡성(emergent complexity) 때문에 항공이나 원자력 발전만큼 엄격하게 만드는 데 따르는 어려움을 인정하고 있습니다. 저희는 이러한 관행들을 명문화하기 위한 프레임워크를 구축하는 작업을 진행하고 있습니다.
아래는 프론티어 AI 훈련을 위한 안전 사례에 포함되어야 한다고 생각하는 몇 가지 초기 지침입니다. 이 모범 사례들은 현재 우리의 학습 내용을 반영하며, 신중한 개발을 위해 내부 프로세스를 계속 반복하면서 발전할 것으로 기대합니다. 저희는 현재의 생각을 투명하게 공유하고 커뮤니티의 피드백을 받고자 합니다. 참고로, 본 문서는 프론티어 강화학습 훈련에 초점을 맞추고 있으며, 내부 및 외부 배포에는 훨씬 더 광범위한 정렬 속성(alignment properties)을 고려해야 합니다.
- 기술적 안전장치 (Technical safeguards)
안전 사례는 세 가지 측면의 기술 스택을 다루어야 합니다: 정렬 훈련(alignment training), 격리(containment), 그리고 모니터링(monitoring). 이러한 안전장치들은 모델이 잘못된 행동을 시도하지 않도록 보장하고, 설령 그렇게 하더라도 격리를 깨기 어렵게 하며, 피해가 발생하기 전에 모니터링으로 포착될 수 있도록 돕습니다.
모델 정렬: 첫 번째 방어선은 모델을 우리가 의도하는 방식으로 신뢰성 있게 행동하도록 훈련시키는 것입니다. 여기에는 다음이 포함될 수 있습니다:
훈련 환경 및 평가(Training environments and grading): 훈련 중 보상 해킹(reward hacks)에 대한 긍정적 강화가 발생하는 것을 방지함으로써, 모델이 잘못된 행동을 개발할 위험을 줄일 수 있습니다. 여기에는 다음이 포함될 수 있습니다:
자동화된 데이터셋 검토: 에이전트를 사용하여 오작동(exploits)을 통해 의도된 행동 대신 잘못 정렬된 궤적(misaligned trajectories)이 높은 보상을 받을 수 있는 깨진 강화학습 (RL) 환경을 찾아 수정함으로써, 훈련 중 잘못 정렬됨이 강화될 기회를 줄입니다.
수동 데이터셋 검토: 자동화된 레드팀(red-teaming)에 더하여 데이터셋에 대한 수동 검토 및 품질 점검을 수행하여 의도치 않게 잘못 정렬된 행동을 강화할 수 있는 결함 있는 작업을 식별합니다.
평가자 튜닝 (Grader tuning): 모델이 훈련 중 RL 환경을 악용하거나 해킹하려는 시도를 벌점화하도록 평가자를 조정합니다.
사전 실행 분석 (Prior run analysis): 이전 실험의 추적(traces)에 대해 분류기(classifiers)를 실행하여 평가자가 의도한 대로 작동하는지 확인합니다.
정렬 측정 (Alignment measurement): 모델의 잘못 정렬 경향성(misalignment propensities)을 추적하는 평가를 실행하여 정렬 훈련의 효과를 측정합니다. 여기에는 다음이 포함될 수 있습니다:
- 오프라인 정렬 평가 (Offline alignment evals): 프론티어 실행 중 정렬 평가를 수행하여 훈련이 의도한 대로 작동하는지 평가하고, 물질적인 퇴행(material regressions)이 있는지 조사합니다.
- 백테스팅 (Backtesting): 이전 사고에 대해 정렬 평가를 백테스트하여 평가가 이전에 잘못 정렬된 모델을 감지하며 특정 사고에 과적합되지 않았는지 확인합니다.
- 평가 게임 추적 (Track evaluation gaming): 행동 변화(예: 정렬 평가에서 평가 인식 및 메타게이밍 모니터 활성화)를 유발할 수 있는 평가 인지 또는 메타게임(모델이 테스트되고 있음을 인식하는 것)을 추적하며, 특정 차단 임계값과 함께 진행합니다.
- 최악 사례 스트레스 테스트 (Worst-case stress tests): 최악의 경우 잘못된 행동을 유도하고 적어도 하나의 평가가 이 잘못된 행동을 감지하는지 확인합니다.
사고(chain-of-thought)로 훈련 방지: 모델이 사고 모니터를 회피하도록 진화하는 것을 막기 위해 자동화된 평가자가 강화학습에서 사고를 보지 못하게 합니다.
격리 (Containment): 모델이 잘못 정렬되는 경우, 유해한 행동이 발생하는 것을 막을 만큼 샌드박싱(sandboxing)과 보안을 강력하게 만듭니다. 여기에는 다음이 포함될 수 있습니다:
다층적인 인프라 보안: 모델이 실행되는 샌드박스와 샌드박스를 호스팅하는 연구 인프라 모두를 강화하는 데 막대한 투자를 하여, 샌드박스 탈출(sandbox escape) 사태 발생 시 추가적인 보호 계층을 확보해야 합니다.
격리 레드팀 운영: 프론티어 훈련 실행에서 얻은 체크포인트를 사용하여 이 시스템들(샌드박스, 연구 인프라, 경계 보안)에 대해 반복적으로 레드팀 테스트를 수행하고 안전 분석을 거쳐 모든 격차를 찾아 메워야 합니다. 또한 모델이 훈련 중에 접할 수 있는 모든 서비스(예: 인터넷 캐시)도 레드팀 테스트를 수행해야 합니다.
교차 샘플 통신 제한: 고대역폭의 교차 샘플 통신은 다중 에이전트 도구링(multi-agent tooling)과 같이 승인된 경로로 제한하고, 에이전트에 의해 대역폭이 크고 쉽게 발견될 수 있는 인프라 측 채널(side channels)을 폐쇄해야 합니다.
불변 기록: 모든 강화학습(RL) 훈련, 평가 및 내부 배포에 대해 에이전트 기록을 합리적인 기간 동안 불변하게 저장(예: 쓰기 전용 스토리지 계정)하여 신뢰할 수 있는 사고 조사를 가능하게 하고 의도치 않은 편집을 방지해야 합니다.
모니터링: 모델이 잘못된 행동을 하기 시작하는 경우, 잠재적인 비정렬(misalignment)을 포착하고 심각한 사고가 발생하기 전에 우선순위 문제를 신속하게 해결할 수 있는 실시간 모니터링 시스템을 갖추어야 합니다. 여기에는 다음이 포함될 수 있습니다:
-
모니터 가능성 강제 적용: 모델이 명확한 임계값으로 측정되는 모니터 가능성(monitorability) 및 모니터 회피 평가(monitor evasion evals)를 통해 계속 모니터링 가능하도록 보장하여, 우려되는 행동을 조기에 포착해야 합니다.
-
알려진 문제에 대한 높은 재현율(high recall): 모니터링 시스템이 별도로 분리된 평가 데이터셋에서 과거 사고에 대해 높은 재현율을 갖도록 해야 합니다.
-
모니터의 평가 신선도: 새로운 실행을 위해 순수하게 새로운 위험을 대표하는 평가 데이터 포인트를 생성하여, 모니터 재현율 및 정밀도의 측정치가 오래되지 않도록(stale) 해야 합니다.
신속 대응: 모델이 피해를 입히기 전에 정의된 SLA 내에서 조치로 이어지는 우선순위 알림을 구현합니다. 이는 온콜(on-call) 담당자에게 페이지를 하거나 영향을 받는 실행(run)을 자동으로 일시 중지하는 방식일 수 있습니다 (예: 주간에는 보안 온콜 및 실행 소유자에게 사고 발생 시 페이지하고, 야간에는 확인되지 않은 알림에 대해 실행을 자동 일시 중지).
- 운영 지침
기술적 안전장치에 대한 권고 사항과 더불어, 저희는 프론티어 AI 훈련 실행(training run)의 안전 사례를 위한 운영 모범 사례를 구축해 왔습니다. 여기에는 다음이 포함될 수 있습니다:
반대 의견 제시 (사전 회고/pre-mortems): 안전 사례가 초안 작성된 후, 다른 팀의 구성원이 반대 의견을 작성하여 안전 사례의 잠재적인 허점을 찾고 조정된 위험 분석(calibrated take on risk)을 공유해야 합니다. 훈련팀은 이를 해결하여 안전 사례를 더 강력하게 만드는 데 도움을 받아야 합니다.
승인: 안전 사례는 고위 리더십 구성원들로부터 검토되어야 하며, 이들은 각자 실행을 거부할 수 있는(veto) 능력을 가져야 합니다. 이는 실행에 대한 다중 내부 확인이 이루어지도록 보장하기 위함입니다 (예: 연구 조직 리드/VP, 안전 책임자, 최고 과학자).
책임성: 훈련 실행을 담당하는 고위 리더(예: 연구 조직 리드/연구 VP)는 안전 사례와 모든 사고 대응(성과 평가의 일부 포함)에 대한 책임을 져야 합니다. 이를 통해 훈련팀 역시 안전과 정렬화(alignment)를 추진하도록 인센티브가 부여됩니다.
일시 중지: 안전 사례를 무효화할 수 있는 문제(예: 새로운 보안 문제)가 발견되면, 모든 관련 실행을 일시 중지하기 위한 실행 매뉴얼(runbooks), 기술적 통제 장치, 그리고 SLA가 마련되어 있는지 확인해야 합니다.
내부 투명성: 안전 사례는 내부 감독 그룹(예: 안전 및 보안 위원회)에 제공되어야 합니다.
감사: 감사자들에게 안전 사례의 주장이 유효하고 건전한지 검증할 수 있도록 충분한 접근 권한이 제공되어야 하며, 부족한 점이 발견되면 이를 제기할 수 있어야 합니다.
에스컬레이션(Escalations): 정렬 불일치(misalignment) 에스컬레이션을 제기할 명확한 프로세스가 있어야 하며, 정의된 정렬 불일치 심각도 수준표와 특정 심각도 수준에 도달했을 때 임원진(예: CEO)에게 페이지를 보낼 수 있는 정렬 불일치 온콜(on-call)이 필요합니다.
기술적 통제(Technical controls): 인간과 에이전트가 규정 미준수 실행을 시작하기 어렵게 만들어야 합니다. 모니터링 및 자동 일시 중지 같은 안전 기능은 실패 시 폐쇄(fail closed)되어야 합니다 (예: 적절한 모니터링 활성화 없이 실행을 시작하거나, RL 훈련, 평가 또는 내부 배포에서 모니터를 비활성화하는 것이 불가능해야 합니다).
롤백 능력(Rollback ability): 훈련 과정에서 정렬 불일치 모델의 모든 다운스트림 사용처(예: 데이터 생성 또는 채점)를 식별하기 쉬워야 하며, 필요할 경우 정렬 불일치 출력의 영향을 되돌릴 수 있도록 해야 합니다.
잔여 위험 완전성(Residual risk completeness): 안전 사례는 현재 구현된 완화 조치로 다뤄지지 않은 잔여 위험 목록을 포괄적으로 열거해야 하며, 이를 통해 정보에 입각한 위험 수용 결정이 가능하도록 해야 합니다.
이는 저희의 현재 권장 사항이며 OpenAI에서 구현되는 과정에 있습니다. 저희는 앞으로 몇 주 동안 이러한 관행이 계속 발전할 것으로 예상합니다.
- 정렬 불일치 사고 조사(Investigations of misalignment incidents)
저희는 또한 심각한 AI 정렬 불일치 사고를 조사하기 위한 일부 모범 사례를 개발해 왔습니다. 연구소들은 개별 사건으로부터 가능한 한 많은 것을 배우려고 노력해야 합니다 (다른 고위험 산업의 조사 관행과 유사함). 이는 미래에 그러한 사례가 발생하지 않도록 예방하는 데 도움이 될 것입니다. 이러한 조치에는 다음과 같은 몇 가지 예시가 포함될 수 있습니다:
내부 투명성(Internal transparency): 사고 조사가 완료되는 데 상당한 시간이 걸릴 수 있으므로, 사건 조사에는 주기적인 내부 업데이트가 제시되어야 합니다 (예: 진행 중인 조사에 대한 일일 업데이트). 직원들은 안전하고 업무와 관련성이 있는 경우, 원본 기록이나 정렬 불일치 모델의 샘플링을 포함하여 더 많은 접근 권한을 얻을 수 있는 정의된 경로를 가져야 합니다.
Misalignment의 근본 원인 분석: 연구자들은 오정렬된 행동이 어떻게 도입되었는지 이해하고 미래에 이를 더 잘 예방하기 위해, 훈련 역학(예: 표적 제거(targeted ablations) 또는 재샘플링 실험을 통해)의 근본 원인을 파악해야 합니다.
사후 분석(Postmortem): 해당 사고가 발생하기 전에 어떤 문제들이 어떻게 도입되었고 왜 감지되거나 에스컬레이션되지 않았는지 등 모든 기여 원인을 이해하기 위해 운영적, 문화적 사후 분석이 수행되어야 합니다.
탐지: 우리는 사건 자체에 직접적으로 의존하는 정보(예: 대본이나 사고 요약)를 기반으로 언덕 오르기(hillclimbing)를 하지 않으면서도, 해당 사건을 유발할 수 있는 경향성을 발견할 수 있는 정렬 테스트 방법론을 개발해야 합니다. 사건에서 파생된 평가(evals)는 미래 모델이 매우 유사한 사건에 대해서도 오정렬의 경향성을 보이지 않도록 '회귀 테스트(regression tests)'로 만들어져야 합니다.
대외 공개: 조사 결과, 사후 분석 보고서 및 운영상의 변경 사항은 조사가 끝난 후 대중과 공유되어야 합니다. 영향을 받은 제3자들에게는 가능한 한 빨리 통보해야 합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 OpenAI Blog의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기