RAG vs Persistent Wiki

RAG와 Persistent Wiki는 둘 다 "LLM에게 source를 근거로 답하게 한다"는 목표를 공유하지만, 질문에 답한 결과가 다음 질문에 남는가에서 갈린다. 일반적인 문서 기반 LLM 사용, 즉 파일 묶음을 업로드하고 질문 시점에 관련 chunk를 검색해 답을 생성하는 방식은 작동은 하지만 매 질문마다 지식을 새로 발견해야 한다.^[1] Persistent Wiki는 이 재발견 비용을 없애기 위해, retrieval 결과를 그때그때 버리지 않고 구조화된 markdown 페이지로 축적한다.

무엇이 다른가

• 새 source가 들어왔을 때 RAG는 그것을 색인만 하지만, Persistent Wiki는 내용을 읽어 핵심 정보를 추출하고 기존 entity page·topic summary·synthesis에 통합하며, 새 데이터가 기존 주장과 충돌하면 그 모순을 표시한다.^[1:1]
• 이 차이는 저장 포맷보다 지식이 답변 뒤에 남는가에 있다고 볼 수 있다. Persistent Wiki는 단순한 embedding index가 아니라 cross-reference·contradiction flag·synthesis가 누적되는 compounding artifact라는 것이 원문의 핵심 주장이다.^[1:2]

언제 어느 쪽을 쓰나

• 일회성 문서 질의는 RAG만으로 충분할 수 있다고 보인다 — 매번 재발견하는 비용을 감수할 만큼 질문이 반복되지 않기 때문이다.
• 시간이 지날수록 source와 질문이 쌓이는 연구·학습에는 Persistent Wiki가 유리하다고 판단할 수 있다. 이미 만든 연결과 synthesis를 다음 질문에 재사용할 수 있어서다.
• Persistent Wiki를 쓴다고 RAG(retrieval)를 완전히 배제하는 것은 아니다. Raw source 확인이 필요할 때는 Persistent Wiki도 retrieval을 사용한다 — 이는 두 접근의 배타성이 아니라 역할 분담의 문제라고 해석할 수 있다.

선택 절차와 실패 모드

1. 질문이 일회성 fact lookup인지, 다음 질문에도 쓰일 model인지 먼저 판단한다. 판단을 건너뛰고 모든 검색 결과를 permanent page로 만들면, navigation이 source archive처럼 변해 오히려 찾기 어려워진다.
2. 이미 Wiki에 관련 page가 있으면 그것을 먼저 읽고, source freshness가 필요한 부분만 Raw로 확인한다. Wiki가 있다는 이유로 Raw retrieval을 아예 멈추면 version-sensitive claim이 stale하게 남는다.
3. 새 explanation이 여러 질문에 쓰이고 source가 분명하면 기존 page를 보강하거나 page type에 맞게 ingest한다. 이때 RAG search hit를 검증된 synthesis처럼 그대로 인용하면 원래 있던 source scope가 사라진다는 점을 주의해야 한다.
4. 재사용 판단이 없거나 개인 맥락만 담긴 질문은 answer로 끝내고 Wiki를 늘리지 않는다.

관련

• Persistent Wiki — 축적하는 knowledge layer의 정의다.
• Query Compounding — 재사용 판단 후의 갱신 절차다.
• LLM Wiki Operating Model — retrieval, ingest, maintenance의 역할 분담이다.
• Vector Retrieval for RAG — RAG 쪽 retrieval이 임베딩·근사 인덱스·유사도로 실제로 어떻게 동작하는지를 다룬다.

출처