Phần 6: Nền Tảng AI — Phát Hiện Gian Lận Dưới 10ms & Cổng Enterprise LLM Chuẩn Nhật Bản

📖 Bản tiếng Anh (English Edition)

Bài trước: Phần 5 — Kiến Trúc Chiến Dịch: Chống Chọi Đỉnh Tải 10 Tỷ Yên | Danh mục Series

Answer-first: PayPay kiểm soát gian lận dưới 10ms và tích hợp AI tạo sinh an toàn nhờ kết hợp kho đặc trưng Feast trên Redis với Triton Inference Server chạy mô hình ONNX qua gRPC. Dữ liệu nhạy cảm được bảo vệ qua Enterprise LLM Gateway làm mờ PII và cache ngữ nghĩa, đáp ứng nghiêm ngặt chuẩn APPI Nhật Bản.

Điều kiện tiên quyết: Nắm vững quy trình MLOps, kiến trúc kho đặc trưng thời gian thực, phục vụ mô hình suy luận qua gRPC với Triton/ONNX và quy định bảo mật APPI Nhật Bản.

1. Ngân Sách Độ Trễ Nghiêm Ngặt Của Hệ Thống Chấm Điểm Gian Lận Thời Gian Thực

Trong môi trường bán lẻ trực tiếp, ngưỡng chịu đựng độ trễ của khách hàng được tính bằng từng phần trăm giây. Khi người mua hàng quét mã QR động tại quầy thu ngân của một cửa hàng tiện lợi 7-Eleven hay Lawson, bất kỳ sự ngập ngừng nào vượt quá 1 giây đều tạo ra trải nghiệm khó chịu rõ rệt. PayPay thiết lập cam kết SLA độ trễ tổng thể cho một vòng đời thanh toán đầu cuối (end-to-end) là dưới 300 mili-giây:

Bảng Phân Bổ Ngân Sách Độ Trễ Thanh Toán (SLA Trần 300ms):
┌─────────────────────────┬──────────────┬─────────────────────────────────┐
│ Bước Xử Lý Mạng         │ Trần Độ Trễ  │ Thành Phần Kiến Trúc Phụ Trách │
├─────────────────────────┼──────────────┼─────────────────────────────────┤
│ Tầng Biên & Gateway     │ 35ms         │ Bắt tay TLS & Định tuyến Envoy │
│ Xác Thực & Phiên User   │ 20ms         │ Kiểm tra JWT & Sinh trắc học    │
│ Chấm Điểm Gian Lận ML   │ 10ms (SLA)   │ Feast Online Store & GPU Triton │
│ Ghi Sổ Cái Phân Tán     │ 30ms         │ Giao dịch ACID TiDB Multi-Raft  │
│ Bù Trừ Ngân Hàng Ngoài  │ 120ms        │ Mạng liên ngân hàng (Zengin/CAFIS)│
│ Phản Hồi Về Client      │ 35ms         │ Ghép kênh phản hồi HTTP/2       │
│ Vùng Đệm Dự Phòng Trễ   │ 50ms         │ Xử lý thử lại tạm thời / Jitter │
└─────────────────────────┴──────────────┴─────────────────────────────────┘

Trong ngân sách chặt chẽ này, cỗ máy học máy (ML) chấm điểm rủi ro gian lận được ấn định một thời hạn deadline cứng không quá 10 mili-giây. Nếu cỗ máy suy luận không thể đưa ra kết luận trong khoảng thời gian này, hệ thống thanh toán tuyệt đối không được phép báo lỗi làm gián đoạn việc mua sắm của khách. Thay vào đó, giao dịch tự động chuyển sang chế độ giáng cấp an toàn: đối chiếu nhanh các tập luật tĩnh (rule heuristics), cho phép thanh toán tiếp tục và đánh dấu giao dịch để đội ngũ kiểm toán hậu kỳ rà soát bất đồng bộ sau đó.

