Ba hệ quả trực tiếp cho thiết kế agent:

1. "Thủ tục vay" mạnh hơn "lãi suất & phí bảo hiểm" ở mọi nghiên cứu đo được cả hai (chênh 29% ở nghiên cứu tại TP.HCM, gần gấp 3 lần ở nghiên cứu Biên Hoà) — một agent chỉ giỏi so sánh APR sẽ không được dùng, vì người dùng không vào với câu hỏi "cái nào rẻ nhất". Agent phải thắng ở tốc độ trước, rồi mới cài chi phí vào.
2. Rủi ro cảm nhận có hệ số âm nhưng nhỏ nhất trong mô hình (β = −0,068): cảnh báo rủi ro gần như không đủ sức ngăn một người đang cần tiền gấp — nhưng vì tác động âm nhỏ, hệ thống có thể minh bạch rủi ro mà không sợ mất hết người dùng. Chi phí của việc trung thực thấp hơn người ta tưởng, miễn là cảnh báo đi kèm lối thoát cụ thể chứ không đứng một mình.
3. Niềm tin đến từ danh tiếng tổ chức, không từ chất lượng lời khuyên — một nghiên cứu ghi nhận "hình ảnh & danh tiếng" mạnh gấp gần 4 lần yếu tố đứng thứ hai. Agent kế thừa niềm tin từ thương hiệu ví và từ tên đối tác thật, không tự tạo ra được — nên một lần agent bịa điều khoản là một lần tiêu vào vốn niềm tin của cả ví, không chỉ của riêng một câu trả lời.

1.3 Bốn chân dung người vay qua ví điện tử

Persona dựng từ hành vi và bối cảnh trong dữ liệu nghiên cứu, không từ nhân khẩu học đơn thuần — dùng để quyết định agent nên hỏi gì, hỏi bao nhiêu câu, và cảnh báo ở đâu:

2. Giải pháp — FIN-10

Trợ lý hội thoại tiếng Việt trong ví điện tử, tư vấn đủ 5 nhóm sản phẩm bằng dữ liệu thật, đã dẫn nguồn — không phải catalog giả lập. Mỗi đề xuất luôn gắn đúng tên tổ chức cấp tín dụng/bảo hiểm/quản lý quỹ thật — không bao giờ giấu sau nhãn "đối tác của MoMo", vì niềm tin của người dùng ví gắn với thương hiệu cụ thể như phát hiện 1.2(3) ở trên đã chỉ ra.

2.1 Nguyên tắc kiến trúc duy nhất chi phối toàn hệ thống

LLM không được sinh ra bất kỳ con số tiền/lãi/phí nào. Ranh giới này cưỡng chế ở tầng dữ liệu, không chỉ ở tầng prompt: kho tri thức RAG loại trừ sẵn mọi tài liệu chứa giá/lãi/phí ngay từ khâu chunk hoá, nên kể cả khi LLM hỏng cũng không có nguyên liệu để bịa số. Repositories đọc số từ PostgreSQL, không bao giờ đọc số từ vector store — vector store chỉ giữ văn bản pháp lý và điều khoản.

2.2 Đường ống 7 chốt — mọi câu trả lời đi qua đủ 7 bước, không chốt nào bỏ qua được

Thứ tự trong chốt ⑤ cố định và không đổi được: điều kiện cứng chạy trước tính (người chưa đủ tuổi phải nghe "chưa đủ tuổi" ngay, không phải sau khi bị hỏi hết bảng lương); kiểm soát rủi ro chạy sau tính (DTI cần khoản trả hàng tháng, là đầu ra của máy tính); xếp hạng chạy cuối, chỉ trên ứng viên đã đạt điều kiện. Trọng số xếp hạng cố định và có version: khả năng chi trả 35% · tổng chi phí 30% · độ khớp nhu cầu 25% · độ linh hoạt 10%. Hoà điểm thì gói tổng chi phí thấp hơn thắng; vẫn hoà thì sắp theo mã sản phẩm — không có bước nào ngẫu nhiên.

