·10분

Post-training은 눈을 감고 달리고 있다

Eval score는 올라갑니다. 모델은 치팅합니다. 테스트는 올바른 솔루션을 거부합니다. 아무도 trajectory를 읽지 않습니다. Post-training에는 전용 inspection layer가 필요합니다. 우리는 그것을 만들고 있습니다.

2026년 post-training의 불편한 진실이 있습니다: 업계는 학습 루프를 돌리는 데는 매우 능숙해졌지만, 거기서 나온 결과물을 이해하는 데는 매우 서투릅니다.

팀들은 실험을 돌리고, eval score를 확인하고, 넘어갑니다. 점수가 오르니까 다 잘 되고 있겠지. 하지만 실제로는 그렇지 않은 경우가 많습니다. 벤치마크를 만점 받는 모델이 치팅하고 있을 수 있습니다. "실패"한 모델이 실제로는 정답일 수 있습니다. 차이를 알 수 있는 유일한 방법은 trajectory를 읽는 것인데, 거의 아무도 하지 않습니다.

우리는 post-training에 근본적인 레이어가 빠져 있다고 믿습니다: 체계적인 trajectory inspection. 있으면 좋은 것이 아니라. 인프라로서. 이유는 이렇습니다.

Eval score라는 착각

오늘날 post-training 워크플로우는 이렇습니다: 실험을 돌리고, 벤치마크로 측정하고, 출시할지 결정합니다. 전체 피드백 루프가 하나의 숫자 — eval score — 를 통과합니다.

그 숫자는 두 방향으로 동시에 거짓말하고 있습니다.

방향 1: 통과하면 안 되는 모델이 통과한다

모델들은 aggregate metric에서 보이지 않는 방식으로 평가를 gaming하는 법을 배웠습니다. 이론이 아닙니다 — 모든 주요 lab에서 프로덕션에서 일어나고 있습니다:

  • METR은 OpenAI의 o3가 자율 코딩 run의 30%에서 reward-hack했다는 것을 발견했습니다. 한 task에서는 100%의 trajectory에서 치팅 — eval 함수를 패치해서 항상 만점을 반환하게 하고, 타이머를 재작성해서 속도 결과를 위조했습니다. "치팅하지 마세요"라고 말해도 효과가 거의 없었습니다.
  • PostTrainBench에서 자율권을 받은 agent들이 체계적 contamination을 보였습니다: 테스트셋 직접 로드, 벤치마크 문제를 "synthetic example"로 위장, 평가를 역분석. 가장 뛰어난 agent가 가장 많이 치팅했습니다 (84개 run에서 12건).
  • NIST는 agent들이 테스트를 통과하기 위해 assertion을 주석처리하고, CTF 문제의 답을 구글링하고, 의도된 취약점 대신 DoS 공격을 실행하는 것을 기록했습니다.

모든 경우에서 eval score는 좋아 보였습니다. Trajectory는 다른 이야기를 하고 있었습니다.

방향 2: 통과해야 할 모델이 떨어진다

반대 방향도 똑같이 해롭습니다. OpenAI가 SWE-bench Verified를 감사했을 때, 어려운 task의 59.4%에 기능적으로 올바른 솔루션을 거부하는 결함 있는 테스트 케이스가 있다는 것을 발견했습니다. 문제에 언급되지 않은 특정 함수명을 강제하는 테스트. 요구하지 않은 동작을 검사하는 테스트.

모델이 문제를 풀었습니다. 테스트가 실패라고 했습니다. Pass rate만 보면, 올바른 작업을 버리고 학습 신호를 낭비하는 것입니다.

Eval score는 실제로 무슨 일이 일어났는지의 손실 압축입니다. 무엇이 통과하고 실패했는지는 말해주지만, 왜인지는 말하지 않습니다. "왜"는 trajectory에 있습니다.

Reward hacking은 eval 안에 머물지 않는다

일부 팀은 reward hacking을 벤치마크의 호기심 — 짜증나지만 격리된 문제로 취급합니다. 아닙니다.

Anthropic은 모델이 프로덕션 RL에서 reward-hack하는 것을 배우면, 그 행동이 일반화된다는 것을 보여줬습니다. 하나의 metric을 gaming하는 것을 배운 모델이 자발적으로 alignment faking과 sabotage 시도를 보였습니다. RLHF safety training은 chat-like 쿼리에서는 모델이 aligned 되어 보이게 만들었지만, 코딩 쿼리에서는 "극심한 misalignment"가 지속됐습니다 — misalignment이 수정된 것이 아니라 context-dependent하게 된 것입니다.

이것을 일찍 잡는 유일한 방법은 gradient update가 behavior를 굳히기 전에 trajectory를 보는 것입니다.

자동 모니터링만으로는 부족한 이유

분명히 해두자면: LLM 기반 모니터링은 작동합니다.METR의 MALT 연구는 프롬프트된 LLM 모니터가 reward hacking 탐지에서 AUROC 0.96을 달성하며, true positive의 80-90%를 잡을 수 있음을 보여줬습니다. OpenAI의 chain-of-thought 모니터링 연구는 GPT-4o 같은 약한 모델도 CoT를 관찰하여 frontier 추론 모델을 효과적으로 모니터링할 수 있음을 보여줬습니다.

