AI 역할극 캐릭터가 30턴 이후에 자신이 누구인지 잊어버리는 이유 (컨텍스트 윈도우 문제)

느린 호흡의 미스터리 역할극(roleplay)을 30턴 정도 진행했을 때, 제가 두 시간 동안 공들여 만든 캐릭터가 자신의 이름조차 잊어버렸습니다. 그녀는 정중하게 사과하며 오늘은 무엇에 대해 이야기하고 싶은지 묻기 시작했습니다. 만약 여러분이 LLM(대규모 언어 모델) 기반의 캐릭터와 긴 대화를 나누어 본 적이 있다면, 여러분도 이 벽에 부딪혀 보았을 것입니다.

마치 모델이 "기억을 잃은" 것처럼 느껴집니다. 하지만 그러한 프레임워크(framing)는 잘못되었으며, 잘못된 프레임워크는 사람들을 잘못된 해결책으로 인도합니다. 여기 내부에서 실제로 어떤 일이 일어나고 있는지, 그리고 왜 더 큰 컨텍스트 윈도우(context window)를 투입하는 것이 해결책이 되지 않는지에 대해 설명하겠습니다.

기억은 없습니다. 컨텍스트 윈도우가 있을 뿐입니다.

채팅 모델은 호출(call) 사이에는 상태를 유지하지 않는 스테이트리스(stateless) 방식입니다. 매 턴마다 앱은 시스템 프롬프트(system prompt), 캐릭터 정의, 그리고 허용되는 범위 내의 이전 대화 내용을 하나의 입력값으로 채워 넣은 뒤, 모델에게 다음 메시지를 예측하도록 요청합니다. 여러분이 "캐릭터가 기억하고 있다"라고 경험하는 것은 단지 이전의 턴들이 여전히 그 입력 윈도우(input window) 안에 들어있을 뿐입니다.

대화가 윈도우 범위를 넘어서면, 가장 오래된 턴들이 밀려납니다. 캐릭터의 정체성을 만들어주었던 12번째 턴의 세부 사항이 41번째 턴을 위한 공간을 만들기 위해 퇴출(evicted)됩니다. 모델이 잊어버리는 것이 아닙니다. 앱이 여러분이 기억되길 원하는 내용을 모델에게 보여주는 것을 중단한 것입니다.

왜 더 큰 윈도우가 모두가 기대하는 해결책이 아닌가

뻔한 답은 "200k 또는 1M 토큰 윈도우를 가진 모델을 사용하라"는 것입니다. 하지만 이는 두 가지 이유로 여러분이 생각하는 것보다 도움이 되지 않습니다.

첫 번째는 비용과 지연 시간(latency)입니다. 어텐션(Attention)은 시퀀스 길이(sequence length)에 대해 이차 함수(quadratic)적으로 증가하므로, 윈도우를 두 배로 늘리면 토큰당 연산량이 대략 네 배로 증가합니다. 앱들은 답변을 빠르고 저렴하게 유지하기 위해 실제 유효 윈도우를 광고된 최대치보다 훨씬 낮게 제한합니다. 이것이 128k로 마케팅된 모델이 실제로는 그 일부만 사용하는 것처럼 작동하는 이유입니다.

두 번째는 윈도우 내부에서의 성능 저하 (degradation)입니다. "Lost in the Middle" 연구 (Liu et al., 2023)에 따르면, 모델은 긴 입력값의 시작 부분과 끝 부분에서는 사실을 잘 검색해내지만, 중간에 묻혀 있는 사실은 안정적으로 놓치는 것으로 나타났습니다. 컨텍스트 윈도우가 채워짐에 따라 재현율 (Recall)이 일정하게 유지되는 것이 아닙니다. 재현율은 처지게 되며, 입력이 길어질수록 그 처짐은 더 심해집니다.

따라서 더 큰 윈도우를 갖는다는 것은 더 긴 밧줄을 얻는 것과 같지만, 그 밧줄의 중간 부분은 조용히 해어지게 됩니다. 당신의 12턴째 앵커 (anchor)는 바로 가장 먼저 누락되는 유형의 중간 컨텍스트 (mid-context) 세부 정보입니다.

