Karpathy의 LLM Knowledge Bases

개념

Andrej Karpathy가 공개한 패턴. RAG의 한계를 지적하면서, LLM이 마크다운 위키를 직접 관리하는 방식을 제안한다. 핵심 비유는 풀타임 리서치 사서를 두는 것 — 사람이 하기 지루한 작업(교차 참조, 요약 유지, 일관성 체크)을 LLM이 맡는다.

왜 기존 RAG로 부족한가

"LLM이 매번 질문할 때마다 지식을 처음부터 다시 조립한다"

기본 RAG는 이렇게 동작한다.

• 질문할 때마다 벡터DB에서 청크를 검색 → LLM이 재합성
• 여러 문서를 종합해야 하는 질문도 매번 처음부터
• 지식이 누적되지 않는다. 앞서 한 번 분석해서 얻은 통찰이 휘발됨

Karpathy의 주장은 이 "매번 재조립" 구조가 근본적 낭비라는 것.

구조

3계층으로 나뉜다.

raw/          ← 원본 소스 (논문, 기사, 데이터). 불변. LLM은 읽기만
wiki/         ← LLM이 생성·유지하는 마크다운 파일들
  index.md    ← 전체 페이지 목록 + 한 줄 요약
  log.md      ← 시간순 작업 기록
  *.md        ← 개념 페이지, 요약, 비교표 등
schema/       ← 규칙 문서. 위키 구조, 명명 규칙, 워크플로우 정의

• raw — 원본은 건드리지 않는다. LLM의 해석과 소스를 분리
• wiki — LLM이 완전히 소유하는 층. 여기가 핵심
• schema — CLAUDE.md 같은 규칙 파일. LLM이 일관되게 동작하도록 가이드

세 가지 작업

ingest (흡수)

새 소스가 들어오면:

1. LLM이 문서를 읽고 핵심 파악
2. 요약 페이지 작성
3. 기존 페이지들과 교차 연결
4. index.md 업데이트
5. log.md에 기록

하나의 소스가 10~15개 위키 페이지를 건드릴 수 있다.

query (질의)

사용자가 질문하면:

1. 관련 위키 페이지 검색
2. 답변 생성 (인용 포함)
3. 좋은 답변은 새 위키 페이지로 저장

이게 RAG와 다른 지점. 탐색 결과가 위키에 축적된다.

lint (점검)

정기적으로 위키 건강도를 검사한다.

• 페이지 간 모순 탐지
• 구식 정보 발견
• 고아 페이지 (아무 데서도 링크 안 됨) 정리
• 언급만 되고 페이지가 없는 개념 식별

RAG vs LLM Knowledge Bases

	RAG	LLM KB
지식 처리 시점	질문할 때 (매번)	소스 들어올 때 (미리)
저장 형태	벡터 임베딩	마크다운 문서
지식 누적	안 됨	됨 (위키에 쌓임)
사람이 읽기	어려움	그대로 읽을 수 있음
인프라	벡터DB + 임베딩 파이프라인	git 리포 하나

왜 마크다운인가

• git — 버전관리, 변경 이력, 브랜칭이 공짜
• 가독성 — LLM 출력을 사람이 바로 읽을 수 있음
• 도구 생태계 — Obsidian 그래프 뷰, 정적 사이트 생성기 등 기존 도구 그대로 활용
• 단순 — 벡터DB나 복잡한 파이프라인 없이 파일만으로 동작

한계

• LLM이 위키를 통째로 관리하므로 조용히 틀릴 수 있음 — 개인용은 괜찮지만 팀용은 위험
• 약 100개 소스, 40만 단어 규모에서 효과적. 그 이상은 구조화된 DB가 필요할 수 있음
• 같은 소스를 반복 ingest하면 내용이 왜곡될 수 있어서 멱등성 보장 필요

더 보기

• RAG — 전통적 RAG 파이프라인
• RAG-한계와-보완 — RAG의 구조적 한계
• GraphRAG — 문서 간 관계 그래프를 활용한 다른 확장
• Agentic-RAG — Agent가 판단·반복하는 RAG 패턴