Sơ Đồ Tri Thức & Mind Map Kiến Trúc

Beyond Document Retrieval: LLM Agents & Structured Data

arXiv:2608.19235v1 UT Arlington (2026) Sơ đồ tổng quan
Trực quan hóa dưới dạng Mind Map & Diagram chuyên sâu

Vượt Ra Ngoài Truy Xuất Tài Liệu (Document Retrieval)

Các Thách Thức Kiến Trúc Khi LLM Agent Truy Vấn Dữ Liệu Doanh Nghiệp Có Cấu Trúc

Tác giả: Sheikh Nazib Ahmed • Đại học University of Texas at Arlington, USA • sxa5256@mavs.uta.edu

Độ chính xác kết quả
95%
Staged (vs 43% Baseline)
Vi phạm bảo mật
0 vi phạm
Triệt tiêu 7 lỗi rò rỉ
Trả lời sai tự tin
0 trường hợp
Giảm từ 8 ca về 0
Từ chối chuẩn xác
100%
Chặn đứng truy cập trái phép

Tóm Tắt Khoa Học (Abstract) Bản Dịch Chuẩn

arXiv:2608.19235v1 [cs.DL]

RAG đã trở thành kiến trúc phổ biến để kết nối LLM với tri thức doanh nghiệp. Hầu hết hệ thống hiện nay truy xuất tài liệu phi cấu trúc (PDF, wiki, tickets) rồi nạp vào LLM để tóm tắt. Tuy nhiên, một nhóm ngày càng tăng các enterprise agent phải truy vấn dữ liệu có cấu trúc: cơ sở dữ liệu quan hệ (RDBMS), kho dữ liệu và các analytics API, nơi câu trả lời là một kết quả được tính toán (computed result) chứ không phải một đoạn văn bản được truy xuất (retrieved passage). Việc truy vấn dữ liệu có cấu trúc buộc hệ thống phải đưa ra các quyết định mà document RAG không bao giờ phải đối mặt, được cấu trúc thành 7 chiều kiến trúc cốt lõi: (1) Ngữ nghĩa truy xuất, (2) Phân quyền, (3) Nhận diện ý định, (4) Phân giải thực thể, (5) Đánh giá, (6) Chế độ thất bại, và (7) Độ trễ. Nghiên cứu thực nghiệm chứng minh agent phân tầng (staged agent) triệt tiêu hoàn toàn vi phạm bảo mật và nâng độ chính xác từ 43% lên 95%.

Từ khóa cốt lõi: Structured Enterprise Data Text-to-SQL Computed Result Read-After-Write Consistency Ambiguity Resolution
SƠ ĐỒ 1

Master Mind Map: Toàn Cảnh Nghiên Cứu

Cấu trúc 4 nhánh trọng tâm kết nối từ bản chất bài toán đến kiến trúc tham chiếu

Interactive Mind Map
LLM ENTERPRISE AGENTS DỮ LIỆU CÓ CẤU TRÚC (Beyond Document Retrieval) 1. KHÁC BIỆT BẢN CHẤT • Doc RAG: Tìm đoạn văn (Passage) • Structured: Tính toán kết quả (SQL) • LLM: Bộ dịch & tóm tắt, không phải đọc 2. BẢY CHIỀU KIẾN TRÚC • 1. Ngữ nghĩa truy xuất (Schema) • 2. Phân quyền ngoài model (Auth) • 3. Nhận diện ý định & phạm vi • 4. Phân giải thực thể (Canonical ID) • 5. Đánh giá đa giai đoạn • 6. Chế độ thất bại & 7. Độ trễ 3. KIẾN TRÚC THAM CHIẾU • Diễn giải tác vụ & phạm vi • Ngữ cảnh chính sách (Chạy song song) • Gắn kết thực thể & Cổng chính sách • Lập kế hoạch lược đồ & nguồn • Xác thực & Thực thi có quản trị • Giải thích & Lưu vết nguồn gốc 4. THẤT BẠI & BÀI TOÁN MỞ 5 Chế Độ Thất Bại: Ảo giác schema, sai khóa, nhầm ID, rò rỉ 4 Bài Toán Mở (Open Problems): Truy vấn xuyên miền, tiến hóa schema, Thẻ truy vấn giải thích, benchmark enterprise
SƠ ĐỒ 2