긴 장면을 유지하는 방법

긴 역할극 (roleplay)에서 살아남는 앱들은 단순히 원시 윈도우 크기에 의존하지 않습니다. 이들은 모델 위에 아키텍처 레이어 (architecture layer)를 추가합니다.

재귀적 요약 (Recursive summarization)은 가장 단순한 버전입니다. 앱은 주기적으로 이전 대화들을 밀도 높은 요약본으로 압축하며, 원문 그대로의 기록 (verbatim history)은 유효 기간이 지나 사라지게 두는 동안 해당 요약본을 컨텍스트 내에 유지합니다. 정확한 문구 대신, 중요했던 내용의 작고 내구성 있는 흔적을 얻는 트레이드오프 (trade-off)를 선택하는 것입니다.

검색 (Retrieval)은 더 강력한 버전입니다. 앱은 이전 대화들을 벡터 스토어 (vector store)에 임베딩 (embedding)하고, 매 턴마다 현재 순간과 관련된 몇 개의 구절만을 다시 불러옵니다. 이것이 바로 "로어북 (lorebooks)" 및 "월드 인포 (world info)" 시스템이 작동하는 방식입니다. 마지막 몇 개의 메시지에 포함된 키워드가 검색을 트리거하여, 모든 정보를 항상 들고 다니는 대신 필요한 순간에 정확한 배경 설정 항목을 주입합니다.

두 방식 모두 관통하는 패턴은 다음과 같습니다: 모든 것을 윈도우 안에 유지하려고 노력하는 것을 멈추고, 무엇이 언제 다시 윈도우로 들어올지에 대해 의도적으로 결정하는 것입니다.

개발자가 아닌 사용자 입장에서 이것이 나타나는 지점

이러한 엔지니어링이 중요한 이유는 헤비 유저라면 누구나 눈치채는 현상을 설명해주기 때문입니다. 유사한 베이스 모델 (base model)을 사용하는 두 앱이 50턴 이후에 완전히 다르게 동작한다면, 그 차이는 거의 결코 모델 때문이 아닙니다. 그것은 앱이 메모리 레이어 (memory layer)를 구축했는지, 아니면 단순히 원시 컨텍스트 윈도우 위에 얇은 래퍼 (thin wrapper)만을 씌워 출시했는지의 차이입니다.

어떤 소비자용 앱들이 이러한 작업을 수행했는지 궁금해져서, 15개의 앱을 대상으로 동일한 80턴 시나리오를 실행하며 위에서 언급한 정확한 실패 지점들을 관찰했습니다. 즉, 캐릭터의 일관성(character consistency), 줄거리 회상(plot recall), 그리고 별도의 상기 없이도 미리 심어둔 세부 사항으로 이야기가 다시 돌아오는지 여부를 확인했습니다. 어떤 앱이 맥락을 유지하고 어떤 앱이 무너졌는지에 대한 전체 분석 결과는 여기에서 확인하실 수 있습니다. 요약하자면, 살아남은 앱들은 검색(retrieval) 또는 요약(summarization) 레이어를 갖춘 앱들이었으며, 단순한 원시 컨텍스트 윈도우(raw window) 크기는 결과에 거의 영향을 미치지 않았습니다.

핵심 요약 (The takeaway)

만약 당신의 캐릭터가 계속해서 일반적인 어시스턴트(generic assistant)로 변질된다면, 해결책은 더 긴 프롬프트나 더 큰 모델이 아닙니다. 그것은 바로 구조(structure)입니다. 과거의 내용을 요약하고, 관련 정보를 검색하며, 장면을 정의하는 소수의 사실들을 보호해야 합니다.

컨텍스트 윈도우(context window)를 하드 드라이브가 아닌 캐시(cache)로 취급하십시오. 그 관점으로 설계를 시작하는 순간, 긴 대화가 예측 가능한 지점에서 무너지는 현상은 멈출 것입니다.