반복되는 엔티티를 앵커로 삼아 코퍼스를 탐색 지도로 바꾼다

무엇인가

이 논문이 푸는 문제는 대규모 문서 컬렉션 위에서 답을 만들려면 여러 문서에 흩어진 근거를 연결해야 한다는 것이다. 예를 들어 프로젝트의 승인은 메일 한 곳, 요구사항은 운영 문서, 최신 상태는 트래커, 최종 결정은 회의록에 나뉘어 있고, 각 출처는 답의 일부만 담으며 어느 문서에도 그 관계가 명시되지 않는다. 기존 RAG는 질의에 대한 top-k 문서를 한 번 고정해 가져오고, 에이전트 검색은 전체 코퍼스를 여러 단계로 반복 검색하지만, 코퍼스가 평평한 파일 모음으로 노출되면 관련 문서를 찾아도 그것이 다른 문서와 어떻게 연결되는지 알 수 없다. 그 결과 에이전트는 매 질의마다 관계를 스스로 재발견해야 하고, 보완 근거를 놓치면서 토큰을 크게 소모한다. 저자들은 이를 코퍼스 항해 문제로 규정하고, 질의와 무관하게 미리 식별 가능한 재사용 구조를 노출하는 영속적 항해 계층이 필요하다고 주장한다.

어떻게 동작하나

제안 방법인 CorpusMap은 문서에 반복 등장하는 엔티티(사람, 프로젝트, 제품, 사고 등)를 항해 앵커로 삼는 엔티티 중심 계층이다. 오프라인에서 네 단계로 구축한다. 카탈로깅 단계에서는 어떤 엔티티 타입을 추출할지가 코퍼스마다 다르므로 LLM이 샘플 문서들로 후보 카탈로그를 만들고 이를 합쳐 검증·수정해 이름, 정의, 동일성 기준, 관찰 예시를 담은 카탈로그를 코퍼스에서 유도한다. 추출 단계에서는 이 카탈로그와 문서 문맥으로 엔티티 멘션을 식별·타이핑하고, 한 문서 안에서 같은 대상을 가리키는 것들을 문서 지역 엔티티로 묶는다. 해석 단계에서는 각 이름을 원문 출현 위치에 접지한 뒤, 비어 있는 공유 레지스트리에 대해 문서별 지역 엔티티를 순서대로 대조해 기존 항목에 연결(LINK)할지, 새 엔티티를 추가(ADD)할지, 미해결(UNRESOLVED)로 둘지 판정한다. 렌더링 단계에서는 두 개 이상 문서에 연결된 교차문서 엔티티만 유지하고, 각 엔티티를 Entity Page로 렌더링한다. 형식화하면 엔티티 노드 집합과 문서 노드 집합, 그리고 각 엔티티를 그것을 언급한 문서 이웃에 잇는 링크로 이루어진 이분 그래프 G=(E∪D, L), L={(e,d) | e∈E, d∈N(e)}다. Entity Page에는 간단한 개요, 출처 문서가 태그된 핵심 사실들, 해당 엔티티가 등장하는 여러 이름, 이웃 문서 전체로의 링크가 담긴다. 페이지는 원본 문서 옆에 파일로 저장되므로 에이전트는 raw 코퍼스와 같은 셸 도구로 읽고 검색할 수 있고, 질문과 함께 관련 Entity Page에 연결된 문서 경로가 후보로 주어지면 페이지에서 문서로, 문서에서 그 문서를 나열한 페이지로 양방향으로 링크를 따라간다. 문서를 대체하는 것이 아니라 위에 얹는 계층이라는 점이 중요하다.

무엇과 다른가

실험은 근거가 여러 문서에 분산된 질문을 담은 세 벤치마크에서 수행했다. EnterpriseRAG-Bench의 전부 멀티문서인 질문 80개(문서 2,819개), WixQA의 멀티문서 질문 79개(기사 6,221개 전체), HERB의 콘텐츠 기반 질문 238개(문서 6,365개)를 쓴다. 모델은 GPT-5.5와 GPT-5.6 Luna·Terra·Sol, DeepSeek-V4-Pro, MAI-Thinking-1, 오픈웨이트 Qwen3.8-27B까지 7개이며, LLM 판정 지표에는 GPT-5.6 Sol을 쓴다. 평가축은 답변 품질(정확성·완전성·사실성·내용), 검색 품질(문서 재현율·문맥 재현율), 효율(질문당 궤적 전체의 누적 입력 토큰)이다. 비교 대상은 Raw Corpus, Document Page, Group Page, LLM Wiki, Corpus2Skill, 그리고 이상적 검색 상한을 보여주는 Gold Documents(Oracle)와 BM25·dense retrieval·HippoRAG·GraphRAG다.

어떻게 쓰나

