Ba nguyên tắc chống bịa đặt :

1. Không có nguồn thì không trả lời. Câu trả lời chính sách luôn kèm trích dẫn; không tìm được căn cứ thì trả lời không biết.
2. Độ tin cậy thấp hoặc câu hỏi vượt phạm vi (kỷ luật, khóa tài khoản, tai nạn) → chuyển tổng đài / người thật.
3. Câu hỏi về tiền không đi qua LLM. LLM chỉ hiểu câu hỏi và diễn giải kết quả; con số do engine tính, nên tài xế và hãng luôn đối soát được về cùng một công thức.

Kiến trúc

PWA (React + Vite)  ──►  FastAPI (SSE, trả lời chảy dần)
                              │
                     LangGraph router — phân loại câu hỏi
                              │
    ┌────────────┬────────────┼────────────┬─────────────┐
  RAG          Income        Zone       Memory        HITL
 Qdrant       engine       khu vực /   ghi nhớ      chuyển
 hybrid       + Postgres    khung giờ  ưu tiên      tổng đài
 BM25+vector  (SQL)                    tài xế

• RAG: Qdrant, hybrid BM25 + vector, lọc metadata theo phạm vi hợp đồng và ngày hiệu lực. Tài liệu vào index phải qua allowlist có review - không phải file nào bỏ vào thư mục cũng được dùng làm căn cứ trả lời.
• Thu nhập: tham số công thức (giá/km, tỉ lệ chia sẻ, thuế, điều kiện thưởng) nằm trong file cấu hình, không hardcode. Hãng đổi chính sách thì sửa cấu hình, không phải sửa code.
• Giọng nói: gọi API nhà cung cấp qua backend proxy.
• Phân phối: PWA - mở link, thêm vào màn hình chính là dùng được. Không qua chợ ứng dụng, không cần tài xế cập nhật phiên bản. Backend và frontend chạy cùng origin sau Caddy trên VPS, CI/CD tự động từ nhánh chính.

Tính khả thi

MVP hiện chạy được các luồng chính. Kết quả đã kiểm được:

• Tra chính sách: tài liệu đúng nằm trong top 3 ở 49/49 câu có nguồn; 53/57 quyết định trả lời/chuyển đúng; không có rò sai hợp đồng, vùng hoặc ngày.
• Phân loại câu hỏi: 349 câu mẫu, 765 lượt chạy, macro F1 0,932; 58/58 lượt đường tắt đúng và không gọi LLM.
• F6, F7 và F8 đã kiểm thử riêng; bài kiểm tra tích hợp đạt 17/17.
• Bộ demo có 6 hồ sơ, 3.942 dòng chuyến (3.605 chuyến hoàn thành), 4.262 lượt chào cuốc và dữ liệu của 15 quận Hà Nội.

Giới hạn hiện tại :

• Dữ liệu chuyến trong bản demo là dữ liệu mô phỏng, sinh từ chính công thức tính tiền. Nó đủ để chứng minh cơ chế chạy đúng, chưa chứng minh sản phẩm làm tăng thu nhập thật của tài xế.
• Công thức cước cần hiệu chỉnh bằng sao kê thật trước khi chạy thí điểm. Đây là việc cần dữ liệu từ phía hãng, nhóm không tự tin hoàn toàn làm được.
• Phạm vi dự án hiện tại: tài xế ở Hà Nội.

Hướng phát triển

1. Nối dữ liệu chuyến thật của hãng (chỉ đọc) thay cho dữ liệu mô phỏng, và hiệu chỉnh công thức bằng sao kê thật. Đây là điều kiện tiên quyết để chạy thí điểm.
2. Chuyển tiếp có hồ sơ: khi phải chuyển người thật, gửi kèm toàn bộ ngữ cảnh hội thoại sang tổng đài để nhân viên không phải hỏi lại từ đầu.
3. Mở rộng địa bàn và mô hình hợp đồng theo đúng cách đã làm với Hà Nội.
4. Đo hiệu quả thật: tỉ lệ câu hỏi tự giải quyết được không cần tổng đài, số cuộc gọi giảm bao nhiêu, và chỉ khi có nhóm đối chứng mới nói tới ảnh hưởng lên thu nhập tài xế.