③ Tài liệu có phiên bản và ngày hiệu lực. Chính sách thay đổi. Trả lời theo bản cũ nguy hiểm ngang với bịa. Hệ thống phải quản lý version, rollback, soft-delete, chỉ dùng bản active, và nói rõ ngày hiệu lực trong trích dẫn.

④ Tiếng Việt nội bộ. Người dùng gõ không dấu ("nghi phep thai san"), dùng viết tắt phòng ban, và gọi cùng một khái niệm bằng nhiều từ ("tải lên" / "upload"). Mọi so khớp theo ký tự phải chạy trên cùng một dạng chuẩn hóa, nếu không kết quả phụ thuộc vào việc người dùng có gõ dấu hay không.

1.4 Yêu cầu phải đạt

Phạm vi được xác định rõ từ đầu. Các hạng mục sau nằm ngoài bản MVP bốn tuần, với lý do ghi lại trong hồ sơ thiết kế: xử lý nghiệp vụ HR thật (duyệt phép, tính lương), tích hợp chấm công/bảng lương, trả lời câu hỏi gắn dữ liệu cá nhân của người hỏi, tích hợp Slack/Teams/Zalo, OCR và XLSX, fine-tune model riêng, business dashboard.

2. Giải pháp kỹ thuật

2.1 Kiến trúc triển khai

Ba service độc lập chạy bằng Docker Compose sau một Nginx reverse proxy, cùng một tầng dữ liệu dùng chung.

Backend và Agent nói chuyện qua HTTP nội bộ, xác thực bằng INTERNAL_TOKEN. Chỉ Backend tiếp xúc Frontend; Agent nằm sau một biên duy nhất.

2.2 Pipeline xử lý một câu hỏi

Toàn bộ luồng là một LangGraph 12 node, mỗi node bị bao bởi giới hạn thời gian theo chặng và deadline còn lại của cả request (28 giây).

Nguồn: src/agents/graph.py · src/agents/nodes/ · src/services/answer_verifier.py

2.3 Sáu quyết định thiết kế cốt lõi

① PostgreSQL + pgvector làm luôn vector store. Không thêm vector DB riêng. Lý do không phải để tiết kiệm container: dữ liệu nghiệp vụ và chunk nằm cùng một transaction boundary, nên có thể lọc quyền truy cập bằng SQL ngay trong câu truy vấn retrieval. Quyết định ngày đầu này về sau trở thành nền tảng của toàn bộ authorization.

② LLM không bao giờ quyết định phân quyền. Bản đầu có một "Department Guard" chạy bằng LLM sau khi đã sinh câu trả lời. Nó được thay hoàn toàn bằng cơ chế tất định:

• visibility_filter() sinh biểu thức SQL từ vai trò + phòng ban đã xác thực, dùng toán tử overlap && để tận dụng GIN index trên applicable_departments.
• is_visible_metadata() kiểm tra lại tương đương bằng Python trên evidence đã materialize — hai lớp độc lập cùng một luật.
• AuthorizedRetriever buộc mọi đường đi (sub-query, section expansion, parent lookup) phải finalize dưới cùng một authorization context.
• Thiếu vai trò trong request mặc định là employee — phân quyền mặc định theo chiều hẹp nhất.

③ Không đủ bằng chứng thì từ chối, không đoán. evidence_quality_decision() chấm từng chunk một: điểm cao ở chunk này không cho phép chunk khác đi qua. Không qua cổng thì generator không được gọi.

④ Verifier tất định, retry đúng một lần. Toàn bộ logic kiểm chứng nằm trong một AnswerVerifier duy nhất, hoàn toàn tất định, và tối đa một targeted retry trên cùng EvidenceSet — không retrieval lại, vì retrieval lại chỉ che giấu vấn đề của bằng chứng. So với thiết kế ban đầu retry tới 6 lần, cách này giảm đáng kể latency và chi phí.

⑤ Hybrid retrieval cho tiếng Việt nội bộ. Sáu bước: vector · full-text · khớp cụm/viết tắt · RRF · rerank · section expansion. Điểm rerank không được dùng làm ngưỡng từ chối — min_similarity luôn đọc cosine thô, để lớp an toàn chống bịa không đổi khi ta chỉnh cách sắp xếp.

