LLM, 기억에 대한 고민

해보기 전과 해본 후, 내가 LLM에 대해 가지고 있던 2가지 착각이 있었다. 하나는 LLM크기에 대한 것. 나는 작은 모델이 여러번 추론하는 게 큰 모델 하나보다 났다고 생각했지만, 지난 소설가가 되자 실험을 통해볼 때 작은 모델에는 확실히 한계가 있는 부분이 있었다. 그리고 또 하나는 컨텍스트.

작은 모델의 어려번 추론이 큰 모델의 고차원적인 추론을 따라잡을 수 있었다면 컨텍스트의 제한은 문제가 되지 않는다. 왜냐면, 컨텍스트를 나눠서 여러 번 처리하면 되기 때문이다. 하지만 아니었다. 이 사실은 내가 서비스를 설계하는 데 상당히 많은 고민을 하게 만들었다.

여전히 답은 없다. 계속 해볼 뿐이다. 어찌보면 좋은 점도 있다. 모델을 직접 튜닝하는 것 말고도 아직 할 일이 많다.

일반적으로 컨텍스트 길이는 예전에는 8k였다. 한국어의 경우 한 글자가 거의 한 토큰이 된다. 대충 입출력 합쳐 8천 자 정도라고 보면 된다. 보통 반반 나눠서 하므로 입력칸은 4천자다.

이후 컨텍스트 길이가 폭발적으로 늘면서 128k 까지 가자 난 위와 같은 생각으로 '더 늘릴 필요 있나?'라고 생각했다. 그리고 지금 GPT-5는 400k까지 갔다. 출력은 128k라는거 보니 입력이 더 길다. 근데.

사실 이거도 대단히 빠듯할 수 있다. 그리고.

난 근본적으로 컨텍스트에 모든 지식을 때려박는 게 맞는지도 의문이 들고 있다.


일반적으로 입력에 들어가는 1차적인 내용은 사용자 질의다. 이건 길어야 100자나 될까. 하지만 그걸로 안심할 수는 없다.

일반젓인 챗봇은 사용자의 다양한 입력에 대해 적절히 답할 수 있게 시스템 프롬프트를 튜닝해 놓는다. 이건 짧아도 100자, 길면 수천 자도 될 수 있다. 여기에는 챗봇이 어떤 입장에서 답변할지 (페르소나), 어떤 형식으로 답변할지, 답변에 들어가야 할 내용과 들어가면 안될 내용 (규제), 추론 과정을 유도하는 명령 (CoT) 등등이 들어간다. 일반적인 상용 챗봇 서비스들도 수천 자 수준의 시스템 프롬프트가 들어가는 것으로 알고 있다.

그리고 기본적으로 챗봇은 RAG기반으로 돌아간다. 학습에 사용한 데이터는 아웃데이트 될 수 있고, 학습 과정에서의 교란으로 잘못된 사실이 출력될 수 있기 때문이다. 따라서 참조자료를 넣어 그것을 바탕으로 답변하게 하며 참조자료에 없는건 답변을 회피하게 한다. 언제나 완벽한 참조자료를 뽑아낼 수 있는 게 아니므로 자료를 여러 건 넣어야한다. 대략 건당 500-1000자 정도 들어가고 5개 정도는 넣는다. 그걸로 최대 5000자.

대화는 한번에 끝나지 않는 법이다. 대화는 주고받는 거니까. 한 번 물어본 내용을 LLM은 기억하지 않는다. 따로 저장해 두었다가 다시 저 컨텍스트에 넣어줘야 한다. 보통 3턴 잡으면 대화가 자연스럽게 이어진다고 한다. 질문, 답변이 각각 1000자라고 하면, 2턴 전 질답을 넣을 때 질문, 답변 2개씩 해서 4000자.

그리고 저 기준에 따라 지금 하는 질문이 1000자.

엑사원이 32k의 토큰 길이를 지원하고 따라서 입력은 16k다. 위에 말한 저걸 모두 넣으면 사실상 그거만으로 거의 꽉 찬다. 저 정도 사이즈면 매우 최소한의 챗봇을 구성하고 마는 수준의 성능이다. 그런데 멀티턴을 지원하는 턴 수를 늘리려면 추가로 공간이 필요하다. 참조자료도 여러 소스에서 더 많이 찾아 넣으려면 그것도 어마어마하게 든다. LLM으로 문서작성을 시킨다면, 작성중인 문서도 통으로 들어가야 한다. 파일 첨부는 얼만큼 잡아먹을지 계산도 어렵다. 그냥 길이를 정해 커트하는 수밖에.

