테스트 타임에 규칙을 벡터 하나로 담는 방법

오늘 살펴볼 논문은 arXiv에 공개된 Implicit Rule Induction with Test-Time Task Embeddings in ARC-like Tasks (2609.21181)입니다. 원문 링크는 제목 아래에 걸려 있습니다. 이 논문이 내세우는 주장은 하나의 문장으로 정리할 수 있는데, 테스트 타임에 task embedding만 먼저 고치는 Embed-TTT라는 두 단계 절차를 거치면 ARC 스타일 과제에서 규칙을 작은 벡터에 알아서 담아낼 수 있다는 것입니다.

이 논문은 사전학습된 백본에 변환 규칙을 담는 학습 가능한 임베딩을 덧붙인 VARC라는 구조에서 출발하는데, 기존 VARC가 테스트 타임 학습을 백본과 task embedding에 함께 적용했다면 이번에는 순서를 갈라서 먼저 임베딩만 고치고 그 다음에 임베딩을 고정하고 백본을 고칩니다. 평가는 ARC-AGI-1과 ConceptARC, 그리고 규칙을 미리 알고 있는 두 가지 통제 데이터셋에서 이뤄졌습니다.

왜 작은 벡터 하나에 눈이 갔을까

안녕하세요, 패트릭입니다. 저는 이 논문을 처음 봤을 때 모델 크기 이야기가 아니라 순서 이야기가 먼저 눈에 들어왔는데요. 보통 테스트 타임 학습이라고 하면 주어진 예제에 맞춰 모델 전체를 조금씩 움직이는 그림을 떠올립니다. 그런데 여기서는 전체를 한꺼번에 움직이지 않고, 먼저 작은 벡터 하나만 움직여서 규칙을 잡아보자는 제안을 합니다. 그렇다면 왜 굳이 순서를 나눠야 할까요?

제가 이 논문에서 가장 흥미롭게 본 부분은 규칙이라는 말을 가중치 전체에 흩어놓지 않고 임베딩이라는 좁은 통로로 몰아넣었다는 선택입니다. 규칙이 벡터에 담긴다면 그 벡터를 꺼내서 비교하고, 검색하고, 분석할 수 있으니까요. 규칙이 모델 전체에 스며들어 있으면 성능은 올라도 무엇을 배웠는지 말하기 어렵습니다. 반면 규칙이 작은 벡터에 모여 있으면 성능과 해석이 함께 갑니다. 이 차이는 생각보다 중요합니다.

물론 작은 벡터가 만능이라는 뜻은 아닙니다. 벡터 하나로 복잡한 변환을 다 표현할 수 있을지, 그리고 테스트 타임의 몇 개 예제만으로 그 벡터가 안정적으로 찾아질지는 바로 의심해볼 대목입니다. 그래서 저는 숫자를 보기 전에 이 질문을 먼저 품고 읽기 시작했습니다. 과연 몇 개 안 되는 예제로 규칙 벡터가 매번 제대로 찾아질까, 그리고 그 벡터가 우연히 맞힌 답이 아니라 규칙 자체를 담고 있다고 어떻게 믿을 수 있을까.

ARC 스타일 문제는 왜 매번 처음처럼 느껴질까

ARC 스타일 과제를 처음 보면 규칙이 꽤 단순해 보입니다. 색을 바꾸고, 도형을 옮기고, 대칭을 만들고, 크기를 키우는 정도니까요. 그런데 막상 몇 개만 풀어보면 매번 처음처럼 느껴집니다. 왜냐하면 예제가 두세 개만 주어지고, 그 예제에서 규칙을 스스로 찾아내야 하기 때문입니다. 정답을 외운 모델은 여기서 바로 막힙니다.

생각해보면 사람도 비슷하게 배웁니다. 처음 보는 퍼즐을 만나면 손으로 몇 번 그려보면서 "아, 이건 회전이 아니라 뒤집기였네" 하고 감을 잡습니다. 모델에게도 그에 해당하는 과정이 필요한데, 일반적인 학습은 미리 본 규칙에는 강하고 처음 보는 규칙에는 약합니다. 학습 때 본 분포 안에서는 잘 맞히지만, 분포를 조금만 벗어나도 규칙을 못 찾습니다. 그렇다면 규칙 찾기와 규칙 실행을 같은 능력으로 묶어서 평가해도 될까요? 저는 이 질문이 이 논문 전체를 관통한다고 봅니다.

