Karpathy의 LLM 위키(Wiki): 개념과 직접 만드는 법

원본: https://www.youtube.com/watch?v=zVEb19AwkqM · 업로드: 2026-04-06 · 길이: 17m · 채널: Onchain AI Garage

서론

지난주 Andrej Karpathy가 올린 “LLM 지식 베이스(knowledge base)” 관련 트윗을 본 분이 많을 겁니다. AI를 리서치 도구로 쓰는 새로운 접근으로 꽤 주목을 받았죠. 핵심 아이디어는 단순합니다. 자신이 파고들고 있는 주제에 대해 LLM을 시켜 개인용 위키(wiki) 형태의 지식 베이스를 점진적으로 구축하게 만드는 것. Karpathy 본인이 방법을 간단히 풀어놨고, Farza, Yuchen Jin 같은 다른 연구자·개발자들도 자신들이 어떻게 실천했는지 후속 트윗으로 공유했습니다.

오늘 영상에서는 이 패턴을 직접 만들어 볼 겁니다. 먼저 개념이 무엇인지, 왜 다른 대안보다 유용한지 정리한 뒤, Claude Code로 함께 하나를 만들어 보겠습니다.

RAG의 한계: 매번 처음부터 다시 짜맞추는 지식

요즘 대부분의 사람들이 LLM으로 문서를 다루는 방식은 RAG(retrieval-augmented generation, 검색 증강 생성)입니다. ChatGPT나 NotebookLM에 파일을 올리고, 질문하면 관련 청크를 가져와 답을 만드는 구조죠. 간단한 질문에는 잘 작동합니다.

하지만 문제가 있습니다. 아무것도 누적되지 않는다는 점이에요. 질문할 때마다 LLM은 지식을 바닥부터 다시 발견하고, 매번 파편들을 새로 엮어냅니다. 다섯 개의 문서를 종합해야 풀리는 미묘한 질문이라면, LLM은 매 쿼리마다 그 조각들을 다시 찾아서 연결해야 합니다. 기억도, 상호 참조도, 축적된 이해도 없습니다.

LLM 위키 패턴은 이 구조를 뒤집습니다. 쿼리 시점에 검색하는 게 아니라, 미리 LLM이 영속적인(persistent) 상호 연결 위키를 만들어 둡니다. 상호 참조는 이미 걸려 있고, 모순은 이미 플래그가 붙어 있고, 종합(synthesis)은 이미 지금까지 투입된 모든 자료를 반영합니다. 지식이 한 번 쓰고 버려지는 게 아니라 복리로 쌓입니다(compound).

Karpathy의 표현을 그대로 빌리면: LLM이 구조화되고 상호 연결된 마크다운(markdown) 파일들로 이루어진 영속적 위키를 점진적으로 짓고 유지하는데, 이 위키가 여러분과 원본 자료(raw sources) 사이에 앉아 있게 된다는 것.

결정적인 부분은 위키를 여러분이 직접 쓰지 않는다는 점입니다. LLM이 전부 쓰고 유지합니다. 여러분은 중요한 일—좋은 출처를 찾고, 탐색하고, 옳은 질문을 던지는 일—에 집중하면 됩니다. LLM은 요약, 상호 참조, 정리, 기록 같은 잡일(grunt work), 즉 지식 베이스를 유용하게 만들지만 아무도 손대고 싶어 하지 않는 일을 전부 떠맡습니다.

3계층 아키텍처

Karpathy가 설명한 기본 아키텍처는 세 개의 층(layer)으로 꽤 깔끔하게 나뉩니다.

왼쪽: 원본 자료(raw sources). 기사, 논문, 이미지, 데이터셋 등 여러분이 수집하는 모든 것. 이 분야에 있는 사람이라면 흥미로운 글, 트윗, GitHub 저장소를 자주 발견할 겁니다. 이것들이 원본이고, 불변(immutable) 입니다. LLM은 읽기만 하고 절대 수정하지 않습니다. 진실의 출처(source of truth) 역할이죠.

가운데: 위키 그 자체. LLM이 전적으로 소유하는 마크다운 파일들의 디렉터리입니다. 요약 페이지, 엔티티(entity) 페이지, 개념(concept) 페이지, 비교 페이지 등이 들어갑니다. LLM이 이것들을 직접 만들고, 새 자료가 들어올 때마다 갱신하고, 모든 상호 참조를 유지하며 일관성을 지킵니다.

오른쪽: 스키마(schema). 구성 파일입니다. 예를 들면 CLAUDE.md 같은 형태로, LLM에게 위키가 어떻게 구조화돼 있는지, 컨벤션이 무엇인지, 어떤 워크플로를 따라야 하는지 알려 주는 역할입니다. 여러분과 LLM이 시간이 지나면서 여러분 도메인에 맞게 함께 진화시켜 나갑니다.

비유하자면—위키는 코드베이스고, 옵시디언(Obsidian)은 IDE, LLM은 프로그래머, 스키마는 스타일 가이드입니다.

세 가지 핵심 작업: 인제스트, 쿼리, 린트

1. 인제스트(ingest). 새 원본을 raw 폴더에 떨어뜨리고 LLM에게 처리하라고 시킵니다. LLM은 출처를 읽고, 요약 페이지를 쓰고, 인덱스를 갱신하고, 관련된 모든 기존 페이지에 상호 링크를 겁니다. 출처 하나가 위키 10~15페이지를 건드릴 수도 있습니다.

2. 쿼리(query). 위키에 질문을 던집니다. LLM은 인덱스를 검색하고 관련 페이지들을 읽어 답을 종합합니다. 영리한 부분은 이겁니다—좋은 답은 그 자체로 새 페이지로 위키에 다시 적립됩니다. 그래서 탐색 과정도 인제스트된 자료처럼 지식 베이스에 복리로 쌓입니다.

3. 린트(lint). 유지보수 패스(maintenance pass)입니다. LLM에게 위키 건강 상태를 점검하라고 시킵니다. 모순, 낡은 주장, 링크가 끊긴 고아 페이지, 빠진 상호 참조, 웹 서치로 채울 수 있는 공백 등을 찾아내게 하는 거죠. LLM은 조사해 볼 만한 새 질문을 제안하는 데도 꽤 능숙합니다. 이 과정을 통해 위키가 커져도 건강하게 유지됩니다.

인제스트가 일어나면 벌어지는 일

이 패턴의 진짜 힘은 인제스트 단계에 있습니다.

1. LLM이 원본을 읽는다.
2. 핵심 정보(개념, 엔티티, 주장, 데이터 포인트)를 추출한다.
3. 메타데이터와 태그를 단 요약 페이지를 위키에 쓴다.
4. 기존 엔티티·개념 페이지들을 전부 갱신해 새 정보를 이미 알려진 것과 통합한다.
5. 기존 주장과 충돌하는 내용이 있으면 모순으로 플래그한다.
6. 위키의 마스터 카탈로그인 인덱스를 갱신한다.
7. 무엇이 언제 바뀌었는지 타임스탬프가 찍힌 로그에 추가한다.