Nhờ kiến trúc hai tốc độ này, mặc dù phục vụ hơn 7,8 tỷ giao dịch mỗi năm, PayPay vẫn duy trì tỷ lệ thất thoát do gian lận ở mức kỷ lục toàn cầu: chỉ khoảng 0,0015%, thấp hơn rất nhiều so với mức trung bình của các tổ chức thẻ quốc tế.

2. Đường Ống Phát Hiện Gian Lận Thời Gian Thực: Feast & NVIDIA Triton

Để hoàn tất việc chấm điểm rủi ro trong chưa đầy 10ms, PayPay phân tách hoàn toàn tầng tính toán đặc trưng (feature engineering) khỏi logic thanh toán trực tiếp:

flowchart TD
    subgraph Ingress["Tiếp Nhận Giao Dịch Thanh Toán (EKS Gateway)"]
        REQ["Yêu Cầu Thanh Toán Đến<br/>(User, Điểm Bán, Dấu Vân Tay Thiết Bị, Số Tiền)"]
    end

    subgraph FeatureStore["Kho Đặc Trưng Thời Gian Thực: Feast Online Store"]
        REDIS_FEAT["Cụm Redis Cluster (Đọc Đặc Trưng Feast Dưới 1ms)"]
        STREAM_FEAT["Apache Flink Trên Kafka (Tính Chỉ Số Tốc Độ Trượt 15m)"]
        STREAM_FEAT --> REDIS_FEAT
    end

    subgraph ScoringEngine["Tầng Phục Vụ Suy Luận AI: NVIDIA Triton"]
        GPU_FLEET["Cụm Triton Inference Server (GPU TensorRT)"]
        MODEL1["Mô Hình 1: LightGBM Lượng Tử Hóa (1.200 Đặc Trưng Bảng)"]
        MODEL2["Mô Hình 2: Graph Neural Network (Phát Hiện Vòng Chuyển Tiền)"]
        GPU_FLEET --> MODEL1
        GPU_FLEET --> MODEL2
    end

    subgraph DecisionTier["Cỗ Máy Ra Quyết Định Rủi Ro"]
        GATE["Cổng Hành Động Rủi Ro Tự Động"]
        ACT_ALLOW["CHO PHÉP: Tiến Hành Ghi Sổ Cái TiDB (< 7ms)"]
        ACT_CHALLENGE["THỬ THÁCH: Yêu Cầu Quét Sinh Trắc Học FaceID (< 10ms)"]
        ACT_BLOCK["CHẶN ĐỨNG: Khóa Giao Dịch & Báo Động Ngay"]
    end

    REQ --> REDIS_FEAT
    REDIS_FEAT -->|Vector Đặc Trưng Float32| GPU_FLEET
    MODEL1 --> GATE
    MODEL2 --> GATE

    GATE -->|Điểm Rủi Ro < 35| ACT_ALLOW
    GATE -->|Điểm Rủi Ro 35 - 75| ACT_CHALLENGE
    GATE -->|Điểm Rủi Ro > 75| ACT_BLOCK

Các Trụ Cột Kỹ Thuật Chính

1. Kho Đặc Trưng Trực Tuyến Feast Trên Redis Cluster: Quản trị hơn 1.200 đặc trưng hành vi người dùng, bao gồm các chỉ số vận tốc giao dịch động (ví dụ: số lượng giao dịch trong 15 phút gần nhất, tổng số tiền chi tiêu trong 1 giờ qua trên các danh mục cửa hàng khác nhau). Toàn bộ các chỉ số này được tính toán trước bởi Flink và truy xuất qua Redis hash chỉ trong dưới 1 mili-giây.
2. Cụm Suy Luận NVIDIA Triton Với TensorRT: Các mô hình học máy được huấn luyện định kỳ bằng PyTorch và LightGBM, sau đó được lượng tử hóa (quantized) từ FP32 xuống INT8/FP16 bằng TensorRT. Chạy trên các node worker GPU chuyên dụng với khả năng thực thi mô hình đồng thời, Triton hoàn tất suy luận chỉ trong dưới 2,5 mili-giây.
3. Cơ Chế Phân Loại Hành Động 3 Trạng Thái:
   • CHO PHÉP (Điểm < 35): Giao dịch sạch, hệ thống chuyển tiếp ngay sang cụm TiDB để chốt sổ cái.
   • THỬ THÁCH (Điểm 35–75): Hành vi có dấu hiệu bất thường (ví dụ đột ngột mua hàng giá trị cao từ IP lạ). Ứng dụng kích hoạt bước xác thực bổ sung qua sinh trắc học thiết bị FIDO2/WebAuthn trước khi trừ tiền.
   • CHẶN ĐỨNG (Điểm > 75): Khớp với chữ ký gian lận đã biết hoặc tài khoản bị chiếm đoạt. Giao dịch bị từ chối tức thì.

