Ai là Andrej Karpathy?
Andrej Karpathy là một trong những nhân vật quan trọng nhất trong lịch sử AI hiện đại. Ông là co-founder của OpenAI, từng giữ vị trí AI Director tại Tesla, và là tác giả của course nổi tiếng “Neural Networks: Zero to Hero”. Karpathy được biết đến với khả năng giải thích khái niệm phức tạp theo cách dễ hiểu, và luôn tìm tòi các cách tối ưu để làm việc với AI.
Vào tháng 4 năm 2025, Karpathy chia sẻ một insight đơn giản nhưng sâu sắc trên X và GitHub: thay vì cứ dùng RAG (Retrieval-Augmented Generation) để AI tìm kiếm từ đầu mỗi lần, tại sao không để AI biên soạn và duy trì một wiki có cấu trúc liên kết? Khi wiki đủ lớn, bạn có thể hỏi nó bất kỳ câu hỏi phức tạp nào, và LLM sẽ có toàn bộ kiến thức tích lũy sẵn để trả lời. Không cần tìm kiếm, không cần compile on-the-fly.
Vấn đề với RAG: không có tích lũy
RAG hiện nay là một trong những kỹ thuật phổ biến nhất để “kết nối” LLM với dữ liệu bên ngoài. Cơ chế rất đơn giản: khi người dùng đặt câu hỏi, hệ thống tìm kiếm trong database, lấy ra những đoạn văn liên quan nhất (retrieval), rồi đưa cho LLM để sinh ra câu trả lời. Nghe hợp lý, nhưng có một vấn đề tinh tế: mỗi lần query, hệ thống lại phải tìm kiếm lại, compile lại context mới. Không có học tập, không có tích lũy, không có compound effect.
Tưởng tượng bạn có một thủ thư. Mỗi lần bạn đặt câu hỏi, anh ta chạy vào kho sách, tìm những cuốn liên quan, rồi quay lại trả lời. Nhưng anh ta không bao giờ học, không bao giờ tóm tắt, không bao giờ liên kết kiến thức. Mỗi lần lại phải compile from scratch. Đó chính là vấn đề của RAG truyền thống.
Karpathy chỉ ra rằng RAG thiếu một khía cạnh quan trọng của tri thức con người: tri thức được tích lũy, được tổ chức, được liên kết qua thời gian. Bạn không bao giờ học khái niệm một lần rồi xóa nó. Thay vào đó, bạn xây dựng một “mental model”, một bản đồ kiến thức dài hạn mà bạn tái sử dụng cho mỗi câu hỏi mới.
Giải pháp 3 tầng: Raw → Wiki → Schema
Karpathy đề xuất một kiến trúc bao gồm ba tầng, tương ứng với ba folder.
Tầng 1: Raw (immutable sources). Đây là lớp dữ liệu thô từ các nguồn bên ngoài: PDF, bài viết, tweet, email, mã nguồn. Những file này không bao giờ thay đổi. Chúng là “immutable sources”. Nếu bạn có 100 papers, 50 sách, 200 blog posts, tất cả đều nằm ở đây. Cách tổ chức không quan trọng, miễn là bạn có thể tìm lại được.
Tầng 2: Wiki (AI-compiled, structured, linked). Đây là lớp được LLM biên soạn từ raw sources. Thay vì để LLM tìm kiếm trong raw mỗi lần, bạn cho LLM đọc toàn bộ raw sources một lần, sau đó yêu cầu nó viết ra một bộ bài viết wiki có cấu trúc. Mỗi bài viết là một khái niệm, một sự kiện, một quy tắc. Quan trọng nhất: các bài viết được liên kết với nhau qua wikilinks. Đây chính là knowledge graph dưới dạng markdown.
Tầng 3: Schema (constraints, rules, metadata). Đây là lớp định nghĩa quy tắc mà wiki phải tuân theo. Nó chứa file CLAUDE.md, một “constitution” cho wiki. CLAUDE.md định nghĩa format bài wiki, frontmatter YAML bắt buộc, naming convention. Bằng cách có schema rõ ràng, LLM sẽ generate wiki theo format nhất quán, dễ tái sử dụng.
Ba tầng này tạo thành hệ thống phân lớp tương tự phát triển phần mềm: raw sources như uncompiled source code, wiki là compiled bytecode, schema là build rules và linting rules. Chi tiết về sự khác biệt giữa raw và compiled ở bài dữ liệu thô vs dữ liệu tinh lọc.
6 giai đoạn chu kỳ: Raw → Compile → View → Query → Feedback → Lint
Karpathy không chỉ đề xuất kiến trúc, mà còn mô tả một quy trình chu kỳ lặp lại liên tục.
1. Raw (thêm dữ liệu thô). Bạn liên tục thêm sources mới vào folder raw/. Bài báo vừa đọc, cuốn sách vừa xong, notes từ cuộc họp. Không cần tổ chức hay biên soạn, chỉ cần lưu lại.
2. Compile (biên soạn wiki). Cho LLM đọc những raw sources mới, rồi yêu cầu nó cập nhật wiki. Có thể thêm bài mới, sửa bài cũ, thêm wikilinks. Bước này là “compile”, từ source code sang executable.
3. View (xem và duyệt). Mở Obsidian, xem wiki, duyệt qua các bài viết và liên kết. Obsidian tuyệt vời cho việc này vì render markdown đẹp, hỗ trợ wikilinks, có graph view để visualize knowledge network.
4. Query (hỏi LLM câu hỏi phức tạp). Thay vì để LLM tìm kiếm trong raw, bạn cho nó đọc toàn bộ wiki (fit trong context window), rồi hỏi câu hỏi. LLM đã có toàn bộ kiến thức tích lũy nên trả lời chi tiết, nhất quán và có liên kết tới khái niệm khác.
5. Feedback (lấy ý kiến từ query). Khi hỏi câu hỏi, LLM có thể phát hiện wiki đang thiếu gì, hoặc có mâu thuẫn ở đâu. Đây chính là feedback loop.
6. Lint (tự kiểm tra wiki). LLM chạy “health check” trên toàn bộ wiki: tìm broken wikilinks, orphan notes, contradictions, stale information. Đây là “linting”, tương tự eslint trong JavaScript. Wiki không phải tập hợp static, nó là living system mà LLM liên tục bảo trì. Chi tiết ở bài AI agent bảo trì vault.
6 giai đoạn này không linear, mà là vòng tròn vô hạn. Bạn luôn ở giữa chu kỳ: lưu sources → compile → view → query → feedback → lint → lưu thêm → compile lại.
Tại sao RAG không cần thiết ở quy mô cá nhân
Một trong những lợi thế lớn nhất của pattern này là không cần hạ tầng phức tạp. RAG đòi hỏi vector databases, embedding models, retriever networks, semantic search, tất cả đều có cost và complexity. Nhưng nếu bạn chỉ quản lý wiki cá nhân (1.000-2.000 articles), Karpathy chỉ ra rằng context windows hiện đại đã đủ lớn để chứa toàn bộ wiki.
Một bài wiki trung bình khoảng 300-500 từ. 1.000 bài = 300.000-500.000 từ, khoảng 2 triệu tokens. Claude có context window 200.000 tokens, vậy wiki vừa vặn trong một context window, thậm chí còn dư cho câu hỏi và response.
Markdown là định dạng rất compact. Nếu biên soạn wiki thông minh, sử dụng wikilinks và summary sections, không copy-paste content, bạn có thể nén tri thức rất tốt. 10.000 từ raw sources có thể được biên soạn thành 1.000 từ wiki, nhưng vẫn giữ tất cả ý tưởng chính.
Điều này có nghĩa: bạn không cần vector database, không cần RAG pipeline. Chỉ cần Markdown + Obsidian + Claude API. Đơn giản gấp mười lần, chi phí gấp một phần mười.
Obsidian là IDE, LLM là coder, wiki là codebase
Tiêu đề bài viết này là một analogy sâu. Khi lập trình, bạn có IDE (editor + tools), compiler (biến source code thành executable), và codebase (files, libraries, dependencies).
Trong pattern Karpathy: IDE = Obsidian, nơi bạn view, edit, graph, xem lại knowledge. Compiler = LLM (Claude, GPT-4), nơi bạn transform raw sources thành wiki. Codebase = wiki (markdown files), nơi knowledge được lưu trữ, tổ chức, liên kết.
Tri thức quản lý rất giống lập trình. Code cần compile thành machine code, knowledge cần compile thành wiki. Code cần lint để tìm lỗi, wiki cần lint để tìm broken links và contradictions. Code cần dependencies được quản lý, wiki cần wikilinks được quản lý. IDE cần syntax highlighting, Obsidian cần markdown formatting + graph view.
Sự khác biệt chính: compiler truyền thống là deterministic (input → output luôn giống nhau), còn LLM compiler là probabilistic (có thể generate ra biến thể khác nhau). Nhưng nếu bạn có CLAUDE.md schema tốt, bạn có thể làm cho LLM compiler đủ deterministic để dùng được.
Ứng dụng thực tế: bắt đầu nhỏ
Nếu bạn là solo entrepreneur, researcher, hoặc chỉ là một người muốn quản lý kiến thức tốt hơn, đây là cách bắt đầu.
Bước 1: Tạo ba folder: raw/, wiki/, schema/. Trong schema/, tạo file CLAUDE.md mô tả cách bạn muốn wiki được format.
Bước 2: Thêm 10-20 raw sources đầu tiên. Có thể là blog posts về chủ đề bạn quan tâm, notes từ khóa học, hoặc research papers.
Bước 3: Cho Claude đọc toàn bộ raw sources, yêu cầu viết wiki. Dùng prompt đơn giản: “Đọc những sources dưới đây. Viết ra bộ wiki articles, mỗi article 300-500 words, markdown format. Có frontmatter YAML với title, tags, related. Liên kết bằng wikilinks.”
Bước 4: Paste files vào Obsidian. Mở graph view, duyệt qua.
Bước 5: Query. Hỏi Claude: “Dựa vào wiki này, giải thích…” Claude trả lời dựa trên wiki có sẵn.
Bước 6: Lint. “Kiểm tra wiki này, tìm broken links, orphan notes, contradictions.”
Bước 7: Mỗi tuần, thêm 5-10 raw sources mới, compile, view, query, lint lại. Mỗi lần wiki lớn thêm, phong phú hơn, mạnh hơn.
Bạn không cần tool đặc biệt, không cần code, không cần vector database. Chỉ cần Obsidian (free), Claude API (rẻ), và một editor text. Mỗi tuần một buổi compile dài 30 phút, vậy là đủ để maintain wiki 1.000+ articles.
Cẩn thận với automation mà bạn không hiểu. Pattern này rất mạnh, nhưng không phải “set and forget”. Nếu tự động hóa compile, lint, update mà không thường xuyên xem lại wiki, nó sẽ degrade. Wiki sẽ tích tụ dead links, duplicate content, contradictions. Quy tắc của Karpathy: human-in-the-loop ở mỗi giai đoạn. View wiki thường xuyên, lint thường xuyên, feedback thường xuyên.
Câu hỏi thường gặp
Pattern này tốt hơn RAG ở điểm nào?
Ở quy mô cá nhân (dưới 1.000 articles, dưới 500.000 tokens), pattern Karpathy đơn giản hơn, rẻ hơn, transparent hơn, và tích lũy kiến thức tốt hơn. Bạn có thể đọc, sửa, visualize wiki trực tiếp, không cần black box retriever. RAG tốt hơn nếu bạn có quy mô lớn (hàng triệu tài liệu) hoặc data thay đổi liên tục.
Nếu wiki sai thì sao?
Wiki có thể sai, nhưng bạn fix được. Vì nó là markdown, bạn manually edit. Hoặc feedback tới LLM: “Bài này sai ở chỗ nào, sửa lại.” Không phải black box như RAG.
Làm sao biết khi nào nên compile lại?
Thường xuyên, khi bạn thêm raw sources mới. Có thể mỗi tuần một lần, hoặc mỗi lần đọc xong cuốn sách. Không cần frequent vì tri thức thay đổi chậm.
Có tốn token không?
Biên soạn tốn tokens. Nhưng khi wiki đã có, bạn sử dụng rất tiết kiệm tokens vì đã nén dữ liệu trong wiki, không cần RAG tìm kiếm liên tục.
Bài liên quan
- Obsidian là IDE, LLM là coder — chi tiết cách dùng Obsidian như IDE
- Wiki cá nhân dùng Karpathy pattern — hướng dẫn xây wiki cá nhân
- Dữ liệu thô vs dữ liệu tinh lọc — raw sources vs compiled wiki
- Tự động compile raw to wiki — automation workflow
- AI agent bảo trì vault — AI agents tự động bảo trì wiki
Nguồn tham khảo
[1] MindStudio. What Is Andrej Karpathy’s LLM Wiki? How to Build a Personal Knowledge Base With Claude Code.
[2] Karpathy. llm-wiki — GitHub Gist.
[3] VentureBeat. Karpathy shares ‘LLM Knowledge Base’ architecture that bypasses RAG.
Bửu Trung — Dân Lười, thích Tối ưu.
Bạn đã thử dùng AI để biên soạn wiki chưa? Hay vẫn đang copy-paste từng bài một? Chia sẻ cách bạn đang quản lý kiến thức, mình muốn nghe.
