Một AI agent có thể vượt qua toàn bộ bộ kiểm thử trước khi phát hành (go live) nhưng vẫn thất bại khi gặp người dùng thật. Điều này không quá khó hiểu. Bộ dữ liệu evaluation (đánh giá) chủ yếu đại diện cho những tình huống đội ngũ phát triển đã nghĩ tới hoặc thu thập được trước đó, trong khi production luôn chứa nhiều biến thể hơn: người dùng có thể diễn đạt cùng một vấn đề theo hàng chục cách khác nhau, cung cấp thiếu thông tin, thay đổi ý định giữa cuộc hội thoại hoặc rơi vào một trạng thái hệ thống hiếm gặp. Với những agent có khả năng gọi công cụ và thực hiện hành động, số điểm có thể xảy ra lỗi còn nhiều hơn: agent có thể hiểu đúng yêu cầu nhưng lấy sai dữ liệu, chọn sai công cụ, truyền sai tham số hoặc thực hiện đúng hành động nhưng giải thích kết quả không rõ ràng.

Vì vậy, go live không phải điểm kết thúc của quá trình phát triển AI product. Ngược lại, đây là lúc một nguồn dữ liệu mới bắt đầu xuất hiện: hành vi thật của hệ thống trước người dùng thật. Từ thời điểm này, câu hỏi quan trọng không còn chỉ là “AI đang hoạt động tốt đến đâu?”, mà còn là làm thế nào để mỗi thất bại trên production giúp hệ thống ít có khả năng mắc lại cùng lỗi đó trong tương lai? Đó là bài toán của Learning & Feedback Flywheel. Hãy cùng Lemon’s Tribe tìm hiểu trong bài viết này nhé.

“AI học từ production” thực ra nghĩa là gì?

Có một hiểu nhầm về phần lớn AI product hiện nay, đó là: AI càng được sử dụng nhiều từ càng tự học và trở nên tốt hơn. Nếu hôm nay một người dùng nói rằng chatbot trả lời sai, model nền tảng không vì thế mà tự thay đổi trọng số để ngày mai trả lời tốt hơn. Tương tự, một agent đã xử lý hàng triệu cuộc hội thoại cũng không mặc nhiên thông minh hơn chỉ nhờ số lượng tương tác đó.

Muốn hệ thống thay đổi, vẫn cần một cơ chế biến dữ liệu thu được từ production thành một thay đổi cụ thể. Tùy vào nguyên nhân của vấn đề, đội ngũ phát triển có thể cập nhật knowledge base, cải thiện retrieval, sửa prompt, điều chỉnh cách lựa chọn và sử dụng công cụ, thay đổi workflow, bổ sung quy tắc làm rõ yêu cầu, thay model hoặc trong một số trường hợp mới cần đến fine-tuning. Vì vậy, “learning” trong production nên được hiểu ở cấp độ hệ thống, thay vì chỉ giới hạn ở việc huấn luyện model.

Hiểu đơn giản, production tạo ra bằng chứng về những gì hệ thống đang làm tốt hoặc chưa tốt. Những bằng chứng này được phân tích để xác định nguyên nhân, chuyển thành một thay đổi có kiểm soát, được kiểm tra bằng evaluation rồi mới đưa trở lại production. Vòng lặp cơ bản có thể hình dung như sau:

Production → Quan sát → Phát hiện → Chẩn đoán → Cải thiện → Evaluation → Triển khai trên Production

Tuy nhiên, nếu quá trình kết thúc sau khi một lỗi được sửa, cách làm này vẫn khá giống với việc xử lý lỗi trong phần mềm truyền thống. Điểm khiến nó trở thành một flywheel nằm ở chỗ những thất bại đã phát hiện không biến mất sau khi được khắc phục. Những trường hợp có giá trị được giữ lại và trở thành test case cho các lần thay đổi tiếp theo. Anthropic cũng đề xuất khai thác bug tracker, support queue và những thất bại (failure) quan sát được trong production để xây dựng evaluation, sau đó duy trì những hành vi đã ổn định dưới dạng regression test (kiểm thử hồi quy).^{1 2}

Như vậy, production không chỉ là nơi sản phẩm được sử dụng mà còn dần trở thành nguồn dữ liệu giúp bộ evaluation phản ánh tốt hơn những gì sản phẩm thực sự gặp ngoài đời.