여기서 한 가지 짚고 넘어갈 점이 있습니다. ARC-AGI-1이나 ConceptARC 같은 벤치마크는 점수 자체도 중요하지만, 그 점수가 무엇을 재고 있는지가 더 중요합니다. 어떤 모델이 점수를 올렸다고 해서 규칙을 더 잘 찾은 것인지, 아니면 규칙을 실행하는 손놀림이 더 좋아진 것인지가 섞여 있기 때문입니다. 이 구분이 흐리면 연구가 엉뚱한 방향으로 갈 수 있습니다. 점수는 올랐는데 처음 보는 규칙 앞에서는 여전히 헤매는 식입니다. 그래서 저는 이 논문의 벤치마크 이야기가 단순한 부록이 아니라 문제의식의 일부라고 읽었습니다.

뼈대는 그대로 두고 규칙만 따로 담으면 어떨까

VARC라는 구조를 처음 들으면 "사전학습된 큰 모델 옆에 작은 벡터를 하나 붙인 것 아닌가?"라는 생각이 들 수 있습니다. 그런데 논문을 조금 더 들여다보면 진짜로 눈여겨볼 부분은 벡터를 붙였다는 사실 자체가 아니라, 규칙이라는 일을 백본과 임베딩 사이에 다시 나눴다는 데 있습니다. 백본은 격자를 읽고 그리는 실행 능력을 맡고, 임베딩은 이번 과제의 변환 규칙이 무엇인지를 가리키는 역할을 맡습니다.

이 나눔이 있으면 테스트 타임의 풍경이 달라집니다. 새로운 과제가 오면 백본을 크게 흔들기 전에 "이번 규칙은 어디쯤일까?"를 작은 벡터 안에서 먼저 찾습니다. 비유하자면 큰 공장을 통째로 옮기기 전에 작은 나침반부터 돌려보는 셈인데요. 공장은 무겁고, 나침반은 가볍기 때문입니다. 그래서 탐색 비용이 작고, 잘못 찾았을 때 되돌리기도 쉽습니다.

저는 여기서 멈칫했습니다. 규칙이 정말 그렇게 깔끔하게 분리될까 하는 의문이 들었기 때문입니다. 실제 변환에서는 규칙과 실행이 얽혀 있는 경우가 많습니다. 예를 들어 도형을 옮기는 문제에서는 어디로 옮길지와 어떻게 그릴지가 따로 떨어지지 않습니다. 그런데도 임베딩이라는 좁은 병목을 두면 모델이 알아서 규칙 쪽 정보를 그리로 몰아넣을까요? 이 논문은 그 물음에 실험으로 답하겠다고 말합니다. 먼저 임베딩만 고치고, 그 다음에 백본을 고치는 순서입니다.

한꺼번에 고치지 않고 순서를 나누면 벌어지는 일

기존 VARC의 테스트 타임 학습은 백본과 task embedding을 함께 고치는 방식이었습니다. 주어진 예제에 맞춰 큰 모델과 작은 벡터를 동시에 움직이는 방식입니다. 반면 이번에 제안된 Embed-TTT는 순서를 분명히 나눕니다. 먼저 task embedding만 미세 조정하고, 그 다음에는 임베딩을 고정(freeze)한 채 백본을 미세 조정합니다.

표면적으로 보면 단순합니다. 실제로는 그렇지 않습니다. 함께 고치면 큰 백본이 작은 벡터의 일을 가로챌 수 있기 때문입니다. 백본은 파라미터가 많아서 예제 몇 개에도 쉽게 과적합될 수 있는데, 그러면 규칙이 벡터에 남지 않고 백본 가중치 어딘가에 흩어집니다. 결과적으로 답은 맞힐지 몰라도 규칙 벡터는 비어 있게 됩니다. 순서를 나누면 이런 가로채기를 막을 수 있습니다. 먼저 작은 벡터에게만 기회를 주면, 그 벡터가 규칙을 담아내야만 손실이 내려가니까요.

그렇다면 두 번째 단계는 왜 필요할까요? 임베딩만으로 규칙의 방향이 잡혔다 해도, 백본이 그 방향을 실행에 옮기는 손놀림까지 완벽하지는 않기 때문입니다. 그래서 임베딩을 고정하고 백본을 다듬는 두 번째 단계가 이어집니다. 저는 이 순서를 보고 일종의 역할 분담 계약처럼 느꼈습니다. 전반전에는 규칙 찾기를 임베딩이 전담하고, 후반전에는 규칙 실행을 백본이 다듬는 것이죠. 물론 이 계약이 매번 지켜질지는 실험으로 확인해야 합니다. 그래서 다음 숫자들이 중요합니다.

