왜 다시 트랜스포머 모델인가?

트랜스포머 모델, 실제로 연구는 구글에서 했지만 OpenAI에서 상용화하여 세상을 떠들석하게 만든 논문 하나가 있다. “Attention is all you need”.

트랜스포머라고 불리는 새로운 AI 모델을 제안하여 유명해진 모델로 현재 우리가 쓰고 있는 주요 AI 서비스의 근간이 되는 모델을 제안한 논문이다.

AI가 챗봇 형태의 서비스를 넘어 에이전트로 바뀌고 있는 요즘 트랜스포머 모델이 어떻게 동작하는지 되짚어 보는 일은 왜 이런 일을 해야 하는지 스스로 생각해 볼 수 있는 기회를 제공한다.

최근 다시 한 번 트랜스포머 모델에 대해 정리를 하려 생각하던 중 Deeplearning 사이트에 “Transformer in action”이라는 좋은 강의가 나왔다. 아래의 내용은 해당 강의에서 중요한 부분이라 생각하는 부분을 정리한 글이다.

여전히 문제는 콘텍스트, 맥락이다

초창기에는 AI를 효과적으로 사용하기 위해 프롬프트라는 글을 작성하는 것이 중요했고 이 일은 점차 콘텍스트 엔지니어링이라는 개념이 등장했다.

최근에는 LLM을 코딩 에이전트로 도입하면서 좀 더 효과적으로 AI를 소프트웨어 생산에 적용하기 위하여 “하네스 엔지니어링”이라는 개념이 널리 퍼지고 있다.

이러한 모든 변화는 어떻게 하면 LLM의 콘텍스트를 효과적으로 관리하는 방법론이라 생각된다.

그렇다면 LLM에서 콘텍스트가 의미하는 것은 무엇이며, 최근 LLM 서비스의 근간을 이루고 있는 트랜스포머 모델에서 어떻게 콘텍스트가 다루어지는지 살펴보는 것은 AI 사용을 효과적으로 설계하기 위하여 중요한 일일것이다.

현재 널리 쓰이는 생성형 모델들은 디코더 전용 (Decoder-only) 구조

원래 논문에서는 인코더-디코더 (Encoder-Decoder) 구조를 다루고 있다. 그러나 오늘날 널리 쓰이는 생성형 모델들은 디코더 전용(Decoder-only) 구조를 사용한다고 알려져 있다.

직관적으로 보기에는 우리가 프롬프트를 입력하고 LLM이 답하는 구조이기 때문에 인코더-디코더 구조가 아닐까 했는데 클로드가 자세히 설명해 주었다.

실제로 우리가 입력하는 프롬프트외에 클로드나 ChatGPT와 같은 프로그램에서 추가하는 시스템 프롬프트가 추가된다.

아울러 추론과정에서 시스템에서 CoT를 통하여 추론과정에서 생성된 프롬프트도 추가 된다. 따라서 LLM은 이런 다양한 토큰들의 모임을 한번에 처리하는 것이 유리하다.

아울러 클로드의 설명에 따르면 Decoder – Only 모델이 스케일링에 효율적이라고 한다. 즉 매개변수를 늘리고 GPU computing 양을 늘려 성능을 향상하기 손쉽다는 주장이다.

자기회귀 루프 (Autoregressive Loop)

자기(Auto)는 스스로를 말하는 이공계 용어이다. 이공계에서는 존재하지 않는 개념을 나, 상대방 (Neighbor) 이렇게 부르기도 한다.
회귀 (regressive)는 출력을 다시 입력으로 사용한다는 뜻으로 이해하자. 마치 소가 되새김질을 하듯이.

LLM이 실제로 문장을 만들어내는 (코드를 만들어 내는) 핵심 메커니즘이 바로 이 자기회귀 루프라고 한다. LLM에 프롬프트를 입력하면 한 번에 딱 하나의 토큰씩, 이전에 생성된 토큰에 의존하여 다음 토큰을 예측하는 자기회귀 생성(Autoregressive Generation) 과정을 쉼 없이 반복한다.

토큰 조립과 콘텍스트 윈도우

루프의 시작은 입력 텍스트를 토큰으로 분리하는 것이다.

시스템이 사용자가 입력한 프롬프트 토큰만 처리하는 게 아니라는 사실이다. 앞서 언급했듯이 “당신은 도움이 되는 어시스턴트입니다”와 같은 지시사항이 담긴 템플릿 토큰(Template Token), 혹은 추론 과정에서 생성된 CoT 토큰등이 모두 한데 뭉쳐진다.

이 모든 토큰의 총합이 바로 콘텍스트 윈도우(Context Window)를 구성하게 된다.

LLM은 오직 현재 활성화된 콘텍스트 윈도우 내부만 바라보며 바로 다음에 올 단 하나의 토큰을 예측한다. 콘텍스트 관리가 중요하다는 이유도 결국 모델이 한 번에 볼 수 있는 최대 텍스트 양이 이 윈도우 크기이기 때문디다.

확률 분포와 다음 토큰의 선택

콘텍스트 윈도우 안의 토큰들을 입력받은 모델은 자신이 아는 모든 어휘(Vocabulary)를 대상으로 ‘다음에 어떤 토큰이 오는 것이 가장 자연스러운지’ 확률을 계산한다.

모델이 가진 토큰 수, 즉 어휘수가 22000자라 해보자. 하나의 다음 토큰을 결정하기 위해서는 이 모든 22000개의 단어가 다음 토큰이 될 확률을 계산하는 일이다. 그렇게 다음 토큰을 결정하고는 변화된 콘텍스트에 대해서 (토큰이 하나가 추가 되었으니까) 다시 22000개의 단어에 대해서 그 다음번 단어가 될 확률을 계산한다.

GPU가 녹아내린다라는 샘 올트만의 말에 공감이 가는 부분이다.

언제까지 이런 뱅뱅이를 돌리나

이 도돌이표 같은 루프는 다음 세 가지 조건 중 하나를 충족할 때 비로소 멈춘다고 한다.

• 스톱 토큰 (Stop Token): 모델이 훈련 과정에서 문장을 끝내야 할 때 내뱉도록 학습한 특수한 종료 토큰을 만났을 때
• 최대 토큰 제한: 사용자가 시스템 설정을 통해 지정해 둔 출력 토큰의 상한선에 도달했을 때
• 콘텍스트 윈도우 한계: 콘텍스트 윈도우의 용량이 완전히 가득 차서 더 이상 채울 공간이 없을 때

마치며

결국 우리가 마주하는 LLM의 모든 풍부한 응답은 입력 분리, 콘텍스트 취합, 확률 계산, 토큰 추가라는 이 짧은 루프가 멈춤 조건을 만날 때까지 수없이 회전한 결과물인 셈이다.

왜 LLM이 내가 원하는 소프트웨어를 만들어 내지 못하는지 기계를 탓하기 전에 이 확률 계산기가 옳게 확률을 계산할 수 있는 정보를 내가 입력했는지 자문해 볼 일이다.

내가 결정하지 못해서 우선 순위를 정하지 않았는데 기계가 이랬다 저랬다 한다라고 불평하기 전 내가 기계에 바라는 역할을 제대로 써 넣었는지도 생각해 보아야 한다.

다음 포스팅에서는 이 수많은 어휘의 확률 분포 속에서, 모델은 실제로 어떻게 가장 적절한 하나의 토큰을 선택하는지 대표적인 전략들에 대해 소개할 예정이다.