Load test AI Agent cần kiểm tra những kịch bản nào?

Một chatbot trả lời tốt trong buổi demo với năm người thử có thể chậm hẳn, báo lỗi hoặc im lặng khi hàng trăm khách cùng nhắn trong đợt khuyến mãi. Nguyên nhân hiếm khi nằm ở một chỗ: mô hình ngôn ngữ phản hồi chậm hơn khi nhà cung cấp quá tải, API nội bộ chạm hạn mức, hàng đợi dồn ứ, kết nối bị ngắt giữa chừng. Load test là cách phát hiện những điểm gãy này trước khi khách hàng phát hiện.

Bài viết tập trung vào kiểm thử tải và hiệu năng của AI Agent, không bàn chất lượng câu trả lời. Nếu bạn cần bộ câu hỏi để chấm độ đúng của chatbot, hãy xem bài kiểm thử AI chatbot bằng bộ câu hỏi. Hai loại kiểm thử bổ sung cho nhau: một agent trả lời đúng nhưng mất nửa phút mới hiện chữ đầu tiên thì khách vẫn bỏ đi.

1. Load test AI Agent khác gì load test website

Với website thông thường, mỗi yêu cầu tốn tài nguyên tương đối đều và phản hồi trong thời gian ngắn. Với AI Agent, một lượt hỏi có thể kéo theo nhiều bước: truy xuất kho kiến thức, gọi mô hình để hiểu câu hỏi, gọi một hai công cụ đọc dữ liệu từ CRM hay hệ thống đơn hàng, rồi gọi mô hình lần nữa để soạn câu trả lời. Mỗi bước có độ trễ và giới hạn riêng, và chỉ cần một bước nghẽn là cả lượt chậm.

Điểm khác thứ hai là phụ thuộc bên ngoài. Phần tốn thời gian nhất thường là mô hình ngôn ngữ do bên thứ ba cung cấp, với hạn mức theo số yêu cầu và số token mỗi phút. Doanh nghiệp không kiểm soát được hạ tầng đó, chỉ kiểm soát được cách agent phản ứng khi chạm hạn mức. Điểm khác thứ ba là chi phí: mỗi lượt thử đều tốn tiền thật cho mô hình, nên load test cần được lên kế hoạch chứ không chạy tùy hứng.

2. Tám nhóm kịch bản cần kiểm tra

1. Lưu lượng đồng thời

Kịch bản cơ bản nhất: bao nhiêu phiên hội thoại cùng lúc thì agent vẫn phản hồi trong ngưỡng chấp nhận. Phiên thử cần giống thật, gồm nhiều lượt hỏi đáp nối tiếp với khoảng nghỉ như người gõ, trộn các loại câu hỏi theo tỷ lệ lấy từ nhật ký thật. Chỉ bắn một câu hỏi giống nhau liên tục sẽ cho kết quả đẹp hơn thực tế, vì bộ nhớ đệm trả lời hộ.

2. Độ trễ đến chữ đầu tiên

Khi câu trả lời được hiện dần từng chữ, người dùng cảm nhận tốc độ qua thời gian chờ đến chữ đầu tiên hơn là tổng thời gian. Load test cần đo riêng hai con số này, theo phân vị chứ không theo trung bình: nếu phần lớn lượt nhanh nhưng một phần nhỏ phải chờ rất lâu, trung bình vẫn đẹp mà khách vẫn phàn nàn. Lượt có gọi công cụ nên được đo tách với lượt chỉ hỏi đáp.

3. Hạn mức của mô hình và API nội bộ

Mỗi tài khoản nhà cung cấp mô hình có hạn mức theo phút. CRM, hệ thống đơn hàng hay dịch vụ nhắn tin cũng có hạn mức. Kịch bản cần đẩy tải tới gần và vượt các ngưỡng này để xem agent làm gì: thử lại có giãn cách, xếp hàng, báo khách chờ, hay báo lỗi khó hiểu. Cách thiết kế phía agent để sống chung với hạn mức được bàn riêng ở bài xử lý API rate limit khi AI Agent kết nối nhiều hệ thống; ở đây chỉ cần kiểm chứng thiết kế đó chạy đúng dưới tải.

