LLM Wiki vs RAG — 핵심 차이와 적합 상황

원 질문: LLM Wiki와 RAG의 핵심 차이점은 무엇이고, 어떤 상황에서 LLM Wiki가 더 적합한가?

답변

요약

RAG는 매 쿼리마다 원본 문서를 재검색해 즉흥 합성한다(출처: compounding-artifact). LLM Wiki는 소스를 한 번 통합해 구조화된 지식 베이스로 컴파일하고, 이후 쿼리는 이미 합성된 위키를 탐색한다. 핵심 차이는 지식의 누적 여부다 — RAG는 무덤을 더 빠르게 검색하고, LLM Wiki는 무덤을 살아있는 지식으로 바꾼다(출처: compounding-artifact).

비교

차원RAGLLM Wiki
지식 처리 방식쿼리마다 청크 검색 후 즉흥 합성 (출처: compounding-artifact)소스 인제스트 시 한 번 통합, 위키에 지속 누적 (출처: compounding-artifact)
교차참조없음 — 청크 단위로 고립 (출처: compounding-artifact)풍부한 위키 그래프, 엔티티·개념 페이지 상호 링크 (출처: three-layer-architecture)
모순 처리없음 (충돌 정보 혼재) (출처: compounding-artifact)플래그 후 양쪽 기록, Contradiction 섹션 명시 (출처: compounding-artifact)
합성 시점쿼리 시 즉흥 (매번 재계산) (출처: compounding-artifact)인제스트 시 사전 컴파일, 이후 점진 갱신 (출처: compounding-artifact)
인프라 요구벡터 DB + 임베딩 모델 (출처: index-first-retrieval)~100 소스까지 index.md + Grep 만으로 충분 (출처: index-first-retrieval)
지식 영속성세션 종료 시 재계산 — 누적 없음 (출처: compounding-artifact)위키가 세션을 넘어 유지 (출처: compounding-artifact)
소유권LLM이 매번 원본 청크에서 읽음Layer 2(Wiki)를 LLM이 소유·유지 (출처: three-layer-architecture)

관찰

  • RAG와 LLM Wiki의 가장 결정적 차이는 합성의 시점이다. RAG는 쿼리 시, LLM Wiki는 인제스트 시 합성한다. 그 결과 LLM Wiki는 동일 주제 재쿼리 시 비용이 감소하고 답변 깊이가 증가한다(compounding 효과).
  • LLM Wiki의 index-first retrieval은 임베딩 없이도 동작한다. index.md라는 인간이 읽을 수 있는 카탈로그가 벡터 DB 역할을 대체한다(출처: index-first-retrieval).
  • RAG는 소스가 많아질수록 인프라 복잡도가 선형 이상으로 증가하지만, LLM Wiki는 ~100 소스까지 단순 파일 구조로 유지된다(출처: index-first-retrieval).
  • LLM Wiki 위에서도 인사이트 쿼리 결과가 insights/에 파일링되면, 다음 쿼리의 출발점이 된다 — 탐색 자체가 위키를 풍부하게 만드는 이중 compounding.

결론

LLM Wiki가 더 적합한 상황:

  1. 개인·소규모 도메인 지식 (~100 소스): 벡터 인프라 없이 운영 가능(출처: index-first-retrieval)
  2. 시간 경과에 따른 지식 누적이 중요한 경우: 연구·학습·개인 위키처럼 소스가 지속 추가되는 환경
  3. 교차참조·맥락 연결이 핵심인 경우: 분산된 소스 간 아이디어 연결을 원할 때
  4. 모순 감지·일관성 유지가 필요한 경우: 위키의 lint + Contradiction 플래그 메커니즘 활용

RAG가 더 적합한 상황:

  • 수천~수만 개 문서를 정밀 검색해야 하는 대규모 엔터프라이즈 환경
  • 원본 문서의 정확한 부분을 찾아 인용해야 하는 법률·컴플라이언스 케이스
  • 벡터 인프라 투자가 이미 완료된 조직