LLM Wiki - RAG이 대체할 수 없는 체계화된 지식

AI 시스템을 위한 컴파일된 지식

Page content

전제는 간단합니다. 컴파일된 지식은 검색된 단편보다 재사용성이 높습니다. RAG는 직관적인 질문—LLM에게 외부 지식을 어떻게 접근하게 할 것인가?—에 대한 기본 답변이 되었습니다.

이제 우리에게 익숙한 일반적인 아키텍처는 다음과 같습니다. 문서를 가져와 청크(chunk)로 분할하고, 임베딩을 생성하며, 벡터 데이터베이스에 저장한 후, 쿼리 시 관련 조각을 검색하여 모델에 전달합니다. 이 패턴은 유용하지만 과도하게 사용되기도 합니다. RAG는 접근성(access)에는 매우 뛰어나지만, 구조화(structure)에는 자동으로 우수한 것이 아닙니다. 관련 단편을 찾을 수는 있지만 도메인에 대한 안정적인 이해를 생성하지는 않으며, 컨텍스트를 검색할 수는 있지만 정석적인 설명(canonical explanation)을 결정하지는 않습니다. 또한 문서에서 답변을 제공할 수는 있지만 살아있는 지식베이스(living knowledge base)를 유지하지는 않습니다.

llm-wiki

LLM Wiki는 또 다른 검색 패턴이 아니라, 지식 아키텍처를 바라보는 완전히 다른 방식입니다. 질문이たびに 있을 때마다 모델이 원시 청크에서 종합(synthesize)하도록 요청하는 대신, LLM Wiki는 파이프라인의 초기 단계에서 모델을 사용하여 수집 시점(ingest time)에 종합을 수행하고 그 결과를 구조화되고 읽기 가능하며 연결된 지식으로 저장합니다.

간단한 요약은 다음과 같습니다.

  • RAG는 쿼리 시점에 지식을 검색합니다.
  • LLM Wiki는 수집 시점에 지식을 컴파일합니다.

이 차이점은 비용, 대기 시간, 품질, 유지 관리, 거버넌스 및 실패 모드에 영향을 미치며, LLM Wiki가 자체 아키텍처 카테고리를 가질 자격이 있는 중심적인 이유입니다.

RAG는 표현이 아닌 검색을 최적화합니다

RAG는 언어 모델이 훈련 데이터 외부의 정보를 사용할 수 있게 하여 다음 용도에 유용하므로 강력합니다.

  • 회사 문서
  • 제품 매뉴얼
  • 기술 지원
  • 내부 검색
  • 연구 보조
  • 정책 조회
  • 코드 문서화
  • 지식베이스 챗봇

하지만 RAG에는 구조적 약점이 있습니다. 종종 지식을 구조화된 도메인 모델이 아닌 검색 가능한 단편의一堆(pile)로 취급합니다.

일반적인 RAG 시스템은 다음과 같이 작동합니다.

  1. 문서 수집.
  2. 청크로 분할.
  3. 임베딩 생성.
  4. 벡터 데이터베이스에 청크 저장.
  5. 각 쿼리에 대해 유사한 청크 검색.
  6. 해당 청크를 사용하여 LLM에게 답변하도록 요청.

이는 많은 질문에 잘 작동하지만, 복잡한 질문의 경우 반복적인 해석 작업을 생성하기도 합니다. 사용자가 개념적으로 풍부한 무언가를 질문할 때마다 시스템은 다음 작업을 수행해야 합니다.

  • 단편 검색
  • 중요한 단편 결정
  • 관계 추론
  • 모순 해결
  • 임시 설명 구축
  • 답변 생성

그 후 종합은 사라지고 다음 쿼리는 처음부터 다시 시작됩니다. 질문이 단순할 때는 문제가 없으나, 동일한 개념이 원시 단편에서 반복적으로 재구성될 때 비효율적이 됩니다.

가장 흔한 RAG의 실수는 더 나은 검색이 더 나은 지식을 의미한다고 가정하는 것입니다. 때로는 맞지만, 종종 그렇지 않습니다. 왜냐하면 검색과 표현은 서로 다른 문제를 해결하기 때문입니다. 검색은 어떤 텍스트 조각이 관련 있는지를 답변하고, 표현은 지식이 처음부터 어떻게 구조화되어야 하는지를 답변합니다. RAG 시스템은 주제에 대해 정확한 다섯 개의 청크를 검색할 수 있지만, 다음과 같은 이유로 여전히 실패할 수 있습니다.

  • 청크가过时(outdated)됨
  • 문서가 서로 모순됨
  • 중요한 개념이 여러 페이지에 흩어져 있음
  • 소스가 용어를 일관되지 않게 사용함
  • 답변이 조회가 아닌 종합을 필요로 함
  • 정석 페이지(canonical page)가 없음