출처 하나가 들어올 때마다 위키 전체가 조금씩 더 똑똑해집니다. 이것이 복리 효과입니다.

인간과 LLM의 역할 분담

역할 분담은 꽤 깔끔합니다.

• 인간은 질문을 큐레이팅(curating)하고 생각합니다. 출처를 고르고, 분석 방향을 정하고, 좋은 질문을 던지고, 무엇이 진짜로 중요한지 판단합니다.
• LLM 에이전트는 요약하고, 상호 참조를 걸고, 유지합니다. 위키 페이지를 전부 작성하고, 크로스 레퍼런스를 최신으로 유지하고, 요약을 관리하고, 모순에 플래그를 답니다.

왜 이게 작동할까요? Karpathy가 잘 짚었습니다. 사람이 위키를 포기하는 이유는 유지보수 부담이 가치보다 빨리 늘어나기 때문입니다. 규모가 어느 정도 커지면 유지 자체가 중노동이 되죠. 그런데 LLM은 지루해하지 않고, 상호 참조 갱신을 잊지 않으며, 한 번의 패스로 15개 파일을 건드릴 수 있습니다. 유지 비용이 사실상 0에 수렴하기 때문에, 위키는 제대로 유지됩니다.

이 접근이 이기는 네 가지 원칙

1. 명시적(explicit)이다. 지식이 탐색 가능한 위키에 전부 가시적으로 드러납니다. AI가 무엇을 알고 무엇을 모르는지 직접 확인할 수 있습니다. 숨겨진 임베딩(embedding)도, 불투명한 메모리 시스템도 없습니다.

2. 당신 것이다. 직접 커스터마이즈할 수 있고, 전부 로컬 파일입니다. 특정 제공자의 시스템에 묶이지 않고, 모든 걸 본인이 보관합니다.

3. 앱보다 파일(file over app). 모든 것이 마크다운·이미지 같은 범용 포맷입니다. 어떤 도구, CLI, 뷰어와도 호환되고, Unix 툴킷 전부가 내 데이터 위에서 그대로 작동합니다.

4. 원하는 AI를 가져올 수 있다(bring your own AI). Claude, ChatGPT, Codex, 오픈소스 모델 뭐든 붙일 수 있습니다. 더 나아가 자기 위키로 모델을 파인튜닝(fine-tuning)해서, 컨텍스트뿐 아니라 가중치에도 지식이 들어가게 만들 수도 있습니다. 아마 이게 다음 단계일 겁니다.

어디에 쓸 수 있나

이 패턴은 도메인이 꽤 넓습니다.

• 리서치: 수 주, 수 개월에 걸쳐 한 주제를 깊이 파고드는 경우. 논문을 읽고 점진적으로 발전하는 테제(thesis)와 함께 포괄적인 위키를 쌓아 갈 수 있습니다.
• 개인: 목표, 건강, 자기계발을 트래킹하며 시간이 지나면서 자신의 구조화된 초상을 쌓아갈 수 있습니다.
• 비즈니스: Slack, 회의록, 고객 통화로부터 먹이를 받는 사내 위키. LLM이 유지보수를 맡으니 항상 최신 상태입니다.
• 독서: 책의 각 장을 채우고, 등장인물·주제 페이지를 구축합니다.
• 실사(due diligence): 투자·리서치 실사용.

데모: 트레이딩 전략 위키 만들기

영상 후반부에서는 Claude Code와 Opus 4.6을 써서 트레이딩 전략용 위키를 실제로 만듭니다.

먼저 Claude에게 Karpathy 트윗을 포함해 이 패턴을 구현한 여러 사람들의 트윗을 전부 먹입니다. Yuchen Jin은 이 구조를 정말 깔끔한 다이어그램으로 정리해 놨더군요.

Claude Code는 플랜 모드(plan mode)로 시작합니다. “이걸 만드는 계획을 짜라”고 시키면, 문서를 탐색한 뒤 아키텍처를 계획합니다. 작성자는 긴 트레이딩 영상의 트랜스크립트 8개를 시드 원본 자료로 갖고 있는 상태에서 시작합니다.

플랜의 결과는:

• 디렉터리 구조 생성
• 트랜스크립트 파일을 원본 자료로 복사
• 스키마 역할을 할 CLAUDE.md 작성 (옵시디언 스타일 위키링크를 사용)
• 위키 로그 만들기
• 개념 페이지 시드(market structure, liquidity, strategy and execution, psychology 같은 최상위 개념들)
• 위키 인덱스 페이지 만들기
• 원본 자료 전부 인제스트

스캐폴드가 완성된 뒤, 두 개의 에이전트를 병렬로 띄워 원본 8개를 인제스트하고, 요약을 만들고, 개념 페이지를 갱신합니다. 초기 인제스트가 끝나면 옵시디언으로 열어 봅니다. Karpathy도 옵시디언을 IDE 비슷하게 쓴다고 언급했죠. 가볍고, 파일 구조와 링크 관계가 한눈에 보입니다. 예를 들어 “identity shift protected stops” 같은 페이지에 들어가면 “draw on liquidity” 같은 다른 페이지로 가는 링크들이 걸려 있는 게 보입니다.

위키에 질문해 보기

진짜 재미있는 부분은 이제부터입니다. “draw on liquidity를 설명해 줘”라고 물으면, LLM은 웹 서치 없이 위키 파일들을 읽어서 답을 줍니다. 핵심 아이디어, 종류, qualifying vs disqualifying draws, 구체적 예시, 다른 개념과의 연결 관계까지요.

“그럼 draw on liquidity는 차트상에 어떻게 나타나?”라고 후속 질문을 하면, failure swings와 unfilled fair value gaps 같은 형태로 나타난다고 위키에서 읽어 답합니다.

여기서 재미있는 일이 벌어집니다. “이것들을 식별할 다른 방법이 있어?”처럼 위키에 없는 정보가 필요한 질문을 던지면, LLM이 웹 서치로 외부를 조사한 뒤 찾은 새 정보로 위키를 자동 백필(backfill) 합니다. 실제로 4~5개의 식별 방법을 새로 찾아와 order blocks, breaker blocks, equal highs/lows 같은 새 개념 페이지를 만들었습니다. 다음에 이 개념들에 대해 물으면 더는 웹 서치할 필요가 없죠.

Claude가 스스로 정리해 준 대로: “이것이 바로 위키가 성장해야 하는 방식입니다. 당신이 질문했고, 저는 위키 바깥까지 조사했고, 새 지식이 영구 페이지로 다시 적립되었습니다.”

이 방식으로 답을 받는 것에 그치지 않고, 마크다운 파일, 슬라이드쇼, matplotlib 이미지를 만들게 한 뒤 옵시디언에서 전부 보는 식으로 시각화도 커스터마이즈할 수 있습니다.

