🤖 machine learning

Auditing the Audit: Five Failure Modes in Benchmark-Validity Audits

이 논문은 섭동 기반의 AI 모델 구성 타당성 감사가 취약하며 침묵하는 구현 실패에 노출되기 쉽다고 주장하며, 비확증적 증거를 유보하기 위한 6단계 실사 게이트를 제안하고, 안전 벤치마크와 오픈 웨이트 모델에 관한 특정 사례 연구가 이 새로운 5가지 감사 실패 모드 분류 체계 하에서 확증적 표준을 충족하지 못함을 입증한다.

원저자: Yanhang Li, Zhichao Fan, Zexin Zhuang

게시일 2026-07-07

📖 5 분 읽기🧠 심층 분석

CC BY 4.0

원저자: Yanhang Li, Zhichao Fan, Zexin Zhuang

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

당신은 식품 안전 검사관이라고 상상해 보세요. 당신의 업무는 한 레스토랑의 "건강 메뉴"가 실제로 건강한지 확인하는 것입니다. 이를 위해 당신은 단순히 음식을 맛보는 것에 그치지 않고, 재료를 교체하는(예: 설탕을 소금으로 바꾸는) 특별한 테스트를 실행하여 영양 성분 표시가 올로게 변하는지 확인합니다. 만약 설탕을 소금으로 바꿨음에도 영양 성분 표시가 그대로라면, 당신은 그 테스트가 고장 났다는 것을 알게 됩니다.

이 논문은 **'감사인을 감사하기(auditing the auditors)'**에 관한 글입니다. 저자들은 AI 안전성을 검증하기 위해 사용하는 도구와 체크리스트 자체가 취약할 수 있다고 주장합니다. 이러한 도구들은 미묘한 방식으로 고장 날 수 있으며, 그 결과로 전체 과정에 결함이 있음에도 불구하고 마치 완벽한 것처럼 보이게 만들 수 있습니다.

다음은 이들의 연구 결과를 쉬운 비유를 사용하여 정리한 내용입니다.

핵심 문제: "고장 난 자"

저자들은 기업이나 연구자들이 AI 모델을 테스트할 때 "섭동 감사(perturbation audits)"를 사용한다고 말합니다. 이는 질문을 약간 수정하여(섭동) AI의 답변이 의도한 대로 변하는지 확인하는 것을 의미합니다.

주장: 이러한 감사 방식은 고무로 만든 자와 같습니다. 때때로 그 고무가 늘어나거나 끊어지는 방식이 마치 측정이 제대로 된 것처럼 보이게 만들지만, 실제로는 거짓을 말하고 있는 것입니다.
위험성: 규제 기관(예: 정부 기관)이 최종 수치(예: "안전도 95%!")를 보고 그것을 신뢰할 수 있지만, 그 수치를 얻기 위해 사용된 "자"가 이미 고장 났다는 사실을 깨닫지 못할 수 있습니다.

5가지 실패 방식 (The "Five Failure Modes")

저자들은 이러한 감사 파이프라인이 소리 없이 실패할 수 있는 다섯 가지 구체적인 방식을 발견했습니다. 이들은 소프트웨어 결함(기계가 고장 남)과 측정 결함(논리가 틀림)의 두 그룹으로 나뉩니다.

그룹 1: 소프트웨어 결함 (기계가 고장 남)

이는 컴퓨터 코드가 의도한 대로 작동하지 않는 버그들입니다.