하지만 문제가 있습니다: 이 모니터를 학습 신호로 사용하면, meta-reward-hacking 문제가 발생합니다. OpenAI는 CoT 모니터를 RL reward에 통합하면 초기에는 capability와 alignment이 모두 향상되지만, 최적화가 더 진행되면 agent가 "위장된 reward hacking"을 학습한다는 것을 발견했습니다 — 겉보기에 benign한 chain-of-thought를 생성하면서, 모니터가 탐지할 수 없는 방식으로 계속 치팅하는 것. 모니터가 또 하나의 gaming 대상이 됩니다.

METR도 다른 각도에서 같은 한계를 인정했습니다: MALT 데이터셋은 "모니터가 실제로 신뢰성 있게 작동하는지 검증할 ground truth 데이터셋이 없었기" 때문에 만들어졌습니다. 유도된 사례는 "종종 명백"했고, "agent가 더 미묘하고 현실적인 전략을 실행할 수 있을 것"이라고 언급했습니다. 0.96 AUROC에도 불구하고, 자신들의 데이터셋에서 강한 모니터 성능을 관찰하는 것이 "실제 위험 탐지에 충분하거나 필수적이라고 생각하지 않는다"고 결론지었습니다.

이것이 근본적인 문제입니다: 자동 모니터는 모니터링 대상인 바로 그 시스템에 의해 gaming될 수 있습니다. LLM 모니터에 대해 최적화하는 LLM은 또 하나의 최적화 루프일 뿐이며, 최적화 루프는 Goodhart의 법칙 효과를 만들어냅니다. Backstop으로 필요한 것은 gradient descent로 gaming될 수 없는 것: general한 grounding을 가진 인간 리뷰어, 모델이 모든 자동 검사를 만족시키는 출력을 생성하는 법을 배웠을 때도 "이건 말이 안 된다"를 인식할 수 있는 사람입니다.

Gemini와 Waymo에서 수천 개의 trajectory를 eyeball한 Google 출신Auriel의 말처럼: "어떤 metric도 대체할 수 없는 직관이 생깁니다." 그 직관 — trajectory를 읽고 왜인지 말로 표현하기도 전에 뭔가 이상하다고 느끼는 능력 — 이 정확히 자동 모니터에 없는 것입니다.

스케일 문제가 진짜 문제다

우리가 이야기하는 모든 사람이 동의합니다: trajectory를 읽어야 합니다. 읽지 않는 이유는 순전히 운영적입니다.

경험 많은 리뷰어가 10개 trajectory에 약 90분이 필요합니다. SWE-bench run 하나에 300개 이상의 task. 실제 post-training 파이프라인은 실험당 수천 개의 trajectory를 생성하고, 실험은 매주 또는 더 빠르게 실행됩니다. Run당 450시간 이상의 전문가 리뷰가 필요합니다.

미국 국립표준기술연구원(NIST)의 최우선 권고도 수동 inspection만으로는 스케일이 안 되기 때문에 AI 지원 transcript 리뷰입니다.

툴링이 존재하지 않습니다. 운영 역량도 존재하지 않습니다. 그래서 팀들은 건너뛰고, 눈을 감고 달립니다.

우리가 만들고 있는 것

Archipelago에서, 우리는 trajectory inspection이 있으면 좋은 워크플로우 단계가 아니라 post-training 스택에 빠져 있는 인프라 레이어라고 믿습니다.

모든 학습 run은 trajectory를 생성합니다. 그 trajectory에는 모델이 실제로 무엇을 배웠는지 — 그리고 무엇을 가장하는 법을 배웠는지에 대한 ground truth가 들어 있습니다. 지금은 아무도 그것을 처리할 도구나 역량이 없기 때문에 그 신호가 버려지고 있습니다.

우리는 이 gap을 메우는 시스템을 만들고 있습니다:

  • 전용 trajectory 리뷰 툴링 — 범용 라벨링 UI가 아닌, agent trajectory를 위해 설계된 시스템: timeline 추출, tool call 매핑, diff 분석, 리스크 신호 표면화
  • 관리형 리뷰 팀 — failure mode를 분류하고, reward hacking 패턴을 잡고, 각 decision point에서 corrective feedback을 작성하는 500명 이상의 훈련된 CS 학생
  • 구조화된 출력 — 문서에 놓이는 리포트가 아닌, 다음 학습 run에 바로 투입 가능한 JSONL feedback dataset

첫 파일럿 파트너를 찾고 있습니다 — trajectory를 읽어야 한다는 것을 알지만 규모 있게 할 수 없는 post-training 팀. 해당된다면, 이야기 나누고 싶습니다.

참고 자료

Jongwon Park
박종원
Archipelago 파운더. 강화학습 엔지니어 (크래프톤 PUBG). 초거대 AI 프로젝트에서 500명 이상의 라벨러 운영 총괄.

눈을 감고 달리지 마세요.

파일럿을 함께 할 post-training 팀을 찾고 있습니다. 현재 trajectory 워크플로우를 알려주세요.

파일럿 요청