모델만이 아니라 환경도 감사받아야 합니다
RL 환경에도 공격자 관점의 독립 감사가 필요한 이유
완성된 모델을 제3자가 평가하는 관행은 불과 2년 만에 AI 안전 분야에서 공통으로 쓰는 몇 안 되는 도구 가운데 하나로 자리 잡았고, 실제로 효과가 있습니다. 하지만 이 평가는 모델까지만 봅니다. 모델의 행동이 실제로 만들어지는 곳은 그보다 한 단계 아래에 있습니다. 무엇이 강화될지는 프론티어 모델을 학습시키는 RL 환경이 정하고, 그 안의 verifier는 task를 대신해 재려고 사람이 손으로 만든 불완전한 잣대일 뿐입니다.
같은 방식의 task, verifier, harness로 만들어진 공개 에이전틱 벤치마크를 감사해 보면 허술한 verifier, 유출된 정답, 풀지 않아도 통과되는 task가 곳곳에서 나옵니다. 프론티어 랩들도 자사 학습 과정에서 같은 문제, 곧 reward hacking이 나타난다고 보고합니다. Task를 풀지 않아도 통과시켜 주는 verifier는 잘못된 행동을 강화하고, 그 행동을 잡아내야 할 모니터까지 무디게 만들며, 최악의 경우 더 큰 misalignment의 씨앗이 됩니다. 개발자가 의도하지 않았더라도 이미 안전 문제입니다.
내부 QA를 늘린다고 메워지는 틈이 아닙니다. 한 팀이 자기 환경을 점검하면 그 팀의 사각지대는 그대로 남고, 환경이 다루는 작업이 더 길어지고 복잡해질수록 틈은 더 벌어집니다. 그렇게 남은 사각지대까지 찾아내려면 독립적이고 서로 다른 시각을 가진 사람들이 계속 들여다봐야 합니다.
그래서 우리는 영향이 큰 RL 환경이라면 프론티어 모델 학습에 쓰이기 전에도, 쓰이는 동안에도 공격자 관점의 독립 감사(adversarial audit)를 받아야 한다고 주장합니다. 이미 자리 잡은 제3자 모델 감사를 한 단계 더 깊이, 학습에 들어가는 입력 자체까지 확장하자는 것입니다. 가장 까다로운 반론은 랩의 지적 재산이 노출된다는 것인데, 이는 접근을 통제하고 모니터링하면 해결할 수 있습니다. 효과적인 설계 가운데 하나는 다양한 사람이 허점을 찾도록 보상을 거는 시장, 곧 버그 바운티입니다. 최종 모델이 아니라 학습 입력을 감사하므로 출시를 늦출 필요가 없습니다. 또 허점이 있는 환경은 랩 스스로의 학습을 망칩니다. 그러니 랩으로서도 규제를 기다릴 것 없이 안전 기관들과 자발적인 시범 사업을 벌여 이 생태계를 만들 이유가 있습니다.