0.01퍼센트만 건드렸는데 풀리기 시작했다면

여기서 재미있는 질문이 생깁니다. 전체 파라미터의 0.01퍼센트도 안 되는 작은 임베딩만 건드렸는데, 정말로 문제가 풀릴까요? 논문이 보고한 결과는 "어느 정도는 그렇다"입니다. task embedding만 최적화했을 뿐인데 ARC-AGI-1과 ConceptARC, 그리고 Mini-ARC 과제 중에서 적지 않은 fraction이 풀렸다고 합니다.

저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 작은 벡터만으로 풀린다는 말은 뒤집으면 규칙의 상당 부분이 그 작은 공간에 들어간다는 뜻이기 때문입니다. 큰 모델을 통째로 돌리지 않아도 방향이 잡힌다는 건, 백본이 이미 실행 능력은 갖추고 있고 남은 일이 규칙 식별에 가깝다는 신호로 읽힙니다. 저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 이런 관점에서 보면 0.01퍼센트라는 숫자는 단순한 효율 자랑이 아니라 구조에 대한 힌트입니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 적지 않은 fraction이 풀렸다는 말이 모든 과제가 풀렸다는 뜻은 아니기 때문입니다. 임베딩만으로 풀리는 과제와 백본까지 건드려야 풀리는 과제가 나뉜다면, 그 경계 자체가 연구 대상이 됩니다. 어떤 규칙은 작은 벡터로 충분하고, 어떤 규칙은 실행 다듬기까지 필요할까요? 논문은 통제 데이터셋에서 규칙을 미리 알고 있는 설정을 만들어 이 경계를 들여다봅니다. 알려진 규칙을 가진 데이터에서는 벡터가 무엇을 잡았는지 직접 확인할 수 있으니까요. 그래서 저는 이 결과를 "작은 벡터로 끝"이 아니라 "작은 벡터부터 시작"으로 읽었습니다.

이 벡터가 규칙을 안다고 말할 수 있을까

문제를 맞혔다고 해서 규칙을 안다고 말할 수는 없습니다. 답을 우연히 맞힐 수도 있고, 예제의 빈틈을 파고들어 지름길로 갈 수도 있기 때문입니다. 그렇다면 Embed-TTT로 얻은 임베딩이 규칙 정보를 정말 담고 있는지 어떻게 확인할 수 있을까요? 논문은 두 가지 방식으로 이 물음에 답합니다. 하나는 임베딩 기반 검색이고, 다른 하나는 알려진 규칙에 대한 선형 분석입니다.

먼저 검색 이야기부터 해보겠습니다. 규칙 벡터가 제대로 만들어졌다면 비슷한 규칙의 과제는 벡터 공간에서도 가까이 있어야 합니다. 그래서 새로운 과제의 임베딩과 가까운 이웃을 찾아보면 같은 규칙을 가진 과제가 나와야 하죠. 논문에 따르면 Embed-TTT로 얻은 임베딩은 이런 검색 성능을 끌어올렸습니다. 그냥 함께 고쳤을 때보다 규칙끼리 더 잘 모였다는 뜻인데요. 저는 이 대목에서 고개를 끄덕였습니다. 답 맞히기와 규칙 모으기가 같은 방향으로 움직인다는 건 벡터가 우연이 아니라 구조를 잡고 있다는 신호이기 때문입니다.

다음은 선형 분석입니다. 알려진 규칙을 가진 통제 데이터셋에서는 각 과제의 정답 규칙이 무엇인지 미리 알 수 있습니다. 그래서 임베딩 위에 간단한 선형 분류기를 얹고 규칙을 맞혀보는데, 이 분석이 정확하게 들어맞았다고 합니다. 선형으로 읽힐 정도라면 벡터 안에 규칙 정보가 꽤 곧게 들어 있다는 뜻이죠. 물론 선형 분석이 잘 됐다고 해서 벡터가 규칙의 모든 것을 이해한다는 뜻은 아닙니다. 선형으로 읽히는 정보와 실행에 필요한 정보는 다를 수 있기 때문입니다. 하지만 적어도 "벡터에 규칙이 있다"는 주장에는 힘이 실립니다. 답만 맞힌 게 아니라, 꺼내서 읽을 수 있는 형태로 남았다는 것이죠.

