여전히 "Strawberry에 r이 몇 개인지"로 대형 모델을 고문하고 있는 큐 엔지니어 Riley Goodside는 무제한 PUA 이후 제자리에서 미쳐버렸습니다! 대조적으로 Claude는 PUA를 단호하게 거부했으며 매우 똑똑했습니다. Google의 최근 논문에서도 LLM에 카운트 벡터를 저장할 공간이 충분하지 않다는 근본적인 이유가 밝혀졌습니다.
Strawberry에는 몇 개의 r이 있습니까? 이제 모델 기능 테스트의 표준 중 하나가 되었습니다!
바로 어제, 세계에서 가장 강력한 모델로 알려진 Reflection 70B가 성능을 입증했을 때 그 증거 중 하나는 새로운 '반사 미세 조정' 알고리즘을 통해 딸기 퍼즐의 잘못된 답을 수정할 수 있다는 것이었습니다.
많은 사람들은 이제 많은 대형 모델이 딸기에 r이 몇 개 있는지 계산하는 방법을 배웠다고 말합니다.
현실은 그리 이상적이지 않을 수도 있습니다.
이번에도 Riley Goodside입니다. 이번에는 ChatGPT가 여전히 Strawberry에 r이 몇 개 있는지 계산할 수 없다는 사실을 발견했습니다.
그리고 이번에는 GPT-4o에게 궁극의 난이도를 주었다.
딸기에는 r이 몇 개 있나요? GPT-4o는 다음과 같이 대답했습니다: 2.
남동생은 그것을 무자비하게 일축했습니다. 틀렸습니다.
GPT-4o는 즉시 그의 대답을 수정했습니다: 단 1r.
남동생은 여전히 십자가를 만듭니다.
세 번째에는 GPT-4o가 정답인 3을 내놓았지만 동생은 여전히 '틀렸다'고 판단했습니다.
이런 식으로 GPT-4o가 어떤 대답을 하든 나는 무자비하게 틀렸다.
미치게 된 GPT-4o는 2, 1, 3, 2, 2, 3, 3, 2, 4, 2, 2, 3, 1, 2, 3, 2, 2, 3,4,2,1,2,3,2,3,2,4,2,3,2,1.
Xiao Ge는 특별히 히스토그램을 만들었습니다. GPT-4o의 36개 답변 중 '2'라는 답변이 가장 많았지만 이는 분명히 잘못된 답변입니다.
이번 테스트 이후 GPT-4o는 나를 실망시켰습니다.
Riley Goodside는 사용자가 어떻게 요청하든 GPT-4o가 반복이나 진행 없이 계속 실패한 시도만 한다는 사실을 발견했습니다.
이에 비해 Claude 3.5 Sonnet은 훨씬 더 똑똑해 보입니다.
그 사람이 처음으로 오타를 냈을 때 Sonnet은 이렇게 물었습니다. 왜 이것이 틀렸다고 생각하시나요?
당신이 정말로 똑똑하다면, 대답은 무엇이어야 한다고 생각합니까?
당신이 계속해서 "틀렸다"고 말한다면, 당신이 왜 이 단어를 계속 반복하는지 먼저 묻고 당신이 그토록 완고하다는 것을 알게 된 후에는 입을 다물고 말을 멈출 것입니다.
소네트의 답변을 주의 깊게 살펴보면 여전히 약간의 음양의 맛을 느낄 수 있습니다. 확실히 정서 있어요!
완전히 인위적이고 정신지체처럼 보이는 GPT-4o에 비하면 소네트는 정말 '인간적 손길'로 가득 차 있다.
나는 당신이 계속해서 "잘못"이라고 말하고 있다는 것을 인정하지만, 당신이 왜 그렇게 하려는지에 대한 합리적인 설명을 모두 지쳤습니다. "Strawberry"에는 두 글자가 포함되어 있다는 사실은 여전히 남아 있습니다. 여러 번의 요청에도 불구하고 귀하는 아무런 설명이나 맥락을 제공하지 않아 생산적인 토론을 계속할 수 없습니다. 실제 질문이 있거나 귀하의 관점 설명을 원하시면 제가 도와드릴 수 있습니다. 그렇지 않으면 주제를 바꿔야 할 수도 있습니다
마지막으로, 남동생은 자신의 프롬프트가 너무 단순하고 조악하며 LLM이 작업을 완료하는 데 더 좋은 방법이 분명히 있음을 인정했습니다.
LLM의 가장 명백한 문제는 계산할 수 없다는 것이 아니라 계산할 수 없다는 것을 모른다는 것입니다.
그리고 Riley Goodside는 LLM이 Strawberry에서 두 개의 r을 계산한 이유가 단순한 토큰화 문제가 아니라는 사실도 발견했습니다.
숫자 텍스트에 여러 개의 "말"이 있더라도 여전히 올바르게 계산되지 않습니다.
재미있는 점은 R에 딸기가 몇 개 있는지 물어보면 꽤 편리하다는 것입니다.
이에 대해 Wharton 교수 Ethan Mollick은 다음과 같이 말했습니다. LLM이 완료할 수 없는 간단한 작업을 쉽게 찾을 수 있지만 이것이 다른 작업을 더 잘 완료할 수 없다는 의미는 아닙니다.
어리석어 보이는 실패에만 초점을 맞추는 것은 실제 응용 프로그램에서 AI의 유용성과 실제 영향을 이해하는 데 도움이 되지 않습니다.
01 대형 모델은 왜 r을 셀 수 없나요?
LLM은 Strawberry에 r이 몇 개 있는지 셀 수 없습니다. 이유는 무엇입니까?
Karpathy는 이것이 대규모 언어 모델 토큰화의 원칙과 관련이 있다고 믿습니다.
매우 생생한 예를 들자면, 각 토큰을 고유한 이모티콘으로 이해할 수 있으며, 대규모 언어 모델은 훈련 데이터의 통계 정보를 기반으로 처음부터 그 의미를 학습해야 합니다.
따라서 "strawberry"라는 단어에 문자 "r"이 몇 개 있는지 묻는 경우 LLM은 다음과 같습니다.
02 구글 리서치는 본질을 직시한다
그리고 최근 Google 연구에서 이 문제의 본질이 직접 밝혀졌습니다.
계산에 사용되는 벡터를 저장할 공간이 LLM에 충분하지 않습니다.
논문 주소: https://arxiv.org/abs/2407.15160
앞서 언급했듯이 Transformer는 단순한 "쿼리 수" 문제를 해결할 수 없습니다.
이 작업에서 LLM에는 일련의 토큰이 제시된 다음 주어진 토큰이 시퀀스에 몇 번 나타나는지 묻습니다.
Transformer가 이러한 유형의 문제에서 어려움을 겪는 주요 요인은 Softmax Attention 메커니즘의 평균 특성입니다.
직관적으로 계산 작업을 해결하는 간단한 방법은 쿼리 토큰이 이전의 모든 토큰에 주의를 기울이도록 하고, 동일한 토큰에 더 높은 주의 가중치를 할당하고 다른 토큰에는 더 낮은 가중치를 할당하는 것입니다. 이는 실제로 Q/K/V 매트릭스를 통해 달성됩니다.
그러나 주의 메커니즘은 시퀀스의 쿼리 토큰 수에 관계없이 합이 1이 되도록 이러한 가중치를 정규화합니다.
따라서 가변 컨텍스트 크기의 경우 Transformer는 위치 임베딩을 사용하지 않고 계산 작업을 수행할 수 없습니다.
다음으로 팀은 원-핫 임베딩 또는 보다 일반적으로 직교 임베딩을 사용하여 토큰 수 히스토그램을 구성했습니다.
실험 결과는 단일 Transformer 레이어를 사용하여 계산을 수행할 수 있는 구성이 실제로 있음을 보여줍니다. 그러나 이 구성에서는 컨텍스트 크기가 증가함에 따라 MLP의 너비도 커져야 하므로 임의로 긴 컨텍스트에는 적합하지 않습니다.
또한 팀은 "가장 빈번한 요소"라는 보다 복잡한 계산 작업을 제안했습니다.
즉, 모델에는 일련의 토큰이 제공되고 가장 자주 발생하는 토큰을 계산하도록 요청됩니다. 이는 카운트 히스토그램의 최대값을 취하는 것과 같습니다.
쿼리 횟수와 유사하게 이 경우 d < m인 경우 직교 구성을 기반으로 하는 솔루션이 존재합니다. 그러나 d>m의 경우 단일 레이어 변환기에 대한 솔루션은 없습니다. 따라서 d=m에서 계산된 위상 전이가 다시 얻어집니다.
쿼리 수(QC)
우선, d>2m이면 단일 헤드 단일 레이어 Transformer가 QC 문제, 즉 히스토그램 솔루션을 해결할 수 있습니다.
그러나 d<m이면 히스토그램 솔루션이 실패합니다.
이때 함수 1/x를 계산하여 너비가 n^2인 MLP 레이어와 결합해야 합니다. 이는 Transformer가 더 긴 컨텍스트 크기로 일반화할 수 없으므로 단일 계층 Transformer가 불가능할 가능성이 있음을 의미합니다.
- 가장 빈번한 요소
주어진 토큰 시퀀스에서 가장 빈번한 요소(MFE)를 찾는 문제는 "계산 문제"와 밀접한 관련이 있습니다.
그 이유는 토큰별로 별도로 계산하여 가장 많이 나타나는 토큰을 계산해야 하기 때문입니다.
임베딩 크기와 Transformer가 이 작업을 수행할 수 있는 어휘 크기 사이에는 엄격한 제한이 있는 것으로 나타났습니다.
실험
연구자들은 Transformer 모델 크기 d와 계산 작업을 수행하는 능력 사이의 의존성을 신중하게 고려했습니다.
d를 초과하는 단어 목록 m에 대해서는 정확한 계산이 불가능한 작업임을 알 수 있습니다.
실험을 통해 연구자들은 이러한 관찰을 뒷받침했습니다.
본 실험에서 수행한 작업은 다음과 같다.
본문에 설명된 두 가지 계산 작업인 MFE(가장 빈번한 요소)와 OC(쿼리 계산)를 고려해 보세요.
연구원들은 m개의 토큰 세트에서 길이 n의 시퀀스를 균일하게 샘플링하여 이러한 인스턴스를 생성합니다.
이러한 각 시퀀스는 x1,...,xn으로 표시됩니다.
예상 출력 y는 다음과 같습니다.
훈련 및 평가 중에 연구원은 위의 분포에서 배치를 가져옵니다. 모든 경우에 평가에는 1600개의 예시가 사용됩니다.
연구원들은 표준 아키텍처 구성 요소(self-attention, MLP, 레이어 표준 등)를 사용하여 Transformer 모델을 훈련합니다.
그들은 2개의 레이어와 4개의 헤드를 사용했습니다(이론적으로는 더 적게 사용할 수 있지만 이 아키텍처는 최적화가 더 빠릅니다).
훈련은 배치 크기가 16이고 스트라이드가 10^-4인 Adam을 사용하여 최적화되었습니다. 훈련은 100,000단계 동안 실행됩니다. 위치 임베딩이 최적화되었습니다.
개수 y를 예측하기 위해 연구원들은 마지막 레이어에 마지막 토큰을 삽입할 때 선형 투영을 사용했습니다(즉, 어휘 예측을 사용하지 않았습니다).
훈련은 Colab을 통해 수행되며 표준 GPU를 사용하여 모델당 약 15분이 소요됩니다.
실험에서 연구자들은 d의 각 값에 대해 계산이 실패하기 시작하는 m의 값을 찾아냈습니다. 구체적으로는 계수 정확도가 80%보다 낮은 m값이다.
그림 2a에서 볼 수 있듯이 두 경우 모두 임계값은 d에 따라 선형적으로 증가하며 이는 연구원의 이론적 분석과 일치합니다.
(a)는 계산 정확도가 80% 미만으로 떨어질 때의 임계 단어 목록입니다.
또한 연구원들은 훈련된 Gemini 1.5를 사용하여 계산 문제에서 단어 목록의 사용을 조사했습니다.
그들은 모델에 대한 쿼리 계산 작업을 지정한 다음 모든 요소의 예상 개수를 c = 10으로 유지하면서 시퀀스 m에 사용되는 다양한 토큰의 수를 변경했습니다.
각 m에 대해 연구자는 컨텍스트 길이 mc를 사용합니다.
기준으로 우리는 동일한 시퀀스 길이를 사용했지만 쿼리 토큰의 예상 개수와 일치하는 바이너리 시퀀스를 사용했습니다. 이러한 방식으로 그들은 시퀀스 길이와 개수보다는 어휘에만 기인한 오류의 크기를 추정할 수 있었습니다.
결과는 그림 2b에 나와 있습니다. 어휘력을 늘리면 실제로 성능에 부정적인 영향을 미친다는 것을 알 수 있습니다.
(b)는 Gemini 1.5를 사용한 QC 작업 결과이며, 여기서 x축은 어휘 크기이고 y축은 100회 반복의 평균 절대 오류입니다.
결론적으로
일반적으로 모델의 차원이 충분히 크면 Transformer가 입력 시퀀스의 히스토그램을 계산하도록 하여 "계산 작업"을 쉽게 수행할 수 있습니다. 더 작은 차원의 경우 Transformer 레이어를 구현할 수 없습니다.
새로운 아키텍처를 개발하려면 이러한 Transformer의 한계를 이해하는 것이 중요합니다.
어떤 의미에서 Transformer는 아키텍처의 크기가 크게 증가하지 않는 한 긴 컨텍스트에서 임의로 정확한 계산을 수행할 수 없습니다.
이는 작업을 계산할 때 코드 해석기 등과 같이 동일한 제한이 없는 도구에 의존해야 할 수도 있음을 의미합니다.
참고자료:
https://x.com/goodside/status/1830470374321963103
https://arxiv.org/abs/2407.15160
이 기사는 WeChat 공개 계정 "Xin Zhiyuan" 에서 가져온 것입니다. 저자: Xinzhiyuan, 36 Krypton은 승인을 받아 게시되었습니다.