3. Kiến Trúc Pipeline Đặc Trưng Hai Tốc Độ (Dual-Speed Feature Pipeline)

Đảm bảo tính đồng nhất tuyệt đối giữa dữ liệu huấn luyện ngoại tuyến (offline) và dữ liệu chấm điểm trực tuyến (online) là yếu tố sống còn nhằm triệt tiêu hiện tượng lệch pha đặc trưng (training-serving skew):

flowchart TD
    subgraph StreamingPath["Luồng Nhanh: Thu Thập Đặc Trưng Streaming (Dưới 1 Giây)"]
        KAFKA["Topic Sự Kiện Giao Dịch Apache Kafka"]
        FLINK["Apache Flink Xử Lý Luồng Có Trạng Thái"]
        REDIS["Cụm Redis Cluster (Kho Trực Tuyến Feast)"]
        KAFKA --> FLINK -->|Cửa Sổ Trượt Thời Gian Thực| REDIS
    end

    subgraph BatchPath["Luồng Chậm: Pipeline Đặc Trưng Lịch Sử Batch (Chạy Đêm)"]
        TIDB["Sổ Cái TiDB & Hồ Dữ Liệu S3"]
        SNOW["Kho Dữ Liệu Phân Tích Snowflake / DuckDB"]
        FEAST_OFF["Kho Đặc Trưng Ngoại Tuyến Feast (Parquet Trên S3)"]
        SYNC["Tác Vụ Đồng Bộ Batch Từ Ngoại Tuyến Sang Trực Tuyến"]
        
        TIDB --> SNOW --> FEAST_OFF --> SYNC --> REDIS
    end

    subgraph MLServing["Tầng Phục Vụ Suy Luận AI Thời Gian Thực"]
        ONLINE_CLI["Go 1.25 Client Chấm Điểm Gian Lận"]
        TRITON["NVIDIA Triton Inference Server"]
        
        REDIS -->|Vector Dữ Liệu Dưới 1ms| ONLINE_CLI
        ONLINE_CLI -->|Truy Vấn Suy Luận gRPC| TRITON
    end

Cơ Chế Phối Hợp Giữa Luồng Nhanh Và Luồng Chậm

• Luồng Nhanh (Streaming Fast Path): Apache Flink liên tục tiêu thụ các sự kiện thanh toán từ Kafka. Flink duy trì trạng thái bộ nhớ để tính toán các cửa sổ trượt (sliding windows) thời gian thực (chẳng hạn số lần nhập sai mã PIN trong 5 phút, tốc độ di chuyển địa lý giữa 2 lần quẹt thẻ) và ghi đè trực tiếp giá trị mới vào Redis qua Feast API sau mỗi 100ms.
• Luồng Chậm (Batch Slow Path): Các đặc trưng thống kê dài hạn phức tạp (chẳng hạn tỷ lệ khiếu nại của cửa hàng trong 90 ngày, độ biến thiên chi tiêu của người dùng trong 180 ngày) được tính toán theo lô ban đêm trên hàng chục terabyte dữ liệu. Kết quả được lưu dưới dạng Parquet trên S3 và đồng bộ vào Redis trước khung giờ mở cửa buổi sáng.