시간이 지나면 거대한 지식 베이스가 쌓이고, 옵시디언에서 breaker blocks 같은 개념이 관련 개념·링크들과 함께 깔끔하게 연결돼 보입니다.

마무리

Karpathy가 지난주 꺼낸 이 핵심 아이디어를 오늘 함께 만들어 봤습니다. 기본 버전은 Claude Code로 한 시간 정도면 충분합니다. 이후 원하는 대로 커스터마이즈하면 되고, 이게 특별히 강력한 건 커스터마이즈할 여지가 정말 많다는 점입니다.

자신이 어떻게 자기 지식 베이스를 구축하고 있는지, 더 나은 아이디어가 있는지 댓글로 공유해 주시면 감사하겠습니다.

Karpathy의 LLM 위키: RAG의 다음 수순, 스스로 자라는 지식 베이스

원본: YouTube — Karpathy’s LLM Wiki: What It Means & How to Build One · 업로드: 2026-04-06 · 길이: 17m · 채널: Onchain AI Garage

서론 — “RAG 이후”의 지식 관리

지난 두 해 동안 “LLM에 문서를 붙이는 방법”의 표준은 사실상 RAG(retrieval-augmented generation, 검색 증강 생성)였다. 문서를 청크로 쪼개고, 벡터 임베딩(embedding)으로 인덱싱하고, 질문이 올 때마다 관련 청크를 끌어와 답을 만드는 방식이다. 그런데 2026년 4월 초, Andrej Karpathy가 트위터에 올린 짧은 글(원문)이 꽤 빠르게 퍼졌다. 핵심은 이렇다: 자기 최근 토큰 사용량의 큰 부분이 더 이상 코드가 아니라 지식을 다루는 데 쓰이고 있다는 것. 그리고 그 지식을 다루는 방식이 RAG가 아니라, LLM이 스스로 유지하는 마크다운 위키라는 것.

이 영상은 그 트윗을 읽고 개념을 정리한 뒤, Claude Code와 Opus 4.6으로 트레이딩 전략용 LLM 위키를 실제로 만들어 보는 17분짜리 워크스루(walkthrough)다. 이 문서에서는 영상의 내용을 토대로, 왜 이 패턴이 주목받는지, 아키텍처가 어떻게 구성되는지, 그리고 실제로 만들 때 어떤 선택지가 있는지를 정리한다.

본론

1. RAG는 왜 부족한가 — “매번 처음부터 다시 짜 맞추는 기억”

Karpathy와 이 영상의 발표자가 공통적으로 지적하는 RAG의 한계는 한 문장으로 요약된다. “아무것도 누적되지 않는다.” 쿼리할 때마다 LLM은 관련 청크를 끌어와 답을 만들고, 그 과정에서 수행한 추론은 다음 쿼리가 오면 사라진다. 다섯 개의 문서를 종합해야 풀리는 미묘한 질문이라면, 매 쿼리마다 그 연결을 새로 만들어야 한다. 문서가 늘수록 이 비용은 커지는데, 정작 “지금까지 내가 쌓은 이해”는 남지 않는다.

LLM 위키 패턴은 이걸 시간축에서 뒤집는다. 쿼리 시점에 검색하는 게 아니라, 인제스트 시점에 미리 짓는다. 쿼리가 오기 전에 이미 상호 참조가 걸려 있고, 모순은 플래그되어 있으며, 요약·종합 페이지가 준비돼 있다. VentureBeat의 정리 기사는 이를 “RAG를 우회해 AI가 유지하는, 계속 진화하는 마크다운 라이브러리”로 표현한다. 핵심 비용은 쿼리가 아닌 유지보수 쪽으로 옮겨 가는데, 이 유지보수는 LLM이 처리한다.

2. 3계층 아키텍처 — raw / wiki / schema

영상이 제시하는 구조는 Karpathy의 원래 설명과 정확히 맞물린다(GitHub gist: llm-wiki).

• raw/: 원본 자료(기사, 논문, 트윗, 데이터셋, 이미지, 트랜스크립트). 불변(immutable) 이고, 진실의 출처(source of truth)다. LLM은 읽기만 하고 수정하지 않는다.
• wiki/: LLM이 전적으로 소유하는 마크다운 파일 디렉터리. 요약, 엔티티, 개념, 비교 페이지가 들어간다. 새 자료가 들어올 때마다 LLM이 직접 작성·갱신하고, 모든 상호 참조의 일관성을 지킨다.
• schema (예: CLAUDE.md 같은 설정 파일): 위키의 구조, 컨벤션, 워크플로를 LLM에게 알려주는 스타일 가이드. 도메인에 맞게 시간이 지나면서 사람과 LLM이 함께 다듬어 간다.

영상의 비유를 그대로 빌리면 — “위키는 코드베이스, Obsidian은 IDE, LLM은 프로그래머, 스키마는 스타일 가이드”다. Karpathy 본인이 Obsidian을 IDE처럼 쓴다고 언급했고, 실제로 많은 구현체가 Obsidian 스타일의 위키링크([[...]])를 채택한다. 커뮤니티 구현체로는 Ar9av/obsidian-wiki나 NicholasSpisak/second-brain 같은 예시가 이미 나와 있다.

3. 세 가지 핵심 작업 — ingest / query / lint

Karpathy의 gist가 명시하는 위키의 “작동 모드”는 세 가지다.

1. Ingest. raw/에 새 자료를 떨어뜨리면, LLM이 읽고, 요약 페이지를 쓰고, 인덱스를 갱신하고, 관련 있는 기존 페이지 10~15개에 상호 링크를 건다. 출처 하나가 여러 페이지를 동시에 건드리며 위키 전체가 조금씩 더 똑똑해진다. 이것이 복리 효과(compounding) 다.
2. Query. 위키에 질문을 던지면 LLM이 인덱스를 검색하고 관련 페이지를 읽어 답을 종합한다. 흥미로운 부분은 좋은 답이 새 페이지로 위키에 다시 적립된다는 것. 탐색의 결과물이 인제스트된 원본과 동등한 자산이 된다.
3. Lint. 주기적인 유지보수 패스. 모순된 주장, 오래된 사실, 고아 페이지, 빠진 상호 참조, 웹 서치로 채울 공백을 찾아낸다. LLM은 “더 파볼 만한 다음 질문”도 제안할 수 있다.

영상은 이걸 실제로 보여 준다. 발표자가 “draw on liquidity는 차트상에 어떻게 나타나?”라고 묻고, 위키에서 답을 받는다. 그 다음 위키에 없는 질문(“다른 식별 방법이 있냐?”)을 던지자 LLM이 웹을 검색해 외부에서 4~5개의 방법을 찾아오고, 그 결과를 order blocks, breaker blocks, equal highs/lows 같은 새 개념 페이지로 자동 백필한다. 다음부터는 같은 질문에 대해 웹 서치가 필요 없다.

4. 왜 사람은 위키를 포기하는가, 왜 LLM은 안 포기하는가

