LLM(대규모 언어 모델) 및 해당 애플리케이션에 대한 레드 팀 계획
이 가이드에서는 LLM(대규모 언어 모델) 제품 수명 주기 전반에서 RAI(책임 있는 AI) 위험에 대한 레드 팀을 설정하고 관리하는 방법을 계획하기 위한 몇 가지 잠재적 전략을 제공합니다.
레드 팀이란?
레드 팀이라는 용어는 지금까지 보안 취약성을 테스트하기 위한 체계적인 적대적 공격을 설명했습니다. LLM이 부상함에 따라 이 용어는 기존의 사이버 보안을 넘어 AI 시스템에 대한 다양한 종류의 검색, 테스트 및 공격을 설명하도록 보편적인 의미로 발전했습니다. LLM을 사용하면 무해한 사용과 적대적 사용 모두 잠재적으로 유해한 출력을 생성할 수 있으며, 이는 증오 발언, 폭력 선동 또는 영화화 또는 성적 콘텐츠와 같은 유해한 콘텐츠를 비롯해 다양한 형태를 취할 수 있습니다.
RAI 레드 팀이 중요한 사례인 이유는 무엇인가요?
레드 팀은 LLM을 사용하는 시스템 및 기능의 책임 있는 개발에서 모범 사례입니다. 체계적인 측정 및 완화 작업을 대체하는 것은 아니지만 레드 팀은 피해를 발견하고 식별하는 데 도움이 되며, 완화의 효과를 검증하기 위한 측정 전략을 사용하도록 설정하기도 합니다.
Microsoft는 Azure OpenAI 서비스 모델에 대해 레드 팀 연습을 수행하고 안전 시스템( 콘텐츠 필터 및 기타 완화 전략 포함)을 구현했지만(책임 있는 AI 사례 개요 참조) 그러나 LLM 애플리케이션의 컨텍스트는 고유하며 레드 팀을 통해 다음을 수행해야 합니다.
LLM 기본 모델을 테스트하고, 애플리케이션의 컨텍스트를 고려할 때 기존 안전 시스템에 차이가 있는지 확인합니다.
기존 기본 필터 또는 완화 전략의 단점을 식별하고 완화합니다.
개선을 위해 오류에 대한 피드백을 제공합니다.
레드 팀이 체계적인 측정을 대체하는 것은 아닙니다. 체계적인 측정을 수행하고 완화를 구현하기 전에 수동 레드 팀의 초기 라운드를 완료하는 것이 가장 좋습니다. 위에서 강조한 것처럼 RAI 레드 팀의 목표는 위험을 식별하고, 위험 표면을 이해하고, 측정 및 완화해야 하는 사항을 알릴 수 있는 위험 목록을 개발하는 것입니다.
레드 팀 LLM 프로세스를 시작하고 계획하는 방법은 다음과 같습니다. 사전 계획은 레드 팀 연습의 생산성을 높이는 데 매우 중요합니다.
테스트 전
계획: 테스트를 수행할 사람
다양한 레드 팀 구성원 그룹 모집
제품 영역에 대한 다양한 분야에서 사람들의 경험, 인구 통계 및 전문 지식을 고려해서 레드 팀 구성원의 이상적인 구성(예: AI, 사회 과학, 보안 관련 전문가)을 결정합니다. 예를 들어 의료 서비스 제공자를 돕기 위한 챗봇을 설계하는 경우 의료 전문가는 해당 영역의 위험을 식별하는 데 도움을 줄 수 있습니다.
무해한 사고 방식과 적대적 사고 방식을 모두 갖춘 레드 팀 구성원을 모집합니다.
적대적 사고 방식과 보안 테스트 환경을 보유한 레드 팀 구성원을 갖는 것은 보안 위험을 이해하는 데 필수적이지만, 애플리케이션 시스템의 일반 사용자이며 개발에 관여하지 않은 레드 팀 구성원은 일반 사용자가 겪을 수 있는 피해에 대한 중요한 관점을 제시할 수 있습니다.
레드 팀을 위험 및/또는 제품 기능에 할당
특정 전문 지식을 갖춘 RAI 레드 팀이 특정 유형의 위험을 조사하도록 할당합니다(예: 보안 주제 전문가는 탈옥, 메타프롬프트 추출 및 사이버 공격과 관련된 콘텐츠를 조사할 수 있음).
여러 테스트 라운드의 경우 각 라운드에서 레드 팀 할당을 전환하여 각 위험에 대한 다양한 관점을 얻고 창의성을 유지할지 여부를 결정합니다. 할당을 전환하는 경우 레드 팀원이 새로 할당된 위험에 대한 지침을 신속하게 파악할 수 있는 시간을 허용합니다.
이후 단계에서는 애플리케이션과 해당 UI가 개발될 때 애플리케이션의 특정 부분(즉, 기능)에 레드 팀원을 할당하여 전체 애플리케이션의 적용 범위를 보장할 수 있습니다.
각 레드 팀이 얼마나 많은 시간과 노력을 할애해야 하는지 고려합니다(예: 무해한 시나리오에 대한 테스트는 악의적인 시나리오에 대한 테스트보다 시간이 덜 필요할 수 있음).
레드 팀에게 다음을 제공하면 도움이 될 수 있습니다.
- 다음을 포함할 수 있는 명확한 지침:
- 지정된 레드 팀 라운드의 목적과 목표를 설명하는 소개, 테스트할 제품 및 기능과 액세스 방법, 테스트할 문제의 종류, 테스트가 좀 더 타기팅되는 경우 레드 팀원의 중점 영역, 각 레드 팀이 테스트에 얼마나 많은 시간과 노력을 기울여야 하는지 여부, 결과를 기록하는 방법, 질문이 있을 때 연락할 사람
- 다음과 같은 정보를 포함하여 예제 및 결과를 기록할 파일 또는 위치:
- 예제가 공개된 날짜, 사용 가능한 입력/출력 쌍의 고유 식별자(재현용), 입력 프롬프트, 출력의 설명 또는 스크린샷
계획: 테스트할 내용
애플리케이션이 기본 모델을 사용하여 개발되었으므로 다음과 같은 여러 계층에서 테스트해야 할 수 있습니다.
안전 시스템을 갖춘 LLM 기본 모델은 애플리케이션 시스템의 컨텍스트에서 해결해야 할 수 있는 격차를 식별합니다. (테스트는 일반적으로 API 엔드포인트를 통해 수행됩니다.)
애플리케이션 (테스트는 UI를 통해 수행하는 것이 가장 좋습니다.)
LLM 기본 모델과 완화 전후의 애플리케이션이 모두 마련되어 있습니다.
다음 권장 사항은 레드 팀을 구성할 때 다양한 지점에서 테스트할 항목을 선택하는 데 도움이 됩니다.
먼저 기본 모델을 테스트하여 위험 표면을 이해하고, 위험을 식별하고, 제품에 대한 RAI 완화의 개발하도록 안내할 수 있습니다.
RAI 완화의 효과를 평가하기 위해 RAI 완화를 사용 및 사용하지 않고 제품의 버전을 반복적으로 테스트합니다. (수동 레드 팀은 평가가 충분하지 않을 수 있습니다. 체계적인 측정도 사용하지만 수동 레드 팀의 초기 라운드를 완료한 후에만 사용합니다.)
프로덕션 UI에서 가능한 한 많은 애플리케이션 테스트를 수행합니다. 실제 사용과 가장 유사하기 때문입니다.
결과를 보고할 때 테스트에 사용된 엔드포인트를 명확히 합니다. 제품이 아닌 엔드포인트에서 테스트가 완료되면 이후 라운드에서 프로덕션 엔드포인트 또는 UI에서 다시 테스트하는 것이 좋습니다.
계획: 테스트 방법
광범위한 위험을 파악하기 위해 개방형 테스트를 수행합니다.
RAI 레드 팀원이 특정 위험의 예를 찾도록 요청하는 대신문제가 있는 콘텐츠를 탐색하고 문서화할 경우의 이점은 다양한 문제를 창의적으로 탐색하여 위험 표면을 사각지대 없이 제대로 이해할 수 있습니다.
개방형 테스트에서 위험 목록을 만듭니다.
- 위험의 정의와 예제를 포함하는 위험 목록을 만드는 것이 좋습니다.
- 이 목록을 이후 테스트 라운드에서 레드 팀에게 지침으로 제공합니다.
안내형 레드 팀 작업 수행 및 반복: 목록의 위험 계속 조사, 노출된 새 위험 식별
사용 가능한 경우 위험 목록을 사용하고 알려진 위험 및 완화의 효과에 대한 테스트를 계속합니다. 이 프로세스에서 새로운 위험을 식별할 수 있습니다. 이러한 항목을 목록에 통합하고, 측정 및 완화 우선 순위를 변경하여 새로 확인된 위험을 해결합니다.
반복 테스트에서 우선적으로 테스트할 위험을 계획합니다. 위험의 심각도 및 노출 가능성이 더 큰 컨텍스트를 포함하는(이에 국한되지 않음) 여러 가지 요인을 통해 우선 순위를 알 수 있습니다.
계획: 데이터 기록 방법
수집해야 하는 데이터와 선택 사항인 데이터를 결정합니다.
레드 팀이 기록해야 하는 데이터(예: 사용한 입력, 시스템의 출력, 사용 가능한 경우 나중에 예제를 재현하기 위한 고유 ID 및 기타 참고 사항)를 결정합니다.
중요한 정보를 놓치지 않으면서 레드 팀원을 혼란스럽지 않게 하려면 수집하는 데이터를 전략적으로 결정해야 합니다.
데이터 수집을 위한 구조 만들기
공유 Excel 스프레드시트는 레드 팀 데이터를 수집하는 가장 간단한 방법입니다. 이 공유 파일의 장점은 레드 팀이 서로의 예제를 검토하여 자체 테스트에 대한 창의적인 아이디어를 얻고 데이터 중복을 방지할 수 있다는 것입니다.
테스트 도중
레드 팀 작업이 진행되는 동안 활성 대기 상태를 유지하도록 계획
- 지침 및 액세스 문제로 레드 팀원을 지원할 준비를 합니다.
- 스프레드시트의 진행률을 모니터링하고 적시 미리 알림을 레드 팀원에게 보냅니다.
각 테스트 라운드 후
보고서 데이터
주요 관련자와 정기적으로 다음과 같은 간단한 보고서를 공유합니다.
식별된 상위 문제를 나열합니다.
원시 데이터에 대한 링크를 제공합니다.
예정된 라운드에 대한 테스트 계획을 미리 봅니다.
레드 팀원을 승인합니다.
기타 관련 정보를 제공합니다.
식별 정보와 측정값 간을 구분
보고서에서 RAI 레드 팀의 역할은 위험을 노출하고 위험 표면에 대한 이해를 높이는 것이며 체계적인 측정 및 엄격한 완화 작업을 대신하는 것이 아니라는 것을 명확히 해야 합니다. 사람들이 특정 예제를 해당 위험 확산에 대한 메트릭으로 해석하지 않는 것이 중요합니다.
또한 보고서에 문제가 있는 콘텐츠 및 예제가 포함된 경우 콘텐츠 경고를 포함하는 것이 좋습니다.
이 문서의 지침은 법률 자문을 제공하기 위한 것이 아니며, 법률 자문으로 해석되어서는 안 됩니다. 사용자가 비즈니스를 운영하는 관할권에는 AI 시스템에 적용되는 다양한 규제 또는 법적 요구 사항이 있을 수 있습니다. 이러한 모든 권장 사항이 모든 시나리오에 적합한 것은 아니며, 반대로 일부 시나리오에서는 이러한 권장 사항이 충분하지 않을 수 있습니다.