서론 (Intro)

모델 제공업체들은 계속해서 더 큰 컨텍스트 윈도우 (context windows)를 출시하고 있습니다: 100k 토큰, 200k, 어떤 경우에는 100만 개가 넘기도 합니다. 마케팅 문구는 간단합니다: 모든 것을 붙여넣기만 하면, 모델이 무엇이 중요한지 알아서 파악할 것이라는 것입니다. 이는 유혹적인 아이디어이지만, 프로덕션 (production) 환경에서 실행되어야 하는 그 어떤 것에도 적절한 기본 설정이 아닙니다.

여기에 간극이 있습니다. 튜토리얼이나 데모에서는 "긴 컨텍스트 (long context)"란 문서를 붙여넣고 질문을 한 번 던지는 것을 의미합니다. 아무도 소요 시간을 측정하지 않고, 아무도 열 번째 호출에 대해 비용을 지불하지 않으며, 아무도 무엇이 무시되었는지 알아차리지 못합니다. 하지만 프로덕션에서는 동일한 요청이 매일 수천 번 실행되며, 매번 빠르고, 저렴하며, 정확해야 하는 시스템을 대상으로 합니다. 100k 토큰을 수용할 수 있는 능력이 있다고 해서, 모든 요청에 그만큼의 양을 채워 넣는 것이 좋은 아이디어인지에 대해서는 아무것도 말해주지 않습니다. 아래는 순진한 접근 방식이 실제 트래픽을 만났을 때 나타나는 네 가지 실패 모드 (failure modes)입니다. (이 시나리오들은 예시를 위한 복합적인 구성이며, 특정 고객의 사례 연구는 아닙니다.)

서비스가 시작되기 전까지는 아무도 눈치채지 못하는 지연 시간 세금 (The latency tax)

예를 들어, 어떤 고객 지원 도구가 "혹시 모를 관련성"을 위해 매 메시지마다 고객의 지난 40개 티켓 전체 이력을 모델에 제공한다고 가정해 봅시다. 데모에서는 이것이 단 한 번의 호출이며, 즉각적인 것처럼 느껴집니다. 하지만 프로덕션에서는 모델이 한 단어를 쓰기 전에 수만 개의 토큰을 처리해야 하기 때문에, 모든 답변이 이제 2초가 아닌 10~12초가 걸립니다. 사용자들은 "더 많은 컨텍스트"를 경험하는 것이 아닙니다. 그들은 느린 봇을 경험하며, 느린 봇은 대화 도중에 버려지게 됩니다.

마진을 갉아먹는 요소 (The margin killer)

토큰 비용은 파일럿 단계에서는 놓치기 쉽지만, 규모가 커지면 잔혹하게 복리로 작용합니다. 고객에게는 사용자(seat)당 비용을 청구하지만, 배후에서는 토큰당 비용을 지불하는 팀은 사용량이 아닌 컨텍스트 크기에 따라 증가하는 매출원가 (COGS)를 떠안게 될 수 있습니다. 만약 해당 이력이 관련이 있는지 여부와 관계없이 모든 요청이 동일하게 부풀려진 페이로드 (payload)를 전달한다면, 가격 모델이 이미 판매된 지 한참 후에 고객 기반이 성장함에 따라 단위 경제성 (unit economics)이 조용히 무너질 수 있습니다.

중간에서 길을 잃음 (Lost in the middle)

심지어 토큰들이 기술적으로 "윈도우 (window)" 안에 있더라도, 어텐션 (attention)이 그 전체에 걸쳐 균일하게 작용하지는 않습니다. 모델은 컨텍스트 (context)의 중간에 파묻힌 정보보다 시작과 끝 근처의 정보를 사용하는 데 훨씬 더 뛰어나다는 것이 입증되었습니다. 질문과 관련된 단 하나의 답변이 47페이지에 있는 100페이지 분량의 정책 문서를 받은 컴플라이언스 어시스턴트 (compliance assistant)를 상상해 보십시오. 모델은 모든 토큰을 "읽었을" 수도 있지만 여전히 그 답변을 놓칠 수 있습니다. 컨텍스트 안에 있는 것과 어텐션(attention)을 받는 것은 같은 의미가 아니기 때문입니다.

환각 (hallucination)으로 변하는 노이즈 (Noise)

"안전하게 상위 15개 청크 (chunks)를 포함하자"라며 너무 많은 정보를 가져오는 검색 시스템 (retrieval systems)은 안전하게 행동하는 것이 아닙니다. 과도한 컨텍스트는 중립적인 채우기용 데이터가 아닙니다. 느슨하게 관련된 문서들은 모델이 정보를 혼합하고, 잘못 귀속시키며, 그럴듯하게 들리지만 사실은 틀린 답변으로 자신 있게 결합할 수 있는 더 많은 재료를 제공합니다. 시스템은 요란하게 실패하지 않습니다. 설득력 있게 실패합니다.

컨텍스트 관리란 LLM의 옷을 입은 데이터 엔지니어링이다

이러한 모든 실패 모드 (failure modes)는 동일한 근본 원인의 증상입니다. 즉, 컨텍스트를 비용과 감쇠 곡선 (decay curve)이 존재하는 리소스가 아닌, 무제한의 양동이로 취급하는 것입니다. 해결책은 더 큰 윈도우 (window)가 아닙니다. 그것은 파이프라인 (pipeline)입니다. 즉, 청킹 (chunking), 필터링 (filtering), 랭킹 (ranking), 요약 (summarizing), 그리고 현재 작업에 실제로 필요한 것만을 검색 (retrieving)하는 과정입니다. 이것은 프롬프트 엔지니어링 (prompt engineering)이 아닙니다. 지난 10년 동안 우수한 검색 및 추천 시스템의 근간이 되었던 것과 동일한 규율을 새로운 유형의 소비자에게 적용하는 것입니다.

직접 구축할 것인가, 구매할 것인가

만약 컨텍스트 관리 (context management)가 제품 차별화의 핵심이라면 — 그리고 데모 단계를 지나고 나면 대개 그러합니다 — 이를 단순히 빠른 시작 (quickstart)을 제공하는 프레임워크에 덧붙여진 사후 고려 사항으로 취급하기보다는, 검색 (retrieval) 및 필터링 (filtering) 레이어를 직접 소유할 가치가 있습니다. 기성 벡터 저장소 (off-the-shelf vector stores)와 오케스트레이션 라이브러리 (orchestration libraries)는 초기 프로토타입을 위한 합리적인 시작점이지만, 랭킹 로직 (ranking logic), 요약 전략 (summarization strategy), 그리고 특정 작업에 무엇이 관련이 있는지에 대한 결정이야말로 실제 제품 가치가 존재하는 지점입니다. 규모가 커짐에 따라 비용과 정확도를 최적화해야 하는 단계에 이르면, 타인의 기본 설정 (defaults)에 전적으로 의존하고 싶지는 않을 것입니다.

여러분이 배포했거나 디버깅했던 최악의 컨텍스트 비대화 (context-bloat) 버그는 무엇이었나요? 다른 사람들이 어떤 패턴을 마주했는지 궁금합니다.