Điểm nổi bật
- Độ nóng hiện tại: khoảng 2.382 stars và tăng 208 stars hôm nay trên GitHub Trending Python.
- Luận điểm cốt lõi: thay vì để RAG “đọc lại từ đầu” mỗi lần hỏi, OpenKB biên dịch tài liệu thành wiki có liên kết chéo rồi mới cho agent truy vấn.
- Phạm vi đầu vào: hỗ trợ PDF, Word, Markdown, PowerPoint, HTML, Excel, CSV, text và URL.
- Thiết kế khác biệt: dùng PageIndex để xử lý tài liệu dài theo hướng vectorless, reasoning-based retrieval, đồng thời xuất wiki markdown tương thích Obsidian.
Biểu đồ
Tóm tắt
OpenKB đáng chú ý vì nó đánh trực diện vào một điểm yếu cố hữu của nhiều hệ thống RAG: mỗi lần người dùng hỏi là mỗi lần hệ thống lại đi tìm, cắt chunk, xếp hạng và “khám phá lại” thứ lẽ ra đã có thể được tổng hợp một lần rồi giữ làm tài sản dài hạn. Repo này đề xuất một cách làm gần hơn với trí nhớ tổ chức: tài liệu đầu vào được biên dịch thành wiki gồm summary, concept page, entity page và cross-link, sau đó mới phục vụ query hoặc chat.
Điều làm OpenKB hấp dẫn với giới làm agent là nó không chỉ là retrieval engine. Nó còn có lớp Skill Factory để distill tri thức đã biên dịch thành skill cài được cho agent khác. Nghĩa là repo không chỉ giúp đọc tài liệu tốt hơn, mà còn giúp chuyển tài liệu thành khả năng vận hành dùng lại được.
Chi tiết
Nếu nhìn dưới lăng kính sản phẩm, OpenKB đang cố đẩy RAG từ trạng thái “trả lời tạm thời” sang trạng thái “xây tài sản tri thức”. Đây là khác biệt lớn. Ở nhiều đội ngũ, tài liệu nội bộ, paper nghiên cứu, deck chiến lược hay SOP vẫn bị nạp vào vector store rồi lãng quên như các chunk cô lập. Khi câu hỏi mới xuất hiện, hệ thống lại phải dựng câu trả lời gần như từ đầu. README của OpenKB đưa ra một triết lý khác: hãy để LLM biên dịch nguồn đầu vào thành wiki sống, nơi summary, concept, entity và liên kết chéo được duy trì liên tục. Khi đó giá trị tri thức không nằm ở một lần truy vấn, mà nằm ở khả năng cộng dồn.
Điểm kỹ thuật đáng chú ý là cách repo xử lý tài liệu dài. Thay vì đẩy mọi thứ vào vector retrieval thuần túy, OpenKB dùng PageIndex để dựng tree index cho PDF dài rồi cho LLM đọc theo cấu trúc. Điều này phù hợp với các bộ tài liệu enterprise hoặc paper dày, nơi việc chỉ cắt chunk theo token thường làm mất logic xuyên chương. Với người làm AI cho doanh nghiệp, đây là chi tiết có giá trị thực tế vì tài liệu quan trọng hiếm khi ngắn và sạch như benchmark demo.
Điểm thứ hai là đầu ra wiki markdown tương thích Obsidian. Đây không phải chi tiết trang trí. Nó cho thấy dự án muốn tri thức sinh ra phải có đời sống riêng ngoài phiên chat. Người dùng có thể duyệt graph, mở concept pages, chỉnh tay nếu cần, rồi tiếp tục để agent dùng lại. Nghĩa là knowledge base không bị khóa trong một runtime kín. Nó vừa là substrate cho LLM, vừa là artefact có thể đọc được bởi con người.
Skill Factory là mảnh ghép chiến lược nhất. Khi một knowledge base đã đủ sâu về một chủ đề, OpenKB có thể distill nó thành skill folder mà các agent như Claude Code hoặc Codex cài trực tiếp. Từ góc nhìn tổ chức, điều này biến tri thức từ “nội dung để hỏi đáp” thành “hành vi có thể kích hoạt”. Đó là bước tiến lớn, vì nhiều doanh nghiệp không chỉ muốn agent trả lời hay, họ muốn agent hành xử theo một domain playbook đã được nội hóa.
Rủi ro của cách tiếp cận này là chi phí biên dịch ban đầu và chất lượng wiki phụ thuộc khá nhiều vào pipeline LLM phía sau. Nếu summary hay concept page được tạo lệch, sai lệch có thể được tích lũy thay vì bị quên đi. Nhưng ngay cả với rủi ro đó, OpenKB vẫn rất đáng theo dõi vì nó chạm đúng một xu hướng lớn: hạ tầng tri thức cho agent đang dịch từ vector DB đơn thuần sang các cấu trúc giàu ngữ nghĩa và có thể tái sử dụng lâu dài hơn.