So Sánh Hai Đường Ống (Pipeline Flow Comparison)

Tại sao mô hình Document RAG không thể áp dụng nguyên si cho dữ liệu có cấu trúc

A. Document RAG Pipeline Mô hình cổ điển

Mục tiêu: Đọc đoạn văn bản và tổng hợp câu trả lời.

1. User Question 2. Embed Query (Dense Vector) 3. Retrieve Top-K Chunks (Vector Index Search) 4. LLM Context Generation (Tổng hợp từ đoạn văn) Final Response
B. Governed Structured-Data Agent Kiến trúc phân tầng

Mục tiêu: Dịch thành câu truy vấn hình thức, kiểm tra chính sách bảo mật, tính toán số liệu.

1
Diễn giải Tác vụ & Phạm vi (LLM) || Song song: Tra cứu Chính sách
Xác định vùng dữ liệu (Finance, HR, Ops) và vai trò người dùng (RBAC/Tenancy).
Model + Auth
2
Gắn kết Thực thể & Cổng Chính sách (Entity Binding & Gate)
Ánh xạ tên sang Canonical ID. Nếu mơ hồ hoặc ngoài quyền hạn -> DỪNG/HỎI LẠI ngay.
Bảo mật ngoài LLM
3
Lập kế hoạch Lược đồ & Nguồn dữ liệu (Schema-Aware Source Planning)
Sổ đăng ký (Registry) cung cấp bảng, cột, quan hệ khóa ngoại (Foreign Keys) hợp lệ.
Schema Registry
4
Xác thực Khả năng Trả lời (Answerability Validation)
Kiểm tra đủ điều kiện WHERE, vị từ thời gian, chỉ số hỗ trợ trước khi sinh SQL.
Pre-execution
5
Thực thi Truy vấn Có Quản trị & Giải thích Kết quả (Execution & Summary)
Database trả về bảng số liệu; LLM tóm tắt và ghi vết nguồn gốc (Audit/Provenance).
Audit Log
SƠ ĐỒ 3

Sơ Đồ 7 Chiều Kiến Trúc (The Seven Architectural Dimensions)

Mỗi chiều là một sự phân kỳ mang tính nguyên tắc giữa Document RAG và Structured Data Agent

Chiều 1 Retrieval Semantics

Ngữ Nghĩa Truy Xuất

Doc RAG: Độ tương đồng vector cosine trên text chunks.
Structured: Lập kế hoạch theo lược đồ (Schema Registry) & kiến tạo SQL hình thức.
Key: Schema-Aware Routing
Chiều 2 Authorization

Độ Mịn Phân Quyền

Doc RAG: ACLs cấp tài liệu, lọc trước khi nạp context.
Structured: Kiểm tra 3 tầng ngoài model: Thực thể (Entity), Vùng dữ liệu (Scope), và Trường (Field Masking).
Key: Outside Model Enforcement
Chiều 3 Intent Recognition

Nhận Diện Ý Định

Doc RAG: Ngầm định bên trong vector embedding tương đồng.
Structured: Xuất trạng thái tường minh: loại tác vụ (lookup, so sánh, điều tra) và tập nguồn ứng viên.
Key: Explicit Scope State
Chiều 4 Entity Resolution

Phân Giải Thực Thể

Doc RAG: Để mặc sự mơ hồ cho LLM tự suy luận khi đọc context.
Structured: Gắn kết bắt buộc với Canonical ID. Khử mơ hồ bằng cách hỏi lại người dùng trước khi truy vấn.
Key: Disambiguation Before Query
Chiều 5 Evaluation

Giao Thức Đánh Giá