4. Hàng đợi

Những tác vụ không cần trả lời ngay, như ghi lead vào CRM hay gửi email xác nhận, thường được đẩy vào hàng đợi. Load test cần xem hàng đợi dài ra thế nào khi tải tăng, tuổi tác vụ cũ nhất là bao nhiêu, và sau khi tải giảm thì mất bao lâu để xử lý hết. Hàng đợi không bao giờ vơi là dấu hiệu tốc độ xử lý thấp hơn tốc độ đổ vào. Muốn đi sâu vào cấu trúc bên trong, xem bài hàng đợi tác vụ cho AI Agent.

5. Timeout

Mỗi bước trong chuỗi xử lý nên có thời gian chờ tối đa. Kịch bản cần cố tình làm một phụ thuộc chậm đi, ví dụ giả lập CRM phản hồi rất chậm, rồi xem agent có cắt đúng lúc và nói với khách một câu hợp lý không. Timeout đặt quá dài khiến khách ngồi nhìn màn hình trống; đặt quá ngắn khiến lượt hợp lệ bị cắt oan khi hệ thống chỉ hơi chậm.

6. Phục hồi sau quá tải

Sau khi đẩy tải vượt ngưỡng một lúc rồi hạ xuống, hệ thống có tự trở lại bình thường không, hay cần khởi động lại. Cũng cần xem các phiên đang dở có bị mất ngữ cảnh, khách có nhận câu trả lời trùng, tác vụ ghi có bị thực hiện hai lần do thử lại. Đây là kịch bản hay bị bỏ qua nhất nhưng lại mô tả đúng nhất chuyện xảy ra trong một đợt khuyến mãi thật.

7. Chi phí lúc cao điểm

Mỗi lần chạy nên ghi lại tổng số token và số lần gọi mô hình, quy ra chi phí trên mỗi phiên và mỗi giờ cao điểm. Con số này thường khác xa ước tính ban đầu vì phiên thật dài hơn, ngữ cảnh lớn dần theo số lượt, và thử lại khi lỗi cũng tốn tiền. Kết quả nên được đưa vào phần ngân sách vận hành; cách lập khoản này có ở bài lập ngân sách AI Agent.

8. Đối chiếu với cam kết mức dịch vụ

Cuối cùng, kết quả load test cần được đặt cạnh các cam kết đã có hoặc sắp ký: độ trễ, tỷ lệ lỗi, thời gian sẵn sàng. Nếu hệ thống không đạt ở mức tải dự kiến, cần sửa trước hoặc điều chỉnh cam kết. Các chỉ số của cam kết được trình bày ở bài SLA cho AI Agent.

3. Quy trình chạy load test

Bước 1: Dựng hồ sơ tải từ dữ liệu thật

Lấy nhật ký các kênh để biết lúc đông nhất có bao nhiêu phiên, phân bố loại câu hỏi, số lượt trung bình mỗi phiên, tỷ lệ lượt phải gọi công cụ. Nếu chưa có agent, dùng số liệu của đội chăm sóc khách hàng hoặc lượt truy cập website trong các đợt cao điểm trước. Thêm các sự kiện dự kiến như chiến dịch quảng cáo lớn.

Bước 2: Chuẩn bị môi trường và dữ liệu thử

Load test nên chạy trên môi trường riêng có cấu hình gần giống thật, với tài khoản mô hình và hạn mức tách khỏi hệ thống đang phục vụ khách. Các hệ thống như CRM cần môi trường thử hoặc bản giả lập có độ trễ giống thật; tuyệt đối không bắn tải vào CRM thật hay gửi tin nhắn thật tới khách. Dữ liệu thử cần đủ đa dạng để bộ nhớ đệm không làm kết quả đẹp giả.