"유령 편집" (F1): 요리사에게 "소금을 설탕으로 바꾸세요"라고 명령했다고 가정해 봅시다. 하지만 요리사가 그 메모를 무시하고 소금을 그대로 유지합니다. 감사는 교체가 일어났다고 생각하지만, AI는 실제로 변경된 내용을 보지 못했습니다. 테스트는 실행되지만, AI는 여전히 이전의 질문에 답하고 있습니다. 결과는 완벽한 점수로 나타나지만, AI가 실제로 테스트를 받지 않았기 때문에 이는 거짓입니다.
"나쁜 번역가" (F2): AI가 길고 복잡한 문장을 썼고, 로봇이 이를 읽으려고 시도한다고 가정해 봅시다. 만약 로봇이 "The"로 시작하는 문장만 이해할 수 있고, AI가 "It is..."라고 썼다면, 로봇은 읽기에 실패합니다. 만약 AI가 문체(style)를 약간 바꾼다면, 로봇이 갑자기 그것을 이해하게 될 수도 있습니다. 감사는 AI의 행동이 변했다고 생각하지만, 실제로는 로봇이 글을 더 잘 읽게 된 것뿐입니다.
"끊어진 쌍" (F4): 당신이 새로운 트랙에서 자동차가 더 빠른지 테스트하고 있다고 가정해 봅시다. 이전 트랙에서 자동차의 시간을 측정하고, 그다음 새로운 트랙에서 시간을 측정합니다. 그런데 만약 두 번째 주행에서 다른 자동차를 사용한다면, 그 비교는 무의미합니다. 감사에서도 동일한 "질문"과 그 "수정된 버전"을 정확히 짝지어주지 않는다면, 수학적 계산이 엉망이 되고 안전 마진은 가짜처럼 보이게 됩니다.

그룹 2: 측정 결함 (논리가 틀림)

이는 코드는 작동하지만, 결과를 해석하는 방식에 결함이 있는 경우입니다.

"혼란스러운 점수 기록원" (F3): 이는 점수를 매기는 사람(또는 코드)이 엉뚱한 것을 보고 있는 일련의 오류들입니다.
- 역전된 관습 (Inverted Convention): "1"은 "좋음"을 의미하고 "0"은 "나쁨"을 의미하는 게임이 있다고 가정해 봅시다. 점수 기록원이 실수로 "1"을 "나쁨"으로 생각합니다. 그들은 AI가 아주 훌륭함에도 불구하고 AI가 형편없다고 보고합니다.
- 순서 편향 (Order Bias): 정답이 항상 첫 번째 옵션인 객관식 테스트가 있다고 가정해 봅시다. AI는 그냥 첫 번째 옵션을 선택합니다. 점수 기록원은 "와, 정확도 100%!"라고 말하지만, AI는 그냥 첫 번째 버튼을 누르고 있는 것입니다.
- "절단(Truncation)" 버그: 저자들은 다른 버그를 수정하는 과정에서 스스로 도입한 버그를 발견했습니다. 그들은 AI에게 상위 50개의 답변을 고르라고 지시했지만, 정답은 51번째에 있었습니다. AI는 그것을 볼 수 없었고, 그래서 가장 흔한 답변을 골랐습니다. 감사는 평탄한 선(변화 없음)을 보여주었으며, 이는 AI가 테스트에 면역이 있는 것처럼 보이게 했지만, 실제로는 테스트가 AI의 진짜 답변을 보지 못한 것이었습니다.
"부적절한 도구" (F5): 코끼리를 재기 위해 설계된 저울로 깃털의 "무게"를 측정하려고 한다고 가정해 봅시다. 저울은 "0"이라고 표시할 것이며, 이는 기술적으로는 맞지만, 그 작업에는 쓸모없는 도구입니다. 어떤 안전 벤치마크는 세부 사항을 바꿨을 때 AI가 생각을 어떻게 바꾸는지를 보기 위해 설계되었습니다(진단적). 반면 다른 벤치마크는 AI가 어떻게 유지되는지를 보기 위해 설계되었습니다(불변성). 만약 "불변성" 벤치마크에 "변화" 테스트를 사용한다면, 수학적 결과는 고장 난 것처럼 보일 것이며, 심지어 AI가 완벽하더라도 말입니다.

해결책: "6단계 게이트 (Six-Point Gate)"

저자들은 결과의 신뢰성을 확보하기 위해 모든 감사가 통과해야 하는 새로운 체크리스트(게이트)를 제안합니다. 이것을 보안 검문소라고 생각하십시오.

