ACE를 생각하고 계신가요? 토큰을 더 적게 사용하며 구현할 수 있습니다

ALTK-Evolve와 ACE 모두 에이전트가 자신의 궤적(trajectories)으로부터 학습하도록 합니다. 차이점은 무엇을 하느냐에 달려 있으며, 이것이 토큰 비용을 결정합니다.

LLM 에이전트에게 현실적인 다단계 작업(multi-step task)—계산서 분할하기, 노래 찾기, 9개의 시뮬레이션 앱에 걸친 주문 조정하기—를 부여해 보세요. 그리고 실패했을 때, 그것은 보통 지식 부족 때문이 아닙니다. API 페이지를 잘못 넘기거나, 틀린 사람을 해결하거나, 요청되지 않은 값을 반환합니다. 모델은 API를 알고 있지만, 어떻게 신뢰성 있게 사용하는지는 내재화하지 못했습니다. 이것은 에이전트 자신의 이력(history)으로부터 학습할 수 있습니다.

최근 두 시스템이 정확히 이를 수행하며, 같은 종류의 에이전트를 사용합니다: ACE (Agentic Context Engineering)와 저희의 ALTK-Evolve (여기서 소개). 둘 다 **에이전트 메모리(agentic memory)**의 한 형태입니다. 즉, 에이전트의 과거 궤적을 재사용 가능한 **교훈(lessons)**으로 변환하여 추론 시간(inference time)에 다시 공급하며, 가중치 업데이트나 인간 레이블링이 필요 없습니다. 심지어 어려운 부분에 대해서도 의견이 일치합니다. 그들이 갈라지는 지점은 *전달 방식(delivery)*입니다.

단어에 대한 참고 사항을 말씀드리자면, 두 시스템이 사물을 다르게 명명하기 때문에 다음과 같이 부르겠습니다: 저희는 원시적인 학습 내용을 에이전트가 얻는 **교훈(lesson)**이라고 부를 것입니다. ACE는 이 교훈들을 하나의 포괄적이고 진화하는 **플레이북(playbook)**으로 정리합니다. 반면, 저희는 개별적으로 검색 가능한 **지침(guidelines)**으로 통합합니다. 같은 교훈이지만, 다른 컨테이너입니다.

두 시스템 모두 압축을 거부합니다.

ACE는 실패 모드를 정확하게 명명합니다: 간결성 편향(brevity bias)—최적화가 짧고 일반적인 지침 쪽으로 무너지는 현상—과 맥락 붕괴(context collapse)—모델이 매 단계마다 전체 맥락을 재작성하며 세부 정보를 요약해버리도록 요청받는 것. 이에 대한 답변은 풍부하고 항목별로 나열된 플레이북을 유지하는 것이며, 모든 글머리 기호에 유용/유해 카운터를 두고 읽는 시점에 모델이 관련성을 추출하도록 하는 것입니다.

다른 방향으로 접근해도 같은 결론에 도달합니다. 각 고유한 지침은 **지원 횟수(support count)**를 유지하는데, 이는 해당 지침을 생성한 독립적인 에피소드의 수를 의미하며, 우리는 이 저장소를 몇 가지 규칙으로 요약하지 않습니다. 다섯 개의 다른 작업에서 발견된 교훈과 한 번만 나타난 교훈은 서로 다른 객체이며, 둘 다 보존할 가치가 있습니다.

따라서 핵심 질문인 에이전트가 어렵게 얻은 교훈을 깔끔하게 요약해야 할까요? 에 대해 ACE와 ALTK-Evolve는 같은 답을 제시합니다. 아니요. 개수를 세고, 붕괴시키지 마세요. ACE의 항목별 카운터와 우리의 지원 횟수는 동일한 아이디어의 두 가지 표현일 뿐입니다.

두 가지 측면에서 살펴볼 수 있습니다: 메모리가 구축되는 방식과 전달되는 방식 — 그리고 토큰 비용에 영향을 미치는 것은 바로 전달 방식의 차이입니다.