2.3 Luồng hội thoại bám theo đúng những gì nghiên cứu hành vi chỉ ra

• Hỏi nhu cầu trước khi đề xuất — không mở đầu bằng bảng so sánh sản phẩm, đúng nguyên tắc "động cơ vay là biến mạnh nhất" (mục 1.2).
• Nhận diện tiếng lóng tiền tệ nhưng không tự đoán. "Vay 30 chai", "50 củ", "20 vé", "20 xị" được nhận ra là số tiền — nhưng hệ thống hỏi lại thay vì tự quy đổi. Quyết định này đến từ đo đạc thật, không phải trực giác: ban đầu để LLM tự quy đổi theo bảng trong prompt, đo lại vẫn thấy quy sai ở nhiều case dù đã được dặn rõ trong prompt — nên chốt lại thành một rào chặn ở tầng code, chạy trước LLM, cùng cơ chế với chặn injection. Đoán sai một con số tiền còn nguy hiểm hơn hỏi lại một câu.
• Cảnh báo rủi ro luôn kèm lối thoát định lượng, đúng như phát hiện "rủi ro cảm nhận có hệ số âm nhưng nhỏ" khuyến nghị: khi khoản trả vượt ngưỡng DTI an toàn của gói, hệ thống không dừng ở "rủi ro cao" — nó tính sẵn các kỳ hạn thay thế kèm DTI mới cho từng phương án. Cảnh báo giữ nguyên qua nhiều lượt kể cả khi khách hàng nài ép chọn phương án rủi ro hơn — agent không nhượng bộ chỉ vì bị hỏi lại nhiều lần.
• Từ chối là một kết quả hợp lệ. Không có sản phẩm phù hợp thì trả lời thẳng kèm mã lý do, không cố nhét một gói không đạt điều kiện vào danh sách cho đủ số lượng.
• Không so sánh chéo nhóm. "Thẻ tín dụng tốt hơn hay Túi Thần Tài tốt hơn?" không có đáp án chung một thước đo — hệ thống giải thích vì sao, thay vì bịa ra một điểm số hoặc hỏi ngược vô ích khi câu hỏi vốn đã đủ rõ để trả lời trực tiếp.
• Luôn nêu tên tổ chức cấp tín dụng thật cạnh mỗi đề xuất — không ẩn sau nhãn "đối tác".

2.4 5 nhóm sản phẩm, mỗi nhóm một thước đo riêng — vì chúng không quy về một đơn vị chung

Dữ liệu là 10 sản phẩm thật của 11 đối tác (data_origin=PUBLISHED_REFERENCE), lấy từ công bố công khai — không phải dữ liệu mock:

Toàn bộ 11 đối tác (kể cả MoMo với vai trò trung gian) được đối chiếu chéo giữa trang chính thức momo.vn, biểu phí đối tác và báo chí uy tín trước khi đưa vào catalog — mọi khoảng trống hoặc mâu thuẫn giữa nguồn (ví dụ lãi suất thẻ BVBank JCB Link: 2,71%/tháng theo trang MoMo vs 3,58%/tháng theo biểu phí BVBank) được ghi lại rõ ràng thay vì chọn liều một con số.

3. HITL, phân quyền & tuân thủ

Hệ thống dựng hai gate bắt buộc trước khi một hồ sơ được coi là hoàn tất, đúng yêu cầu "cấm bypass HITL" của đề bài:

• User Confirmation — người dùng xác nhận một snapshot bất biến cụ thể (số liệu, sản phẩm, chi phí, version tại đúng thời điểm xác nhận).
• Human Review — mọi hồ sơ, kể cả rủi ro thấp, đều phải qua một reviewer với 4 hành động khả dụng: APPROVE · REJECT · REQUEST_INFORMATION · ESCALATE. Reviewer không được sửa dữ liệu người dùng hay override một sản phẩm hard-ineligible; "Approve" chỉ chuyển sang bước nộp mô phỏng, không đồng nghĩa phê duyệt tín dụng thật.