Muốn học từ thất bại, trước tiên phải biết đâu là thất bại

Vấn đề đầu tiên là production hiếm khi cung cấp sẵn một nhãn rõ ràng cho biết cuộc hội thoại nào đã thành công và cuộc hội thoại nào thất bại. Cách trực tiếp nhất để tìm câu trả lời là hỏi người dùng. Thumbs up/down (like hoặc dislike), chỉ số CSAT hay khảo sát ý kiến đều là các dạng phản hồi trực tiếp (explicit feedback), tức người dùng chủ động cho biết họ đánh giá trải nghiệm như thế nào.

Những tín hiệu này có giá trị vì chúng phản ánh trực tiếp cảm nhận của người dùng, nhưng chúng cũng có hai hạn chế. Thứ nhất, không phải ai cũng để lại đánh giá sau khi cuộc hội thoại kết thúc, khiến lượng phản hồi thường chỉ bao phủ một phần nhỏ tổng số tương tác. Thứ hai, nhóm người chủ động phản hồi không nhất thiết đại diện cho toàn bộ người dùng. Hiện tượng response-rate bias tương tự đã được ghi nhận trong nghiên cứu về ước lượng mức độ hài lòng của người dùng: nếu chỉ quan sát nhóm chủ động phản hồi, kết quả có thể bị lệch so với toàn bộ population.³ Vì vậy, nếu chỉ dựa vào rating để phát hiện failure, chúng ta đang cố hiểu production thông qua một lát cắt khá nhỏ. Phần dữ liệu còn lại nằm trong chính hành vi của người dùng và kết quả xảy ra sau khi agent phản hồi.

Giả sử một AI chăm sóc khách hàng (CSKH) trả lời rằng “Giao dịch của bạn đã được xử lý thành công”. Người dùng không bấm 👎 (dislike), nhưng vài chục giây sau lại hỏi “Vậy tại sao người nhận vẫn chưa có tiền?”, rồi yêu cầu gặp nhân viên hỗ trợ. Không có phản hồi tiêu cực trực tiếp (explicit negative feedback) nào xuất hiện, nhưng chuỗi hành vi này cho thấy vấn đề nhiều khả năng chưa được giải quyết. Những tín hiệu như vậy thường được gọi là phản hồi gián tiếp (implicit feedback). Trong các hệ thống hội thoại, việc người dùng diễn đạt lại cùng một yêu cầu (reformulation) đã được nghiên cứu như một tín hiệu giúp nhận diện friction (nghĩa gốc là “ma sát”, trong bối cảnh product thì friction là các trở ngại/lỗi khiến trải nghiệm sản phẩm của khách hàng bị gián đoạn hoặc ảnh hưởng) hoặc sự không hài lòng (dissatisfaction).^{4 5}

Tuy nhiên, không phải tín hiệu gián tiếp nào cũng có giá trị như nhau. Một người dùng có thể yêu cầu gặp nhân viên đơn giản vì họ thích nói chuyện với người thật; một cuộc hội thoại có thể kéo dài vì bản thân vấn đề phức tạp; người dùng cũng có thể hỏi lại vì chưa đọc kỹ câu trả lời trước. Những hành vi này hữu ích để phát hiện các trường hợp cần xem xét, nhưng chưa đủ để kết luận rằng AI agent đã thất bại.

Vì vậy, các tín hiệu này không nên được xem là bằng chứng có giá trị như nhau. Một số tín hiệu cho phép chúng ta kiểm chứng trực tiếp vấn đề đã được giải quyết hay chưa. Chẳng hạn, nếu AI agent thông báo đã hoàn tiền nhưng trạng thái trên hệ thống cho thấy hoàn tiền chưa được thực hiện, có thể xác định khá chắc chắn rằng kết quả agent trả về không đúng. Những hành vi như người dùng liên hệ lại về cùng một vấn đề, mở lại ticket hoặc nhân viên phải sửa hành động của AI cũng là dấu hiệu tương đối rõ rằng lần xử lý trước chưa đạt kết quả mong muốn. Trong khi đó, các tín hiệu như người dùng diễn đạt lại câu hỏi, yêu cầu gặp nhân viên, hội thoại kéo dài bất thường hay thể hiện cảm xúc tiêu cực chủ yếu cho thấy trải nghiệm đang có vấn đề và cần được kiểm tra thêm, chứ chưa đủ để kết luận agent đã xử lý sai.

