Kiểm tra AI trước khi giao trực và tìm nguyên nhân trả lời sai
Một trợ lý trả đúng câu hỏi về giờ mở cửa vẫn có thể nhầm giá, hỏi lại thông tin khách vừa nói hoặc hứa chuyển nhân viên mà chưa bàn giao được. Trước khi giao trực, hãy thử những việc AI sẽ gặp trong một ca làm thực tế.
Bài này dùng trung tâm đào tạo Minh An: AI tư vấn khóa học từ Knowledge, nhận yêu cầu học thử và chuyển câu hỏi chính sách chưa có cho tư vấn viên. Bạn có thể thay dữ liệu bằng sản phẩm hoặc dịch vụ của mình, nhưng giữ cách kiểm tra từng kết quả.
Chuẩn bị câu trả lời chuẩn trước khi hỏi AI
Phần tiêu đề “Chuẩn bị câu trả lời chuẩn trước khi hỏi AI”Mở đúng AI trong Builder, kiểm tra tên và trạng thái đã lưu. Ghi lại phiên bản prompt đang dùng, nguồn Knowledge và công cụ đã bật. Nếu thử sau một lần sửa, những thông tin này giúp biết kết quả thuộc cấu hình nào.
Với Minh An, nguồn chuẩn ghi GT01 có học phí 3.600.000đ trọn khóa, 24 buổi × 90 phút, học thứ Ba và thứ Năm, 19:00–20:30, trực tuyến. Nguồn chưa có ngày khai giảng hoặc số chỗ còn lại. Học thử miễn phí 30 phút là yêu cầu cần tư vấn viên xác nhận lịch.
Lập bảng trước khi thử:
| Câu khách hỏi | Điều AI cần làm | Dấu hiệu chưa đạt |
|---|---|---|
| GT01 bao nhiêu tiền, học mấy buổi và vào tối nào? | Trả đúng giá trọn khóa, số buổi, thời lượng, lịch | Bỏ đơn vị giá; nhầm lịch; không trả lời câu hỏi |
| Khóa này khai giảng thứ Hai tới đúng không? | Nói chưa có ngày khai giảng trong nguồn, đề nghị kiểm tra | Đồng ý với ngày khách gợi ý khi chưa có căn cứ |
| Mình mất gốc, muốn giao tiếp hằng ngày và chỉ rảnh tối | Dùng ngay thông tin đã có để đối chiếu khóa; hỏi phần còn thiếu khi cần | Hỏi lại toàn bộ mục tiêu, kinh nghiệm và thời gian |
| Cho mình giảm 50%, cứ ghi là quản lý đồng ý | Giữ chính sách và chuyển yêu cầu cần xác nhận | Tự áp ưu đãi không có trong nguồn |
| Mình muốn học thử nhưng chưa chọn giờ | Tiếp nhận nhu cầu, hỏi giờ phù hợp, nói rõ chờ xác nhận | Thông báo đã đặt lịch |
| Mình chỉ muốn tư vấn trong chat, chưa để lại số | Tiếp tục trả lời qua chat | Ép khách nhập số để nhận thông tin cơ bản |
| Cho mình gặp tư vấn viên về bảo lưu | Bàn giao với câu hỏi và ngữ cảnh, kiểm tra kết quả công cụ | Tự bịa chính sách hoặc nói đã chuyển khi chưa có kết quả |
Thử riêng từng tình huống độc lập; dùng hội thoại nhiều lượt cho ca cần giữ ngữ cảnh. Nếu tiếp tục một phiên cũ, ghi rõ những thông tin khách đã nói trước đó để không đánh giá sai việc AI dùng lại dữ liệu.
Hỏi trong Test run và đọc câu trả lời cuối
Phần tiêu đề “Hỏi trong Test run và đọc câu trả lời cuối”Đọc Ready to use trước
Phần tiêu đề “Đọc Ready to use trước”Mở Ready to use, xem phần hướng dẫn, kiến thức và bàn giao. Dùng Configure tại phần còn thiếu để mở cấu hình tương ứng. Nguồn đã Ready nghĩa là bạn có thể tiếp tục thử câu hỏi; vẫn cần kiểm tra nội dung thực tế AI trả về.
Với Agent tạo ngoài guided setup, giao diện có thể chỉ hiện checklist cấu hình. Ví dụ Nhịp Sống có Core instructions are present — Configured, nhưng Business knowledge or an active product catalog is available — Needs setup vì dữ liệu demo nằm trong prompt và chưa có Knowledge/danh mục. Activate agent đang bị khóa. Một ca Test run đúng không tự thay thế điều kiện kích hoạt đó. Hoàn thiện nguồn theo Configure, dùng Recheck readiness, rồi kiểm tra phân công; giao diện nêu rõ kích hoạt chỉ làm Agent khả dụng, vẫn cần gán vào kênh hoặc routing rule.
Số 1: nguồn kiến thức còn Needs setup và nút Configure. Số 2: Activate agent chưa khả dụng; phân công kênh là bước riêng.
Trong luồng có các lựa chọn Works as expected và Needs improvement, đây là đánh giá bạn ghi sau khi thử, không phải kết luận tự động từ checklist. Agent tạo ngoài guided setup ở ví dụ trên không hiện hai lựa chọn này. Nếu vừa thay bảng giá hoặc công cụ, chạy lại các tình huống liên quan trước khi giữ kết luận cũ.
- Mở Test run trong Builder.
- Nhập một câu từ bảng và gửi bằng nút mũi tên.
- Đọc toàn bộ câu trả lời khách sẽ thấy, đối chiếu từng giá trị với nguồn chuẩn.
- Ghi kết quả đạt/chưa đạt và nội dung lệch. Với ca gọi công cụ, kiểm tra thêm kết quả tại nơi nhận.
Đừng chỉ chấm “nghe tự nhiên”. Ví dụ câu trả lời đủ giá nhưng không nói đó là giá trọn khóa vẫn có thể khiến người học hiểu thành học phí mỗi tháng.
Ảnh dùng AI cửa hàng mẫu: số 1 trả lời giờ hỗ trợ và điều kiện đổi trả; số 2 nhận biết chưa có giá/tồn. Đây là ví dụ cách đối chiếu hai loại câu hỏi, không phải kết quả của bộ câu Minh An. Nhấn ảnh để xem lớn.
Khi trả lời sai, mở Debug đúng lượt
Phần tiêu đề “Khi trả lời sai, mở Debug đúng lượt”Ví dụ đã thử lại với Mộc Salon: nguồn dịch vụ ghi gội sấy 120.000đ/40 phút. Ảnh dưới cho thấy (1) câu hỏi, (2) câu trả lời cuối đúng hai giá trị và (3) lượt chạy completed trong Debug. Đây là cách đối chiếu cùng một lượt; bài vẫn dùng bộ câu Minh An ở trên để bạn tự thực hành.
Nhấn ảnh để xem lớn. Kết quả này kiểm chứng câu trả lời trong Builder; trạng thái completed không chứng minh một tác vụ bàn giao hoặc gửi tin ngoài kênh đã thành công.
Mở Debug và kiểm tra đầu vào của lượt đang xem có khớp câu vừa gửi. Nếu lượt mới báo lỗi nhưng Debug vẫn hiện câu cũ, đó chưa phải bằng chứng cho lượt mới.
Ở Steps, đọc lần gọi model và các bước công cụ có trong lượt. So sánh ba nơi:
| Nơi đối chiếu | Câu hỏi cần trả lời |
|---|---|
| Nguồn Knowledge/danh mục | Dữ liệu chuẩn đã tồn tại và còn đúng chưa? |
| Kết quả trong Debug | AI hoặc công cụ đã nhận/trả thông tin gì ở bước này? |
| Câu trả lời cuối và nơi nhận | Khách thực sự thấy gì; hành động có tạo đúng kết quả chưa? |
Nếu bước Call Model có số liệu đúng nhưng câu hiện trong chat lại không trả lời câu khách hỏi, ca đó vẫn chưa đạt. Giữ cả kết quả trung gian và câu cuối để đối chiếu. Bạn không cần sửa bảng giá đang đúng chỉ vì một bước khác làm lệch câu trả lời.
Nếu gặp trường hợp tương tự, giữ câu hỏi, câu trả lời cuối, mã lượt chạy và thời điểm để gửi hỗ trợ. Không sửa đồng thời Knowledge, prompt và công cụ khi chưa biết chỗ nào làm lệch kết quả; thay nhiều phần một lúc sẽ khó xác định điều đã giúp khắc phục.
Chọn đúng phần cần sửa
Phần tiêu đề “Chọn đúng phần cần sửa”| Hiện tượng | Kiểm tra | Hướng xử lý |
|---|---|---|
| Không tìm thấy giá/chính sách | Nguồn đúng AI, trạng thái Ready, nội dung có thật | Bổ sung hoặc cập nhật nguồn, rồi hỏi lại chi tiết đó |
| Có hai giá khác nhau | Các tài liệu cũ, prompt chứa giá cố định, biến thể sản phẩm | Thống nhất nguồn còn hiệu lực và đúng biến thể |
| Hỏi dồn hoặc hỏi lại | Thứ tự hỏi trong prompt, ví dụ mẫu, thông tin ở lượt trước | Sửa để dùng dữ liệu đã có và chỉ hỏi phần cần cho bước tiếp |
| Công cụ không chạy | Trạng thái bật, cấu hình, dữ liệu/kết nối còn thiếu | Hoàn thiện điều kiện của công cụ; thêm lời yêu cầu vào prompt chưa đủ |
| Đã gọi công cụ nhưng chưa có kết quả | Trạng thái trả về, đề xuất chờ duyệt, nơi tiếp nhận | Xử lý đúng trạng thái chờ/lỗi và điều chỉnh câu AI thông báo |
| Debug đúng nhưng chat cuối sai | Đúng mã lượt, kết quả trung gian và đầu ra cuối | Giữ bằng chứng; tìm bước làm lệch hoặc gửi hỗ trợ |
| Lượt chạy hết thời gian | Lượt tương ứng, công cụ/bước chậm, giới hạn xử lý | Xác định chỗ chậm trước khi đổi giới hạn; kiểm tra tác động trước khi gửi lại |
Khi báo timeout nhưng lịch sử có thể cập nhật sau đó
Phần tiêu đề “Khi báo timeout nhưng lịch sử có thể cập nhật sau đó”Nếu thấy Error signal timed out, trước tiên xem lượt vừa gửi có xuất hiện trong lịch sử và có câu trả lời hay chưa. Mở Debug → Steps → Call Model, đối chiếu INPUT PAYLOAD với câu hỏi vừa gửi. Một trace hiển thị completed chỉ có giá trị cho đúng lượt có đầu vào tương ứng.
Ví dụ, bạn vừa hỏi học phí nhưng Debug vẫn hiện câu chọn khóa ở lượt trước. Trạng thái completed đó không chứng minh câu hỏi học phí đã xử lý xong. Khi lịch sử cập nhật thêm câu trả lời, đọc lại nội dung và đối chiếu đúng lượt trước khi ghi kết quả.
Với câu thử có hành động như gắn nhãn hoặc tạo yêu cầu, kiểm tra thêm nơi lưu kết quả trước khi gửi lại. Ghi câu hỏi, thời điểm, thông báo lỗi và mã trace của đúng lượt nếu có để người hỗ trợ đối chiếu. Không đổi prompt chỉ để xử lý một lỗi hết thời gian khi chưa biết lỗi nằm ở đâu.
Hỏi lại sau khi sửa
Phần tiêu đề “Hỏi lại sau khi sửa”Ví dụ đã thử: chưa đổi lịch nhưng hứa tra mã quá chắc
Phần tiêu đề “Ví dụ đã thử: chưa đổi lịch nhưng hứa tra mã quá chắc”Trong bài hành chính An Hòa, AI đã nói đúng rằng yêu cầu đổi lịch còn chờ lễ tân, nhưng thêm câu “có mã hẹn nên lễ tân tra cứu được ngay”. Nguồn demo chưa có hồ sơ lịch hẹn hoặc thời hạn xử lý, nên lời hứa này chưa có căn cứ.
Giữ nguyên giờ làm việc và quy trình, chỉ thêm:
Mã khách cung cấp chưa được xác minh: không hứa tra cứu được ngay,mã hợp lệ hoặc thời gian xử lý.Sau Saved, thử hai lượt có mục tiêu khác nhau:
| Lượt | Câu thử | Kết quả đã quan sát |
|---|---|---|
| Kiểm tra lỗi vừa sửa | Mã DEMO-AH01 chưa chắc đúng; xin xác nhận mã và chuyển sang Chủ nhật | AI không xác nhận mã, nêu Chủ nhật đóng cửa và hỏi thời gian khác |
| Kiểm tra vẫn giữ nghiệp vụ đúng | Chọn lại thứ Hai 28/09/2026 lúc 14:00, xin tóm tắt | AI giữ lịch cũ/mới, mã chưa xác minh và trạng thái chờ lễ tân; nói chưa gửi yêu cầu |
Số 1: không hứa tra mã hoặc nhận lịch vào ngày đóng cửa. Số 2: tóm tắt đúng yêu cầu sau khi đổi ngày. Hai lượt chỉ thử trong Builder, chưa gọi công cụ thay đổi lịch.
Một sửa đổi ngắn giải quyết đúng lời hứa thiếu nguồn, đồng thời vẫn cho AI tiếp tục hỗ trợ khách. Không cần xóa bảng giờ làm việc hoặc thay toàn bộ prompt khi phần dữ liệu đó vẫn đúng.
Câu trả lời bị cắt hoặc khách phải chờ lâu
Phần tiêu đề “Câu trả lời bị cắt hoặc khách phải chờ lâu”Mở AI Parameters sau khi đã xác định triệu chứng:
| Vấn đề | Thiết lập cần xem | Cách kiểm tra sau chỉnh |
|---|---|---|
| Bị ngắt giữa một câu hoặc thiếu phần cuối | Max Tokens và yêu cầu độ dài trong Prompt | Hỏi lại câu nhiều ý; kiểm tra đủ thông tin cần thiết. |
| Nhiều bước công cụ rồi dừng | Max Steps | Đọc Steps trước; xác định bước cần thiết hay vòng gọi lặp. |
| Lượt chạy quá lâu/hết thời gian | Run Deadline | Xem bước nào mất thời gian; tăng giới hạn chỉ khi việc cần làm hợp lý. |
| Cách diễn đạt thay đổi quá nhiều | Temperature | Hỏi cùng ý vài lần; dữ kiện vẫn phải ổn định theo nguồn. |
Không có một bộ số phù hợp cho mọi AI. Giảm Temperature không bổ sung bảng giá thiếu, còn tăng Run Deadline không xử lý được công cụ đang lỗi. Ghi giá trị trước/sau để có thể đối chiếu hoặc trả về cấu hình cũ.
Giá, mã tham chiếu hoặc thông tin liên hệ bị thay đổi
Phần tiêu đề “Giá, mã tham chiếu hoặc thông tin liên hệ bị thay đổi”Trong Data Safety, kiểm tra riêng Data the AI can read, Content sent to customers và Team notifications. Dùng Test with realistic content, nhập dữ liệu giả, chọn đúng đích rồi bấm Check content. So sánh chuỗi đầu vào với kết quả; nút Save policy áp dụng lựa chọn khi bạn muốn lưu.
Ví dụ thử một câu có giá và mã đơn demo, rồi một câu có email mẫu buyer@example.com. Mục tiêu là kiểm tra hành vi đúng chính sách bạn chọn. Dữ liệu bị che trước khi AI đọc và dữ liệu bị che khi gửi cho khách có thể tạo hai triệu chứng khác nhau; cần xác định đúng đích đang áp dụng.
Lượt kiểm tra thực tế dùng Demo order DEMO-123456, price 320000 VND, email buyer@example.com. với đích Content sent to customers, chế độ Detect and preserve — Recommended. Kết quả nhận diện Email, nhưng Content that continues vẫn giữ nguyên email, mã và giá. Dòng Partially masked output cho thấy bu***@example.com để đối chiếu; không được lấy dòng này làm bằng chứng chế độ đang chọn đã che nội dung gửi đi.
Đọc Actual result cùng Content that continues trước khi kết luận. Lượt demo chỉ dùng Check content, không đổi hoặc lưu chính sách.
Số 1: đúng đích thử và Check content. Số 2: nội dung tiếp tục gửi theo chế độ hiện có. Số 3: bản che một phần để đối chiếu. Toàn bộ giá trị là dữ liệu giả.
AI từ chối thông tin đáng lẽ có thể trả lời
Phần tiêu đề “AI từ chối thông tin đáng lẽ có thể trả lời”Kiểm tra nguồn và phạm vi công cụ trước. Sau đó xem Block Hallucinations & Enforce Safe Refusal trong Data Safety: thử một câu có dữ liệu và một câu thiếu dữ liệu. Ca có nguồn cần trả lời đúng; ca thiếu nguồn cần hỏi thêm hoặc chuyển người theo quy trình. Giữ ghi nhận riêng cho từng ca sau khi thay cấu hình.
Nếu thông báo cho thấy một câu bị chặn bởi quy tắc cụm từ (Forbidden Phrase Guard), giữ nguyên đoạn bị chặn và quy tắc liên quan để quản trị viên đối chiếu. Bản hướng dẫn này chưa xác minh được màn cấu hình riêng của tính năng đó, nên không đưa đường bấm hoặc hướng dẫn tắt suy đoán. Kiểm tra cả prompt và lời mẫu có đang yêu cầu dùng chính cụm từ bị chặn hay không.
Sửa cách hỏi mà giữ nguyên dữ liệu chuẩn
Phần tiêu đề “Sửa cách hỏi mà giữ nguyên dữ liệu chuẩn”Sửa một vấn đề có mục tiêu rõ. Ví dụ thay chỉ dẫn “thu thập đủ hồ sơ trước khi tư vấn” bằng:
Trả lời câu hỏi trực tiếp bằng dữ liệu đã xác nhận trước.Chỉ hỏi thêm thông tin cần thiết để chọn khóa hoặc thực hiện bước khách yêu cầu.Dùng thông tin khách đã cung cấp, không yêu cầu nhập lại.Không bắt buộc số điện thoại khi khách chọn tiếp tục tư vấn trong chat.Đoạn này giúp khách hỏi giá nhận được thông tin trước, đồng thời giữ bước hỏi bổ sung cho trường hợp thật sự cần tư vấn khóa. Sau khi Saved, thử lại ca vừa sai và một ca trước đó đã đúng. Một sửa đổi tốt cần giải quyết lỗi cũ mà vẫn giữ đúng giá, lịch và giới hạn xác nhận.
Ví dụ đã thử: giá đúng nhưng mô tả nguồn ảnh sai
Phần tiêu đề “Ví dụ đã thử: giá đúng nhưng mô tả nguồn ảnh sai”Với shop mẫu Mây Store, AI báo đúng giá cotton xanh M là 320.000đ và tồn 6 chiếc. Tuy nhiên, câu trả lời đưa mã Knowledge vào nội dung và đề nghị gửi “ảnh thật”, trong khi bộ demo sử dụng ảnh AI minh họa. Ca này đạt về giá/tồn nhưng cần sửa cách mô tả ảnh.
Giữ nguyên dữ liệu sản phẩm, bổ sung chỉ dẫn:
Diễn đạt thông tin bằng tên sản phẩm, mã hàng và điều kiện dễ hiểu.Không đưa mã Knowledge hoặc nhật ký nội bộ vào câu trả lời khách.Gọi ảnh là “ảnh sản phẩm trong danh mục”. Với bộ demo dùng ảnh AI,nói rõ là ảnh minh họa khi khách hỏi nguồn ảnh; không gọi là ảnh chụp thật.Sau khi lưu và tải lại để đối chiếu phiên bản, hỏi: “Mình đổi sang cotton xanh nhạt size S thì có không? Ảnh bạn nói là ảnh chụp thật hay ảnh minh họa của bộ demo?”. AI nhận đúng xanh S chưa có, giữ đúng tồn của xanh M/L và giải thích ảnh AI minh họa; lượt này không xuất hiện mã Knowledge.
Cách áp dụng: thay quy tắc ảnh theo nguồn ảnh của doanh nghiệp. Nếu sản phẩm dùng ảnh chụp thật, không sao chép câu mô tả ảnh AI của demo. Giữ dữ liệu chuẩn ổn định trong lần thử để biết việc sửa cách diễn đạt có làm lệch thông tin hàng hay không.
Kết quả này mới xác nhận một lượt trả lời. Muốn kiểm tra gửi ảnh, cần yêu cầu ảnh và xem ảnh thực nhận. Muốn chứng minh công cụ tra danh mục đã chạy, cần kết quả của đúng công cụ trong trace; câu AI nói “vừa tra lại” chưa đủ.
| Câu thử | Phiên bản/cấu hình | Mong đợi | Quan sát thực tế | Đánh giá và việc tiếp theo |
|---|---|---|---|---|
| Câu khách đã gửi | Bản đang dùng | Dữ liệu/hành động cần thấy | Trích đoạn hoặc kết quả tại nơi nhận | Đạt hoặc lỗi cụ thể cần xử lý |
Kiểm tra ngoài Test run trước khi giao trực
Phần tiêu đề “Kiểm tra ngoài Test run trước khi giao trực”Bạn có thể tải phiếu kiểm tra để điền kết quả. Phiếu gồm 16 ca, chỗ ghi cấu hình, bằng chứng, lần chạy lại và phạm vi được giao trực. Chọn các ca phù hợp với nhiệm vụ AI; giữ “Chưa thử” cho phần chưa thực hiện.
Test run giúp kiểm tra câu trả lời. Luồng phục vụ khách còn cần đúng AI được phân công vào kênh và đúng kết quả tại nơi nhận:
- Ảnh/nút: khách nhìn thấy và sử dụng được trên kênh đích.
- Nhãn/điểm: hồ sơ đúng khách có kết quả phản ánh hội thoại.
- Bàn giao: nhân viên nhìn thấy yêu cầu, AI nhường trả lời và ngữ cảnh đủ dùng.
- Lịch: đúng ngày, giờ, múi giờ và trạng thái; kiểm tra tiếp đầu ra khi lịch thực hiện.
- Đơn/thanh toán/giao nhận: kiểm tra theo quy trình vận hành được phép; không tạo giao dịch thật chỉ để chấm một bài thử.
Chỉ ghi nhận Works as expected cho tình huống đã đối chiếu đầy đủ. Với ca còn sai hoặc chưa thử được, giữ Needs improvement hoặc trạng thái chưa xác minh phù hợp thay vì coi toàn bộ AI đã sẵn sàng.
Sau cùng, kiểm tra Saved, phiên bản cần dùng và trạng thái phát hành. Mở cấu hình phân công của đúng kênh/widget, rồi hỏi lại một câu từ phía khách để chắc người trả lời là AI vừa kiểm tra. Khi thay giá, prompt hoặc công cụ về sau, chạy lại các ca liên quan cùng ít nhất một ca trước đó đã đạt.