Vòng đời một hồ sơ đi qua 8 trạng thái tường minh (DRAFT → ADVISED → USER_CONFIRMED → PENDING_HUMAN_REVIEW → NEEDS_INFO/APPROVED/REJECTED → SIMULATED_SUBMITTED), mỗi thay đổi ghi audit với vai trò người thực hiện (CUSTOMER, HUMAN_REVIEWER, PRODUCT_ADMIN, AUDITOR_COMPLIANCE, hoặc SYSTEM). Thay đổi dữ liệu người dùng, version sản phẩm, rule hay kết quả tính toán làm confirmation/approval cũ hết hiệu lực ngay, buộc xác nhận lại từ đầu.

RBAC 4 vai trò (CUSTOMER, HUMAN_REVIEWER, PRODUCT_ADMIN, AUDITOR_COMPLIANCE) tách bạch quyền: khách hàng chat và xác nhận, reviewer duyệt hàng đợi, admin quản lý danh mục/version, auditor xem read-only cho mục đích compliance. Rule engine đánh giá rủi ro tín dụng theo dữ liệu CIC mô phỏng — nợ nhóm 2 tạo cảnh báo, nợ nhóm 3–5 hoặc đang bị nhắc nợ/thu hồi chặn cứng sản phẩm, trễ hạn ≥3 lần trong 12 tháng tạo cảnh báo riêng — độc lập với eligibility theo sản phẩm.

Bảo mật có một bộ 172 test riêng (34 test guard số/mệnh đề/injection, 7 test phân tách phiên, 10 test rate limit) — mỗi test tương ứng một chuỗi tấn công đã đo là lọt qua được trước khi vá, không phải giả định lý thuyết.

4. Trải nghiệm người dùng & mặt kỹ thuật

• Giao diện: SPA React + TypeScript, 7 route (landing, chat, danh sách sản phẩm, admin, đăng nhập, hồ sơ cá nhân, trạng thái hồ sơ), hợp đồng API sinh tự động từ OpenAPI để frontend/backend không lệch schema.
• Backend: FastAPI, 22 endpoint (chat, lịch sử hội thoại, danh mục, tài khoản, hồ sơ, đơn vay, thẩm định, vận hành) — một tiến trình phục vụ cả API lẫn UI.
• CTA và nội dung chuẩn hoá: các cụm từ như "Bạn chắc chắn được duyệt", "Sản phẩm tốt nhất" (khi chưa nêu metric), "Reviewer đã duyệt khoản vay" bị cấm tuyệt đối trong toàn bộ nội dung hiển thị — không chỉ trong câu trả lời của agent. Mọi màn hình liên quan đến mô phỏng đều mang disclaimer cố định: dữ liệu và kết quả là mô phỏng, không phải phê duyệt tín dụng hay cam kết từ tổ chức tài chính.
• Dữ liệu tri thức pháp lý: 1.688 đoạn (chunk) trong ChromaDB — 1.198 trích dẫn pháp luật/quy định, 417 tài liệu nền, 43 mục glossary, 30 điều khoản sản phẩm — embedding bằng model tiếng Việt chạy local (bkai-foundation-models/vietnamese-bi-encoder), không gọi API ngoài cho bước này.
• Hội thoại được lưu có chủ đích phân biệt theo trạng thái đăng nhập: khách đã đăng nhập lưu ở PostgreSQL, sống sót qua restart; khách vãng lai chỉ lưu trong RAM và không được lưu là có chủ ý, không phải thiếu sót — nội dung hội thoại chứa thu nhập và dư nợ, lưu một bản ghi vô danh nghĩa là không ai có thể yêu cầu xoá nó, kể cả chính người đã gõ ra.
• Chế độ dự phòng khi mất key LLM: AGENT_MODE=rules chuyển sang router quy tắc thuần, không cần OpenAI API key — demo xuống cấp về văn phong chứ không chết hoàn toàn.

