턴(Turn)이 아닌 대화 전체(Conversation)를 검사하는 안전장치

Common Sense Media는 OpenAI가 청소년을 겨냥해 출시한 ChatGPT에 대해, 해당 그룹을 위한 특별 보호 장치를 갖추고 몇 달 만에 출시했음에도 불구하고, 어린 사용자에게 받아들일 수 없는 위험이라고 지적했습니다. 안전하게 만들어진 제품이라도 검토 과정에서 실패할 수 있으며, 개별 응답은 모두 문제가 없어 보일 수 있습니다. 이것이 AI를 배포하는 모든 사람들에게 핵심적인 긴장 요소입니다.

턴별 필터링 대 세션 수준 평가

거의 모든 모더레이션(moderation) 설정은 같은 방식으로 시작합니다: 들어오는 메시지와 나가는 응답 각각을 정책에 따라 분류하고, 실패한 부분을 차단하거나 다시 작성하는 것입니다. 이는 저렴하고 빠르며, 상태 비저장(stateless)이고 감사하기 쉬우며, 입력 하나당 판정 하나, 로그 라인 하나로 끝납니다.

하지만 이것은 드리프트(drift)를 감지할 수 없습니다. 30턴에 걸쳐 점진적으로 더 개인적이거나, 더 의존적이거나, 또는 역할극에 몰입하는 대화는 개별적으로 깨끗한 메시지 30개를 만들어냅니다. 해악은 턴이 아니라 궤적(trajectory)에서 발생합니다. 이것이 불일치점입니다: 일부 플랫폼은 세션을 평가하지만, 대부분의 팀은 메시지를 평가합니다.

따라서 결정해야 할 것은 **세션 수준 평가기(session-level evaluator)**를 추가할지 여부입니다. 이는 지금까지의 대화를 읽고 라인(line)이 아닌 아크(arc), 즉 전체 흐름을 판단하는 두 번째 검사 장치입니다. 비용은 현실적입니다: 더 많은 토큰, 증가된 지연 시간(latency), 그리고 합법적인 긴 튜터링 세션이 플래그 지정될 수 있는 새로운 오탐지(false-positive) 영역이 생깁니다. 일반적으로 거부되는 대안—단순히 턴별 분류기를 더 엄격하게 만드는 것—은 비용은 적지만, 유용성(usefulness)과 직접적으로 상충합니다. 왜냐하면 상태 비저장 필터가 드리프트를 포착할 수 있는 유일한 방법은 고립된 상황에서는 괜찮은 턴들을 과도하게 차단하는 것이기 때문입니다.

평가 스위트(eval suite)를 살펴보고 어떤 것을 필요로 하는지 결정하십시오. 만약 모든 테스트 케이스가 하나의 프롬프트와 하나의 예상 응답으로 구성되어 있다면, 검토자들이 실제로 보고할 실패 모드에 대한 가시성이 전혀 없습니다.

드리프트 테스트 케이스의 예시

다중 턴 평가(Multi-turn evals)는 생소하지 않습니다. 그것은 고정된 파일 형식입니다:

- id: escalation-dependency-01
persona: 15yo, late night, repeat user
turns: 24 # scripted, gradually more personal
...

두 개의 단언 계층(assertion layers)과 하나의 고정 장치(fixture). 현재 가지고 있는 것은 턴별(per-turn) 검사입니다. 세션별(per-session) 검사가 새로 추가된 부분이며, 이 부분이 실패하는 지점입니다.

런타임 측면에서는 모든 턴마다 세션 평가기(session evaluator)가 필요하지 않습니다. 이를 트리거하세요: N 턴마다 실행하거나, 저렴한 위험 점수(cheap risk score)가 임계값을 넘을 때, 또는 대화 길이가 턴별 데이터로는 더 이상 대표성을 갖지 못하는 지점을 지날 때 실행합니다. 이렇게 하면 추가되는 지연 시간(latency)이 중간 요청(median request)에는 영향을 주지 않고, 중요한 세션의 작은 부분에만 집중되게 합니다.

PM 입장에서 보면 이것은 아키텍처 논의가 아니라 범위 설정(scoping) 논의입니다: '우리의 안전 테스트는 단일 교환을 다루고, 우리가 문제가 될 검토는 긴 대화들을 다룬다'는 것은 명확한 경계가 있는 투자 가능한 격차(fundable gap)입니다.

핵심 요약 (Key Takeaways)

• 턴별 조정(Per-turn moderation)은 저렴하고 감사 가능하지만, 여러 턴에 걸쳐 흐르는 대화에는 구조적으로 취약합니다.
• 턴별 분류기(per-turn classifier)를 강화하여 보상하려 하면, 제품이 정상적인 장기 작업 수행 능력을 떨어뜨리면서 안전성을 확보하게 되므로 잘못된 수단입니다.
• 모든 턴마다가 아니라 길이 또는 위험 점수를 기반으로 세션 수준 검사(session-level checks)를 트리거해야 비용이 위험이 존재하는 곳에만 집중됩니다.

여러분의 평가 스위트(eval suite)의 테스트 케이스 중 가장 긴 대화는 실제로 얼마나 실행되나요? 그리고 그것이 여러분의 중간 실시간 세션보다 더 길었나요?

참고 출처: The Verge, Common Sense Media