Bước 3: Chạy theo ba dạng tải

Chạy tăng dần để tìm ngưỡng bắt đầu chậm. Chạy giữ ở mức đỉnh dự kiến trong một khoảng đủ dài để lộ ra rò rỉ tài nguyên hay hàng đợi dồn. Chạy tăng đột ngột để mô phỏng lúc một tin quảng cáo vừa gửi đi. Mỗi lần chạy ghi lại cấu hình, phiên bản mô hình và prompt để so sánh được với lần sau.

Bước 4: Đọc kết quả và sửa đúng lớp

Khi thấy chậm hay lỗi, xác định nghẽn ở đâu: truy xuất kho kiến thức, gọi mô hình, gọi công cụ, hàng đợi hay hạ tầng của chính agent. Nhật ký có mã yêu cầu và thời gian từng bước là thứ giúp làm việc này nhanh; nội dung cần ghi có ở bài nhật ký AI Agent. Sửa xong thì chạy lại đúng kịch bản cũ để xác nhận.

4. Ví dụ giả định

Một cửa hàng thời trang trực tuyến chuẩn bị đợt giảm giá cuối tuần, dự kiến lượng chat trên website tăng vọt trong giờ đầu. Load test theo dạng tăng đột ngột cho thấy độ trễ đến chữ đầu tiên vẫn ổn, nhưng các lượt hỏi tình trạng đơn hàng chậm hẳn vì hệ thống đơn hàng giới hạn số truy vấn mỗi phút, và agent thử lại liên tục khiến tình hình tệ hơn.

Nhóm dự án thêm bộ nhớ đệm ngắn hạn cho các truy vấn tồn kho giống nhau, cho thử lại có giãn cách, và khi chạm hạn mức thì agent nói rõ với khách rằng đang tra cứu và sẽ trả lời trong giây lát thay vì báo lỗi. Chạy lại cùng kịch bản, lượt tra cứu đơn vẫn chậm hơn lượt hỏi đáp nhưng không còn lỗi. Chi phí mô hình trên mỗi phiên cao hơn dự tính vì khách giờ cao điểm hỏi nhiều lượt hơn, và con số này được đưa vào ngân sách tháng có khuyến mãi.

5. Rủi ro và giới hạn

• Bắn tải nhầm vào hệ thống thật, gửi tin nhắn hoặc tạo bản ghi thật cho khách
• Dùng mô hình giả lập toàn bộ nên không thấy độ trễ và hạn mức của nhà cung cấp thật
• Kịch bản quá đơn điệu, bộ nhớ đệm làm kết quả đẹp hơn thực tế
• Chạy một lần trước go-live rồi không chạy lại sau các thay đổi lớn

Load test cũng có giới hạn tự nhiên. Nó không dự đoán được sự cố của nhà cung cấp mô hình, và môi trường thử dù giống đến đâu vẫn khác môi trường thật ở vài chỗ. Vì vậy kết quả load test nên đi cùng phương án khi quá tải thật: chuyển khách sang biểu mẫu để lại thông tin, hiện thông báo chờ, hoặc chuyển nhân viên. Load test cũng tốn chi phí mô hình, nên cần ước tính và duyệt trước mỗi đợt chạy lớn.

6. Phân chia trách nhiệm

Đội kỹ thuật hoặc đơn vị triển khai thiết kế kịch bản, dựng môi trường, chạy và phân tích kết quả. Bộ phận nghiệp vụ, thường là chăm sóc khách hàng hoặc marketing, cung cấp số liệu cao điểm và lịch các chiến dịch sắp tới, đồng thời quyết định độ trễ nào là chấp nhận được với khách. Người quản lý ngân sách duyệt chi phí chạy thử và xem con số chi phí lúc cao điểm.

Chủ các hệ thống được agent gọi, như CRM hay hệ thống đơn hàng, cần được báo trước và xác nhận hạn mức thật của hệ thống mình. Nhiều trường hợp nghẽn nằm ở đây chứ không ở agent, và chỉ chủ hệ thống mới nâng được hạn mức hoặc mở thêm năng lực đọc.

