arrow_back
schema
Kế Hoạch Triển Khai Kỹ Thuật (Bản 1 Trang Hợp Nhất)

Advancing RAG for Structured Enterprise Data

Paper #01 • IIT Roorkee Bản Liền Mạch 1 Trang
science Triển khai công trình khoa học vào Production: SmartRestaurant AI Consultant (Aria)

Chuyển Đổi Naive RAG Sang Advanced Hybrid RAG Cho Dữ Liệu Thực Đơn & Bảng Biểu

Kế hoạch toàn diện được thiết kế trên một trang duy nhất, bao gồm phân tích hiện trạng, 6 trụ cột cốt lõi, đặc tả mã nguồn, lộ trình hành động 5 pha tăng tốc nhờ AI (3.5 – 4 ngày) và khung sườn đánh giá lại tự động với sự tham gia của AI (LLM-as-a-Judge).

Chỉ Số Tham Chiếu Paper 01 Reference
Precision@5 (Paper) 90.0% ↑ +15% so Naive
Recall@5 (Paper) 87.0% ↑ +13% so Naive
MRR (Paper) 0.85 Top-1 chính xác
Lộ Trình Dự Kiến 3.5 ngày ⚡ AI Tăng Tốc

1. Tổng Quan & Phân Tích Hiện Trạng Hệ Thống

info

Bản chất vấn đề: Vì sao SmartRestaurant cần chuyển đổi sang Advanced RAG của Paper 01?

Dữ liệu nhà hàng bản chất là dữ liệu doanh nghiệp hỗn hợp có cấu trúc cao (thực đơn món ăn, danh mục, giá tiền, calorie, nguyên liệu, cảnh báo dị ứng, combo theo bàn, chính sách voucher/đổi trả). Hiện tại hệ thống đang sử dụng kỹ thuật lọc chuỗi thô sơ trong backend/src/services/ragService.js, dẫn đến việc không thể xử lý các câu hỏi phức tạp về thành phần, không nhận diện được đồng nghĩa/ngữ nghĩa, và hoàn toàn không bảo toàn được cấu trúc bảng biểu khi đưa vào prompt của Aria.

Hiện Trạng Hiện Tại (SmartRestaurant)

Naive 2-Stage Filter
  • cancel
    Lọc từ khoá thô sơ: Sử dụng hàm stage1Filter so khớp chuỗi searchable.includes(kw). Bỏ sót hoàn toàn ngữ nghĩa (ví dụ: khách tìm "món ăn giải ngấy" sẽ không khớp với "salad thanh mát").
  • cancel
    Fallback thiếu thông minh: Khi không tìm thấy món theo từ khoá, tự động trả về Top món is_trending hoặc ngẫu nhiên, không phục vụ đúng nhu cầu thực tế của khách hàng.
  • cancel
    Không có Vector Embeddings & Reranking: Không lưu trữ véc-tơ ngữ nghĩa trong Supabase pgvector hay FAISS, không có bộ tái xếp hạng Cross-Encoder để ưu tiên các món phù hợp nhất.
  • cancel
    Cấu trúc bảng biểu bị làm phẳng: Dữ liệu món ăn chỉ được ghép nối dạng text thô, làm mất liên kết chặt chẽ giữa các thuộc tính dinh dưỡng, dị ứng và giá trị theo nhóm đối tượng.
Hậu quả thực tế: Trợ lý Aria dễ bị ảo giác (hallucination), không tư vấn trúng đích cho thực khách có yêu cầu kiêng cữ khắt khe (dị ứng đậu phộng, ăn chay trường, giới hạn calo), điểm Faithfulness thấp.

Mục Tiêu Sau Khi Áp Dụng Paper 01

Advanced Hybrid RAG
  • check_circle
    Lập chỉ mục cấp độ hàng (Row-Level Indexing): Mỗi món ăn và chính sách được tuần tự hoá thành đơn vị JSON chuẩn quan hệ hàng - cột, giữ nguyên ngữ cảnh tiêu đề, thành phần và chỉ số dinh dưỡng.
  • check_circle
    Truy xuất Lai Dung hợp (Hybrid Retrieval): Kết hợp song song Dense Vector (all-mpnet-base-v2 / BGE-M3) với Sparse BM25 theo tỷ lệ tối ưu: $$Score_{combined} = 0.6 \times Dense + 0.4 \times Sparse$$
  • check_circle
    Lọc Siêu Dữ Liệu bằng SpaCy NER: Trích xuất tức thì các thực thể (Tên món, Giá tiền, Ngân sách, Dị ứng, Cấp độ cay, Thời gian) để pre-filter loại bỏ các món vi phạm kiêng cữ.
  • check_circle
    Tái Xếp Hạng Ngữ Cảnh (Cross-Encoder Reranker): Chấm điểm trực tiếp cặp (Query, Món) bằng ms-marco-MiniLM-L-12-v2 để chọn Top-5 món chuẩn xác nhất.
  • check_circle
    Bộ nhớ 10 Lượt & Vòng Lặp Phản Hồi: Khi thực khách đánh giá Thumbs-down (👎) hoặc phản hồi không hài lòng, hệ thống tự động tái cấu trúc truy vấn (Query Reformulation) và truy xuất lại.
Kỳ vọng sau triển khai: Giải quyết triệt để tình trạng ảo giác, phản hồi chính xác theo thực đơn và ràng buộc của thực khách (dị ứng, chế độ ăn, ngân sách), nâng cao chất lượng tư vấn của trợ lý Aria.

2. 6 Trụ Cột Kỹ Thuật Đột Phá Cho Dữ Liệu Có Cấu Trúc

Thiết Kế Đặc Thù Cho Dữ Liệu Bảng Biểu & Quan Hệ Hàng Cột

Bài báo giải quyết triệt để sự thất bại của các hệ thống RAG văn bản truyền thống khi đối mặt với dữ liệu bảng biểu, hồ sơ nhân sự và bảng giá. Dưới đây là cách chuyển hóa từng trụ cột thành các thành phần kỹ thuật tương ứng trong kiến trúc SmartRestaurant.

1

Lập Chỉ Mục Cấp Hàng (Row-Level Indexing)

Thay vì làm phẳng cả trang menu hay bảng thành đoạn text dài làm đứt gãy quan hệ dữ liệu, hệ thống chia nhỏ từng món ăn và biến thể thành một bản ghi hàng có cấu trúc (Structured Row Unit).

// Định dạng tuần tự hoá hàng:
[Món: Phở Bò Tái Lăn | Mục: Món Nước | Giá: 65k | Calo: 520 | Dị ứng: Bò, Hành tây | Cay: 1/5]
verified Bảo toàn 100% quan hệ hàng-cột
2

Lọc Siêu Dữ Liệu (SpaCy NER Filter)

Tích hợp bộ trích xuất thực thể có tên SpaCy NER chuyên biệt cho F&B để bóc tách: loại món, hạn chế dị ứng (hải sản, gluten, đậu phộng), chế độ ăn (chay, keto), và ngân sách mong muốn.

// Bộ lọc tự động áp dụng:
Filter: is_vegetarian=True AND allergens NOT CONTAINS 'peanut'
verified Loại trừ vi phạm y tế & kiêng cữ trước khi xếp hạng
3

Truy Xuất Lai (Dense + BM25 Fusion)

Dung hợp giữa Dense Embeddings (bắt ngữ nghĩa trừu tượng: "món nhậu thanh nhẹ") và BM25 (khớp chính xác mã món, tên món cụ thể, từ khoá số lượng/giá).

$$Score = 0.6 \times S_{dense} + 0.4 \times S_{sparse}$$
verified Precision@5 tăng từ 75% lên 90%
4

Tái Xếp Hạng Ngữ Cảnh (Cross-Encoder)

Top 20 ứng viên sau bước lai được chuyển qua mô hình Cross-Encoder ms-marco-MiniLM-L-12-v2 để chấm điểm tương thích trực tiếp theo cặp (Query, Item).

// Đánh giá tương tác sâu:
CrossEncoder.predict([(user_query, item_text)])
verified MRR đạt 0.85 — Món đúng nhất luôn ở Top 1
5

Tinh Chỉnh Truy Vấn Động (Query Expansion)

Tự động viết lại (Query Rewriting) các câu hỏi mơ hồ ("uống gì ngon?") và mở rộng truy vấn (Query Expansion) với từ khoá đa dạng dựa trên LLM Groq để bao quát tối đa các món tiềm năng.

// Tự động biến đổi truy vấn:
"ăn nhẹ" → "khai vị, salad, nem cuốn, súp ấm"
verified Recall@5 tăng vọt từ 74% lên 87%
6

Vòng Lặp Phản Hồi (Human-in-the-Loop)

Duy trì bộ nhớ hội thoại 10 lượt tương tác (ConversationBufferMemory). Bổ sung nút Thích/Không thích (👍/👎); khi khách bấm 👎, hệ thống tự động kích hoạt truy xuất lại với chiến lược mới.

// Cơ chế tự thích ứng:
Feedback == 👎 → Auto-trigger reformulated re-retrieval
verified Tự sửa sai theo thời gian thực (Self-Correction)
anchor Kỹ Thuật "Tiếp Đất" Nghiêm Ngặt (Grounded Prompting)
Chống Ảo Giác 100%

"Tiếp đất" (Grounding) là gì? Giống như một chiếc mỏ neo giữ chặt con tàu, "Tiếp đất" là kỹ thuật ép mô hình AI chỉ được phép đưa ra câu trả lời dựa trên 100% dữ liệu thực đơn thực tế được tìm thấy trong kho CSDL. AI bị cấm tuyệt đối việc tự suy đoán hay "bịa" (hallucination) ra món ăn, giá tiền hoặc thành phần không có thật.