Doc RAG: Recall@k, MRR (truy xuất) + Faithfulness (sinh).
Structured: Đánh giá nhận biết theo từng giai đoạn: Độ chính xác thực thi, Schema fidelity, Auth compliance.
Key: Stage-Aware Evaluation
Chiều 6 & 7 Failures & Latency

Chế Độ Thất Bại & Độ Trễ

Doc RAG: Bỏ sót đoạn, ảo giác context; độ trễ do Vector search + LLM.
Structured: Ảo giác schema, sai phép JOIN, rò rỉ phân quyền; độ trễ phụ thuộc Policy Service + DB query.
Key: Multi-Service Latency Graph
SƠ ĐỒ 4

Sơ Đồ Phân Loại 5 Chế Độ Thất Bại Table IV • Failure-Mode Taxonomy

5 rủi ro đặc thù mang tính hệ thống khi LLM Agent sinh và thực thi mã truy vấn trực tiếp trên cơ sở dữ liệu doanh nghiệp

⚠️
Bề Mặt Thất Bại Mới Khi Rời Xa Document Retrieval

Trong khi Document RAG chỉ dừng lại ở việc bỏ sót đoạn văn (*retrieval miss*) hoặc ảo giác câu chữ, Structured-Data Agent trực tiếp quyết định hành vi truy vấn thực thi (*executable behavior*). Sai sót ở đây dẫn đến rò rỉ dữ liệu, truy vấn sai lệch ngữ nghĩa, hoặc trả kết quả rỗng âm thầm.

5 Critical Risks
FAIL-01 Cú Pháp

Ảo Giác Lược Đồ

Schema Hallucination

Bịa bảng/cột không tồn tại
FAIL-02 Quan Hệ

Sai Khóa Nối

Wrong Joins

JOIN sai ngữ nghĩa nghiệp vụ
FAIL-03 Thực Thể

Nhầm Định Danh

Identifier Confusion

Lẫn lộn mã hợp đồng & dịch vụ
FAIL-04 Bảo Mật

Rò Rỉ Phân Quyền

Auth Leakage

Lộ sự tồn tại qua tóm tắt
FAIL-05 Toàn Vẹn

Tập Con Âm Thầm

Silent Data Subset

Chạy không lỗi nhưng thiếu WHERE
Chi Tiết Chẩn Đoán & Biện Pháp Giảm Thiểu Kiến Trúc (Architecture Defense)
1

Ảo Giác Lược Đồ (Schema Hallucination)

Mức độ: Cao Cú pháp & Schema
Hiện tượng & Biểu hiện

LLM tự suy diễn và bịa ra các bảng (*tables*) hoặc cột (*columns*) hoàn toàn không tồn tại trong cơ sở dữ liệu doanh nghiệp.

Tác động nguy hiểm

Truy vấn gãy vỡ ngay lập tức tại tầng thực thi, gây lỗi gián đoạn chuỗi tác vụ hoặc trả về thông báo lỗi vô nghĩa cho người dùng.

Giải pháp kiến trúc dập tắt

Schema Registry tất định: Chỉ cung cấp lược đồ đã qua kiểm định; chốt kiểm tra tĩnh (static schema validation) trước khi gửi truy vấn tới DB.

2

Sai Khóa Nối (Wrong Joins)

Mức độ: Cực kỳ nguy hiểm Ngữ nghĩa quan hệ
Hiện tượng & Biểu hiện

Các bảng được nối (JOIN) trên các trường sai ngữ nghĩa. Truy vấn hoàn toàn đúng cú pháp SQL nhưng sai bản chất nghiệp vụ.

Ví dụ thực tế trong bài báo

Nối trên trường trùng tên hoặc ngộ nhận: ví dụ nối account_number (số tài khoản thanh toán) với service_id (mã thuê bao) khiến dữ liệu bị nhân bản sai lệch.

Giải pháp kiến trúc dập tắt

