에이전트에게 수백만 개의 토큰을 컨텍스트 윈도우에 제공했지만 여전히 제대로 작동하지 않습니다.
이거 저장하세요 :)
사용 가능한 모델에 도구와 긴 작업을 부여합니다. 처음 15단계까지는 훌륭합니다. 집중적이고 정확합니다. 질문에 답하고 사용자를 잘 분석합니다.
그러나 대화의 규모가 커지기 시작하면서 에이전트는 방향을 잃기 시작합니다. 에이전트는 10단계 전에 내린 결정을 뒤집습니다. 컨텍스트 윈도우를 거짓 정보로 오염시키기 시작합니다. 사용자 선호도가 존재한다는 것을 알지만, 이를 안정적으로 가져오지 못합니다. 그동안 여러분은 왜 문제가 발생했는지 파악하는 데 어려움을 겪습니다.
그래서 더 큰 것을 찾게 됩니다. 작업을 더 오래 유지하기 위해 더 큰 컨텍스트 윈도우를 가진 모델. RAG 파이프라인 최적화를 시도합니다. 에이전트 메모리 솔루션을 위해 인터넷을 샅샅이 뒤집니다.
그리고 어떤 것도 예상대로 작동하지 않습니다.
그 이유를 이해하면 에이전트 스택 전체에서 가장 가치 있으면서도 가장 이해되지 않은 계층으로 바로 연결됩니다.
실패는 순환 고리입니다
에이전트가 성능을 저하시키는 이유는 능력 부족이 아닙니다. 그것은 피드백 루프이며, 네 개의 고리로 구성됩니다. 네 개의 고리를 모두 보면, 일반적인 해결책은 더 이상 해결책처럼 보이지 않습니다.
첫 번째 고리: 모델은 컨텍스트 전체를 균등하게 사용할 수 없으며, 컨텍스트가 채워질수록 더 악화됩니다.
이것은 대부분의 사람들이 내면화하지 못하는 부분입니다. 모델이 정보를 사용하는 능력은 컨텍스트 윈도우 전체에서 균일하지 않습니다. 모델은 맨 처음과 맨 끝에 있는 정보를 안정적으로 사용하며, 중간 부분은 체계적으로 덜 집중합니다. 특히 긴 입력을 위해 특별히 구축된 경우에도 마찬가지입니다. 더 많이 채우면 신뢰도는 더욱 떨어집니다. 이는 단어 목록을 반복하는 것과 같은 간단한 작업에서도 나타납니다. 단 하나의 방해 요소만 추가해도 성능이 눈에 띄게 떨어집니다. 여러 개의 복합적인 요소를 추가하면 더욱 심해집니다.
따라서 모델이 실제로 안정적으로 추론할 수 있는 유효 컨텍스트는 상자에 적힌 숫자보다 훨씬 작습니다. 그리고 더 많이 채울수록 더 작아집니다.
이제 에이전트가 하는 일을 생각해보세요. 에이전트는 누적됩니다. 모든 도구 결과, 모든 단계의 기록, 모든 메모가 컨텍스트에 추가됩니다. 이는 에이전트가 수행하는 모든 단계의 품질을 꾸준히 낮추고 있음을 의미합니다. 증가하는 컨텍스트는 단계별 오류를 만들어내는 것입니다.
두 번째 고리: 이러한 단계별 오류는 합산되지 않습니다. 곱해집니다.
에이전트가 몇 단계만 수행한다면 약간의 단계별 오류는 괜찮을 것입니다. 하지만 에이전트는 수십 단계를 수행합니다. 그리고 실패는 누적되지 않고 복합적으로 작용합니다. 5단계에서 95% 신뢰할 수 있는 에이전트는 20단계 작업에서도 95% 신뢰성을 유지하지 않습니다. 충분한 단계를 실행하면 동전 던지기에 가까워질 뿐입니다.
더 나쁜 점은 오류가 스스로 강화된다는 것입니다. 약간 궤도를 벗어난 하나의 도구 호출은 다음 호출도 벗어날 가능성을 높입니다. 이를 첫 번째 고리(기본 오류율 자체가 윈도우가 채워짐에 따라 증가하는 현상) 위에 쌓으면 장기 에이전트의 특징적인 실패 모드가 나타납니다. 에이전트는 우아하게 저하되지 않습니다. 잠시 유지되다가 갑자기 급락합니다.
세 번째 고리: 작업이 길고, 모델은 상태 비저장(stateless)입니다. 따라서 모델 외부에 상태를 저장해야 합니다.
언어 모델은 호출 사이에 아무것도 유지하지 않습니다. 모든 호출은 빈 상태로 시작됩니다. 모델이 아는 것은 다시 입력으로 제공되는 것뿐입니다. 따라서 긴 작업의 경우 상태를 외부화해야 합니다. 스크래치패드, 진행 파일, 체크포인트, 벡터 저장소, 사실을 추출하여 여러 세션에 다시 제공하는 전용 메모리 계층 등이 필요합니다.
이것은 정확하고 필요합니다. 그리고 깔끔한 해결책처럼 보입니다. 에이전트는 중요한 것을 잊지 않습니다. 모든 중요한 정보는 영구 저장소에 있기 때문입니다.
네 번째 고리: 저장된 메모리는 비활성 상태이며, 이를 다시 가져오는 것은 해결하려던 문제 자체를 악화시킵니다.
여기서 순환이 닫힙니다. 모델은 데이터베이스를 추론할 수 없습니다. 오직 컨텍스트 윈도우에 있는 내용만 추론할 수 있습니다. 따라서 메모리는 다시 가져오는 순간에만 도움이 됩니다. 그리고 모든 검색은 토큰을 추가합니다. 에이전트가 진행 상황을 추적하기 위해 작성하는 모든 요약은 나중에 다시 읽어야 하는 토큰입니다. 공간을 확보하기 위해 기록을 압축하는 모든 단계는 손실이 있으며, 버려지는 세부 사항은 종종 나중에야 중요성이 드러나는 미묘한 부분입니다.
따라서 컨텍스트 제한을 극복하기 위해 구축한 메모리 시스템은 결국 컨텍스트 제한을 더 악화시킵니다. 더 많은 메모리는 더 많은 검색을 의미하고, 이는 윈도우에 더 많은 노이즈를 의미하며, 더 많은 단계별 오류를 의미하고, 이는 복합적으로 작용하여 처음에 메모리를 찾게 만든 바로 그 상황으로 이어집니다.
순환 고리는 실제입니다. 그리고 컨텍스트 윈도우 크기가 얼마나 크든 상관하지 않습니다.
용량은 결코 중요한 축이 아니었습니다
순환 고리를 인식하면 표준적인 해결책의 무용함이 명확해집니다.
더 큰 컨텍스트 윈도우는 이를 깨지 않습니다. 단지 급락 전에 축적할 수 있는 부패의 한계를 높일 뿐입니다. 한편, 유효 컨텍스트에 대한 모든 연구는 같은 사실을 계속 보여줍니다: 안정적으로 사용 가능한 부분은 광고된 숫자보다 훨씬 느리게 증가합니다. 여러분은 실제로 사용할 수 없는 용량을 구매하고 있는 것입니다.
더 많은 메모리는 이를 깨지 않습니다. 이미 모든 것을 담을 수 없는 윈도우에 다시 들어오기 위해 경쟁하는 자료의 양을 증가시킵니다.
다음 아키텍처도 이를 깨지 못할 것입니다. 어텐션(attention)에 맞서는 도전자들, Mamba와 같은 상태 공간 모델(state-space model)과 그 하이브리드는 모든 토큰을 주소 지정 가능하게 유지하는 대신 과거를 고정 크기 상태로 압축하여 승리합니다. 이는 선형 시간 추론과 시퀀스에 따라 커지지 않는 메모리 공간을 제공합니다. 하지만 회상(recall)을 제공할 수는 없습니다. 고정 크기 상태는 모든 것을 담을 수 없기 때문에 설계상 망각합니다. 규모가 커지면 순수 상태 공간 모델은 트랜스포머(transformer)에 비해 정확히 외부 메모리가 존재하는 이유인 특정 사실을 시퀀스의 임의 지점에서 다시 가져오는 작업에서 뒤처집니다. 이것이 진지한 포스트-어텐션(post-attention) 노력이 회상을 수행하기 위해 소수의 어텐션 레이어를 유지하는 하이브리드인 이유이며, 상태 모델은 그렇게 할 수 없습니다. 아키텍처를 변경해도 벽은 움직이지 않습니다. 단지 반대편에서 벽에 도달할 뿐입니다.
따라서 교훈은 "더 큰 숫자를 선택하라"가 아닙니다. 용량은 결코 제약 조건이 아니었습니다.
진정한 제약 조건은 각 단계에서 어떤 토큰이 윈도우를 차지할지에 대한 결정의 품질입니다.
그것이 전부입니다. 가장 큰 컨텍스트가 아니라 가장 작고 충분한 컨텍스트입니다. 회상보다는 관련성(relevance over recall)입니다. 잘라내기의 우연이 아니라 일급 연산으로서의 의도적인 망각입니다. 연구는 이를 직접적으로 뒷받침합니다: 잘 선택된 몇 천 개의 토큰을 순서를 유지하며 검색하는 것이 전체 128K 윈도우를 모델에 덤프하는 것보다 낫습니다. 장점은 얼마나 많이 들어올 수 있는지가 아니라 무엇이 들어오는지 선택하는 데 있습니다.
그리고 이것이 대부분의 팀을 사로잡는 함정입니다. 선택을 위해 사용하는 도구가 잘못된 형태이기 때문입니다.
유사성은 관련성이 아닙니다
어떤 컨텍스트를 다시 가져올지 결정하는 기본 방법은 유사성 검색(similarity search)입니다. 모든 것을 임베딩하고, 에이전트가 컨텍스트를 필요로 할 때 현재 쿼리와 가장 가까운 벡터를 검색합니다.
그러나 유사성은 잘못된 질문에 답합니다. 가까운 것을 반환할 뿐, 관련된 것을 반환하지 않습니다. 이 둘은 매우 다른 것입니다.
에이전트가 실제로 필요로 하는 질문은 "이것과 유사한 것은 무엇인가"가 결코 아닙니다. 그것은 "현재 이 작업과 이 상태가 주어졌을 때, 중요한 것과 연결되는 것은 무엇인가"입니다. 그것은 관계형 질문(relational question)입니다. 의존성, 출처, 무엇이 무엇을 대체했는지, 어떤 결정이 어떤 결과를 초래했는지에 관한 것입니다. 유사한 벡터를 검색하도록 조정된 저장소는 대신 모델에 근접 실수(near-misses) 더미를 제공합니다. 그리고 근접 실수는 정확히 첫 번째 고리의 방해 요소로, 급락으로 이어지는 단계별 오류를 유발합니다.
이것이 해결책이 임베딩 저장소 앞에 얇은 캐시를 두는 것일 수 없는 이유입니다. 지능은 조회에 있는 것이 아니라 구조에 있습니다.
아무도 가격을 책정하지 않는 계층
에이전트 스택에서 포착해야 할 가장 중요한 계층은 모델도, 저장소도 아닙니다. 그것은 그 사이의 계층입니다. 모델이 주의를 기울일 대상을 결정하는 계층입니다.
그리고 실제로 그 작업을 수행하려면 세 가지 조건을 충족해야 합니다.
중립적이어야 합니다. 내부 사항은 끊임없이 변화합니다. 트랜스포머에서 상태 공간 모델로, 하이브리드로. 하나의 프론티어 모델에서 다음 모델로, 몇 달마다 새로운 가격 대비 성능 리더가 등장합니다. 단일 모델에 고정된 컨텍스트 전략은 움직이는 표적에 베팅하는 것입니다. 여러분의 조직이 실제로 가치를 축적하는 것은 컨텍스트, 즉 에이전트가 알고 수행한 내용에 대한 힘들게 얻은 구조화된 기록입니다. 이를 한 공급업체의 메모리 기능에 고정시키면, 가장 내구성 있는 자산을 여러분의 것이 아닌 로드맵에 인질로 맡기는 것입니다. 단일 모델 외부에 존재하는 선택 계층은 동일한 조직화된 컨텍스트가 실행하는 모든 모델과 아직 채택하지 않은 다음 모델에도 서비스를 제공할 수 있게 합니다.
수평적이어야 합니다. 프레임워크의 체크포인트는 하나의 실행만 알고 있습니다. 모델의 내장 메모리는 해당 모델의 대화만 알고 있습니다. 벡터 인덱스는 하나의 코퍼스만 알고 있습니다. 실제 워크로드를 실행할 때 중요한 그림을 보유한 것은 없습니다: 여러 에이전트, 여러 세션, 여러 모델, 모두가 하나의 일관되고 쿼리 가능한 컨텍스트 뷰를 필요로 합니다. 이러한 기록 시스템(System of Record) 역할은 앱이나 프레임워크 또는 연구소가 수행하도록 설계되지 않았습니다. 각각 자신의 조각만 보기 때문입니다. 이것은 모든 것을 가로지르는 수평적인 고유의 계층입니다.
구조화되어야 합니다. 이것이 "단지 더 나은 데이터베이스"와 구별되는 점입니다. 선택은 관련성 문제이며, 관련성은 관계형입니다. 컨텍스트 위의 구조, 관계와 의존성, 출처와 대체(supersession)는 검색을 선택으로 전환합니다. 이는 저장소와 근본적으로 다른 프리미티브이며, 순환 고리가 요구하는 바로 그것입니다.
"연구소들이 그냥 이걸 출시하지 않을까?"
명백한 반론은 모델 연구소들이 이를 흡수할 것이라는 점입니다. 그들은 계속해서 메모리와 컨텍스트 기능을 출시하고 있으며, 모델 자체의 어텐션에 대한 특권적인 접근 권한을 가지고 있습니다.
그들은 그럴 것이고, 이 반론은 절반은 맞습니다. 단일 앱을 감싸는 단일 모델의 경우 연구소가 처리하도록 두는 것이 종종 충분합니다. 괜찮습니다.
그러나 연구소의 인센티브는 자체 모델을 더욱 끈적하게 만드는 것입니다. 이것은 이식성의 반대입니다. 하나의 모델 내부에 융합된 큐레이션은 다중 모델, 조직 전체의 경우를 처리할 수 없습니다. 진정한 컨텍스트 기반(substrate)은 이러한 기능과 정면으로 경쟁하지 않습니다. 연구소가 구조적으로 제공하려 하지 않는 상황을 위해 존재합니다: 여러 에이전트와 팀에서 여러 모델을 실행하고, 에이전트가 생각할 대상을 결정하는 계층을 오늘날 실행하는 모델의 공급업체가 소유하도록 두지 않으려는 경우입니다.
그리고 추세는 이를 더욱 강화합니다. 모델의 성능이 향상될수록 더 많이 사용됩니다. 더 많이 사용될수록 조직에서 더 많은 에이전트를 실행합니다. 더 많은 에이전트를 실행할수록 중립적이고 수평적이며 구조화된 선택 계층의 가치는 더욱 커집니다.
누가 이걸 만들고 있나요?
여기가 HydraDB가 등장하는 부분입니다. 중립적이고, 수평적이며, 구조화되어 있습니다. 유사성 검색이 평탄화하는 관계, 의존성, 출처, 대체를 보유합니다. 시간적으로 버전 관리되고 선호도를 인식하므로, 무엇이 사실인지뿐만 아니라 무엇이 그것을 대체했는지도 알고 있습니다. 특정 에이전트가 시간이 지남에 따라 학습한 내용에 대한 가시성을 제공합니다. 이 구조는 검색을 선택으로 전환합니다.
내부적으로 HydraDB는 계층화된 저장소에서 실행됩니다: 활성 컨텍스트를 위한 핫 인메모리 캐시, 웜을 위한 NVMe, 콜드를 위한 오브젝트 스토리지. 컨텍스트는 최근성과 중요성에 따라 승격 및 강등되므로, 모델이 추론하는 작업 세트는 의도적으로 작게 유지됩니다. 모델과 모델이 알 수 있는 모든 것 사이에 위치합니다.
모든 에이전트가 대답해야 하는 질문
아키텍처 논쟁, 메모리 제품, 컨텍스트 윈도우 경쟁을 벗겨내십시오. 그 모든 것 아래에서, 모든 장기 실행 에이전트는 매 단계마다 같은 질문에 답합니다.
알고 있는 모든 것 중에서, 지금 당장 무엇에 대해 생각해야 할까?
더 큰 윈도우는 그 질문에 답하지 않습니다. 단지 에이전트가 무시할 대상을 더 많이 제공할 뿐입니다. 순환 고리는 실제이며, 영구적이며, 어떤 용량으로도 닫히지 않습니다.
업계는 여전히 용량으로 문제를 해결하려 하고 있습니다. 불가능합니다. 이것이 항상 선택 문제였다는 점을 내면화한 팀은 작동하는 에이전트를 출시할 것이고, 다른 팀은 거의 작동하는 에이전트를 출시할 것입니다.
이것은 결코 모델의 순수한 한계가 아니었습니다. 유한한 예산 하에서 작동하는 모든 것은 주의를 기울일 대상을 선택해야 합니다. 선택은 오늘날의 한계에 대한 해결 방법이 아닙니다. 그것은 한계 하에서 추론이 항상 요구해 온 것입니다.
이 글이 유용했다면, 저를 팔로우해 주세요 @eng_khairallah1 더 많은 AI 콘텐츠를 위해. 매주 분석, 강좌, 도구를 게시합니다.
도움이 되었기를 바랍니다, Khairallah ❤️
