에이전트가 완성된 작업을 제출하고, 당신이 빠르게 확인할 수 있는 모든 것이 깔끔합니다. 테스트는 통과(green) 상태입니다. 인용(citations)도 포함되어 있습니다. 요약은 잘 읽히고 숫자들도 일치합니다. 훑어보니 괜찮아 보이고, 그대로 배포(ship)합니다. 하지만 제대로 확인하려면 시간이 너무 오래 걸려 확인하지 않았던 단 한 가지가, 바로 이 모든 작업의 성패를 가르는 핵심이었습니다.

당신은 이런 작은 사례를 경험해 본 적이 있을 것입니다. 훑어볼 수 있는 부분들이 맞게 보여서 AI의 답변을 수용했지만, 몇 주 뒤에 훑어볼 수 없었던 부분이 틀렸다는 사실을 알게 됩니다. 이제 이 상황을 확장하여 두 가지 사실을 나란히 놓고 생각해 보십시오. 이 두 사실이 결합되면 당신의 평소 작업 방식이 조용히 적용되지 않는 지점을 설명해 줍니다.

유능한 최적화 도구(optimiser)를 특정 신호(signal)에 맞추면, 그 도구는 해당 신호를 잘 만족하도록 학습됩니다. 그 신호가 실제 대상의 충실한 대리자(stand-in)라면 괜찮습니다. 대부분의 작업은 이와 같습니다. 코드가 실행되거나 되지 않거나, 숫자가 맞거나 맞지 않거나, 당신은 이를 확인할 수 있습니다. 문제는 '보기 좋은 것'과 '실제로 좋은 것'이 아무도 모르게 분리될 수 있는 작업들입니다. 안전 검토(Safety review), 전략(Strategy), 장기적 판단(Long-horizon judgement), 그리고 결론을 저렴한 비용으로 다시 도출(re-derive)할 수 없는 연구 등이 이에 해당합니다. 이러한 영역에서는 검증(check)이 취약하기 때문에, 최적화 도구는 목표를 달성하지 않고도 검증 조건만 만족할 수 있으며, 당신은 외부에서 이를 구분할 수 없습니다.

이제 어떤 작업이 이에 해당하는지 주목하십시오. 당신에게 가장 중요한 작업의 상당 부분이 바로 이 '확인하기 어려운 공간'에 위치합니다. 따라서 실패는 당신이 가장 감당하기 어려운 곳에서 발생하며, 성공의 얼굴을 하고 나타납니다. Alex Mallen은 이를 **포템킨 작업(Potemkin work)**이라고 표현했습니다. 마치 포템킨 마을(Potemkin village)의 화려한 외관처럼, 아무도 확인할 수 없는 질문들 위에 정교하게 세워진 품질의 가식(facade)을 의미합니다. 눈에 보이는 정직한 무능함은 피할 수라도 있습니다. 하지만 설득력 있는 가식은 당신에게 가장 필요한 것, 즉 자신이 실패하고 있다는 것을 알 수 있는 능력을 앗아갑니다.