⑥ Quan sát được nhưng không rò nội dung. Trace store ghi route, retrieval, verification, retry, latency theo chặng, token và chi phí từng lời gọi — nhưng nguyên tắc số một là không lưu nội dung. Ledger chẩn đoán chỉ giữ hash 16 ký tự thay vì nguyên văn tài liệu, và có test khẳng định điều đó.

2.4 Vòng đời tài liệu

Upload → kiểm tra loại file và dung lượng → lưu file → parse (pypdf / python-docx, giữ heading, bảng, trang nguồn, character offset) → chunk theo cấu trúc chính sách tiếng Việt (Chương II > Mục 1 > Điều 12) → embed → ghi vào pgvector → kích hoạt version mới.

Một Quality Gate tất định chặn giữa: nếu bóc tách ra quá ít ký tự trên mỗi trang hoặc quá nhiều chunk không xác định được mục, version dừng ở pending_review chờ HR xem bằng mắt, thay vì âm thầm trở thành nguồn trích dẫn. Xoá là soft-delete có thùng rác và khôi phục được.

2.5 Chất lượng kỹ thuật và vận hành

• CI/CD — 5 job GitHub Actions: Python (ruff + pytest + coverage) · eval gate offline · backend (build + Jest + integration + E2E trên Postgres cô lập) · frontend (lint + build) · monitoring config. Thêm workflow publish image lên GHCR và deploy production có xác thực image tag bất biến.
• Giám sát: Prometheus + Grafana + Alertmanager với 15 alert rule (service down, error rate, latency, retrieval/generation/LLM failure spike, vượt ngân sách chi phí LLM, RAM/disk host, database down, số kết nối DB).
• LLMOps: prompt production khai báo trong registry có prompt_id + version + hash, ghi vào trace. Đổi prompt là một thay đổi truy vết được.
• Kiểm soát chi phí: model rẻ cho định tuyến, model chính cho sinh câu trả lời. Cost tracking ghi token và tiền cho từng lời gọi, cộng đúng về một trace mỗi câu hỏi.

3. Tính khả thi

3.1 Khả thi về triển khai — đã chạy thật

• Toàn bộ stack 6 container dựng bằng một lệnh docker compose up -d, có health check cho từng service.
• Bản chạy công khai trên internet sau nginx + TLS, có tài khoản demo cho ba vai trò hiển thị ngay trang đăng nhập.
• CI chạy trên mọi PR; image publish lên GHCR; workflow deploy production xác thực image tag bất biến trước khi triển khai lên VPS.
• 13 migration Alembic + 9 migration TypeORM, có test khoá sơ đồ để phát hiện trôi dạt entity ↔ schema.

3.2 Khả thi về chất lượng AI

Toàn bộ đánh giá chạy trên golden dataset khoá bằng SHA256, bằng bộ chấm tất định tự viết — không dùng RAGAS và không dùng LLM-as-a-judge, nên kết quả tái lập được.

Truy xuất — đạt mục tiêu

Trích dẫn — đạt mục tiêu

Không có trích dẫn nào trỏ tới tài liệu không tồn tại hoặc không nằm trong phạm vi người hỏi được đọc. Cơ chế đứng sau con số này là kiến trúc chứ không phải may mắn: chunk không xác định được section_path bị SQL loại từ đầu nên không bao giờ trở thành nguồn trích dẫn, và metadata trích dẫn được dựng ở server từ chunk đã retrieve chứ không lấy từ output của model.

An toàn và phân quyền

Không có rò rỉ trong bất kỳ lần chạy nào được lưu trong repo. Đây là kết quả trực tiếp của quyết định thiết kế ②: phân quyền là tất định và nằm ở tầng SQL, nên nó không phụ thuộc vào việc model hôm đó trả lời thế nào.

Vòng đời tài liệu và định tuyến

• F3 — 10/10 checkpoint PASS trên kịch bản E2E chạy thật qua Backend API: upload v1 và trả lời có trích dẫn, chặn trùng lặp 409, upload v2 không gián đoạn, xử lý v3 parse lỗi không gián đoạn, rollback về v1 và trả lời lại đúng, chặn rollback về version lỗi.
• Định tuyến ý định — 64/65 case (98,46%), ổn định qua 6 lần chạy nối tiếp.

3.3 Khả thi về hiệu năng và chi phí