7. Chỉ số cần ghi trong mỗi lần chạy

• Độ trễ đến chữ đầu tiên và tổng thời gian, theo phân vị và theo loại lượt
• Tỷ lệ lỗi tách theo nguyên nhân: hạn mức, timeout, lỗi mô hình, lỗi công cụ
• Độ dài và tuổi hàng đợi trong lúc tải cao và thời gian xả hết sau đó
• Chi phí mô hình trên mỗi phiên và mỗi giờ cao điểm

Ghi chỉ số theo cùng một mẫu cho mọi lần chạy để so được giữa các phiên bản. Một bảng so sánh trước và sau mỗi thay đổi lớn, như đổi mô hình hay thêm công cụ, thường đủ để phát hiện suy giảm hiệu năng trước khi khách phản ánh.

8. Checklist trước khi go-live

• Hồ sơ tải dựng từ dữ liệu cao điểm thật, có biên cho chiến dịch
• Môi trường thử tách biệt, tài khoản mô hình và hạn mức riêng
• Đã chạy đủ ba dạng: tăng dần, giữ đỉnh, tăng đột ngột
• Đã thử phụ thuộc chậm, chạm hạn mức và phục hồi sau quá tải
• Không có tác vụ ghi trùng hay lẫn dữ liệu giữa các phiên dưới tải
• Chi phí lúc cao điểm đã đưa vào ngân sách vận hành
• Có phương án cho khách khi quá tải thật

9. Câu hỏi thường gặp

Load test AI Agent có cần gọi mô hình ngôn ngữ thật không? Có, ít nhất ở một phần các lần chạy. Giả lập mô hình giúp thử phần hạ tầng rẻ hơn, nhưng độ trễ, hạn mức và lỗi của nhà cung cấp mô hình chỉ lộ ra khi gọi thật. Nên dùng tài khoản và hạn mức riêng cho việc thử để không ảnh hưởng hệ thống đang chạy.

Nên thử với mức tải bao nhiêu? Lấy lưu lượng lúc đông nhất mà doanh nghiệp từng ghi nhận trên các kênh, cộng thêm biên cho các đợt khuyến mãi hoặc chiến dịch dự kiến, rồi thử vượt mức đó để biết hệ thống gãy ở đâu. Con số cụ thể phụ thuộc dữ liệu thật của từng doanh nghiệp.

Load test khác kiểm thử chất lượng câu trả lời thế nào? Kiểm thử chất lượng hỏi agent trả lời có đúng không. Load test hỏi khi nhiều người hỏi cùng lúc, agent có còn trả lời kịp, không lỗi, không lẫn dữ liệu giữa các phiên và không đốt chi phí vượt dự tính hay không. Hai loại cần làm riêng.

Khi nào cần chạy lại load test? Khi đổi mô hình hoặc nhà cung cấp mô hình, thêm công cụ hay hệ thống được gọi trong mỗi lượt, mở thêm kênh, hoặc trước một sự kiện dự kiến kéo lưu lượng tăng mạnh. Thay đổi prompt làm câu trả lời dài hơn cũng có thể làm độ trễ và chi phí đổi đáng kể.

Kết luận

Load test AI Agent không chỉ đo xem hệ thống chịu được bao nhiêu người, mà tìm ra bước nào gãy trước và agent cư xử ra sao khi gãy. Kịch bản tốt dựa trên dữ liệu cao điểm thật, gọi mô hình thật trong môi trường tách biệt, và luôn đo cả chi phí. Chạy một lần trước go-live và chạy lại sau mỗi thay đổi lớn là đủ để tránh phần lớn những bất ngờ trong ngày đông khách.

Trao đổi với Naventic để lên kịch bản load test cho chatbot trước đợt cao điểm. Đọc thêm: AI Chatbot doanh nghiệp.