Second Brain với Agentic AI và Obsidian: cách tôi làm

Xin chào anh em. Bài này tôi chia sẻ cách làm Second Brain với Agentic AI và Obsidian, tức một bộ não thứ hai chạy được thật, gồm bốn thứ: thư mục raw để vứt tài liệu thô vào, một tiến trình để AI tự bóc tách và nối chéo, một file index để tra cho nhanh, và một vòng dọn dẹp định kỳ. Cuối bài có mẫu đề bài anh em chép về giao cho con AI của mình.

Video gốc dài 27 phút. Bài viết này bổ sung ba thứ video không có: cấu trúc thư mục viết ra thành bảng, hai khối đề bài copy được, và phần đối chiếu với bản gốc của Andrej Karpathy.

Thứ tự tôi sẽ đi:

1. Vì sao lưu nhiều mà vẫn không dùng được
2. Hai người đi trước đã giải bài toán này thế nào
3. Vì sao lưu trữ tốt vẫn chưa đủ
4. Agentic Second Brain là gì
5. Cấu trúc thư mục và file index
6. Vòng dọn dẹp định kỳ
7. Việc nào giao cho AI, việc nào mình giữ
8. Cài đặt để lưu một phát vào thẳng raw
9. Gắn kho ghi chú vào một con agent
10. Giới hạn thật của cách làm này

Vì sao lưu nhiều mà vẫn không dùng được?

Bản chất là anh em đang tích trữ chứ không phải đang xây kho. Tích trữ thì chỉ tốn chỗ.

Anh em để ý thói quen của mình mà xem. Lướt web thấy bài hay, lưu. Thấy một video hay, lưu. Thấy mấy chục cái prompt ngon, lưu. Thấy một bộ skill của người ta chia sẻ, lưu luôn. Rồi sao ạ? Rồi thôi. Rất ít khi chúng ta mở lại.

Thế là hình thành một đống dữ liệu nằm rải rác. Một ít trên Facebook, một ít trên TikTok, một ít trong thư mục Downloads, một ít trong ứng dụng ghi chú nào đó. Đống đấy không suy nghĩ được, cũng không hành động được.

Và đây mới là chỗ đau. Công sức đi tìm lại thứ mình đã lưu nhiều khi còn vất vả hơn đi tìm mới. Bây giờ có AI rồi, hỏi thẳng một câu là ra đáp án, nhanh hơn lục kho của chính mình. Nên cái kho ấy càng ngày càng ít được đụng tới.

Câu hỏi đúng không phải là lưu thế nào cho gọn. Câu hỏi đúng là làm sao biến đống dữ liệu đấy thành thứ suy nghĩ được và hành động được.

Hai người đi trước đã giải bài toán này thế nào?

Có hai cách làm kinh điển, và cả hai đều giải quyết đúng một nửa bài toán.

Zettelkasten của Niklas Luhmann giải bài toán gì?

Zettelkasten giải bài toán liên kết. Luhmann không xếp ghi chú theo thư mục cố định, ông cho chúng tham chiếu chéo lẫn nhau.

Ông là giáo sư xã hội học ở Đại học Bielefeld. Cái hộp giấy của ông có khoảng 90.000 tấm thẻ viết tay, làm từ đầu những năm 1950 tới năm 1997. Đại học Bielefeld hiện đang lưu trữ và số hoá toàn bộ chỗ này. Danh mục công bố của ông gần 600 đầu, trong đó hơn 40 cuốn sách.

Mỗi tấm thẻ của ông gồm mấy phần: một mã định danh riêng, vài cái thẻ phân loại, phần nội dung, phần liên kết sang mã của thẻ khác, và phần trích dẫn nguồn.

Anh em thấy quen không ạ? Nó y hệt database. Có khoá chính, có tag, có khoá ngoại trỏ sang bản ghi khác.

Mục tiêu của cách làm này là tạo ra một cấu trúc phi tuyến tính. Ý tưởng mới nảy ra từ những mối nối bất ngờ giữa các mẩu tin lẻ, chứ không nảy ra từ việc xếp folder cho đẹp. Chính Luhmann gọi cái hộp giấy đấy là bộ nhớ thứ hai của ông.

Cấu trúc PARA của Tiago Forte khác chỗ nào?

