1. Tại sao một Nền tảng Thanh toán Quy mô lớn lại cần Kiến trúc AI
Vào năm 2024, PayPay đã vượt qua cột mốc 70 triệu người dùng đăng ký. Ở quy mô đó, diện tích hỗ trợ (support surface) trở nên vô cùng khổng lồ: hàng triệu người dùng có các câu hỏi về thanh toán, tài khoản quá hạn, tranh chấp giao dịch và các tính năng sản phẩm. Diện tích phát hiện gian lận (fraud detection) cũng phình to theo từng người dùng mới và từng mẫu giao dịch mới. Đội ngũ kỹ thuật nội bộ — gồm hàng trăm kỹ sư thuộc nhiều đơn vị kinh doanh — tạo ra hàng nghìn quyết định mỗi tuần, vốn rất cần sự hỗ trợ của việc truy xuất và tổng hợp tri thức.
AI không phải là một tính năng bổ sung của PayPay vào năm 2025. Đó là một sự bắt buộc về mặt vận hành.
Ba yếu tố đã hội tụ để thúc đẩy PayPay đầu tư mạnh mẽ vào AI:
- Áp lực về quy mô: 7,8 tỷ giao dịch trong năm tài chính FY2024 tạo ra khối lượng công việc hỗ trợ và vận hành tỷ lệ thuận mà các đội ngũ con người không thể hấp thụ một cách hiệu quả về mặt chi phí.
- Hợp tác SoftBank-OpenAI: Là một công ty thuộc Tập đoàn SoftBank, PayPay có quyền tiếp cận sớm các năng lực doanh nghiệp của OpenAI — bao gồm “Cristal Intelligence”, một nền tảng AI doanh nghiệp được thiết kế để phân tích và duy trì các hệ thống mã nguồn cũ (legacy codebases). Sự hợp tác này đã mang lại cho PayPay lợi thế công nghệ trong việc áp dụng AI.
- Chuyển dịch chiến lược: Ban lãnh đạo PayPay nhận thấy rằng việc chuyển đổi từ một nền tảng thanh toán thành một Hệ điều hành Tài chính (Financial OS) yêu cầu AI hoạt động như một hạ tầng vô hình — đồng thời cung cấp năng lực cho phát hiện gian lận, chấm điểm tín dụng, hỗ trợ khách hàng và cá nhân hóa sản phẩm.
Kết quả là một kiến trúc AI đa tầng bao gồm công cụ cho lập trình viên, quản lý tri thức nội bộ và các sản phẩm AI hướng tới khách hàng.
2. Tầng 1: LLM API Hub — Cổng kết nối Đa Mô hình (Multi-Model Gateway)
Nền tảng AI của PayPay là một LLM API Hub trung tâm: một cổng kết nối nội bộ định tuyến các yêu cầu AI đến nhiều mô hình ngôn ngữ lớn (LLM) khác nhau, giúp tách biệt mô hình cụ thể khỏi ứng dụng tiêu thụ dữ liệu.
Ứng dụng Nội bộ / Agent
↓
LLM API Hub (cổng kết nối nội bộ)
↓
┌───────┬───────────┬──────────┐
│ GPT-4o│ Gemini │ Claude │
│(OpenAI)│(Google) │(Anthropic)│
└───────┴───────────┴──────────┘
Tại sao lại cần một hub đa mô hình?
- Không bị khóa nhà cung cấp (No vendor lock-in): Nếu OpenAI thay đổi giá cả hoặc hành vi của mô hình, PayPay có thể chuyển lưu lượng truy cập sang Gemini hoặc Claude mà không cần sửa đổi bất kỳ ứng dụng tiêu thụ nào.
- Tối ưu hóa chi phí: GPT-4o-mini xử lý các tác vụ thông thường, có độ phức tạp thấp hơn (tóm tắt tài liệu, tạo câu hỏi FAQ, viết comment code) với chi phí chỉ bằng một phần nhỏ so với các mô hình lớn hơn. GPT-4o hoặc Claude 3 Opus sẽ xử lý các tác vụ suy luận phức tạp (phân tích mẫu gian lận, luồng agent nhiều bước) nơi mà độ chính xác cao xứng đáng với chi phí token đắt đỏ.
- Tầng bảo mật và tuân thủ: Tất cả các yêu cầu đều đi qua một tầng lọc (sanitization layer) của hub trước khi gửi tới API LLM bên ngoài. Các thông tin định danh cá nhân nhạy cảm (PII) của người dùng, dữ liệu tài chính và chi tiết hệ thống nội bộ sẽ bị phát hiện và lọc bỏ. Các phản hồi của LLM cũng được xác thực trước các chính sách an toàn trước khi trả về ứng dụng.
- Quản lý giới hạn tần suất (Rate limiting) và Nhật ký kiểm toán tập trung: Mỗi lượt gọi API LLM đều được ghi nhật ký với thông tin service gọi, mô hình sử dụng, số lượng token, độ trễ và chi phí. Nhật ký kiểm toán (audit trail) này là bắt buộc đối với cả quản trị chi phí lẫn tuân thủ quy định pháp luật trong lĩnh vực tài chính.
3. Tầng 2: Đường ống RAG Nội bộ (Internal RAG Pipeline)
Các LLM rất mạnh mẽ nhưng có một hạn chế cơ bản: kiến thức của chúng bị đóng băng tại thời điểm hoàn tất huấn luyện. Trong khi đó, tri thức nội bộ của PayPay — tài liệu vận hành (runbooks), chính sách tuân thủ, quy trình nhân sự, đặc tả sản phẩm và báo cáo sự cố lịch sử — liên tục được cập nhật và là tài sản độc quyền.
Retrieval-Augmented Generation (RAG - Tạo phản hồi tăng cường truy xuất) giải quyết khoảng cách này bằng cách cung cấp cho LLM quyền truy cập vào một cơ sở tri thức động, có thể tìm kiếm được tại thời điểm suy luận (inference time).
Kiến trúc RAG của PayPay
Nguồn Tri thức:
├── Wiki nội bộ (Confluence)
├── Tài liệu vận hành kỹ thuật (Runbooks)
├── Quy chế công ty & Tài liệu tuân thủ
└── Báo cáo sự cố lịch sử (Incident post-mortems)
↓ (Đường ống Ingestion)
Tiền xử lý (Preprocessing):
- Tài liệu được chia nhỏ (chunked) theo tiêu đề và chương
- Mỗi chunk giữ nguyên ngữ cảnh của tài liệu cha
- Gắn thẻ siêu dữ liệu (metadata): loại tài liệu, người sở hữu, lần cập nhật cuối
↓
Vector Embedding → Lưu vào ChromaDB (vector store)
↓ (Đường ống Truy vấn - Query Pipeline)
Truy vấn của Người dùng
→ Được embedding vào cùng một không gian vector
→ Tìm kiếm độ tương đồng ngữ nghĩa trong ChromaDB
→ Truy xuất Top-K chunk có liên quan nhất
→ Injected các chunk này vào context window của LLM
→ LLM tạo câu trả lời dựa trên thông tin thực tế từ tài liệu
Tại sao lại chia nhỏ tài liệu theo tiêu đề/chương? Việc chia nhỏ theo các đơn vị ngữ nghĩa (phần, chương) thay vì các cửa sổ token ngẫu nhiên đảm bảo ngữ cảnh được truy xuất có tính mạch lạc — LLM nhận được toàn bộ lập luận hoặc quy trình hoàn chỉnh, chứ không phải một mảnh vụn bắt đầu giữa câu. Điều này giúp giảm thiểu đáng kể hiện tượng “ảo tưởng” (hallucination) trong câu trả lời RAG, yếu tố cực kỳ quan trọng đối với các tài liệu tuân thủ nơi độ chính xác là tuyệt đối.
Các Case Study RAG trong Vận hành Thực tế
| Use Case | Nguồn Tri thức | Đối tượng Sử dụng |
|---|---|---|
| Hỗ trợ Kỹ thuật Q&A | Tài liệu kiến trúc, runbooks | Kỹ sư nội bộ |
| Tuân thủ Pháp lý Q&A | Quy định pháp luật, chính sách PCI DSS | Đội ngũ tuân thủ và pháp lý |
| Phân tích Sự cố | Báo cáo sự cố (post-mortems) lịch sử | Kỹ sư SRE on-call |
| Truy xuất Chính sách | HR, tài chính, chính sách sản phẩm | Toàn bộ nhân viên |
Đường ống RAG này còn mang lại một lợi ích phụ: nó ép buộc kỷ luật viết tài liệu. Các đội ngũ muốn tri thức của mình có thể truy xuất được bắt buộc phải giữ các trang Confluence của họ luôn được cập nhật, cấu trúc rõ ràng và gắn thẻ tag chính xác — biến việc áp dụng AI thành một chương trình cải tiến tài liệu trong toàn tổ chức.
4. Tầng 3: Ứng dụng AI Thực tế — Chatbot Xử lý Nợ Quá Hạn (Delinquency Chatbot)
PayPay đã ra mắt ứng dụng generative AI hướng tới người dùng đầu tiên vào tháng 3 năm 2025: một Chatbot Xử lý Nợ Quá Hạn tích hợp Generative AI (Generative AI-Enabled Payment Delinquency Chatbot).
Vấn đề: Các dịch vụ tài chính của PayPay (tín dụng PayPay Atobarai, thẻ PayPay Card) phát sinh các trường hợp nợ quá hạn — người dùng trễ hạn thanh toán. Việc xử lý các thắc mắc về nợ quá hạn một cách thủ công rất tốn kém, nhạy cảm về thời gian và tâm lý — người dùng gặp khó khăn về tài chính thường có xu hướng tránh né tương tác với nhân viên hỗ trợ con người do cảm giác xấu hổ hoặc lo âu.
Giải pháp AI:
Người dùng bắt đầu truy vấn về nợ quá hạn (trên app hoặc web)
↓
Chatbot truy xuất thông tin từ RAG:
- Lịch sử thanh toán cụ thể của người dùng (cá nhân hóa)
- Số tiền quá hạn hiện tại và ngày đến hạn
- Các phương án thanh toán khả thi và thời hạn
- Chính sách công ty về phí phạt chậm trả và thời gian ân hạn
↓
LLM tạo ra phản hồi đồng cảm, chính xác và được cá nhân hóa
↓
Người dùng có thể xác nhận kế hoạch trả nợ trực tiếp trong khung chat
↓
Nếu cần leo thang (escalation) → chuyển giao mượt mà sang nhân viên hỗ trợ kèm đầy đủ ngữ cảnh cuộc hội thoại trước đó
Nguyên tắc thiết kế:
- Hạ thấp rào cản tâm lý: Tông giọng của chatbot được thiết kế có chủ ý để không phán xét và tập trung vào giải pháp, giúp giảm bớt lo âu — rào cản chính khiến người dùng trốn tránh các vấn đề nợ nần.
- Độ chính xác quan trọng hơn tốc độ: Với những rủi ro liên quan đến tài chính và pháp lý, cơ chế truy xuất RAG được tối ưu hóa cho độ chính xác cao — tốt hơn là truy xuất ít tài liệu nhưng cực kỳ chính xác hơn là nhiều tài liệu có liên quan lỏng lẻo.
- Chuyển giao mượt mà (Graceful escalation): Chatbot có các giao thức chuyển giao rõ ràng — khi tình huống vượt quá phạm vi xử lý (tranh chấp phức tạp, đe dọa pháp lý), nó sẽ tóm tắt cuộc hội thoại và định tuyến đến một nhân viên hỗ trợ là con người kèm theo toàn bộ ngữ cảnh, tránh trải nghiệm gây ức chế khi người dùng phải giải thích lại từ đầu.
5. Tầng 4: Từ Công cụ tới các Agent Tự Trị (Autonomous Agents)
Chiến lược AI của PayPay cho năm 2025 và tương lai rất rõ ràng: dịch chuyển từ AI đóng vai trò công cụ sang AI hoạt động như một Agent tự trị.
- Năm 2024 — Giai đoạn Công cụ AI:
- GitHub Copilot để hoàn thành mã nguồn.
- Slackbot nội bộ để hỏi đáp Q&A và tìm kiếm tài liệu.
- GPT-4 cho các tác vụ đơn lẻ (giải thích code, tóm tắt Pull Request).
- Năm 2025 — Giai đoạn Agent: PayPay đang xây dựng các agent có khả năng tự suy luận, lên kế hoạch và thực thi các tác vụ nhiều bước một cách tự trị — chứ không chỉ phản hồi lại các câu lệnh (prompts) đơn lẻ.
Ví dụ: Code Review Agent
Kích hoạt (Trigger): Một PR được tạo trên GitHub
Hành động của Agent:
1. Đọc file diff của PR và xác định các service bị thay đổi.
2. Truy xuất các tài liệu kiến trúc liên quan từ RAG.
3. Kiểm tra độ phủ của bài test (test coverage) so với chính sách công ty.
4. Phân tích các thay đổi có khả năng gây lỗi (breaking changes) trong các contract gRPC.
5. Đăng bình luận review có cấu trúc:
- Security: "Endpoint này thiếu giới hạn tần suất (rate limiting) — xem runbook X."
- Architecture: "Việc này vi phạm ranh giới domain của Wallet — xem tài liệu ADR-42."
- Testing: "Độ phủ test cho các trường hợp biên của thanh toán đang dưới 80%."
6. Gắn cờ (flag) yêu cầu người review con người kiểm tra nếu điểm rủi ro vượt ngưỡng.
Agent này không thay thế người review con người — nó khuếch đại hiệu quả của họ bằng cách hoàn thành phần việc cơ học, tẻ nhạt của quy trình code review trước khi con người bắt đầu đọc dòng code đầu tiên.
6. LLMOps: Cách PayPay Quản trị AI trên Production
Vận hành AI trong một môi trường dịch vụ tài chính có sự quản lý nghiêm ngặt của pháp luật đòi hỏi một cơ chế quản trị mà hầu hết các dự án AI thông thường bỏ qua. Các thực hành LLMOps của PayPay:
- Tài liệu Thiết kế (DesignDocs) cho các thành phần AI: Mỗi tính năng AI mới đều phải tuân theo quy trình viết DesignDoc giống như bất kỳ microservice nào — làm rõ lý do chọn mô hình, chiến lược chia nhỏ tài liệu, thiết kế prompt và hành vi dự phòng (fallback) trước khi bắt đầu code. Điều này đảm bảo các quyết định kiến trúc AI được lập luận chặt chẽ và ghi chép đầy đủ như các quyết định hạ tầng.
- Khung đo lường đa tầng (Multi-tier metrics framework):
- Sức khỏe hệ thống: Độ trễ API LLM, thời gian truy xuất RAG, chi phí tính toán embedding, tỷ lệ lỗi.
- Chất lượng phản hồi: Độ chính xác truy xuất (các chunk được truy xuất có đúng không?), tính xác thực của phản hồi (câu trả lời có dựa trên tài liệu truy xuất hay là ảo tưởng?).
- Giá trị doanh nghiệp: Đối với chatbot xử lý nợ quá hạn — tỷ lệ giải quyết (người dùng đồng ý kế hoạch trả nợ mà không cần nhân sự con người can thiệp), điểm số hài lòng của người dùng, thời gian giảm nợ quá hạn.
- Danh mục Bằng sáng chế (Patent portfolio): PayPay đã giành được nhiều bằng sáng chế cho các thành phần cụ thể trong đường ống RAG nội bộ của họ — đặc biệt là cách xử lý, chia nhỏ và lập chỉ mục dữ liệu huấn luyện từ các hệ thống nội bộ. Tài sản trí tuệ này giúp bảo vệ cách tiếp cận truy xuất tri thức của họ trước các đối thủ cạnh tranh.
- Thúc đẩy AI từ dưới lên (Bottom-up adoption): Văn phòng Sử dụng AI của PayPay không áp đặt các công cụ hoặc use case cụ thể. Các kỹ sư tự đề xuất tích hợp AI, chứng minh giá trị qua các thử nghiệm có kiểm soát, và sau đó được áp dụng rộng rãi trong toàn tổ chức nếu kết quả xứng đáng với chi phí. Văn hóa này đã tạo ra một danh mục các ứng dụng AI phong phú và sáng tạo hơn nhiều so với việc áp đặt từ trên xuống.
7. Ý nghĩa đối với Hạ tầng Tài chính
Kiến trúc AI của PayPay vào năm 2025 đại diện cho một xu thế dịch chuyển lớn hơn trong ngành fintech: AI đang trở thành hạ tầng, chứ không chỉ là tính năng. LLM API Hub cũng cơ bản đối với hoạt động của PayPay giống như Kafka hay TiDB — một lớp hạ tầng mà mọi hệ thống khác đều phụ thuộc vào, yêu cầu tính sẵn sàng cao, khả năng quan sát và khả năng quản trị nghiêm ngặt.
Sự chuyển dịch từ nền tảng năm 2018 (một ứng dụng thanh toán QR bị sập ngay chiến dịch đầu tiên) sang nền tảng năm 2025 (một Hệ điều hành Tài chính 70 triệu người dùng chạy các AI Agent tự trị) không diễn ra thông qua một quyết định kiến trúc đơn lẻ. Nó được hình thành từ quá trình cải tiến liên tục — mỗi chiến dịch, mỗi sự cố, mỗi công nghệ mới đều là động lực thúc đẩy các cải tiến kiến trúc tiếp theo.
Đối với các đội ngũ đang xây dựng hệ thống AI Agent vào nền tảng của riêng mình, series Kiến trúc Hệ thống Agent tự trị sẽ trình bày sâu về mặt kỹ thuật đối với các mô hình điều phối đa agent (multi-agent orchestration) làm nền tảng cho các hệ thống như Code Review Agent và Chatbot xử lý nợ quá hạn.