결과적으로 CorpusMap은 모든 벤치마크와 모든 LLM에서 최고의 답변·검색 품질을 기록했다. raw 코퍼스 에이전트 검색 대비 전체 품질이 6.4~11.7점 향상되면서 평균 입력 토큰은 34~57% 줄었고, 토큰 절감 폭은 가장 비싼 두 모델인 GPT-5.5와 GPT-5.6 Sol에서 가장 컸다. 코퍼스를 다른 단위로 조직하는 네 개의 항해 계층 베이스라인은 Raw Corpus를 일관되게 앞서지 못했는데, 저자들은 이것이 항해 계층을 붙이는 것만으로 개선이 보장되지는 않는다는 증거라고 본다. CorpusMap은 비교 불가능한 Oracle과의 격차도 상당히 좁혔고, 단일 문서에 근거한 질문이 대부분인 EnterpriseRAG-Bench의 나머지 질문에서도 더 적은 토큰으로 Raw Corpus를 앞섰다. DeepSeek-V4-Pro와 MAI-Thinking-1에서도 최고 품질을 냈고, 검색 후 고정 문맥만으로 답하는 패러다임의 BM25, dense retrieval, HippoRAG, GraphRAG보다도 우수했다.

전제와 한계

실무적으로 중요한 분석도 여럿 제시된다. 맵 구축은 1회 비용이며 이후 모든 질의가 공유하는데, 구축 비용을 질의 수로 나눠 더하면 처음에는 Raw Corpus보다 비싸지만 질의가 늘수록 낮아져 특정 질의 수를 넘으면 더 저렴해진다. 맵 재사용성도 확인됐는데, 가장 저렴한 LLM이 만든 맵조차 모든 답변 LLM에서 Raw Corpus보다 전체 품질을 올렸다. 즉 한 번 싸게 만들어 강한 모델로 재사용할 수 있다. 증분 갱신에서는 기존 레지스트리를 재사용하고 연결 문서가 바뀐 Entity Page만 다시 렌더링해 전체 재구축 대비 상당한 토큰을 아꼈고, 갱신마다 품질이 전반적으로 향상됐으며 최종 맵은 같은 문서에 대한 전체 재구축과 비슷한 성능을 냈다. 갱신으로 근거가 편입된 질문은 원래 raw 코퍼스에서도 검색 가능했음에도 개선됐는데, 이는 새 문서를 맵에 넣는 것이 단순 접근성 이상의 의미를 가진다는 뜻이다. LLM 없이 GLinker(GLiNER 계열 모델)로 추출·링크하고 Entity Page를 LLM 호출 없이 렌더링한 맵도 LLM 구축 맵과 비슷한 효과를 냈고 모든 지표에서 더 낮은 비용으로 Raw Corpus를 앞섰다. 방해 문서를 추가해 코퍼스를 키운 조건과 오픈웨이트 Qwen3.8-27B에서도 모든 코퍼스 크기에서 우세했다.

케이스 스터디는 이 설계의 차이를 잘 보여준다. manifest의 v1 스펙에서 서명이 어떻게 표현되는지 묻는 질문의 답은 서로 다른 소스에 있는 초안과 v1 스펙 두 문서에 있었다. 트리 구조로 코퍼스를 조직하는 Corpus2Skill은 두 문서를 한 클러스터에 넣었지만 다른 브랜치들을 탐색하다 실패하고 그런 문서가 없다고 결론지었다. 반면 CorpusMap의 에이전트는 초안을 링크한 작업 항목의 Entity Page를 열고, 초안을 읽은 뒤 그 용어로 Entity Page들을 검색하고, v1 스펙을 링크한 Serving Runtime 페이지를 열어 읽는 경로로 답에 도달했다. 트리는 문서를 주로 하나의 브랜치에 두지만, 공유 엔티티를 통한 링크는 같은 근거로 가는 여러 경로를 제공한다. 개발자 입장에서는 사내 문서 검색이나 RAG 파이프라인에서 청크 유사도만으로 잡히지 않는 크로스소스 근거를 다루려 할 때, 엔티티 해석 기반의 영속 계층을 오프라인으로 구축해 두는 접근이 유력한 후보가 된다. 도입 시에는 코퍼스에 맞는 엔티티 타입 카탈로그 유도 비용, 해석 정확도(잘못된 LINK는 맵 전체를 오염시킨다), 증분 갱신 파이프라인, 권한 분리 설계를 확인해야 한다.

저자들이 명시한 한계와 전제도 분명하다. Entity Page가 여러 문서에 흩어져 있던 개인정보나 민감정보를 한곳에 집약할 수 있고, 접근 권한이 없는 사용자에게 문서를 노출할 위험이 있다. 또한 기반 코퍼스와 LLM에 따라 만들어진 맵과 생성된 답변이 유해하거나 편향된 내용을 담을 수 있다. 이에 대해 실배포에서는 권한 수준별로 맵을 구축·서빙하고 프라이버시·콘텐츠 필터 같은 안전장치를 넣어야 한다고 제안한다. 방법 자체의 전제도 있다. 두 개 이상 문서에 연결된 교차문서 엔티티만 유지하므로 한 문서에만 등장하는 엔티티는 항해 경로를 제공하지 못하고, 어떤 유지 엔티티에도 연결되지 않은 문서는 고립 노드로 남아 raw 검색에만 의존한다. 구축 비용은 1회성으로 선지급되므로 질의 수가 적으면 분할 상환 이점이 사라진다.