PARA giải bài toán phân loại. Tiago Forte chia dữ liệu thu về làm bốn nhóm: Projects là dự án đang chạy, Areas là mảng mình phụ trách lâu dài, Resources là tài nguyên tham khảo, Archives là thứ để đấy không dùng nữa.

Ông này viết quyển "Building a Second Brain", và chữ "bộ não thứ hai" phổ biến ra ngoài phần lớn là nhờ quyển đó.

Hai bác này phong cách khác nhau. Một bác đi theo hướng nối chéo, một bác đi theo hướng chia nhóm. Nhưng tư tưởng chung là một: gắn tri thức bên ngoài vào với nhau thành một khối dùng được.

Vì sao lưu trữ tốt vẫn chưa đủ?

Vì hiệu quả không nằm ở chỗ lưu. Hiệu quả nằm ở chỗ lấy ra được và hành động được.

Tôi nhìn chuyện này bằng con mắt của người thiết kế hệ thống. Có hai vế phải đạt cùng lúc:

• Vế một, lưu trữ tốt. Hai phương pháp bên trên lo vế này rất giỏi.
• Vế hai, lấy ra được và hành động được. Chỗ này thì cả hai đều bó tay.

Chỉ đạt vế một thì vô nghĩa. Kết quả cuối cùng đo bằng hành động của mình, bằng chất lượng quyết định của mình, bằng công việc mình làm xong. Không đo bằng số lượng ghi chú.

Anh em thử nghĩ xem vì sao bộ não sinh học của chúng ta mạnh đến vậy. Nó mạnh không phải vì nó nhớ nhiều. Nó mạnh vì nó ra quyết định ngay trên thứ nó nhớ.

Tôi ví dụ. Anh em đang đi bộ, có cái xe lao tới. Anh em tránh luôn, đôi khi tránh trong vô thức. Bộ não nhận thông tin, đối chiếu với thứ đã nhớ, ra quyết định, tất cả trong tích tắc.

Cái hộp giấy của Luhmann không làm được chuyện đó. Nó nằm im. Ai lôi nó ra thì nó mới có ích.

Agentic Second Brain là gì?

Agentic Second Brain là bộ não thứ hai được nối vào một con AI biết hành động. Nó nhớ, nó suy luận, rồi nó làm việc ngay trên chỗ đã nhớ.

Trước đây điều này không khả thi. Bây giờ thì khả thi, vì đủ ba yếu tố.

Thứ nhất, nó ghi nhớ được. Bản thân mô hình ngôn ngữ lớn không có khả năng nhớ lâu, nó được thiết kế để quên. Muốn nó nhớ thì phải ghi ra ngoài. Ghi ra vector database cũng được, ghi ra file text cũng được, miễn là nằm ngoài mô hình.

Thứ hai, nó suy luận được. Anh em ra một yêu cầu, nó tự lập luận xem cần đi bao nhiêu bước. Chỗ này thì các mô hình bây giờ làm tốt rồi. Anh em trả tiền cho hãng để dùng mô hình lớn, hoặc mua phần cứng về chạy mô hình nhỏ ngay tại chỗ và không tốn tiền theo lượt hỏi nữa.

Thứ ba, nó hành động được. Nó vào web tìm được, nó chọc vào file Excel, Word, PowerPoint được, nó chọc vào hệ thống dữ liệu khách hàng của anh em được.

Ghép ba thứ này lại thì được cái combo. Mà quan trọng nhất là chỗ này: nếu anh em chỉ dùng công cụ AI mặc định thì anh em không có gì khác biệt cả. Ai cũng tải đúng cái tool đấy về. Thứ tạo ra khác biệt là dữ liệu riêng của anh em.

Còn một vấn đề nữa phải giải. Mỗi lần hỏi là AI phải xử lý lại từ đầu rồi vứt kết quả đi. Dùng gói thuê bao thì anh em đụng giới hạn số lượt hỏi. Dùng ở doanh nghiệp thì trả tiền theo từng lần gọi. Tốn kém mà kết quả không giữ lại được. Chuyện chi phí này tôi có chia sẻ kỹ hơn trong bài tối ưu chi phí token khi cho AI vận hành kênh YouTube.