Karpathy가 이 패턴의 쓸모를 설명할 때 실제로 쓰는 표현은 간결하다. “사람은 위키를 포기한다. 유지보수 부담이 가치보다 빠르게 늘기 때문이다.” 개인 위키, 팀 위키, 사내 위키 전부 같은 궤적을 겪는다. 파일이 100개를 넘어가면 상호 참조 갱신이 노동이 되고, 500개를 넘어가면 거의 아무도 손대고 싶어 하지 않는다.

LLM의 구조적 이점은 감정이나 능력이 아니라 지루함의 부재에 있다. 상호 참조 15개를 한 번의 패스로 동시에 갱신하는 일은 사람에겐 고통스럽지만 LLM에겐 그냥 파일 I/O다. 유지 비용이 0에 수렴하면, “위키가 제대로 유지된 상태로 남는다”는 지금까지 실현된 적 없는 조건이 현실적으로 가능해진다. 이게 이 패턴이 단순히 “RAG의 변종”이 아니라 구조적 전환으로 받아들여지는 이유다.

5. 영상이 담지 않는 실전 이슈들

영상은 개념 소개와 간단한 데모에 집중하기 때문에, 실전 운영에서 부딪히는 문제 몇 가지는 다루지 않는다. 몇 가지 관찰 사항을 덧붙인다.

• 스키마 없이는 위키가 난잡해진다. CLAUDE.md(또는 동등한 설정 파일)에서 페이지 타입, 파일명 규칙, 링크 규칙을 구체적으로 정의해 두지 않으면, 에이전트가 매번 다른 방식으로 파일을 쓴다. Karpathy가 스키마를 “스타일 가이드”라고 부른 건 정확히 이 때문이다.
• 모순 처리는 선언적으로 해 둬야 한다. 모순이 생겼을 때 “새 정보가 이긴다”인지 “두 주장을 다 남기고 사람이 판단한다”인지는 도메인마다 다르다. 스키마에서 규칙으로 못 박아 두는 쪽이 안전하다.
• 웹 백필에는 출처 정책이 필요하다. LLM이 외부 검색으로 위키를 확장할 수 있는 건 강력한 기능이지만, 그만큼 낚인 출처나 광고성 자료가 위키에 침투할 위험도 함께 생긴다. 도메인 화이트리스트, 신뢰도 점수, “출처 없으면 쓰지 않는다” 같은 규칙이 보통 필요하다.
• 인제스트는 한 번에 여러 에이전트를 병렬로. 영상에서도 두 개의 서브 에이전트가 동시에 raw/를 인제스트한다. 파일 경합을 피하려면 “에이전트별로 다른 원본 파일 세트를 본다” 같은 단순한 파티셔닝이 필요하다.

핵심 인사이트

• RAG는 쿼리 시점에 추론하고, LLM 위키는 인제스트 시점에 추론한다. 비용이 옮겨가는 방향이 다르다는 것이 실제 사용자 경험의 거의 모든 차이를 만든다.
• 지식은 복리로 쌓여야 가치가 있다. 한 번 쓰고 버리는 답은 규모의 불경제를 만들고, 쌓이는 답은 규모의 경제를 만든다.
• 에이전트가 유지보수의 주체가 되는 순간, 사람이 못 하던 일이 가능해진다. 위키의 실패는 늘 “유지 실패”였고, 그 비용이 0으로 수렴하면 실패 모드 자체가 사라진다.
• 파일 기반(file-over-app) 선택이 결정적이다. 마크다운·이미지·텍스트는 어떤 벤더에도 묶이지 않고, Unix 툴킷 전체가 그대로 작동하며, 다른 LLM·에이전트에 그대로 이식할 수 있다. 벡터 DB 기반 RAG에서는 이식성이 거의 없다.
• 스키마가 곧 성공의 예측 변수다. 같은 원본, 같은 LLM이라도 스키마가 느슨하면 3일이면 무너지고, 촘촘하면 3개월이 지나도 일관성이 유지된다.

더 알아보기

• llm-wiki · GitHub gist (Karpathy 원문) — Karpathy가 직접 정리한 “idea file”. 아키텍처, 작동 모드, 도구 얘기가 개념 수준으로 담겨 있다.
• Andrej Karpathy on X — “LLM Knowledge Bases” — 이 모든 논의의 시작점이 된 원 트윗.
• VentureBeat — Karpathy shares ‘LLM Knowledge Base’ architecture — 언론 관점에서 RAG 비교, 파급력, 업계 반응을 정리한 기사.
• Ar9av/obsidian-wiki — GitHub — Obsidian 위에서 이 패턴을 돌리는 실제 구현체 예시.
• NicholasSpisak/second-brain — GitHub — “개인 세컨드 브레인”을 LLM 위키 패턴으로 구현한 오픈소스 프로젝트.
• MindStudio — How to Build a Personal Knowledge Base With Claude Code — Claude Code 관점에서의 실전 가이드, 이 영상과 가장 겹치는 맥락.

토론: “LLM 위키가 RAG의 다음 수순인가?”

논제: 이 영상이 제시하는 핵심 주장 — “개인·연구용 지식 관리에서 LLM이 유지하는 마크다운 위키(LLM wiki)가 RAG(검색 증강 생성)보다 구조적으로 더 나은 패턴이다” — 은 얼마나 견고한가.

Round 1

🟢 Pro — “이것은 단순한 변종이 아니라 구조적 전환이다”

첫째, 비용이 옮겨 가는 방향이 근본적으로 다르다. RAG는 매 쿼리마다 청크를 검색하고 그 자리에서 추론을 조립한다. 다섯 개 문서에 흩어진 사실을 종합해야 풀리는 질문은 쿼리를 할 때마다 처음부터 다시 연결돼야 한다. LLM 위키는 그 추론을 인제스트 시점에 미리 치러 두고, 결과를 영속적인 마크다운 페이지로 적립한다. 쿼리 시점에는 그냥 읽으면 된다. 같은 질문이 반복될수록, 그리고 질문들이 서로 연결될수록, 이 비용 구조는 기하급수적으로 유리해진다.

둘째, 파일 기반(file-over-app) 선택이 이식성과 감시성을 동시에 해결한다. 마크다운·이미지·텍스트는 어떤 벤더에도 묶이지 않고, 사람이 직접 열어 볼 수 있으며, Unix 툴킷 전부가 그대로 작동한다. VentureBeat의 정리(기사)가 짚은 대로, “AI가 유지하는 진화하는 마크다운 라이브러리”는 벡터 DB 기반 RAG에서는 불가능한 수준의 투명성을 준다. AI가 무엇을 알고 무엇을 모르는지 디렉터리만 열어도 확인되는 것이다. 숨겨진 임베딩, 불투명한 메모리가 없다.

