Microsoft의 FastContext에 대한 노트, 그리고 retrieval hints를 활용한 작은 SWE-QA 실험

지난주 Microsoft의 FastContext 논문에 관한 게시물이 있었습니다: https://www.reddit.com/r/LocalLLaMA/comments/1ud1lro/why_is_no_one_talking_about_microsofts_open/ 저는 제 개인 설정으로 관련 벤치마크를 실행해보고 싶다고 댓글을 남겼습니다. 이것이 그 후속 작업입니다. 이것은 FastContext와의 직접적인 비교는 아닙니다. 에이전트(agent), 하네스(harness), 그리고 토큰 계산 방식이 다르기 때문입니다. 그 이유는 아래에 명확히 설명되어 있습니다.

요약(TL;DR): FastContext는 저장소 탐색(repo exploration)을 메인 솔버(solver)에서 분리함으로써 메인 에이전트의 컨텍스트(context) 비용을 절감할 수 있음을 보여줍니다. 저는 SWE-QA에서 더 단순한 retrieval-hint(검색 힌트) 버전을 시도했습니다: 저장소를 오프라인으로 인덱싱하고, Claude Code에 짧은 파일/범위 힌트를 제공한 뒤, 동일한 에이전트가 정상적으로 답변하게 하는 방식입니다. 720개의 쌍으로 된 샘플을 대상으로 테스트한 결과, GPT-5.4 판정(judge) 점수는 본질적으로 변하지 않으면서 총 토큰 수는 43.8% 감소했습니다.

FastContext에 대한 나의 해석
FastContext는 코딩 에이전트를 위한 경량 저장소 탐색 서브 에이전트(subagent)입니다.
동기는 명확합니다: 코딩 에이전트는 작업을 해결하기 전에 저장소를 탐색하는 데 많은 토큰을 소비합니다. 읽기(reads), grep, 광범위한 파일 스캔 등이 솔버의 컨텍스트에 포함되며, 그 컨텍스트는 계속해서 유지됩니다. FastContext는 이러한 탐색 과정을 별도의 탐색기(explorer)로 이동시킵니다.

FastContext 결과
핵심 주장들에 대한 저의 해석은 다음과 같습니다:

• 저장소 탐색을 해결(solving) 과정에서 분리할 수 있다.
• 메인 에이전트가 직접 광범위한 저장소 탐색을 수행하는 대신 압축된 파일/라인 증거를 받는다면, 메인 에이전트의 토큰 사용량이 크게 줄어든다.
• 그들이 학습시킨 4B-30B 탐색 모델은 실험에서 대략 프런티어 모델(frontier-model) 수준의 저장소 탐색 능력을 제공할 수 있다.

중요한 세부 사항은, 해당 표에서 논문이 메인 에이전트 궤적(trajectory)의 토큰/턴(tokens/turns)을 보고했다는 점입니다. 따라서 탐색기의 내부 모델 호출은 해당 토큰 수에 포함되지 않았습니다. 이는 "프런티어 솔버가 유지해야 할 컨텍스트가 얼마나 되는가?"라는 질문에는 합리적인 지표이지만, 전체 시스템 토큰과 동일하지는 않습니다.
한 가지 주의할 점은, FastContext는 SWE-QA에 대해 자체적인 이진 정확도 판정기(binary correctness judge)를 사용한다는 것입니다.

그들이 왜 SWE-QA의 공식 5차원 판정 스크립트 (five-dimension judge script)를 사용하지 않았는지는 알 수 없으나, 이는 점수 단위가 공식 SWE-QA 점수와 다르다는 것을 의미합니다.

나의 접근 방식
나는 다르고 더 단순한 해결책을 테스트했습니다.
탐색 에이전트 (explorer agent)를 훈련하거나 실행하는 대신, 시맨틱 검색 엔진 (semantic search engine)인 Attemory를 사용하여 저장소 (repo)에 대한 오프라인 검색 인덱스 (offline retrieval index)로 활용했습니다. 각 SWE-QA 실행 전에, 러너 (runner)는 깨끗한 벤치마크 질문을 사용하여 인덱싱된 저장소에 쿼리를 보냈습니다. 관련 파일과 라인 범위는 힌트 (hint)로서 프롬프트 (prompt)에 추가되었습니다.
또한 Mini-SWE-Agent 대신 Claude Code를 사용하여, 베이스라인 (baseline)이 연구용 하네스 (research harness)가 아닌 더 완전한 프로덕션 코딩 에이전트 하네스 (production coding-agent harness)를 사용할 수 있게 함으로써 실제 일상적인 사용에 더 가깝게 만들었습니다.
에이전트는 힌트를 무시할 수 있었습니다. 여전히 Read, Grep, Glob, Bash, Task를 사용할 수 있었고, 서브 에이전트 (subagents)를 실행할 수도 있었습니다. 벤치마크는 읽기 전용 (read-only)이었으며 웹/외부 지식을 허용하지 않았습니다. 이는 벤치마크 자체의 제한 사항이었으며, Attemory 실행을 위해 추가된 추가 제한 사항은 아니었습니다.

