서로 다른 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
관련 논문
Mindwalk – 코딩 에이전트 세션을 코드베이스 3D 맵 위에서 재생하는 시각화 도구
Claude Code나 Codex 같은 AI 코딩 에이전트가 세션 중 코드베이스의 어떤 파일을 탐색하고 수정했는지를 3D 지도 형태로 시각화해서 재생해주는 로컬 도구다. 에이전트가 작업을 어떻게 이해했는지 한눈에 파악할 수 있다.
Ghost Font: 사람은 읽을 수 있지만 AI는 읽기 어려운 안티-AI 폰트 실험
움직임(모션)을 이용해 글자를 표현해서 AI 모델이 정적 이미지 분석으로는 메시지를 해독하지 못하게 막는 실험적 프로젝트인데, 커뮤니티에서는 이미 GPT-5.6, Claude Opus 등으로 해독에 성공한 사례가 속출해 실효성 논쟁이 뜨겁다.
GPT-5.6, Grok 4.5, Claude, Muse Spark 등 12개 모델이 동일한 앱 4개를 빌드한 결과 비교
12개 LLM 모델에게 레이캐스터 미로, 루빅스 큐브, 계산기, Game of Life 앱을 각각 5번씩 만들게 해서 성공률·비용·속도를 비교한 실전 벤치마크다. GPT-5.6 Sol이 전반적으로 가장 일관된 결과를 냈고, Grok 4.5는 가성비 면에서 눈에 띄었다.
Databricks가 수백만 라인 실제 코드베이스로 Coding Agent를 벤치마킹한 결과
Databricks가 자사 실제 코드베이스를 기반으로 여러 AI 코딩 에이전트의 성능과 비용을 직접 측정했고, 모델 토큰 가격과 실제 태스크 비용이 전혀 다르다는 점, 그리고 오픈소스 모델이 이제 최상위 수준에 도달했다는 점을 확인했다.
Reasoning에서 Uncertainty 추정하기: LLM의 다국어 및 교차언어 MCQA 성능 대규모 연구
LLM이 저자원 언어 질문을 받을 때 영어로 추론하게 하면 불확실성 추정 성능이 고자원 언어 수준으로 올라온다.
LLM-as-a-Verifier: 범용 Verification 프레임워크
LLM의 토큰 확률 분포를 활용해 discrete 점수 대신 continuous 점수를 뽑아내면, 추가 학습 없이 코딩·로봇·의료 에이전트 평가 정확도를 SOTA로 끌어올릴 수 있다.