Giả lập người dùng: cách test agent hội thoại nhiều lượt trước khi giao cho khách

Thử hình dung tuần cuối trước khi bàn giao. Agent đổi trả hàng bạn dựng cho khách đã vượt qua toàn bộ hai trăm cặp câu hỏi–đáp mẫu. Rồi một nhân viên bên khách ngồi thử, gõ “tôi muốn đổi giày”, và đến lượt thứ ba thì agent hỏi lại mã đơn mà người đó vừa đưa.

Lỗi kiểu này không nằm trong câu trả lời nào riêng lẻ. Nó chỉ xuất hiện khi cuộc trò chuyện kéo dài, khi người dùng trả lời thiếu ý, đổi ý hoặc sốt ruột. Đó là lý do một FDE làm agent hội thoại cần thêm một kỹ năng: dựng người dùng giả lập để “phỏng vấn” agent hàng trăm lần trước khi khách thật đụng vào.

Vì sao bộ test tĩnh không đủ?

Đội Strands Evals nói thẳng rằng một bộ dữ liệu tĩnh gồm các cặp đầu vào–đầu ra, dù lớn đến đâu, cũng không bắt được tính động của hội thoại.

Tin nhắn tiếp theo của người dùng phụ thuộc vào điều agent vừa nói. Nếu agent hỏi sai câu, người thật sẽ trả lời khác, và mọi lượt phía sau đều rẽ sang một nhánh mà bộ test mẫu không lường trước.

Vì thế cần một bên đối thoại biết phản ứng. τ-bench, benchmark do Sierra công bố, làm đúng việc này: một mô hình ngôn ngữ đóng vai người dùng, trò chuyện với agent có quyền gọi các API nghiệp vụ. Sierra mô tả bộ giả lập là một LLM được dẫn dắt bằng chỉ dẫn riêng cho từng kịch bản.

Một người dùng giả lập cần gì?

Thứ đầu tiên là mục tiêu, và mục tiêu phải giấu. Tian Pan, khi viết về người dùng tổng hợp để đánh giá agent nhiều lượt, nhấn mạnh rằng không được nói trước mục tiêu cho agent; agent phải tự khai thác nó qua hội thoại. Đây chính là kỹ năng bạn muốn test, nên đừng vô tình đưa sẵn đáp án vào system prompt của agent.

Thứ hai là persona nhất quán. Strands Evals yêu cầu người dùng giả lập giữ cùng phong cách giao tiếp, trình độ chuyên môn và tính cách từ đầu đến cuối. Một “khách lớn tuổi ít dùng app” mà đến lượt năm bỗng viết như kỹ sư thì kịch bản đó đã hỏng.

Thứ ba là biết khi nào dừng. Strands Evals theo dõi mục tiêu của người dùng giả lập song song với cuộc trò chuyện để biết lúc nào nên kết thúc. Tian Pan bổ sung một điều hay bị quên: người thật có sức kiên nhẫn hữu hạn.

Một bộ giả lập quá kiên nhẫn sẽ làm agent trông như đúng ở những đường đi mà khách thật đã bỏ cuộc từ lâu, nên cần một “ngân sách kiên nhẫn”.

Ví dụ: agent đổi trả của một chuỗi bán lẻ

Giả sử khách của bạn là một chuỗi bán giày, agent có quyền tra đơn, đổi size và hoàn tiền. Một kịch bản giả lập có thể viết như sau:

SCENARIO = {
    "persona": "Khách 50 tuổi, ít dùng app, trả lời ngắn, dễ sốt ruột",
    "hidden_goal": "Đổi đôi giày trong đơn W1234 sang size 42; "
                   "nếu hết size 42 thì hoàn tiền về thẻ",
    "reveal_rules": "Chỉ đưa mã đơn khi agent hỏi; không tự nói size cũ",
    "patience_turns": 6,
    "expected_db": {"W1234": {"status": "exchanged", "size": 42}},
}

Mục tiêu ẩn chỉ có bộ giả lập biết. Quy tắc tiết lộ buộc agent phải hỏi đúng câu. Ngân sách sáu lượt nghĩa là nếu agent vòng vo, khách giả sẽ nói “thôi, để tôi gọi tổng đài” và kết thúc. Đoạn code cho một lần chạy thử chỉ cần vài dòng:

def run_episode(agent, sim, scenario, db):
    msg = sim.start(scenario)
    for _ in range(scenario["patience_turns"]):
        reply = agent.respond(msg, db)   # agent có thể gọi API, ghi vào db
        msg, done = sim.next(reply)      # sim tự kiểm mục tiêu đã đạt chưa
        if done:
            break
    return db.snapshot() == scenario["expected_db"]