Vậy tại sao không tổng hợp trước một lần, để lần sau hỏi thì nó trả lời ngay trên bản đã tổng hợp?

Nó giống hệt chuyện biên dịch trong lập trình. Biên dịch một lần, chạy nhiều lần. Không ai đi biên dịch lại mỗi lần chạy cả.

Karpathy đề xuất bỏ RAG để làm gì?

Andrej Karpathy, đồng sáng lập OpenAI và cựu giám đốc AI của Tesla, đưa ra một mẫu gọi là LLM Wiki. Ý chính là thay vì mỗi câu hỏi lại đi lục tài liệu thô, hãy để mô hình dựng sẵn và nuôi một cuốn wiki bằng file markdown.

Khác biệt nằm ở chỗ này:

Điểm tôi thích nhất ở đề xuất này là nó rẻ. Không cần RAG, không cần vector database, không cần hạ tầng gì hết. Chỉ cần file markdown nằm trên máy của anh em.

Nói luôn cho công bằng: mẫu này hợp với cá nhân và đội nhỏ. Doanh nghiệp lớn hay tập đoàn thì không hợp, tôi có phân tích lý do ở mục giới hạn cuối bài.

Kho ghi chú gồm những thư mục nào?

Ba lớp, đi theo đúng đường dữ liệu chảy: raw chứa bản gốc, wiki chứa bản đã bóc tách, index và log để tra và để ghi sổ.

Cụ thể từng chỗ:

Trong wiki tôi chia tiếp thành mấy nhóm cho dễ tra: concepts cho khái niệm, entities cho công cụ và tổ chức, sources cho nguồn, syntheses cho phần tự tổng hợp.

Cái hay của toàn bộ chỗ này là tất cả đều là file text. Không có định dạng độc quyền nào, không khoá anh em vào nhà cung cấp nào.

File index làm gì trong hệ thống này?

File index là mục lục để con AI đọc trước, thay vì nó phải quét cả kho.

Nhìn thì đơn giản, nhưng nó chính là chỗ quyết định tốc độ. Con AI vào, đọc mục lục, thấy câu hỏi thuộc nhóm nào, rồi mới mở đúng vài trang cần đọc. Không có mục lục thì nó phải đọc tràn lan.

Chuyện này giống hệt index trong database. Có index thì tra nhanh, nhưng index viết sai chỗ hoặc phình quá to thì lại thành gánh nặng. Anh em nào làm database sẽ thấy quen ngay, tôi có phân tích cơ chế đó trong bài vì sao có index mà SQL vẫn chậm.

Một chi tiết nữa đáng làm. Câu trả lời của con AI cũng lưu ngược lại vào wiki được, thành một trang kiến thức mới. Anh em làm việc với nó càng nhiều thì kho càng dày. Càng ngày càng ngon. Càng ngày càng ngon.

Vòng dọn dẹp định kỳ kiểm những gì?

Kiểm ba thứ: tri thức mâu thuẫn, tri thức đã cũ, và trang mồ côi không nối với ai.

Đây là chỗ nhiều người bỏ qua, và bỏ qua là hỏng cả kho. Anh em cứ thêm file vào liên tục. Đến lúc nào đó có một file mới mang tri thức phủ nhận file cũ. Hai bản cùng nằm đấy, con AI đọc cả hai, rồi nó trả lời sai mà không ai biết.

Nên phải có một tiến trình định kỳ chạy soát lại. Giống như thu một đống đồ về nhà thì thỉnh thoảng vẫn phải dọn tủ.

Đây là đề bài dọn dẹp tôi giao, anh em chép về sửa lại theo kho của mình:

Vai tro: nguoi giu kho tri thuc cua toi.
Pham vi: toan bo thu muc wiki, file index, file log.

Chay bon phep soat, moi phep bao cao rieng:

[1] Mau thuan
    Tim cac trang noi nguoc nhau ve cung mot su viec.
    Voi moi cap, ghi ro: duong dan hai trang, cau mau thuan,
    nguon goc va ngay cua tung ben.
    Khong tu sua. Chi liet ke de toi quyet.

[2] Da cu
    Tim trang co nguon goc cu hon 12 thang ma chu de van dang doi nhanh.
    Danh dau la CAN KIEM TRA LAI, kem ly do mot dong.