RAG는 접근 계층(access layer)이지 지식 모델 자체는 아니며, LLM Wiki는 일부 지식은 검색되기 전에 표현되어야 한다는 점에서 존재합니다.

LLM Wiki란 무엇인가?

LLM Wiki는 언어 모델이 소스 자료를 구조화된 위키 형태의 지식으로 변환하는 데 도움을 주는 지식 시스템입니다. 원시 문서만 저장하고 나중에 청크를 검색하는 대신, 시스템은 다음과 같은 파생된 지식 아티팩트(derived knowledge artifacts)를 생성합니다.

  • 주제 페이지
  • 요약
  • 용어집
  • 개념 페이지
  • 엔티티 페이지
  • 교차 링크
  • 비교
  • 모순 메모
  • 소스 참조
  • 의사결정 기록
  • 설명

출력물은 일반적으로 사람이 읽을 수 있으며, 많은 구현체에서는 일반 Markdown으로 저장됩니다. 이는 다음과 같은 이유로 중요합니다.

  • 검사 가능
  • 이식 가능
  • 편집 가능
  • 버전 관리 가능
  • diff가 용이
  • 정적 사이트 및 PKM 도구와 호환

이 아이디어는 LLM이 마법처럼 모든 것을 안다는 것이 아니라, LLM이 소스 자료 위에 구조화된 계층을 유지하는 데 도움을 주어 최종 권한이 아닌 구조화 보조자(structuring assistant) 역할을 한다는 것입니다.

핵심 아이디어

LLM Wiki의 핵심 아이디어는 수집 시점의 지식 종합(ingest-time knowledge synthesis)입니다. RAG 시스템에서는 종합이 일반적으로 사용자가 질문할 때 발생하지만, LLM Wiki에서는 질문이 제기되기 전인 수집 단계에서 더 일찍 종합이 발생합니다.

단순화된 파이프라인은 다음과 같습니다.

sources
  -> ingest
  -> summarize
  -> structure
  -> link
  -> maintain
  -> query or browse

시스템은 쿼리 시점까지 지식의 의미를 파악하기 위해 기다리지 않습니다. 대신 미리 재사용 가능한 구조를 생성하므로, LLM Wiki는 검색 파이프라인보다 컴파일된 지식베이스에 더 가깝습니다.

실용적인 예

로컬 LLM 호스팅에 대한 60개의 기사가 있다고 가정해 봅시다. RAG 시스템은 이를 청크로 분할하고 Ollama, vLLM, llama.cpp, SGLang 간의 차이점에 대해 질문할 때 관련 섹션을 검색한 후 LLM이 검색된 단편에서 답변을 조립하도록 할 것입니다.

LLM Wiki 시스템은 다른 작업을 수행합니다. 수집 시점에 구조화된 페이지를 생성합니다.

  • ollama.md
  • vllm.md
  • llama-cpp.md
  • sglang.md
  • local-llm-hosting-overview.md
  • inference-backends-comparison.md
  • gpu-memory-and-context-length.md

그리고 이를 연결합니다. 나중에 질문할 때 시스템은 원시 단편부터 시작하는 것이 아니라, 질문이 도착하기 전에 이미 조립된 구조화된 지식 계층부터 시작합니다. 그리고 개념적 및 비교적 질문의 경우, 이 품질 차이는 상당합니다.

LLM Wiki 작동 방식

공식적인 구현체는 단 하나만 있는 것은 아니지만, 대부분의 LLM Wiki 시스템은 동일한 개념적 단계를 따릅니다.

소스 수집

시스템은 소스 자료(블로그 포스트, PDF, Markdown 노트, 기술 문서, 전사본, 논문, 미팅 노트, 북마크, 코드 주석, README 파일 등)로 시작하며, 이는 생성된 위키와 구별되는 별도의 계층으로 보존되어야 합니다. 이는 생성된 위키 페이지가 원본 진리가 아닌 파생된 지식이기 때문에 중요합니다. 진지한 LLM Wiki는 항상 소스로 돌아가는 링크를 유지해야 하므로, 생성된 페이지는 항상 ‘이 주장은 어디에서 왔는가?‘라는 기본 질문에 답할 수 있어야 합니다.

수집 및 추출

수집 단계에서 시스템은 소스 자료를 읽고 유용한 지식을 추출합니다. 다음을 식별할 수 있습니다.

  • 주요 주제
  • 엔티티 및 도구
  • 정의
  • 주장
  • 결정 사항
  • 예시
  • 소스 간 모순
  • 해결되지 않은 질문
  • 반복되는 개념

이 단계에서 LLM Wiki는 일반 RAG와 차별화되기 시작합니다. RAG가 보통 검색을 위해 문서를 청크로 나누는 반면, LLM Wiki는 단순히 검색 가능하게 만드는 것이 아니라 개념적으로 자료를 이해하고 재구성하려고 시도합니다.