Sự phân biệt này dẫn đến một nguyên tắc quan trọng khi đánh giá AI product: đừng chỉ đo xem AI đã nói gì; hãy đo xem sau khi AI nói hoặc hành động, trạng thái của người dùng và hệ thống đã thay đổi như thế nào. Một agent có thể tạo ra câu trả lời rất thuyết phục nhưng vẫn không giải quyết được vấn đề. Chất lượng câu trả lời và khả năng giải quyết vấn đề có liên quan với nhau, nhưng không thể đánh đồng chúng là một.

Biết thất bại ở đâu vẫn chưa đủ để biết phải sửa gì

Giả sử team đã xác định được một cuộc hội thoại không giải quyết được vấn đề. Sau khi đọc lại, kết luận dễ đưa ra nhất là “AI trả lời sai”. Kết luận này đúng nhưng gần như không giúp ích cho việc cải thiện hệ thống, bởi cùng một câu trả lời sai có thể bắt nguồn từ nhiều nguyên nhân hoàn toàn khác nhau. Ví dụ, người dùng hỏi: “Tôi chuyển tiền rồi nhưng người nhận chưa nhận được.”, AI agent có thể thất bại ngay từ bước hiểu yêu cầu khi nhầm đây là một giao dịch thất bại thay vì giao dịch đã thực hiện nhưng chưa hoàn tất. Agent cũng có thể hiểu đúng nhưng retrieval lấy nhầm tài liệu, hoặc thông tin cần thiết đã có đầy đủ nhưng model suy luận sai. Trong một trường hợp khác, vấn đề nằm ở công cụ: agent chọn đúng API nhưng truyền sai mã giao dịch nên nhận về trạng thái của một giao dịch khác. Cũng có thể toàn bộ quá trình xử lý đều đúng nhưng câu trả lời cuối cùng gây hiểu nhầm, hoặc workflow hiện tại đơn giản là không đủ khả năng giải quyết trường hợp đó và agent đáng lẽ phải chuyển sang nhân viên chăm sóc khách hàng sớm hơn.

Có thể tạm chia chuỗi này thành sáu lớp: hiểu yêu cầu → truy xuất → suy luận→ sử dụng công cụ → phản hồi → vấn đề được giải quyết. Mục đích của việc phân loại là để xác định sai sót ở bất kỳ bước nào đều khiến quá trình xử lý phía sau đi sai hướng.

Giả sử agent truyền nhầm mã giao dịch vào API. API vì thế trả về dữ liệu của một giao dịch khác, model dựa vào dữ liệu đó để đưa ra kết luận sai và cuối cùng trả lời sai cho người dùng. Nếu chỉ nhìn vào output, chúng ta có thể gọi đây là trả lời sai (response failure)và bắt đầu sửa prompt. Nhưng nội dung trả lời này chỉ là triệu chứng cuối cùng; nguyên nhân thực sự nằm ở bước xác định giao dịch và gọi công cụ. Sửa prompt trong trường hợp này không giải quyết được vấn đề.

Đây cũng là lý do evaluation cho AI agent cần quan sát không chỉ câu trả lời cuối cùng mà cả tracing của quá trình xử lý: agent hiểu yêu cầu như thế nào, lấy thông tin gì, gọi công cụ nào với tham số nào, nhận kết quả gì và trạng thái cuối cùng của hệ thống ra sao. Anthropic phân biệt khá rõ giữa transcript — những gì agent đã làm trong quá trình xử lý — và outcome — trạng thái cuối cùng mà agent tạo ra.⁶ Với Product team, sự phân biệt này giúp chuyển câu hỏi từ “AI có trả lời sai không?” thành “AI bắt đầu sai ở đâu và thành phần nào của hệ thống cần được thay đổi?”.

Từ thất bại đến một hệ thống tốt hơn