[3] Mo coi
    Tim trang khong co lien ket den va cung khong co lien ket di.
    De xuat noi vao dau, hoac de xuat gop vao trang nao.

[4] Lech index
    Doi chieu file index voi thu muc thuc te.
    Bao cao trang co trong thu muc ma thieu trong index, va nguoc lai.

Dau ra: mot bao cao markdown duy nhat, chia bon muc dung thu tu tren.
Ghi them mot dong vao file log: ngay chay, so van de tim thay tung muc.
Tuyet doi khong xoa file nao, khong sua noi dung trang nao.

Anh em để ý dòng cuối. Tôi không cho nó xoá. Nghiệm thu trước, xoá sau. Con AI làm tốt phần lục lọi, nhưng quyền bỏ đi thì vẫn phải nằm ở người.

Việc soát này chạy nền được, và nếu anh em muốn chạy nhiều nhánh song song thì cách điều phối tôi có chia sẻ trong bài dynamic workflow với Opus 4.8 điều phối subagent.

Việc nào giao cho AI, việc nào mình giữ?

Giao cho AI phần giữa. Giữ lại hai đầu.

Bản chất vấn đề của cách làm cũ nằm ở đúng một chữ: lười. Con người chúng ta cực kỳ ngại làm việc lặp lại. Có một hai file thì làm được. Kiên trì nhiều năm thì không.

Bác người Đức kia kỷ luật kinh khủng. 90.000 tấm thẻ viết tay, mỗi tấm đều gắn mã và nối link đầy đủ. Mình thì không được như thế. Tôi cũng không. Bảo tôi ngồi lò dò xem file mới này nối vào file cũ nào thì tôi ngại lắm.

Mà không chịu làm thì dữ liệu ra lởm. Dữ liệu lởm thì con AI ra quyết định lởm. Vòng đấy khép kín, không thoát được.

Đọc bảng này anh em thấy ngay đường ranh. Phần giữa là bàn giấy, giao hết. Hai đầu là tư duy, giữ lại.

Đây cũng đúng cách tôi giao việc cho cả đội agent trong công ty, tôi có chia sẻ trong bài cho đội ngũ AI agent vận hành cả công ty.

Cài đặt thế nào để lưu một phát vào thẳng raw?

Cài Obsidian, cài thêm extension Obsidian Web Clipper, rồi trỏ vị trí ghi chú mặc định vào raw.

Obsidian tải về dùng trên máy cá nhân, không mất phí. Bấm download, bật lên là xong. File nằm trên máy anh em, không nằm trên máy người khác.

Phần mẹo nằm ở cái extension. Đang đọc tài liệu trên mạng, thấy hay, bấm một phát là bài đó vào thẳng kho. Không phải copy, không phải dán, không phải đặt tên.

Ba bước, làm trong mười phút:

1. Tải Obsidian về, tạo một kho mới.
2. Cài extension Obsidian Web Clipper cho trình duyệt.
3. Vào Setting, mục mặc định, ô Vị trí ghi chú điền raw.

Xong. Từ giờ anh em cứ đọc và cứ lưu. Phần còn lại con AI lo.

Gắn kho ghi chú vào một con agent thì được gì?

Được một trợ lý trực 24/7, hỏi lúc nào cũng trả lời, và trả lời trên dữ liệu của chính mình.

Tôi gắn kho của tôi vào một con agent, rồi cho nó ra kênh Telegram. Bất kỳ lúc nào tôi cũng hỏi được, không cần mở máy tính.

Chỗ này mới là điểm khác biệt thật. Con AI mặc định trả lời chung chung, ai hỏi cũng ra thế. Con AI có kho riêng thì trả lời bằng thứ chính anh em đã đọc, đã gặp, đã ghi lại.

Anh em nào muốn xem một ca nghiệp vụ cụ thể hơn thì đọc bài AI agent kiểm tra hoá đơn đầu vào. Cùng một tư tưởng, khác đề bài.

Đây là khối luật tôi đặt cho con agent đọc kho. Anh em chép về, đổi đường dẫn rồi dùng:

Vai tro: tro ly tra cuu tren kho ghi chu ca nhan cua toi.
Duong dan kho: <dien duong dan vault cua anh em>

Luat tra loi:
[1] Truoc khi tra loi, doc file index de biet trang nao lien quan.
    Khong duoc doan khi chua doc.