요약

시스템은 요약을 생성하지만, 유용한 요약은 텍스트의 더 짧은 버전이 아니라 논리의 구조를 보존해야 합니다. 약한 요약은 “이 문서는 로컬 LLM 호스팅 도구를 논의합니다"라고 말합니다. 유용한 요약은 “이 문서는 배포 복잡성, GPU 사용량, API 호환성, 프로덕션 준비도를 기준으로 로컬 LLM 호스팅 도구를 비교하며, Ollama를 로컬 사용에 적합하고, vLLM을 서버 워크로드에 강력하며, llama.cpp를 양자화 모델에 유연한 것으로 위치시킵니다"라고 말합니다.

기술적 지식의 경우, 요약은 다음을 포착해야 합니다.

  • 어떤 문제를 해결하는가
  • 어떤 가정을 하는가
  • 어떤 트레이드오프가 있는가
  • 어떤 의존성이 있는가
  • 무엇을 여전히 불확실한가

여기서 LLM이 진정으로 유용한데, 이는 구조화된 설명으로 어수선한 산문을 압축하는 데 능숙하기 때문입니다.

구조화

요약만으로는 충분하지 않습니다. 시스템은 지식이 어디에 속해야 하는지 결정해야 하며, 이것이 바로 표현 계층입니다. 일반적인 구조에는 다음이 포함됩니다.

  • 주제 페이지
  • 개념 페이지
  • 인덱스 페이지
  • 비교 페이지
  • 용어집 항목
  • 방법 안내 페이지
  • 아키텍처 노트
  • 의사결정 기록
  • 관련 페이지 맵

요약의一堆(pile)은 위키가 아닙니다. 위키에는 페이지 경계, 링크, 반복되는 구조가 필요하며, 좋은 LLM Wiki는 페이지 수로 측정되는 것이 아니라 페이지가 실제로 재사용되는지로 측정됩니다.

연결

링크는 지식 시스템의 형태를 정의합니다. 일반 문서 아카이브에서는 관계가 종종 암묵적이지만, LLM Wiki에서는 명시적이 되어야 합니다. 유용한 링크 유형에는 다음이 포함됩니다.

  • 개념에서 개념으로
  • 기사에서 요약으로
  • 도구에서 비교로
  • 문제에서 해결책으로
  • 아키텍처에서 구현으로
  • 소스에서 파생 페이지로
  • 용어집 용어에서 상세 페이지로

이것이 LLM Wiki와 기본 요약 간의 가장 중요한 차이점 중 하나입니다. 요약은 텍스트를 줄이지만, 링크는 지식 그래프를 구축합니다.

검토 및 수정

이 단계는 장난감 시스템에서만 선택 사항이며, 진지한 시스템에서는 인간 검토가 필수적입니다. 검토 프로세스는 다음을 확인해야 합니다.

  • 요약이 충실한가
  • 링크가 유용한가
  • 주장이 소스가 있는가
  • 페이지가 중복되는가
  • 개념이 잘못 배치된가 -过时 정보가 표시된 가
  • 생성된 페이지가 확신을 과장하는가

LLM Wiki는 인간의 노력을 줄일 수 있지만, 인간의 책임을 제거해서는 안 됩니다.

LLM Wiki vs RAG

LLM Wiki와 RAG 간의 가장 명확한 차이점은 타이밍입니다.

쿼리 시점 종합

RAG에서는 사용자가 질문할 때 시스템이 정보를 검색합니다.

query
  -> retrieve chunks
  -> assemble context
  -> generate answer

이는 유연하며 다음 상황에서는 잘 작동합니다.

  • 코퍼스(문서 집합)가 큼
  • 정보가 자주 변경됨
  • 질문이 예측 불가능함
  • 광범위한 커버리지 필요
  • 모든 것을 큐레이션할 수 없음

하지만 개념적 질문에 대해 덜 일관적일 수 있습니다. 모델이 매번 단편에서 종합해야 하므로, 유사한 쿼리에 대해 일관되지 않은 답변이 생성될 수 있습니다.

수집 시점 종합

LLM Wiki에서는 시스템이 질문이 도착하기 전에 종합을 수행합니다.

sources
  -> summarize
  -> structure
  -> link
  -> query or browse later

이는 덜 유연하지만 더 일관적이며, 다음 상황에서는 잘 작동합니다.

  • 코퍼스가 관리 가능함
  • 도메인이 안정적임
  • 개념이 반복됨
  • 인간 가독성이 중요함
  • 재사용 가능한 종합 필요
  • 유지 관리되는 지식 계층 필요

주요 차이점