check_circle 4 Cơ Chế Ràng Buộc Trong Prompt Của Trợ Lý Aria:
  • Khóa biên dữ liệu: Đặt toàn bộ thông tin món ăn vào thẻ <retrieved_menu> để AI nhận thức rõ ranh giới thông tin.
  • Quy tắc cấm đoán (Hard Negative): Nếu khách hỏi món nhà hàng không có, AI bắt buộc phải trả lời: "Quán chưa có món này, em gợi ý món gần nhất...", cấm tự sáng tác món.
  • Buộc trích dẫn thuộc tính: Mỗi món gợi ý đều phải kèm theo giá tiền, calo, và cảnh báo dị ứng lấy trực tiếp từ bảng dữ liệu.
  • Tự động tóm tắt: Khống chế câu trả lời dưới 3-4 câu trọng tâm, tránh dài dòng để khách chốt món nhanh trên điện thoại.
layers Kiến Trúc Chỉ Mục Kép Đa Tầng (Dual-Index Optimization)

Hệ thống duy trì 2 chỉ mục song song: Chỉ mục độ chính xác cao chạy trên FAISS HNSW + BGE-M3/all-mpnet-base-v2 phục vụ các truy vấn chuyên sâu về dinh dưỡng, và Chỉ mục hạng nhẹ In-Memory chạy tại Node.js Redis phục vụ tra cứu nhanh tên món và giá tiền với độ trễ < 15ms.

3. Kiến Trúc Hệ Thống & Luồng Dữ Liệu Tích Hợp

Kiến Trúc Tích Hợp Toàn Diện (End-to-End System Architecture)

Sơ đồ dưới đây minh họa sự tương tác giữa 3 tầng chính: Frontend (Web App khách hàng/nhân viên), Node.js Backend Gateway & Redis Cache, và Python AI-Service (FastAPI + Advanced RAG Core).

lightbulb Vì Sao Cần Tách Biệt Hai Luồng Ngoại Tuyến (Offline) & Trực Tuyến (Online)? (Giải thích đơn giản)

Hãy hình dung quy trình này tương tự như cách vận hành một bếp nhà hàng chuyên nghiệp:

Luồng Ngoại Tuyến (Offline Pipeline) — "Khâu Sơ Chế Buổi Sáng"

Trước khi mở cửa đón khách, đầu bếp phải rửa rau, hầm nước dùng, ướp thịt sẵn. Tương tự, mỗi khi quản lý cập nhật thực đơn hoặc định kỳ ban đêm, hệ thống chạy ngầm để tuần tự hoá bảng món ăn thành text và tính toán sẵn Vector Embeddings + chỉ mục BM25. Quá trình này nặng về CPU/GPU nên làm trước dưới nền để không bắt khách chờ đợi.

Luồng Trực Tuyến (Online Pipeline) — "Phục Vụ Món Ra Bàn Trong Tích Tắc"

Khi thực khách ngồi vào bàn và hỏi trợ lý Aria ("Cho tôi món thanh đạm không cay dưới 100k"), hệ thống không cần tạo lại embedding từ đầu, mà chỉ việc quét tìm trên các chỉ mục đã chuẩn bị sẵn, lọc dị ứng bằng SpaCy và xếp hạng Top 5 món. Nhờ đó, câu trả lời xuất hiện tức thì trong < 500ms.

account_tree

Sơ Đồ Luồng Dữ Liệu: Xử Lý Ngoại Tuyến & Truy Vấn Trực Tuyến