[2] Chi tra loi bang noi dung co trong kho.
    Khong co thi noi thang la kho chua co, dung suy dien.
[3] Moi y trong cau tra loi phai kem duong dan trang nguon.
[4] Neu hai trang noi nguoc nhau, neu ca hai va noi ro dang co mau thuan.
    Khong tu chon ben nao.
[5] Tra loi ngan. Y chinh truoc, chi tiet sau.

Sau khi tra loi:
[6] Neu cau tra loi tong hop tu ba trang tro len va co gia tri dung lai,
    hoi toi mot cau: co luu thanh trang wiki moi khong.
    Toi dong y thi moi ghi, va ghi them mot dong vao file log.

Luật số 2 và số 4 là hai luật tôi coi trọng nhất. Một luật chặn nó bịa, một luật chặn nó tự chọn phe khi dữ liệu của tôi đang mâu thuẫn.

Bức tranh tổng gói trong một bảng

Bốn chặng này lặp lại mãi. Càng chạy lâu kho càng có giá.

Giới hạn thật của cách làm này

Hai giới hạn, và tôi nói thẳng luôn để anh em khỏi vỡ mộng giữa đường.

Giới hạn thứ nhất, con AI tự quyết định bóc tách thế nào. Anh em vứt tài liệu thô vào, nó tự đọc, tự chọn giữ gì bỏ gì, tự nối sang trang nào. Nên hoàn toàn có khả năng nó làm đúng, và cũng có khả năng nó làm sai.

Chuyện này còn phụ thuộc vào mô hình anh em chọn. Mô hình năng lực thấp bóc tách kém hơn hẳn mô hình năng lực cao. Khác biệt giữa các đời mô hình lớn tới đâu thì tôi có phân tích trong bài Fable 5 và ba thay đổi cho doanh nghiệp.

Điểm khó chịu nhất là mình không bao giờ biết trong kho của mình đang thiếu gì. Bản tóm tắt nó viết ra có thể bỏ qua một chi tiết quan trọng. Tỷ lệ có thể thấp, nhưng phải biết là có. Đừng tin nó đúng 100%.

Cách sống chung của tôi: giữ nguyên bản gốc trong raw không sửa gì. Việc gì hệ trọng thì mở lại bản gốc đọc, đừng chỉ đọc bản tóm tắt.

Giới hạn thứ hai, hiệu năng khi kho phình to. Vài trăm tài liệu thì không vấn đề gì. Nhưng số lượng lớn lên là bắt đầu đuối.

Lý do nằm ở chỗ con AI phải chọc thẳng vào file. Có file index rồi đấy, nhưng chuyện gì xảy ra khi chính cái index càng ngày càng dày? Nó phải quét cả trang đó để tìm. Và tốc độ quét lại phụ thuộc vào tốc độ đọc ghi ổ cứng của máy anh em.

Đây đúng là bài toán kiến trúc lưu trữ kinh điển, giống chuyện một cơ sở dữ liệu lúc nhanh lúc chậm mà nhìn bên ngoài không hiểu vì sao, tôi có phân tích một ca như thế trong bài MongoDB lúc nhanh lúc chậm.

Nên nói cho rõ: mẫu này hợp với cá nhân và đội nhỏ. Tập đoàn với kho tài liệu hàng chục nghìn file thì phải đi hướng khác.

Làm được gì trong 7 ngày tới?

1. Ngày 1. Tải Obsidian, tạo một kho mới, tạo đúng hai thư mục raw và wiki.
2. Ngày 1. Cài Obsidian Web Clipper, trỏ Vị trí ghi chú vào raw.
3. Ngày 2. Viết file luật cho con AI. Nói rõ nó được ghi vào đâu và không được xoá gì.
4. Ngày 2 tới 5. Cứ đọc và cứ lưu. Đừng sắp xếp gì hết. Mục tiêu là có khoảng 20 tài liệu trong raw.
5. Ngày 5. Giao cho con AI bóc tách toàn bộ raw, viết trang wiki và dựng file index.
6. Ngày 6. Hỏi nó ba câu thật, loại câu anh em vẫn phải tự đi tra. Xem đáp án có dẫn được nguồn không.
7. Ngày 7. Chạy khối đề bài dọn dẹp ở trên. Đọc báo cáo bốn mục rồi tự quyết giữ hay bỏ.