차원 RAG LLM Wiki
주요 타이밍 쿼리 시점 수집 시점
주요 작업 청크 검색 지식 컴파일
최적 코퍼스 크고 변화함 큐레이션되고 안정적임
출력 생성된 답변 구조화된 지식 페이지
인프라 검색 인덱스 또는 벡터 DB Markdown 또는 위키 구조
강점 유연한 접근 재사용 가능한 종합
약점 단편화된 컨텍스트 유지 관리 드리프트
인간 가독성 종종 간접적 보통 직접적

상호 보완적이며 상호 배타적이지 않음

논쟁은 “LLM Wiki 또는 RAG"로 프레임되어서는 안 됩니다. 이는 잘못된 질문입니다. LLM Wiki는 대부분의 프로덕션 시스템에서 RAG를 대체하지 않습니다. 둘 다 구별되고 상호 보완적인 역할을 합니다. 잘 설계된 시스템은 다음과 같이 보일 수 있습니다.

raw documents
  -> source store
  -> LLM Wiki synthesis
  -> reviewed knowledge pages
  -> search index
  -> RAG over source and synthesis
  -> answer with citations

이 아키텍처에서 LLM Wiki는 표현 계층을 개선하고 RAG는 접근 계층을 개선합니다. 크고 변화하는 코퍼스에 대한 검색에는 RAG를 사용하고, 안정적이고 큐레이션된 지식에 대한 컴파일된 종합에는 LLM Wiki를 사용하며, 동시에 규모와 일관성이 필요할 때 둘을 함께 사용합니다.

LLM Wiki vs 인접 시스템

LLM Wiki vs 요약

약한 LLM Wiki는 생성된 요약의 폴더일 뿐이며, 이는 충분하지 않습니다. 요약은 콘텐츠를 압축하지만, LLM Wiki는 이를 구조화합니다. 진정한 LLM Wiki에는 안정적인 페이지, 링크, 개념, 인덱스, 소스 추적, 수정 이력, 유지 관리 워크플로우, 충돌 감지가 필요합니다. 위키 부분이 LLM 부분만큼 중요합니다.

LLM Wiki vs 지식 그래프

지식 그래프는 엔티티와 관계를 명시적으로 표현하는 반면, LLM Wiki는 Markdown 페이지와 링크를 통해 더 부드럽고 문서 중심적인 그래프를 생성합니다. 성숙한 시스템은 둘 다를 사용할 수 있습니다. 위키는 사람이 읽을 수 있는 설명을 제공하고 지식 그래프는 정확하게 구조화되고 기계가 쿼리할 수 있는 관계를 제공합니다.

LLM Wiki vs 에이전트 메모리

LLM Wiki는 또한 AI 메모리와 다릅니다. 메모리는 미래의 행동에 영향을 미치는 컨텍스트를 저장하는 반면, LLM Wiki는 인간과 시스템 모두 읽고, 검색하고, 검토하고, 연결할 수 있는 구조화된 지식을 저장합니다.

메모리는 다음을 기억할 수 있습니다.

  • 사용자가 Go 예제를 선호함
  • 프로젝트가 ORM을 피함
  • 에이전트가 어제 명령을 시도함
  • 버그 조사가 실패함

LLM Wiki는 다음을 저장할 수 있습니다.

  • 어떤 Go 데이터베이스 접근 패턴이 있는지
  • sqlc가 GORM와 어떻게 비교되는지
  • 아웃박스(outbox) 패턴이 중요한 이유
  • RAG가 메모리 시스템과 어떻게 다른지

메모리는 행동 컨텍스트이고 LLM Wiki는 표현된 지식입니다. 둘을 혼합하면 검사, 감사 또는 유지 관리가 어려운 시스템이 됩니다.

LLM Wiki가 잘 작동하는 시기

LLM Wiki는 안정적인 도메인, 개인 연구, 큐레이션된 코퍼스, 기술 문서화, 그리고 동일한 자료에 대한 반복적 종합이 낭비인 상황에서 가장 잘 작동합니다.

안정적인 도메인

LLM Wiki는 도메인이 매시간 변경되지 않을 때 가장 잘 작동합니다. 좋은 예시에는 다음이 포함됩니다.

  • 기술적 개념
  • 연구 노트
  • 학습 자료
  • 아키텍처 패턴
  • 책 노트
  • 모델 비교 노트
  • 내부 엔지니어링 원칙
  • 큐레이션된 문서
  • 개인 지식베이스

지식이 며칠 내에过时 되지 않고 요약하기에 충분히 안정적이라면, LLM Wiki는 위키가 성장함에 따라 복리되는 지속적인 가치를 제공할 수 있습니다.

연구 종합