5. Tính khả thi — đã đo, không phải hứa

• 1.045 unit test, 100% pass.

• Bộ eval hành vi 126 case, chia 3 tầng theo cách chấm (không theo chủ đề, để tách bạch "tính sai" khỏi "diễn đạt khác"):

  Tầng	Số case	Chấm bằng gì	Ngưỡng	Kết quả 24/08/2026
  A — tất định	66	Đáp án dựng sẵn từ công cụ tính + tên mục glossary	100%	66/66 (100%)
  B — hành vi	43	Loại hành vi + ràng buộc nội dung (must_include/must_not_include)	≥85%	43/43 (100%)
  C — nhiều lượt	17	Con số của lượt trước còn sống ở lượt sau	≥80%	17/17 (100%)

  Đây là lần đầu cả ba tầng cùng đạt tuyệt đối. Đáp án tầng A bị "đóng băng" (không tính lại lúc chạy) và có cơ chế tự phát hiện lệch — cơ chế này ra đời sau một sự cố thật: một khoản phí trả góp đổi trong công cụ tính ngày 19/08 mà đáp án đóng băng ngày 22/08 không mang theo, khiến tầng A báo 66/66 ba lần liên tiếp trong khi ứng dụng thiếu đúng 5.400.000đ so với đáp án đang dùng để chấm — hai cái sai giống nhau so ra bằng nhau. Từ đó, dựng lại đáp án dừng lại khi phát hiện số liệu đổi, chỉ ghi đè khi chạy với cờ xác nhận rõ ràng.

• Chặn injection 100% ở cả chỉ số offline (ngưỡng chặn merge) lẫn 5 case injection riêng trong tầng A — kể cả các biến thể không dấu, leetspeak, diễn đạt lại.

• Không bịa số: 100%, thực thi bằng guard chốt ⑥ trên mọi câu trả lời, không phải một mục tiêu đo bằng mẫu.

• Runner loại các case lỗi do giới hạn tốc độ nhà cung cấp API khỏi mẫu số thay vì tính là trượt, để tránh nhầm lỗi hạ tầng với tín hiệu chất lượng thật.

• Đã deploy trên Google Cloud Run, health check trả {"status":"ok","env":"production"}.

6. Giới hạn còn mở — nói thẳng, không giấu

• Vẫn là pilot độc lập, chưa tích hợp thật vào ví MoMo.
• Một vài số liệu công bố (lãi suất Vay Nhanh theo từng đối tác cụ thể, hạn mức thẻ BVBank) có mâu thuẫn giữa nguồn thứ cấp và biểu phí chính thức — hệ thống ưu tiên nêu rõ khoảng/nguồn thay vì chốt một số duy nhất khi chưa xác minh được.
• ReAct agent không tất định tuyệt đối — cùng một câu hỏi có thể ra hành vi khác nhau đôi chút giữa hai lần chạy dù nhiệt độ = 0; đây là lý do bộ eval nhìn xu hướng nhiều lần chạy, không chốt vào một con số đơn lẻ.
• Rate limit trên /login có thể bị vượt qua bằng cách đổi header mỗi request — điểm yếu đã biết, chưa vá, ghi công khai trong tài liệu bảo mật thay vì che giấu.
• Rate limit và session hiện tại lưu trong RAM của một container — đúng cho demo một instance, chưa sẵn sàng cho nhiều replica.
• Persona "tiểu thương/hộ kinh doanh" (nhu cầu vay lặp lại theo chu kỳ) mới dừng ở giả thuyết thiết kế, chưa có phỏng vấn trực tiếp để xác nhận.
• Ảnh hưởng xã hội tới quyết định vay mâu thuẫn giữa các nguồn nghiên cứu (có ý nghĩa mạnh ở một số, không có ý nghĩa ở số khác) — nên yếu tố này cố tình chưa được đưa vào logic xếp hạng.

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

