Tóm Tắt Tổng Quan: Khoảng Trống Của RAG Tiêu Chuẩn Trong Doanh Nghiệp
Trong môi trường vận hành hạ tầng kỹ thuật cao như viễn thông (Telecom Network Operations), các kỹ sư đối mặt với hàng chục nghìn trang tài liệu không đồng nhất: từ quy trình vận hành chuẩn (SOP), hướng dẫn cấu hình thiết bị của nhiều nhà cung cấp (Cisco, Huawei, Nokia, Ericsson), cho đến các báo cáo phân tích nguyên nhân gốc rễ (RCA) phức tạp.
Phương pháp Dense Vector Retrieval tiêu chuẩn thường thất bại nặng nề vì 3 lý do:
Một hàm khoảng cách ngữ nghĩa không thể đồng thời bao quát các từ viết tắt chuyên ngành, mã model và quan hệ liên kết cấu trúc giữa các phần tài liệu.
Khi cắt nhỏ tài liệu, một bước cấu hình quan trọng có thể bị chia đôi giữa đoạn $c_{i,j}$ và đoạn $c_{i,j+1}$, khiến LLM nhận ngữ cảnh cụt ngủn.
RAG tiêu chuẩn đẩy thẳng top-k đoạn vào LLM sinh câu trả lời mà không có cổng kiểm duyệt, dẫn đến ảo giác nghiêm trọng (21.4% tỷ lệ bịa đặt).
1. Hình Thức Hóa Bài Toán (Problem Statement)
Cho kho ngữ liệu doanh nghiệp đa nguồn $\mathcal{D} = \{d_1, d_2, \dots, d_N\}$, trong đó mỗi tài liệu thuộc về một hoặc nhiều không gian tên nhà cung cấp (vendor namespaces) $\mathcal{V} = \{v_1, \dots, v_M\}$. Mỗi tài liệu $d_i$ được chia thành tập các đoạn gối đầu nhau:
Với truy vấn người dùng $q$, mục tiêu là tìm tập bằng chứng $\mathcal{E} \subset \mathcal{C}$ và sinh câu trả lời $a = \mathcal{G}(q, \mathcal{E})$ sao cho mọi thông tin trong $a$ đều được chứng thực nghiêm ngặt bởi $\mathcal{E}$, triệt tiêu hoàn toàn hiện tượng ảo giác.
2. Quy Trình Giải Pháp Hai Giai Đoạn (Two-Phase Multi-Agent Architecture)
DocuSearch phân rã toàn bộ quá trình tìm kiếm và suy luận thành 2 giai đoạn rõ ràng: Giai đoạn Tiền-MMR (Pre-MMR) chịu trách nhiệm phân tích, truy xuất đa luồng và chọn lọc bằng chứng; Giai đoạn Hậu-MMR (Post-MMR) thực hiện vòng lặp thẩm định tác tử theo từng đoạn.
Giai Đoạn 1: Tiền-MMR (run_supervisor Pipeline)
Hình 1 Bài Báo Gốc(5 loại mẫu phản hồi)"] S1 --> S2["Bước 2: Trích xuất Từ khóa BM25
(LLM + Telecom Curated Lexicon)"] S2 --> S2b["Bước 2b: Phát hiện Vendor
(LLM + Regex Scoping)"] S2b --> T1["Bước 3: Vector Search
Qdrant + BGE-Large-1024
k_v = 40"] S2b --> T2["Bước 4: BM25 Search
SQLite FTS5
k_b = 40"] S2b --> T3["Bước 5: KG Expansion
SQLite Edge Table
k_kg = 15"] T1 --> RRF["Bước 5b: Dung hợp Weighted RRF
w_v = 0.50, w_b = 0.35, w_kg = 0.15, k = 60"] T2 --> RRF T3 --> RRF RRF --> CE["Bước 6: Tái xếp hạng Cross-Encoder
k_r = 12
s_final = 0.65 s_CE + 0.35 s_RRF"] CE --> MMR["Bước 7: Chọn lọc MMR
lambda = 0.65, Dung lượng tập E = 10"] MMR --> E_OUT(["Danh sách Bằng chứng E có thứ tự"]) classDef primary fill:#e0f2fe,stroke:#0284c7,stroke-width:2px,color:#0369a1; classDef fusion fill:#fef3c7,stroke:#f59e0b,stroke-width:2px,color:#92400e; classDef select fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#15803d; class S1,S2,S2b primary; class T1,T2,T3,RRF,CE fusion; class MMR,E_OUT select;
Hình 1: Quy trình xử lý song song 3 tín hiệu truy xuất kết hợp dung hợp RRF, tái xếp hạng Cross-Encoder và chọn lọc MMR.
Giai Đoạn 2: Hậu-MMR (run_per_chunk_evaluation Loop)
Hình 2 Bài Báo Gốc(Context Need Detection)"} N1 -- Có --> EXP["Lấy đoạn liền kề c_prev, c_next
(Metadata DB - Tối đa L = 2)"] EXP --> N2{"Điểm đầy đủ >= 7?
(Sufficiency Scoring)"} N1 -- Không --> N2 N2 -- Không đạt --> NEXT_C{"Còn đoạn trong E?"} NEXT_C -- Còn --> START NEXT_C -- Hết --> FALLBACK["Cơ chế Dự phòng Fallback:
Hợp nhất tất cả ngữ cảnh đã mở rộng"] N2 -- Đạt --> GEN["LLM Sinh câu trả lời ứng viên
(Nhiệt độ T = 0.0)"] GEN --> VERIFY{"Xác minh Căn cứ?
(Groundedness Verification)"} VERIFY -- Hợp lệ --> SUCCESS(["THÀNH CÔNG: Trả về câu trả lời
method = per_chunk"]) VERIFY -- Ảo giác --> NEXT_C FALLBACK --> FB_GEN["Sinh câu trả lời tổng hợp đa đoạn"] FB_GEN --> FB_VERIFY{"Xác minh Căn cứ Fallback"} FB_VERIFY -- Đạt --> FB_SUCCESS(["Trả về câu trả lời Fallback
method = fallback_merge"]) FB_VERIFY -- Thất bại --> REJECT(["Từ chối trả lời do thiếu chứng cứ"]) classDef check fill:#fef3c7,stroke:#f59e0b,stroke-width:2px,color:#92400e; classDef action fill:#e0f2fe,stroke:#0284c7,stroke-width:2px,color:#0369a1; classDef success fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#15803d; classDef fallback fill:#fee2e2,stroke:#ef4444,stroke-width:2px,color:#991b1b; class N1,N2,VERIFY,FB_VERIFY check; class EXP,GEN,FB_GEN action; class SUCCESS,FB_SUCCESS success; class FALLBACK,REJECT fallback;
Hình 2: Vòng lặp đánh giá tác tử theo từng đoạn với các cổng chặn nghiêm ngặt và cơ chế dự phòng hợp nhất đa đoạn.
3. Kiến Trúc Hệ Thống 6 Tầng Chức Năng (6 Functional Layers)
Hỗ trợ PDF, DOCX, XLSX thông qua Docling, PyMuPDF, python-docx. Cắt đoạn với kích thước $s = 900$ ký tự và độ gối $\delta = 140$ ký tự.
Ba luồng tìm kiếm song song: Qdrant Vector ANN ($k_v=40$), SQLite FTS5 BM25 ($k_b=40$), và SQLite Graph Neighbor ($k_{kg}=15$).
Dung hợp Weighted RRF với $k=60$, tái xếp hạng top 12 đoạn qua Cross-Encoder, và chọn lọc 10 đoạn bằng thuật toán MMR ($\lambda = 0.65$).
Trái tim của hệ thống: Đánh giá độc lập từng đoạn với 4 node LLM (Context Need, Sufficiency $\ge 7$, Generation, Grounding Check).
Điều phối qua đồ thị có trạng thái LangGraph gồm 5 node chính: query_analysis, retrieve, fuse_and_rank, evidence_select, per_chunk_eval.
Giao diện Plotly Dash tương tác hoàn chỉnh: tìm kiếm hội thoại, trực quan hóa quy trình thời gian thực, Knowledge Hub, Learning Hub, quản lý Ingestion.
4. Phương Pháp Luận & Công Thức Toán Học Cốt Lõi
A. Phân Loại Template & Định Dạng Khung Phản Hồi (5 Response Templates)
Trong Mục V.A và V.F của bài báo gốc, tác tử Template Selector đóng vai trò định hình khuôn mẫu sinh kết quả phía sau ($a = \mathcal{G}(q, \mathcal{E}, t^*)$). Thay vì để LLM sinh tự do dễ lan man, DocuSearch phân loại mọi truy vấn vào một trong 5 mẫu định sẵn $\mathcal{T}$. Tập 120 câu truy vấn đánh giá ở Bảng III được phân bổ đều trên 5 nhóm này:
| Mã Template ($t \in \mathcal{T}$) | Bản Chất & Ý Định Truy Vấn | Khuôn Mẫu Cấu Trúc Phản Hồi (Output Schema) | Ứng Dụng SmartRestaurant |
|---|---|---|---|
| 1. procedure_sop | Quy trình vận hành chuẩn: Các câu hỏi "Làm thế nào...", "Các bước thực hiện...". Đòi hỏi tính tuần tự nghiêm ngặt. | Danh sách bước đánh số (1, 2, 3...), điều kiện tiên quyết (Prerequisites), cú pháp lệnh CLI thực thi và bước kiểm tra xác thực (Verification). | Quy trình chế biến món ăn chuẩn tại bếp, quy trình kiểm kê kho nguyên liệu cuối ngày, checklist mở ca / đóng ca nhà hàng. |
| 2. concept_explanation | Giải thích khái niệm & nguyên lý: Các câu hỏi "X là gì?", "Cơ chế hoạt động của Y...". Đòi hỏi tính súc tích, định nghĩa chuẩn xác. | Định nghĩa cốt lõi, nguyên lý hoạt động kỹ thuật, các thành phần kiến trúc chính và trường hợp sử dụng điển hình (Use cases). | Aria giải thích phương pháp nấu Sous-vide, kỹ thuật ủ thịt Dry-aged, triết lý món ăn thực dưỡng hoặc phong cách ẩm thực Fusion. |
| 3. comparison_decision | So sánh & Ra quyết định: Các câu hỏi "Khác nhau giữa A và B?", "Nên chọn giải pháp nào trong tình huống X?". | Bảng đối chiếu đa tiêu chí (tính năng, hiệu năng, chi phí tài nguyên), ưu/nhược điểm từng giải pháp và khuyến nghị kỹ thuật cụ thể. | So sánh các Combo thực đơn cho nhóm khách tiệc, gợi ý dòng rượu vang (Cabernet vs Merlot) phù hợp nhất với khẩu vị bít tết của khách. |
| 4. parameter_lookup | Tra cứu thông số kỹ thuật: Tra cứu giá trị mặc định, dải giá trị cho phép, ý nghĩa cờ lệnh hoặc tham số cấu hình hệ thống. | Bảng thuộc tính: Tên tham số, kiểu dữ liệu, giá trị mặc định (Default), dải hợp lệ, tác động khi thay đổi giá trị. | Tra cứu lượng calo món ăn, thành phần dị ứng cụ thể (Gluten, Peanut, Hải sản), giá niêm yết và thời gian chế biến tiêu chuẩn. |
| 5. troubleshooting_rca | Khắc phục sự cố & Phân tích lỗi (RCA): Các truy vấn mã lỗi (Alarm codes, error logs, incident reports), mất kết nối hệ thống. | Mô tả triệu chứng (Symptoms), giả thuyết nguyên nhân gốc rễ khả dĩ, câu lệnh kiểm tra chẩn đoán và biện pháp xử lý từng bước. | Xử lý sự cố máy POS không in bill, cổng thanh toán ngân hàng treo, khách phàn nàn món ăn có mùi lạ (quy trình đổi món & xin lỗi). |
B. 3 Tín Hiệu Truy Xuất Bổ Trợ & Ý Nghĩa Kỹ Thuật Độc Lập
Trong môi trường tài liệu doanh nghiệp phức tạp, một hàm truy xuất đơn lẻ luôn tồn tại các "điểm mù" lớn. DocuSearch xây dựng thế kiềng ba chân bổ trợ lẫn nhau trên 3 chiều: Không gian ngữ nghĩa (Semantic), Khớp nối từ vựng chính xác (Lexical), và Cấu trúc quan hệ thực thể (Relational Graph):
Mã hóa ngữ nghĩa bằng BGE-Large-EN-v1.5 ($d=1024$), tính Cosine Similarity trên Qdrant ANN ($k_v=40$):
Khớp từ vựng chính xác trên SQLite FTS5 ($k_b=40, k_1=1.2, b=0.75$). Bắt trọn mã lỗi, từ viết tắt:
Duyệt bảng cạnh liên kết trong SQLite từ các đoạn hạt giống ($k_{kg}=15$):
| Tiêu Chí So Sánh | 1. Vector Search ($w_v=0.50$) | 2. BM25 Search ($w_b=0.35$) | 3. KG Expansion ($w_{kg}=0.15$) |
|---|---|---|---|
| Chiều Tương Đồng | Không gian biểu diễn ngữ nghĩa liên tục | Tần suất xuất hiện từ vựng rời rạc (TF-IDF) | Quan hệ liên kết cấu trúc và thực thể |
| Loại Bằng Chứng Bắt Được | Khái niệm tương đồng, câu hỏi trừu tượng | Từ viết tắt kỹ thuật, mã lỗi, tên lệnh CLI | Phụ lục, bước tiếp theo ở chương khác |
| Đóng Góp Vào Kết Quả | Định vị nhanh vùng tài liệu liên quan ngữ nghĩa | Khóa chặt các đoạn chứa đúng mã định danh | Tăng Recall@10 từ 0.71 lên 0.79 (+8 pp) |
| Ánh Xạ SmartRestaurant | "Món thanh đạm cho người giảm cân" | "Mã món D04", "Không tôm", "Bò Wagyu" | Món ăn → Nguyên liệu → Dị ứng → Nhà cung cấp |
C. Dung Hợp Weighted Reciprocal Rank Fusion (RRF)
Ba danh sách xếp hạng được hợp nhất với các trọng số thực nghiệm đã được tối ưu hóa:
Các đoạn xuất hiện đồng thời trong nhiều danh sách truy xuất nhận được điểm cộng hưởng tự nhiên. Hằng số $k=60$ đóng vai trò làm mượt, tránh để đoạn có rank #1 ở một tín hiệu đơn lẻ lấn át toàn bộ hệ thống.
D. Tái Xếp Hạng Cross-Encoder & Chọn Lọc Đa Dạng MMR
Kết hợp điểm tương tác sâu giữa truy vấn và ngữ cảnh với điểm hợp nhất RRF:
Cân bằng giữa độ liên quan cao nhất và mức độ đa dạng nội dung để tránh lãng phí context window:
5. Vòng Lặp Đánh Giá Tác Tử Theo Từng Đoạn (Per-Chunk Agentic Evaluation)
Khác biệt cơ bản nhất giữa DocuSearch và các hệ thống RAG thông thường nằm ở cách tiếp cận: Coi mỗi đoạn ứng viên $c \in \mathcal{E}$ như một bài toán giải quyết độc lập. Thay vì nhồi nhét tất cả các đoạn vào prompt khiến LLM bị phân tâm và dễ sinh ảo giác từ ngữ cảnh hỗn tạp, DocuSearch thẩm định tuần tự từng đoạn:
LLM đánh giá đoạn có bị đứt gãy không. Nếu có, truy vấn $c_{prev}, c_{next}$ từ SQLite (tối đa $L=2$).
Chấm điểm tính đầy đủ trên thang 1–10. Nếu điểm $\sigma(\tilde{c}, q) < 7$, loại ngay lập tức không thử sinh câu trả lời.
Sinh câu trả lời $\hat{a}$ dựa trên $\tilde{c}$, truy vấn $q$, và template $t^*$ ở nhiệt độ $T=0.0$ giữ tính tiền định.
Lệnh LLM độc lập thẩm định câu trả lời có được chứng thực hoàn toàn bởi $\tilde{c}$ không. Nếu đạt, kết thúc quy trình.
Trong trường hợp không một đoạn đơn lẻ nào trong top-10 vượt qua cả 4 bước kiểm tra (chiếm khoảng 3.6% truy vấn phức tạp), DocuSearch kích hoạt nhánh dự phòng: hợp nhất tất cả các ngữ cảnh đã mở rộng $\tilde{\mathcal{E}}$, sinh câu trả lời tổng hợp đa đoạn và kiểm tra căn cứ lần cuối trước khi trả lời kỹ sư.
6. Ngăn Xếp Công Nghệ & Bảng Tham Số Triển Khai
Bảng I: Ngăn Xếp Công Nghệ Cốt Lõi Core Tech Stack
| Thành Phần (Component) | Công Nghệ / Mô Hình |
|---|---|
| Vector Store | Qdrant (Self-hosted) |
| Embedding Model | BGE-Large-EN-v1.5 (d=1024, CUDA) |
| Reranker Model | Cross-Encoder (CUDA) |
| Full-Text Search | SQLite FTS5 (BM25) |
| Metadata & KG Store | SQLite (Edge Table + Documents) |
| LLM Inference | Local REST / vLLM (Mistral 7B) |
| Orchestration Graph | LangGraph (Stateful DAG) |
| Web UI Framework | Plotly Dash Interactive App |
| Document Parsing | Docling, PyMuPDF, python-docx, openpyxl |
| Ingestion Monitoring | watchdog directory monitor |
Bảng II: Cấu Hình Tham Số Mặc Định Default Parameters
| Tham Số | Ký Hiệu | Giá Trị |
|---|---|---|
| Vector top-k | $k_v$ | 40 |
| BM25 top-k | $k_b$ | 40 |
| KG top-k | $k_{kg}$ | 15 |
| Rerank top-k | $k_r$ | 12 |
| Tập bằng chứng MMR | $|\mathcal{E}|$ | 10 |
| Hằng số làm mượt RRF | $k$ | 60 |
| Trọng số RRF (Vector / BM25 / KG) | $w_v, w_b, w_{kg}$ | 0.50 / 0.35 / 0.15 |
| MMR Lambda | $\lambda$ | 0.65 |
| Ngưỡng tính đầy đủ | $\tau$ | 7 |
| Số vòng lặp lân cận tối đa | $L$ | 2 |
| Kích thước đoạn / Độ gối | $s, \delta$ | 900 / 140 ký tự |
| Nhiệt độ suy luận LLM | $T$ | 0.0 |
7. Đánh Giá Thực Nghiệm & Phân Tích Thành Phần (Ablation Study)
Thực nghiệm được thực hiện trên 120 truy vấn kỹ thuật viễn thông được gán nhãn thủ công từ các tài liệu SOP, RCA, cấu hình thiết bị của nhiều nhà cung cấp viễn thông.
Bảng III: Chất Lượng Truy Xuất (Retrieval Quality) 120 Queries
| Cấu Hình (System) | P@5 | R@5 | P@10 | R@10 |
|---|---|---|---|---|
| Dense only (Chỉ Vector) | 0.61 | 0.48 | 0.54 | 0.63 |
| Dense + BM25 | 0.68 | 0.56 | 0.61 | 0.71 |
| DocuSearch (Đầy Đủ - 3 Tín Hiệu) | 0.76 | 0.64 | 0.69 | 0.79 |
Mở rộng KG giúp tăng Recall@10 thêm +8 điểm so với Dense+BM25 và +16 điểm so với chỉ dùng Vector.
Bảng IV: Độ Căn Cứ & Tỷ Lệ Ảo Giác Answer Grounding
| Hệ Thống (System) | Có Căn Cứ | Ảo Giác | Dự Phòng |
|---|---|---|---|
| Single-pass RAG tiêu chuẩn | 71.2% | 21.4% | — |
| DocuSearch (Vòng lặp từng đoạn) | 89.6% | 6.8% | 3.6% |
Tỷ lệ có căn cứ tăng vọt +18.4 điểm phần trăm, tỷ lệ ảo giác giảm xuống chỉ còn 6.8%.
Bảng V: Phân Tích Triệt Tiêu Các Thành Phần (Ablation Study) Impact on Grounding Rate
| Cấu Hình Đánh Giá (Ablation Variant) | Tỷ Lệ Có Căn Cứ | Mức Sụt Giảm | Ý Nghĩa Thực Tế |
|---|---|---|---|
| DocuSearch Đầy Đủ (Full Pipeline) | 89.6% | Baseline | Kết hợp toàn diện cả 5 đóng góp mới |
| Không có kiểm tra căn cứ (w/o groundedness check) | 74.3% | -15.3 pp | Tác động mạnh nhất: LLM tự tin bịa câu trả lời khi không bị giám sát |
| Không có chấm điểm đầy đủ (w/o sufficiency scoring) | 78.1% | -11.5 pp | Cố sinh câu trả lời từ các đoạn thiếu thông tin ($\sigma < 7$) gây sai sót |
| Không có mở rộng lân cận (w/o neighbour expansion) | 82.4% | -7.2 pp | Đoạn bị đứt gãy quy trình giữa chừng làm giảm chất lượng nội dung |
| Không có tái xếp hạng Cross-Encoder | 83.7% | -5.9 pp | Thiếu tương tác sâu query-chunk làm lọt đoạn kém liên quan vào top-10 |
| Không có mở rộng Đồ thị Tri thức (w/o KG expansion) | 85.2% | -4.4 pp | Bỏ sót các bước quy trình nằm ở chương mục khác không chứa từ khóa trùng |
| Không có phân định vendor (w/o vendor scoping) | 86.1% | -3.5 pp | Nhiễu từ tài liệu của nhà cung cấp khác làm loãng kết quả tìm kiếm |
8. Định Hướng Tương Lai: Học Tăng Cường Cho Truy Xuất Thích Ứng (Adaptive RL)
Các tác giả đề xuất mô hình hóa quy trình truy xuất nhiều bước của DocuSearch như một Tiến trình Quyết định Markov (Markov Decision Process - MDP) $\mathcal{M} = (\mathcal{S}, \mathcal{A}, \mathcal{P}, \mathcal{R}, \gamma)$ lấy cảm hứng từ mô hình GridWorld TD-learning của Karpathy. Thay vì cấu hình trọng số RRF cố định, tác tử sẽ tự học chính sách khi nào cần bật BM25, khi nào mở rộng KG và khi nào dừng truy xuất.
Khuyến khích câu trả lời chính xác, trích dẫn đúng, phản hồi tốt từ kỹ sư trên UI Dash và phạt độ trễ cao.
Hiện tại $\Phi_{\text{current}} = 80.2\%$. Dự báo chính sách Q-Learning offline nâng lên $86.4\%$ (+6.2 pp).
Bảng VI: Mức Tăng Hiệu Năng Dự Kiến Với Học Tăng Cường Thích Ứng RL-Based Adaptive Retrieval Gains
| Chỉ Số Đánh Giá (Metric) | Hiện Tại (Current) | Dự Báo Với RL | Mức Tăng (Gain) |
|---|---|---|---|
| Precision@10 | 0.69 | 0.76 | +7 pp |
| Recall@10 | 0.79 | 0.86 | +7 pp |
| Tỷ lệ Căn cứ (Grounding Rate) | 89.6% | 94.5% | +4.9 pp |
| Điểm tổng hợp $\Phi$ | 80.2% | 86.4% | +6.2 pp |
9. Ánh Xạ Kiến Trúc DocuSearch Vào Đồ Án SmartRestaurant
Kiến trúc DocuSearch giải quyết trực tiếp 2 bài toán lớn trong hệ thống SmartRestaurant: (1) Trợ lý Aria tư vấn món ăn cho thực khách đòi hỏi độ chính xác tuyệt đối về dị ứng/nguyên liệu, và (2) Hệ thống quản lý tri thức nội bộ nhà hàng tra cứu quy trình chế biến món ăn (SOP) và xử lý sự cố thiết bị bếp/POS (RCA).
- Vector ($w_v = 0.50$): Hiểu nhu cầu trừu tượng của khách ("món thanh đạm ít calo", "tiệc sinh nhật sang trọng lãng mạn").
- BM25 ($w_b = 0.35$): Khớp chính xác tên món, mã món, hoặc thành phần cấm kỵ dị ứng ("không đậu phộng", "bò Wagyu A5", "mã D08").
- KG Expansion ($w_{kg} = 0.15$): Duyệt đồ thị quan hệ Món ăn → Nguyên liệu → Dị ứng → Nhà cung cấp thực phẩm.
Ảo giác trong nhà hàng có thể gây sốc phản vệ cho thực khách. Áp dụng Vòng lặp đánh giá từng đoạn với Sufficiency $\ge 7$ và bộ Groundedness check đảm bảo Aria không bao giờ tự bịa ra thành phần dinh dưỡng nếu tài liệu không đề cập rõ ràng.
Công thức chế biến các món phức tạp thường dài qua nhiều bước. Thay vì cắt đoạn quá dài, cơ chế Dynamic Neighbour Expansion ($L \le 2$) tự động kéo thêm các bước $c_{next}$ từ metadata database khi đầu bếp tra cứu quy trình chế biến trên tablet bếp.
Vendor scoping chuyển thành Branch/Cuisine scoping (giới hạn tìm kiếm theo Chi nhánh Quận 1, Quận 7 hoặc Menu chay). Triển khai On-premise qua Mistral/vLLM cục bộ bảo vệ 100% bí quyết công thức sốt và dữ liệu kinh doanh của chuỗi nhà hàng.
Tài Liệu Tham Khảo (Academic References)
[1] P. Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks,” in NeurIPS, vol. 33, pp. 9459–9474, 2020.
[2] S. Robertson and H. Zaragoza, “The Probabilistic Relevance Framework: BM25 and Beyond,” Foundations and Trends in Information Retrieval, 2009.
[3] J. Carbonell and J. Goldstein, “The Use of MMR, Diversity-Based Reranking for Reordering Documents and Producing Summaries,” in ACM SIGIR, 1998.
[4] S. Xiao et al., “C-Pack: Packaged Resources to Advance General Chinese Embedding,” arXiv:2309.07597, 2023.
[5] LangChain AI, “LangGraph: Building Stateful, Multi-Actor Applications with LLMs,” GitHub, 2024.
[6] Qdrant Team, “Qdrant: Vector Database for the Next Generation of AI Applications,” 2023.
[7] G. V. Cormack, C. L. A. Clarke, and S. Buettcher, “Reciprocal Rank Fusion Outperforms Condorcet and Individual Rank Learning Methods,” in ACM SIGIR, 2009.
[8] N. Reimers and I. Gurevych, “Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks,” in EMNLP, 2019.
[9] M. Edge et al., “From Local to Global: A Graph RAG Approach to Query-Focused Summarization,” arXiv:2404.16130, 2024.
[10] A. Q. Jiang et al., “Mistral 7B,” arXiv:2310.06825, 2023.
[11] A. Karpathy, “REINFORCEjs: Gridworld with Temporal Difference Learning,” 2015.