통합(Consolidation) (저장소가 구축되는 방식). ACE는 생성기(Generator) → 반사기(Reflector) → 큐레이터(Curator) 루프를 통해 하나의 플레이북을 성장시키며, 증분 델타 업데이트를 적용하고 임베딩을 통해 중복을 제거합니다. 우리는 거의 동일한 교훈들을 클러스터링하고 클러스터 내부에서 병합하며, **지원 횟수를 보존(support-conserving)**합니다 — 여러 교훈이 병합될 때 생존하는 것은 이들의 결합된 카운터를 상속받기 때문에, 저장소는 줄어들지만 각 지침을 뒷받침하는 경험의 기록은 손실되지 않습니다. 또한 우리는 인과적 귀속(causal attribution) 및 출처 궤적(source trajectory)으로 전략, 복구, 최적화와 같은 유형별 지침을 추출하고, 서브태스크 수준에서 수행하여 한 앱에서 배운 교훈이 다른 앱으로 전이될 수 있도록 합니다.

전달(Delivery) (추론 시 모델에 도달하는 것). 이것이 수치를 좌우합니다. ACE는 모델이나 작업에 관계없이 모든 단계마다 **포괄적인 플레이북(comprehensive playbook)**을 주입합니다. 우리는 전달을 상수가 아닌 다이얼처럼 취급합니다. 즉, 높은 지원을 제공하는 작고 고정된 핵심 가이드라인으로 시작하여, 특정 작업을 위해 선택된 소수의 항목(코사인 또는 LLM 기반 안내, 우선순위 가중치 적용)으로 확장하거나 — 모델이 사용할 여유가 있을 때는 전체 통합 세트를 사용합니다. 동일한 교훈은 두 에이전트 모두에게 사용 가능하지만, 차이점은 ACE는 항상 모든 것을 보내고, 우리는 주어진 모델이 실제로 사용할 수 있는 만큼만 보낸다는 것입니다.

AppWorld에서, 동일한 기본 ReAct 에이전트를 사용하여 양쪽 시스템을 사내에서 실행했을 때:

강력한 모델에서는 두 지표 모두 ACE 추론 비용의 약 40% 수준으로 더 우수합니다. 약한 모델에서는 ACE가 54.8인 것에 대해 56.0을 기록하여 — 이 정도 차이는 **정확도 면에서 동률(tie)**로 간주할 수 있습니다 (저희의 반복 실행 결과는 54.8로, 이 벤치마크의 실행별 노이즈 범위 내에서 ACE와 거의 일치합니다) — 비용은 약 7분의 1 수준입니다.

비용에 대해 공정하게 말씀드리자면: ACE 자체의 효율성 이야기는 컨텍스트를 저렴하게 구축하는 것에 관한 것입니다. 저희는 다른 축, 즉 그것을 제공(serving) 하는 것에 초점을 맞춥니다. 모든 단계마다 전체 플레이북을 주입하는 대신 작업별로 몇 가지 가이드라인만 검색하여 가져오는 것이 토큰이 사용되는 곳이며, 이는 위에서 언급된 전달 방식의 직접적인 결과입니다.

정확도는 어디서 오는 것일까요? 난이도별 분석은 두 가지 다른 이야기를 들려줍니다:

Figure 1. 난이도별 메모리 이후 작업 목표 달성 비교 (ours vs. ACE). DeepSeek-V3.2(오른쪽)에서는 Easy, Hard, Overall에서 우리가 우위를 점하며; ACE는 Medium에서만 근소하게 앞섭니다. gpt-oss-120b(왼쪽)에서는 ACE가 Easy와 Medium에서 앞서지만, 작업별 선택 방식이 Hard 작업을 지배하고 전체 평균에서도 우위를 차지합니다. 각 시스템은 자체 메모리 없는 기준선(아래 Method notes의 난이도별 참조 표 참고) 대비 개선되었습니다.