4. Mã Nguồn Golang 1.25+ Client Gọi Suy Luận Triton Đồng Thời

Dưới đây là mã nguồn Golang 1.25+ của client chấm điểm rủi ro. Chương trình sử dụng golang.org/x/sync/errgroup để lấy đặc trưng song song từ Redis, đóng gói tensor nhị phân, gọi cụm Triton qua gRPC trong ngân sách 8ms và tự động fallback về luật phòng thủ nếu phát sinh timeout:

// Package fraud triển khai client chấm điểm gian lận thời gian thực dưới 10ms trên NVIDIA Triton cho PayPay.
package fraud

import (
	"context"
	"encoding/binary"
	"errors"
	"fmt"
	"log/slog"
	"math"
	"time"

	"github.com/redis/go-redis/v9"
	"golang.org/x/sync/errgroup"
	"google.golang.org/grpc"
	"google.golang.org/grpc/codes"
	"google.golang.org/grpc/credentials/insecure"
	"google.golang.org/grpc/status"
)

type Decision string

const (
	DecisionAllow     Decision = "ALLOW"
	DecisionChallenge Decision = "CHALLENGE"
	DecisionBlock     Decision = "BLOCK"
)

type TransactionContext struct {
	TransactionSN string
	UserID        int64
	MerchantID    int64
	Amount        int64 // Yên Nhật
	DeviceID      string
	IPAddress     string
}

type FraudEvaluation struct {
	Decision   Decision
	RiskScore  float32
	IsFallback bool
	LatencyMS  float64
}

type RiskClient struct {
	logger      *slog.Logger
	redisClient *redis.Client
	tritonConn  *grpc.ClientConn
}

func NewRiskClient(logger *slog.Logger, redisClient *redis.Client, tritonTarget string) (*RiskClient, error) {
	conn, err := grpc.NewClient(
		tritonTarget,
		grpc.WithTransportCredentials(insecure.NewCredentials()),
	)
	if err != nil {
		return nil, fmt.Errorf("không thể khởi tạo gRPC client kết nối Triton: %w", err)
	}

	return &RiskClient{
		logger:      logger,
		redisClient: redisClient,
		tritonConn:  conn,
	}, nil
}

// EvaluateRisk thực hiện chấm điểm giao dịch trong ngân sách giới hạn nghiêm ngặt 8 mili-giây.
func (c *RiskClient) EvaluateRisk(ctx context.Context, tx TransactionContext) (*FraudEvaluation, error) {
	start := time.Now()
	evalCtx, cancel := context.WithTimeout(ctx, 8*time.Millisecond)
	defer cancel()

	var userVelocity map[string]string
	var deviceHistory map[string]string

	// Bước 1: Nạp song song các nhóm đặc trưng từ Redis bằng errgroup
	g, gCtx := errgroup.WithContext(evalCtx)

	g.Go(func() error {
		key := fmt.Sprintf("feast:user:velocity:%d", tx.UserID)
		val, err := c.redisClient.HGetAll(gCtx, key).Result()
		if err != nil && !errors.Is(err, redis.Nil) {
			return err
		}
		userVelocity = val
		return nil
	})

	g.Go(func() error {
		key := fmt.Sprintf("feast:device:history:%s", tx.DeviceID)
		val, err := c.redisClient.HGetAll(gCtx, key).Result()
		if err != nil && !errors.Is(err, redis.Nil) {
			return err
		}
		deviceHistory = val
		return nil
	})

	if err := g.Wait(); err != nil {
		c.logger.WarnContext(ctx, "truy xuất đặc trưng Redis chậm, kích hoạt cơ chế luật phòng thủ",
			slog.String("tx_sn", tx.TransactionSN), slog.String("error", err.Error()))
		return c.fallbackHeuristics(tx, time.Since(start)), nil
	}

	// Bước 2: Đóng gói vector đặc trưng kiểu float32
	features := c.assembleFeatureVector(tx, userVelocity, deviceHistory)

	// Bước 3: Gửi yêu cầu suy luận sang Triton qua gRPC
	score, err := c.invokeTritonInference(evalCtx, features)
	if err != nil {
		c.logger.WarnContext(ctx, "suy luận Triton bị timeout hoặc lỗi mạng, kích hoạt fallback",
			slog.String("tx_sn", tx.TransactionSN), slog.String("error", err.Error()))
		return c.fallbackHeuristics(tx, time.Since(start)), nil
	}

	duration := time.Since(start).Seconds() * 1000.0

	// Bước 4: Ánh xạ điểm rủi ro thành hành động xử lý
	var decision Decision
	if score >= 75.0 {
		decision = DecisionBlock
	} else if score >= 35.0 {
		decision = DecisionChallenge
	} else {
		decision = DecisionAllow
	}

	return &FraudEvaluation{
		Decision:   decision,
		RiskScore:  score,
		IsFallback: false,
		LatencyMS:  duration,
	}, nil
}

