Thiết kế lớp tri thức bền vững: Kiến trúc RAG không chấp nhận 'đoán mò'

RAG (Retrieval-Augmented Generation) truy xuất thông tin nhưng không bao giờ ghi nhớ. Bài viết này đề xuất một kiến trúc hybrid gồm ba tầng — bằng chứng, tri thức và điều phối — để xây dựng ứng dụng có khả năng tích lũy hiểu biết qua thời gian, kèm theo bản triển khai Azure-native hoàn chỉnh được áp dụng cho bộ dữ liệu bảo hiểm tài sản mô phỏng.

Điểm cốt lõi không nằm ở công nghệ cụ thể mà ở tư duy thiết kế: biến tri thức thành một "tài sản" được biên dịch một lần, thay vì tái tạo từng truy vấn. Kiến trúc này đặc biệt hữu ích cho các hệ thống cần xử lý mâu thuẫn giữa các tài liệu, theo dõi lý do ra quyết định và cung cấp khả năng truy vết nguồn gốc chặt chẽ — điều mà RAG thuần túy không thể đáp ứng.

Giới hạn của RAG cổ điển: Truy xuất không phải là tích lũy hiểu biết

Trong loạt bài RAG-ING Ahead, tác giả đã xây dựng một bộ truy xuất cloud-native hoàn chỉnh. Tuy nhiên, sau khi vận hành các dự án thực tế trong thời gian dài, một câu hỏi lớn nảy sinh: hệ thống truy xuất cùng một đoạn văn, lý luận để đưa ra câu trả lời tốt — rồi vứt bỏ toàn bộ quá trình đó. Ngày hôm sau, khi có câu hỏi liên quan, hệ thống lại làm lại từ đầu với chi phí tương đương và không đảm bảo đi đến cùng một kết luận.

Sơ đồ bộ nhớ đệm ngữ nghĩa cho thấy kiến trúc RAG truyền thống không tích lũy được gì sau mỗi truy vấn

Bộ nhớ đệm ngữ nghĩa chỉ là giải pháp tạm thời — nó lưu câu trả lời, không lưu sự hiểu biết. Khi câu hỏi nằm ngoài ngưỡng tương tự, mọi thứ lại bắt đầu từ con số không. Đây không phải là bài toán truy xuất mà là bài toán kiến trúc: không có nơi nào trong RAG chuẩn để "hiểu biết" tích lũy.

Kiến trúc ba tầng: Bằng chứng, Tri thức và Điều phối

So sánh với một nhà nghiên cứu có tủ hồ sơ: người đầu tiên chỉ kéo tài liệu, đọc xong rồi quên hết — đó là RAG. Người thứ hai ghi chú tóm tắt, liên kết các khái niệm, ghi lại quyết định và lý do, cập nhật so sánh khi có bằng chứng mới — đó là mục tiêu cần xây dựng.

Kiến trúc đề xuất có ba tầng, mỗi tầng trả lời một câu hỏi khác nhau:

Tầng	Câu hỏi	Tối ưu cho
Bằng chứng (Evidence)	Tài liệu nguồn nào liên quan đến câu hỏi này?	Độ chính xác, trích dẫn, tính mới
Tri thức (Knowledge)	Hệ thống đã suy luận được gì? Nó đang tin điều gì?	Tính liên tục, mối quan hệ, tổng hợp
Điều phối (Orchestrator)	Tầng nào cần thiết để trả lời an toàn?	Định tuyến, rủi ro, phạm vi thời gian

Một quy tắc quan trọng giữ toàn bộ kiến trúc vững chắc: Trang tri thức không bao giờ là nguồn. Nó luôn phải truy vết được về một nguồn cụ thể. Vi phạm quy tắc này sẽ biến hệ thống thành một tập hợp các tuyên bố tự tin không thể kiểm chứng.

Sơ đồ kiến trúc hybrid ba tầng cho thấy cả hai tầng đều dẫn xuất từ cùng một nguồn và bổ sung cho nhau

Mô hình đối tượng trong lớp tri thức

Lớp tri thức không chỉ là một thư mục file Markdown mà là một kho lưu trữ có cấu trúc. Ba loại đối tượng là điểm mấu chốt:

Quyết định (Decision) — vì lý do thường chết đầu tiên. Mỗi quyết định lưu quy tắc, phạm vi áp dụng, ngày hiệu lực, người chịu trách nhiệm và lý do với con trỏ trỏ về nguồn. Trong bộ dữ liệu mô phỏng, một email trao đổi giữa nhà phân tích và trưởng bộ phận bảo hiểm giải thích lý do con số 15 năm — điều mà không hệ thống truy xuất nào đánh giá cao.

Mâu thuẫn (Contradiction) — một đối tượng hạng nhất, không phải lỗi. Các bộ tài liệu thực tế luôn tự mâu thuẫn. RAG xử lý điều này cực tệ: nó lấy một chunk, hoặc cả hai, rồi bảo mô hình hòa giải trong một lượt suy luận — dẫn đến câu trả lời trôi chảy nhưng đã âm thầm chọn phe. Mâu thuẫn cần có đối tượng riêng với trạng thái, cả hai phát biểu nguyên văn, ngày hiệu lực và trường tại_sao_chưa_giải_quyết. Nhiệm vụ của hệ thống là phát hiện xung đột và từ chối giải quyết nó.