설정은 다음과 같았습니다:
베이스라인 (Baseline): CC + 읽기 전용 도구 (read-only tools) + DeepSeek v4
Attemory: CC + 읽기 전용 도구 (read-only tools) + DeepSeek v4 + 실행 전 검색 힌트 (one pre-run retrieval hint) 1개

판정기 (judge)는 openai/gpt-5.4로 실행된 공식 SWE-QA 5차원 LLM-as-judge 스크립트였습니다.

결과
SWE-QA에서 이 실험은 15개의 저장소와 720개의 쌍으로 된 샘플을 다루었습니다.

Attemory 결과
따라서 토큰 감소 (token drop)는 단순히 탐색 (exploration)을 메인 컨텍스트 (main context) 외부로 옮겼기 때문만은 아닙니다. 이번 실행에서는 메인 에이전트 토큰 (main-agent tokens)과 서브 에이전트 토큰 (subagent tokens)이 모두 감소했습니다.
품질 결과는 이 판정기 하에서 기본적으로 무승부입니다: 83.39 대 83.17.

FastContext와의 차이점
이 부분이 구분이 유용하다고 생각되는 지점이지만, 다시 말하지만 직접적인 벤치마크 비교는 아닙니다.
FastContext의 경로는 다음과 같습니다:
저장소 탐색기 (repository explorer) 훈련/실행 -> 탐색기가 증거 발견 -> 해결사 (solver)가 답변

내가 테스트한 설정은 다음과 같습니다:
저장소를 한 번 인덱싱 -> 유력한 증거 검색 -> 동일한 해결사가 답변

이는 주장해야 할 내용(what needs to be claimed)을 변화시킵니다.

FastContext를 사용하면 결과의 일부가 동일 모델(same-model) 또는 프런티어 모델(frontier-model)의 탐색을 대체할 수 있을 만큼 충분히 우수한 훈련된 탐색기(trained explorer)에 의존하게 됩니다. 반면 retrieval-hint 설정에서 Attemory는 두 번째 해결사(solver)도 아니고 훈련된 코드 탐색기도 아닙니다. 이는 단지 힌트(hint)만을 제공할 뿐입니다. 최종 답변은 여전히 동일한 다운스트림 코딩 에이전트(downstream coding agent)로부터 나옵니다.

다른 두 가지 차이점도 주목할 만한 가치가 있습니다:

1. 코드 탐색기(Code explorer) vs 일반 메모리 검색(general memory search)
   FastContext는 코딩 에이전트를 위한 특화된 리포지토리 탐색기(repository explorer)입니다. 작업(task)마다 온라인으로 탐색하며 압축된 코드 증거(code evidence)를 반환합니다.
   Attemory는 더 일반적인 메모리 검색 계층(memory retrieval layer)입니다. 이 실험에서는 리포지토리 코드에만 사용했지만, 동일한 메커니즘은 코드, 문서(docs), 긴 대화, 작업 이력(task history), 사용자 메모리 및 기타 롱 컨텍스트(long-context) 소스를 대상으로 설계되었습니다. 또한 한 번 인덱싱(indexing)하면 여러 번 검색할 수 있습니다. 리포지토리는 오프라인으로 수집(ingested)되어 재사용 가능한 세션으로 저장되며, 여러 SWE-QA 질문에 걸쳐 재사용됩니다.

2. 온라인 디코딩(Online decode) vs 프리필 전용 검색(prefill-only retrieval)
   FastContext의 탐색기는 여전히 온라인 에이전트 루프(agent loop)입니다. 도구 호출(tool calls)을 생성하고, 파일을 읽고, 출력을 검사하며, 인용(citations)을 반환합니다. 더 작은 훈련된 탐색기를 사용하더라도, 탐색 경로에는 여전히 토큰 단위의 디코딩(token-by-token decoding)이 포함됩니다.
   Attemory 검색은 프리필 전용(prefill-only)이며 디코딩이 필요 없습니다(decode-free). 도구 호출, 중간 추론(intermediate reasoning) 또는 파일 검색 트랜스크립트를 토큰 단위로 생성할 필요가 없습니다. 인덱싱된 메모리가 복원되면, 쿼리가 해당 메모리 상태에 대해 프리필(prefill)로 실행되고 검색 결과가 직접 반환됩니다. 해결사(solver)는 여전히 증거를 검증하고 질문에 답해야 하지만, 로컬라이제이션(localization) 단계는 또 다른 에이전트 실행이 아닌 빠른 검색 작업(retrieval operation)이 됩니다.

작은 홍보: Attemory는 아직 초기 단계입니다. 특히 매우 큰 리포지토리에서의 검색 성능은 여전히 더 많은 작업이 필요합니다. 관심이 있으시다면, 여러분의 워크플로에서 직접 사용해 보시는 것을 환영합니다. 이슈(Issues) 제보도 환영합니다.
submitted by /u/langsfang
[link] [comments]