연구 종합은 가장 강력한 사용 사례 중 하나입니다. 연구자들은 종종 많은 소스를 읽고 동일한 메타 질문을 반복적으로 제기하기 때문입니다.

  • 주요 아이디어는 무엇인가?
  • 어떤 소스가 일치하는가?
  • 어떤 소스가 충돌하는가?
  • 어떤 개념이 반복되는가?
  • 주제의 현재 상태는 무엇인가?
  • 다음에 무엇을 읽어야 하는가?

LLM Wiki는 이 연구 자료를 재사용 가능한 구조(주제 페이지, 비교 페이지, 모순 메모, 관련 링크 등)로 변환하여 연구자가 도메인으로 돌아올 때마다 동일한 정신적 맵을 재구성하지 않도록 돕습니다. 논문, 기술 기사, 전사본, 문서, 노트, 실험 로그와 작업할 때 특히 유용합니다.

개인 지식 시스템

LLM Wiki는 PKM 및 더 넓은 지식 시스템 스펙트럼 및 second brain 워크플로우와 자연스럽게 맞습니다. 왜냐하면 개인 지식 시스템에는 이미 다음이 포함되어 있기 때문입니다.

  • 노트
  • 링크
  • 완성되지 않은 아이디어
  • 요약
  • 참조
  • 주제 맵

LLM은 다음을 통해 구조를 유지하는 데 도움을 줄 수 있습니다.

  • 긴 노트 요약
  • 링크 제안
  • 주제 페이지 생성
  • 중복 개념 감지
  • 용어집 용어 추출
  • 인덱스 페이지 생성
  • 격차 식별

인간은 편집자로 남으며, 이는 인간 판단과 기계 보조 간의 올바른 관계입니다.

기술 블로그

기술 블로그는 완전한 자동화 시스템을 구축하지 않더라도 내부적으로 LLM Wiki 아이디어를 사용할 수 있습니다. 잘 구조화된 사이트는 다음을 포함할 수 있습니다.

  • 핵심 페이지(pillar pages)
  • 클러스터 인덱스 페이지
  • 주제 요약
  • 관련 기사 맵
  • 용어집 페이지
  • 비교 페이지
  • 정석적인 설명자(canonical explainers)

이는 SEO뿐만 아니라 지식 표현입니다. 잘 구조화된 기술 블로그는 기사가 인간과 AI 시스템 모두 탐색할 수 있는 내구성 있는 지식 구조로 연결될 때 더 가치가 있습니다.

소규모 팀 지식베이스

LLM Wiki는 엔지니어링 결정, 제품 아키텍처, 온보딩 노트, 지원 플레이북, 내부 표준, 사후 분석, 런북을 포함한 큐레이션된 지식을 가진 소규모 팀에 잘 작동할 수 있습니다. 핵심 조건은 거버넌스입니다. 누구나 생성된 구조를 검토하고 유지 관리해야 하며, 명확한 소유권이 없으면 초기에 잘 생성되었든 상관없이 위키는 소음으로 퇴화합니다.

LLM Wiki가 적합하지 않은 시기

고도로 동적인 데이터

LLM Wiki는 정보가 끊임없이 변경될 때 약합니다. 라이브 재고, 가격 피드, 사건 상태, 금융 시장 데이터, 급변하는 지원 티켓, 실시간 로그는 모두 검색 또는 직접 API 접근으로 더 잘 서비스됩니다. 빠르게 움직이는 데이터를 정적 요약으로 컴파일하는 것은 컴파일된 계층을 실제와 동기화하는 강력한 새로고침 프로세스가 없으면 역효과가 납니다.

대규모 미관리 코퍼스

LLM Wiki는 자동으로 수백만 개의 문서로 확장되지 않습니다. 대규모에서 어려운 문제는 생성을 넘어 다음과 같은 영역으로 확장됩니다.

  • 접근 제어
  • 데이터 계보
  • 소유권
  • 중복 제거
  • 인덱싱
  • 신선도 추적
  • 평가
  • 거버넌스

간단한 Markdown 위키는 이러한 요구 사항을 해결할 준비가 되어 있지 않으며, 기업 규모에서 LLM Wiki는 전체 시스템이 아닌 더 큰 지식 아키텍처 내부의 하나의 계층이 될 수 있습니다.

저품질 소스

LLM Wiki는 나쁜 소스를 신뢰성 있게 고칠 수 없습니다. 소스 자료가 모순되거나,过时 되거나, 저품질이거나, 중복되거나, 불완전하거나, 범위가 잘못 설정되면, 생성된 페이지는 세련되게 보이지만 틀릴 수 있습니다. 이는 깔끔한 생성된 페이지가 잘못된 확신을 생성하기 때문에 특히 위험합니다. 포맷은 기본 콘텐츠가 이를 정당화하지 않더라도 품질을 신호합니다.

검토 프로세스 부재