셋째, 사람이 위키를 포기하는 이유가 구조적으로 제거된다. 위키의 실패 모드는 늘 “유지 실패”였다. 파일이 100개를 넘어가면 상호 참조 갱신이 노동이 되고, 500개를 넘기면 아무도 손대지 않는다. Karpathy가 정리한 gist(llm-wiki)가 결정적인 이유는, 유지 비용을 0에 수렴시키는 주체를 LLM에게 넘겼기 때문이다. 한 번의 패스로 15개 파일을 동시에 건드리는 작업이 사람에게는 고통스럽지만 LLM에게는 그냥 파일 I/O다.

🔴 Con — “개인 생산성 해킹을 아키텍처로 오해하면 안 된다”

첫째, 스케일 상한이 명확하다. Epsilla의 분석(기사)과 Atlan의 비교(기사)가 같은 수치를 제시한다. LLM 위키가 안정적으로 작동하는 범위는 대략 100400개 문서, 50,000100,000 토큰 규모다. Karpathy 본인의 위키조차 약 100개 문서, 40만 단어에서 “컴파일 시간이 길어지고 인덱스 일관성이 떨어진다”는 궤적을 보인다고 알려져 있다. RAG는 수백만 문서를 다룰 수 있는데, LLM 위키는 컨텍스트 윈도우가 구조적 상한이다. “RAG의 대체”라고 말하려면 이 한계를 정면으로 인정해야 한다.

둘째, 닫힌 인식 루프(closed epistemic loop)가 위험하다. LLM이 위키를 만들고, 유지하고, 쿼리한다면 — 인제스트 단계의 해석 오류가 위키 페이지에 구워져서 이후 모든 쿼리가 그 오류를 진실로 참조한다. v2solutions의 정리(기사)와 SSGM 프레임워크 논문(arXiv)이 지적한 메모리 독성(memory poisoning), 의미적 표류(semantic drift), 검색 시점 충돌/할루시네이션이 바로 이 시나리오다. 영상이 자랑스럽게 보여 주는 “LLM이 웹에서 새 정보를 찾아와 위키에 백필하는” 장면은 동시에 검증되지 않은 외부 자료가 위키의 영구 페이지로 구워지는 장면이기도 하다.

셋째, 엔터프라이즈 현실을 무시한다. Obsidian이 열려 있는 로컬 디렉터리는 보안·접근 제어·멀티유저·감사 어느 하나도 제공하지 않는다. Epsilla가 지적한 대로, 이것은 개인 생산성 해킹이지 조직 아키텍처가 아니다. “RAG가 죽었다”는 헤드라인은 자극적이지만, 실제로는 “내 개인 연구 노트 100개 파일 정도까지는 RAG보다 나은 패턴이 있다”는 훨씬 좁은 명제가 정확하다.

Round 2

🟢 Pro (재반론)

Con이 첫째로 제기한 “100~400개 문서라는 스케일 상한” 논점부터. 이 수치는 사실이지만, 그걸 약점으로 제시하는 건 논점 흐리기다. 대부분의 실제 쿼리는 특정 주제의 하위 위키 안에서 일어난다. Karpathy의 원래 설계(gist)는 위키를 주제별로 분할(shard)하는 것을 명시적으로 허용한다. 트레이딩 전략 위키, 리서치 위키, 비즈니스 위키가 각각 100~400 규모로 독립적으로 유지될 수 있다. “수백만 문서”라는 숫자는 RAG가 해결한다고 주장하는 문제이지, 개인/팀 연구자가 실제로 마주하는 워크로드가 아니다.

Con이 둘째로 든 “닫힌 인식 루프” 우려는 더 흥미로운 쟁점이지만, 방향이 거꾸로 돌아간다. RAG 역시 닫힌 인식 루프다. 다만 루프의 결과물이 마크다운 페이지가 아니라 벡터 공간 안의 보이지 않는 임베딩일 뿐이다. Glean의 분석(기사)이 명시하듯, RAG의 대표적 할루시네이션 원인은 인덱스에 남아 있는 낡은 문서다. 차이는 — LLM 위키에서는 잘못 구워진 주장을 사람이 grep으로 찾아 수정할 수 있고, RAG에서는 그럴 수 없다는 것. Con이 제기한 위험은 실재하지만, 그것은 위키 패턴의 취약점이 아니라 가시성이 있기 때문에 드러나는 취약점이다.

Con의 셋째 논점 “엔터프라이즈 아키텍처가 아니다” 에는 한 발짝 양보한다. 맞다. 하지만 Karpathy도 이 영상의 발표자도 “엔터프라이즈 아키텍처”라고 주장한 적이 없다. 연구자, 개인, 소규모 팀의 지식 관리가 타깃이고, 그것이 전체 지식 작업의 압도적 다수다. “엔터프라이즈에 적합하지 않다”는 명제는 참이지만, “따라서 패턴 자체가 약하다”는 결론은 따라오지 않는다.

🔴 Con (재반박)

Pro의 재반론 첫째인 “주제별 샤딩(shard)” 논점은 문제를 숨기는 방식이다. 주제별로 위키를 쪼개면 각 위키 안에서는 일관성이 유지되지만, 주제 경계를 가로지르는 쿼리는 사라진다. 그런데 영상이 자랑한 바로 그 장면 — “다섯 개 문서를 종합해야 풀리는 미묘한 질문” — 이 경계를 넘나들 때 가장 유용하다. 샤딩은 스케일 문제를 해결하지 않는다. 해결된 문제를 덜 유용하게 재정의할 뿐이다. 결과적으로 Pro가 원래 주장한 “복리로 쌓이는 종합”의 영역이 축소된다.

Pro의 둘째 재반론 “RAG도 닫힌 루프지만, LLM 위키는 가시적이라 grep으로 고칠 수 있다” 는 논점은 표면적으로는 깔끔한데, 실제 운영 상황을 생략한다. 누가 grep으로 고치는가? 사람이다. 그런데 이 패턴의 매력 포인트는 처음부터 “사람의 유지 부담이 0에 수렴한다”였다. 가시성을 유지하려면 사람이 주기적으로 감사해야 하고, 감사를 하려면 다시 유지 비용이 발생한다. “LLM이 다 한다”와 “사람이 grep으로 수정할 수 있어서 안전하다”는 동시에 성립하지 않는다. Pro는 문제가 나올 때마다 다른 쪽 약속으로 넘어갔다 왔다 하고 있다.

Pro의 셋째 재반론 — “엔터프라이즈는 목표가 아니다” — 에 대해선, 그 양보가 이 패턴의 마케팅과 충돌한다는 점을 짚어야 한다. VentureBeat 같은 매체가 이 패턴을 다루는 방식(기사)은 “RAG 우회”, “RAG 대체” 같은 프레이밍이다. 커뮤니티 구현체들도 “개인 생산성 도구” 이상의 스케일을 약속한다. Pro가 양보한 “개인·소규모 팀용 패턴”은 정직한 범위인데, 담론이 그 범위에서 머물러 있지 않다. 이 점을 Pro가 인정하는 것은 중요한 수정이다.

Round 3

🟢 Pro