보간은 되는데 외삽은 안 되는 이유가 말해주는 것

앞선 결과가 "벡터에 규칙이 담긴다"를 보여줬다면, 다음 질문은 그 규칙 공간이 얼마나 제대로 된 모양인지입니다. 논문은 파라미터로 조절되는 규칙들을 가져와서 그 기하학적 구조가 임베딩에 되살아나는지 확인합니다. 예를 들어 회전 각도나 이동 거리처럼 연속적으로 바뀌는 규칙이 있다면, 임베딩 공간에서도 그 순서와 간격이 비슷하게 나타나야 하겠죠.

결과는 반반으로 갈라졌습니다. 규칙 사이를 잇는 보간(interpolation)은 됐지만, 본 적 없는 바깥으로 나가는 외삽(extrapolation)은 안 됐기 때문입니다. 두 규칙의 중간쯤에 해당하는 새로운 규칙은 벡터 연산으로도 만들 수 있었는데, 학습 때 본 범위를 벗어난 규칙은 벡터가 제대로 가리키지 못했습니다. 이 차이는 생각보다 많은 것을 말해줍니다. 모델이 규칙 공간의 내부를 매끄럽게 채우는 법은 배웠지만, 바깥으로 뻗어나가는 법까지 배운 것은 아니라는 뜻이니까요.

개인적으로는 이 실패가 성공만큼 값지다고 느꼈습니다. 보간까지만 되고 외삽이 안 된다는 건 이 방법이 분포 안의 조합에는 강하고 분포 밖의 확장에는 여전히 약하다는 정직한 경계이기 때문입니다. 만약 외삽까지 됐다고 주장했다면 오히려 의심했을 것 같은데요. 분포 밖 규칙은 예제 몇 개로 방향을 잡기도 어렵고, 백본의 실행 능력 자체가 그 구간에서는 검증된 적이 없기 때문입니다. 그래서 저는 이 결과를 이렇게 읽었습니다. 임베딩은 본 적 있는 규칙들 사이의 지도를 그리는 데는 능숙하지만, 지도 바깥으로 나가는 모험까지는 아직 못 한다는 것이죠. 그 모험을 가능하게 하려면 무엇이 더 필요할까요? 아마도 실행 쪽의 일반화와 평가 쪽의 분리가 함께 가야 할 것 같습니다.

규칙 찾기와 규칙 실행을 같은 점수로 묶어도 될까

이제 처음에 던졌던 질문으로 돌아올 차례입니다. 규칙을 찾는 일과 찾은 규칙을 실행하는 일은 같은 능력일까요? 논문의 답은 "아니오에 가깝다"입니다. 그래서 분포 안 규칙과 분포 밖 규칙을 더 잘 가르고, 규칙 찾기와 규칙 실행을 분리해서 재는 벤치마크가 필요하다고 말합니다.

이 제안이 와닿는 이유는 점수표가 주는 착시를 걷어내기 때문입니다. 지금의 점수는 두 능력이 섞인 채로 나옵니다. 실행이 좋아져서 오른 점수인지, 처음 보는 규칙을 찾아내서 오른 점수인지가 구분되지 않죠. 그러면 연구자는 무엇을 고쳐야 할지 알기 어렵습니다. 실행이 문제인데 규칙 찾기 쪽을 붙잡고 있거나, 반대로 규칙 찾기가 문제인데 실행 모델만 키우는 일이 생깁니다. 구분이 없으면 처방도 없습니다.

그렇다면 어떻게 나눌 수 있을까요? 논문이 가리키는 방향은 통제된 규칙을 가진 데이터셋을 더 적극적으로 쓰자는 쪽입니다. 규칙을 미리 알고 있으면 벡터가 규칙을 잡았는지 따로 물을 수 있고, 실행 단계가 규칙을 제대로 옮겼는지 따로 물을 수 있기 때문입니다. 물론 통제 데이터셋만으로는 실제 ARC의 야생성을 다 담을 수 없습니다. 야생의 규칙은 파라미터 몇 개로 정리되지 않는 경우가 많으니까요. 하지만 야생 점수와 통제 분석을 함께 보면 연구의 균형이 잡힙니다. 하나는 현실감을 주고, 다른 하나는 해석을 주거든요. 저는 앞으로의 벤치마크가 이 두 다리를 함께 놓는 쪽으로 가야 한다고 봅니다.