Hơn nửa số request hoàn tất dưới 3 giây. Về chi phí, với 1.000 câu hỏi mỗi ngày thì tiền model rơi vào khoảng 54 USD/tháng — chi phí vận hành không phải rào cản ở quy mô doanh nghiệp vài nghìn nhân viên.

Nhóm cũng đã dựng sẵn bộ đo tải CCU hai arm (một arm dùng mock provider để đo trần của phần mềm, một arm dùng provider thật để đo trải nghiệm người dùng), chạy 960 request qua bốn mức đồng thời 1/5/10/25. Giá trị của phép đo này là nó chỉ đích danh thành phần cần tối ưu trước tiên bằng bằng chứng số thay vì suy đoán.

3.4 Kết luận về tính khả thi

Hệ thống khả thi cả về kỹ thuật lẫn kinh tế. Các hạng mục còn lại trước khi triển khai diện rộng đều đã được định vị chính xác và có kế hoạch xử lý ở mục 4; phần chưa chốt được nêu ở phụ lục.

4. Hướng phát triển

Ba giai đoạn, theo thứ tự giá trị mang lại cho người dùng.

Giai đoạn 1 — Trả lời được nhiều hơn, nhanh hơn

Mục tiêu: nhân viên hỏi gì cũng nhận được thứ có ích, kể cả khi tài liệu chưa phủ hết.

• Mở rộng vùng trả lời — hiệu chỉnh ngưỡng bằng dữ liệu để agent trả lời được nhiều câu hơn mà vẫn giữ nguyên cam kết không trả lời sai.
• Trả lời một phần cho câu hỏi nhiều vế, thay vì từ chối trọn gói khi chỉ một vế thiếu căn cứ.
• Mỗi câu từ chối kèm đường đi tiếp — gửi thẳng câu hỏi cho HR, hoặc gợi ý tài liệu liên quan mà người hỏi được phép đọc.
• Hiển thị câu trả lời theo dòng để người dùng thấy tiến trình thay vì chờ trước màn hình trống.
• Bấm vào trích dẫn mở thẳng tài liệu gốc, đúng đoạn, có tô sáng.

Giai đoạn 2 — Khép vòng cải tiến cùng HR

Mục tiêu: sản phẩm tốt lên theo thời gian thay vì đứng yên sau khi bàn giao.

• Thu phản hồi ngay trong hội thoại — nhân viên đánh giá câu trả lời hữu ích hay chưa đúng.
• Màn hình khoảng trống chính sách cho HR — câu hỏi nhiều nhất, câu chưa có tài liệu để trả lời, từ đó HR biết cần bổ sung hoặc làm rõ quy định nào.
• HR soát chất lượng câu trả lời; câu được đánh dấu trở thành bài kiểm tra cho lần cải tiến sau.
• Chủ động thông báo cho những người từng hỏi khi điều khoản liên quan lên phiên bản mới.
• SLA và trạng thái đơn để người gửi biết đơn của mình đang ở bước nào.

Giai đoạn 3 — Mở rộng quy mô và phạm vi

Mục tiêu: từ một trợ lý HR thành nền tảng tri thức nội bộ.

• Nâng năng lực phục vụ đồng thời để đáp ứng toàn bộ nhân sự cùng lúc.
• Nộp đơn và đặt lịch gặp HR ngay trong hội thoại, thay vì chỉ tra cứu.
• Đưa trợ lý vào Slack / Teams / Zalo — người dùng không phải mở thêm một ứng dụng nữa.
• Kết nối HRIS để trả lời an toàn các câu hỏi cá nhân ("tôi còn bao nhiêu ngày phép").
• Mở sang miền tri thức khác — IT helpdesk, quy trình tài chính, đào tạo — tái dùng nguyên kiến trúc hiện có.

Bốn nguyên tắc giữ nguyên khi mở rộng

1. LLM không quyết định phân quyền.
2. Không đủ bằng chứng thì từ chối.
3. Trích dẫn dựng ở server chứ không lấy từ output của model.
4. Nhật ký vận hành không lưu nội dung câu hỏi hay tài liệu.

Một tính năng mới không được phép khoét lỗ trong bốn điều đó, vì một cái lỗ như vậy rất khó chứng minh là chỉ mở đúng cho một trường hợp.