Con의 재반박 첫째, “샤딩이 주제 경계를 넘는 쿼리를 희생시킨다” 는 지적은 합리적인 경계 사례(edge case)지만, 이를 샤딩의 본질적 실패로 보는 것은 과장이다. 실전에서는 공유 루트 인덱스 + 주제별 위키라는 조합이 가능하다. 각 주제 위키는 독립적으로 유지되지만, 루트 인덱스가 “어떤 주제 어느 페이지에 어떤 개념이 있는지”를 얕게 요약한다. 개념 간 쿼리가 올 때는 루트 인덱스를 읽어 관련 주제 위키를 식별하고, 그 다음 해당 위키들을 깊게 읽는다. 이것은 Con이 주장한 “경계를 넘는 쿼리가 사라진다”와 정면으로 다르다. 실제로 이는 Ar9av/obsidian-wiki, NicholasSpisak/second-brain 같은 커뮤니티 구현체들이 이미 채택하고 있는 패턴이다.

Con의 둘째, “LLM이 다 한다와 사람이 grep으로 고칠 수 있다는 동시에 성립하지 않는다” 는 지적은 이 토론에서 가장 날카로운 점이고, 솔직히 절반은 맞다. 그래서 정직한 재정식화는 이렇다: 이 패턴은 “유지 비용을 0으로 만든다”가 아니라 “유지 비용의 90%를 LLM에게 넘기고, 사람은 10%의 감사(audit) 역할만 한다” 이다. 그 10% 감사의 도구가 grep, Obsidian 그래프 뷰, Git diff다. RAG에서는 이 10% 감사조차 할 방법이 없다(임베딩 공간을 grep할 수는 없다). Con의 지적은 이 패턴의 약속을 과소수정하지 않고 정확하게 수정하게 해 준 기여다.

Con의 셋째 지적 — “담론이 ‘개인·소규모 팀’ 범위에 머물지 않고 ‘RAG 킬러’ 프레이밍으로 과장된다” — 에 대해서는 전적으로 동의한다. 매체 헤드라인의 과장은 실제 기술 주장과 구분해야 한다. 이 영상 자체는 트레이딩 위키라는 구체적·개인적 사례를 다루고 있고, 원 gist의 범위도 개인 리서치다. 과장은 주변 담론이 만들어 낸 것이고, 패턴 자체의 평가와는 별개다.

🔴 Con

Pro의 “공유 루트 인덱스” 해결책에는 경계 조건의 부담이 거기로 옮겨 간다는 점을 지적해야 한다. 루트 인덱스가 얕은 요약이면 개념 간 쿼리는 복원되지만 정밀도가 떨어지고, 깊은 요약이면 다시 컨텍스트 상한 문제로 돌아온다. 이건 “샤딩이 유효한 해결책”이라기보다 “샤딩과 통합 중 하나를 골라야 한다”는 트레이드오프다. Pro가 마치 아키텍처 선택으로 해결된 문제처럼 말하는 것은 정확하지 않다. 다만 트레이드오프로 인정한다면, 이 논점은 양쪽이 합의할 수 있다.

Pro가 둘째에서 “유지 비용 0 → 90%를 LLM이, 10%를 사람이” 로 정식화한 부분은 이 토론의 가장 가치 있는 수정이다. 정직하게 말해서, 이 재정식화가 맞다면 원래 영상의 메시지는 바뀌어야 한다. “위키가 자동으로 유지된다”는 표현은 과장이고, 정확히는 “위키 유지가 LLM에게 델리게이트되며, 사람의 감사 책임은 남는다”이다. 이 차이는 실전 운영에서 누가 감사를 언제 하는지를 정책으로 명시해야 함을 뜻한다. Lint 패스를 “유지보수 모드”로만 기술하는 Karpathy의 원 gist는, 이 정책 레이어를 독자에게 숙제로 떠넘긴 셈이다.

Pro가 셋째에서 담론의 과장을 인정한 것은 좋은 수정이다. 그러나 하나 더 덧붙여야 한다. 가장 위험한 실수는 이 패턴을 RAG의 대체로 받아들이는 것이 아니라, RAG의 문제를 전혀 해결하지 않는다는 점을 잊는 것이다. 여전히 원본 선정의 편향, 인제스트 해석의 오류, 외부 검색의 신뢰도 문제는 남는다. 이 패턴이 해결한 것은 지식의 재사용 경제이고, 해결하지 않은 것은 지식의 진실성이다. 이 구분을 유지하면, 양쪽 모두 실전에서 안전하게 쓸 수 있다.

🧭 종합

합의 지점

• 이 패턴은 RAG의 대체가 아니라 RAG의 보완이다. 적용 범위는 주로 개인·연구자·소규모 팀의 지식 관리이고, 문서 수 100400개, 토큰 50k100k 규모에서 가장 유효하다.
• 비용이 옮겨 가는 방향이 실제로 유리하다. 인제스트 시점에 종합을 미리 치러 두는 구조는, 반복·연결 쿼리가 많은 워크로드에서 RAG 대비 구조적 우위를 준다.
• 파일 기반(file-over-app)의 가시성은 본질적 장점이다. Obsidian 그래프 뷰, Git diff, grep으로 사람이 감사할 수 있다는 것은 실제로 할루시네이션·표류를 줄이는 수단이 된다.
• “유지 비용 0”은 과장이다. 정확한 표현은 “유지의 90%를 LLM에게 넘기고, 사람이 10%의 감사를 수행한다”이다. 이 10%는 공짜가 아니고, 정책으로 명시돼야 한다.

열린 질문

• 주제 경계를 넘는 쿼리를 어떻게 유지할 것인가. 공유 루트 인덱스 + 샤딩의 트레이드오프는 아직 업계 베스트 프랙티스가 없다.
• 닫힌 인식 루프 안에서 오류가 구워지는 것을 어떻게 감지할 것인가. Lint 패스의 주기와 감사 도구는 도메인마다 달라야 한다.
• 외부 검색으로 위키를 백필할 때의 출처 정책. 도메인 화이트리스트, 신뢰도 점수, “출처 없으면 쓰지 않는다” 같은 규칙이 없으면, 편한 확장이 곧 위키 오염의 경로가 된다.
• 이 패턴이 과연 엔터프라이즈로 일반화될 수 있는가. 보안, 접근 제어, 감사, 멀티유저 이슈를 해결하는 순간 원래의 “단순함” 매력은 상당 부분 증발한다.

더 나아간 관점

이 영상과 그 원 트윗이 정말로 바꾸려 하는 건 RAG 파이프라인이 아니라 지식 노동의 경제다. RAG는 “문서가 있고, 질문이 있고, 답이 나온다”라는 거래적(transactional) 모델을 전제한다. LLM 위키는 “지식은 누적되어야 가치가 있다”는 자본(capital) 모델을 전제한다. 전자는 질문을 비용으로 본다. 후자는 질문을 투자로 본다.

