드디어 Karpathy의 LLM Wiki gist를 읽어봤다 (네, 저도 이제야 유행에 합류했어요 XD).
그런데 솔직히 말하면, 이 전체 아이디어는 꽤 간단한 개념으로 수렴된다: "업데이트 가능한 RAG".
1. 문제점
LLM이 문서를 처리할 때는 아무것도 축적되지 않는다. 매번 쿼리할 때마다 모델이 청크를 검색하고, 처음부터 종합하고, 잊어버린다. 지식은 결코 컴파일되지 않는다. 그리고 내 생각에 더 중요한 점은: 대화 자체에서 유용한 정보가 거의 추출되지 않는다는 것이다.
RAG가 부분적으로 도움은 되지만 (넓은 의미에서 .md 파일 폴더도 RAG다), 표준 파이프라인(모두가 사용하는)에는 업데이트, 증류, 자체 정리 기능이 내장되어 있지 않다. 지식은 한 번 인덱스에 들어가면 그냥 거기서 가만히 있는다. 바로 그 격차를 LLM Wiki가 메워준다.
Karpathy의 발상의 전환: 원본 소스와 사용자 사이에 에이전트가 점진적으로 작성하고 유지 관리하는 마크다운 위키가 위치한다. 한 번 컴파일하고, 계속 최신 상태를 유지한다.
2. 아키텍처: 3계층
- raw/ - 소스, 변경 불가. 에이전트는 여기에 쓰지 않는다.
- wiki/ - 시스템의 핵심; LLM이 직접 작성하고 상호 연결하는 마크다운 페이지들 (엔터티, 개념). 본질적으로 그래프 형태의 지식이다.
- CLAUDE.md - LLM Wiki를 실행하는 방법에 대한 메뉴얼일 뿐. 페이지 형식, 링크 규칙, 수집 흐름, 린트 규칙을 담고 있다. 클로드를 챗봇에서 규율 있는 위키 관리자로 바꿔주는 요소다.
추가 튜닝 없이 수백 페이지를 처리할 수 있다:
3. 작업
세 가지 작업 - 바로 API 함수로 그리고 싶을 것이다:
- Ingest -> add(source: file | list[file]). 소스를 넣으면 -> 에이전트가 읽고 -> 사용자와 논의하고 -> 요약을 작성하고 -> 인덱스를 업데이트하고 -> 관련 엔터티 페이지를 편집하고 -> 로그에 추가한다. 하나의 소스가 10-15개의 페이지에 영향을 미친다.
- Query -> search(prompt: str). 가장 중요한 작업. 질문에 답변하고 + (핵심 포인트) 합성 결과를 새로운 페이지로 자동으로 위키에 파일링한다. 탐색이 채팅 기록에서 사라지지 않고 누적된다. 내부적으로는 기본적으로 add(source=dialogue)와 같다.
- Lint -> lint(). 인수 없음. 주기적으로 위키를 탐색한다: 모순, 고립된 페이지, 오래된 사실, 누락된 상호 참조. N번째 사용자 메시지마다 또는 변경된 줄 카운터를 기준으로 트리거된다. /schedule에 연결하기 쉽다.
Claude Dreaming이 강하게 떠오른다 - Dreaming이 이 패턴에서 부분적으로 영감을 받았다고 생각한다 (물론 기능 세트는 조금 다르지만).
4. 인덱싱
두 개의 특수 파일이 위키를 탐색 가능하게 만든다:
- index.md - 현재 상태. 각 페이지에 대한 한 줄 설명이 있는 모든 페이지의 카탈로그. 에이전트는 어떤 쿼리든 먼저 이것을 읽는다 - "위키에 뭐가 있는지"에 대한 최소 컨텍스트다.
- log.md - 모든 이벤트의 로그, 자유 형식. 추가 전용 타임라인. 줄이 일관된 형태를 따르면 (예: \
## [YYYY-MM-DD] ingest | title\), 로그를 일반 유닉스 도구로 깔끔하게 grep할 수 있어 감사(audit)에 유용하다.
index.md는 더 확장될 수 있다 (벡터 인덱스, BM25, GraphDB 등) - 별도 포스트에서 다루겠다.
5. 핵심 요점
이렇게 프레이밍하고 싶다: 이것은 RAG와 LLM Wiki 사이의 선택이 아니다 - 둘은 동일한 "누적 기억" 축 위의 서로 다른 두 지점일 뿐이다.
RAG가 반드시 벡터 DB일 필요는 없다 - 마크다운 파일 폴더도 RAG다.
따라서 LLM Wiki는 세 가지가 추가된 RAG라고 다시 표현할 수 있다:
- 요약 계층.
- (거의) 자유 형식으로 그 요약 수준에서 구조를 작성할 수 있는 기능.
- 주기적인 구조 감사 + 자체 개선 (CRON).