func (c *RiskClient) assembleFeatureVector(tx TransactionContext, velocity, device map[string]string) []float32 {
	vector := make([]float32, 4)
	vector[0] = float32(tx.Amount)
	vector[1] = 1.0 // Giá trị vận tốc mặc định
	vector[2] = 0.0 // Cờ bất thường thiết bị
	vector[3] = 1.0 // Hệ số rủi ro ngành hàng

	if val, ok := velocity["tx_count_1h"]; ok {
		var cnt float32
		if _, err := fmt.Sscanf(val, "%f", &cnt); err == nil {
			vector[1] = cnt
		}
	}
	return vector
}

func (c *RiskClient) invokeTritonInference(ctx context.Context, features []float32) (float32, error) {
	// Xây dựng buffer byte nhị phân thô cho TensorRT Triton
	buf := make([]byte, len(features)*4)
	for i, f := range features {
		binary.LittleEndian.PutUint32(buf[i*4:], math.Float32bits(f))
	}

	// Kiểm tra xem context đã hết hạn chưa trước khi gửi mạng
	if ctx.Err() != nil {
		return 0, ctx.Err()
	}

	// Tính toán điểm số suy luận mô phỏng sát thực tế
	var rawScore float32 = 0.0
	if features[0] > 100000 {
		rawScore += 40.0
	}
	rawScore += features[1] * 5.0

	return min(rawScore, 100.0), nil
}

func (c *RiskClient) fallbackHeuristics(tx TransactionContext, elapsed time.Duration) *FraudEvaluation {
	// Cơ chế luật dự phòng an toàn khi cụm AI gặp sự cố
	var score float32 = 10.0
	if tx.Amount > 150000 {
		score = 50.0 // Yêu cầu xác thực bổ sung với các giao dịch giá trị cao
	}

	decision := DecisionAllow
	if score >= 35.0 {
		decision = DecisionChallenge
	}

	return &FraudEvaluation{
		Decision:   decision,
		RiskScore:  score,
		IsFallback: true,
		LatencyMS:  elapsed.Seconds() * 1000.0,
	}, nil
}

5. Cổng Enterprise LLM Hub & Kiến Trúc RAG Tuân Thủ Đạo Luật APPI Nhật Bản

Bên cạnh bài toán an ninh thanh toán trực tiếp, PayPay xây dựng Enterprise LLM Hub nhằm tự động hóa quy trình thẩm định hồ sơ cửa hàng và rà soát pháp lý:

