LLM이 미래 질의를 예상해 문서 코퍼스를 파일시스템으로 미리 재구성한다
Librarian Agents: Training LLMs to Curate Long-Context Workspaces that Anticipate Future Queries
무엇인가
기업 지식베이스, 대형 코드 저장소, 사용자 대화 기록처럼 컨텍스트 윈도우를 넘는 코퍼스를 다루는 일이 늘었지만, 필요한 정보는 한곳에 모여 있지 않고 여러 문서에 흩어져 있다. 표준적인 RAG는 질의가 들어올 때마다 원문을 검색하고 관련 구절을 가져와 답을 합성한다. 문제는 이 방식이 철저히 반응적(reactive)이라는 점이다. 질의마다 검색을 새로 돌리므로, 문서 간 관계를 매번 처음부터 다시 발견해야 한다. 지식 그래프처럼 미리 구조를 만들어 두는 방법도 있지만, 개체명 추출 같은 고정된 휴리스틱과 스키마에 묶여 새로운 형태의 질의에는 잘 대응하지 못한다. 이 논문이 파고드는 지점은 현대 에이전트 하네스(예: Claude Code)의 비대칭성이다. LLM 에이전트는 이미 존재하는 파일시스템을 탐색해 당면 과제를 푸는 데는 능숙하지만, 미래에 쓸 재사용 가능한 워크스페이스를 스스로 구축하도록 훈련된 적은 거의 없다.
어떻게 동작하나
Librarian Agents는 이 비대칭성을 메우는 프레임워크다. 빌더 에이전트가 원본 문서 집합을 계층적 파일시스템으로 변환한다. 이 워크스페이스에는 원문에서 합성한 파일들과 원본 코퍼스로 되돌아가는 참조 링크가 함께 담긴다. 이후 동결된(frozen) 답변 에이전트가 사용자 질의를 받으면, 원문 더미 대신 이 워크스페이스를 탐색해 근거를 찾는다. 저자들은 좋은 예측적 워크스페이스의 조건으로 세 가지를 든다. 첫째, 많은 질의를 커버하면서 짧은 경로로 도달 가능해야 한다(예: 추상화 수준별 디렉터리). 둘째, 합성 파일이 놓친 세부 정보를 확인할 수 있도록 원문 경로와 참조 링크를 반드시 보존해야 한다. 셋째, 구축 비용이 여러 질의에 걸쳐 상각되어야 한다. 한 번의 질의에만 쓰이는 답변 초안은 이 조건을 만족하지 못한다.
무엇과 다른가
방법론의 핵심은 워크스페이스 구축을 유한 지평 마르코프 결정 과정(MDP)으로 정식화한 것이다. 상태는 현재 파일시스템이고, 빌더의 행동은 CreateFile(원문·기존 합성 파일을 통합해 새 합성 파일 생성, 출처 링크 포함), MergeFiles(관련 파일들을 상위 요약·디렉터리로 병합해 계층 도입), Delete(중복·무용한 합성 파일 제거, 원본 문서는 절대 삭제하지 않음), Stop(구축 종료) 네 가지로 제한된다. 보상은 최종 파일시스템의 다운스트림 유틸리티에서 구축 비용을 뺀 희소 보상과, 각 편집의 한계 기여도를 계산하는 밀집 보상 두 가지로 정의된다. 할인율 1에서 두 보상은 텔레스코핑되어 동치가 되며, 이는 잠재 기반 보상 셰이핑(potential-based reward shaping)과 같은 형태다. 실제 학습에서는 매 편집마다 답변 가능성을 평가하는 비용을 피하기 위해 8턴마다 답변 가능성을 프로브하고, 그 변화량과 최종 정답 여부를 결합한 대리 목적함수를 쓴다. 정책 최적화는 GRPO로 수행하며, 주 실험에서는 탐색 비용·구축 비용 가중치를 모두 0으로 두어 정확도만 최적화한다. 답변 에이전트는 기본적으로 고정해, 빌더가 '답변 에이전트에게 유용한 기억'을 만드는 법만 학습하도록 문제를 분리했다.
어떻게 쓰나
인도메인 평가는 BrowseComp-Plus(학습 680개 과제, 평가 50개 홀드아웃)에서 이뤄졌다. Qwen3.5-4B를 동결 답변 에이전트로 쓸 때 Librarian Agents는 정확도 0.75를 기록해 임베딩 베이스라인 0.42, 리랭커 0.44를 크게 앞섰다. Gemini 3.1 Flash Lite에서는 0.77 대 0.30, 0.42였다. RL 파인튜닝을 뺀 절제 실험은 이보다 낮은 성능을 보였고, 저자들은 베이스 모델이 훈련받지 않은 과제인 만큼 정책 최적화가 필수적이라고 해석한다.
전제와 한계
상각 효과도 수치로 제시된다. 문서 집합 하나가 여러 질의를 서비스하도록 확장한 실험에서 구축 선행 비용은 179K 토큰, 정확도는 0.77이었고 비교 대상은 0.36과 0.04였다. 50개 문서 집합에 걸친 443개의 동결 합성 질의(집합당 7~10개)에서는 정확도 0.64 대 베이스 빌더 0.24, 질의당 답변 시점 비용 9.3K 토큰이었다. 문서 집합당 20개 질의를 가정하면 구축 비용을 나눠 질의당 약 18K 토큰으로 추정된다. 정확도로 정규화하면 질의 10개 기준 기대 정답당 기록 토큰이 33.8% 적다(RL/Base 비율 0.662, 95% 신뢰구간 [0.504, 0.836]). 학습 분포를 벗어난 BRIGHT(3개 도메인, 도메인당 50문항, 도메인당 파일시스템 1개) zero-shot 평가에서는 pass@1 0.52, pass@3 0.67을 기록했고, 초록 기준 평균 31%포인트 향상이다. 구조 통계도 달라졌다. 학습된 빌더는 평균 53.4개의 활성 합성 파일을 45.4개 클러스터와 8.0개 병합 산출물로 조직했지만, 베이스 정책은 4.8개 파일, 4.2개 클러스터, 0.6개 병합에 그쳤다.
개발자 관점에서 이 논문이 바꾸는 것은 '검색 인덱스를 어떻게 만들 것인가'라는 질문의 성격이다. 인덱스나 지식 그래프를 사람이 정한 스키마로 고정하는 대신, 다운스트림 정답률을 보상으로 코퍼스 구조 자체를 학습시키는 발상이다. 문서 집합이 고정되어 있고 그 위로 질의가 반복해서 들어오는 서비스, 예컨대 사내 문서 검색이나 장기 운영되는 코드베이스 질의응답에서는 선행 구축 비용을 여러 질의로 나눌 수 있다는 전제가 성립할 때 특히 매력적이다. 다만 답변 에이전트를 동결한 상태에서 빌더만 최적화했다는 점, 그리고 합성 파일이 원문 링크를 유지한다는 설계를 실제 파이프라인에서 어떻게 강제할지가 도입 시 확인할 지점이다.
저자들이 밝힌 한계는 분명하다. 평가가 정적 코퍼스에 대한 질의응답에 국한되며, 문서가 계속 바뀌는 상황에서 예측적 기억을 유지하는 것은 미해결 문제다. 빌더 에이전트가 방대한 파일 컨텍스트 위에서 동작하므로 확장성에 제약이 있고, 클러스터링이나 검색을 결합해 완화할 수 있다고 제안한다. 또한 유한한 합성 산출물로 모든 질의를 예상할 수는 없어, 압축 과정에서 needle-in-a-haystack 유형의 국소적 세부 정보가 사라질 수 있다. 참조 링크로 폴백 경로는 남겨두지만, 언제 합성 파일시스템을 우회할지 판단하는 것은 여전히 과제다. 향후 과제로는 답변 트래픽 자체로 파일시스템을 갱신하는 방식과, 현재 네 가지로 제한된 행동을 원자적 파일시스템 명령 조합으로 일반화하는 것을 꼽는다.