Hết bảy ngày anh em có một kho chạy được. Chưa xịn, chưa đầy đủ, nhưng chạy được đã.

Câu hỏi hay gặp

Không dùng Obsidian có được không?

Được. Obsidian chỉ là cửa sổ nhìn vào một đống file markdown nằm trên máy. Anh em dùng trình soạn thảo nào cũng chạy. Cái được của Obsidian là nó vẽ ra đồ thị liên kết và mở link giữa các trang nhanh, nên nhìn kho dễ hơn. Bỏ Obsidian đi thì hệ thống vẫn nguyên vẹn.

Cách này thay được RAG và vector database chưa?

Chưa, và cũng không nhằm thay. Mẫu LLM Wiki hợp với kho cỡ cá nhân, vài trăm tài liệu. Vượt ngưỡng đó thì việc quét file trở thành nút thắt, lúc ấy vector database vẫn là đường đúng. Cứ bắt đầu bằng file text cho rẻ, đụng trần rồi tính tiếp.

Nên chọn mô hình lớn hay mô hình nhỏ chạy tại chỗ?

Tuỳ hai thứ: dữ liệu có nhạy cảm không, và túi tiền thế nào. Mô hình lớn bóc tách tốt hơn, nhưng trả tiền theo lượt gọi. Mô hình nhỏ chạy trên máy của mình thì đầu tư phần cứng một lần, sau đó hỏi bao nhiêu cũng không tốn thêm, đổi lại chất lượng tóm tắt thấp hơn.

Kho ghi chú cũ lộn xộn thì bắt đầu lại từ đâu?

Đừng dọn tay. Copy nguyên cả đống cũ vào raw, kể cả file trùng, rồi giao cho con AI bóc tách. Nó dựng wiki xong anh em mới chạy phép soát mâu thuẫn và soát trang mồ côi. Dọn bằng máy nhanh hơn dọn bằng cơm rất nhiều.

Làm sao biết con AI tóm tắt sai?

Bắt nó dẫn nguồn cho từng ý, đây là luật số 3 trong khối luật ở trên. Câu trả lời nào quan trọng thì mở trang gốc trong raw đối chiếu. Và chạy phép soát mâu thuẫn định kỳ, vì hai trang nói ngược nhau là dấu hiệu rõ nhất cho thấy có chỗ đã bóc tách sai.

Đội nhiều người dùng chung một kho được không?

Được, nếu đội nhỏ và chấp nhận một điều kiện: phải có người duyệt trước khi con AI ghi đè trang cũ. Không có khâu duyệt thì hai người nạp hai nguồn trái nhau, wiki bị sửa qua sửa lại, và không ai biết bản nào mới nhất. Cứ bắt đầu bằng một người giữ kho.

Đúc kết

Về dài hạn thì dữ liệu quan trọng hơn công cụ. Công cụ ai cũng tải được, dữ liệu thì chỉ mình anh em có.

Thứ chặn chúng ta suốt bao năm không phải là thiếu phương pháp. Luhmann để lại phương pháp từ những năm 1950 rồi. Thứ chặn chúng ta là không đủ kỷ luật để làm phần bàn giấy. Bây giờ phần bàn giấy đó giao được cho máy.

Anh em giữ đúng hai đầu: chọn nguồn đáng lưu, và đặt câu hỏi cho ra hồn. Phần giữa vứt cho nó.

Cứ làm đi sai lại sửa. Tạo hai thư mục, cài một extension, lưu hai chục bài rồi hỏi thử. Chưa hoàn chỉnh cũng được, chạy được đã. Tuỳ anh em, phong cách nào cũng được.

Nguồn tham khảo

• Andrej Karpathy, llm-wiki.md, GitHub Gist: gist.github.com
• Niklas Luhmann Archive, Đại học Bielefeld, về kho khoảng 90.000 tấm thẻ: uni-bielefeld.de
• Johannes F. K. Schmidt, Niklas Luhmann's Card Index: The Fabrication of Serendipity, Sociologica 2018: bản PDF của Đại học Bielefeld
• Giới thiệu phương pháp Zettelkasten: zettelkasten.de