Sau khi xác định được một interaction thất bại và tìm ra nguyên nhân, bước tiếp theo là biến những gì xảy ra trong production thành một thay đổi cụ thể cho hệ thống. Trong Customer Service, một trong những nguồn dữ liệu hữu ích nhất cho bước này chính là cách nhân viên hỗ trợ tiếp tục xử lý sau khi AI không giải quyết được vấn đề.

Giả sử AI kết luận rằng một giao dịch cần chờ thêm 24 giờ và chuyển người dùng sang nhân viên CSKH. Nhân viên kiểm tra thêm một trường dữ liệu mà AI chưa sử dụng, nhận ra giao dịch thực tế đang ở một trạng thái khác, sau đó dùng một công cụ khác để giải quyết vấn đề. Nếu chỉ ghi nhận rằng đoạn hội thoại (conversation) đã được chuyển sang nhân viên CSKH (human handoff), team chỉ biết AI thất bại. Nhưng nếu so sánh quá trình xử lý của AI với nhân viên, team có thể biết thêm AI đã thiếu điều gì để xử lý đúng: hiểu sai intent (ý định của khách hàng), chưa thu thập đủ thông tin, thiếu kiến thức (knowledge), chọn sai công cụ hay chưa biết khi nào cần chuyển sang cho nhân viên CSKH.

Human correction vì thế có thể trở thành một nguồn phản hồi chuyên môn cho hệ thống. Tuy nhiên, nó không nên mặc nhiên được xem là thông tin chính xác (ground truth), bởi con người cũng có thể xử lý sai hoặc sử dụng một cách khắc phục tạm thời không chính thống. Trước khi được dùng để cải thiện AI, human correction vẫn cần được đối chiếu với kết quả cuối cùng (ví dụ vấn đề của người dùng có được giải quyết không) và chuẩn hóa thành những thông tin có thể sử dụng được.

Từ đây, team mới có cơ sở để chọn cách cải thiện phù hợp. Một thất bại trong quá trình truy xuất (retrieval failure) có thể cần sửa dữ liệu hoặc cơ chế truy xuất; thất bại về công cụ (tool failure) cần sửa cách agent lựa chọn hoặc sử dụng công cụ; còn một thất bại về nhận diện ý định của khách hàng (intent failure) chưa chắc cần prompt tốt hơn mà có thể cần agent biết hỏi lại người dùng trước khi hành động. Chẳng hạn với câu “Sao tôi chưa nhận được tiền?”, agent chưa thể biết người dùng đang nói về tiền do người khác chuyển đến, tiền hoàn lại hay tiền cashback. Nếu tự đoán một intent, toàn bộ các bước phía sau vẫn có thể chạy đúng nhưng cuối cùng lại giải quyết sai vấn đề. Trong trường hợp này, một câu hỏi làm rõ có giá trị hơn một câu trả lời được tạo ra quá sớm.⁷

Tuy nhiên, làm rõ lại vấn đề của khách hàng cũng không nên trở thành phản xạ mặc định mỗi khi agent gặp một chút không chắc chắn, vì hỏi lại quá nhiều sẽ tạo thêm friction. Quyết định này nên phụ thuộc vào cả mức độ không chắc chắn (confidence score) và hậu quả nếu đoán sai. Với một lựa chọn ít rủi ro (có thể thu hồi được), agent có thể chấp nhận mức độ không chắc chắn cao hơn; nhưng trước một hành động như chuyển tiền, hủy dịch vụ hoặc thay đổi thông tin quan trọng, việc xác nhận lại trở nên cần thiết hơn. Như vậy, mục tiêu của việc chẩn đoán không chỉ là tìm ra AI sai ở đâu mà còn giúp team lựa chọn đúng cách thức can thiệp cho loại failure đó.

Biến failure thành regression test

Nếu quá trình kết thúc sau khi hệ thống được sửa, bài học từ production vẫn có thể mất đi. Một thay đổi model, prompt, knowledge base hay workflow trong tương lai hoàn toàn có thể khiến lỗi cũ xuất hiện trở lại. Vì vậy, bước tiếp theo của feedback flywheel là giữ lại những failure có giá trị dưới dạng regression test.