flowchart TD
    subgraph ClientUnits["Các Khối Nghiệp Vụ Nội Bộ"]
        MERCH_OPS["Bộ Phận Thẩm Định Điểm Bán (Giấy Phép Kinh Doanh)"]
        CUSTOMER_DISPUTE["Đội Điều Tra Tranh Chấp & Khiếu Nại Khách Hàng"]
        AUDIT_LEGAL["Ban Pháp Chế & Tuân Thủ Quy Định Ngân Hàng"]
    end

    subgraph PrivacyShield["Tấm Khiên Bảo Mật APPI Chuẩn Nhật Bản"]
        NER_MASK["Cỗ Máy Làm Mờ PII Chuyên Biệt Tiếng Nhật<br/>(Xóa My Number, Địa Chỉ, Số Tài Khoản)"]
        VAULT["Két Mật Mã Lưu Token Gốc (Mã Hóa AES-256-GCM)"]
        SEMANTIC_CACHE["Bộ Nhớ Đệm Ngữ Nghĩa (Vector DB Qdrant)"]
    end

    subgraph LLMGateway["Cổng Điều Phối Enterprise LLM & Cỗ Máy RAG"]
        ROUTER["Bộ Định Tuyến Mô Hình & Giới Hạn Tốc Độ"]
        RAG_VEC["Kho Vector Milvus<br/>(Bộ Luật Thương Mại Nhật & Danh Sách Đen Yakuza)"]
        PROMPT_BUILDER["Bộ Ghép Ngữ Cảnh & Tạo Lời Nhắc Chuẩn"]
    end

    subgraph ModelFleet["Tầng Mô Hình Ngôn Ngữ Sovereign"]
        LOCAL_LLM["Mô Hình Tự Host Llama-3-70B (VPC EKS Riêng Biệt)"]
        MANAGED_LLM["Mô Hình Quản Trị Bedrock / Claude (Zero Data Retention)"]
    end

    MERCH_OPS --> NER_MASK
    CUSTOMER_DISPUTE --> NER_MASK
    AUDIT_LEGAL --> NER_MASK

    NER_MASK <--> VAULT
    NER_MASK --> SEMANTIC_CACHE
    SEMANTIC_CACHE -->|Trường Hợp Chưa Có Cache| ROUTER

    ROUTER <--> RAG_VEC
    ROUTER --> PROMPT_BUILDER
    PROMPT_BUILDER --> LOCAL_LLM
    PROMPT_BUILDER --> MANAGED_LLM

    LOCAL_LLM --> MERCH_OPS

Các Lớp Phòng Vệ Bảo Mật Dữ Liệu Chủ Quyền

• Tự Động Làm Mờ Dữ Liệu Định Danh Cá Nhân (PII) Chuẩn APPI: Đạo luật Bảo vệ Thông tin Cá nhân của Nhật Bản (APPI) nghiêm cấm việc truyền thông tin định danh chưa che chắn ra các dịch vụ AI bên ngoài. Mô hình nhận diện thực thể đặt tên (NER) tiếng Nhật sẽ quét toàn bộ tài liệu, thay thế số thẻ My Number, số tài khoản ngân hàng và địa chỉ cư trú bằng các token thay thế mã hóa trước khi lời nhắc rời khỏi VPC.
• Thẩm Định Pháp Lý Tự Động Bằng RAG: Hồ sơ của các điểm bán mới được đối chiếu tự động với Bộ luật Thương mại Nhật Bản và danh sách các tổ chức tội phạm có tổ chức (Boryokudan) trong kho vector Milvus, rút ngắn thời gian phê duyệt hồ sơ từ 3 ngày làm việc xuống dưới 4 phút.
• Bộ Nhớ Đệm Ngữ Nghĩa (Semantic Caching): Các câu hỏi pháp lý và quy chuẩn lặp lại được lưu đệm trong Qdrant dựa trên độ tương đồng cosine (>0.94), giảm 68% chi phí gọi API mô hình lớn và trả về kết quả thẩm định dưới 50ms.

6. Đánh Đổi Kiến Trúc & Kinh Nghiệm Tối Ưu Môi Trường Sản Xuất

Vận hành hệ thống AI doanh nghiệp và học máy thời gian thực ở quy mô hàng chục triệu người dùng đòi hỏi kỷ luật kỹ thuật rất lớn:

Câu Hỏi Thường Gặp (FAQ)

📖 Bản tiếng Anh (English Edition)

Bài trước: Phần 5 — Kiến Trúc Chiến Dịch: Chống Chọi Đỉnh Tải 10 Tỷ Yên | Danh mục Series