Wikontic vs LightRAG: Khi GraphRAG chặt chẽ, đỡ RÁC

TL;DR

• Vấn đề: GraphRAG hiện tại (như của Microsoft) đang "đốt tiền" để tạo ra những cái graph đầy rác. "Elon Musk" và "Musk" bị tách làm 2 node riêng biệt, khiến việc query bị phân mảnh.
• Wikontic (Paper Dec 2025): Giải quyết bằng cách dùng Wikidata làm "cảnh sát". Nó ép LLM phải map entity vào ID có sẵn. Kết quả: Graph siêu sạch, token cost giảm 20 lần.
• So sánh nhanh:
  • Wikontic: Dùng cho kiến thức chuẩn (Wikipedia, Science, History). Chính xác nhưng cứng nhắc.
  • LightRAG: Dùng cho dữ liệu nội bộ (Private Docs). Nhanh, bao quát nhưng hơi "bừa bộn".

1. "Graph Rác"

Anh em nào từng chạy thử Microsoft GraphRAG chắc đều trải qua cảm giác này: Hì hục setup, tốn $50 tiền API để index một cuốn sách, và kết quả nhận được là một cái graph... "ngáo ngơ".

Trong cái graph đắt đỏ đó, bạn sẽ thấy:
- Một node tên là Apple.
- Một node khác là Apple Inc..
- Một node nữa là Táo khuyết.

Với chúng ta, 3 cái này là một. Nhưng với GraphRAG (theo trường phái Open Information Extraction), đây là 3 thực thể khác nhau hoàn toàn. Khi bạn hỏi: "Tình hình tài chính của Apple thế nào?", hệ thống có thể chỉ quét node Apple mà bỏ quên luôn đống dữ liệu quý giá ở node Apple Inc..

Cái này trong nghề gọi là Surface Form Heterogeneity. Nghe tên thì nguy hiểm, nhưng hiểu đơn giản là: LLM nó sáng tạo quá mức, mỗi lần gọi tên một kiểu, và cái Graph của bạn biến thành bãi rác của những cái tên trùng lặp.

Tháng 12/2025 vừa rồi, team nghiên cứu tung ra Wikontic. Đọc paper xong tôi thấy hướng đi này cực kỳ thú vị: Thay vì thả cửa cho LLM muốn viết gì thì viết, họ ép nó vào khuôn khổ.

2. Wikontic: Chặt chẽ và khó tính

Hình 1: Pipeline của Wikontic. Thay vì "thả rông" cho LLM, hệ thống có bước (2) Refinement và (3) Normalization dựa trên Wikidata.

Nếu coi các phương pháp RAG hiện tại là những gã thợ săn thấy gì bắn nấy, thì Wikontic là một ông thủ thư già, cực kỳ nguyên tắc. Nó vận hành theo 3 luật bất thành văn:

Luật 1: Không có chuyện "tự bịa" quan hệ

Các tool Open IE thường cho ra những triple kiểu:

"Nolan" -- is the guy who made --> "Inception"

Wikontic gạt phăng đi. Nó bắt buộc phải map vào schema của Wikidata:

"Nolan" -- P57 (director) --> "Inception"

Nếu LLM trích xuất ra quan hệ "đạo diễn", Wikontic sẽ tra từ điển và map nó ngay về property P57.

Luật 2: Entity phải "Chính chủ"

Thấy chữ "Nolan" trong văn bản? Wikontic không vội tạo node mới (vì sợ trùng với Nolan nào đó khác). Nó tra ngay trong Database Alias:
- À, "Nolan" thường là alias của "Christopher Nolan" (Q41466).
- Chốt: Gán thông tin này vào node Q41466.

Hình 2: Cách Wikontic chuẩn hóa Entity. Nó tìm các ứng viên từ Alias DB, sau đó dùng LLM để chọn ra Canonical Name chính xác nhất.

Luật 3: Tiết kiệm là quốc sách