Đây là những bước tiếp theo chúng tôi đề xuất, sắp theo mức độ cấp thiết đối với người dùng và doanh nghiệp, không phải theo độ khó kỹ thuật — để anh/chị dễ quyết định nên đầu tư thời gian vào đâu trước.

Nên làm ngay, trước khi mở rộng cho nhiều người dùng hơn

1. Vá một lỗ bảo mật đã biết ở bước đăng nhập, và chuyển phần "nhớ trạng thái" của hệ thống sang nơi dùng chung được giữa nhiều máy chủ. Hệ thống hiện chạy ổn định trên một máy chủ demo; đây là điều kiện bắt buộc trước khi phục vụ lượng người dùng thật trên nhiều máy chủ cùng lúc — làm trước để không phải sửa chữa gấp khi lượng dùng tăng đột ngột.
2. Đo lại "hỏi bao nhiêu câu là vừa" bằng hành vi thật của người dùng MoMo, thay vì theo lý thuyết. Hiện agent dừng ở tối đa vài câu trước khi đưa đề xuất đầu tiên, dựa trên nghiên cứu hành vi vay nói chung. Con số đúng cho riêng khách hàng MoMo cần đo bằng tỷ lệ người rời đi giữa chừng theo từng lượt hỏi — một khi có số liệu thật, trải nghiệm sẽ tinh hơn nhiều so với suy luận từ bên ngoài.

Nên làm trong giai đoạn thử nghiệm có người dùng thật

3. Đo thêm "lời giải thích của agent có thuyết phục không", không chỉ "con số có đúng không". Công cụ đo đã có sẵn, nhưng chúng tôi chủ động chưa dùng nó để quyết định một bản cập nhật có được phát hành hay không — vì cần thêm thời gian kiểm chứng thước đo này đủ tin cậy trước khi để nó có quyền chặn một bản phát hành. Đây là bước thận trọng có chủ đích, không phải việc bị bỏ sót.
4. Thử nghiệm A/B giữa hai cách cảnh báo rủi ro — một cách kèm gợi ý lối thoát cụ thể (ví dụ kéo dài kỳ hạn để giảm gánh nặng trả nợ hàng tháng) và một cách cảnh báo thẳng không kèm gợi ý — để đo xem cách nào giữ được nhiều khách hàng ở lại kênh vay chính thức hơn, thay vì bỏ đi tìm nguồn vay khác rủi ro hơn. Nghiên cứu hành vi cho chúng tôi biết hướng tác động; chỉ đo trên chính khách hàng MoMo mới cho biết mức chênh lệch thật, để quyết định có đáng đầu tư sâu hơn vào hướng này không.
5. Xác nhận nhóm khách hàng "tiểu thương/hộ kinh doanh" — những người vay vốn lưu động lặp lại theo chu kỳ bán hàng — bằng phỏng vấn trực tiếp khoảng 8–12 khách hàng thực tế. Đây là nhóm duy nhất trong 4 chân dung người dùng mà chúng tôi mới suy luận từ bối cảnh thị trường, chưa có bằng chứng hành vi trực tiếp. Nếu đúng như giả thuyết, nhóm này cần thêm một tính năng riêng: agent nhớ chu kỳ vay của khách để chủ động cảnh báo khi tần suất vay tăng bất thường — trước khi khách rơi vào tình trạng vay chồng vay.

Duy trì lâu dài, không phải làm một lần rồi thôi

6. Đưa việc rà soát lãi suất, hạn mức và điều kiện của từng đối tác thành một việc lặp lại định kỳ 6 tháng/lần. Thị trường tín dụng tiêu dùng đang thay đổi nhanh hơn tốc độ một lần cập nhật dữ liệu có thể theo kịp — với anh/chị, "đúng tại thời điểm khách hỏi" quan trọng hơn nhiều so với "đẹp một lần lúc ra mắt rồi cũ dần".