검토 없는 LLM Wiki는 위험합니다. 왜냐하면 생성된 구조가 권위를 생성하기 때문입니다. RAG의 잘못된 답변은 하나의 쿼리에 영향을 미칠 수 있지만, 잘못된 생성된 위키 페이지는 이를 검색하는 많은 향후 쿼리, 독자, 에이전트에 영향을 미칠 수 있습니다. 모델은 과잉 일반화하거나, 예외를 누락하거나, 구조를 발명하거나, 호환되지 않는 아이디어를 병합하거나, 불확실성을 숨기거나, 오해의 소지가 있는 링크를 생성하거나,过时 자료를 현재인 것처럼 요약할 수 있습니다. 따라서 실제로 중요한 지식에 대해서는 인간 검토가 선택 사항이 아닙니다.

한계 및 실패 모드

LLM Wiki 구축의 주요 위험은过时된 요약, 지식베이스에 고정된 환각적 종합, 약한 소스 추적, 유지 관리 비용, 생성된 구조에 대한 잘못된 확신입니다.

유지 관리 드리프트

지식 드리프트는 생성된 페이지가 기본 소스와 일치하지 않게 될 때 발생합니다. 이는 다음으로 인해 발생할 수 있습니다.

  • 소스가 변경됨
  • 새로운 소스가 추가됨
  • 오래된 페이지가 새로고침되지 않음
  • 요약이 수동으로 편집됨
  • 링크가过时 됨
  • 모델 출력이 시간에 따라 변경됨

드리프트는 LLM Wiki의 중심 운영 위험이며, 좋은 시스템은 이를 전파하기 전에 포착하기 위해 명시적인 새로고침 및 유효성 검사 워크플로우가 필요합니다.

환각적 종합

RAG는 답변 시점에 환각할 수 있지만, LLM Wiki는 수집 시점에 환각할 수 있으며, 이는 더 미묘하고 더 위험합니다. 생성된 위키 페이지가 잘못된 종합을 포함하면, 향후 사용자는 해당 페이지를 사실로 취급할 수 있으며, 향후 AI 시스템은 이를 검색하고 오류를 더 증폭시킬 수 있습니다. 생성된 구조는 계보(provenance)가 필요하며, 모든 중요한 주장은 원래 소스로 돌아가야 하므로 환각이 검토 중에 포착될 수 있어야 하며 지식베이스에 침묵하여 임베딩되지 않아야 합니다.

과도한 구조화

페이지를 저렴하게 생성할 수 있는 LLM이 있으면, 너무 많은 페이지를 생성하려는 유혹이 생깁니다. 다음과 같은 결과에 직면할 수 있습니다.

  • 빈 분류법
  • 중복 개념
  • 얕은 페이지
  • 의미 없는 링크
  • 생성된 혼란
  • 가짜 완성도

유용한 위키는 페이지 수로 측정되는 것이 아니라 페이지가 시간이 지남에 따라 실제로 재사용되고, 연결되고, 업데이트되는지로 측정됩니다.

불명확한 소유권

모델은 페이지의 소유주가 될 수 없습니다. 진지한 시스템은 다음을 포함하는 명확한 소유권 규칙이 필요합니다.

  • 누가 페이지를 검토하는가
  • 누가 업데이트를 승인하는가
  • 누가过时된 페이지를 삭제하는가
  • 누가 모순을 해결하는가
  • 누가 정석적인 구조를 결정하는가

이 명확함이 없으면 LLM Wiki는 잘 의도되고 잘 생성되었지만 조용히 무시되는 또 다른 방치된 지식베이스가 됩니다.

아키텍처 패턴

패턴 1. 개인 LLM Wiki

개인 패턴은 가장 간단하고 실용적인 버전이며, 개인에게 가장 적합합니다.