Giả sử agent từng chọn nhầm một trong hai giao dịch gần nhau của cùng người dùng. Sau khi tìm ra nguyên nhân và sửa logic lựa chọn giao dịch, team có thể giữ lại chính tình huống đó trong evaluation dataset. Từ thời điểm này, mỗi phiên bản mới không chỉ phải xử lý tốt những capability mà team muốn xây dựng, mà còn phải chứng minh rằng nó không tái tạo những lỗi sản phẩm từng gặp trong production. Đây cũng là điểm khác biệt giữa capability evaluation và regression evaluation: một bên kiểm tra hệ thống có làm được điều chúng ta mong muốn hay không, bên còn lại bảo vệ những hành vi đã hoạt động đúng trước các thay đổi về sau.⁸

Tuy nhiên, đưa một lỗi thực tế vào evaluation không đơn giản là sao chép nguyên cuộc hội thoại. Một trường hợp kiểm thử cần tái tạo được điều kiện khiến lỗi xảy ra và xác định rõ kết quả mong muốn. Với ví dụ trên, bài kiểm thử cần tạo lại bối cảnh có hai giao dịch dễ nhầm lẫn, sau đó kiểm tra agent có xác định đúng giao dịch hay chủ động hỏi thêm khi chưa đủ thông tin. Nếu chỉ so sánh câu chữ giữa câu trả lời mới và câu trả lời cũ, bài kiểm thử vẫn có thể đạt dù nguyên nhân gây ra lỗi chưa thực sự được khắc phục.

Đây là lúc Learning & Feedback Flywheel bắt đầu tạo ra giá trị tích lũy. Bộ evaluation ban đầu chủ yếu phản ánh những tình huống đội ngũ phát triển dự đoán có thể xảy ra. Sau một thời gian vận hành, nó được bổ sung bằng những tình huống đã thực sự xảy ra với người dùng. Một lỗi vì thế không còn là sự cố được phát hiện, sửa rồi đóng lại, mà trở thành một phần của bộ kiểm thử dùng để bảo vệ sản phẩm trước những thay đổi trong tương lai.⁹

Dù vậy, bộ evaluation không thể tự động bao phủ mọi loại lỗi. Nếu đội ngũ chỉ xem xét những cuộc hội thoại có đánh giá tiêu cực, được chuyển sang nhân viên hoặc người dùng phải liên hệ lại, hệ thống sẽ ngày càng bao phủ tốt những loại lỗi đã biết nhưng vẫn có thể bỏ sót những vấn đề tiềm ẩn. Vì vậy, bên cạnh việc theo dõi những tín hiệu đã xác định, vẫn cần lấy mẫu ngẫu nhiên các cuộc hội thoại và rà soát định kỳ để tìm ra những dạng lỗi mới.¹⁰

Một Learning & Feedback Flywheel tốt vì thế cần làm được hai việc song song: ghi nhớ những sai lầm đã biết để chúng không dễ quay trở lại, đồng thời tiếp tục phát hiện những thất bại mà hệ thống chưa từng gặp hoặc chưa biết cách nhận diện.

Learning & Feedback Flywheel hoàn chỉnh

Từ những phần trên, một Learning & Feedback Flywheel có thể được tóm lại thành sáu bước.

• Observe — Quan sát production. Thu thập đủ thông tin để hiểu một tương tác đã diễn ra như thế nào: người dùng yêu cầu gì, agent truy xuất thông tin nào, sử dụng công cụ ra sao và trạng thái cuối cùng của người dùng hoặc hệ thống là gì.
• Detect — Phát hiện những trường hợp đáng xem xét. Xác định những trường hợp có dấu hiệu chưa được giải quyết tốt. Các kết quả có thể kiểm chứng trực tiếp nên được ưu tiên, sau đó mới kết hợp những tín hiệu gián tiếp như người dùng liên hệ lại, mở lại ticket, diễn đạt lại câu hỏi, yêu cầu gặp nhân viên hoặc để lại đánh giá tiêu cực.
• Diagnose — Xác định nguyên nhân. Tìm điểm đầu tiên khiến quá trình xử lý đi sai hướng, thay vì dừng lại ở kết luận chung chung rằng “AI trả lời sai”. Nguyên nhân có thể nằm ở việc hiểu yêu cầu, truy xuất thông tin, suy luận, sử dụng công cụ, cách phản hồi hoặc khả năng giải quyết vấn đề.
• Improve — Sửa đúng thành phần. Sửa đúng thành phần gây ra lỗi. Một vấn đề ở retrieval cần cách xử lý khác với lỗi khi gọi công cụ; trường hợp thiếu thông tin có thể cần một câu hỏi làm rõ thay vì một prompt dài hơn. Không phải vấn đề nào của AI product cũng được giải quyết bằng cách thay model.
• Evaluate — Kiểm tra thay đổi. Kiểm tra xem thay đổi mới có thực sự khắc phục được vấn đề mà không làm hỏng những hành vi vốn đang hoạt động tốt hay không.
• Learn — Giữ lại bài học. Những lỗi có giá trị được chuyển thành regression test để các phiên bản sau tiếp tục phải vượt qua chúng. Đây là bước giúp một lần thất bại trong thực tế trở thành bài học có thể sử dụng lâu dài.

