질문이 오기 전에 문서를 정리하는 AI 사서, Librarian Agents

배경과 문제

긴 문서 묶음에서 질문에 답하려면 정보가 여러 문서에 흩어져 있어 매번 처음부터 다시 찾아야 한다. 논문에서 대조하는 전형적인 검색 증강 생성(RAG)은 질문이 들어올 때마다 원문을 검색하고 관련 구절을 합성하는 '반응형' 방식이라, 질문마다 유용한 문서 간 관계를 다시 발견해야 하는 비용이 든다. 개체 추출 규칙에 기반한 지식 그래프 등의 사전 구조화는 미리 색인을 만들지만 개체 추출 같은 고정된 규칙에 의존해, 질문이 색인과 정확히 맞지 않으면 새로운 중간 산출물이 필요한 경우에 부자연스럽다.

이 논문은 질문을 보기 전에 문서 묶음을 '미래 질문을 예측하는 작업 공간'으로 재구성하는 '선제적 큐레이션'을 제안한다. 현대 에이전트 시스템에서 LLM은 기존 파일시스템을 탐색해 즉각적인 과제를 푸는 데는 능숙하지만, 미래에 재사용할 작업 공간을 미리 구축하도록 훈련된 경우는 드물다는 비대칭성에 주목한다. 빌더 에이전트가 원문을 합성 파일과 참조 링크로 이루어진 계층적 파일시스템으로 변환하고, 이후 답변 에이전트가 그 작업 공간을 탐색해 질문에 답한다.

기존 접근의 한계

반응형 RAG는 질문마다 검색을 새로 수행하므로, 같은 문서 묶음에 대해 반복되는 질문이 많으면 계산 비용이 누적된다. 에이전트 RAG는 질문 시점에 검색과 추론을 동적으로 섞지만 여전히 질문을 받은 후에만 복잡한 검색을 시작한다. 여기서 비교한 지식 그래프나 RAPTOR 같은 사전 구조화는 유용하지만 개체 추출이나 요약 규칙이 고정되어 있어, 질문 분포가 색인과 어긋나면 성능이 떨어진다.

자동 압축(AutoCompaction)은 문서 스트림을 질문 독립적인 노트로 압축하지만, 이 논문의 실험에서는 BrowseComp-Plus 정확도가 0.04로 매우 낮았다. 표 1에서 GraphRAG는 정확도 0.36, 자동 압축은 0.04인 반면, RL로 훈련한 Librarian은 0.77을 기록했다. 이는 이 실험에서 학습된 빌더가 더 높은 정확도를 얻었다는 뜻이다. 각 방식의 구축 토큰 사용량도 다르므로 같은 계산량에서 구조화 방식만 바꾼 비교로 읽어서는 안 된다.

연구방법을 단계별로

작업 공간 구축은 유한 지평 마르코프 결정 과정(MDP)으로 형식화된다. 상태는 현재 파일시스템이고, 빌더 에이전트는 네 가지 행동 중 하나를 선택한다. CreateFile은 원문 일부를 통합해 출처 링크가 있는 합성 파일을 만들고, MergeFiles는 관련 합성 파일을 묶어 상위 요약이나 디렉터리형 산출물을 만든다. Delete는 중복되거나 불필요한 합성 파일만 제거하며 원문은 절대 삭제하지 않아 폴백 경로를 보존한다. Stop은 구축을 끝내고 현재 파일시스템을 최종 작업 공간으로 반환한다.

보상은 답변 정확도에서 탐색 비용과 구축 비용을 빼는 형태로 정의한다. 주실험에서는 비용 가중치를 모두 0으로 두어 정확도만 최적화했다. 이상적으로 매 편집 전후의 효용 차이를 보상으로 주고 미래 보상을 할인하지 않으면, 중간 항들이 상쇄되어 마지막 효용을 높이는 목표와 같아진다. 하지만 실제 학습은 평가 비용을 줄이려고 8턴마다 최대 4번 답변 가능성을 조사하고, 연속 조사 간 정확도 변화와 마지막 정답 보상을 합친다. 논문은 이를 실용적인 대리 목표라고 구분하며, 매 편집을 평가하는 이상적 보상과 그대로 같은 절차는 아니다.

빌더는 Qwen3.5-4B를 GRPO로 미세조정한다. LoRA rank 32, 학습률 4×10⁻⁵, 배치 크기 8, 롤아웃 그룹 크기 4, 최대 32턴, 턴당 1024토큰, 전체 궤적 60K 토큰 한도다. 680개 문서 묶음 과제로 훈련하고, 보지 않은 50개 과제로 평가한다. 빌더가 미래 질문을 직접 보지는 않지만 학습 질문에 대한 답변 결과가 보상에 쓰인다. CreateFile과 MergeFiles의 내용은 고정된 Qwen3.5-35B-A3B 실행기가 작성하고, 긴 빌더 이력은 고정된 Gemini 3.1 Flash Lite가 압축한다. 고정된 답변 에이전트와 평가자로 빌더 정책들을 비교하되, 공통 한도가 실제 토큰 소비량까지 같다는 뜻은 아니다.

결과와 숫자의 의미

BrowseComp-Plus에서 Librarian Agents는 Qwen3.5-4B 답변 에이전트 기준 정확도 0.75로, 가장 강한 Reranker 기준 0.44보다 31%p 높았다. Gemini 3.1 Flash Lite 답변 에이전트 기준으로는 0.77로, 기준 0.42보다 35%p 높았다. RL 파인튜닝 없이 빌더를 쓰면(noFT) 정확도가 0.25~0.28에 그쳐, 이 설정에서 RL 학습이 빌더의 성능을 높였음을 보여준다. 다른 학습법이나 구조화 방식으로는 불가능하다는 증거는 아니다.