실제 시스템에 올린다고 상상하면 생기는 질문들

좋은데, 이걸 실제로 어떻게 서빙할까요? 논문을 읽을 때마다 저는 이 질문을 습관처럼 던지는데요. 테스트 타임 학습은 말 그대로 테스트할 때 고치는 과정이라서, 서빙 관점에서는 비용과 지연이 바로 따라옵니다. 과제마다 임베딩을 먼저 고치고 백본까지 고친다면, 요청 하나당 들어가는 계산이 만만치 않기 때문입니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 과제마다 두 단계 최적화를 돌리면 배치 처리는 어떻게 할지, 메모리는 얼마나 더 들고, 동시에 들어오는 요청이 많아지면 대기열이 어떻게 밀릴지 말이죠. 작은 임베딩만 고치는 전반전은 비교적 가볍겠지만, 백본을 고치는 후반전은 무겁습니다. 모든 요청에 후반전까지 돌릴 것인지, 아니면 전반전에서 자신이 있을 때만 멈출 것인지 같은 운영 정책이 필요해집니다. 논문이 보고한 0.01퍼센트 이야기는 여기서 다시 빛납니다. 전반전만으로 풀리는 과제라면 후반전을 생략할 수 있으니, 평균 비용을 낮출 여지가 생기거든요.

또 하나는 안정성의 문제입니다. 테스트 타임에 모델을 고치면 같은 입력에도 결과가 달라질 수 있고, 고치는 과정이 예제의 순서나 품질에 흔들릴 수 있습니다. 예제가 두 개뿐인데 그중 하나가 애매하다면 벡터가 어디로 튈까요? 운영의 아침을 생각하면 이 질문은 꽤 현실적입니다. 밤사이 들어온 변칙 입력 때문에 벡터가 엉뚱한 곳으로 가면, 아침에 들어오는 정상 요청까지 영향을 받을 수 있기 때문입니다. 그래서 저는 테스트 타임 학습을 볼 때 점수만큼이나 실패 모드가 궁금합니다. 벡터가 틀렸을 때 모델이 이를 알아채고 멈출 수 있는지, 아니면 틀린 방향으로 끝까지 밀고 나가는지 말이죠.

제가 다음 연구에서 보고 싶은 장면

제가 앞으로 보고 싶은 것은 벡터가 틀렸을 때의 얼굴입니다. 지금까지는 벡터가 규칙을 잘 잡았을 때의 이야기가 중심이었는데요. 벡터가 엉뚱한 규칙을 가리켰을 때 백본이 어떻게 반응하는지가 더 궁금합니다. 백본이 "이 방향은 이상하다"고 멈칫하는지, 아니면 시키는 대로 엉뚱한 답을 그려내는지가 다음 설계의 갈림길이기 때문입니다.

또 하나 보고 싶은 것은 보간과 외삽 사이의 다리입니다. 지금은 본 적 있는 규칙들 사이에서는 매끄럽지만 바깥으로는 못 나간다고 했죠. 그렇다면 바깥으로 한 걸음씩 나가면서 벡터가 언제부터 흔들리는지, 그리고 그 흔들림을 미리 감지할 신호가 벡터 안에 있는지가 궁금합니다. 불확실성을 함께 내놓는 벡터라면 운영에서도 훨씬 다루기 쉬울 것 같습니다. 자신이 없을 때는 후반전 최적화를 더 돌리거나, 아예 사람에게 물어보는 선택지를 만들 수 있으니까요.

마지막으로 벤치마크 이야기로 글을 닫겠습니다. 규칙 찾기와 규칙 실행을 나누고, 분포 안과 분포 밖을 가르는 평가는 결국 "무엇을 모르는지 아는 모델"을 향합니다. 점수가 높은 모델을 넘어, 자기가 모르는 규칙 앞에서는 모른다고 말할 줄 아는 모델 말이죠. 그렇다면 사람의 역할은 무엇일까요. 아마도 어떤 결과를 좋은 결과로 정의할지, 그리고 모델이 모른다고 말했을 때 그 다음을 어떻게 이어줄지를 정하는 일이 아닐까 싶습니다. 이 논문은 그 질문에 직접 답하지 않지만, 질문을 물을 수 있는 도구를 하나 건넵니다. 규칙을 담는 작은 벡터라는, 꺼내서 읽을 수 있는 도구 말이죠.