Nhờ việc không tạo node rác, Wikontic claim là chỉ tốn dưới 1,000 output tokens cho mỗi đoạn văn.
Để dễ hình dung: Con số này thấp hơn 20 lần so với Microsoft GraphRAG. Một sự tối ưu khủng khiếp về chi phí vận hành.

Hình 3: Kết quả benchmark MINE-1. Wikontic (cột màu cam) đạt độ nhớ thông tin >80%, bỏ xa GraphRAG (khoảng 48%).

Kết quả: Trên benchmark MINE-1, Wikontic đạt 86% Information Retention. GraphRAG gốc chỉ lẹt đẹt 48%. Tức là Wikontic nhớ dai gấp đôi với chi phí rẻ bằng 1/20.

3. Wikontic vs. LightRAG: Chọn phe nào?

Hình 4: Sự khác biệt cốt lõi. Wikontic (phải) gộp tất cả các biến thể tên gọi về một thực thể duy nhất nhờ Wikidata, trong khi Open IE (trái) tạo ra các node rời rạc.

Gần đây cộng đồng cũng hype LightRAG (của HKUDS). Nhiều anh em hỏi tôi nên dùng cái nào. Thực ra đây là cuộc chiến giữa hai triết lý:

Vậy chốt lại?

• Chọn Wikontic nếu bạn làm app Giáo dục, Lịch sử, News, Wiki-bot. Những domain mà Wikidata đã cover rất tốt.
• Chọn LightRAG nếu bạn làm Enterprise Search cho tài liệu nội bộ (Hợp đồng, Specs kỹ thuật, Email).

4. Nhưng khoan... Wikontic có "Gãy" không?

Có chứ. Hay thì hay vậy, nhưng tôi thấy Wikontic có một tử huyệt chí mạng: Nó phụ thuộc hoàn toàn vào Wikidata.

Hãy tưởng tượng bạn áp dụng Wikontic cho công ty dược phẩm của bạn.
- Tài liệu nhắc đến mã thuốc nội bộ: Project-ATPX4869.
- Wikontic tra Wikidata: 404 Not Found.
- Hệ quả: Nó sẽ đánh dấu thông tin này là "ontology-misaligned" (lệch chuẩn). Nhẹ thì nó bỏ qua, nặng thì nó cố ép Project-ATPX4869 vào một cái entity nào đó không liên quan.

Lúc này, sự "dễ dãi" của LightRAG lại lên ngôi. Nó sẽ vui vẻ tạo node Project-ATPX4869 và nối với Tác dụng phụ: Teo nhỏ mà không cần hỏi ý kiến ai cả.
Ngoài ra, Latency cũng là vấn đề. Việc phải lookup vào DB của Wikidata cho mỗi entity chắc chắn sẽ chậm hơn nhiều so với việc để LLM phun text tự do.

5. Kết bài

Nói tóm lại, ý tưởng cốt lõi của Wikontic là biến bài toán GraphRAG từ việc để LLM "tự do sáng tác" thành một quy trình "điền vào chỗ trống" (Slot Filling) dựa trên cấu trúc của Wikidata. Nó không chỉ đơn thuần là trích xuất text, mà là "ánh xạ" (mapping) thế giới thực vào một hệ thống định danh duy nhất.

Wikontic là một cú tát cần thiết vào xu hướng "nhồi nhét" hiện tại của GraphRAG. Nó chứng minh rằng: Chất lượng (Quality) quan trọng hơn Số lượng (Quantity).

Nếu anh em định build hệ thống production:
1. Với dữ liệu nội bộ: Vẫn nên stick với LightRAG hoặc custom lại pipeline của GraphRAG, nhưng hãy thêm bước Entity Resolution (học theo ý tưởng của Wikontic).
2. Với dữ liệu public/knowledge: Wikontic là chân ái.

Code của Wikontic sắp public, anh em có thể canh me tại repo bên dưới để test thử.

Nghiên cứu và source code được nhắc tới trong bài:
- Wikontic Paper: Arxiv 2512.00590
- LightRAG Paper: Arxiv 2410.05779
- LightRAG Repo: HKUDS/LightRAG
- Wikontic Repo: screemix/Wikontic