Sau khi phiên bản mới được triển khai, hệ thống tiếp tục gặp những tình huống mới và vòng lặp lại bắt đầu. Qua mỗi chu kỳ, bộ evaluation không chỉ lớn hơn mà còn phản ánh ngày càng sát những vấn đề sản phẩm thực sự gặp phải.

Nhìn theo cách này, xây dựng Learning & Feedback Flywheel không nhất thiết phải bắt đầu bằng fine-tuning hay một hệ thống đánh giá tự động phức tạp. Điều quan trọng hơn là tạo được một chuỗi liên kết rõ ràng: nhận biết vấn đề đã xảy ra, tìm đúng nguyên nhân, sửa đúng thành phần, kiểm tra lại và giữ lại bài học để lỗi cũ không dễ quay trở lại.

Tạm kết

Với phần mềm truyền thống, một lỗi thường đi qua chu trình phát hiện, sửa, kiểm thử rồi đóng lại. Với AI product, quá trình có thể đi thêm một bước: những lỗi đáng giá sẽ được giữ lại trong bộ evaluation để tiếp tục đánh giá cho các phiên bản sau. Đây cũng là lý do một AI agent không tự nhiên trở nên tốt hơn chỉ vì đã phục vụ nhiều người dùng. Việc sử dụng trong thực tế chỉ tạo ra dữ liệu và bằng chứng về cách hệ thống đang hoạt động. Sản phẩm chỉ thực sự cải thiện khi đội ngũ có cơ chế biến những bằng chứng đó thành thay đổi cụ thể, kiểm chứng thay đổi và giữ lại những bài học quan trọng cho những lần phát triển tiếp theo.

Theo thời gian, bộ evaluation vì thế không còn chỉ phản ánh những tình huống đội ngũ dự đoán trước khi ra mắt. Nó dần tích lũy những trường hợp khó, những sai lầm và những bài học mà sản phẩm đã thực sự gặp khi vận hành. Nói cách khác, bộ evaluation dần trở thành bộ nhớ về những gì hệ thống từng làm sai. Và chính khả năng ghi nhớ những sai lầm đó tạo nên hiệu ứng tích lũy của Learning & Feedback Flywheel: sản phẩm không chỉ sửa được vấn đề của hôm nay, mà còn giảm khả năng lặp lại chính vấn đề đó trong tương lai.

Cheers & Peace!

---

Nguồn tham khảo

1. Anthropic (2026), Demystifying evals for AI agents. ↩︎
2. LangChain, Evaluation Types. ↩︎
3. Christakopoulou et al. (2020), Deconfounding User Satisfaction Estimation from Response Rate Bias, ACM RecSys. ↩︎
4. Wang et al. (2021), Contextual Rephrase Detection for Reducing Friction in Dialogue Systems, EMNLP. ↩︎
5. Sano, Kaji & Sassano (2017), Predicting Causes of Reformulation in Intelligent Assistants, SIGDIAL. ↩︎
6. Anthropic (2026), Demystifying evals for AI agents. ↩︎
7. Chen et al. (2025), Learning to Clarify: Multi-turn Conversations with Action-Based Contrastive Self-Training. ↩︎
8. Anthropic (2026), Demystifying evals for AI agents. ↩︎
9. LangChain, LangSmith Evaluation Concepts. ↩︎
10. Anthropic (2026), Demystifying evals for AI agents. ↩︎