한 번에 처리하지 않고 여러 번 나눠 처리하면 되지 않냐고? 70b, 100b 규모의 LLM을 여러번 추론 시키는 건 비용이 엄청나다. 서비스 규모를 늘리려면 그거도 감당 안된다. 작은 모델로 나눠서 여러번 추론하는 건.

처음 말했듯이 성능이 안된다. 소설쓰기 실험에서 mini급만 해도 설정을 반영해서 스토리를 만드는 게 아니라 그냥 설정 문구를 싸지르는 수준의 글을 쓰지 않던가.

작업의 종류에 따라 모델을 나누는건? 이미 빵빵한 추론서비스를 제공하는 API 기반으로는 좋은 방법이다. 하지만 on-prem으로 구축하는 내부 서비스로는 힘들다. 기능별로 모델을 나누면 어떤 기능에 요청이 쏠릴 때 병목현상이 발생한다. 서비스 안정성에 직결된다.

거기에 기능의 난이도, 중요도를 구분해 판단하는 것 부터가 고도의 추론 과정이 필요하다. 그걸 전문적으로 학습한 planner모델이 따로 필요하다.

그렇게 하더라도,

무한한 정보를 수용할 수는 없다. 책의 내용을 처리하려고 해도 단행본 하나가 보통 300-500k다. 그걸 다 우겨넣을 수는 없다. 요약해 넣는다 해도, 거기서 사용자가 뭘 물어볼 줄 알고? 특히 문학같은 곳에선 긴 컨텍스트에 걸쳐 암시되는 정보들이 무수히 많다. 장면장면을 파편화해서 일부만 따오는 RAG로는 감당하기 힘들다.

내가 내 소설 챗GPT에 참고자료로 넣고 돌려봐서 잘 안다. 여기 올린 실험보다 더 많이 해봤다. 사람 헷갈리는 건 기본, 없는 사람 만드는 것도 예사, 거기에 그걸 우기는 것도 일상이며, 결과적으로 사람에 대해 물어보면 엉뚱한 사람의 일도 섞고 만들어낸 사건도 섞어서 엉망으로 만든다.

LLM을 이용해 별도의 요약본을 만들거나 메타데이터를 생성해 구조화 하는 것도 검토 중이지만 글쎄...

하지만 문학만 그럴까? 사람과의 대화에도 대단히 맥락이 잠재되어 드러나는 경우가 허다하다. 그걸 모두 이해하려면 한정된 컨텍스트에 필요한 정보만을 모아 저장해야 한다. 하지만 뭘 기준으로 그걸 뽑을까?

거기에 더 큰 문제가 있다.

LLM은 AI모델이다. 그리고 알려진 AI모델은 모두 학습된 데이터 내에서만 정확도를 보장한다. 학습되지 못한 부분은 취약하다. 그런데 현재의 LLM은 수 년간 쌓여온 대량의 레거시 데이터에 의존한다. 그리고 그 데이터는 대부분 컨텍스트가 4k, 8k 시절에 만들어졌다. 이후 10k 가 넘어가는 데이터도 만들어졌지만 그 사이 모델은 100k를 넘어가고 있다. 몇 년 사이의 이야기가 아니라 1년 안에 벌어진 차이다.

즉, 컨텍스트 꽉꽉 채워넣은 상황 자체가 학습데이터가 부족한 케이스다. 당연히 정확도가 떨어진다. 실제로, 긴 텍스트에 대해 번역 요청을 하면 멋대로 요약하는건 디폴트 사양일 정도다.

연구에 의하면 참조로 넣어준 컨텍스트 중 가운데에 나오는 것들이 무시되는 경향이 있다고 한다.

https://arxiv.org/abs/2307.03172

당연한 결과다. LLM에서는 참조하는 정보가 어디에 있는지 위치를 positional encoding이란 걸 해서 수치로 표현하는데, 맨 앞과 맨 뒤는 값이 확연히 차이나겠지만 중간은 차이가 줄어드니 모호해 질 수밖에 없다. 사실 사람도 비슷해서 두괄식, 미괄식 글은 있지만 줄괄식 글은 없는거와 같다. 그러니 많은 정보를 넣어준다고 모델이 모두 참조 가능한 것이 아니다.

실제로 LLM을 통해 장문을 처리해야 할때, 지시를 본문 앞뒤로 해서 2번 넣어주면 지시를 좀 더 잘 이행하는 경향이 있다.