Câu hỏi mở (Open question) — biết mình không biết gì. Một số câu hỏi chưa thể trả lời vì bị chặn bởi mâu thuẫn. Câu hỏi mở hiển thị rõ ràng là an toàn; câu trả lời sai lặng lẽ mới là thứ tạo ra khiếu nại.

Sáu kiểu thất bại mà kiến trúc này tồn tại để vượt qua

Bộ dữ liệu demo được xây dựng với sáu cái bẫy, và một hệ thống RAG thuần túy rơi vào tất cả:

1. Thay thế có phạm vi (Scoped supersession): Quy tắc chung là kiểm tra mái trên 20 năm, nhưng bản cập nhật sau chỉ áp dụng 15 năm cho một vùng gió cụ thể. RAG trả về "15 năm" mà không kèm điều kiện.
2. Mâu thuẫn thực sự: Hai tài liệu hiện hành nói ngược nhau. RAG chọn một; lớp tri thức tạo đối tượng mâu thuẫn và tuyên bố không có câu trả lời.
3. Trôi thuật ngữ: "Actual Cash Value", "ACV", "cash settlement basis" — nếu không phân giải thực thể, wiki sẽ có bốn trang riêng lẻ bất đồng với nhau.
4. Phạm vi ngày hiệu lực: Một quy tắc có hiệu lực từ 1/3 nhưng khiếu nại xảy ra 20/2. Semantic similarity không mã hóa thời gian — RAG trả lời sai một cách thuyết phục nhất.
5. Mất lý do: Lý do nằm trong email, quy tắc nằm trong hướng dẫn, và kết nối giữa chúng nằm ở hư không.
6. Đa bước (Multi-hop): Câu hỏi "Tại sao khiếu nại này được phân loại Level 1?" cần bốn bước đi qua bốn loại tài liệu. Top-k similarity xếp hạng, không đi qua.

Bảo mật và quản trị: Viết tri thức là một lớp rủi ro khác

Câu trả lời chat sai ảnh hưởng một cuộc trò chuyện. Trang tri thức chuẩn sai ảnh hưởng mọi câu trả lời xây trên nó, cho đến khi được sửa — và không ai nhận ra vì nó trông giống tri thức.

Mô hình không bao giờ ghi trực tiếp vào kho. Nó đề xuất bản vá. Ứng dụng xác thực và, nếu thay đổi có hệ quả, con người phê duyệt. Việc "giải quyết mâu thuẫn" không bao giờ được tự động hóa.

Vòng đời bản vá cho thấy mô hình chỉ đề xuất, ứng dụng quyết định áp dụng hay không

Triển khai Azure: Ánh xạ các tầng vào dịch vụ

Phần này hướng dẫn chi tiết triển khai trên nền tảng Azure mà tác giả sử dụng hàng ngày:

Kiến trúc Azure-native với màu sắc tương ứng: đỏ là lưu trữ, xanh dương là truy xuất, xanh lá là lớp tri thức

Trách nhiệm	Dịch vụ Azure
Nguồn thô bất biến	Azure Blob Storage
Quét PDF, bảng, biểu mẫu	Azure AI Document Intelligence
Truy xuất chunk, vector, hybrid	Azure AI Search
Triển khai mô hình chat và embedding	Microsoft Foundry
Trạng thái wiki có cấu trúc	Azure Cosmos DB for NoSQL
API và điều phối	FastAPI trên Azure Container Apps
Xử lý theo sự kiện	Event Grid → Container Apps Jobs

Một chi tiết quan trọng: vector similarity không phải là phân quyền. Bộ lọc bảo mật phải là một điều kiện cứng trên trường được đánh chỉ mục, áp dụng ở mọi truy vấn — kể cả trên trang wiki xuất Markdown.

Khi nào không nên xây dựng hệ thống này

Tác giả khuyên thẳng thắn: hãy dùng RAG thuần túy khi kho tài liệu nhỏ, người dùng chủ yếu cần tra cứu nguồn chính xác, tài liệu thay đổi quá nhanh, hoặc tổ chức chưa thể quản trị tri thức AI bền vững. Xây dựng lớp tri thức khi cùng một lĩnh vực được truy vấn lặp đi lặp lại, tổng hợp đa nguồn là bình thường, quyết định cần tồn tại qua biến động nhân sự, và dấu vết kiểm toán từ câu trả lời đến nguồn là yêu cầu bắt buộc.

Kết luận

Kiến trúc ba tầng này không thay thế RAG mà cho nó một nơi để "cất giữ" những gì đã học được. Với các hệ thống cần độ tin cậy cao — bảo hiểm, tài chính, y tế — việc tích lũy hiểu biết, theo dõi mâu thuẫn và truy vết nguồn gốc không còn là tùy chọn mà là yêu cầu cốt lõi của thiết kế.

Toàn bộ dự án (ứng dụng, hạ tầng, dữ liệu và bộ Obsidian vault sẵn sàng mở) có trên GitHub tại github.com/mcekikj/persistent-knowledge-layer, phát hành theo giấy phép MIT.