Semantic Graph & Foreign-Key Constraints: Buộc LLM tuân thủ đồ thị quan hệ hình thức, không cho phép tự ý nối bảng ngoài các cạnh hợp lệ đã định nghĩa.

3

Nhầm Lẫn Mã Định Danh (Identifier Confusion)

Mức độ: Nghiêm trọng Phân giải thực thể
Hiện tượng & Biểu hiện

Hệ thống dùng lẫn lộn giữa các loại mã định danh khác nhau của cùng một khách hàng trong hệ sinh thái doanh nghiệp.

Bối cảnh doanh nghiệp

Một người dùng có đồng thời: Mã KH (customer_id), Số hợp đồng (contract_no), Số tài khoản (billing_id), và Mã thiết bị (device_id). LLM không thể tự phân biệt nếu không có siêu dữ liệu kiểu.

Giải pháp kiến trúc dập tắt

Entity Resolution & Điểm ngắt làm rõ: Khi mã nhập vào không đủ thông tin nhận diện loại, hệ thống dừng lại hỏi người dùng thay vì đoán mò.

4

Rò Rỉ Phân Quyền Qua Tóm Tắt (Auth Leakage)

Mức độ: Vi phạm tuân thủ Bảo mật & Compliance
Hiện tượng & Biểu hiện

Khi LLM tóm tắt kết quả đa miền, dù bản ghi cấm đã bị lọc bỏ trước đó, câu trả lời vẫn vô tình làm lộ sự tồn tại của miền dữ liệu bí mật.

Ví dụ kinh điển

Trả lời: "Tôi không thể truy xuất dữ liệu phiếu hỗ trợ nội bộ của bạn" → Vô tình xác nhận phiếu hỗ trợ đó có tồn tại và hệ thống đã tìm thấy nó.

Giải pháp kiến trúc dập tắt

Neutral Denial Templates: Định dạng từ chối đồng nhất ngoài LLM, ranh giới phản hồi kiểm soát cấu trúc câu trả lời để không để lộ cấu trúc bảng hay trạng thái truy vấn.

5

Tập Con Dữ Liệu Âm Thầm (Silent Data Subset)

Mức độ: Nguy hiểm ngầm định Toàn vẹn kết quả
Hiện tượng & Biểu hiện

Truy vấn chạy trơn tru 100%, không trả về bất kỳ lỗi nào, nhưng kết quả trả về bị thiếu hụt một phần dữ liệu quan trọng mà người dùng không hề hay biết.

Nguyên nhân cốt lõi

LLM bỏ quên một điều kiện WHERE bắt buộc (như status = 'ACTIVE', hoặc loại trừ bản ghi tạm) hoặc thiếu một nhánh ánh xạ ID đa nguồn.

Giải pháp kiến trúc dập tắt

Policy Injection & Benchmark Đối Chứng: Tự động tiêm các mệnh đề lọc bắt buộc từ Policy Engine trước khi thực thi; kiểm thử liên tục với 21 truy vấn chuẩn.

SƠ ĐỒ 5

Bằng Chứng Thực Nghiệm: Baseline vs. Staged Agent

Kết quả thử nghiệm có đối chứng (n = 21 câu hỏi, 4 vai trò, 2 nguồn dữ liệu độc lập)

Chỉ Số Đánh Giá (Metric) Baseline (Trực tiếp) Staged Agent
Độ chính xác kết quả (Outcome Accuracy) 0.43 0.95 (+52%)
Số lần vi phạm chính sách (Policy Violations) 7 vi phạm 0 (Triệt tiêu)
Tỷ lệ rò rỉ dữ liệu (Leakage Rate) 0.33 (33%) 0.00 (0%)
Câu trả lời sai nhưng tự tin (Confidently Wrong) 8 câu 0 câu
Độ chính xác khi từ chối (Refusal Accuracy) 0.00 1.00 (100%)
Khả năng quy kết nguyên nhân lỗi (Failure Attribution) 0.33 1.00 (100%)
PHÁT HIỆN CỐT LÕI