게이트: "이 AI는 안전하다"라고 말하기 전에, 반드시 6가지 체크(G1~G6)를 통과해야 합니다.
1. 편집 내용이 실제로 AI에 도달했는가?
2. 점수가 기본 베이스라인보다 높은가?
3. 수학적으로 통계적으로 타당한가?
4. "혼란스러운 점수 기록원" 버그를 확인했는가?
5. 어떤 종류의 테스트를 수행하는지 공개했는가?
6. 다른 버그를 고치는 과정에서 도입한 버그가 있는지 확인했는가?

결과: 현실 점검

저자들은 이 "6단계 게이트"를 10개의 AI 테스트(2개의 모델과 5개의 벤치마크 사용)에 적용했습니다.

충격적인 결과: 10개의 테스트 중 단 하나도 "확정적(Confirmatory, 완전히 신뢰할 수 있는)" 단계로 간주될 만큼 게이트를 통과하지 못했습니다.

3개는 부적격(Ineligible) (처음부터 테스트가 고장 남).
3개는 검증되지 않음(Unvalidated) (점수 기록원을 믿을 수 없음).
2개는 수학적 체크 실패.
2개는 탐색적(Exploratory) (흥미롭지만, 아직 실전에 투입하기엔 시기상조임).

핵심 요점

저자들은 "AI가 안전하지 않다"고 말하는 것이 아닙니다. 그들은 **"우리는 아직 AI가 안전하다(혹은 안전하지 않다)고 말하는 보고서들을 신뢰할 수 없다"**고 말하는 것입니다.

그들은 벤치마크 수치를 신뢰하기 전에, 테스트를 수행하는 사람들이 **"자기 감사 연대기(Self-Audit Chronology)"**를 발표해야 한다고 주장합니다. 이것은 마치 정비사의 기록부와 같습니다:

"여기 우리가 발견한 버그가 있습니다."
"이것을 어떻게 고쳤습니다."
"고치기 전과 후의 숫자가 어떻게 변했는지 보여드립니다."
"첫 번째 버그를 고치는 동안 우리가 실수로 도입한 또 다른 버그가 여기 있습니다."

결론: 만약 당신이 AI 감사에서 나온 깨끗하고 완벽한 숫자와 함께, 그 숫자를 얻기 위해 발생했던 모든 버그와 수정 사항에 대한 지저-하고 정직한 기록을 보지 못했다면, 그 숫자를 믿지 마십시오. 그 숫자는 단지 "침묵하는 무효 동작(silent no-op)"일 수 있습니다. 즉, 아무 일도 일어나지 않은 상태에서 결과만 나온 '유령 편집'일 수 있습니다.

기술 요약: 감사를 감사하다 – 벤치마크 타당성 감사에서의 5가지 실패 모드

1. 문제 정의

거버넌스 프레임워크(예: EU AI Act, NIST AI RMF, 중국의 GB/T 45654)는 AI 제공업체가 문서화된 평가 증거를 제출할 것을 점점 더 요구하고 있으며, 이는 흔히 **섭동 기반 구성 타당성 감사(perturbation-based construct-validity audits)**의 형태를 띱니다. 이러한 감사들은 제어된 편집을 벤치마크 항목에 적용하여, 모델의 성능 지표가 근본적인 구성(construct)이 변할 때만(예: 의미적 반전) 변화하고 표면적인 재작성(rewrite) 하에서는 안정적으로 유지되는지를 검증합니다.

본 논문은 이러한 감사 파이프라인 자체가 취약한 측정 시스템이라고 주장합니다. 감사 파이프라인의 결론은 보고된 수치에는 보이지 않는 구현 세부 사항에 의해 은밀하게 조작될 수 있습니다. 감사 파이프라인의 결함은 단순히 벤치마크 점수를 오염시키는 데 그치지 않고, 벤치마크의 결함을 탐지하기 위해 설계된 안전장치를 무력화하며, 독자가 해당 지표를 통해 벤치마크의 신뢰 여부를 결정하려 하기 때문에 최종 지표에는 아무런 흔적도 남기지 않습니다. 핵심적인 문제는 현재의 거버넌스 증거가 감사 파이프라인 자체의 신뢰성을 검증하기 위한 프로토콜을 갖추고 있지 않다는 점입니다.

