Cuối cùng cũng đọc được bản tóm tắt LLM Wiki của Karpathy (ừ, biết là hơi muộn so với mốt này XD).
Và thành thật mà nói, toàn bộ ý tưởng có thể tóm gọn lại thành một thứ khá đơn giản: "RAG có thể cập nhật".
1. Vấn đề
Khi LLM làm việc với tài liệu, không có gì được tích lũy. Mỗi truy vấn - mô hình sẽ truy xuất các đoạn, tổng hợp từ đầu, rồi quên. Kiến thức không bao giờ được biên dịch. Và theo tôi, điều quan trọng hơn là: hầu như không có thông tin hữu ích nào được trích xuất từ chính các cuộc đối thoại.
RAG giúp ích được một phần (theo nghĩa rộng - một thư mục chứa các tệp .md cũng là RAG), nhưng quy trình tiêu chuẩn (mà mọi người đều dùng) không có sẵn cơ chế cập nhật, chưng cất hay tự động dọn dẹp. Kiến thức được đưa vào chỉ mục một lần và sau đó nằm im ở đó. Khoảng trống đó chính xác là thứ mà LLM Wiki lấp đầy.
Sự đảo ngược của Karpathy: giữa các nguồn thô và bạn là một wiki markdown mà tác nhân (agent) sẽ viết và duy trì một cách gia tăng. Biên dịch một lần, giữ cho luôn cập nhật.
2. Kiến trúc: 3 lớp
- raw/ - các nguồn, bất biến. Tác nhân không viết vào đây.
- wiki/ - trái tim của hệ thống; các trang markdown (thực thể, khái niệm) do LLM tự viết và tự tạo liên kết chéo. Về cơ bản là kiến thức dạng đồ thị.
- CLAUDE.md - chỉ là sổ tay hướng dẫn cách chạy LLM Wiki. Chứa: định dạng trang, quy ước liên kết, luồng nhập dữ liệu, quy tắc kiểm tra (lint). Thứ biến Claude từ một chatbot thành một người quản lý wiki có kỷ luật.
Đủ để xử lý hàng trăm trang mà không cần tinh chỉnh thêm:
3. Các thao tác
Ba thao tác - bạn sẽ ngay lập tức muốn hình dung chúng như các hàm API:
- Ingest -> add(source: file | list[file]). Thả một nguồn vào -> tác nhân đọc -> thảo luận với bạn -> viết tóm tắt -> cập nhật chỉ mục -> chỉnh sửa các trang thực thể liên quan -> thêm vào nhật ký. Một nguồn tác động đến 10-15 trang.
- Query -> search(prompt: str). Thao tác quan trọng nhất. Trả lời câu hỏi của bạn + (PHẦN QUAN TRỌNG) tự động lưu kết quả tổng hợp vào wiki dưới dạng các trang mới. Việc khám phá được tích lũy thay vì chết trong lịch sử trò chuyện. Về bản chất, nó giống add(source=dialogue).
- Lint -> lint(). Không có đối số. Định kỳ quét wiki: mâu thuẫn, trang mồ côi, thông tin lỗi thời, thiếu tham chiếu chéo. Kích hoạt - sau mỗi N tin nhắn của người dùng, hoặc một bộ đếm dòng đã thay đổi. Dễ dàng gắn vào /schedule.
Điều này khiến tôi nhớ mạnh mẽ đến Claude Dreaming - tôi nghĩ Dreaming được truyền cảm hứng một phần từ mẫu này (mặc dù bộ chức năng của nó có hơi khác một chút).
4. Lập chỉ mục
Hai tệp đặc biệt giúp wiki có thể điều hướng được:
- index.md - trạng thái hiện tại. Danh mục mọi trang kèm mô tả một dòng. Tác nhân đọc nó đầu tiên trong bất kỳ truy vấn nào - đó là ngữ cảnh tối thiểu "wiki này có những gì".
- log.md - nhật ký của tất cả các sự kiện, dạng tự do. Dòng thời gian chỉ thêm vào. Nếu các dòng có cấu trúc nhất quán (ví dụ: \
## [YYYY-MM-DD] ingest | tiêu đề\), nhật ký có thể được grep sạch sẽ bằng các công cụ unix đơn giản - rất tiện cho việc kiểm tra.
index.md có thể mở rộng hơn nữa (vector index, BM25, GraphDB, ...) - tôi sẽ trình bày trong một bài viết riêng.
5. Bài học rút ra
Tôi sẽ diễn giải nó như thế này: đây không phải là sự lựa chọn giữa RAG và LLM Wiki - chúng là hai điểm trên cùng một trục "bộ nhớ tổng hợp".
RAG không nhất thiết phải là một vector DB - một thư mục chứa các tệp markdown cũng là RAG.
Vì vậy, bạn có thể định nghĩa lại LLM Wiki như một RAG được bổ sung ba thứ:
- Một lớp tóm tắt.
- Khả năng biên soạn (gần như) tự do cấu trúc trên lớp tóm tắt đó.
- Kiểm tra cấu trúc định kỳ + tự cải thiện (CRON).
