← Notes

Karpathy의 LLM Knowledge Bases

general
llmrag지식관리

개념

Andrej Karpathy가 2026년 4월에 공개한 패턴. RAG의 한계를 지적하면서, LLM이 마크다운 위키를 직접 관리하는 방식을 제안했다.

핵심 비유: 풀타임 리서치 사서를 두는 것. 사람이 안 하는 지루한 작업(교차 참조, 요약 유지, 일관성 체크)을 LLM이 맡는다.

기존 RAG의 문제

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

  • 질문할 때마다 벡터DB에서 청크 검색 → 재합성
  • 여러 문서를 종합해야 하는 질문도 매번 처음부터
  • 지식이 누적되지 않음. 컨텍스트가 소실됨

구조

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 그래프 뷰, Marp 슬라이드 등 생태계 활용 가능
  • 단순: 벡터DB나 복잡한 파이프라인 없이 파일만으로 동작

한계

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