2. 방법론

저자들은 감사 파이프라인이 침묵하는 실패(silent failures)에 취약함을 입증하기 위해 **자기 감사 사례 연구(self-audit case study)**를 수행합니다.

범위: 두 개의 오픈 웨이트 7B 인스트럭션 튜닝 모델(Qwen-2.5-7B-Instruct, Mistral-7B-Instruct-v0.3)을 다섯 가지 안전 벤치마크(TruthfulQA, BBQ, ToxiGen, CrowS-Pairs, XSTest)에 대해 평가.
설계: 10개 셀(2개 모델 × 5개 벤치마크), 벤치마크당 200개 항목, 결정론적 디코딩(deterministic decoding), 단일 시드(single seed).
섭동(Perturbations): 항목당 세 가지 유형(형식, 의미, 속성)과 각 유형별 세 가지 섭동.
지표: **대조 선택도 비율(Contrast Selectivity Ratio, CSR)**로 정의되며, $| \Delta_{attr} | / \max(| \Delta_{fmt} |, | \Delta_{sem} |, \epsilon)$ 로 계산됩니다. 이는 속성 섭동이 표면적 섭동보다 더 큰 점수 변화를 유도하는지를 측정합니다.
과정: 저자들은 "레거시(legacy)" 파이프라인을 실행하여 실패를 식별한 후, 이를 수정한 "캐노니컬(canonical)" 파이프라인을 만들어 다시 감사를 수행했습니다. 결정적으로, 이들은 수정 단계 중에 발생한 버그(F3c)를 포함하여 전체 버그 연대기를 추적했습니다.

3. 주요 기여

A. 5가지 실패 모드 (F1–F5)

본 논문은 침묵하며(silent), 실제로 발생하고(realized), 게이트 통과 여부를 판별할 수 있는(gateable) 파이프라인 수준의 실패에 대한 비포괄적 분류 체계를 제안합니다. 이들은 두 가지 계층으로 분류됩니다.

소프트웨어 보증 계층 (엔지니어링 리뷰를 통해 탐지 가능):

F1: 침묵하는 no-op 섭동: 섭동이 스코어러(scorer)가 읽지 않는 필드에 기록되는 경우(예: 질문 문자열을 편집했으나 스코어러는 확률값만 읽는 경우). 이 경우 섭동에 의한 $\Delta = 0$ 이 되어 비율 지표가 인위적으로 부풀려집니다.
F2: 정규 표현식 추출 아티팩트: 자유 형식의 생성물을 파싱하기 위해 정규 표현식을 사용하는 것은 모델의 행동이 아닌 정규 표현식의 견고함을 측정하는 것입니다. 만약 섭동이 생성 스타일을 변화시키면 파싱 가능성이 떨어지며, 이때 $\Delta_{fmt}$ 는 모델의 행동이 아닌 정규 표현식의 커버리지를 추적하게 됩니다.
F4: 깨진 부트스트랩 쌍 형성: 원본 항목과 섭동된 항목을 독립적으로 리샘플링하면 항목 간의 결합이 깨져 신뢰 구간과 분산 추정치가 부풀려집니다.

측정 충실도 계층 (벤치마크의 구성을 고려해야 함):
4. F3: 비충실한 스코어링: 스코어러가 벤치마크의 의도된 프로토콜을 구현하지 못하는 경우.
* F3a (역전된 컨벤션): 나이브한 로딩으로 인해 고정관념이 담긴 문장을 "정답"으로 처리하는 경우 (예: CrowS-Pairs).
* F3b (하네스 순서): 로더의 위치 편향 (예: TruthfulQA MC2에서 정답 인덱스를 $[0, \dots, k-1]$ 로 반환).
* F3c (스코어러 절단): 타겟 토큰이 상위 $k$ -log 확률 범위 밖에 있어(예: ToxiGen), 스코어러가 다수 클래스로 기본 설정되어 $\Delta = 0$ 아티팩트를 생성하는 경우.
5. F5: 메트릭-아키타입 불일치: 불변성(invariance) 벤치마크(변하지 않도록 설계된 것)에 진단용 메트릭(변화를 탐지하도록 설계된 것)을 적용하는 경우. 불변성 벤치마크에서의 낮은 CSR은 모호하며(깨진 벤치마크인지, 공정한 모델인지), 이는 스코어링 수정을 통해서는 해결될 수 없습니다.