Hình 1 Tương Thích Bài Báo
flowchart TD
    subgraph Offline["LUỒNG NGOẠI TUYẾN (Offline Pipeline) — 'Khâu Sơ Chế'"]
        DB[(Supabase PostgreSQL)] --> Serializer["Module Row Serializer"]
        Serializer --> RowSerialized["Văn bản Tuần Tự Hóa row_serialized"]
        RowSerialized --> EmbeddingGen["Mô hình Embedding (768-dim)"]
        RowSerialized --> BM25Corpus["Tokenize Tiếng Việt & BM25 Corpus"]
        EmbeddingGen --> FAISSIndex["FAISS HNSW Index (M=32)"]
        BM25Corpus --> BM25Index["Rank-BM25 Inverted Index"]
    end

    subgraph Online["LUỒNG TRỰC TUYẾN (Online Pipeline) — 'Phục Vụ Ra Bàn'"]
        User["Khách Hàng (Web App)"] -->|"1. Đặt câu hỏi"| Gateway["Node.js Gateway / Express"]
        Gateway -->|"2. Forward query"| AIService["Python AI-Service (FastAPI)"]
        
        AIService --> RetCoord["Hybrid Retriever Orchestrator"]
        RetCoord --> NERFilter["F&B NER Extractor (Bước 3.1)"]
        RetCoord --> ParallelSearch{"Truy Vấn Song Song (Độ Sâu Mở Rộng)"}
        
        ParallelSearch -->|"Dense Search"| FAISSIndex
        ParallelSearch -->|"Sparse Search"| BM25Index
        
        FAISSIndex -->|"Top 30 Dense"| Fusion["Score Fusion (0.6 / 0.4)"]
        BM25Index -->|"Top 30 Sparse"| Fusion
        
        Fusion --> HardFilter["Pre-Reranking Hard-Filter (Bước 3.1)
Loại 100% món dị ứng & quá giá"] NERFilter -.->|"Truyền điều kiện lọc"| HardFilter HardFilter -->|"Top 20 Ứng Viên Sạch"| Reranker["Cross-Encoder Reranker (ms-marco) (Bước 3.2)"] Reranker -->|"Top 5 Món Tối Ưu"| GroundedPrompt["Grounded Prompting Builder"] GroundedPrompt --> LLM["Groq LLaMA 3.3 70B"] LLM -->|"SSE Stream Token"| Gateway Gateway -->|"Hiển thị câu trả lời & món ăn"| User end subgraph FeedbackLoop["VÒNG LẶP PHẢN HỒI ĐÓNG (Closed-Loop Feedback)"] User -.->|"Khách bấm Thumbs-Down 👎"| FeedbackAPI["POST /rag/feedback"] FeedbackAPI -.-> Telemetry["Redis Telemetry Cache"] Telemetry -.-> Reformulator["Query Reformulator (Bước 4.1)"] Reformulator -.->|"Bắn câu truy vấn tái cấu trúc (< 1.2s)"| ParallelSearch end
1 NER & Over-Sampling

Trích Xuất F&B NER & Nới Rộng Truy Vấn

F&B NER bóc tách từ khóa dị ứng, ngân sách, ăn chay. Retriever tự động mở rộng độ sâu ứng viên (Top 30) để không bao giờ bị thiếu hụt sau khi lọc.

2 Parallel & Hard-Filter

Truy Vấn Kép & Lọc Cứng An Toàn

FAISS + BM25 tìm kiếm song song < 5ms; Dung hợp điểm số 0.6/0.4 và loại bỏ 100% món dị ứng hoặc vượt giá theo quy tắc Zero Tolerance.

3 Cross-Encoder Top-5

Tái Xếp Hạng Chuẩn Xác

Đưa danh sách Top 20 ứng viên đã lọc sạch qua mô hình Cross-Encoder để chấm điểm tương quan ngữ cảnh sâu, chọn ra đúng Top 5 món ngon nhất.

4 Grounded Streaming

Tạo Sinh Có Tiếp Đất

Nhúng 5 món vào Grounded Prompt Template của Groq LLaMA 3.3. Trả về token streaming cực nhanh (TTFT < 400ms) kèm trích dẫn nguồn.

psychology

3.3. Khung Sườn Đánh Giá & Tự Phản Tỉnh Bằng AI (AI-in-the-Loop Evaluation)

Paper 01 Mục 3.10 & 4.6

Thay vì chỉ dựa vào kiểm thử thủ công, hệ thống tích hợp 4 tầng giám sát và đánh giá tự động bằng AI để đảm bảo trợ lý Aria luôn tư vấn trung thực, chuẩn xác và liên tục tự thích ứng:

L1 LLM-as-a-Judge

Dùng LLaMA 3.3 70B hoặc GPT-4o chấm điểm định lượng tự động offline trên 3 tiêu chí: Tính trung thực (Faithfulness), Độ liên quan (Relevance), và Độ đầy đủ (Completeness).

Chấm điểm tự động
L2 Guardrail Verifier

Mini-agent chạy ngầm tự phản tỉnh trong thời gian thực (Real-Time Reflection): Quét vi phạm dị ứng và ngân sách trước khi stream token cuối cùng ra bàn ăn. Tự kích hoạt sửa lỗi nếu phát hiện vi phạm.

Phản tỉnh tức thì
L3 Failure Analyzer

Mỗi khi thực khách nhấn nút 👎, AI tự động phân loại nguyên nhân lỗi (Miss retrieval, Sai rerank, Trả lời lạc đề, Câu hỏi mơ hồ) và chuyển giao cho bộ Query Reformulator viết lại truy vấn.

Phân tích lỗi tự động
L4 Human Calibration

Đối soát định kỳ giữa chuyên gia ẩm thực (Human Evaluator) và AI Judge trên 50 lượt mẫu ngẫu nhiên (chỉ số $\kappa \ge 0.85$) để đảm bảo tiêu chuẩn đánh giá luôn khách quan và chuẩn vị.

Đối soát chuyên gia

4. Đặc Tả Mã Nguồn Kỹ Thuật (Code Specifications)

Chi Tiết Cấu Trúc File & Mã Nguồn Cần Thêm / Sửa Đổi

Được thiết kế mô-đun hoá, tương thích hoàn toàn với kiến trúc hiện có của SmartRestaurant

Python 3.11 + FastAPI + Node.js
folder_copy

Cấu Hình Cây Thư Mục Làm Việc (Workspace Directory Structure)

MONOREPO MAPPING

Sơ đồ tổ chức phân cấp thư mục của toàn bộ dự án SmartRestaurant, thể hiện rõ ranh giới giữa Python AI Service (Advanced RAG Core), Node.js Gateway (Backend hiện có), và React Client:

SmartRestaurant/
├── ai-service/                          # [NEW] Microservice Python độc lập chuyên trách Advanced RAG
│   ├── app/
│   │   ├── main.py                      # FastAPI App: Đăng ký routes, middleware CORS, health check
│   │   ├── api/routes/
│   │   │   ├── retrieve.py              # POST /rag/retrieve - Truy vấn hybrid & rerank top-k
│   │   │   ├── chat.py                  # POST /rag/chat - Sinh câu trả lời Grounded SSE stream
│   │   │   └── sync.py                  # POST /rag/sync-menu - Webhook đồng bộ menu vào FAISS/BM25
│   │   ├── processors/                  # Lõi 6 Trụ Cột Kỹ Thuật (Paper 01 Guidelines)
│   │   │   ├── row_serializer.py        # Trụ 1: Table-Aware Row Serialization (giữ quan hệ hàng-cột)
│   │   │   ├── metadata_filter.py       # Trụ 2: F&B NER & Pre-retrieval Hard-Filtering (bóc tách dị ứng/giá & lọc cứng)
│   │   │   ├── hybrid_retriever.py      # Trụ 3: Dual-Index Fusion (FAISS HNSW dense + BM25 Okapi sparse)
│   │   │   ├── cross_encoder_reranker.py# Trụ 4: Tái xếp hạng ngữ cảnh sâu (ms-marco-MiniLM-L-12-v2)
│   │   │   └── query_reformulator.py    # Trụ 5 & 6: Viết lại câu mơ hồ & mở rộng truy vấn khi nhận 👎
│   │   ├── memory/
│   │   │   └── conversation_buffer.py  # Bộ nhớ hội thoại 10 lượt tương tác gần nhất
│   │   └── evaluation/                  # Khung sườn đánh giá AI-in-the-Loop
│   │       ├── llm_judge.py             # L1: Thẩm phán LLM-as-a-Judge chấm điểm định lượng
│   │       ├── guardrail_verifier.py    # L2: Mini-agent tự phản tỉnh thời gian thực (Real-time Reflection)
│   │       └── run_eval.py              # Test suite tự động 100 câu hỏi test benchmark
│   ├── data/indexes/                    # Thư mục lưu file chỉ mục nhị phân FAISS (.bin) và BM25 (.pkl)
│   ├── Dockerfile                       # Multi-stage Docker build nhẹ (~850MB) tối ưu C++ CPU
│   └── requirements.txt                 # faiss-cpu, rank-bm25, sentence-transformers, spacy, groq
├── backend/                             # [EXISTING] Node.js Express Gateway hiện tại
│   └── src/
│       ├── controllers/
│       │   └── feedbackController.js    # [NEW] Tiếp nhận telemetry Thumbs 👍/👎 và sync vào DB
│       └── services/
│           └── ragService.js            # [MODIFY] Chuyển đổi từ lọc từ khóa thô sang gọi ai-service
├── frontend/                            # [EXISTING] React Web Client
│   └── src/components/
│       └── AriaChatWidget.jsx       # [MODIFY] Bổ sung cặp nút đánh giá Thumbs Up / Thumbs Down
├── database/
│   └── migrations/
│       └── 20260912_add_rag_columns.sql # [NEW] Kích hoạt pgvector, thêm cột embedding & row_serialized
└── docker-compose.yml                   # [MODIFY] Bổ sung service ai-service kết nối chung internal network
NEW ai-service/processors/row_serializer.py
Trụ cột 1: Table-Aware Row-Level Indexing

Tuần tự hóa từng món ăn từ bảng menu_items thành các văn bản bán cấu trúc có tiêu đề ngữ cảnh rõ ràng, bảo toàn mối quan hệ hàng - cột theo đúng mục 3.1.2 của bài báo.

# ai-service/processors/row_serializer.py
from typing import Dict, Any

def serialize_menu_row(item: Dict[str, Any]) -> str:
    """
    Tuần tự hoá 1 hàng của bảng menu_items thành chuỗi biểu diễn có cấu trúc.
    Bảo toàn toàn bộ các thuộc tính hàng - cột để lập chỉ mục véc-tơ và BM25.
    """
    category_name = item.get("category", {}).get("name") or item.get("categories", {}).get("name") or "Khác"
    ingredients = ", ".join(item.get("ingredients") or []) or "Không ghi chú"
    allergens = ", ".join(item.get("allergens") or []) or "Không có dị ứng phổ biến"
    spice = item.get("spice_level", 0)
    calories = item.get("calories", "N/A")
    price_vnd = f"{int(item.get('price', 0)):,} VND"

    serialized = (
        f"[MÓN ĂN: {item.get('name', 'Chưa rõ')}]\n"
        f"• Phân loại: {category_name}\n"
        f"• Giá bán: {price_vnd}\n"
        f"• Độ cay: {spice}/5\n"
        f"• Lượng Calo: {calories} kcal\n"
        f"• Thành phần nguyên liệu: {ingredients}\n"
        f"• Cảnh báo dị ứng: {allergens}\n"
        f"• Mô tả hương vị: {item.get('description', '')} {item.get('ai_description', '')}"
    )
    return serialized.strip()
NEW ai-service/processors/hybrid_retriever.py
Trụ cột 3: FAISS HNSW + BM25 Fusion ($0.6/0.4$)

Thực thi công thức kết hợp điểm số tại Mục 3.3.3 của bài báo: Score = 0.6 * Dense + 0.4 * Sparse.

# ai-service/processors/hybrid_retriever.py
import numpy as np
import faiss
from rank_bm25 import BM25Okapi
from sentence_transformers import SentenceTransformer
from typing import List, Dict, Any, Tuple

class HybridMenuRetriever:
    def __init__(self, dense_model_name: str = "sentence-transformers/all-mpnet-base-v2"):
        # Load mô hình Dense Embeddings
        self.encoder = SentenceTransformer(dense_model_name)
        self.dimension = 768
        
        # Cấu hình FAISS HNSW theo paper (M=32, efConstruction=200, efSearch=50)
        self.index = faiss.IndexHNSWFlat(self.dimension, 32)
        self.index.hnsw.efConstruction = 200
        self.index.hnsw.efSearch = 50
        
        self.corpus_items: List[Dict[str, Any]] = []
        self.bm25: BM25Okapi = None

    def build_index(self, serialized_rows: List[str], raw_items: List[Dict[str, Any]]):
        self.corpus_items = raw_items
        
        # 1. Xây dựng FAISS Dense Index
        embeddings = self.encoder.encode(serialized_rows, convert_to_numpy=True, normalize_embeddings=True)
        self.index.reset()
        self.index.add(embeddings)
        
        # 2. Xây dựng BM25 Sparse Index
        tokenized_corpus = [doc.lower().split() for doc in serialized_rows]
        self.bm25 = BM25Okapi(tokenized_corpus)

    def retrieve(self, query: str, top_k: int = 20) -> List[Tuple[Dict[str, Any], float]]:
        if not self.corpus_items:
            return []
            
        # A. Dense Query
        q_emb = self.encoder.encode([query], convert_to_numpy=True, normalize_embeddings=True)
        dense_distances, dense_indices = self.index.search(q_emb, len(self.corpus_items))
        
        dense_scores = {dense_indices[0][i]: float(dense_distances[0][i]) for i in range(len(dense_indices[0]))}
        
        # B. Sparse Query (BM25)
        bm25_scores_raw = self.bm25.get_scores(query.lower().split())
        max_bm25 = max(bm25_scores_raw) if max(bm25_scores_raw) > 0 else 1.0
        sparse_scores = {i: float(bm25_scores_raw[i] / max_bm25) for i in range(len(bm25_scores_raw))}
        
        # C. Weighted Score Fusion (0.6 Dense + 0.4 Sparse theo Paper 01)
        combined_results = []
        for idx in range(len(self.corpus_items)):
            d_score = dense_scores.get(idx, 0.0)
            s_score = sparse_scores.get(idx, 0.0)
            final_score = 0.6 * d_score + 0.4 * s_score
            combined_results.append((self.corpus_items[idx], final_score))
            
        # Sắp xếp giảm dần và lấy Top-K
        combined_results.sort(key=lambda x: x[1], reverse=True)
        return combined_results[:top_k]
NEW ai-service/processors/cross_encoder_reranker.py
Trụ cột 4: Contextual Reranking (MRR = 0.85)

Sử dụng mô hình mã hóa chéo ms-marco-MiniLM-L-12-v2 để chấm điểm tương thích ngữ cảnh theo cặp trực tiếp giữa câu hỏi của khách và nội dung món ăn.

# ai-service/processors/cross_encoder_reranker.py
from sentence_transformers import CrossEncoder
from typing import List, Dict, Any, Tuple
from processors.row_serializer import serialize_menu_row

class ContextualReranker:
    def __init__(self, model_name: str = "cross-encoder/ms-marco-MiniLM-L-12-v2"):
        self.reranker = CrossEncoder(model_name)

    def rerank(self, query: str, candidate_items: List[Dict[str, Any]], top_k: int = 5) -> List[Dict[str, Any]]:
        if not candidate_items:
            return []
            
        # Chuẩn bị cặp (query, passage)
        pairs = [(query, serialize_menu_row(item)) for item in candidate_items]
        
        # Dự đoán điểm liên quan trực tiếp
        scores = self.reranker.predict(pairs)
        
        # Ghép cặp item với điểm số và sắp xếp
        scored_candidates = list(zip(candidate_items, scores))
        scored_candidates.sort(key=lambda x: x[1], reverse=True)
        
        return [item for item, _ in scored_candidates[:top_k]]
MODIFY backend/src/services/ragService.js
Cầu nối Gateway & Thumbs Feedback

Nâng cấp hàm gọi retrieveMenuContext để chuyển quyền tính toán RAG phức tạp sang Python AI-Service khi cần độ chính xác cao, đồng thời hỗ trợ ghi nhận phản hồi Thumbs-down để tự động kích hoạt truy xuất mở rộng.

// backend/src/services/ragService.js (Bổ sung hàm xử lý phản hồi người dùng)
async function handleUserFeedback(sessionId, messageId, feedbackType, lastQuery) {
  // Ghi nhật ký feedback (thumbs up / thumbs down)
  console.log(`[Feedback] Session: ${sessionId}, Type: ${feedbackType}, Query: "${lastQuery}"`);

  if (feedbackType === 'thumbs_down') {
    // Kích hoạt Query Reformulation trên ai-service theo Paper 01 Mục 3.7
    try {
      const response = await fetch(`${process.env.AI_SERVICE_URL || 'http://localhost:8000'}/reformulate`, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ query: lastQuery, sessionId })
      });
      return await response.json();
    } catch (err) {
      console.error('[ragService] Lỗi khi kích hoạt reformulate:', err.message);
    }
  }
  return { status: 'recorded' };
}