두 모델은 다른 이야기를 들려줍니다. gpt-oss-120b에서는 ACE의 전체 플레이북이 Easy와 Medium에서 우위를 점합니다. 이는 일반적인 지침 따르기만으로 충분히 작업이 해결되기 때문에, 포괄적인 프롬프트가 방해하기보다는 더 도움이 된다는 의미입니다. 하지만 모델이 모든 내용을 헤쳐나가는 것이 아니라 올바른 교훈을 선택해야 하는 Hard 작업에서는 큐레이션된 검색(curated retrieval)이 앞서며—이것이 전체 평균을 결정하는 등급입니다. DeepSeek-V3.2에서는 이야기가 바뀝니다: 더 강력한 모델은 ACE의 전체 플레이북을 충분히 흡수하여 Medium에서 우리를 근소하게 앞지르지만, 우리는 Easy, Hard, Overall에서 우위를 점합니다—더 많은 여유 용량을 가지고 있기 때문에, 더 많은 교훈(우리가 전달하는 방식)이 서로 혼잡해지는 대신 계속 도움을 줍니다.

우리는 각 모델에 최적의 구성을 제공합니다. 즉, 강력한 모델에게는 전체 통합 세트를, 약한 모델에게는 선택적 검색을 제공하는데, 이는 큰 컨텍스트가 도움이 되기보다는 약한 모델을 압도하기 때문입니다. (얼마나 많은 정보를 주입해야 하는지, 그리고 이것이 능력 스펙트럼 전반에 걸쳐 어떻게 확장되는지가 저희 후속 게시물의 초점입니다.)

두 시스템 모두 에이전트가 어렵게 얻은 경험을 깔끔한 요약으로 압축하는 것을 거부합니다—이 부분에는 동의합니다. 차이점은 전달 방식이 고정적인지 아니면 보정(calibrated)되었는지 여부입니다: ACE는 무엇이든 매 단계마다 전체 플레이북을 보내지만, 우리는 주어진 모델이 실제로 사용할 수 있는 만큼만 가이드라인 세트를 전송합니다. 이 보정이 위의 수치를 얻게 한 핵심 요소였습니다—ACE의 추론 비용 대비 동일하거나 더 나은 정확도를 달성했으며—그리고 약한 모델에서는 도움이 되는 가이드와 방해가 되는 가이드 사이의 차이를 만들었습니다.

여기서 사용된 추출(extraction), 통합(consolidation), 검색(retrieval) 파이프라인을 포함하는 ALTK-Evolve 라이브러리를 사용해 보거나, 전체 방법론과 이상 분석(ablations)에 대한 완전한 내용을 담은 전체 기술 보고서를 읽어보세요.

이전 게시물: ALTK-Evolve 소개 — 링크 ACE(Agentic Context Engineering) — 링크 AppWorld 벤치마크 — 링크 ALTK-Evolve — 링크 전체 기술 보고서 — 링크

AppWorld test_normal

, 168개 태스크. ReAct 코드 에이전트(각 단계마다 Python 코드를 작성하고 환경이 출력을 반환함). TGC = 태스크 목표 달성(Task Goal Completion); SGC = 시나리오 목표 달성(Scenario Goal Completion)으로, 모든 시나리오 변형이 통과해야 함. 메모리는 train/dev에서만 채굴되며; 결과는 단일 실행(pass@1)입니다. 이는 이 벤치마크의 표준 방식입니다.

ACE 수치는 ALTK-Evolve와 동일한 AppWorld 분할 및 동일한 기본 모델(DeepSeek-V3.2 및 gpt-oss-120b)에서 자체적으로 평가한 ACE 에이전트의 실행 결과입니다. ACE 논문은 다른 기본 모델(DeepSeek-V3.1)을 보고하므로, 저희가 직접 실행함으로써 모델과 하드웨어 환경에 대한 비교 통제성을 유지할 수 있습니다. 두 시스템 모두 동일한 ReAct 에이전트이며 프롬프트 템플릿에서만 차이가 나기 때문에 (72.0 대 79.8 TGC로 인해 두 무메모리 기준선이 다름); 저희는 이 기준선 격차에 의존하는 것이 아니라, 프롬프트 조정으로는 건드릴 수 없는 주장, 즉 토큰 사용량을 크게 줄이면서 동일하거나 더 나은 정확도에만 초점을 맞춥니다.

DeepSeek-V3.2 — test_normal (168개 태스크):

테이블 형식의 데이터는 번역하지 않고 원문 그대로 유지합니다.