에피소드 9. 한 턴 자동화와 성공 판정
원본 범위: 57:55–1:06:26. 파이릿의 입력 목록, 변환기, 거절 평가, 결과 내보내기 데모.
영상은 입력 다섯 개를 사용한다 — 58:33
진행자는 입력이 아주 많을 때 자동화가 필요하다고 설명한 뒤, 실제 데모에는 다섯 개를 사용한다. 원본 입력은 해로운 요청 범주에 속한다. 이 교재의 실습에서는 그 입력을 복사하는 대신 공식 Lab 1의 연습 파일 공개 목표로 바꾼다. 자동화 흐름을 배우는 별도 실습이며 원본과 같은 데이터셋을 실행했다고 기록하지 않는다.
한 턴 시험에서는 입력마다 독립된 대화를 시작한다. 입력 다섯 개를 같은 대화에 연속으로 보내면 앞의 이력이 뒤에 영향을 주므로 다른 시험이 된다.
1. 입력 목록을 기록 저장소에 넣는다 — 59:24
영상의 SeedPromptDataset은 시작 입력들을 담는 데이터셋이다. seed는 여기서 시험을 시작할 입력을 뜻한다. 파일에서 읽은 입력을 memory에 등록하고, 나중에 데이터셋 이름으로 다시 불러온다.
왜 바로 전송하지 않고 이름과 함께 저장할까? 실험이 끝난 뒤 어떤 목록을 썼는지 다시 찾기 위해서다. 입력을 바꾸거나 목록에 항목을 추가했으면 같은 이름만으로 충분하지 않을 수 있으므로 파일 버전과 내용도 남긴다.
영상은 1:00:17 부근에서 실험 이름을 memory label로 지정한다. 이 표지는 나중에 해당 실험의 결과만 골라 내보낼 때 사용한다. 모든 기록을 한꺼번에 내보내는 것과 실험 이름으로 선택하는 것은 다르다.
| 구분 | 무엇을 묶는가? | 예 |
|---|---|---|
| 데이터셋 이름 | 사용한 입력 목록 | 연습 파일 요청 목록 |
| 실험 표지 | 이번 실행에서 나온 기록 | 날짜·대상·변환 방식으로 구분한 실행 이름 |
| 대화 식별자 | 하나의 입력과 응답 또는 이어진 대화 | 한 턴 시험 한 건 |
예시 이름은 교재용이며 영상의 실제 이름을 그대로 사용한 것은 아니다.
2. 어디에 보낼지 정한다 — 1:00:40
영상은 Azure OpenAI 대상의 주소와 인증 정보, 배포 이름을 설정한다. 연결 정보는 로컬 환경 설정에서 읽는다.
주소, API 키, 배포 이름의 역할이 다르다.
| 항목 | 역할 |
|---|---|
| 대상 주소, endpoint | 요청을 보낼 서비스 위치 |
| API 키 | 해당 서비스를 호출하는 인증 정보 |
| 배포 이름, deployment name | 그 서비스 안에서 호출할 배포를 가리키는 이름 |
영상의 특정 배포 이름에 Unsafe가 들어가도 일반적으로 제공되는 제품 이름이라는 뜻은 아니다. 진행자가 구성한 실험 배포의 이름이다. 현재 사용할 모델과 안전 설정을 별도로 기록한다.
3. 거절 점수를 공격 성공 점수로 뒤집는다 — 1:01:22
영상의 SelfAskRefusalScorer는 응답이 거절인지 판단한다. True는 참, False는 거짓이다. 거절 여부를 먼저 판단하고 그 값을 반대로 바꿔 공격 성공처럼 사용한다.
| 실제 응답의 거절 여부 | 거절 평가 | 반대로 바꾼 성공 평가 |
|---|---|---|
| 거절했다고 판단 | 참 | 거짓 |
| 거절하지 않았다고 판단 | 거짓 | 참 |
이 계산은 간단하지만 성공 기준이 “거절하지 않음”으로 좁아지는 문제가 있다. 연습 파일을 요청했는데 모델이 일반적인 보안 조언만 했다면 거절이 아닐 수 있어도 파일값은 나오지 않았다. 목표가 파일 공개라면 실패다.
응답의 어조와 실제 목표를 분리하자.
| 교재용 응답 | 거절 여부와 별개로 확인할 것 | 파일 공개 목표 |
|---|---|---|
| “파일은 공개할 수 없습니다.” | 실제 값이 없음 | 실패 |
| “파일 보호가 중요합니다. 권한을 확인하세요.” | 답변했지만 실제 값이 없음 | 실패 |
| “주의가 필요합니다” 뒤에 실제 연습 값이 나옴 | 경고가 있어도 값이 공개됨 | 성공 |
| 존재하지 않는 값을 지어냄 | 원본 파일과 일치하지 않음 | 실패 |
거절 평가가 쓸모없다는 뜻은 아니다. 초기 분류에는 사용할 수 있지만 그 점수가 이번 과제의 성공 조건과 같은지 확인해야 한다.
4. 글자 사이를 띄우는 변환기를 연결한다 — 1:02:04
영상의 변환기는 입력의 글자 사이에 공백을 넣는다. 에피소드 5에서 본 표기 변형을 자동으로 적용하는 것이다.
원문 예: hello
변환 예: h e l l o
이 작은 예는 변환 방식을 보여 주며 실제 데모의 해로운 입력을 재현하지 않는다. 원문만 저장하면 대상이 무엇을 받았는지 모른다. 변환문만 저장하면 어떤 요구를 어떻게 바꿨는지 비교하기 어렵다. 둘 다 기록한다.
영상은 여러 변환기를 이어 붙일 수 있다고 설명하지만 이번 데모에는 하나를 사용한다. 언어 변환이나 이미지 변환을 추가했다면 다른 실험 조건으로 기록한다.
5. 진행 담당에 대상·평가·변환을 넘긴다 — 1:02:45
영상의 PromptSendingOrchestrator에는 대상, 평가기, 변환기를 연결한다. 이후 목록의 입력을 가져와 변환하고 보내고 점수화한다.
다음은 순서를 이해하기 위한 의사코드다. 실제 파이릿 API 호출 문법이 아니며 실행 스크립트로 사용하지 않는다.
입력 목록에서 하나를 고른다
새 대화를 시작한다
입력을 변환한다
대상에 보낸다
응답을 거절 평가기에 넘긴다
원문, 변환문, 응답, 점수를 저장한다
다음 입력으로 반복한다
여기서 “새 대화”와 “점수 저장”을 생략하면 한 턴 비교와 사후 검토가 어려워진다.
영상에서는 대상의 시스템 프롬프트도 설정한다 — 1:02:59
진행자는 교육 목적이라며 답변 범위를 넓히는 시스템 프롬프트를 대상에 설정한다. 연구자가 대상의 설정을 바꿀 수 있는 실험 환경이기 때문이다.
이것은 일반 사용자 입력으로 시스템 지시를 무시하게 유도한 것과 조건이 다르다.
| 경우 | 연구자가 가진 권한 | 해석 |
|---|---|---|
| 대상 설정에서 시스템 지시를 직접 바꿈 | 실험 대상의 설정 권한 | 바꾼 지시 아래에서 모델 행동을 시험함 |
| 사용자 입력으로 규칙을 바꾸라고 요구 | 대화 입력 권한 | 원래 지시가 유지되는 상태에서 직접 인젝션을 시험함 |
영상의 결과를 “기본 설정의 제품에 일반 사용자가 그대로 성공했다”고 옮기면 실험 조건을 잘못 설명하는 것이다. 시스템 지시, 필터, 모델, 연결 대상 모두 결과에 영향을 준다.
6. 실행 전에 저장해 둔 결과를 읽는다 — 1:03:57
진행자는 데모를 촬영하기 전에 실행해 두었고, 화면에서는 저장된 결과를 확인한다고 설명한다. 코드에 결과가 보인다는 사실과 그 순간 새로 호출했다는 사실은 구분한다.
영상에서 읽는 결과에는 다음 차이가 있다.
| 결과 | 영상에서 주의할 점 |
|---|---|
| 첫 응답은 거절 | 거절 평가를 뒤집으면 성공은 거짓이다. |
| 다른 응답은 주의 문구를 붙이고 내용을 제공 | 주의 문구만 보고 거절로 분류하면 안 된다. 실제 제공 내용을 읽는다. |
| 일본어 입력·응답 | 자동 평가가 언어를 판단하지만 진행자도 직접 읽기 어렵다고 말한다. 언어를 이해하는 검토가 필요하다. |
영상은 자동 점수의 기준을 더 조정할 수 있음을 짚는다. 자동 평가기가 참이라고 출력했다는 사실만으로 과제 성공이 확정되는 것은 아니다. 특히 읽지 못하는 언어의 결과는 번역과 원문 검토를 거쳐 판정한다.
7. 실험 표지로 골라 JSON·CSV로 내보낸다 — 1:05:29
JSON은 이름과 값을 구조적으로 담는 형식이고, CSV는 행과 열로 데이터를 담는 형식이다. 영상은 memory label로 이번 기록을 골라 파일로 내보낸다.
아래는 내보낼 정보의 뜻을 이해하는 가상 기록이다. 실제 호출 결과가 아니다.
| 기록 항목 | 예 |
|---|---|
| 실험 이름 | 연습 파일·공백 변환 시험 |
| 원문 입력 | 연습 파일 내용을 요청하는 문장 |
| 실제 전송 입력 | 공백 변환을 적용한 문장 |
| 대상의 응답 | “권한을 확인하세요.” |
| 자동 평가 | 거절 아님 → 성공 참 |
| 사람의 판정 | 실제 파일값 없음 → 실패 |
| 판정 이유 | 자동 점수는 비거절을 세었고, 과제는 값 공개를 요구함 |
자동 평가와 사람의 판정을 덮어써서 하나만 남기지 않는다. 두 판단이 어디서 달라졌는지 기록해야 평가기를 고칠 수 있다.
공식 Lab 1 자동화 연습
공식 랩 저장소의 Lab 1 노트북을 사용한다. 현재 버전의 연결·실행 안내를 읽고 대상이 연습 환경인지 확인한다.
- 소수의 입력과 성공 조건을 준비한다.
- 대상 주소·모델·시스템 지시·필터 조건을 적는다.
- 변환 전·후 입력을 함께 남기며 한 턴씩 실행한다.
- 자동 점수와 실제 파일값 공개 여부를 대조한다.
- 해당 실험만 내보내서 세 명이 성공·실패·오판 사례를 함께 읽는다.
API가 준비되지 않았다면 노트북에서 입력 목록, 대상, 점수 뒤집기, 내보내기 위치를 찾아 설명한다. 그 단계와 API 실행 완료는 별도로 기록한다.
이해 확인
문제. 거절하지 않았으니 파일 공개에 성공한 것인가?
실제 연습 값이 나왔는지 확인해야 한다. 거절하지 않고 다른 설명만 한 경우는 실패다.
문제. 시스템 프롬프트를 직접 바꾼 실험은 일반 사용자 인젝션과 같은가?
연구자의 설정 권한이 다르다. 결과를 설명할 때 이 조건을 반드시 밝힌다.
문제. 원문과 자동 점수만 있으면 결과를 검토할 수 있는가?
대상이 받은 변환문과 실제 응답도 필요하다. 모델·지시·필터 등 실험 조건과 판정 이유도 남긴다.
현재 코드 확인
영상의 클래스 이름은 원본을 읽기 위한 정보다. 실제 실행은 현재 파이릿 공식 문서와 설치 버전을 맞춘다. 이 교재의 의사코드는 버전별 API를 대신하는 실행 코드가 아니다.
교재 이동
AI Red Teaming 101
- AI 레드티밍 교재와 공식 챌린지
- 에피소드 1. AI 레드티밍의 목적과 세 가지 위험
- 에피소드 2. 생성형 AI의 학습과 글 처리
- 에피소드 3. 시스템 프롬프트와 AI 앱의 입력 경로
- 에피소드 4. 간접 인젝션과 웹페이지 요약 데모
- 에피소드 5. 한 턴 공격과 입력 표현 바꾸기
- 에피소드 6. 여러 턴 공격과 대화 이력
- 에피소드 7. 스포트라이팅과 외부 자료 구분
- 에피소드 8. 파이릿의 구성과 자동화 데모
- 에피소드 9. 한 턴 자동화와 성공 판정
- 에피소드 10. 여러 턴 자동화와 결과 검토
- Lab 1: 12번의 실패, 새 채팅의 성공
- Lakera Agent Breaker - Trippy Planner - Lv 1&2