Độ chính xác tăng nhờ kiến trúc, không phải do LLM thông minh hơn!

Khi cả hai agent cùng quyết định trả lời, độ đúng đắn câu trả lời là giống hệt nhau (0.90).

Mức nhảy vọt từ 0.43 lên 0.95 hoàn toàn đến từ:

  • Biết kiềm chế từ chối khi thực thể bị mơ hồ;
  • Chặn đứng các truy vấn vượt quá quyền hạn (Role/Tenant);
  • Loại bỏ các phép nối (JOIN) chéo nguồn không hợp lệ.
-> Staged architecture mang lại khả năng quản trị tuyệt đối.
SƠ ĐỒ 6

Mind Map: 4 Bài Toán Mở (Open Architectural Problems)

Những giới hạn lớn mà ngành công nghiệp AI doanh nghiệp hiện chưa giải quyết trọn vẹn

OP1 Cross-domain Composition

Soạn Thảo Truy Vấn Xuyên Miền

Khi câu hỏi đòi hỏi dữ liệu từ nhiều database không có quan hệ khóa ngoại (Foreign Key) trực tiếp: Agent phải đánh đổi giữa phép nối liên kết lỏng (federated join), gọi tuần tự chuỗi API, hay tổng hợp ở tầng ứng dụng? Mỗi lựa chọn đều ảnh hưởng nghiêm trọng đến độ trễ và tính toàn vẹn phân quyền.

OP2 Schema Evolution

Quản Lý Sự Tiến Hóa Của Lược Đồ

Cơ sở dữ liệu doanh nghiệp liên tục thay đổi (thêm cột, đổi kiểu dữ liệu, bỏ bảng cũ). Hệ thống cần cơ chế phát hiện trôi dạt siêu dữ liệu (metadata drift), đảm bảo tương thích ngược và ngăn không cho prompt LLM nhận các schema đã lỗi thời.

OP3 Explanation & Provenance

Thẻ Truy Vấn (Query Card) & Giải Thích

Khác với RAG tài liệu có thể trích dẫn trực tiếp câu văn nguồn, dữ liệu có cấu trúc trả về con số tính toán. Người dùng nghiệp vụ không thể đọc mã SQL thô. Cần cơ chế sinh "Query Card" bằng ngôn ngữ tự nhiên, giải thích rõ cách tính mà không làm lộ cấu trúc cơ sở dữ liệu nhạy cảm.

OP4 Enterprise Evaluation

Đánh Giá Chuẩn Ở Quy Mô Doanh Nghiệp

Các benchmark hiện nay (Spider, BIRD) chỉ đo khả năng text-to-SQL đơn lẻ trên schema tĩnh. Thế giới thực cần một benchmark chuẩn mực bao gồm: phân quyền đa vai trò, phân giải thực thể mơ hồ, dữ liệu không đồng nhất và hành vi từ chối an toàn.

Kịch Bản Minh Họa Thực Tế End-to-End Enterprise Scenario Walkthrough

"Khách hàng nào có hóa đơn quá hạn mà đồng thời có phiếu hỗ trợ kỹ thuật chưa giải quyết?"

Kịch bản này đòi hỏi agent xử lý đồng thời 2 miền dữ liệu (Tài chính & Hỗ trợ kỹ thuật). Thay vì chỉ dùng 1 prompt đơn độc, Governed Structured-Data Agent thực hiện tuần tự qua 7 bước:

1. Phân Tích Ý Định

Xác định phép so sánh chéo giữa Finance và Support. Đầu ra là tập thực thể (Entity Set).

2. Kiểm Tra Quyền

Xác minh người dùng có quyền truy cập đồng thời cả hóa đơn và phiếu hỗ trợ hay không.

3. Lập Kế Hoạch Nguồn

Schema Registry tìm đường nối khóa ngoại (Customer_ID) hợp lệ giữa 2 bảng.

4. Thực Thi & Query Card

Thực thi an toàn và trả về danh sách kèm Query Card giải thích logic rõ ràng.