이제 더 골때려졌다. 정보를 어떤 걸 골라넣으면 되는지도 골치아픈데, 그걸 어디에 놓을지도 중요한 관건인 것이다.

이건 또 다른 문제를 야기한다. 예를 들어, 다양한 업무를 처리하는 LLM이 있다고 치자. 각 업무에 맞춰 특화된 지시사항들을 미리 넣어줘, 업무들을 효과적으러 처리할 수 있게 할 수도 있다. 그런데 그 지시들이 많아질수록 LLM은 혼란에 빠진다. 지시의 위치에 따라 무시될수도 있고, 지시사항들을 보느라 참조문서의 본문이 무시될 수도 있다.

사전 정의된 작업들이면 처음에 분기를 타면 된다. 그런데 사전 정의가 안되면?

AI서비스가 개발되면 넥스트 스테이지는 개인화다. 그런데 사용자별로 모델 튜닝하는 건 불가능하다. 개인별로 별개의 모델을 올려 서빙하는 건 낭비적이다. 빅테크라도 무리다. 뭔가 추가적인 어댑터가 나오지 않는 한.

LoRA도 그렇게 휙휙 쉽게 바꾸지는 못하는 걸로 알고 있다.

현재로서는 컨텍스트 엔지니어링만이 답이다. 개인화된 정보를 컨텍스트에 넣는 것이다. 하지만 개인의 피드백과 대화 맥락을 모두 컨텍스트에 넣는 건 무리다. 그 개인이 하던 다양한 작업 이력에서 필요한 작업 종류를 분류해내고 거기에 맞는 작업 플래너를 설계해 그에 맞는 지시들을 묶어 축적하는 건 너무나 어려운 일이다. 또한 맥락은 소량의 지시문이 되는 과정에서 소실된다.

개인화가 그렇게 중요하냐고? 어마어마하게 중요하다. 특히 LLM에서는. 내가 작업하던 데이터, 내가 작업하는 절차, 내가 작업하는 스타일, 내가 하는 하나하나의 피드백들이 실제 작업에 엄청난 영향을 끼친다.

예를 들면, 챗GPT는 대화 기록을 저장하고 이를 나중의 대화에 반영하는 듯 하다. 대화 이력으로 개인 RAG를 구성해주는 느낌이다. 근데 이게 문제가 있다. 내가 질문할 때 가끔 보면, 예전에 GPT가 잘못 답변한 내용도 가져온다. 내가 거기에 대해 부정적인 피드백을 해도 반영이 되지 않는 것이다. 그러면 AI는 잘못을 반복한다.

가르쳐줘도 개선이 안되는 신입사원 같은 꼴이다.

그런데 그게 그나마 났다. 가르쳐줘도 무조건 휘발되어 머리에서 사라지는 신입사원보다는 그나마 개선의 여지가 있으니까.

실제로 챗봇을 구성한다면 어떻게 될까? 히스토리 저장은 기본, 히스토리를 RAG화 하는 것도 필요하다. 당시 사용자 반응을 바탕으로 지시문을 정리하는 작업도 필요할 듯 하다. 사용자가 자주 언급하는 업무정보는 따로 메모해둬야 할 것이다. 업무 종류에 따라 메타데이터를 붙이고 플래너에 반영하기도 해야 한다. 회사 일과 집안일을 동일한 지시문으로 해결할 수가 없다. 그러나.

몇달에 걸쳐 이루어지는 프로젝트의 맥락을 전부 따라갈 수 있을까? 몇년에 걸쳐 쓰고 있는 소설은?

현재 LLM은 소설과 같은 문학에 취약하다. 소설에서는 하나의 복선이 모습을 드러내지 않고 작품 전체에 영향을 끼치는 일도 흔하다. 인물을 이해하려면 한두 장면이 아니라 그 인물이 말하고 행동한 수십, 수백 장면을 이해해야 한다. 한 명의 인물이 상대하는 사람에 따라 태도가 달라지는 것도 흔하고 그것 자체가 그의 본성을 드러내는 요인이 되기도 한다. LLM이 그 소설을 이해하려먼 그걸 모두 이해해야 한다.

어디까지 가능한 일일까.

난 엔지니어다. '그건 그 기술의 한계야'라고 결론 내리는 사람이 아니다. 다만 지금은 답을 찾고 있다.

어쩌면 장기 기억을 반영하기 위한, 압축된 컨텍스트가 필요할지도 모른다. 이전에 RNN에서 쓰였던 잠재 변수처럼. 기술은 돌고 도는 법이니까.

아무튼 머릿속이 복잡해진 걸 여기 정리해본다.