표 1에서 Librarian의 초기 구축 토큰은 178,926으로 noFT의 127,683보다 많지만 정확도는 0.77 대 0.28로 크게 높다. 표 2의 50개 문서 묶음, 443개 고정 합성 질문 평가에서는 정확도 0.637±0.029 대 0.242±0.036, 답변당 토큰 9,346 대 1,238, 파일 수 26.9 대 2.72였다. 즉 더 정확하지만 질문당 원시 토큰은 더 많이 읽는다. 10질문/문서묶음에서 기대 정답 1개당 기록 토큰은 33.8% 감소(RL/Base 비율 0.662, 95% CI 0.504~0.836)했는데, 이는 정확도로 정규화한 비용이며 실제 요금이나 지연 시간 절감이 아니다.

BRIGHT 전이 평가에서는 BrowseComp로만 훈련한 빌더가 AOPS, Biology, Stack Overflow 각 50문항, 총 150문항에서 pass@1 평균 52.0%±2.8, pass@3 추정 66.8%±3.4를 기록했다. 가장 강한 Dense 기준은 pass@1 20.8%, pass@3 28.0%였다. 영역별 차이가 커서 Stack Overflow는 85.5%인 반면 AOPS는 36.0%, Biology는 34.5%였다. 이는 원래 BRIGHT 검색 지표가 아니라 생성 QA로 변환한 평가이며, 전체 BRIGHT 벤치마크를 검증한 것은 아니다. 각 영역마다 작업 공간 하나를 만들어 질문들에 재사용하고, 질문당 독립 응답 4개를 생성해 pass@1과 pass@3을 추정했다.

구체적인 예시

논문은 기업의 설계 문서, 이슈 스레드, 출시 노트, 고객 보고서 묶음을 설명용 가상 사례로 든다. 빌더가 출시 타임라인, 컴포넌트별 설계 색인, 고객에게 보이는 동작 요약을 만들고 같은 원문을 서로 다른 각도에서 연결하는 구상이다. 이렇게 미리 정리하면 구현 세부사항이나 버전 간 동작 변화, 논쟁 중인 주장의 출처를 더 짧은 경로로 찾도록 도울 수 있다. 이 기업 사례를 실제 배포하여 효과를 측정한 결과는 아니다.

그림 7은 합성 파일이 필요한 세부사항을 빠뜨린 경우를 보여준다. BrowseComp+ 질문에 필요한 세부사항이 합성 계층에 없자, 답변 에이전트가 출처 링크를 따라 원문 파일로 이동해 전체 비정형 말뭉치를 일일이 훑지 않고 정답을 복구했다. 원문 복귀가 작동한 한 사례이며, 모든 정보 누락을 자동으로 해결한다는 보장은 아니다.

한계와 오해하기 쉬운 점

이 평가는 정적 문서 묶음에 대한 질문 응답에 국한된다. 문서가 변경될 때 작업 공간을 갱신하는 문제는 미해결이다. 빌더가 큰 파일 컨텍스트 위에서 동작하므로 확장성에 한계가 있고, 클러스터링이나 검색과 결합하면 더 큰 도메인으로 확장할 수 있을 것이라고 논문은 제안한다. 합성 파일이 모든 질문을 예측할 수 없으므로 압축이 바늘 찾기(needle-in-a-haystack) 질문에 필요한 세부사항을 버릴 수 있고, 언제 원문으로 폴백할지 결정하는 것은 여전히 어려운 문제다.

숫자를 해석할 때 평가 조건을 구분해야 한다. 표 2는 50개 문서 묶음의 443개 질문으로 실패도 포함한다. 표 7은 작업 공간이 완성된 49개 묶음의 435개 질문에서 답변을 새로 생성한 별도 비교다. 표 7의 원형 정확도 55.86%, 평탄화 57.70%, 섞기 51.72%를 표 2의 0.637과 직접 비교할 수 없다. 평탄화의 탐색 토큰은 원형의 3,635에서 5,497로 늘었다. 계층 구조가 항상 정답률을 최대화하지는 않으므로 정확도와 탐색 효율을 함께 봐야 한다. 코드와 로그는 공개 예정이라고 되어 있어 공개 완료로 단정하지 않는다.

실제로 어떻게 활용할까

같은 정적 문서 묶음에 반복 질문하는 지식 베이스는 후속 검증을 해볼 응용 후보이다. 그렇다고 질문당 원시 계산량이 줄어드는 것은 아니다. 20질문에 구축 비용을 나눠 더하면 질문당 약 18K 토큰이라는 가상 계산이 나오지만, RL의 원시 토큰은 비교 빌더보다 계속 높다. 정확도로 나눈 기대 정답당 토큰에서는 초기 이점이 있으나 재사용이 늘수록 그 이점이 줄어, 추정 교차점은 약 31질문이며 불확실성 구간은 18~54질문이다. 따라서 31질문을 넘으면 더 저렴해진다는 뜻으로 해석하면 방향이 거꾸로다. 이는 실제 요금이나 지연 시간의 손익분기점도 아니다.

다만 실제 도입 시에는 문서 변경 시 작업 공간 갱신, 대규모 컨텍스트 처리, 압축 누락 시 폴백 전략을 먼저 해결해야 한다. 논문은 향후 작업으로 자신의 트래픽에서 학습해 파일시스템을 갱신하는 방안과, 현재 네 가지 행동을 원자적 파일시스템 명령으로 일반화하는 방안을 제안한다. 현재는 정적 말뭉치 QA에만 검증되었으므로 동적 환경에 바로 적용하기는 어렵다.