AX-Ray: 성능 벤치마크 이후의 AI 안전진단 계층
요약
AI 모델 평가는 지금까지 주로 "얼마나 잘 맞히는가"에 집중해 왔다. 그러나 실제 배포 환경에서는 정답률만으로 충분하지 않다. 모델의 내부 계산 경로가 인과적으로 올바른지, serving 경로가 일관적인지, 장문·캐시·양자화·agentic 실행 환경에서 안전하게 동작하는지까지 확인해야 한다.
VIDRAFT의 AX-Ray는 이 문제를 다루기 위한 AI/AX 안전진단 프레임워크다. AX-Ray는 FINAL-Bench Diagnostics 기반으로 모델 자체, serving 인프라, 운영·규제·에이전트 리스크를 함께 평가한다.
핵심 성과는 명확하다. AX-Ray는 범용 공개 모델 2종에서 인과누설(causal leakage) 결함을 진단·재현·실증한 공개 사례를 제시했다.
Zyphra/Zamba2-1.2Bnvidia/Nemotron-H-8B-Base-8K
이 결과는 단순한 벤치마크 실패가 아니다. 모델이 답을 틀렸다는 문제가 아니라, 모델의 계산 경로 자체가 지켜야 할 causal constraint를 위반할 수 있음을 보여준 사례다.
관련 링크:
문제 정의: 성능은 안전성을 보장하지 않는다
대부분의 LLM 리더보드는 최종 출력의 정답 여부를 측정한다. GPQA, MMLU, HumanEval, GSM 계열 평가가 대표적이다. 이 방식은 필요하다. 모델이 문제를 풀 수 있는지 확인하지 않고 배포할 수는 없다.
하지만 capability benchmark는 다음 질문에 충분히 답하지 못한다.
- prefix representation이 suffix에 의해 오염되지 않는가
- KV-cache 경로와 non-cache 경로가 일관적인가
- chunked prefill, streaming, long-context serving에서 causal mask가 유지되는가
- fp8/bf16/fp32 경로에서 logit consistency가 유지되는가
- serving engine, tokenizer, chat template, position encoding이 동일한 의미를 보존하는가
- agent가 tool, memory, permission을 사용할 때 위험이 통제되는가
즉, 높은 성능 점수는 배포 안전성의 필요조건일 수는 있어도 충분조건은 아니다.
AX-Ray의 출발점은 이 간극이다. 모델을 "잘 맞히는 시스템"이 아니라 "배포 가능한 계산 시스템"으로 진단해야 한다는 관점이다.
인과누설이란 무엇인가
Autoregressive language model에서 시점 t의 hidden state 또는 logit은 원칙적으로 t 이후의 token에 의존해서는 안 된다.
개념적으로는 다음 불변성이 필요하다.
prefix = x[0:t]
suffix = x[t+1:n]
h_t(prefix) ~= h_t(prefix + suffix)
logits_t(prefix) ~= logits_t(prefix + suffix)정상적인 causal mask가 적용된 모델에서는 prefix 위치의 표현이 미래 token을 볼 수 없어야 한다. 그런데 suffix 또는 future token이 prefix hidden state, logit, scoring behavior에 영향을 준다면 causal leakage가 발생한 것이다.
이 결함은 다음과 다르다.
| 항목 | 인과누설과의 차이 |
|---|---|
| Hallucination | 잘못된 사실을 생성하는 문제 |
| Jailbreak | 안전정책을 우회하는 문제 |
| Prompt injection | 외부 지시가 시스템 지시를 오염시키는 문제 |
| Benchmark contamination | 평가 데이터가 학습에 섞인 문제 |
| Causal leakage | 모델 계산 경로가 causal constraint를 위반하는 문제 |
따라서 인과누설은 단순한 출력 품질 문제가 아니다. 모델의 내부 추론 경로, serving correctness, evaluation validity에 직접 연결되는 구조적 결함이다.
왜 일반 벤치마크는 이를 놓치는가
일반적인 capability benchmark는 최종 답변을 관찰한다. 모델이 정답을 맞히면 통과하고, 틀리면 실패한다. 그러나 인과누설은 최종 답변만 봐서는 드러나지 않을 수 있다.
일반 벤치마크는 보통 다음을 묻지 않는다.
- 그 답이 causal mask가 보장된 상태에서 나온 것인가
- prefix hidden state가 suffix에 의해 변하지 않았는가
- cache path와 full forward path가 같은 의미를 유지했는가
- chunked serving에서 token boundary가 안전하게 처리되었는가
- long-context 처리 중 position encoding이나 attention path가 오염되지 않았는가
AX-Ray는 이 지점을 safety diagnostics의 핵심 대상으로 본다. 정답률이 아니라 계산 경로의 신뢰성을 검사하는 것이다.
AX-Ray의 진단 구조
AX-Ray는 3축, 11개 카테고리, 117개 공개 진단 항목으로 구성된다.
| Axis | 목적 |
|---|---|
| MODEL-SCAN | 모델 수준의 causal correctness, reliability, robustness, safety, data integrity, efficiency, internal structure 진단 |
| AX-SCAN | serving, infrastructure, security, compliance, operational deployment risk 진단 |
| AGENT-SCAN | tool permission, hijacking, loop, memory contamination, deletion behavior, autonomy governance 등 agentic risk 진단 |
현재 공개 Dataset의 117개 item record는 MODEL-SCAN 89개, AX-SCAN 28개로 구성되어 있다. AGENT-SCAN은 Space와 리포팅 체계에서 독립 축으로 다뤄지며, agentic deployment risk를 확장 진단하는 방향으로 연결된다.
11개 기술 카테고리
| Category | Scope |
|---|---|
| D1. Causal Safety and Serving Integrity | prefix invariance, causal leakage, cache consistency, tokenizer/serving correctness |
| D2. Reliability | hallucination, factuality, calibration, abstention, citation reliability |
| D3. Robustness and Long Context | adversarial suffix, long-context retrieval, prompt brittleness |
| D4. Security, Safety, and Alignment | jailbreak, harmful compliance, prompt injection, toxicity, bias |
| D5. Data Integrity and Evaluation Methodology | contamination, memorization, PII leakage, benchmark validity |
| D6. Efficiency, Quantization, and Architecture | quantization sensitivity, MoE health, KV-cache scaling |
| D7. White-Box Internal Structure | layer importance, routing, attention heads, activation health, causal tracing |
| D8. Remediation and Treatment | targeted LoRA, layer-guided merge, expert rebalance, knowledge editing |
| AX-A. Serving Infrastructure | cross-engine drift, latency, throughput, determinism, autoscaling |
| AX-B. Infrastructure Security | endpoint auth, SSRF, supply chain, RCE, secrets, logging |
| AX-C. Regulatory Compliance | AI obligations, privacy, public-sector security, certification contexts |
이 구조의 장점은 기술 진단과 운영 책임을 분리하지 않는다는 점이다. 모델 내부의 결함은 serving, 보안, 규제, agentic workflow로 전파된다. AX-Ray는 이 전파 경로를 하나의 safety surface로 본다.
인과누설 발견의 기술적 의미
AX-Ray가 하이라이트한 Zyphra/Zamba2-1.2B와 nvidia/Nemotron-H-8B-Base-8K 사례는 capability leaderboard 관점보다 더 깊은 층의 문제를 드러낸다.
특히 nvidia/Nemotron-H-8B-Base-8K가 포함된 점은 기술적으로 상징성이 크다. 엔비디아는 AI 인프라, GPU, inference ecosystem에서 가장 중요한 이름 중 하나다. 그러나 이 사례가 말하는 바는 특정 기업 전체에 대한 일반화가 아니다.
핵심은 이것이다.
브랜드, 파라미터 수, 성능 점수, 인프라 신뢰도는 causal correctness를 자동으로 보증하지 않는다.
모델은 별도로 진단되어야 한다. Serving stack도 별도로 진단되어야 한다. White-box path, API path, cache path, quantized path는 서로 다른 failure surface를 가진다.
이 점에서 AX-Ray는 모델 평가를 다음과 같이 확장한다.
Capability Benchmark
-> Can the model answer?
Safety Diagnostics
-> Can the model compute correctly?
-> Can the model serve consistently?
-> Can the model be governed in deployment?Solar-Open2-250B 처리 방식: claim boundary의 중요성
AX-Ray는 upstage/Solar-Open2-250B에 대해서도 API-audited 결과를 기록한다. 다만 이 항목은 confirmed causal leakage case로 분류하지 않는다.
공개 글의 핵심 구분은 다음과 같다.
| 항목 | AX-Ray 해석 |
|---|---|
prompt_logprobs scoring anomaly |
API 또는 serving 경로의 caveat |
| hidden-state D1/D7 미측정 | white-box causal leakage 미확정 |
| leaderboard 반영 | official_dhs=false, white-box pending |
| causal-leak highlight | 해당 없음 |
이 구분은 중요하다. Serving anomaly, API scoring issue, confirmed hidden-state causal leakage는 서로 다른 주장이다. AX-Ray는 이들을 섞지 않는다.
기술 진단에서 가장 위험한 실수는 "비슷해 보이는 이상 현상"을 하나의 결론으로 뭉개는 것이다. AX-Ray의 claim boundary는 이 문제를 피하기 위한 장치다.
공개 Dataset의 역할
AX-Ray Dataset은 117개 diagnostic item record를 공개한다. 각 항목은 단순 체크리스트가 아니라 다음 정보를 연결하기 위한 구조를 갖는다.
- diagnostic focus
- failure rationale
- detection direction
- remediation direction
- severity
- automation level
- evidence class
- governance reference
- jurisdictional mapping
특히 Dataset은 한국, EU, 미국, 일본, 중국, UAE, 사우디아라비아 등 여러 법·규제·윤리·종교법적 거버넌스 맥락과 진단 항목을 연결한다. 이는 기술 진단을 실제 배포 책임과 연결하기 위한 설계다.
AX-Ray는 이를 "표준"이 아니라 "가이드라인"으로 제시한다. 즉, 법률 자문이나 인증을 대체하는 것이 아니라, 기술적 위험을 실무자가 검토 가능한 evidence structure로 변환하는 역할을 한다.
공개 범위와 비공개 범위
AX-Ray는 안전진단 프레임워크이지만, 모든 내부 방법을 공개하지는 않는다. 특히 인과누설 진단은 특허권으로 보호되는 영역이므로 공개 범위가 제한된다.
공개되는 정보:
- leaderboard row
- model-level diagnostic summary
- category score
- item taxonomy
- governance mapping structure
- selected public report
- confirmed causal-leakage highlight
공개하지 않는 정보:
- proprietary probe recipe
- threshold-level implementation detail
- raw sensitive prompt
- harmful output
- internal judge prompt
- scoring recipe
- exploit-ready procedure
이 균형은 필요하다. AI safety 연구는 투명해야 하지만, 동시에 공개물이 공격 매뉴얼이 되어서는 안 된다.
배포 관점에서의 F-gate
AX-Ray는 confirmed causal leakage를 단순 감점 요인이 아니라 deployment-blocking defect로 취급한다. 즉, aggregate score가 높더라도 causal leakage가 확인되면 F-gate가 적용될 수 있다.
이는 safety engineering 관점에서 자연스러운 결정이다. 어떤 시스템이 대부분의 입력에서 잘 동작하더라도, core invariant가 깨지는 조건이 확인되면 배포 적합성을 다시 평가해야 한다.
모델 진단에서 중요한 것은 평균 점수만이 아니다.
mean capability score: high
critical invariant violation: true
deployment decision: block or require remediationAX-Ray의 메시지는 단순하다. 안전성 결함은 평균 성능에 묻히면 안 된다.
결론
AX-Ray의 핵심 기여는 새로운 리더보드 하나를 만든 것이 아니다. AI 평가의 관점을 capability benchmark에서 deployment diagnostics로 확장한 것이다.
인과누설은 그 전환을 보여주는 대표 사례다. 모델이 정답을 잘 맞히는지와 모델이 인과적으로 올바른 계산 경로를 유지하는지는 다른 문제다. 그리고 후자는 실제 배포 환경에서 훨씬 더 중요해질 수 있다.
AI 시스템은 이제 연구실을 넘어 공공서비스, 금융, 의료, 보안, 과학연구 자동화, agentic workflow로 이동하고 있다. 이 환경에서 필요한 질문은 더 어렵다.
이 모델은 얼마나 똑똑한가?
그 다음 질문은 더 중요하다.
이 모델은 안전하게 배포하고 운영하고 통제할 수 있는가?
AX-Ray는 이 두 번째 질문을 위한 기술적 진단 계층이다.