[AI 논문 리뷰] 이번 ICML 논문 원픽이었던 - AI가 위키를 직접 쓰기 시작했다! LLM-Wiki 논문 리뷰
RAG는 검색하고 잊는다.
LLM-Wiki는 읽고, 연결하고, 고쳐 쓴다
Retrieval as Reasoning: Self-Evolving Agent-Native Retrieval via LLM-Wiki 리뷰
ICML 2026 주변에서 유난히 재미있던 키워드가 하나 있었다. LLM이 함께 Wiki를 만들고, 그 Wiki가 계속 ‘학습’한다는 이야기다. 정확히 짚으면 두 흐름이 겹친다. Hugging Face의 ICML 2026 오픈 재현 프로젝트에서는 에이전트들이 논문과 실험 로그를 읽고 인용 가능한 지식베이스를 공동 편집했고, 비슷한 시기에 공개된 LLM-Wiki 논문은 이 아이디어를 검색 시스템으로 구체화했다.
여기서 ‘학습’은 대체로 모델 가중치를 업데이트하는 training이 아니다. 문서를 구조화된 Wiki로 컴파일하고, 반복되는 오류를 규칙으로 남기며, 다음 편집에 반영하는 외부 기억의 진화다. 뇌를 다시 훈련하는 게 아니라, 뇌가 읽는 사내 위키가 점점 덜 틀리게 되는 쪽에 가깝다.
검색창을 잘 만드는 대신, AI가 읽을 세계를 만든다
기존 RAG의 계약은 단순하다. 질문을 임베딩하고, 비슷한 청크 Top-k를 가져와, 한 번에 답한다. LLM-Wiki는 계약 자체를 바꾼다. 원문을 독립 청크로 두지 않고 페이지·별칭·태그·출처·양방향 링크가 있는 Wiki로 먼저 컴파일한다. 질의 시 에이전트는 wiki_search와 wiki_read를 반복 호출하면서 중간 단서를 다음 검색으로 바꾼다.
원문 Figure 1. 원문 → 링크된 Wiki → 검증 실패 → Error Book → 재컴파일의 폐루프
| 방식 | 저장 단위 | 질의 방식 | 약점 |
|---|---|---|---|
| Vector RAG | 독립 청크 | 유사도 Top-k | 중간 개체를 따라가기 어려움 |
| GraphRAG | 엔티티·관계·커뮤니티 요약 | 그래프/요약 검색 | 요약 과정에서 세부 근거 손실 가능 |
| LLM-Wiki | 구조화 페이지+링크+출처 | 검색→읽기→링크 추적→충분성 판단 | 비싼 컴파일, 대규모 갱신 문제 |
논문의 진짜 기여: Retrieval as Reasoning
저자들은 에이전트 친화적 검색의 조건을 세 가지로 정리한다.
- Compilability — 원문을 유지보수 가능한 링크드 페이지로 변환할 것
- Composability — 검색·읽기·링크 추적을 작은 도구로 노출해 에이전트가 조합할 것
- Evolvability — 지식 구조가 조용히 썩지 않고, 오류를 발견하고 다음 빌드에서 교정할 것
원문 Figure 2. 한 번 뽑는 검색에서, 읽은 결과로 다음 행동을 정하는 탐색으로
예를 들어 “A의 설계가 영향을 받은 B의 이전 연구는 무엇인가?”라는 질문에서 평면 RAG는 A와 정답 문장이 한 번에 Top-k에 들어오길 빈다. LLM-Wiki는 A 페이지를 읽고 B 링크를 발견한 다음, B 페이지로 이동해 근거가 충분한지 다시 판단한다. 검색 결과가 답변 재료이면서 다음 검색의 프로그램이 되는 셈이다.
Error Book: 모델을 재학습하지 않고도 ‘배운다’
가장 재미있는 장치는 Error Book이다. Wiki 생성 중 발생한 dangling link, 잘못된 출처, 근거 없는 사실, 페이지 간 모순을 기록하고 원인을 규칙으로 바꾼다. 그 규칙은 다음 컴파일 프롬프트에 삽입된다.
error_id: EB-042
phenomenon: "존재하지 않는 페이지로 링크 생성"
root_cause: "현재 index 확인 없이 링크를 추론함"
constraint: "_index.md에 등록된 target만 wikilink로 생성"
verification: "link_target_exists(page, index)"
status: open구조 오류는 코드 validator가 자동 수정하고, 사실성·페이지 간 모순은 주기적으로 LLM이 교정한다. 논문 데이터에서는 dangling link가 검출 오류의 29.1~63.8%를 차지했다. 화려한 추론보다 링크 무결성 검사가 먼저라는, 아주 엔지니어다운 결론이다. AI도 결국 깨진 링크 앞에서는 겸손해진다.
결과는 좋다. 하지만 숫자를 크게 읽으면 안 된다
500개 질문씩 평가한 세 multi-hop QA에서 모두 1위였다. progressive traversal을 제거하자 F1이 11.7~13.8포인트 하락했고, Wiki 구조를 제거하면 6.1~7.0포인트, Error Book을 제거하면 3.4~4.0포인트 떨어졌다. 즉 성능의 핵심은 ‘Wiki 파일 포맷’이 아니라 구조를 실제로 여러 번 탐색하는 루프다.
- 실험은 full Wikipedia가 아니라 각 500개 QA에 딸린 문맥의 합집합이다.
- 초기 Wiki 컴파일 비용은 chunk-and-embed보다 크다.
- 수만 페이지 이상에서는 디렉터리·페이지 선택·오래된 사실 관리가 아직 미해결이다.
- 단일 문서 세부 질문에서는 HippoRAG 2가 LLM-Wiki보다 2.3점 높았다. 요약된 페이지가 원문의 작은 디테일을 누락할 수 있다.
금융권에서는 ‘자율 Wiki’보다 ‘승인형 컴파일’
보험 약관, 규정, 보안 가이드에 바로 적용한다면 LLM이 운영 지식을 마음대로 덮어쓰게 해서는 안 된다. 원문은 immutable source of truth로 보존하고, Wiki는 언제든 재생성 가능한 materialized knowledge view로 다루는 게 맞다.
↓ Document Intelligence + 규칙 기반 파서
↓ LLM Compiler: 상품·특약·조항·시점 페이지와 링크 생성
↓ Schema / citation / temporal / ACL validator
↓ Staging Wiki → diff review → 담당자 승인
↓ Azure AI Search hybrid index + Wiki API
↓ Agent가 search → read → follow → evidence check
여기서 Error Book은 법적 사실을 스스로 고치는 장부가 아니다. “시행일이 없는 조항을 publish하지 말 것”, “폐기된 약관 링크를 최신 약관으로 자동 치환하지 말 것” 같은 컴파일러 실패 패턴을 축적해야 한다. 수정 대상과 근거, 승인자, 적용 버전을 모두 남겨야 감사 시점에 “왜 이 페이지가 이렇게 생겼는가”를 되감을 수 있다.
최소 도입 순서
- 질문 로그에서 3-hop 이상·다문서 합성 질문 비중을 먼저 측정한다.
- 전체 문서가 아니라 한 상품군/한 규정집을 Wiki로 컴파일한다.
- 원문 RAG와 Wiki traversal을 라우팅해 단일 문서 질문은 원문을 보존한다.
- 정답률뿐 아니라 citation coverage, broken-link rate, stale-fact rate, 승인 리드타임을 운영 지표로 둔다.
한 줄 평
개인적으로 이 논문이 재미있는 이유는 모델보다 ingestion을 주인공으로 만들기 때문이다. 지금까지 ingestion은 PDF를 잘게 자르는 전처리였다. LLM-Wiki에서 ingestion은 링크를 만들고, 모순을 검사하고, 실패 규칙을 축적하는 knowledge compilation이다. 다만 자기진화라는 멋진 이름보다 더 중요한 건 provenance, 버전, 삭제 전파, 승인 흐름이다. 금융권에서는 역시 낭만보다 감사 로그가 오래 산다.