Librarian Agents: 긴 문서를 미리 정리하는 LLM 학습

배경

긴 문서 추론은 대규모 언어 모델에게 여전히 어려운 과제입니다. 흔히 쓰는 검색 증강 방식은 질문이 들어온 뒤에야 말뭉치에서 관련 구절을 찾아옵니다. 이 방식은 구조상 수동적입니다. 여러 문서의 단서를 이어 붙여야 하는 질문에서는 검색 단계가 에이전트 전체의 병목이 됩니다.

다른 길은 지식 그래프처럼 구조를 미리 계산해 두는 것입니다. 그러나 이 방식은 사람이 설계한 경직된 휴리스틱에 의존합니다. 나중에 들어올 다양한 질문에는 잘 맞지 않는 경우가 많습니다. arXiv에 공개된 이 논문은 질문을 바꿉니다. 추론이 시작되기 전에 에이전트가 방향을 잡고 말뭉치를 미리 정리해 둘 수 있을까요? 저자들은 이 접근을 anticipatory directed curation이라 부릅니다.

출발점은 Claude Code 같은 최신 에이전트 환경의 비대칭입니다. LLM 에이전트는 이미 있는 파일 시스템을 탐색해 눈앞의 작업을 끝내는 데는 능숙합니다. 하지만 앞으로 쓸 재사용 가능한 작업 공간을 직접 만들도록 훈련받는 일은 거의 없습니다. Librarian Agents는 바로 이 빈틈을 겨냥합니다.

심층 분석

Librarian Agents 프레임워크에는 두 역할이 있습니다. builder agent는 추론 전에 원문 문서를 읽고, 합성 파일과 서로 연결된 인용 링크를 담은 계층형 파일 시스템으로 바꿉니다. 하위 answering agent는 이 작업 공간에서 정보를 찾아 질문에 답합니다. builder는 단순히 글을 쪼개거나 색인을 만들지 않습니다. 사서처럼 어떤 기준으로 분류할지, 어떤 요약 파일을 쓸지, 어떤 링크로 관련 내용을 이을지 스스로 결정합니다. 강화학습으로 작업 공간 구축을 학습하면 무엇이 달라질까요? 저자들은 작업 공간 구축을 마르코프 결정 과정으로 정식화했습니다. builder가 수행하는 각 조작이 행동이고, 구축 전체가 하나의 궤적입니다. 최종 보상은 완성된 작업 공간에서 answering agent가 낸 답변 정확도에서 곧바로 나옵니다. 중간 대리 지표가 아니라 하위 정확도를 직접 최대화하도록 정책을 최적화합니다. 어떤 정리 방식이 유용한지는 사람이 쓴 규칙이 아니라 하위 과제의 결과가 판정합니다.

평가는 두 벤치마크에서 이뤄졌습니다. 여러 문서에 걸친 복잡한 추론이 필요한 BrowseComp-Plus에서는 가장 강력한 검색 베이스라인과 사전 계산 베이스라인보다 33%p 높은 성능을 보였습니다. 일반화를 보는 BRIGHT에서는 보지 못한 도메인에 제로샷으로 적용했는데도 평균 정확도가 31%p 올랐습니다. builder가 특정 말뭉치용 요령이 아니라 비교적 범용적인 정리 능력을 익혔다는 뜻으로 읽힙니다. 비용도 중요합니다. 작업 공간을 만들려면 초기 투자가 필요하고, 그 값어치는 얼마나 많은 질의가 비용을 나눠 지느냐에 달려 있습니다. 논문은 초기 구축 비용을 반복 질의에서 분산해 회수할 수 있다고 보고합니다. 같은 말뭉치를 자주 물을수록 먼저 정리하고 나중에 답하는 방식이 유리해집니다. 초록에는 세부 소거 실험이 없어서, 각 설계 선택의 기여도는 이 글에서 판단하지 않습니다.

산업 영향

이 연구는 에이전트 시스템에서 놓치기 쉬운 단계를 짚습니다. 지식을 정리하는 일과 쓰는 일을 분리할 수 있고, 정리 단계 자체를 학습시킬 수 있다는 점입니다. 지금까지 고정된 파이프라인이 맡던 문제를 다시 보게 만듭니다.

현장에는 기술 문서, 사례 모음, 연구 자료처럼 비교적 안정적이고 반복해서 조회되는 문서 묶음이 많습니다. 이런 환경에서는 builder가 한 번 비용을 들여 계층형 작업 공간을 만들고 answering agent가 이를 재사용하는 편이, 질문마다 즉석에서 검색하는 것보다 매력적일 수 있습니다. 구축 비용을 반복 질의로 회수할 수 있다는 보고가 이 추론을 뒷받침합니다.

연구 측면에서는 작업 공간 구축을 강화학습 문제로 보고 하위 정확도를 보상으로 쓰는 틀이 분명해졌습니다. 에이전트 메모리, 장기 컨텍스트 관리, 지식 베이스 자동 유지에 바로 이어 볼 수 있습니다. 다만 결과는 두 벤치마크에 한정됩니다. 실제 업무 말뭉치는 규모, 갱신 빈도, 잡음이 다를 수 있어 현장 검증이 필요합니다.

전망

다음 질문은 유지 관리에 있습니다. 한 번 만든 작업 공간은 어느 시점의 스냅샷입니다. 원문이 자주 바뀌면 구축 비용이 되풀이되어 분산 회수 논리가 약해집니다. 새 문서가 들어올 때 파일 시스템을 증분 갱신할 수 있는지가 실사용 가능성을 가늠할 시험대가 될 것입니다.

BRIGHT의 제로샷 결과가 어디까지 이어지는지도 열린 문제입니다. 미지의 도메인에서 평균 31%p 향상은 고무적입니다. 구조, 규모, 잡음 수준이 크게 다른 말뭉치에서도 builder의 정리 능력이 유지되는지 확인해야 합니다. 초록에는 손익분기점 수치도 없으므로, 도입을 고민하는 팀은 자신의 질의량과 구축 부담을 직접 재 봐야 합니다.

그럼에도 이 방향은 지켜볼 가치가 있습니다. 에이전트가 미래의 자신과 다른 에이전트를 위해 자료를 미리 준비하도록 가르치면, 문서 처리는 검색 문제에서 학습 가능한 준비 단계로 바뀝니다.