Dòng cuối là quan trọng nhất. Agent có thể viết “Tôi đã đổi size cho anh rồi ạ” rất lịch sự trong khi database không có gì thay đổi. τ-bench chấm bằng cách so trạng thái database sau mỗi tác vụ với kết quả mong đợi, và bạn nên làm y như vậy.

Một lần qua chưa phải là qua

Chạy kịch bản trên một lần và thấy đúng thì chưa nói lên nhiều điều. Sierra dùng chỉ số pass^k để đo độ tin cậy, tức là agent có hoàn thành cùng một tác vụ qua nhiều lần chạy hay không.

Kết quả trong bài báo τ-bench khá đáng ngại: ngay cả agent gọi hàm hàng đầu như GPT-4o cũng thành công dưới 50% số tác vụ, và pass^8 ở miền retail dưới 25%.

Thử làm một phép tính để thấy vì sao con số này tụt nhanh. Nếu một kịch bản thành công ngẫu nhiên 60% mỗi lần và các lần chạy độc lập, xác suất qua cả 8 lần là 0,6 mũ 8, khoảng 1,7%. Một agent “thường thì đúng” vẫn gần như chắc chắn sẽ hỏng với ai đó trong ngày đầu go-live.

Làm ở site khách thế nào?

Bắt đầu từ năm đến mười luồng nghiệp vụ mà khách quan tâm nhất, lấy từ buổi discovery hoặc log tổng đài. Với mỗi luồng, viết một kịch bản có mục tiêu ẩn, persona, quy tắc tiết lộ, ngân sách kiên nhẫn và trạng thái database mong đợi. Nên thêm vài persona khó: người đổi ý giữa chừng, người đưa thông tin sai, người hỏi ngoài phạm vi.

Sau đó chạy mỗi kịch bản k lần trên một bản sao database được reset trước mỗi lần. Báo cáo cho khách cả tỷ lệ thành công lẫn pass^k, kèm vài transcript thất bại tiêu biểu. Transcript làm khách hiểu nhanh hơn mọi biểu đồ, và chúng cũng là danh sách việc cần sửa cho tuần tới.

Ba cái bẫy hay gặp

Cái bẫy đầu tiên là giả lập quá ngoan, như đã nói ở trên: thiếu ngân sách kiên nhẫn thì mọi đường vòng đều trông như thành công. Cái bẫy thứ hai tinh vi hơn.

Tian Pan cảnh báo rằng khi bộ giả lập và agent dùng cùng loại mô hình, bài đánh giá biến thành “phòng gương”: hai bên trò chuyện rất trôi chảy nhưng chẳng giống người thật chút nào.

Cái bẫy thứ ba là tin rằng bộ giả lập đã giống người thật mà không kiểm chứng. Một bài báo trên arXiv tháng 05/2026 đề xuất khung realsim để so người dùng giả lập với hội thoại thật theo góc nhìn phân phối, chứ không so từng câu. Trước mỗi đợt chạy, bạn có thể rà nhanh bằng bảng sau:

Bẫy	Kiểm tra trước khi chạy
Giả lập quá kiên nhẫn	Mỗi kịch bản đã có ngân sách lượt và câu bỏ cuộc chưa?
Phòng gương	Vai người dùng có dùng mô hình khác, hoặc ít nhất prompt rất khác agent không?
Giả lập không giống người thật	Đã so transcript giả lập với transcript thật về độ dài tin nhắn, số lượt và lúc bỏ cuộc chưa?

Đưa kỹ năng này vào CV

Trên CV, hãy mô tả kỹ năng này bằng một dòng cụ thể thay vì lời giới thiệu chung chung, chẳng hạn: “Xây bộ đánh giá bằng người dùng giả lập cho 10 luồng đổi trả, chấm bằng trạng thái database, đưa pass^8 từ X lên Y”.

Khi đi phỏng vấn, nên chuẩn bị sẵn một transcript thất bại (đã ẩn thông tin) và kể bạn đã tìm ra lỗi thế nào, sửa gì, pass^k thay đổi ra sao. Một câu chuyện có số đo trước và sau sẽ thuyết phục hơn mọi danh sách công cụ.

Khách hàng sẽ không nhớ agent của bạn đạt bao nhiêu điểm trên bộ test mẫu. Họ sẽ nhớ lần đầu tiên nó hỏi lại mã đơn họ vừa đưa, và tốt nhất là bạn đã gặp lỗi đó trước họ, trong một transcript giả lập.