이 관점에서 보면, 다음 수순은 RAG 대 LLM 위키의 이항 대결이 아니라 지식을 자본으로 다루는 인프라 전체다. Git·CI/CD가 코드 자본의 인프라였듯, LLM 위키는 지식 자본의 초기 인프라일 수 있다. 그렇게 본다면 영상이 보여 준 트레이딩 전략 위키는 데모가 아니라 조짐이다. 다음에 누군가 만들어야 할 것들은 — 위키 버전 관리, 감사 로그 체계, 주제 간 통합 질의 계층, 외부 검색 출처 신뢰도 엔진, 팀 간 위키 병합 프로토콜 — 전부 이 “지식을 자본으로 다루는” 프레임에서 자연스럽게 따라 나온다.

RAG가 죽는 것도 아니고, LLM 위키가 모든 것을 대체하는 것도 아니다. 진짜 전환은 훨씬 조용하다: “매번 답을 다시 만든다”에서 “답이 쌓여 자산이 된다”로. 이 한 걸음이 평범해 보이지만, 지식 노동의 구조를 바꾼다.

So I'm sure many of you saw this tweet from Andrej Karpathy last week talking about LLM
knowledge bases. They caught a lot of interest as kind of a new way to use AI as a research tool.
And the core concept was to use LLMs to build personal knowledge bases for various topics
of your research interest. He breaks down how he did it here, and there were a couple other
follow-up tweets as well as other researchers and AI enthusiasts talking about the way that
they've done this kind of tooling. So in today's video, we're going to build this for ourselves.
First, I'm going to kind of break down what the concept is and why it's useful compared to other
alternatives. And then we're going to actually build this out together in cloud code. So you'll
see a good example of how you would actually build this out. So wait till the end for that.
So let's start with the problem. Right now, most people's experience with LLMs and documents look
like RAG, R-A-G, retrieval, automation.
made a generation, you upload some files to chat, chat, GBT or notebook, LM or whatever tool. And
when you ask a question, it retrieves some chunks and generates an answer. And that works fine for
simple questions. But here's the issue. Nothing accumulates. Every time you ask a question,
the LM is rediscovering knowledge from scratch. It's repiecing together fragments every single
time. So if you ask something subtle that requires synthesizing five different documents,
it has to find and connect all those pieces on every query. There's no memory, no cross references,
no accumulated understanding. But this LLM powered wiki pattern flips this. Instead of
retrieving at query time, the LM builds a persistent interlink wiki up front. The cross
references are already there. Contradictions are already flagged. The synthesis already reflects
everything you've already fed it. Knowledge compounds instead of being thrown away after
each conversation. And this is the key quote,
from Karpathy. When discussing this, the LM incrementally builds and maintains a persistent
wiki, structured, interlinked, markdown files sitting between you and your raw sources.
And the critical thing is you never write the wiki yourself. The LM writes and maintains
all of it. You're in charge of the important stuff, finding the good sources, exploring,
asking the right questions. The LM handles all the grunt work, the summarizing, the cross
referencing, the filing, bookkeeping, all the stuff that makes knowledge bases useful,
but that no one actually wants to use. So it's a great way to build a good wiki.
There are many ways we can do this, but the basic architecture has three different layers
based on what Karpathy was describing. And it's fairly clean. On the left, you have raw
sources. So articles, papers, images, data sets, whatever you're collecting. I'm sure
most of us who are in this field find interesting articles, find interesting tweets, interesting
GitHubs. And these are your raw sources. And these are immutable. The LM reads them, but
never touches them. They're your source of truth.
In the middle here, you have the raw sources. And these are immutable. The LM reads them,
is the wiki itself, a directory of markdown files that the LM owns entirely, summaries,
entity pages, concept pages, comparisons. The LM creates these, updates them when new
sources come in and maintains all the cross references, keeps everything consistent.
And on the right is the schema. And this is the configuration file, basically, like a Claude MD.
And this tells the LM how the wiki is structured, what the conventions are, what workflows to
follow.
So you and the LLM co-evolve this over time as you figure out what works for your domain.
Think of it like this.
The wiki is the code base, and then Obsidian is the IDE.
And the LLM is the programmer, and the schema is the style guide.
So there are three core operations.
First is to ingest.
You drop a new source into a raw folder and tell the LLM to process it.
It reads the source, writes a summary page, updates the index, and cross-links it across all relevant existing pages.
A single source might touch 10 to 15 wiki pages.
The second is query.
You ask questions against the wiki.
The LLM searches the index, reads the relevant pages, and synthesizes an answer.
And here's kind of the clever part.
Good answers can be filed back into the wiki as new pages.
So your explorations compound in the knowledge base, just like ingested sources do.
And the third is lint.
So this is the maintenance pass.
You ask the LLM to health check the wiki.
Find contradictions.
Stale claims.
Orphan pages with no links.
Missing cross-references.
Gaps that could be filled with a web search.
So the LLM is good at suggesting new questions to investigate.
And this keeps the wiki healthy as it grows.
So what happens when you ingest a source, right?
Because this is where the real power in this is.
So step one, the LLM reads the raw source.
Step two, it extracts key information.
Concepts, entities, claims, data points.
Step three, it writes a summary page in the wiki with metadata and tags.
Step four.
It updates all of the existing entity and concept pages, integrating the new information
into what's already known.
Step five, it flags any contradictions when new data conflicts with existing claims.
Step six, it updates the index, the master catalog of everything in the wiki.
And step seven, it appends to the log, a time-stamped record of what's changed and when.
And seven, so one source drops in and the entire wiki gets a little bit smarter.
So that's the compounding effect.
So here's the division of labor.
And it's pretty clean.
The human curates questions and thinks.
You pick the sources.
You direct the analysis.
You ask the good questions.
You decide what actually matters.
The LLM agent just summarizes cross-references and maintains.
It writes all of the wiki pages.
It keeps cross-references up to date.
It maintains summaries, flags contradictions.
And here's why this works.
Karpathy puts it well.
Humans abandon wikis because the maintenance burden grows faster than the value, right?
It becomes a huge labor just to maintain once these become a certain size.
But nicely, the LLMs don't get bored.
They don't forget to update a cross-reference.
They can touch 15 files in a single pass.
The cost of maintenance drops to near zero.
So the wiki actually stays maintained properly.
So this is why this approach wins.
And there are four principles behind it that make it really compelling.
First, it's explicit.
The knowledge is all visible in a navigatable wiki, which most of us are familiar with.
You can see exactly what the AI knows and what it doesn't know.
There's no hidden embeddings.
There's no opaque memory system.
Second, it's yours.
You can customize it yourself.
These are all local files on your computer.
You're not locked into any provider's system and you keep everything yourself.
Third, it's file over app.
Everything is in universal formats, marked down in images.
This means it's interoperable with any tool, any CLI, any viewer.
The entire Unix toolkit works with on your data.
And fourth, you can bring your own AI.
You can plug in CLAW, GBT, Codex, open source models, whatever you want.
You can even fine tune a model on your wiki so it knows your data in its weights, not just in its context.
And I think that's probably the next step.
So what can you build with this, right?
This pattern applies to a lot of different domains.
Research, obviously, going deep on the topic over weeks and months.
Reading papers, building up a comprehensive wiki with an evolving thesis.
Personal, you can track your goals, health, self-improvement.
You can build a structured picture of yourself over time.
Business, certainly.
An internal wiki fed by Slack, meetings, customer calls, always current because the LLM handles maintenance.
Reading, filling each chapter of a book, building out character and theme pages, and due diligence, obviously.
Today, we're going to build one with trading.
Strategies, which is part of a larger project that I've been working on.
And you'll probably see a video in the coming weeks, me breaking down this project.
But I've been doing a lot of research on advanced trading strategies, and that's the wiki we're going to build today.
So this is kind of the breakdown of what it's going to look like, the directory structure.
And it's the same thing that we've said, the raw sources, the wiki itself, and then the schema and workflows in the Claude file.
Claude, because I'm going to be using this in Claude.
Code with Opus 4.6.
So what the LLM will build will be the strategy pages, the concept pages, the entity pages, cross-referencing, links to everything, and then synthesis pages, comparisons, trade-offs.
So it's time to build it.
I know you're all probably sick of my slides.
So now we're actually going to go in Claude code and build this.
Before we really get into it, if you enjoy this video or find it useful, please leave a like, please subscribe, or share it with your friends.
It helps a lot to grow the channel.
And if you're feeling generous, please leave a tip as a thanks.
It helps me keep making these.
And of course, leave a comment.
I read and try to answer all the comments to the best of my ability.
I really appreciate all the kind words everyone said.
And there are always a ton of really smart, insightful comments and questions that dig deeper into the content of the video.
Now let's get back to it.
I have given Claude a bunch of the tweets.
Like I said, this is the Carpathi tweet.
I've given some others, some of the other users who have done really well.
Farza was one of them.
Yuchen here as well.
Yuchen Jin had this really nice diagram that broke it down.
So I fed this to Claude, along with a couple other tweets, people talking about how they did this.
Okay, so it's going to start out in plan mode, obviously.
We were talking about this concept earlier, but I said, okay, design the plan to build this.
So it entered plan mode.
It's exploring the documents I just showed you, and then it's going to plan the architecture.
So it finished up its plan here.
You could see it's building this LLM wiki pattern.
We're going to be doing it.
Initially, I have eight transcript files, longish videos on trading concepts, and then we could start from here and then build it out.
It has some concepts you could see here.
So it's going to create the directory structure, copy the transcript files.
As the.
The raw sources, it's going to write the Claude MD, which is going to be the schema here that it's going to use.
We're going to be using obsidian style wiki links for everything.
Create the wiki logs, see the concept pages.
You can see what we're working with right now, how granular it's going to get market structure and liquidity strategy and execution psychology.
So it goes into like every general concept.
And you can decide how granular you.
Want to get with this.
And then it's going to create the wiki index page.
Ingest all the raw.
Okay.
So it's got everything here.
Yep.
It looks like a good plan.
So it's going to start building for us.
And it's building out the directories and the transcripts were copied.
Now it's writing the schema file, seeding the concept pages.
Okay.
The scaffolding is complete.
You can see the, all the directories.
The next step is to ingest the eight raw transcripts.
Go ahead.
So it's running two agents right now to ingest the raw sources, create the summaries, and then update the concept pages.
Okay.
The initial ingest is done and now it's pretty much set up the original structure that we need just to visualize it.
Carpathy talks about using obsidian as well as an ID, but you can download this or just ask your agent to download it.
It's a very light file, but this is what we get.
It's probably easier to see.
Uh, it's.
Basic file structure.
You could see all the file here.
This is the wiki has all of the knowledge that you were trying to build up based on it.
You could see what we do here.
Identity shift protected stops.
It has all the links.
You could see the links to other files.
So you have a link to draw on liquidity here if you want to see this.
So this is just a really nice clean visual.
Zation of this, and you could build out a proper front end like this.
I know people have done that, but for my purposes, this is, uh, all I need just to kind of see the information.
Okay.
So lastly, let's try asking it some questions, right?
I asked, can you explain draw on liquidity to me?
And it read the files based on it and gave me an answer without having to go do web searches and check everything else.
Uh, it goes into the core idea of drawn liquidity, types of draws.
Qualifying and disqualifying draws, concrete examples, how it connects to everything else.
So let me ask, um, how do draws on liquidity actually appear?
So it read as well.
This is how it appears on the chart.
Failure swings and unfilled fair value gaps.
And then if I ask you a question, is there any other ways to identify them?
Check outside the wiki.
If I ask any question based on this.
Okay.
If I ask you a question based on this wiki information that it doesn't have on hand, it can then do a web search and then it will go and automatically backfill the wiki with the new information that it found.
So I found several other drawn liquidity identification methods, uh, four of them, five actually.
Uh, so using these resources now, it's going to continue to build out the wiki again.
And this is really how you develop the knowledge base.
It kind of gets smarter on its own as you ask it questions.
And.
If there's information it can't find from the, the wiki itself, it can do quick searches and then backfill it so that it has all the answers later on.
And instead of just answering questions, you can also set it up to create markdown files, slideshows, uh, which is a really useful presentation or matplotlib images.
And then you can all view them in obsidian like that.
So there's a lot of ways you can customize it visually.
So you can see based on the answer, it's writing new concepts, order blocks, breaker blocks, equals.
Equal high lows so that once these concepts and information is inside the wiki, you don't have to go and fetch it every single time you ask about this, these concepts again.
And I'm doing this with Claude with Opus 4.6, but like I said before, you can use any LLM to that does basic research and writing functions or any agent.
You can use the open Claude to do this or Hermes agent.
So as Claude says here, this is exactly how the wiki is meant to grow.
You ask a question.
I researched beyond the wiki.
And the new knowledge got filed back as permanent pages.
So every future query count now reference order blocks, breaker blocks, equal high lows, um, along with the original stuff.
So this is how you really build it up.
And eventually over time, you'd have a really massive knowledge base to work on.
And now you could see in obsidian, it has a breaker blocks as a concept, everything linked together, very easy to understand related concepts and links to everything that you need.
Right.
So that was the core concept from Carpathia.
He talks about this last week, and you just saw us build this together.
There's a lot of, and the great thing is there's a lot of ways to customize this to exactly what you need.
And by doing that, you can create a really powerful knowledge base.
So I hope, I hope you found this video helpful.
We got to break down the concept and then you got to see me build one.
What didn't take that long.
You could probably do it like this basic version in an hour or so and Claude code.
And then customize it.
However you'd like from there, but that's going to be it for today's video, please leave a like subscribe, leave a comment.
Let me know how you're building your own knowledge basis, or if you have any hints to do it better than I did here, you have a lot of great videos lined up for this week.
So please look forward to that.
Thank you for watching.