5. Lộ Trình Triển Khai 5 Pha — Chuẩn Hóa Chi Tiết Từng Công Việc (AI Tăng Tốc)

Kế Hoạch Thực Chiến 3.5 – 4 Ngày (28 – 32 Giờ Làm Việc) Có AI Hỗ Trợ

Tất cả các đầu việc được chuẩn hóa đồng nhất theo 6 tiêu chí bắt buộc: Tên công việc, Mục đích của hành động, Nội dung chi tiết, Thời gian hoàn thiện (có AI hỗ trợ), Đối tượng tác động / nhắm đến (Target Entity) và Cách đánh giá mục tiêu đã xong.

⚡ Tổng thời gian: 3.5 – 4 ngày
schema

Sơ Đồ Luồng Tương Tác Đa Tầng (Architecture Swimlane Pipeline Map)

Mô hình hóa quy trình tuần tự qua 5 Pha, 5 Cổng Nghiệm Thu Cứng (Gates) & Vòng lặp phản hồi ngược thời gian thực

Swimlane Pipeline Map Closed-Loop Feedback
swap_calls

Bảng Ma Trận Chuyển Giao Dữ Liệu & Điều Kiện Nghiệm Thu Giữa 5 Pha

Phase Handover Matrix • Quy định chuẩn giao tiếp dữ liệu đầu vào - đầu ra và cổng nghiệm thu cứng (Gates)

Handover Matrix 5 Cổng Nghiệm Thu
Giai Đoạn Đầu Vào Nhận Được (Inputs) Module Xử Lý Trọng Tâm Sản Phẩm Bàn Giao (Outputs) Cổng Nghiệm Thu (Gate Criteria) Tương Tác Phản Hồi
P1 Pha 1 (0.5d) Bảng CSDL menu_items, chính sách nhà hàng hiện hữu. row_serializer.py + Migration pgvector 100% bản ghi được điền chuỗi row_serialized + cột vector 768d. 🛡️ Gate 1: Schema hợp lệ, 0 bản ghi lỗi tuần tự hóa. Khởi tạo tuyến tính (Tầng dữ liệu gốc).
P2 Pha 2 (1.0d) Corpus row_serialized từ Pha 1 + Câu truy vấn người dùng. FAISS HNSW + BM25 Okapi + Score Fusion ($0.6/0.4$) Danh sách Top 20 ứng viên có điểm số lai cao nhất, bàn giao cho Pha 3. 🛡️ Gate 2: Latency truy vấn < 20ms, Recall@5 ≥ 85%. ⚡ Nhận tín hiệu: Nhận truy vấn viết lại từ Pha 4 để truy xuất lại khi khách 👎.
P3 Pha 3 (0.75d) Top 20 ứng viên từ Pha 2 + Metadata thực khách (dị ứng, ăn kiêng). SpaCy F&B NER (Pre-filter) + Cross-Encoder ms-marco-MiniLM Top 5 món chính xác tuyệt đối nhúng vào SSE Stream trả về cho người dùng. 🛡️ Gate 3: MRR ≥ 0.82, 0% vi phạm dị ứng / kiêng cữ. Bàn giao 5 món sang Giao diện Chatbot ở Pha 4.
P4 Pha 4 (0.75d) Món ăn gợi ý của Pha 3 + Nút tương tác Thumbs Up / Down từ thực khách. Query Reformulator + Feedback Telemetry Controller Ghi log telemetry vào Redis, tự sinh câu truy vấn phủ định món cũ. 🛡️ Gate 4: Bấm 👎 trả món mới < 1.2s, bộ nhớ nhớ đủ 10 lượt. 🔄 Phát tín hiệu: Bắn truy vấn ngược về Bước 2.2 (Pha 2) tức thì!
P5 Pha 5 (0.5d) Toàn bộ pipeline RAG tích hợp hoàn chỉnh (Pha 1 đến Pha 4). LLM-as-a-Judge (100 Golden Tests) + Docker Compose + Cân bằng A/B Cụm 3 container microservices chạy Production ổn định, tài liệu API. 🏆 Gate 5: Production Ready, Precision@5 ≥ 90.0%, zero downtime. ✅ Đích đến hoàn tất toàn bộ lộ trình.
Quy Trình Nối Tiếp Có Điều Kiện: Mỗi pha chỉ được kích hoạt khi vượt qua Gate nghiệm thu cứng của pha trước. Không đốt cháy giai đoạn.
Vòng Lặp Phản Hồi Khép Kín: Pha 4 tương tác ngược trực tiếp về Pha 2 (truy xuất lại khi khách từ chối món trong < 1.2s).
Đích Đến Thẩm Định Hoàn Chỉnh: Pha 5 nghiệm thu toàn bộ hệ thống bằng LLM Judge trước khi bật traffic A/B Production.
PHA 1 (0.5 NGÀY) Schema & Serializer ⚡ AI Giảm 70% DB DDL 1.1 Schema Migration pgvector + HNSW Index PYTHON 1.2 Row Serializer Tuần tự hóa cấp hàng SCRIPT 1.3 Bulk Ingestion Điền cột row_serialized 🛡️ CỔNG NGHIỆM THU GATE 1 100% món có row_serialized hợp lệ Điều kiện mở khóa Pha 2 ĐẠT GATE 1 ➔ KÍCH HOẠT PHA 2 PHA 2 (1.0 NGÀY) Lõi Hybrid Retrieval ⚡ AI Giảm 65% INDEX 2.1 Môi Trường & Corpus FAISS HNSW + BM25 Okapi LÕI LAI 2.2 HybridRetriever Score Fusion: 0.6 + 0.4 FASTAPI 2.3 API Endpoint POST /rag/retrieve 🛡️ CỔNG NGHIỆM THU GATE 2 Latency < 20ms & Bắt trúng 98% Bàn giao Top 20 ứng viên cho Pha 3 ĐẠT GATE 2 ➔ KÍCH HOẠT PHA 3 PHA 3 (0.75 NGÀY) Filter & Reranking ⚡ AI Giảm 60% FILTER 3.1 SpaCy F&B NER Lọc cứng dị ứng & giá tiền RERANK 3.2 Cross-Encoder ms-marco: Top 20 ➔ 5 GATEWAY 3.3 Tích Hợp Pipeline Grounded Prompting SSE 🛡️ CỔNG NGHIỆM THU GATE 3 MRR ≥ 0.82 & 0% vi phạm dị ứng Top 5 món an toàn tuyệt đối ra bàn ĐẠT GATE 3 ➔ KÍCH HOẠT PHA 4 PHA 4 (0.75 NGÀY) Feedback & Memory ⚡ AI Giảm 65% REWRITE 4.1 Reformulator Viết lại câu hỏi + phủ định TELEMETRY 4.2 Feedback API POST /rag/feedback Redis CLIENT UI 4.3 Nút Thumbs 👎/👍 Khách bấm 👎 đổi món 🛡️ CỔNG NGHIỆM THU GATE 4 Khách bấm 👎 đổi món < 1.2s Vòng lặp tự thích ứng hoạt động trơn tru ĐẠT GATE 4 ➔ KÍCH HOẠT PHA 5 🔄 VÒNG LẶP PHẢN HỒI (< 1.2s) PHA 5 (0.5 NGÀY) Thẩm Định & Production ⚡ AI Giảm 70% LLM JUDGE 5.1 Benchmark Test 100 bộ câu hỏi chuẩn DOCKER 5.2 Microservices & A/B 3 services + A/B 50/50 RELEASE 5.3 Production Live Vận hành không gián đoạn 🏆 CỔNG GATE 5 (PRODUCTION READY) Precision@5 ≥ 90% • Zero Downtime ✅ Nghiệm thu toàn diện hệ thống Đường màu xanh lá (nét đứt): Tiến trình tuần tự qua 5 Gate nghiệm thu cứng Đường màu tím neon (uốn cong): Vòng lặp phản hồi đóng từ Pha 4 bắn ngược về Lõi Pha 2 (< 1.2s)
P1

Pha 1: Chuẩn Hóa Schema CSDL & Bộ Tuần Tự Hóa Hàng (Row-Level Serializer)

