LLM(대규모 언어 모델) 및 해당 애플리케이션에 대한 빨간색 팀 계획
이 가이드에서는 LLM(대규모 언어 모델) 제품 수명 주기 전반에 걸쳐 책임 있는 AI(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 시스템에 적용되는 다양한 규제 또는 법적 요구 사항이 있을 수 있습니다. 이러한 모든 권장 사항이 모든 시나리오에 적합한 것은 아니며, 반대로 일부 시나리오에서는 이러한 권장 사항이 충분하지 않을 수 있습니다.