Link bài viết gốc： https://x.com/huangtongxueh/status/21094...
Hoàng Đồng Học h · X · @huangtongxueh · 2026-10-12 08:56
Bài viết này được chia sẻ lại, bản quyền thuộc về tác giả gốc, toàn văn căn cứ theo link bài gốc
Đánh giá Agent đã trở thành nền tảng của các ứng dụng Agent hiện nay. Nếu như đầu năm mọi người đều dồn sự chú ý vào Harness, thì điểm nóng và vùng nước sâu hiện tại chắc chắn là đánh giá Agent và Agent Infra.
Theo những gì tôi tìm hiểu, hầu như nhóm làm sản phẩm Agent nào cũng rất coi trọng phương pháp luận cũng như hiệu quả của việc đánh giá.
Vì vậy, tôi mở riêng một series bài viết để giới thiệu chi tiết cho các bạn về đánh giá là gì, cách làm ra sao, cùng một số phương pháp luận và chi tiết liên quan. Đây là bài viết đầu tiên của series, kết hợp giữa sự đồng thuận trong ngành và các best practice của bản thân tôi để tổng kết lý do vì sao chúng ta cần đánh giá Agent.
1. Bắt đầu từ một lần sửa lỗi
Chẳng hạn hiện có một nghiệp vụ backend cần phát triển bổ sung một công cụ Agent để phục vụ cho nghiệp vụ đó, ví dụ như Qwen Shopping của Taobao, CSKH thông minh của JD, v.v.
Trong quá trình phát triển Agent này, chúng ta sẽ nhận được phản hồi từ môi trường production. Khi người dùng hoặc PM báo lỗi, chúng ta thường sẽ kiểm tra bản ghi thực thi tương ứng với sự cố đó (tức trace), để rà soát cụ thể xem lỗi phát sinh ở bước nào. Các vấn đề thường gặp bao gồm:
- Tool không trả về kết quả bình thường;
- Skill của chúng ta không được Agent hiểu đúng;
- Agent runtime gặp sự cố, Agent loop tồn tại điểm bất hợp lý đối với nhiệm vụ hiện tại, khiến Agent hiểu sai lệch và dẫn đến thất bại của nhiệm vụ lần này.
Sau khi tìm ra vấn đề, chúng ta sẽ sửa tool tương ứng, hoặc điều chỉnh prompt, skill, thậm chí là Agent runtime, rồi kiểm tra lại xem sự cố ban đầu đã được giải quyết hay chưa. Tiếp đó, nếu làm theo quy trình phát triển backend thông thường, chúng ta sẽ thực hiện một số kiểm thử hồi quy. Bàn giao cho QA kiểm thử, QA có thể cũng chỉ kiểm tra chức năng tương ứng, tạo một vài test case, rồi cho rằng đã đủ điều kiện để release lên production.
Nhưng xử lý đến bước này, chúng ta mới chỉ xác nhận được rằng vấn đề được báo cáo lần này đã được giải quyết. Còn việc các nhiệm vụ khác của toàn bộ Agent có bị ảnh hưởng hay không thì rất khó để đánh giá. Những quy tắc kiểu "vá víu" được bổ sung để xử lý một trường hợp ngoại lệ có thể sẽ làm thay đổi hành vi của Agent trong các tình huống khác, nhưng nếu chỉ nhìn vào ca vừa được sửa xong thì chúng ta hoàn toàn không nhận ra được những thay đổi này.
Nỗi lo ngại tương tự thực ra cũng xảy ra khi phát hành tính năng mới. Giờ đây với sự tham gia của Agent, toàn bộ chu kỳ phát triển được rút ngắn lại. Chúng ta cần xác định trong thời gian có hạn: tính năng mới hiện tại có khả dụng hay không, và các tính năng cốt lõi ban đầu có bị ảnh hưởng hay không.
Những nhận định này chủ yếu vẫn đến từ các phản hồi thu thập được hiện tại và kiểm thử trong môi trường test. Nhưng sau khi đưa lên production, hoặc khi lượng dữ liệu tăng lên, đến lúc chúng ta phát hiện ra vấn đề thì người dùng đã bị ảnh hưởng rồi.
Hiện nay, một số công ty làm Agent tốt đều chú trọng đến đánh giá Agent. Ví dụ, đợt tuyển dụng hiện tại của ByteDance rất coi trọng vị trí đánh giá Agent này.
Các team hoặc công ty này mong muốn có một bộ phương pháp kiểm tra có thể tái sử dụng nhiều lần trước khi release, nhằm giúp họ:
- Đánh giá xem lần chỉnh sửa này đã giải quyết cụ thể điều gì, có ảnh hưởng đến các chức năng vốn đang hoạt động bình thường hay không.
- Cùng với những thay đổi của tool, prompt và workflow, giữ lại các căn cứ để xác định xem sản phẩm Agent hiện tại có thực sự trở nên dễ dùng hơn hay không.
2. Đánh giá Agent là gì
Như đã đề cập ở trên, trong quá trình xử lý sự cố hoặc phát triển tính năng mới, chúng ta sẽ sửa đổi tool, prompt, skill hoặc Agent runtime. Dù thay đổi diễn ra ở một vị trí cụ thể, nhưng điều cuối cùng chúng ta cần kiểm tra là khi kết hợp các phần này lại với nhau, Agent còn có thể hoàn thành mục tiêu của người dùng hoặc mục tiêu đã đề ra cho nó hay không.
Quá trình thực thi của Agent có một phần do model quyết định. Model sẽ dựa trên yêu cầu của người dùng, context hiện tại và kết quả tool trả về để quyết định gọi tool nào, truyền tham số gì và bước tiếp theo chúng ta cần làm gì. Điều này khiến toàn bộ luồng thực thi của nó không hoàn toàn được xác định trước bởi code.
Output của model thường đi kèm với sự biến thiên, cùng một nhiệm vụ có thể cho ra kết quả và quá trình thực thi khác nhau. Đây cũng là điều mọi người thường bàn luận: Agent khác với phần mềm truyền thống, nó là một công cụ mang tính xác suất. Việc bản thân nó có thể chạy bình thường không đồng nghĩa với việc Agent lần nào cũng chọn đúng tool phù hợp, truyền đúng tham số và hoàn thành toàn bộ sự việc theo đúng workflow và yêu cầu nghiệp vụ mà chúng ta đã xây dựng.
Vì vậy, để đánh giá một hệ thống như vậy hoạt động ra sao, trước tiên chúng ta cần xác định nhiệm vụ cụ thể cùng tiêu chuẩn hoàn thành, sau đó dựa vào bản ghi thực thi và kết quả thực tế để kiểm tra biểu hiện của nó.
Tiêu chuẩn ở đây thường đến từ yêu cầu nghiệp vụ. Thao tác nghiệp vụ nào được phép thực hiện, điều kiện nào bắt buộc phải thỏa mãn, kết quả cuối cùng phải như thế nào, đều là những thứ chúng ta cần xác định rõ ràng trong quá trình phát triển.
Đây chính là đánh giá Agent mà chúng ta đang nói đến: Một bộ phương pháp xoay quanh các nhiệm vụ cụ thể, dựa trên tiêu chuẩn rõ ràng để kiểm tra quá trình và kết quả thực thi của Agent. Thông qua những lần kiểm tra này để nắm được chất lượng hoàn thành nhiệm vụ của Agent, cũng như độ ổn định của nó dưới môi trường và điều kiện thử nghiệm.
Lấy kịch bản CSKH làm ví dụ, giả sử người dùng cần hủy một đơn hàng, chúng ta có thể chuẩn bị thông tin đơn hàng và điều kiện nghiệp vụ tương ứng cho Agent, để nó xử lý yêu cầu này.
Sau đó tiến hành kiểm tra:
- Đơn hàng được thao tác có đúng là đơn do người dùng chỉ định hay không?
- Đơn hàng này có thỏa mãn điều kiện hủy hay không? Agent có xử lý theo đúng yêu cầu hay không?
- Nếu đơn hàng cần được hủy, thì trạng thái đơn hàng có thực sự thay đổi hay không?
Ví dụ Agent đã gọi tool hủy đơn hàng, cuối cùng cũng phản hồi người dùng rằng "đơn hàng đã được hủy", chúng ta vẫn cần phải kiểm tra trạng thái đơn hàng trong hệ thống backend nghiệp vụ tương ứng. Cả bản ghi gọi tool lẫn nội dung phản hồi đều không thể đứng riêng lẻ để chứng minh rằng nhiệm vụ của chúng ta đã thực sự hoàn thành.
Nếu đơn hàng không đủ điều kiện hủy, chúng ta cần kiểm tra xem Agent có giải thích đúng lý do hay không, và không thực hiện thao tác hủy. Những bản ghi về quá trình thực thi mà chúng ta nhìn thấy thực chất chính là trace. Chúng ta có thể dùng các công cụ như Langfuse hoặc Phoenix để quan sát hoặc thu thập chúng.
Chúng ta có thể thông qua trace để xem Agent đã chọn những tool nào, truyền tham số gì, nhận được kết quả ra sao, sau đó kết hợp với trạng thái của hệ thống nghiệp vụ để đánh giá xem nhiệm vụ lần này có hoàn thành đúng yêu cầu hay không. Để hiểu rõ độ ổn định, còn cần thay đổi một số điều kiện đơn hàng, cách diễn đạt của người dùng và thực thi lặp lại trong cùng điều kiện để quan sát tỷ lệ thành công và thất bại.
Đánh giá Agent có thể kết hợp với công việc kiểm thử hiện tại. Nếu QA đã kiểm tra biểu hiện của Agent trong các kịch bản khác nhau theo các nhiệm vụ và tiêu chuẩn rõ ràng, thì những công việc đó hoàn toàn có thể trở thành một phần của quá trình đánh giá. Các bài test tool ban đầu vẫn có thể tiếp tục sử dụng, ví dụ như kiểm tra tính hợp lệ của tham số, API có trả về bình thường hay không.
Còn về cách đánh giá cụ thể ra sao, bạn có thể lựa chọn phương pháp tùy theo nhiệm vụ. Những kết quả rõ ràng như trạng thái đơn hàng, đối tượng thao tác có thể kiểm tra thông qua code; còn câu hỏi của người dùng đã được giải đáp hay chưa, giải thích có rõ ràng không thì có thể kết hợp đánh giá thủ công hoặc sử dụng model chấm điểm đã qua hiệu chuẩn bởi con người.
3. Vì sao chúng ta cần đánh giá Agent
1. Tránh việc càng sửa càng hỏng
Khi sửa lỗi, phần lớn chúng ta thường chỉ tập trung sự chú ý vào nhiệm vụ bị thất bại lần này. Sau khi tiến hành bug fix, chúng ta sẽ chạy lại request ban đầu một lần nữa để xác nhận xem nó đã hoàn thành bình thường chưa, cuối cùng bàn giao cho QA kiểm thử.
Nhưng làm như vậy thực ra lại nảy sinh một vấn đề: Agent phải xử lý rất nhiều nhiệm vụ khác nhau, lần chỉnh sửa này cũng có thể ảnh hưởng đến việc thực thi các nhiệm vụ khác. Chẳng hạn, chúng ta bổ sung thêm một skill xử lý hoàn tiền cho Agent CSKH, tính năng hoàn tiền đã dùng được rồi, nhưng các luồng tra cứu và hủy đơn hàng ban đầu cũng cần phải kiểm tra lại một lượt. Bởi vì lúc này model có thêm một bộ skill để tham chiếu, việc lựa chọn tool cũng như nhận định ý định của người dùng đều có thể bị tác động.
Do đó, việc lưu giữ lại những nhiệm vụ vốn đã hoàn thành tốt để kiểm tra lại khi cập nhật phiên bản là điều vô cùng quan trọng trong đánh giá. Bởi vì chúng ta bắt buộc phải đảm bảo rằng trước khi cập nhật hoặc release, các chức năng cốt lõi của Agent không bị ảnh hưởng. Chúng ta không thể chỉ nhìn vào việc điểm số tổng thể có tăng lên hay không, hoặc tính năng mới mang lại những khả năng gì, mà còn phải xem cụ thể có những nhiệm vụ nào có thể bị thụt lùi . Đó chính là tầm quan trọng của việc đánh giá Agent, bởi các thay đổi mới có thể che lấp sự suy giảm của một số chức năng sẵn có.
Dựa vào điều này, team sẽ có thêm một căn cứ đánh giá trước khi release, từ đó có thể xử lý sớm một phần vấn đề mà đáng lẽ phải đợi đến khi người dùng phản hồi mới phát hiện ra.
2. Đánh giá xem có thực sự tốt lên hay không
Chúng ta chỉnh sửa prompt, bổ sung skill thường là vì nghĩ rằng làm vậy sẽ giúp Agent hoàn thành nhiệm vụ tốt hơn. Ví dụ như thêm một số quy tắc nghiệp vụ, bổ sung cách xử lý cho các vấn đề thường gặp, thêm các điều kiện biên, hoặc viết phần mô tả hướng dẫn sử dụng tool chi tiết hơn.
Những sửa đổi này nhìn cục bộ thì rất hợp lý, nhưng thực tế có hiệu quả hay không? Chúng ta cần đánh giá từ kết quả thực thi và nhìn nhận trên bình diện tổng thể.
Giả sử chúng ta bổ sung một đoạn hướng dẫn xử lý ngoại lệ cho skill hoàn tiền của sàn thương mại điện tử, ca thất bại trước đó đã vượt qua, kết quả này khiến chúng ta thấy được khả năng cải thiện. Nhưng nếu chỉ nhìn vào lần thực thi này, vẫn chưa thể khẳng định là do việc sửa đổi phát huy tác dụng, hay lần chạy này chỉ là một sự thành công ngẫu nhiên của model. Liệu các tình huống ngoại lệ tương tự khác có xử lý được hay không cũng cần phải tiếp tục kiểm tra.
Khi đã có cơ chế đánh giá, chúng ta có thể để phiên bản cũ và phiên bản mới xử lý cùng một tập nhiệm vụ nhiều lần trong điều kiện đồng nhất nhất có thể, rồi đối chiếu biểu hiện cụ thể của từng bản . Bên cạnh việc xem nhiệm vụ có được hoàn thành hay không, bạn cũng có thể xem cùng một nhiệm vụ mất bao nhiêu thời gian, gọi tool bao nhiêu lần, từ đó đánh giá sự thay đổi về hiệu năng và chi phí.
Có phiên bản tuy xử lý trọn vẹn hơn nhưng lại khiến thời gian chờ của người dùng lâu hơn. Sự thay đổi như vậy có đáng hay không cần chúng ta kết hợp với yêu cầu nghiệp vụ để cân nhắc.
3. Xác nhận khả năng hoàn thành nhiệm vụ một cách ổn định
Nhiều khi, việc xử lý thành công một request trong môi trường test khiến chúng ta cảm thấy tính năng này đã sẵn sàng sử dụng. Nhưng trong kịch bản thực tế, cách diễn đạt của người dùng chắc chắn không chỉ gói gọn như những gì chúng ta thiết kế; họ có thể trò chuyện về vấn đề khác trước rồi mới đưa ra yêu cầu thực sự. Liệu Agent có thể hoàn thành cùng một mục tiêu trong tình huống đó hay không là điều chúng ta cần xác định sâu hơn.
Lấy ví dụ, khi người dùng nói thẳng "hủy đơn hàng này", Agent có thể xử lý bình thường. Nhưng nếu người dùng hỏi về quy định hủy trước, sau đó lại đổi đơn hàng muốn hủy, thì liệu model vào lúc đó có còn lưu giữ đúng context hay không lại là điều cần phải đánh giá lại.
Bên cạnh việc thay đổi các kịch bản, chúng ta cũng cần phải thực thi lặp lại cùng một nhiệm vụ . Đối với những thao tác như "hủy đơn hàng", chúng ta cần để mỗi lần kiểm tra đều bắt đầu từ cùng một trạng thái đơn hàng ban đầu, nhằm quan sát xem biểu hiện của Agent có ổn định hay không. Một lần thành công có thể chứng minh nhiệm vụ lần đó đã hoàn thành, nhưng việc kiểm tra nhiều lần mới giúp chúng ta hiểu được nó có bao nhiêu phần chắc chắn để làm tốt lặp đi lặp lại trong các điều kiện đó.
Một quan điểm rút ra từ thực tế của tôi hiện tại là: tôi không thể đòi hỏi tuyệt đối rằng Agent phải đạt độ chính xác 100% trong một nhiệm vụ cụ thể, nhưng chúng ta có thể thông qua các biện pháp như đánh giá để đưa độ ổn định của nhiệm vụ đạt trên 90%. Đây cũng là mục tiêu mà nhiều công ty công nghệ lớn hiện nay đang hướng tới.
4. Làm rõ thế nào là làm tốt
Khi thảo luận về requirement, chúng ta thường hay nói "hãy để Agent hiểu ý định của người dùng", "xử lý tốt quy trình nghiệp vụ này". Những diễn đạt này có thể chỉ ra phương hướng, nhưng khi đi vào tình huống cụ thể thì cách hiểu của mỗi người lại có thể không giống nhau.
Ví dụ, người dùng có nhiều đơn hàng nhưng chỉ nói một câu "hủy đơn hàng đi". Developer có thể cho rằng Agent có thể dựa vào hội thoại gần nhất để xác định đơn hàng mục tiêu, PM có thể muốn Agent xác nhận lại với người dùng một lần nữa, còn QA khi kiểm thử lại có thể áp dụng một tiêu chí phán đoán khác. Ở đây cần làm rõ trước sản phẩm cho phép Agent thao tác trực tiếp trong điều kiện nào, và trường hợp nào bắt buộc phải hỏi lại để xác nhận.
Khi đưa những tình huống này thành các ca đánh giá, bạn cần phải nêu rõ hành vi nào có thể chấp nhận được và hành vi nào không thể chấp nhận . Khi thảo luận về các ca cụ thể, những yêu cầu vốn chưa được làm rõ trước đó sẽ dần lộ diện. Ngay cả khi tính năng còn chưa hoàn thiện, các cuộc thảo luận này cũng giúp developer, PM và QA thống nhất được bộ tiêu chuẩn đánh giá. Sau khi xem xét output thực tế, team cũng có thể nhận ra các tiêu chuẩn cần được bổ sung, và quá trình đánh giá sẽ tiếp tục được điều chỉnh theo nhận thức chung đó.
Quá trình này thực chất là một quá trình chúng ta lặp cải tiến sản phẩm. Hiện tại, rất nhiều PM của các công ty công nghệ lớn cũng tham gia vào việc đánh giá Agent của chúng tôi, và đây đã trở thành một khâu tương đối then chốt trong đánh giá Agent. Bởi vì nhân sự tham gia đánh giá cần có kiến thức nghiệp vụ vững chắc, hiểu sâu về toàn bộ hệ thống nghiệp vụ thì mới có thể hoàn thành việc lặp cải tiến cho toàn bộ sản phẩm Agent của chúng ta.
Vì vậy, nếu việc đánh giá có thể giúp chúng ta xác định rõ thế nào là "làm tốt", tình trạng hoàn thành nhiệm vụ ra sao là điều chúng ta mong muốn, thì nó sẽ có thể giúp chúng ta hoàn thành một vòng lặp cải tiến sản phẩm trong quá trình này.
5. Biết bước tiếp theo cần sửa gì
Khi các vấn đề liên tục được phản hồi từ môi trường production, chúng ta rất dễ có xu hướng xử lý trước phản hồi nhận được gần nhất. Nhưng nếu chỉ nhìn vào một phản hồi đơn lẻ, rất khó để biết toàn bộ Agent thường thất bại nhất ở những điểm nào, và cũng rất khó xác định thời gian phát triển nên được ưu tiên dành cho đâu.
Khi đặt kết quả đánh giá và trace của một loạt nhiệm vụ lại với nhau, chúng ta có thể phân loại sâu hơn: có nhiệm vụ chọn sai công cụ, có nhiệm vụ làm mất thông tin đã xác nhận trước đó, lại có nhiệm vụ quá trình gọi diễn ra bình thường nhưng cuối cùng không hoàn thành thao tác nghiệp vụ. Nhờ vậy, chúng ta có thể thấy một loại vấn đề nào đó có lặp đi lặp lại hay không, và tìm ra khâu cần tiếp tục điều tra, xử lý.
Tuy nhiên, bộ đánh giá có thể được thu thập riêng cho các case khó, do đó vấn đề thất bại nhiều nhất trong đó chưa chắc đã là vấn đề ảnh hưởng đến nhiều người dùng nhất trên production. Khi sắp xếp mức độ ưu tiên, còn cần kết hợp với tần suất sử dụng các nhiệm vụ này trên production, cũng như hậu quả mà thất bại sẽ mang lại . Một vấn đề hiếm khi xảy ra nhưng có thể thao tác sai đơn hàng cũng có thể đáng được ưu tiên xử lý hơn một vấn đề dùng từ ngữ diễn đạt thường xuyên xuất hiện.
Khi tập hợp những thông tin này lại, team mới có thể quyết định cụ thể hơn xem tiếp theo nên sửa tool, điều chỉnh skill, hay cải thiện cách Agent xử lý context. Sau khi sửa đổi xong, lại dùng các nhiệm vụ tương ứng để kiểm tra, xác nhận xem công sức bỏ ra lần này đã giải quyết được vấn đề ban đầu hay chưa.
IV. Cách ứng dụng đánh giá Agent vào quy trình phát triển Agent thực tế của chúng ta
Quay lại vấn đề fix bug được nhắc đến ở phần đầu. Sau khi kiểm tra trace và tìm ra nguyên nhân, chúng ta còn cần đưa vấn đề lần này vào quá trình phát triển và kiểm thử tiếp theo. Kết hợp với nội dung phía trước, có thể tóm gọn quy trình này thành năm bước: Gom nhiệm vụ, làm rõ tiêu chuẩn, chuẩn bị môi trường, chạy so sánh, liên tục cập nhật.
1. Gom các nhiệm vụ cần đánh giá
Trước tiên hãy xác định rõ thay đổi lần này cần kiểm tra những nhiệm vụ nào. Những nhiệm vụ này có thể đến từ các vấn đề đã phát sinh trên production, cũng có thể đến từ các tính năng cốt lõi của sản phẩm, cũng như yêu cầu nghiệm thu của tính năng mới được bổ sung lần này.
Ví dụ, lần này sửa đổi skill hoàn tiền, thì cần kiểm tra các case hoàn tiền từng thất bại trước đó, các kịch bản hoàn tiền phổ biến khác, cũng như các quy trình cốt lõi có thể bị ảnh hưởng như tra cứu đơn hàng, hủy đơn hàng,... Gom những nhiệm vụ này lại với nhau, bạn mới biết đợt đánh giá lần này đã bao quát những gì.
2. Bổ sung đầy đủ điều kiện của case, viết rõ tiêu chuẩn hoàn thành
Sau khi chọn xong nhiệm vụ, hãy tổ chức nó thành các case có thể thực thi và đánh giá. Ở đây cần giữ lại context và trạng thái nghiệp vụ cần thiết, đồng thời viết rõ kết quả kỳ vọng.
Ví dụ, người dùng lúc đầu yêu cầu hủy đơn hàng A, trước khi Agent thực hiện thao tác lại đổi mục tiêu thành đơn hàng B, nhưng Agent cuối cùng vẫn thao tác trên đơn hàng A. Case này cần giữ lại đoạn hội thoại người dùng thay đổi ý định, trạng thái ban đầu của hai đơn hàng, cũng như mục tiêu cuối cùng mà người dùng xác nhận. Nếu cả hai đơn hàng đều thỏa mãn điều kiện hủy, kết quả kỳ vọng sẽ là: Đơn hàng B bị hủy, đơn hàng A giữ nguyên trạng thái.
Tiếp theo là xác định cách kiểm tra kết quả này. Nội dung nào có thể xác thực trực tiếp thì dùng code để kiểm tra, phần nào cần hiểu ngữ nghĩa thì kết hợp đánh giá thủ công hoặc dùng model. Trong ví dụ này, có thể kiểm tra trực tiếp trạng thái cuối cùng của hai đơn hàng. Như vậy là đã có một case hoàn chỉnh: giao cho Agent nhiệm vụ gì, thực thi trong điều kiện nào, và làm sao để phán đoán xem nó đã hoàn thành hay chưa.
3. Chuẩn bị môi trường chạy nhất quán
Khi so sánh các phiên bản khác nhau, ngoại trừ những thay đổi dự định so sánh lần này, các điều kiện khác cần giữ nhất quán tối đa. Chẳng hạn khi chỉ sửa skill, thì nhiệm vụ, model, cách hiện thực tool và quy tắc chấm điểm không nên đồng thời thay đổi, nếu không sẽ rất khó xác định sự khác biệt về kết quả đến từ đâu.
Trạng thái nghiệp vụ cũng cần được khôi phục trước mỗi lần chạy . Nếu phiên bản cũ đã hủy đơn hàng mà phiên bản mới lại tiếp tục sử dụng trạng thái này thì sẽ không thể so sánh trực tiếp được. Việc đánh giá có thể tiến hành trong môi trường test độc lập, đồng thời để cấu hình model, hành vi của tool và quy tắc nghiệp vụ càng gần với điều kiện sử dụng thực tế càng tốt. Code, prompt, skill và phiên bản nhiệm vụ tương ứng cũng cần được ghi nhận lại.
4. Chạy đánh giá, đối chiếu phiên bản mới và cũ
Hãy để phiên bản cũ và phiên bản đã chỉnh sửa cùng xử lý một batch nhiệm vụ, kiểm tra kết quả theo cùng một tiêu chuẩn. Đối với những nhiệm vụ cần đánh giá độ ổn định, còn cần lặp lại việc thực thi trong cùng điều kiện ban đầu để quan sát tình hình thành công và thất bại.
Khi so sánh, ngoài việc xem xét hiệu năng tổng thể, bạn còn cần xem cụ thể những nhiệm vụ nào từ thất bại đã chuyển thành thành công, và những nhiệm vụ nào vốn dĩ bình thường lại bị thoái hóa. Đồng thời giữ lại trace, căn cứ chấm điểm, cũng như các ghi nhận về thời gian tiêu tốn, lượng token sử dụng, số lần gọi tool,... Như vậy, sau khi phát hiện khác biệt mới có thể tiếp tục phân tích nguyên nhân, và cũng có thể đánh giá xem việc cải tiến có mang lại thời gian và chi phí phát sinh hay không.
5. Xử lý kết quả đánh giá, liên tục bổ sung case
Dựa vào kết quả để phán đoán xem có áp dụng thay đổi lần này hay không. Khi nhiệm vụ cốt lõi xuất hiện thất bại mới, cần kết hợp log thực thi để điều tra trước, sau đó mới xác định xem đã đủ điều kiện đưa lên production hay chưa. Sau khi fix xong thì kiểm tra lại, và giữ lại các vấn đề đã giải quyết để các phiên bản tiếp theo tiếp tục sử dụng.
Bộ nhiệm vụ này có thể đưa vào quy trình kiểm tra trước mỗi đợt release. Sau khi lên production, lại tiếp tục bổ sung các case và điều kiện nghiệp vụ mới từ phản hồi của người dùng thực tế. Nhờ đó, các vấn đề gặp phải trên production sẽ dần dần tích lũy thành căn cứ kiểm tra cho các đợt phát triển tiếp theo, và việc đánh giá cũng sẽ được cập nhật đồng hành cùng sản phẩm.
V. Tổng kết
Đánh giá có thể cung cấp cho chúng ta căn cứ để phán đoán, nhưng căn cứ này có đáng tin cậy hay không thì còn phụ thuộc vào việc chúng ta chọn những case nào, tiêu chuẩn được viết ra sao, và được chạy trong điều kiện nào. Dưới đây là một số vấn đề cần lưu ý.
1. Case ban đầu đã pass không có nghĩa là các vấn đề tương tự đều đã được giải quyết
Ví dụ, chúng ta liên tục sửa đổi prompt và skill dựa trên cùng một nhóm case thất bại, cuối cùng các case này đều đã pass. Nhưng khi đổi sang các nhiệm vụ tương tự mới, liệu có còn hoàn thành bình thường được hay không thì vẫn cần tiếp tục kiểm tra. Vì vậy, ngoài việc giữ lại những case này để làm kiểm thử hồi quy, bạn cũng cần chuẩn bị một số case chưa từng được dùng để tinh chỉnh, nhằm xem những sửa đổi trước đó có xử lý được các vấn đề tương tự khác hay không. Quá trình này khá giống với việc phân chia training set và test set trong huấn luyện machine learning.
2. Bản thân tiêu chuẩn đánh giá cũng có thể có vấn đề
Ví dụ, nghiệp vụ không hề yêu cầu thứ tự thao tác cố định, nhưng chúng ta lại bắt buộc Agent phải gọi tool theo một thứ tự nhất định, điều này có thể khiến một nhiệm vụ vốn dĩ đã hoàn thành lại bị phán định là thất bại. Do đó, khi thấy kết quả đánh giá bất thường, chúng ta cũng cần kết hợp trace và kết quả thực tế để kiểm tra xem rốt cuộc là Agent làm sai, hay là bộ đánh giá phán đoán chưa chính xác. Bản thân tiêu chuẩn đánh giá vốn là một vấn đề thuộc "vùng nước sâu" (vô cùng phức tạp). Thực tiễn tốt nhất hiện nay là để các chuyên gia nghiệp vụ đưa ra toàn bộ tiêu chuẩn trong hệ thống nghiệp vụ hiện tại của chúng ta.
3. Nhiệm vụ thất bại cũng cần nhìn vào nguyên nhân cụ thể
Giả sử service đơn hàng trong môi trường test không khả dụng, dẫn đến một loạt nhiệm vụ thất bại, chúng ta không thể quy chụp ngay là do model hay skill gặp vấn đề. Nhưng nếu là do Agent truyền sai tham số, hoặc không xử lý exception của service theo đúng yêu cầu, thì những hành vi này vẫn cần phải kiểm tra. Giữ lại nguyên nhân thất bại thì sau này mới biết nên sửa ở đâu.
4. Sau khi lên production, vẫn cần tiếp tục quan sát
Các case chúng ta chuẩn bị rất khó bao quát toàn bộ cách diễn đạt của người dùng cũng như các tình huống nghiệp vụ. Dù đánh giá đã pass, sau khi lên production vẫn có thể gặp phải những vấn đề chưa từng lường trước. Những phản hồi mới này vẫn cần tiếp tục được gom vào bộ đánh giá, làm căn cứ kiểm tra cho các lần chỉnh sửa và release tiếp theo.
Nhận định hiện tại của tôi là: Đánh giá Agent đã trở thành nền tảng cốt lõi của việc phát triển Agent. Trong quá trình liên tục chỉnh sửa tool, prompt, skill và Agent runtime, chúng ta cần một phương pháp có thể tái sử dụng nhiều lần để phán đoán xem lần sửa này đã giải quyết được vấn đề hay chưa, những nhiệm vụ vốn dĩ hoàn thành được có bị ảnh hưởng hay không. Có như vậy, khi lặp phát triển nhanh chóng, chúng ta mới nắm chắc hơn về biểu hiện của phiên bản hiện tại.
Đồng thời, trong quá trình làm đánh giá, chúng ta cũng cần liên tục thảo luận: người dùng rốt cuộc mong muốn hoàn thành nhiệm vụ gì, kết quả thế nào mới được coi là làm tốt, những thao tác nào là không thể chấp nhận được. Bản thân những cuộc thảo luận này sẽ giúp chúng ta làm rõ hơn nhu cầu của sản phẩm. Vì vậy, đánh giá Agent không chỉ giúp nâng cao hiệu quả lặp cải tiến chung của sản phẩm, mà còn giúp chúng ta nhận thức rõ hơn sản phẩm cần những gì, cũng như làm thế nào để phục vụ người dùng tốt hơn.
Đây là bài viết đầu tiên của tôi trong series về đánh giá Agent, chủ yếu giới thiệu với các bạn đánh giá Agent là gì, giúp mọi người hiểu được các công ty công nghệ lớn hiện nay nhìn nhận đánh giá Agent như thế nào. Sau này tôi sẽ cập nhật đầy đủ tất cả những gì mình học được/suy ngẫm về đánh giá, chẳng hạn như:
- Cách làm đánh giá cụ thể: LLM as a Judge...
- Các công cụ và thực tiễn thường dùng
Rất mong bạn follow và cũng hoan nghênh bạn đặt câu hỏi nhé ~
Học tương tác với AI (NotebookLM)
Ngoài đọc , bạn có thể nghe , xem và xem hoạ thông tin ở đầu bài. Bài này còn có bộ công cụ tương tác do AI tạo: Bài kiểm tra trắc nghiệm, Thẻ ghi nhớ, Sơ đồ tư duy, Bản trình bày và Báo cáo chuyên sâu.
Mở không gian học tương tác