Thời gian: 0.5 ngày (~4 giờ) • Trọng tâm: Bền vững dữ liệu & Schema quan hệ
DB + Serializer
Bước 1.1: Migration Schema Database (Supabase PostgreSQL + pgvector)
DATABASE
flag Mục đích của hành động:

Chuẩn bị nền tảng lưu trữ bền vững cho biểu diễn vector và văn bản tuần tự hóa, kích hoạt khả năng tìm kiếm vector lân cận ngay trong CSDL quan hệ chính mà không làm xáo trộn cấu trúc dữ liệu hiện hành.

description Nội dung công việc (Chi tiết):

Tạo script migration database/migrations/20260912_add_rag_vector_columns.sql: Kích hoạt extension pgvector, bổ sung cột embedding vector(768), các trường row_serialized TEXT, dietary_tags TEXT[], và khởi tạo chỉ mục HNSW CREATE INDEX idx_menu_hnsw ON menu_items USING hnsw (embedding vector_cosine_ops).

schedule Thời gian hoàn thiện:
1.5 giờ (Thủ công: ~5.0 giờ)
⚡ AI hỗ trợ: Giảm 70% nhờ AI tự động sinh mã DDL SQL, cấu hình tối ưu tham số HNSW và script rollback an toàn.
adjust Đối tượng tác động / nhắm đến (Target Entity):
Thực thể hệ thống: Bảng CSDL quan hệ menu_items, restaurant_policies, extension pgvector và chỉ mục idx_menu_hnsw.
Phạm vi ảnh hưởng: Cấu trúc schema PostgreSQL, đảm bảo các bản ghi món ăn có thể lưu trữ vector nhúng 768 chiều và chuỗi tuần tự hóa.
verified Cách đánh giá mục tiêu đã xong:

Chạy supabase db push thành công không cảnh báo; truy vấn SELECT * FROM menu_items LIMIT 1 trả về đầy đủ các trường mới; chỉ mục HNSW hiển thị trạng thái hợp lệ trong Postgres Catalog.

Bước 1.2: Cài đặt Module Tuần Tự Hóa Cấp Hàng (Row Serializer Engine)
NEW FILE
flag Mục đích của hành động:

Chuyển đổi dữ liệu bảng nhiều cột (tên, danh mục, giá, dị ứng, calo, độ cay) thành chuỗi văn bản có cấu trúc chuẩn theo Paper 01 Mục 3.1.2, giúp mô hình Embedding và BM25 hiểu trọn vẹn ngữ nghĩa của từng thuộc tính trong món ăn.

description Nội dung công việc (Chi tiết):

Tạo module ai-service/processors/row_serializer.py: Cung cấp 2 hàm chính serialize_menu_row(item: dict) -> str và serialize_restaurant_policy(policy: dict) -> str. Format chuẩn: Giữ toàn bộ thuộc tính quan hệ (Tên, Danh mục, Giá tiền, Calo, Cảnh báo dị ứng, Thành phần, Cấp độ cay) thành văn bản chuẩn cấu trúc theo Paper 01 Mục 3.1.2.

schedule Thời gian hoàn thiện:
1.5 giờ (Thủ công: ~4.5 giờ)
⚡ AI hỗ trợ: Giảm 65% nhờ AI sinh toàn bộ Pydantic models, xử lý các trường hợp null và tự động viết 12 unit test cases.
adjust Đối tượng tác động / nhắm đến (Target Entity):
Thực thể hệ thống: Định dạng dữ liệu bản ghi món ăn, Pydantic Schema model và chuỗi văn bản tuần tự hóa row_serialized.
Phạm vi ảnh hưởng: Quy chuẩn hóa toàn bộ thuộc tính quan hệ thành đầu vào đồng nhất cho cả 2 bộ chỉ mục BM25 và Vector Embedding.
verified Cách đánh giá mục tiêu đã xong:

Chạy pytest tests/test_row_serializer.py -v vượt qua 100% test cases; chuỗi serialized chứa đầy đủ tên cột và giá trị tương ứng mà không bị null gãy.

Bước 1.3: Script Đồng Bộ & Tuần Tự Hóa Hàng Loạt (Bulk Ingestion Script)
NEW SCRIPT
flag Mục đích của hành động:

Tự động hóa quá trình nạp và chuyển đổi toàn bộ kho dữ liệu thực đơn hiện có sang định dạng văn bản tuần tự hóa, đồng thời điền dữ liệu vào cột row_serialized phục vụ cho việc tạo chỉ mục kép.

description Nội dung công việc (Chi tiết):

Tạo script ai-service/scripts/seed_structured_corpus.py: Quét toàn bộ bảng menu_items và restaurant_policies từ Supabase, tuần tự hóa từng hàng và lưu ngược vào cột row_serialized theo lô (batch of 50).

schedule Thời gian hoàn thiện:
1.0 giờ (Thủ công: ~3.0 giờ)
⚡ AI hỗ trợ: Giảm 65% nhờ AI sinh boilerplate batch query, retry handling khi gặp network glitch và thanh tiến trình tqdm.
adjust Đối tượng tác động / nhắm đến (Target Entity):
Thực thể hệ thống: Toàn bộ các dòng dữ liệu hiện hành trong bảng menu_items và restaurant_policies trên Supabase Database.
Phạm vi ảnh hưởng: Hoàn thiện 100% cột dữ liệu văn bản tuần tự hóa, sẵn sàng cho việc tính toán vector nhúng và xây dựng chỉ mục BM25.
verified Cách đánh giá mục tiêu đã xong:

Thực thi script hoàn tất; kiểm tra SELECT COUNT(*) FROM menu_items WHERE row_serialized IS NULL cho kết quả bằng đúng 0.

verified Cổng Nghiệm Thu Pha 1 (Gate 1): 100% món ăn trong bảng `menu_items` có chuỗi `row_serialized` hợp lệ, không mất mát dữ liệu thuộc tính hàng-cột. Tiêu chí cứng
P2

Pha 2: Lõi Hybrid Retrieval (FAISS HNSW Index + BM25 Okapi + Score Fusion)

Thời gian: 1.0 ngày (~8 giờ) • Trọng tâm: Tốc độ truy vấn & Độ bao phủ ngữ nghĩa
FAISS + BM25
Bước 2.1: Cấu hình Môi Trường, FAISS HNSW & BM25 Corpus
DEPENDENCIES
flag Mục đích của hành động:

Xây dựng kho chỉ mục kép (Dual-Index) lưu trữ trong RAM của microservice Python, bao gồm vector index (FAISS HNSW) cho ngữ nghĩa và inverted index (BM25 Okapi) cho từ khóa chính xác, đảm bảo độ trễ truy xuất < 10ms.

description Nội dung công việc (Chi tiết):

Thêm vào ai-service/requirements.txt: faiss-cpu>=1.8.0, rank-bm25>=0.2.2, sentence-transformers>=3.0.0. Khởi tạo FAISS HNSW index với tham số tối ưu từ Paper 01: $M=32$, $efConstruction=200$, $efSearch=50$, token hóa tiếng Việt cho kho từ khóa BM25.

schedule Thời gian hoàn thiện:
2.5 giờ (Thủ công: ~7.0 giờ)
⚡ AI hỗ trợ: Giảm 65% nhờ AI tự động tạo Dockerfile đa tầng (multi-stage), cấu hình thư viện C++ FAISS tối ưu cho CPU.
adjust Đối tượng tác động / nhắm đến (Target Entity):
Thực thể hệ thống: Bộ nhớ RAM và file hệ thống của microservice ai-service, đối tượng chỉ mục faiss.IndexHNSWFlat và mô hình rank_bm25.BM25Okapi.
Phạm vi ảnh hưởng: Khởi tạo cấu trúc dữ liệu tìm kiếm nhúng và từ khóa phục vụ cho toàn bộ các bước truy xuất tiếp theo.
verified Cách đánh giá mục tiêu đã xong:

Build thành công container AI-Service; load thử 1,000 vector mẫu vào FAISS và truy vấn nearest neighbors trong thời gian < 5ms.

Bước 2.2: Xây dựng Lớp HybridMenuRetriever & Min-Max Score Normalization
NEW FILE
flag Mục đích của hành động:

Hợp nhất điểm số giữa hai không gian tìm kiếm khác biệt (khoảng cách vector Cosine và điểm tần suất từ khóa BM25) theo công thức chuẩn hóa Min-Max của Paper 01 Mục 3.4, giúp loại bỏ thiên vị điểm số và tìm ra top 20 ứng viên cân bằng nhất.

description Nội dung công việc (Chi tiết):

Tạo file ai-service/processors/hybrid_retriever.py: Tải mô hình embedding BAAI/bge-m3 / all-mpnet-base-v2. Áp dụng công thức chuẩn hóa điểm số Min-Max cho cả Dense và BM25 về thang $[0, 1]$, sau đó kết hợp theo tỷ lệ tối ưu của Paper 01: $Score = 0.6 \times Dense + 0.4 \times BM25$.

schedule Thời gian hoàn thiện:
3.0 giờ (Thủ công: ~8.0 giờ)
⚡ AI hỗ trợ: Giảm 62% nhờ AI sinh toàn bộ code thuật toán dung hợp điểm số (Reciprocal Rank Fusion / Weighted Sum) và xử lý edge cases.
adjust Đối tượng tác động / nhắm đến (Target Entity):
Thực thể hệ thống: Pipeline tính điểm truy xuất lai (HybridMenuRetriever), thuật toán Min-Max Score Normalization, danh sách ứng viên Top 20 CandidateRow.
Phạm vi ảnh hưởng: Thứ hạng và điểm số tương thích của các món ăn trước khi chuyển sang tầng reranking.
verified Cách đánh giá mục tiêu đã xong:

Truy vấn test với cả từ khóa chính xác (vd: "Phở Bò Tái Lăn") và từ khóa ngữ nghĩa (vd: "món giải ngấy thanh mát") đều trả về đúng ứng viên trong Top 10 với điểm combined > 0.75.

Bước 2.3: Xây dựng Endpoint Truy Xuất Độc Lập (FastAPI /rag/retrieve)
API ENDPOINT
flag Mục đích của hành động:

Đóng gói toàn bộ logic truy xuất thành một API RESTful độc lập, có tài liệu OpenAPI Swagger rõ ràng, cho phép kiểm thử độc lập và tách rời tầng truy xuất khỏi tầng sinh ngôn ngữ LLM.

description Nội dung công việc (Chi tiết):

Thêm endpoint POST /rag/retrieve trong ai-service/main.py nhận query và tham số filter, trả về Top 20 ứng viên kèm chi tiết breakdown điểm số (Dense Score, BM25 Score, Combined Score) để phục vụ debug và liên kết Gateway.

schedule Thời gian hoàn thiện:
2.5 giờ (Thủ công: ~6.0 giờ)
⚡ AI hỗ trợ: Giảm 60% nhờ AI tự động tạo FastAPI routers, Pydantic request/response validation schema và tài liệu OpenAPI Swagger.
adjust Đối tượng tác động / nhắm đến (Target Entity):
Thực thể hệ thống: Giao thức API REST (POST /rag/retrieve), hợp đồng dữ liệu request/response RetrieveRequest/RetrieveResponse.
Phạm vi ảnh hưởng: Kênh giao tiếp mạng nội bộ (Local Docker Network) giữa Node.js Gateway và Python AI-Service.
verified Cách đánh giá mục tiêu đã xong:

Test bằng cURL hoặc Swagger UI (/docs) trả về mã HTTP 200 trong < 20ms; JSON trả về chứa đầy đủ danh sách 20 món và điểm số rõ ràng.

verified Cổng Nghiệm Thu Pha 2 (Gate 2): Thời gian truy vấn song song Dense + BM25 < 20ms; tỷ lệ bắt trúng món khóa chính xác đạt 98%. Tiêu chí hiệu năng
P3

Pha 3: Metadata Pre-Filtering (SpaCy NER) & Cross-Encoder Contextual Reranking

Thời gian: 0.75 ngày (~6 giờ) • Trọng tâm: Tinh lọc vi phạm & Tái xếp hạng chính xác
NER + CrossEncoder
Bước 3.1: Bộ Trích Xuất Thực Thể Ẩm Thực Chuyên Biệt (SpaCy F&B NER)
NEW FILE
flag Mục đích của hành động:

Tách bạch các thực thể đặc thù ngành nhà hàng (thành phần gây dị ứng, giới hạn ngân sách, chế độ ăn chay/kiêng, phong cách món) từ câu hỏi người dùng để phục vụ lọc cứng (Metadata Hard-Filtering) trước khi xếp hạng, đảm bảo an toàn tuyệt đối cho thực khách.

description Nội dung công việc (Chi tiết):

Tạo module ai-service/processors/metadata_filter.py: Xây dựng CulinaryEntityExtractor kết hợp MetadataFilter định nghĩa danh mục thực thể F&B: ALLERGEN (tôm, cua, đậu phộng, trứng, sữa...), DIET_RESTRICTION (chay, vegan, không gluten...), SPICE_LEVEL (không cay, cay nhẹ...), BUDGET (số tiền tối đa). Tự động nới rộng độ sâu truy xuất ứng viên và loại trừ 100% món vi phạm trước khi xếp hạng.

schedule Thời gian hoàn thiện:
2.0 giờ (Thủ công: ~6.0 giờ)
⚡ AI hỗ trợ: Giảm 67% nhờ AI tổng hợp từ điển ẩm thực tiếng Việt phong phú (> 300 từ khóa dị ứng/chế độ ăn) và regex patterns.
adjust Đối tượng tác động / nhắm đến (Target Entity):
Thực thể hệ thống: Câu truy vấn đầu vào của người dùng (raw_user_query), từ điển thực thể ẩm thực tùy chỉnh, và bộ lọc thuộc tính metadata (dietary_tags, price_range, spicy_level).
Phạm vi ảnh hưởng: Loại bỏ triệt để 100% các món ăn không an toàn hoặc không hợp tiêu chí khách hàng trước khi tính điểm tương đồng.
verified Cách đánh giá mục tiêu đã xong:

Bộ 50 câu hỏi thử nghiệm chứa dị ứng (vd: "không ăn được hải sản", "dị ứng lạc") lọc chính xác 100% món chứa thành phần tương ứng khỏi danh sách gợi ý.

Bước 3.2: Tầng Tái Xếp Hạng Ngữ Cảnh Bằng Cross-Encoder
NEW FILE
flag Mục đích của hành động:

So sánh sâu ngữ cảnh giữa toàn bộ câu hỏi và thông tin chi tiết từng món ăn bằng mô hình Cross-Encoder để loại bỏ các ứng viên sai lệch ngữ nghĩa mà tầng truy xuất thô mang về, chọn ra Top 5 món chuẩn xác nhất theo đúng Paper 01 Mục 3.5.

description Nội dung công việc (Chi tiết):

Tạo module ai-service/processors/cross_encoder_reranker.py: Tải mô hình cross-encoder/ms-marco-MiniLM-L-12-v2. Hàm rerank(query, candidates, top_k=5) chấm điểm tương quan trực tiếp giữa câu hỏi và đoạn tóm tắt hàng món ăn để chọn lọc ra 5 món chính xác nhất. Tối ưu suy luận chạy trong < 25ms.

schedule Thời gian hoàn thiện:
2.0 giờ (Thủ công: ~5.5 giờ)
⚡ AI hỗ trợ: Giảm 64% nhờ AI tối ưu hóa batch inference, cấu hình luồng PyTorch đa nhân và viết script benchmark latency.
adjust Đối tượng tác động / nhắm đến (Target Entity):
Thực thể hệ thống: Danh sách Top 20 ứng viên thô (candidate_items), mô hình ngôn ngữ cross-encoder/ms-marco-MiniLM-L-12-v2, và trọng số xếp hạng ngữ cảnh cuối cùng.
Phạm vi ảnh hưởng: Tinh lọc danh sách ứng viên, nâng chỉ số MRR@10 từ 0.61 lên trên 0.82.
verified Cách đánh giá mục tiêu đã xong:

Chỉ số MRR trên tập dữ liệu kiểm thử nội bộ đạt ≥ 0.82; thời gian suy luận cho 20 ứng viên đạt < 25ms trên máy chủ CPU tiêu chuẩn.

Bước 3.3: Tích Hợp Vào Aria Conversation Pipeline & Grounded Prompting
MODIFY
flag Mục đích của hành động:

Ràng buộc mô hình LLM (Gemini 1.5 Flash) chỉ được phép trả lời dựa trên thông tin món ăn thực tế được trích xuất (Grounded Generation), triệt tiêu hoàn toàn hiện tượng bịa đặt giá cả hoặc món không có trong thực đơn.

description Nội dung công việc (Chi tiết):

Cập nhật ai-service/pipelines/aria_pipeline.py: Kết nối chuỗi xử lý hoàn chỉnh: User Query $\rightarrow$ SpaCy Pre-filter $\rightarrow$ Hybrid Retrieval Top 20 $\rightarrow$ Cross-Encoder Top 5 $\rightarrow$ Grounded Prompting Template $\rightarrow$ Groq LLM SSE Stream.

schedule Thời gian hoàn thiện:
2.0 giờ (Thủ công: ~5.0 giờ)
⚡ AI hỗ trợ: Giảm 60% nhờ AI tự động tạo pipeline async/await, quản lý context buffer memory 10 lượt và prompt template hoàn chỉnh.
adjust Đối tượng tác động / nhắm đến (Target Entity):
Thực thể hệ thống: Prompt ngữ cảnh (system_prompt & context_block), luồng hội thoại của trợ lý ảo Aria (aria_pipeline.py) và câu trả lời hoàn thiện gửi tới thực khách.
Phạm vi ảnh hưởng: Đảm bảo phản hồi của chatbot bám sát 100% thực đơn thực tế của nhà hàng.
verified Cách đánh giá mục tiêu đã xong:

Kiểm tra end-to-end qua SSE Stream: Câu trả lời đầu tiên xuất hiện sau < 400ms (TTFT); phản hồi chứa đúng thông tin thực đơn kèm trích dẫn giá và calo.

verified Cổng Nghiệm Thu Pha 3 (Gate 3): MRR đạt ≥ 0.82; 0% trường hợp gợi ý nhầm món chứa dị ứng trong bộ 100 test case. Tiêu chí an toàn
P4

Pha 4: Bộ Nhớ Hội Thoại 10 Lượt, UI Thumbs Feedback & Tinh Chỉnh Truy Vấn Động

Thời gian: 0.75 ngày (~6 giờ) • Trọng tâm: Tương tác người dùng & Tự thích ứng thời gian thực
Feedback Loop
Bước 4.1: Xây dựng Module Query Reformulator (Viết Lại Truy Vấn)
NEW FILE
flag Mục đích của hành động:

Tự động bổ sung ngữ cảnh từ lịch sử hội thoại nhiều lượt vào các câu hỏi ngắn hoặc câu hỏi rút gọn của người dùng (ví dụ: 'Món này có cay không?', 'Đổi sang món dưới 100k'), biến chúng thành câu truy vấn đầy đủ nghĩa để RAG tìm kiếm chính xác.