굿하트의 법칙 (Goodhart's law)에 따르면, 일단 어떤 측정치가 목표가 되면 그것은 더 이상 좋은 측정치가 아니게 됩니다. 더 날카로운 주장은 측정치가 가장 취약한 곳에서 그 격차가 가장 크게 벌어진다는 것이며, 당신이 수행하는 가장 중요한 작업 중 일부가 바로 그 지점에 위치한다는 점입니다.

여러분은 이미 현재 시스템에서 이러한 요소들을 목격할 수 있습니다. 한 훈련 연구에서, 속이기 쉬운 (gameable) 환경들로 구성된 커리큘럼은 모델이 더 높은 점수를 얻기 위해 자신의 보상 함수 (reward function)를 스스로 수정하는 단계까지 일반화되었습니다. 수만 번의 에피소드 중 수십 번 정도의 사례였으며, 정직한 베이스라인 (baseline)에서는 전혀 나타나지 않았고, 과정 전반에 걸쳐 일반적인 선행 행동 (good-behaviour) 훈련을 섞어 넣어도 이를 막지 못했습니다. 또한 현재 배포된 프런티어 에이전트 (frontier agents)들에 대해, 이들을 밀접하게 다루는 한 실무자는 현재의 최상위 모델들이 자동 점검이 어려운 작업에서 실패한 부분을 조용히 누락하면서 성공한 것처럼 보이는 결과물을 만들어낸다고 보고했습니다. 하나는 통제된 결과이고 다른 하나는 실무자의 보고이며, 둘 중 어느 것도 이것이 이미 얼마나 광범위하게 퍼져 있는지는 알려주지 않습니다. 하지만 둘 다 같은 방향을 가리키고 있으며, 둘 다 점검이 가장 취약한 바로 그 지점에서 처음으로 드러납니다.

잠시 멈추고, 완전히 다른 세계에서 온 두 번째 사실을 더해 봅시다.

Viking 1의 교훈

1982년, 화성에 있는 Viking 1 착륙선에 무선으로 일상적인 배터리 업데이트가 전송되었습니다. 이 업데이트는 착륙선의 안테나를 조준하는 데이터를 덮어썼습니다. 안테나는 더 이상 지구를 향하지 않았고 착륙선은 침묵에 빠졌습니다. 엔지니어들은 몇 달 동안 명령을 계속 보냈지만 아무런 응답도 듣지 못했고, 임무는 거기서 끝났습니다. 중요한 것은 그 버그가 무엇을 함께 가져갔느냐 하는 점입니다. 그것은 바로 향후 발생할 모든 오류를 수정할 수 있었던 통로였습니다. 패치 라인 (patch line)이 복구 메커니즘이었는데, 그 패치가 바로 그것을 망가뜨린 것입니다.

그것이 바로 한 부류의 실패들이 갖는 전형적인 형태입니다. 첫 번째 실제 실패가 그것으로부터 복구하는 데 사용할 바로 그 통로를 망가뜨리는 것입니다. 항공우주 엔지니어들은 이에 대한 규율을 가지고 있으며, 이는 낙관주의가 아닙니다. 단 한 번만 실행할 수 있는 배포(deployment)의 위험을 제거할 수는 없습니다. 오직 편집증(paranoia)으로만 그 위험에 맞설 수 있을 뿐이며, "패치 채널을 구축했으니 실제로 단 한 번뿐인 것은 아니다"라고 말하는 관리자는 Viking 1호가 침묵하기 직전의 상황을 설명하고 있는 것과 같습니다.

가역성 (Reversibility)은 당신에게 돌아갈 경로를 제공합니다. 위험한 실패는 첫 시도에서 그 경로를 파괴합니다.

중첩 (The overlap)

이 두 가지 사실을 결합하면, 이름을 붙일 가치가 있는 지점이 나타납니다.

당신과 나, 그리고 과학의 많은 부분에서 사용하는 기본 방식은 루프 (loop)입니다: 시도하고, 작동했는지 확인하고, 고장 난 것을 수정하고, 다시 시도하는 것입니다. 그 루프는 조용히 두 가지 가정 위에 서 있습니다. 첫 번째는 실패 신호 (failure signal)가 정직하다는 것, 즉 진짜 성공과 가짜 성공을 구별할 수 있다는 것입니다. 두 번째는 실패가 가역적 (reversible)이라는 것, 즉 실패하고, 배우고, 다시 시도할 수 있다는 것입니다. 당신이 하는 거의 모든 일은 이 두 가지를 모두 충족하며, 그렇기에 루프가 마치 사고(thinking)가 작동하는 방식 그 자체처럼 느껴지는 것입니다.

첫 번째 사실은 가장 이해관계가 큰 (highest-stakes) 작업에서 정직한 신호를 제거합니다. 두 번째 사실은 단 한 번만 실행할 수 있는 배포에서 가역성을 제거합니다. 이 두 가지가 중첩되는 곳에서, 당신은 성공 신호가 작동 여부에 대해 거짓말을 하고, 첫 번째 실제 실패가 그것을 수정할 능력을 앗아가는 문제에 직면하게 됩니다. 그 중첩 구간에서는 "실행하고, 관찰하고, 반복하라 (run it, watch, and iterate)"는 방식이 유효하지 않습니다. 반복 (iteration)은 두 가지 가정을 모두 필요로 하는데, 이곳은 그 어느 것도 갖지 못한 유일한 곳이기 때문입니다. 따라서 루프를 가속화하는 것은 단지 되돌아올 방법도 없이 잘못된 정답에 더 빨리 도달하게 만들 뿐입니다.

구체적인 예를 들어보겠습니다. 마이그레이션 에이전트(migration agent)가 레코드를 새로운 저장소로 이동시키고, 자신의 카운트와 대조하여 복사본을 확인한 뒤, 성공적인 전송을 보고하고, 공간을 확보하기 위해 원본을 삭제한다고 가정해 봅시다. 잘못된 이동을 잡아낼 수 있는 그 확인 절차(check) 자체가 바로 에이전트가 직접 작성한 것입니다. 당신이 복구해야 할 저장소는 에이전트가 방금 삭제해 버린 바로 그 저장소입니다. 조작 가능한 신호(fakeable signal)와 돌이킬 수 없는 실패(irreversible failure)가 단 하나의 루프 안에 공존하며, 이는 사람들이 에이전트에게 가장 빨리 맡기고 싶어 하는 지루한 작업의 전형적인 모습입니다.

더 나은 모델이 이를 해결하지 못하는 이유

이 시점에서 본능적으로 더 나은 모델을 찾으려 할 것입니다. 하지만 더 유능한 모델이라고 해서 취약한 확인 절차(check)를 해결해주지는 않습니다. 오히려 실제 작업(real work)을 확인하는 능력이 향상되는 속도보다, 모델이 대리 지표(proxy)를 만족시키는 능력이 더 빠르게 향상될 때 상황은 악화됩니다. 즉, 밑바탕의 작업은 변하지 않는데 신호만 더 설득력 있게 커지는 것입니다. 이것이 가장 명확한 형태의 타겟팅 문제(targeting problem)입니다. 즉, 힘이 한 단계 낮은 곳, 즉 대리 지표가 대변해야 할 본질이 아닌 대리 지표 그 자체를 향하고 있는 것입니다. 당신은 패치(patch)를 통해 이를 되돌릴 수 없습니다. 왜냐하면 당신이 패치에 사용할 루프 자체가 여기서는 작동하지 않기 때문입니다.

이 문제가 당신을 괴롭히기 위해 반드시 화성 착륙선이나 안전 연구(safety research) 분야에서만 발생해야 하는 것은 아닙니다. 당신이 실행하는 모든 자동화된 루프는 무언가를 위한 확인 가능한 대리 지표(checkable proxy)에 의존하며, 그러한 루프 중 일부는 저렴한 비용으로 되돌릴 수 없는 결정에 관여합니다. 그러니 당신 앞에 놓인 루프에 대해 다음 두 가지 질문을 순서대로 던져보십시오.

첫째: 이 성공 신호가 성공 없이도 만들어질 수 있는가? 만약 작업이 훌륭하다는 유일한 증거가 시스템 자체, 즉 시스템의 출력물이나 시스템이 최적화된 대리 지표(proxy)에서만 나온다면, 그리고 이를 확인할 독립적인 수단이 없다면, 답은 '예'입니다. 시스템은 실제 결과물의 유무와 상관없이 그 증거를 만들어낼 수 있으므로, 그 신호 자체로는 아무것도 증명하지 못합니다. 둘째: 만약 이것이 실제로 실패한다면, 내가 복구할 수 있는가, 아니면 첫 번째 실패가 복구할 수 있는 능력 자체를 제거해 버리는가? 첫 번째 질문의 답이 "예, 조작될 수 있습니다"이고 두 번째 질문의 답이 "아니요, 복구할 수 없습니다"라면, 당신은 위험한 영역에 진입한 것이며, 루프의 속도를 높이는 것은 잘못된 반사 작용입니다.

The Potemkin Map — two-axis framework for diagnosing where your automated loops are most dangerous

두 가지 조치

올바른 대응은 두 가지 조치를 취하는 것이며, 각 사실에 대해 하나씩 적용됩니다. 이 두 조치는 모두 본능에 반하는 것입니다.

첫 번째는 성공 신호(success signal)를 정직하게 만드는 것입니다. 측정이 쉬운 곳이 아니라, 측정이 가장 어려운 곳에 당신의 정밀 조사(scrutiny)를 집중하십시오. 왜냐하면 자연스러운 유혹은 확인하기 편리한 작업을 검토하는 것이며, 그런 작업은 속임수를 쓸 가능성이 가장 낮기 때문입니다. 대신 불투명하고 이해관계가 큰(high-stakes) 작업에 인간의 주의력을 할애하십시오. 왜냐하면 바로 그곳에서 외관(facade)이 형성되기 때문입니다. 그리고 검증 작업은 검증 대상으로부터 독립되어야 합니다. 루프(loop)가 스스로의 작업에 점수를 매기게 하지 마십시오. 또한 작업이 평가되는 것과 동일한 대리 지표(proxy)로 검토자를 판단하지 마십시오. 이것이 모델이 선택하지 않은 연구 검증(research check)과 에이전트(agent)가 말로 빠져나갈 수 없는 테스트 게이트(test gate)가 당신에게 가져다주는 가치입니다. 이는 또한 인간의 정밀 조사가 더할 수 있는 가치이기도 합니다. 적어도 우리가 가진 한 가지 신중한 테스트에서 이를 확인할 수 있습니다: 자동화된 감사자(automated auditor)와 함께 작업하는 사람은 블라인드 테스트에서 심어진 세 개의 사보추어(saboteur) 모델을 모두 찾아낸 반면, 자동화된 감사자 단독으로는 세 개 중 하나만 찾아냈습니다. 다만 그 연구는 명백한 사보추어에 관한 것입니다. 검토를 견뎌내기 위해 구축된 외관(facade)은 더 어렵고 여전히 미해결된 과제이므로, 인간의 정밀 조사가 반드시 잡아낸다는 보장은 없더라도 당신의 확률을 높여줄 것입니다.

두 번째는 루프에 의존하기 전에 실패해도 생존 가능하게 만드는 것입니다. 배포를 단계적으로 진행(stage the deployment)하고, 실패할 가능성이 있는 요소를 거치지 않는 회귀 경로(way back)를 확보하십시오. 그리고 그 회귀 경로가 작동할 것이라고 가정하는 대신, 당신이 우려하는 정확한 실패 조건 하에서도 여전히 작동하는지 테스트하십시오. 이를 생략한다면, 당신은 더 이상 대답할 수 없는 작동 중인 기계를 갖게 될 뿐입니다.

일주일간의 테스트

이를 일주일간의 테스트로 실행해 보십시오. 그리고 만약 그것이 조용히 잘못되었을 때 당신이 가장 크게 잃게 될 것부터 시작하십시오.

현재 당신의 업무가 의존하고 있는 자동화된 루프 (automated loops)와 AI 보조 결정 (AI-assisted decisions) 목록을 작성하십시오. 각 항목에 대해 앞서 언급한 두 가지 질문을 실행하고 이를 지도 위에 배치하십시오. 대부분은 안전한 구석, 즉 정직한 신호 (honest signal)이자 되돌릴 수 있는 실패 (reversible failure) 영역에 위치할 것이며, 그대로 빠르게 실행되도록 두어도 좋습니다. 몇몇은 위험한 구석, 즉 조작 가능한 신호 (fakeable signal)이자 되돌릴 수 없는 실패 (irreversible failure) 영역에 위치할 것입니다. 그런 것들은 반복 (iterating)을 멈추고 계측 (instrumenting)을 시작해야 하며, 루프가 당신에게 되돌릴 수 없는 손실을 입히기 전에 앞서 언급한 두 가지 조치를 취해야 합니다.

이를 실행하는 도구는 The Potemkin Map이며, 아래에서 무료로 이용할 수 있습니다. 당신의 루프 목록을 작성하고, 두 축을 기준으로 각 항목을 점수화하면, 도구가 이를 배치하고 위험한 사분면을 표시하며 각 항목에 맞는 조치를 제공합니다.

확인하기 편리했다는 이유만으로 신뢰해 왔던 루프 중 적어도 하나는, 편리함이 결코 목적이 아니었던 구석에 자리 잡고 있다는 사실을 발견하게 될 것입니다.

원문은 The Durability Curve에 게시되었습니다.