B. 6단계 실사 게이트 (G1–G6)

감사 증거의 적격성을 결정하기 위한 계층적 프로토콜입니다. 셀은 다음 6가지 검사를 모두 통과해야만 "확정적(confirmatory)"인 것으로 간주됩니다.

G1: 스코어러 충실도 감사 (침묵하는 no-op 비율 < 20%, 파싱 가능성 $\ge$ 0.95).
G2: 베이스라인 이상의 원본 점수.
G3: 유의미한 분모 (표면적 델타 $\ge$ 0.02).
G4: 쌍을 이룬 불확실성 (항목 수준의 paired bootstrap).
G5: 아키타입 공개 (벤치마크를 진단용, 불변성 또는 혼합형으로 라벨링).
G6: 수정 회귀 검사 (셀별 검사 및 수정 사항에 대한 단위 테스트).

C. 자기 감사 연대기 프로토콜

저자들은 모든 버그, 발견 방법, 수정 사항, 그리고 전후 델타를 상세히 기록하는 "유보 및 공개(withholding and disclosure)" 프로토콜을 제안합니다. 이는 "깨끗한" 파이프라인과 버그가 은밀하게 흡수된 파이프라인을 구분해 줍니다.

4. 결과

10개 셀의 사례 연구에서 단 하나의 셀도 "확정적" 상태에 도달하지 못했습니다. 세부 내역은 다음과 같습니다:

3개 부적격: F1 (CrowS-Pairs) 또는 F5 (BBQ)로 인해 발생.
3개 스코어 미검증: ToxiGen 및 XSTest 스코어러에 대한 외부 검증 부재.
2개 G2–G4 실패: 수치적 게이트(베이스라인 점수 또는 분모 임계값) 실패로 인해 발생.
2개 탐색적: G1–G4는 통과했으나, G5와 G6가 "제안"된 상태(본 제출물에서 필수 게이트로 구현되지 않음)이므로 확정적이지 않은 것으로 간도됨.

핵심 발견: 한 가지 실패(F3c, 스코어러 절단)는 F1을 수정하는 과정에서 스스로 유발되었습니다. 이는 항목별 메타 로그-확률을 조사한 후에야 발견되었습니다. 이러한 검사가 없었다면, 파이프라인은 완전히 버그에 의한 결과물임에도 불구하고 그럴듯하고 출판 가능한 수치를 생성했을 것입니다.

5. 의의 및 주장

본 논문은 자신의 기여가 고전적인 구성 타당성 증거(수렴/판별 연구)를 대체하는 것이 아니라 보완하는 것이라고 규정합니다.

완곡한 주장: 저자들은 어떤 벤치마크가 유효하지 않다고 증명하거나 F1–F5가 완전한 분류 체계라고 주장하지 않습니다. 그들은 이 분류 체계가 "의도적으로 비포괄적"임을 명시합니다.
핵심 논거: 주요 기여는 유보 프로토콜입니다. 거버넌스 증거는 감사 파이프라인 자체가 실사 게이트를 통과하고 자기 감사 연대기를 공개하지 않는 한 "보증 등급"으로 받아들여져서는 안 됩니다.
시사점: 보고서의 "깨끗한" 수치가 신뢰할 수 있는 파이프라인을 보장하지는 않습니다. 제안된 게이트와 연대기가 없다면, 침묵하며 고장 난 파이프마인이 견고한 파이프라인과 구별되지 않습니다.

논문은 단 하나의 실행 가능한 요청으로 결론을 맺습니다: 거버넌스 용도로 벤치마크 기반 증거를 생성하는 모든 감사는 수치와 함께 반드시 자신의 자기 감사 연대기(최소한 Box 1의 8개 필드)를 공개해야 합니다.