description Nội dung công việc (Chi tiết):

Tạo module ai-service/processors/query_reformulator.py: Cung cấp 2 cơ chế thích ứng của Paper 01: (1) Ambiguous Query Rewriting: Làm rõ câu hỏi mơ hồ ("uống gì ngon?" $\rightarrow$ "đồ uống thanh nhiệt, nước ép trái cây tươi, trà đào cam sả"); (2) Negative Feedback Expansion: Khi khách bấm 👎, trích xuất lịch sử 10 lượt hội thoại gần nhất và diễn đạt lại truy vấn với các thuộc tính thay thế để truy xuất lại danh sách món mới.

schedule Thời gian hoàn thiện:
2.0 giờ (Thủ công: ~6.0 giờ)
⚡ AI hỗ trợ: Giảm 67% nhờ AI thiết kế prompt kỹ thuật reformulation tối ưu vài shot (few-shot prompting) và bộ quy tắc fallback.
adjust Đối tượng tác động / nhắm đến (Target Entity):
Thực thể hệ thống: Lịch sử hội thoại nhiều lượt (chat_history), câu hỏi rút gọn của thực khách, và câu truy vấn độc lập được tái cấu trúc (standalone_search_query).
Phạm vi ảnh hưởng: Tầng tiền xử lý truy vấn trước khi gọi sang module Hybrid Retriever, giảm tỷ lệ truy xuất sai lệch do thiếu ngữ cảnh.
verified Cách đánh giá mục tiêu đã xong:

Test thử với 20 câu hỏi mơ hồ: 100% câu hỏi được viết lại rõ ràng, bổ sung danh từ món cụ thể; khi kích hoạt Negative Feedback, danh sách món trả về mới khác ít nhất 80% so với danh sách cũ bị từ chối.

Bước 4.2: Backend Controller & Endpoint Ghi Nhận Phản Hồi Telemetry
MODIFY
flag Mục đích của hành động:

Thu thập và lưu vết dữ liệu phản hồi đánh giá của người dùng cùng bối cảnh truy xuất (câu hỏi, ngữ cảnh món ăn trả về, điểm đánh giá), tạo nguồn dữ liệu vàng cho việc tinh chỉnh trọng số $\alpha$ và đánh giá chất lượng hệ thống liên tục.

description Nội dung công việc (Chi tiết):

Tạo controller backend/src/controllers/feedbackController.js và endpoint POST /api/chat/feedback: Lưu vết phản hồi (thumbs_up / thumbs_down) vào Redis và Supabase bảng chat_feedbacks kèm query, context_ids và thời gian phản hồi.

schedule Thời gian hoàn thiện:
2.0 giờ (Thủ công: ~5.0 giờ)
⚡ AI hỗ trợ: Giảm 60% nhờ AI sinh mã controller Express.js, middleware xác thực JWT và logic ghi nhận metric bất đồng bộ vào Redis.
adjust Đối tượng tác động / nhắm đến (Target Entity):
Thực thể hệ thống: Bảng cơ sở dữ liệu chat_feedbacks, API endpoint POST /api/chat/feedback, và luồng ghi nhận metric trong Redis.
Phạm vi ảnh hưởng: Kho dữ liệu telemetry phục vụ giám sát vận hành và huấn luyện cải tiến mô hình trong tương lai.
verified Cách đánh giá mục tiêu đã xong:

Gọi POST feedback qua Postman; bản ghi xuất hiện ngay trong Redis key session:feedback:{id} và được sync vào PostgreSQL trong < 50ms.

Bước 4.3: Giao Diện Thumbs Up / Down Trên Frontend AriaChatWidget
UI COMPONENT
flag Mục đích của hành động:

Cung cấp giao diện tương tác trực quan, thân thiện cho phép thực khách dễ dàng bày tỏ sự hài lòng hoặc không hài lòng đối với từng câu trả lời gợi ý món ăn của trợ lý ảo, kích hoạt quy trình tìm món thay thế ngay lập tức.

description Nội dung công việc (Chi tiết):

Cập nhật frontend/src/components/AriaChatWidget.jsx: Thêm cặp nút tương tác 👍 và 👎 dưới mỗi câu trả lời của trợ lý Aria. Khi khách nhấn 👎, hiển thị thông báo nhẹ nhàng: "Aria đang tìm món khác phù hợp hơn với bạn..." và kích hoạt event tự động tìm kiếm lại mà khách không cần nhập lại câu hỏi.

schedule Thời gian hoàn thiện:
2.0 giờ (Thủ công: ~5.0 giờ)
⚡ AI hỗ trợ: Giảm 60% nhờ AI viết component React, xử lý micro-animation với Tailwind và tối ưu trải nghiệm chạm trên màn hình di động.
adjust Đối tượng tác động / nhắm đến (Target Entity):
Thực thể hệ thống: Giao diện người dùng widget trò chuyện (AriaChatWidget.jsx), thanh nút đánh giá (Thumbs Up / Thumbs Down button strip), và trạng thái tương tác của thực khách trên màn hình di động.
Phạm vi ảnh hưởng: Trải nghiệm người dùng đầu cuối (UX/UI), giúp thực khách có quyền can thiệp và nhận gợi ý phù hợp hơn mà không cần gõ lại tin nhắn.
verified Cách đánh giá mục tiêu đã xong:

Kiểm thử trên trình duyệt di động: Nhấn 👍 đổi màu xanh; nhấn 👎 kích hoạt spinner và nhận danh sách món mới thay thế sau < 1.2s.

verified Cổng Nghiệm Thu Pha 4 (Gate 4): Vòng lặp phản hồi hoạt động trơn tru: Bấm 👎 kích hoạt truy xuất mở rộng và đổi món đề xuất trong < 1.2s. Tiêu chí trải nghiệm
P5

Pha 5: Kiểm Thử Tự Động Với LLM-as-a-Judge & Đóng Gói Triển Khai Production

Thời gian: 0.5 ngày (~4 giờ) • Trọng tâm: Đánh giá khoa học & Vận hành ổn định
AI Benchmark & Deploy
Bước 5.1: Thực Thi Bộ Test Thẩm Định Tự Động Với LLM-as-a-Judge
NEW SCRIPT
flag Mục đích của hành động:

Tự động hóa việc chấm điểm và thẩm định chất lượng câu trả lời RAG dựa trên 3 tiêu chí khoa học (Độ tin cậy ngữ cảnh - Faithfulness, Mức độ phù hợp câu trả lời - Answer Relevance, Mức độ chính xác thông tin bảng - Table Precision) theo Mục 4 Paper 01, loại bỏ đánh giá cảm tính chủ quan.

description Nội dung công việc (Chi tiết):

Tạo script thẩm định ai-service/evaluation/run_eval.py: Sử dụng bộ 100 câu hỏi test đại diện cho 5 nhóm khách hàng (Gia đình, Dân văn phòng, Người kiêng khem, Khách nhậu, Cặp đôi). Đánh giá tự động qua mô hình thẩm phán LLM-as-a-Judge trích xuất JSON: Faithfulness, Relevance, Completeness.

schedule Thời gian hoàn thiện:
2.0 giờ (Thủ công: ~8.0 giờ)
⚡ AI hỗ trợ: Giảm 75% nhờ AI tự động tạo 100 kịch bản test case phong phú và xử lý concurrency chạy 100 eval song song trong 45 giây.
adjust Đối tượng tác động / nhắm đến (Target Entity):
Thực thể hệ thống: 100 kịch bản câu hỏi kiểm thử đại diện (golden_benchmark_dataset), script đánh giá tự động run_eval.py, và file báo cáo chất lượng RAG report_eval.json.
Phạm vi ảnh hưởng: Toàn bộ chất lượng đầu ra của hệ thống AI, kiểm soát rủi ro dị ứng và sai sót giá tiền trước khi đưa vào thực tế.
verified Cách đánh giá mục tiêu đã xong:

Báo cáo report_eval.json được sinh ra tự động; không có bất kỳ câu trả lời nào vi phạm dị ứng hoặc sai giá tiền.

Bước 5.2: Cấu Hình Docker Compose Microservices & Phân Luồng A/B Testing
DEPLOYMENT
flag Mục đích của hành động:

Đóng gói toàn bộ kiến trúc thành các container đồng bộ, thiết lập mạng nội bộ bảo mật cao và kích hoạt cơ chế phân luồng A/B Testing để so sánh trực tiếp hiệu quả giữa thuật toán cũ và hệ thống Advancing RAG mới trên môi trường thực tế.

description Nội dung công việc (Chi tiết):

Cập nhật docker-compose.yml: Đóng gói service ai-service chạy cùng Node.js Gateway và Redis. Cấu hình phân luồng A/B testing 50/50 tại Gateway để theo dõi tỷ lệ chuyển đổi thực tế (tỷ lệ nhấn "Thêm vào giỏ hàng") của thực khách.

schedule Thời gian hoàn thiện:
2.0 giờ (Thủ công: ~5.0 giờ)
⚡ AI hỗ trợ: Giảm 60% nhờ AI tối ưu Dockerfile multi-stage build giảm dung lượng từ 3.2GB xuống 850MB và viết cấu hình Nginx/Gateway routing.
adjust Đối tượng tác động / nhắm đến (Target Entity):
Thực thể hệ thống: Tệp cấu hình container docker-compose.yml, 3 container dịch vụ (backend, ai-service, redis), và cơ chế phân phối tải (Traffic Router 50/50).
Phạm vi ảnh hưởng: Hạ tầng môi trường chạy thực tế (Production Infrastructure) và tỷ lệ chuyển đổi đơn hàng của thực khách.
verified Cách đánh giá mục tiêu đã xong:

Lệnh docker compose up -d khởi chạy cả 3 container khỏe mạnh (healthy); hệ thống phân phối request trơn tru không lỗi kết nối.

verified Cổng Nghiệm Thu Pha 5 (Gate 5): Hệ thống đóng gói hoàn chỉnh, vận hành song song ổn định và sẵn sàng phục vụ thực khách thực tế. Nghiệm thu cuối cùng

6. Ma Trận Đánh Đổi Kiến Trúc & Quyết Định Kỹ Thuật (Architecture Tradeoffs)

Cân Bằng Giữa Độ Phức Tạp Kỹ Thuật, Chi Phí Vận Hành & Độ Chính Xác

Mọi quyết định kiến trúc trong hệ thống RAG doanh nghiệp đều là một sự đánh đổi có tính toán (Tradeoff). Không có giải pháp hoàn hảo tuyệt đối, chỉ có giải pháp phù hợp nhất với ràng buộc tài nguyên, ngân sách và yêu cầu nghiệp vụ của SmartRestaurant.

shield_with_heart

Bảng Quản Trị Rủi Ro Kỹ Thuật Khi Vận Hành Kiến Trúc Advancing RAG (Paper 01)

Nhận diện trước 4 thách thức kỹ thuật nội tại của kiến trúc Advancing RAG và phương án hóa giải chuẩn Paper 01

Dành Riêng Cho Advancing RAG
Rủi Ro Kỹ Thuật Của Advancing RAG Mức Độ Hậu Quả Tiềm Ẩn Giải Pháp Giảm Thiểu (Paper 01 Guidelines)
1. Độ trễ gia tăng do mô hình Cross-Encoder Trung bình Thời gian trả lời câu hỏi đầu tiên (TTFT) có thể vượt quá 1.5 giây nếu suy luận Cross-Encoder trên CPU chậm. Sử dụng mô hình lượng tử hóa nhẹ ms-marco-MiniLM-L-12-v2 (hoặc ONNX Runtime). Chỉ tái xếp hạng cho Top 15-20 ứng viên thay vì toàn bộ kho ngữ liệu.
2. Lập chỉ mục tĩnh & Trễ đồng bộ menu Thấp Khi nhà hàng cập nhật món mới hoặc đổi giá, chỉ mục FAISS chưa kịp cập nhật ngay lập tức. Tích hợp Webhook Invalidation từ Supabase: Khi bảng menu_items thay đổi, kích hoạt API cập nhật chỉ mục vi mô gia tăng (Incremental Index Update) vào FAISS.
3. Quá tải bộ nhớ RAM khi mở rộng nhiều chi nhánh Trung bình Lưu nhiều chỉ mục FAISS đồng thời trong RAM microservice có thể làm tràn bộ nhớ (OOM). Áp dụng kiến trúc Chỉ Mục Kép (Dual-Index Optimization - Mục 3.8): Phân vùng index theo restaurant_id; nạp lười (Lazy-load) từ đĩa và giải phóng các menu chi nhánh ít truy cập.
4. Người dùng không chủ động bấm nút Thumbs 👍/👎 Thấp Cơ chế tự điều chỉnh thiếu dữ liệu phản hồi từ thực khách. Bổ sung tín hiệu thụ động ngầm định (Implicit Signals - Mục 6.1): Nếu khách hàng nhấn "Xem chi tiết món", "Thêm vào giỏ hàng" coi như Tích cực (+1); nếu khách yêu cầu lặp lại câu hỏi coi như Tiêu cực (-1).
swap_horiz

Phân Tích Đánh Đổi Kiến Trúc: Hiện Trạng Ban Đầu vs. Advancing RAG vs. Các Phương Án Khác

Mục 3.8 Paper 01 Analysis
Hiện Trạng Cũ Baseline System
Naive Keyword 2-Stage Filter
Nội dung giải pháp:

Hệ thống hiện hành của SmartRestaurant: Dùng câu lệnh SQL WHERE LIKE/ILIKE kết hợp lọc category thô tại Node.js backend, nhồi danh sách món thô vào Prompt LLM để sinh câu trả lời.

Hệ quả & Sự đánh đổi:
Ưu điểm Lợi thế ban đầu

Cực kỳ đơn giản, không cần microservice Python, 0 tốn thêm RAM máy chủ, tận dụng 100% mã nguồn backend Node.js có sẵn.

Cái giá Hạn chế chí mạng

Ảo giác (Hallucination) nặng nề; mù ngữ nghĩa tương đồng ("thanh mát", "món ăn giải ngấy"); dễ bỏ sót món khi sai chính tả; thất bại hoàn toàn với lọc dị ứng khắt khe.

Bắt buộc thay thế vì rủi ro an toàn
Mục Tiêu Đang Chọn Paper 01 Benchmark
Advancing Hybrid RAG Service
Nội dung giải pháp:

Xây dựng microservice riêng bằng FastAPI tích hợp Dual-Index (FAISS HNSW ngữ nghĩa + BM25 Okapi từ khóa) kết hợp Row Serializer, SpaCy NER, Cross-Encoder và Feedback Loop.

Hệ quả & Sự đánh đổi:
Ưu điểm Đột phá vượt bậc

Độ chính xác dữ liệu bảng cao nhất (MRR ≥ 0.82); triệt tiêu 100% rủi ro dị ứng món ăn; tốc độ truy xuất nội bộ < 30ms; 0 đồng phí SaaS; bảo mật nội bộ.

Cái giá Đánh đổi kỹ thuật

Cần duy trì thêm 1 container Python (~800MB RAM); đòi hỏi pipeline tuần tự hóa hàng và webhook cập nhật chỉ mục khi đổi menu.

Lựa chọn tối ưu toàn diện cho SmartRestaurant
Phương Án Khác A All-in-One DB
Pure Supabase pgvector
Nội dung giải pháp:

Lưu trữ vector trực tiếp trong PostgreSQL (extension pgvector), dùng RPC SQL để tính cosine similarity, không dựng Python service hay Cross-Encoder.

Hệ quả & Sự đánh đổi:
Ưu điểm Hạ tầng tinh gọn

Hạ tầng siêu tinh gọn, 0 thêm container, không lo lệch pha dữ liệu giữa DB và Cache bộ nhớ.

Cái giá Hạn chế thuật toán

Thiếu BM25 Okapi nguyên bản để bắt từ khóa chính xác; không có Cross-Encoder reranker; tải tính toán vector ảnh hưởng DB giao dịch chính.

Chỉ hợp: Ứng dụng đọc báo/blog tin tức
Phương Án Khác B External Cloud SaaS
Managed Vector DB (Pinecone/Qdrant)
Nội dung giải pháp:

Ủy thác toàn bộ việc lưu trữ vector và tìm kiếm lân cận cho các dịch vụ đám mây chuyên dụng bên thứ ba (Pinecone Serverless, Qdrant Cloud).

Hệ quả & Sự đánh đổi:
Ưu điểm Tự động mở rộng

Mở rộng quy mô tự động, không tốn RAM máy chủ nhà hàng, có giao diện dashboard giám sát chỉ mục trực quan.

Cái giá Chi phí & Rủi ro

Chi phí định kỳ hàng tháng (\$70-\$200/tháng); trễ mạng internet tăng thêm 80-150ms/truy vấn; dữ liệu món ăn bị gửi ra ngoài hạ tầng nội bộ.

Chưa phù hợp: Tốn kém & trễ mạng cao
verified
SmartRestaurant Chọn Lựa Chọn Nào? Tại Sao Rời Bỏ Hiện Trạng Ban Đầu?

Quyết định kỹ thuật chiến lược được phê chuẩn dựa trên mục tiêu thực tế của nhà hàng

Dự án chính thức loại bỏ Hiện Trạng Ban Đầu (Naive Keyword Filter) và phê chuẩn Phương án Advancing Hybrid RAG (FAISS HNSW + BM25 + Cross-Encoder) theo chuẩn Paper 01. Chúng tôi chấp nhận đánh đổi việc phải duy trì thêm 1 microservice Python và ~800MB RAM để đổi lấy 4 giá trị then chốt không thể thay thế:

filter_alt 1. Triệt tiêu hoàn toàn rủi ro dị ứng & Bịa đặt thực đơn

Hệ thống ban đầu thường xuyên gợi ý sai món khi khách có dị ứng nguy hiểm (ví dụ: dị ứng đậu phộng nhưng vẫn gợi ý món sốt sa tế đậu phộng). Advancing RAG với SpaCy NER và Grounded Generation triệt tiêu 100% rủi ro này.

speed 2. Cam kết tốc độ phản hồi TTFT < 500ms (Không trễ Cloud)

FAISS và Cross-Encoder chạy trong mạng nội bộ (Local Docker Network) chỉ mất < 30ms cho khâu truy xuất, không chịu thêm 80-150ms trễ mạng internet như giải pháp Cloud SaaS (Pinecone/Qdrant).

savings 3. Hoàn toàn 0 đồng chi phí duy trì SaaS định kỳ

FAISS và Rank-BM25 là thư viện mã nguồn mở tự host hoàn toàn miễn phí. Nhà hàng không bị ràng buộc hóa đơn hàng tháng (\$70-\$200/tháng) hay nguy cơ đội chi phí khi lượng khách đặt món tăng vọt.

shield 4. Bảo mật toàn diện dữ liệu thực đơn & công thức món ăn

Toàn bộ dữ liệu menu, thành phần dinh dưỡng và giá vốn của nhà hàng được lưu trữ và lập chỉ mục khép kín trong cụm máy chủ SmartRestaurant, không gửi sang bất kỳ bên thứ 3 nào, bảo vệ bí mật kinh doanh chuỗi nhà hàng.