- Andrej Karpathy gần đây chia sẻ rằng anh đang dùng nhiều token hơn cho việc xây dựng kho lưu trữ tri thức cá nhân so với viết code, và đã công bố tệp hướng dẫn ý tưởng để tạo wiki dựa trên LLM này
- Chỉ cần đưa tệp này cho agent, nó sẽ tự tạo wiki và hướng dẫn cách sử dụng
- Đây là cách LLM trực tiếp viết và quản lý wiki, khác với phương pháp RAG truy xuất lại thông tin từ tài liệu gốc mỗi khi truy vấn, bằng cách xây dựng một wiki bền vững (persistent wiki) nơi tri thức được tích lũy dần theo thời gian
- Wiki có thể được mở bằng các công cụ như Obsidian, trong khi LLM chỉnh sửa và cập nhật các tệp Markdown theo thời gian thực; người dùng tập trung vào việc thu thập nguồn và đặt câu hỏi
- Khi thêm nguồn mới, LLM sẽ đọc nội dung, tích hợp vào wiki hiện có và tạo liên kết tham chiếu chéo; với một nguồn đơn lẻ, có thể cập nhật 10~15 trang wiki
- Có thể áp dụng cho mọi lĩnh vực mà tri thức được tích lũy theo thời gian như quản lý sức khỏe và mục tiêu cá nhân, nghiên cứu, ghi chú đọc sách, wiki nội bộ của nhóm
- Bằng cách để LLM hạ chi phí bookkeeping của việc duy trì wiki xuống gần như về 0, cách tiếp cận này giải quyết bài toán quản lý wiki mà nhiều người từng bỏ cuộc
Ý tưởng cốt lõi
- Phần lớn cách dùng tài liệu với LLM hiện nay là RAG (Retrieval-Augmented Generation): tải lên một bộ sưu tập tệp, rồi khi có truy vấn thì LLM tìm các đoạn liên quan để tạo câu trả lời
- NotebookLM, tính năng tải tệp của ChatGPT và hầu hết các hệ thống RAG đều hoạt động theo cách này
- Tri thức được trích xuất lại từ đầu mỗi lần, không có sự tích lũy tri thức
- Cách tiếp cận của LLM-Wiki thì khác: thay vì để LLM tìm trực tiếp trong tài liệu gốc, nó xây dựng và duy trì dần một wiki bền vững
- Khi thêm nguồn mới, LLM đọc nội dung, trích xuất thông tin cốt lõi và tích hợp vào wiki hiện có
- Cập nhật các trang thực thể, chỉnh sửa tóm tắt chủ đề, đánh dấu mâu thuẫn giữa dữ liệu mới và các nhận định cũ, tăng cường tổng hợp
- Wiki là một thành quả bền vững và tích lũy theo hiệu ứng lãi kép (persistent, compounding artifact): liên kết chéo đã được thiết lập sẵn, mâu thuẫn đã được đánh dấu, phần tổng hợp đã được phản ánh
- Ví dụ sử dụng thực tế: mở agent LLM ở một bên và Obsidian ở bên kia để theo dõi trực tiếp những chỉnh sửa do LLM thực hiện
- Obsidian = IDE, LLM = lập trình viên, wiki = codebase
Lĩnh vực áp dụng
- Cá nhân: theo dõi mục tiêu, sức khỏe, tâm lý, phát triển bản thân — gom nhật ký, bài viết, ghi chú podcast để xây dựng hồ sơ bản thân có cấu trúc
- Nghiên cứu: xây dựng một wiki toàn diện phản ánh luận điểm đang tiến hóa trong quá trình đọc bài báo, bài viết, báo cáo suốt nhiều tuần hay nhiều tháng
- Đọc sách: tổ chức theo từng chương, tạo các trang cho nhân vật, chủ đề và tuyến truyện — độc giả cá nhân cũng có thể xây dựng hàng nghìn trang liên kết với nhau như Tolkien Gateway
- Doanh nghiệp/nhóm: có thể tạo wiki nội bộ do LLM duy trì từ các thread Slack, bản chép lời cuộc họp, tài liệu dự án và cuộc gọi với khách hàng
- Ngoài ra còn có thể áp dụng cho phân tích cạnh tranh, due diligence, lập kế hoạch du lịch, ghi chú bài giảng, đào sâu sở thích và mọi lĩnh vực nơi tri thức được tích lũy
Kiến trúc (3 lớp)
- Nguồn gốc thô (Raw sources): bộ sưu tập tài liệu nguồn đã được tuyển chọn — bài viết, bài báo, hình ảnh, tệp dữ liệu
- Bất biến (immutable), LLM chỉ đọc chứ không chỉnh sửa
- Lớp này là nguồn chân lý (source of truth)
- Wiki (The wiki): thư mục các tệp Markdown do LLM tạo ra — tóm tắt, trang thực thể, trang khái niệm, so sánh, tổng quan, tổng hợp
- LLM sở hữu hoàn toàn lớp này: tạo trang, cập nhật khi có nguồn mới, duy trì liên kết chéo
- Người dùng chỉ đọc, còn LLM là bên viết
- Schema (The schema): tài liệu cấu hình cho LLM biết cấu trúc wiki, các quy ước và workflow (với Claude Code là
CLAUDE.md, với Codex là AGENTS.md)
- Đây là tệp cấu hình then chốt biến LLM từ chatbot thông thường thành người quản lý wiki có hệ thống
- Người dùng và LLM cùng phát triển nó theo thời gian
Các thao tác chính (Operations)
- Ingest: thêm nguồn mới vào bộ sưu tập nguồn gốc và yêu cầu LLM xử lý
- LLM đọc nguồn → thảo luận nội dung cốt lõi → viết trang tóm tắt vào wiki → cập nhật chỉ mục → cập nhật các trang thực thể/khái niệm liên quan → thêm mục log
- Một nguồn đơn lẻ có thể ảnh hưởng đến 10~15 trang wiki
- Có thể xử lý từng nguồn với mức độ can thiệp cao, hoặc giảm giám sát để xử lý theo lô
- Query: đặt câu hỏi trên wiki, LLM sẽ tìm các trang liên quan và tổng hợp câu trả lời kèm trích dẫn
- Câu trả lời có thể ở nhiều dạng như trang Markdown, bảng so sánh, slide deck (Marp), biểu đồ (matplotlib), canvas, v.v.
- Câu trả lời tốt còn có thể được lưu lại thành trang mới trong wiki — bản thân quá trình khám phá cũng được tích lũy vào kho tri thức
- Lint: định kỳ yêu cầu LLM kiểm tra tình trạng wiki
- Các mục kiểm tra: mâu thuẫn giữa các trang, các nhận định cũ đã bị nguồn mới thay thế, trang mồ côi không có liên kết đến, khái niệm quan trọng chưa có trang riêng, thiếu liên kết chéo, khoảng trống dữ liệu có thể lấp bằng tìm kiếm web
Đánh chỉ mục và ghi log
- index.md: tệp hướng nội dung — lập danh mục tất cả các trang trong wiki kèm liên kết, tóm tắt một dòng và metadata
- Khi trả lời truy vấn, LLM đọc chỉ mục trước rồi điều hướng đến các trang liên quan
- Hoạt động hiệu quả ở quy mô ~100 nguồn, hàng trăm trang mà không cần hạ tầng RAG dựa trên embedding
- log.md: nhật ký theo thời gian — ghi lại các lần ingest, query và lint theo thứ tự
- Nếu giữ tiền tố của mỗi mục nhất quán, có thể parse bằng các công cụ Unix
- Ví dụ:
## [2026-04-02] ingest | Article Title → grep "^## \[" log.md | tail -5 để xem 5 mục gần nhất
Công cụ CLI tùy chọn
- Khi wiki phát triển, có thể xây thêm các công cụ nhỏ để LLM hoạt động hiệu quả hơn
- qmd: công cụ tìm kiếm cục bộ cho các tệp Markdown — tìm kiếm lai BM25/vector và LLM reranking, tất cả đều chạy on-device
- Hỗ trợ CLI (LLM có thể shell out) và máy chủ MCP (LLM có thể dùng như công cụ native)
- Với quy mô nhỏ, chỉ tệp chỉ mục là đủ; khi cần, cũng có thể tự tạo script tìm kiếm đơn giản với sự hỗ trợ của LLM
Mẹo và cách tận dụng công cụ
- Obsidian Web Clipper: tiện ích trình duyệt chuyển bài viết web thành Markdown — hữu ích để nhanh chóng thêm nguồn vào bộ sưu tập nguồn gốc
- Lưu ảnh cục bộ: trong Obsidian Settings → Files and links, thiết lập đường dẫn thư mục đính kèm rồi dùng phím tắt để lưu ảnh vào ổ đĩa cục bộ
- LLM không thể đọc toàn bộ Markdown có ảnh inline trong một lần, nên thường sẽ đọc văn bản trước rồi kiểm tra ảnh riêng
- Obsidian Graph View: giúp nắm hình dạng tổng thể của wiki — rất phù hợp để xem các mối liên kết, các trang trung tâm và các trang mồ côi
- Marp: định dạng slide deck dựa trên Markdown — có plugin cho Obsidian, cho phép tạo trực tiếp bản trình bày từ nội dung wiki
- Dataview: plugin Obsidian cho phép truy vấn frontmatter của trang — nếu LLM thêm YAML frontmatter (tag, ngày, số lượng nguồn), có thể tạo bảng và danh sách động
- Wiki là một kho git của các tệp Markdown — miễn phí có lịch sử phiên bản, branching và cộng tác
Cách nó hoạt động
- Rào cản cốt lõi của việc duy trì kho tri thức không phải là đọc hay suy nghĩ, mà là bookkeeping: cập nhật liên kết chéo, làm mới tóm tắt, đánh dấu mâu thuẫn, giữ tính nhất quán trên hàng chục trang
- Lý do mọi người từ bỏ wiki là vì gánh nặng bảo trì tăng nhanh hơn giá trị nhận được
- LLM không biết chán, không quên cập nhật liên kết chéo, và có thể xử lý 15 tệp cùng lúc → chi phí bảo trì tiệm cận về 0
- Ý tưởng này có liên hệ về mặt tinh thần với Memex(1945) của Vannevar Bush: một kho tri thức mang tính cá nhân, được tuyển chọn chủ động, nơi các kết nối giữa tài liệu có giá trị ngang với chính tài liệu
- Vấn đề "ai sẽ duy trì nó" mà Bush chưa giải quyết được thì nay do LLM đảm nhận
Tính chất của tài liệu này
- Tài liệu này được viết có chủ đích ở mức trừu tượng — mục tiêu là truyền đạt bản thân ý tưởng chứ không phải một triển khai cụ thể
- Chi tiết như cấu trúc thư mục, quy ước schema, định dạng trang, công cụ... sẽ thay đổi tùy miền, sở thích và LLM
- Tất cả thành phần đều là tùy chọn và mô-đun — chỉ dùng những gì cần, bỏ qua những gì không cần
- Khuyến nghị sử dụng theo cách chia sẻ với agent LLM rồi cùng nhau cụ thể hóa thành phiên bản phù hợp với nhu cầu riêng
15 bình luận
Farzapedia: Wikipedia cá nhân được tạo từ 2.500 mục nhật ký, ghi chú và tin nhắn
index.mdlàm điểm vào, để khi truy vấn agent tự tìm các trang cần thiết4 lợi thế của cá nhân hóa dựa trên LLM Wiki mà Karpathy nêu ra
Cảm ơn vì đã chia sẻ. Tôi đã thử chạy và thực sự rất ấn tượng. Có lẽ cộng đồng sẽ tiếp tục đưa ra những phương pháp được cải thiện hơn nữa.
Tôi cũng đã thử triển khai. Khi dùng nhiều phần cứng khác nhau, tôi có bổ sung một chút để có thể liên kết Obsidian vault với bản sao lưu GitHub. Tôi cũng đã tạo và thêm parser cho Codex và Gemini. https://github.com/hang-in/seCall
Trông gọn gàng đấy.
Ôi, dù đã đọc bài viết chính mà tôi vẫn thấy mơ hồ, nhưng tham khảo repo Git này thì cuối cùng cũng thấy được hướng đi rồi. Cảm ơn bạn rất nhiều.
Vì bm25 yếu trong việc tìm kiếm tiếng Hàn nên tôi cũng đã áp dụng thêm guardrail có thể tìm kiếm tiếng Hàn tốt.
Mình chỉ khởi tạo Vault cơ bản vốn chẳng có gì đặc biệt, cho nó đọc đúng một file đó rồi nói rằng muốn cụ thể hóa ý tưởng này, thế là cùng với kỹ năng brainstorm của superpowers, mình đã dựng xong khung tổng thể và hoàn tất cả
CLAUDE.mdlẫn thiết lập plugin Obsidian.Bản thân ý tưởng tận dụng nó như một kiểu kho lưu trữ tri thức cá nhân thì tôi cũng thấy khá thú vị.
Nhưng việc AI có thể xử lý được ngữ cảnh wiki ngày càng chồng chất lên hay không thì tôi vẫn chưa rõ lắm.
Ở góc độ bức tranh lớn thì đây là việc tìm kiếm các cuộc trò chuyện trong quá khứ, nên nếu chỉ sắp xếp tốt vấn đề tổ chức là sẽ là một ý tưởng hay. Thực tế tôi cũng thấy nó đã giúp ích rất nhiều cho việc tổng hợp dự án.
Đúng là thứ tôi định triển khai trong openclaw đã xuất hiện rồi. Phải mang về dùng mới được.
Ý kiến trên Hacker News
Có vẻ cách tiếp cận này rốt cuộc sẽ dẫn đến model collapse
Theo bài báo trên Nature, càng để LLM viết tài liệu thì chất lượng càng suy giảm tích lũy, theo kiểu diễn giải lại thông tin chính xác sẵn có ngày càng kém súc tích hơn
Thật ngạc nhiên khi Karpathy dường như không thấy vấn đề này. Có cảm giác những người theo chủ nghĩa cực đoan về AI đã đánh mất một thứ gì đó như “cảm quan bình thường”
Khi bạn bắt đầu muốn nhấn mạnh “nước sốt bí mật do tôi viết” hơn là kết quả do LLM tạo ra, thì nên tự hỏi tại sao lại như vậy
Thật thất vọng vì ông ấy lại phản ứng theo kiểu đó. Nó khiến tôi nhớ đến câu “nếu không thể nói như một con người thì thà đừng nói”
Có vẻ như nhiều người thông minh đang nhìn thấy một kiểu ‘hồn ma trong cỗ máy’ và dần đánh mất cảm giác rất con người đó
Bài “I Saw Something New in San Francisco” của Ezra Klein đã chỉ ra rất đúng hiện tượng này
claude.md, chứ đừng nói đến cả một wikiTôi đang xây một thứ tương tự theo hướng tiếp cận lấy quản trị làm trung tâm
Tôi gắn bộ nhớ trên toàn bộ không gian làm việc với task hoặc project, rồi điều khiển theo thời gian thực bằng giao diện SPA
Có thể tham khảo dự án hmem
Tôi từng thử để mô hình chuyển sang chế độ nghiên cứu và tự sắp xếp tri thức nội bộ, nhưng cuối cùng nó lại trở nên hỗn độn như một nồi súp LLM
Trong các dự án lập trình, những gì hiệu quả nhất vẫn là yêu cầu rõ ràng, cải tiến lặp lại và code được tài liệu hóa tốt. Khi ký ức trở nên quá nhiều thì lỗi còn tăng lên
Rốt cuộc điều này có vẻ chỉ là trì hoãn vấn đề
Để duy trì wiki, LLM mỗi lần lại phải đọc lại wiki thay vì nguồn gốc ban đầu, và trong quá trình đó lỗi thứ cấp cứ tích lũy thêm
Có lẽ khi các mô hình thế hệ tiếp theo với context 10M hay 1000 tps xuất hiện thì kiểu tiếp cận này sẽ trở nên vô nghĩa
Lớp trung gian này rất hữu ích để nắm được ý đồ thiết kế và xác định độ lệch so với phần triển khai thực tế
Tôi không thấy các hệ thống hoàn toàn tự chủ và tự tham chiếu có giá trị gì. Giá trị thực sự nằm ở cấu trúc nơi con người có thể can thiệp và nói rằng “cái này phải hoạt động theo cách này”
Cuối cùng, các thử nghiệm như thế này tuy thú vị nhưng không có nhiều ý nghĩa trong thực tế. Các nhà cung cấp mô hình lớn đang tiến nhanh hơn nhiều, nên hiện tại tôi nghĩ dùng bản tối giản đơn thuần sẽ tốt hơn
Ý tưởng này khiến tôi nhớ đến bài luận “Man-Computer Symbiosis” của Licklider năm 1960
Đó là khái niệm Intelligence Amplification: con người đặt mục tiêu, máy tính chuyển giả thuyết thành mô hình để kiểm chứng và đảm nhận phần tính toán lặp đi lặp lại
Có thể xem bản gốc tại đây
Có một danh sách các hệ thống hiện thực hóa ý tưởng liên quan ở đây
Tôi đang vận hành một knowledge base dựa trên LLM tên là commonplace
Hệ thống này được thiết kế để LLM có thể đọc và thực thi chính lý thuyết, tạo nên cấu trúc mà lý thuyết chính là runtime
Nó vẫn còn thô nhưng lại rất hợp với tôi
Tôi cũng đã làm một công cụ tương tự nhưng dành riêng cho codebase
llmdoc phát hiện thay đổi tệp bằng hash, rồi để LLM cache phần tóm tắt như một tài sản duy nhất mô tả từng tệp
Có thể truy cập qua CLI, và tốc độ khám phá code tăng lên đáng kể
Thực chất đây là một cấu trúc RAG
Không có vector DB, nhưng ở chỗ tạo chỉ mục liên kết ngữ nghĩa và xây cấu trúc phân cấp để hỗ trợ truy xuất thì vẫn là cùng một ý tưởng
Tôi đang làm dự án atomic, một knowledge base AI áp dụng ý tưởng gần giống với tổng hợp wiki
Lấy DocMason làm ví dụ, nó trích xuất sơ đồ từ PPT hay Excel để các agent như Codex phân tích
Nó gần với tổng hợp tri thức hơn là truy xuất. Cảm giác như LLM đang tự quản lý Zettelkasten của chính nó vậy
Dự án này rất thú vị nên tôi nhất định sẽ xem kỹ
Tôi cũng đã nghĩ về khái niệm LLM-WIKI từ lâu rồi, nhưng OP có vẻ đã đào sâu hơn nhiều. Hy vọng nó sẽ phát triển thành một bộ não thứ hai thực sự
Giống như tài liệu
copilot-instructions.md, đây là một cấu trúc chứa chỉ dẫn để LLM tham chiếuTôi cũng từng thử điều tương tự trong một dự án ở công ty
Khi bị kiệt sức và phải chăm sóc người thân trong gia đình, khả năng tập trung của tôi giảm đi nên tôi giao phó khá nhiều cho workflow đa tác nhân
Nó vận hành xoay quanh một wiki markdown dựa trên Obsidian, nhưng kết quả là lại sinh ra một dạng technical debt mới — như thể một phần bộ não của tôi bị trống đi
Dù vậy, workflow wiki này gây nghiện đến mức rất khó dừng lại
Dù LLM có cho ra kết quả tốt đến đâu, với wiki cá nhân thì quá trình đó vẫn quan trọng hơn
Tôi thường đi bộ hoặc bơi mà không mang điện thoại để đầu óc được trống ra. Mệt về thể chất và mệt về tinh thần là hai kiểu khác nhau nên cách này có ích
Thật vui khi thấy kiểu tiếp cận này đang được chú ý
Nhưng khi trộn tài liệu với dữ liệu có cấu trúc như work item hay ADR thì chỉ dùng markdown sẽ khó truy vấn
Cách AGENTS.md giải quyết bằng việc dạy LLM các quy tắc thư mục, nhưng khi dữ liệu phức tạp hơn thì sẽ chạm giới hạn
Vì vậy tôi đang phát triển Binder
Nó lưu dữ liệu trong DB có cấu trúc, nhưng render ra markdown đồng bộ hai chiều
Nó cung cấp tự động hoàn thành và kiểm chứng bằng LSP, còn agent hay script thì truy cập cùng một dữ liệu qua CLI hoặc MCP
Tôi đã tạo AS Notes cho VS Code
Có thể xem tại asnotes.io
Nó tích hợp chức năng của một hệ thống quản lý tri thức cá nhân vào VS Code, giúp dễ dàng viết, liên kết và cập nhật markdown cùng wiki link
Nó cũng hỗ trợ render mermaid và LaTeX
Nhờ vậy có thể lưu trữ lâu dài kết quả từ các cuộc trò chuyện với AI dưới dạng markdown, mang lại cảm giác giá trị hơn nhiều so với chỉ dùng Copilot
Cuối cùng thì chủ đề này cũng đã xuất hiện. Tôi đã chăm chút khu vườn và xây dựng harness về chủ đề này từ lâu, nên với tôi đây là một điều rất đáng mừng. Bí quyết của thầy Karpathy thật thú vị. Bản thân PKM dường như không nằm ở độ khó của công nghệ, mà là ở quá trình mỗi cá nhân tích lũy lâu dài, cấu trúc hóa và chia sẻ với trí tuệ ngoài con người, qua đó con người dần nắm bắt một mô hình đồng tiến hóa giữa đôi bên. Tức là phải chăng câu hỏi đã quay trở lại với con người? Con người đã sẵn sàng để đồng hành cùng chúng ta chưa? Không có cái gọi là đáp án đúng, và mỗi người sẽ tự tích lũy bằng chính câu hỏi của mình. Tôi rất mong đợi. Cảm ơn GeekNews vì tin này.
Dù không nên có định kiến... nhưng cứ nhìn những bình luận kiểu này thì lại thấy có gì đó rất khó tả.
Lý do phải bình luận bằng bot là gì?
Đây là bot à? Trí tuệ ngoài hành tinh (???)