notes and sources
  -> LLM assisted summaries
  -> Markdown pages
  -> manual review
  -> [Obsidian](https://www.glukhov.org/ko/knowledge-management/tools/obsidian-for-personal-knowledge-management/ "Using Obsidian for Personal Knowledge Management") or static site

이는 연구자, 작가, 엔지니어, 기술 블로거, 학생, 컨설턴트에게 잘 작동하며, 팀 조정 또는 거버넌스 인프라가 필요하지 않으면서 반복적 종합을 줄이고 개인 지식을 탐색하기 쉽게 만들어 가치로 이어집니다.

패턴 2. 팀 LLM Wiki

팀 패턴은 소규모 그룹에 가장 적합하며 개인 버전보다 더 많은 거버넌스가 필요합니다.

team docs
  -> ingest workflow
  -> generated draft pages
  -> review queue
  -> published wiki
  -> search or RAG layer

여기에서 검토 대기열(review queue)이 중요합니다. 왜냐하면 생성된 지식은 인간 체크포인트 없이 팀의 진실 소스(source of truth)에 직접 게시되어서는 안 되기 때문입니다. 경량적인 검토 프로세스조차도 제도화된 지식이 되기 전 가장 위험한 환각을 포착합니다.

패턴 3. LLM Wiki plus RAG

이는 종종 가장 균형 잡힌 아키텍처로, 원시 소스 접근과 컴파일된 종합을 모두 제공합니다.

raw sources
  -> LLM Wiki pages
  -> reviewed knowledge base
  -> search index
  -> RAG over raw and compiled knowledge
  -> cited answer

RAG 시스템은 원시 문서, 생성된 요약, 주제 페이지, 비교 페이지, 용어집 항목에서 검색할 수 있으므로, 원시 문서만 운영하는 것보다 검색 품질이 현저히 강해집니다.

패턴 4. 사이트 아키텍처로서의 LLM Wiki

기술 웹사이트의 경우, 자동화 없이도 LLM Wiki 아이디어가 콘텐츠 구조를 안내할 수 있습니다.

articles
  -> pillar pages
  -> topic maps
  -> comparisons
  -> internal links
  -> search and AI access

이는 블로그를 기사가 단순한 포스트가 아닌 구조화된 맵의 노드인 지식 시스템으로 변환합니다. 이는 독자 경험과 기계 가독성 발견 가능성 모두에 있어 상당한 차이입니다.

LLM Wiki 설계 원칙

원시 소스를 별도로 유지

원본 소스를 절대 잃지 마십시오. 생성된 페이지는 소스 문서를 대체해서는 안 되고 그 위에 위치해야 합니다. 소스 계층은 증거를 제공하고, 위키 계층은 해석을 제공합니다. 원본을 잃으면 이를 기반으로 한 해석을 검증하거나, 도전하거나, 업데이트할 능력을 잃습니다.

가능한 한 Markdown 사용

Markdown은 지루하지만 훌륭합니다. 이식 가능하고, 읽기 쉽고, diff 가능하고, 버전 관리 가능하고, 편집하기 쉬우며, 정적 사이트와 PKM 도구에 친숙합니다. 지루한 포맷은 영리한 플랫폼보다 오래 생존하므로, 오늘 구축된 Markdown 기반 LLM Wiki는 귀하가 선택했을 수 있는 독점적 데이터베이스가 여러 번의 파괴적 마이그레이션을 거친 후에도 여전히 사용 가능할 것입니다. 구문 참조는 Markdown Cheatsheet 및 Markdown Code Blocks 가이드를 참조하십시오. 이는 기술 콘텐츠를 포함하는 위키 페이지를 구조화할 때 특히 관련이 있습니다.

계보 추적

각 생성된 페이지는 다음에 답해야 합니다.

  • 이를 생성한 소스는 무엇인가?
  • 언제 생성되었는가?
  • 언제 검토되었는가?
  • 무엇이 변경되었는가?
  • 누가 승인했는가?

계보가 없으면 시간이 지남에 따라 페이지가 기원으로부터 더 멀리 드리프트함에 따라 신뢰가 붕괴됩니다. 실용적인 페이지 스키마는 다음과 같을 수 있습니다.

title
summary
status
sources
last_reviewed
related_pages
concepts
open_questions

기술 콘텐츠의 경우 다음을 추가하십시오.

applies_to
version
examples
tradeoffs
failure_modes

연구 콘텐츠의 경우 다음을 추가하십시오.

claims
evidence
contradictions
confidence

더 적지만 더 나은 페이지 선호

사소한 아이디어마다 페이지를 생성하지 마십시오. 강력한 개념 페이지, 유용한 비교 페이지, 주제 인덱스, 정석적인 요약, 그 자리를 차지하는 용어집 항목을 선호하십시오. 20개의 잘 유지 관리된 페이지가 있는 작고 유용한 위키가 아무도 읽거나 업데이트하지 않는 200개의 페이지가 있는 큰 생성된 혼란보다 낫습니다.

의미 있는 링크 생성

링크는 무작위로 페이지를 연결하는 대신 관계를 설명해야 합니다. 유용한 링크 유형에는 다음이 포함됩니다.

  • 관련 개념
  • 의존 관계
  • 대조 관계
  • 예시
  • 소스
  • 확장 관계
  • 구현

무작위 링크는 소음을 생성하고 구조에 대한 독자 신뢰를 침식합니다.

불확실성 표시

LLM Wiki 페이지는 모든 지식이 동일하게 확실하다고 가정해서는 안 됩니다. 유용한 상태 마커에는 다음이 포함됩니다.

  • 확인됨
  • 가능성 높음
  • 논쟁적 -过时 됨
  • 검토 필요
  • 소스 충돌
  • 생성된 요약

이러한 마커는 독자를 잘못된 확신으로부터 보호하고 유지 관리자에게 어떤 페이지가 주의가 필요한지 명확한 신호를 제공합니다.

LLM Wiki 평가 방법

생성된 페이지가 인상적으로 보이는지만 묻지 마십시오. 지식 작업(improvement knowledge work)을 개선하는지 묻십시오. 유용한 평가 질문에는 다음이 포함됩니다.

  • 사용자가 개념을 더 빠르게 찾을 수 있는가?
  • 반복적인 질문이 더 잘 답변되는가?
  • 소스 링크가 보존되는가?
  • 모순이 더 쉽게 보이는가?
  • 페이지가 재사용되는가?
  • 요약이 정확한가? -过时된 콘텐츠가 감지되는가?
  • 위키가 반복적 종합을 줄이는가?
  • 인간이 작성하거나 결정하는 데 도움이 되는가?
  • RAG 답변 품질을 개선하는가?

이 중 대부분에 대한 답변이 아니라면, 페이지 수가 많든 상관없이 위키는 장식일 뿐입니다.

LLM Wiki와 지식 관리

LLM Wiki는 지식 관리에 속합니다. 왜냐하면 이는 근본적으로 모델 호스팅, 벡터 검색 또는 에이전트 실행이 아닌 표현과 관련되기 때문입니다. 이는 다른 질문을 답변합니다. 지식은 어떻게 구조화되어야 인간과 AI 시스템이 재사용할 수 있는가? 이는 이를 지식 시스템 아키텍처 계층에 위치시키며, PKM, 위키, RAG, 에이전트 메모리, 지식 그래프, 기술 출판, 연구 종합과 자연스럽게 연결합니다.

깔끔한 계층 모델은 다음과 같습니다.

  • 인간 사고 - PKM, 아이디어 탐색 및 개발
  • 공유 지식 - 위키, 정석적인 페이지 유지
  • 컴파일된 지식 - LLM Wiki, 구조화된 종합 생성
  • 기계 접근 - RAG, 쿼리 시점 컨텍스트 검색
  • 에이전트 연속성 - 메모리, 행동 및 선호도 지속

LLM Wiki는 컴파일된 지식 계층을 차지하며, 이것이 유용한 이유입니다. 이는 문서一堆(pile)을 인간과 기계가 모두 탐색하고 추론할 수 있는 무언가로 변환하는 계층입니다.

저의 의견 있는 관점

LLM Wiki는 중요합니다. 하지만 과대광고가 약간 잘못되었습니다. 이는 RAG 킬러가 아니라, 지식 표현이 중요하다는 상기입니다. 산업은 몇 년 동안 검색 파이프라인 최적화에 시간을 보냈고, 그 작업은 필요했습니다. 하지만 많은 시스템은 여전히 잘못 구조화된 지식에서 검색합니다. 더 나은 임베딩과 더 나은 리랭커가 도움이 되지만, 약한 지식 계층을 완전히 보상할 수는 없습니다.

LLM Wiki는 더 나은 질문을 제기함으로써 대화 구조로 되돌아갑니다.

  • 핵심 개념은 무엇인가?
  • 무엇이 정석적인가?
  • 아이디어는 어떻게 연결되는가?
  • 무엇이 한 번 요약되어야 하는가?
  • 무엇이 새로 검색되어야 하는가?
  • 무엇이 인간에 의해 검토되어야 하는가?

이것이 올바른 대화이며, 미래는 더 나은 벡터 검색뿐만 아니라 표현, 검색, 메모리가 각각 구별되고 잘 이해된 역할을 하는 계층화된 지식 시스템입니다.

결론

LLM Wiki는 질문이 제기되기 전에 언어 모델을 사용하여 소스 자료를 구조화되고, 연결되고, 재사용 가능한 지식으로 변환하는 데 도움을 주는 컴파일된 지식의 아키텍처 패턴입니다. 핵심 워크플로우는 다음과 같습니다.

summarize
  -> structure
  -> link
  -> review
  -> reuse

RAG와 비교할 때, 주요 차이점은 타이밍입니다. RAG는 쿼리 시점에 종합을 수행하는 반면, LLM Wiki는 수집 시점에 종합을 수행하므로 안정적인 도메인, 연구 종합, 개인 지식베이스, 기술 블로그, 큐레이션된 팀 지식에 가치 있습니다.

하지만 실제 한계가 있습니다. 소스가 변경되면 드리프트되고, 모델 출력이 잘못되면 환각되며, 검토가 없으면 잘못된 확신을 생성하고, 소유권이 불명확하면 소음으로 붕괴됩니다. 잘못 사용하면 방치된 또 다른 위키가 됩니다. 잘 사용하면 원시 문서와 AI 시스템 간의 표현 계층이 됩니다. RAG의 대체품이 아니라, 검색을 가치 있게 만드는 누락된 계층입니다.

소스 및 추가 읽기

구독하기

시스템, 인프라, AI 엔지니어링에 관한 새 글을 받아보세요.