서로 다른 Language Model들이 비슷한 숫자 표현 방식을 학습한다
Different Language Models Learn Similar Number Representations
TL;DR Highlight
Transformer, LSTM, Linear RNN 등 구조가 전혀 다른 언어 모델들이 숫자를 표현할 때 공통적으로 주기 T=2, 5, 10의 주기적 패턴을 학습한다는 연구 결과로, 모델 아키텍처를 넘어선 '수렴 진화' 현상을 수학적으로 설명한다.
Who Should Read
LLM 내부 표현(representation)이 어떻게 형성되는지 궁금한 ML 연구자나, 수치 연산 능력을 모델에 더 잘 내재화하고 싶은 AI 시스템 개발자.
Core Mechanics
- 자연어 텍스트로 학습된 언어 모델들은 숫자를 내부적으로 표현할 때 주기 T=2, 5, 10이 지배적인 주기적(periodic) 특징을 공통적으로 학습한다. 이는 10진수 체계와 짝수/홀수 구분에 자연스럽게 대응한다.
- 연구팀은 이 주기적 특징에 '2단계 계층 구조'가 있음을 발견했다. 첫 번째 단계는 Fourier 도메인에서 특정 주파수에 스파이크가 생기는 것이고, 두 번째 단계는 그 표현이 'mod-T 기하학적 분리 가능성(geometrically separable)'을 갖추는 것인데, 이 두 번째 특성은 모든 모델이 갖추는 건 아니다.
- Fourier 도메인의 희소성(sparsity)은 mod-T 기하학적 분리 가능성의 필요 조건이지만 충분 조건은 아님을 수학적으로 증명했다. 즉, 주기 패턴이 있다고 해서 자동으로 숫자를 선형 분류할 수 있는 표현이 만들어지지는 않는다.
- 기하학적으로 분리 가능한 표현이 만들어지는 경로는 두 가지다. 하나는 일반 언어 데이터에 포함된 '텍스트-숫자 공출현(co-occurrence)' 및 '숫자 간 상호작용' 신호를 통한 학습이고, 다른 하나는 '멀티 토큰 덧셈 문제'(single-token이 아닌)를 학습할 때다.
- Transformer, Linear RNN, LSTM, 고전적인 word embedding 등 구조적으로 완전히 다른 모델들이 모두 비슷한 숫자 표현을 학습한다. 이 현상을 연구팀은 생물학의 '수렴 진화(convergent evolution)'에 빗대어 설명한다.
- 숫자 표현의 품질(기하학적 분리 가능성 여부)은 학습 데이터, 아키텍처, 옵티마이저, 토크나이저 모두에 영향을 받는다. 어느 하나만으로 결정되지 않는다.
- 이 연구는 LLM에 수학 연산 회로를 외부에서 연결하려는 시도(neurosymbolic 접근)에도 시사점을 준다. 서로 다른 모델들이 호환 가능한 숫자 표현을 공유한다면, 그 '공통 표현'을 연결 지점으로 활용할 수 있는 가능성이 열린다.
Evidence
- HN에서 이 결과가 '플라톤적 표현 가설(Platonic Representation Hypothesis, 서로 다른 모델이 같은 훈련 데이터를 학습하면 공통된 현실 표현에 수렴한다는 가설)'을 지지하는 증거라는 의견이 나왔다. 한 댓글은 '공유 표현 덕분에 모델 간 수학 연산 회로를 연결하는 것이 더 쉬워질 수 있다'고 언급했다.
- '플라톤적 표현 가설'에 대한 비판적 댓글도 있었다. '현실을 학습한다'는 표현이 과장이며, 모델은 데이터셋의 통계적 규칙성을 학습할 뿐이라는 반론이다. 이 가설이 'LLM이 객관적 현실에 수렴하므로 인간보다 객관적이다'는 식의 주장을 정당화하는 데 오용된다는 우려도 제기됐다.
- 숫자 표현의 고유값 분포가 벤포드 법칙(Benford's Law, 자연 발생 숫자에서 앞자리 숫자의 분포 패턴)과 유사하게 보인다는 관찰이 있었고, 인간이 큐레이션한 텍스트 코퍼스라면 이런 패턴이 나타나는 것이 당연하지 않냐는 질문도 나왔다.
- 이 현상이 훈련 데이터 때문인지, 모델 아키텍처 때문인지 궁금하다는 댓글이 있었다. 논문에서 데이터·아키텍처·옵티마이저·토크나이저 모두 영향을 준다고 밝히고 있지만, 상대적 기여도에 대한 궁금증이 남는다는 반응이었다.
- 서로 다른 모델이 비슷한 표현을 공유한다는 발견을 실용적으로 활용하려는 시도도 소개됐다. 'turnstyle'이라는 라이브러리가 모델 간 공유 표현을 활용한 neurosymbolic 프로그래밍을 구현 중이라는 자기 홍보성 댓글이 달렸다.
How to Apply
- LLM에 수치 연산 정확도를 높이고 싶다면, 단일 토큰 덧셈 문제보다 멀티 토큰 덧셈 문제로 파인튜닝하는 것이 mod-T 기하학적 분리 가능한 숫자 표현을 만드는 데 효과적일 수 있다.
- 모델 아키텍처를 넘어서 숫자 표현을 공유하거나 전이하려는 시스템(예: 서로 다른 모델 간 수학 연산 모듈 공유)을 설계할 때, T=2·5·10 주기 기반의 Fourier 표현이 공통 인터페이스로 작동할 수 있는지 검토해볼 수 있다.
- 토크나이저 설계가 숫자 표현 품질에 영향을 준다는 사실을 고려해, 수치 데이터를 많이 다루는 도메인 특화 모델을 학습할 때는 숫자를 어떻게 토큰화할지(digit-level vs. 숫자 단위)를 실험해보는 것이 좋다.
- 모델 내부 표현을 해석하거나 probing(표현 내에 특정 정보가 있는지 선형 분류기로 확인하는 기법)할 때, 숫자에 대해 mod-2, mod-5, mod-10 기준으로 선형 분류 가능성을 테스트하면 해당 모델의 수치 표현 품질을 간단히 평가할 수 있다.
Terminology
관련 논문
Claude가 rsync의 버그를 증가시켰는가? 데이터 분석
rsync 프로젝트에 Claude AI가 도입된 이후 버그가 늘었다는 소셜 미디어 주장을 실제 데이터와 통계 분석으로 검증한 글로, 결론적으로 Claude 도입 후 릴리즈가 역사적 분포에서 유독 버그가 많다는 통계적 근거는 없었다.
취약한 앱을 직접 만들고 LLM이 해킹할 수 있는지 $1,500 써서 실험해봤다
Firebase 취약점을 가진 앱을 직접 제작하고 GPT-5.5, Claude, Deepseek 등 주요 LLM이 자율적으로 해킹할 수 있는지 실험한 결과, GPT-5.5가 70% 성공률로 압도적이었고 Claude는 보안 거부 정책 때문에 능력과 무관하게 낮은 점수를 기록했다.
Clustered Self-Assessment: LLM 불확실성 정량화를 위한 간단하고 효과적인 방법
LLM이 여러 답변을 의미 단위로 묶어 객관식으로 만들고 스스로 채점해서 '이 답 얼마나 확신해?'를 수치로 뽑아내는 기법.
SkillHarm: 자동 생성 기반의 Skill-Use Lifecycle 전반을 다루는 Agent Skill 공격 벤치마크
AI 에이전트가 사용하는 'Skill 패키지'에 악성 페이로드를 심으면 최신 모델도 86%까지 뚫린다는 보안 벤치마크.
MemTrace: LLM Memory System의 오류를 추적하고 원인을 찾아내는 프레임워크
RAG, Mem0 같은 LLM 메모리 시스템이 왜 틀린 답을 내는지 자동으로 찾아주는 디버깅 프레임워크
DeepSWE: 오염 없는 장기 코딩 에이전트 벤치마크
기존 SWE-bench의 데이터 오염 및 검증 오류 문제를 해결하기 위해 처음부터 새로 만든 코딩 에이전트 벤치마크로, GPT-5.5가 70%로 1위를 차지하고 모델 간 성능 격차가 훨씬 뚜렷하게 드러난다.
Constraint Decay: LLM 에이전트가 백엔드 코드 생성에서 구조적 제약을 못 따라가는 이유