Việc áp dụng không còn là phần khó. Stanford AI Index 2026 ghi nhận mức áp dụng AI ở cấp tổ chức đạt 88%, và AI tạo sinh đạt 53% dân số áp dụng chỉ trong ba năm, nhanh hơn cả máy tính cá nhân hay internet. Phần khó đến sau đó: ai đó trong đội phải quyết định trả tiền cho công cụ nào, rồi bảo vệ lựa chọn ấy khi hóa đơn hoặc chất lượng đầu ra bị đặt câu hỏi. Bài viết này nói về việc đưa ra quyết định đó dựa trên bằng chứng. Chúng tôi trình bày các loại bằng chứng hiện có, sáu phép thử để áp dụng cho bất kỳ đánh giá đã công bố nào trước khi dựa vào nó, và một scorecard mà đội kỹ thuật có thể tự chạy nội bộ.
Chọn công cụ AI giờ là nút thắt
Dòng tiền đang chảy nhanh hơn khả năng đánh giá thứ nó mua về. Vào tháng 9/2026, Gartner dự báo tổng chi tiêu AI toàn cầu năm 2026 sẽ đạt 2,7 nghìn tỷ USD, tăng 49,5% so với năm trước, trong đó riêng phân khúc phần mềm AI tăng từ khoảng 288 tỷ USD năm 2025 lên khoảng 462 tỷ USD năm 2026.
Đồng thời, việc sử dụng đang lan rộng trong doanh nghiệp. Trong khảo sát State of AI của McKinsey, công bố tháng 8/2026, 44 phần trăm người trả lời cho biết AI đang được mở rộng trên toàn doanh nghiệp, tăng từ 38 phần trăm một năm trước, và tỷ lệ báo cáo dùng AI ở ba chức năng kinh doanh trở lên tăng từ 51 lên 56 phần trăm. Mỗi chức năng đó là một quyết định công cụ riêng, thường do một người khác nhau đưa ra, với quan niệm khác nhau về thế nào là tốt.
Không đội nào có thể thử hết mọi ứng viên. Vì vậy ai cũng phải dựa vào phán đoán của người khác: một trang của vendor, một trang review, một bảng xếp hạng, lời giới thiệu của đồng nghiệp. Điều đó hợp lý. Kỹ năng đáng xây dựng là biết mỗi nguồn đó chịu được bao nhiêu trọng lượng, và điều đó bắt đầu từ lý do công cụ AI khó đánh giá hơn loại phần mềm mà chúng ta quen mua.
Vì sao công cụ AI không tuân theo cách đánh giá phần mềm thông thường
Chúng ta đánh giá một cơ sở dữ liệu hay hệ thống CI bằng cách đọc tài liệu, chạy PoC và kiểm tra kết quả. Năm đặc tính của công cụ AI phá vỡ quy trình đó.
Đầu ra không mang tính tất định. Cùng một đầu vào có thể cho kết quả khác ở lần chạy sau. Hướng dẫn về đầu ra có thể tái lập của chính OpenAI, công bố tháng 11/2023, nói rằng ngay cả khi cố định seed thì "không đảm bảo tính tất định" và các thay đổi ở backend có thể làm đổi kết quả. Vì vậy một câu trả lời tốt trong bản demo chứng minh được rất ít. Điều quan trọng là độ phân tán qua nhiều lần chạy cùng một đầu vào.
Cơ chế tính phí che giấu chi phí hằng tháng. Nhiều công cụ tạo sinh bán credit, phút hoặc token thay vì theo seat. Trang giá của Runway, theo bản chúng tôi đọc ngày 2/10/2026, niêm yết gói Standard ở mức 15 USD mỗi tháng khi trả theo tháng, với 625 credit, và cho biết model Gen-4.5 tiêu tốn 12 credit cho mỗi giây video được tạo. Tức là 52 giây đầu ra mỗi tháng, và trang này nói thêm rằng credit hằng tháng của gói đó không được cộng dồn sang tháng sau. Giá đăng ký cho bạn biết rất ít cho đến khi bạn biết cần bao nhiêu lần thử để có một kết quả dùng được.
Nhịp phát hành làm đánh giá lỗi thời. Cũng báo cáo của Stanford ghi nhận rằng kết quả trên SWE-bench Verified, một benchmark lập trình, tăng từ 60% lên gần 100% chỉ trong một năm. Một bài đánh giá viết dựa trên model năm ngoái mô tả một sản phẩm đã bị thay thế, thường vẫn dưới cùng một cái tên.
Benchmark có thể bị chính các công ty được đo điều hướng. The Leaderboard Illusion, một nghiên cứu năm 2025 về bảng xếp hạng Chatbot Arena, phát hiện rằng việc thử nghiệm riêng không công bố cho phép một số ít nhà cung cấp thử nhiều biến thể trước khi phát hành công khai và chỉ công bố điểm tốt nhất. Các tác giả xác định có 27 biến thể riêng được Meta thử trước khi phát hành Llama-4.
Danh sách xếp hạng có thể chạy theo tiền. Một trang nhận hoa hồng trên mỗi lượt nhấp có lý do để sắp danh sách theo mức chi trả. Nếu trang không nói thứ tự được tạo ra thế nào, người đọc không thể biết có như vậy hay không.
Năm loại bằng chứng và giá trị của từng loại
Mọi điều bạn có thể biết về một công cụ trước khi mua đều đến qua một trong năm kênh. Mỗi kênh chứng minh được một số điều, không chứng minh được những điều khác, và bị lách theo cách riêng.
Tài liệu của vendor
Trang giá, bảng hạn mức, tài liệu API, changelog và điều khoản xử lý dữ liệu là nguồn đáng tin nhất cho các giới hạn cứng, vì vendor phải chịu trách nhiệm về chúng. Chúng chứng minh được một gói bao gồm gì, giới hạn ở đâu và giá bao nhiêu. Chúng không chứng minh được chất lượng. Việc lách chủ yếu là bằng cách bỏ sót: dùng tính từ ở chỗ lẽ ra phải có con số, và giới hạn chỉ xuất hiện trong một bài ở trung tâm trợ giúp.
Đánh giá của đám đông
Đánh giá của người dùng chứng minh rằng khách hàng thật tồn tại và cho thấy điều gì làm họ khó chịu sau tháng đầu tiên. Chúng không chứng minh được sự phù hợp với trường hợp của bạn, vì người đánh giá tự chọn mình và thường dùng sản phẩm khác cách bạn sẽ dùng. Đây cũng là kênh bị lách công khai nhất. Quy định năm 2024 của Ủy ban Thương mại Liên bang Mỹ (FTC) về đánh giá và lời chứng thực cấm đánh giá giả, kể cả đánh giá do AI tạo ra, và cấm doanh nghiệp đưa ra ưu đãi gắn với việc đánh giá thể hiện một quan điểm nhất định. Cơ quan quản lý không ban hành quy định cho một vấn đề hiếm gặp. Hãy đọc điểm số của đám đông để lấy các chi tiết cụ thể trong nội dung, và kiểm tra nền tảng xác thực người đánh giá thế nào.
Benchmark và bảng xếp hạng
Một benchmark chứng minh hiệu năng tương đối trên một tác vụ cố định trong điều kiện cố định, hữu ích để thu hẹp danh sách rút gọn. Nó không chứng minh được hiệu năng trên đầu vào của bạn, và các benchmark phổ biến bị bão hòa, như con số SWE-bench ở trên cho thấy. Việc lách là công bố có chọn lọc và tinh chỉnh theo bài kiểm tra. Hãy ưu tiên các benchmark công bố danh sách tác vụ, quy tắc chấm điểm và số lần lặp.
Đánh giá biên tập có phương pháp được công bố
Một đánh giá biên tập có thể chứng minh rằng ai đó đã so sánh nhiều công cụ theo cùng tiêu chí. Nó chỉ mạnh bằng bằng chứng đứng sau: đọc tài liệu trên bàn không phải là kiểm thử thực tế, và một người đánh giá tốt sẽ nói rõ mình đã làm điều nào. Việc lách ở đây mang tính thương mại, qua tài trợ hoặc quan hệ affiliate không được công bố. Sáu phép thử ở phần tiếp theo được viết cho kênh này, và hầu hết cũng áp dụng được cho benchmark và nền tảng review.
Bản pilot của chính bạn
Bản pilot chứng minh điều duy nhất mà không nguồn bên ngoài nào làm được: công cụ hoạt động thế nào trên đầu vào của bạn, ở khối lượng của bạn, trên gói bạn sẽ mua. Nó không chứng minh được nhiều hơn mẫu bạn đã chạy, và là loại bằng chứng tốn kém nhất để tạo ra. Người dễ lách nó nhất là chính bạn, bằng cách chọn đầu vào sau khi đã thấy đầu ra hoặc bảo vệ một công cụ mà đội vốn đã thích. Một quy trình bằng văn bản, trình bày bên dưới, là cách kiểm soát.
Sáu phép thử cho mọi đánh giá bạn định tin
Mỗi phép thử có thể kiểm tra trong vài phút bằng cách đọc chính các trang của bên đánh giá. Để cho thấy thế nào là đạt, chúng tôi dẫn các tài liệu phương pháp công khai của bốn bên đánh giá thuộc những loại rất khác nhau: Artificial Analysis, đơn vị benchmark các model AI; G2, một marketplace review phần mềm doanh nghiệp; RTINGS, đơn vị kiểm thử phần cứng tiêu dùng trong phòng thí nghiệm; và Catalora, một danh bạ biên tập các công cụ AI cho người làm video và hình ảnh. Chúng tôi mô tả những gì mỗi trang nêu vào ngày 2/10/2026. Chúng tôi không kiểm toán xem thực tế có khớp với trang hay không, và không xếp hạng bốn đơn vị này với nhau.
1. Rubric được công bố
Một điểm số bạn không tháo rời ra được chỉ là một ý kiến. Artificial Analysis công bố thành phần của Intelligence Index: phiên bản 4.3.2 kết hợp mười bài đánh giá theo trung bình có trọng số trên bốn nhóm (agent 30%, lập trình 20%, suy luận khoa học 20%, tổng quát 30%), kèm trọng số của từng bài. RTINGS nêu trong bài cách kiểm thử màn hình rằng Test Bench 2.1 của họ gồm 375 bài kiểm tra riêng lẻ và mọi màn hình đều đi qua cùng một bench. Câu hỏi cần đặt ra là liệu bạn có thể tính lại con số tiêu đề từ các thành phần của nó hay không.
2. Mỗi tiêu chí nêu rõ bằng chứng nó cần
Một tiêu chí gọi là "chất lượng" chẳng có nghĩa gì cho đến khi bên đánh giá nói cái gì được tính là bằng chứng cho nó. Trang của Catalora về cách chấm điểm công cụ AI liệt kê năm trục (dễ sử dụng, chất lượng đầu ra, giá trị so với chi phí, tốc độ và hiệu năng, hỗ trợ và tài liệu) và với mỗi trục nêu bằng chứng cần có, ý nghĩa của các dải điểm và khi nào trục bị giữ lại không chấm. Cũng trang đó nói rằng các đánh giá của họ dựa trên bằng chứng có tài liệu và báo cáo độc lập, và họ không mua rồi chạy thử mọi công cụ. Đó là mức chi tiết nên tìm: người đọc thấy được loại bằng chứng nào nằm sau một con số, và loại nào không. Bảng của Artificial Analysis làm điều tương tự cho một benchmark, liệt kê số câu hỏi, số lần lặp và quy tắc chấm điểm của từng bài đánh giá.
3. Bên đánh giá từ chối chấm điểm khi thiếu bằng chứng
Một bên đánh giá có con số cho mọi thứ là đang đoán ở đâu đó. Phương pháp chấm điểm nghiên cứu của G2 đặt ra các ngưỡng: một sản phẩm cần ít nhất 10 review trong một danh mục để được đưa vào báo cáo Grid của danh mục đó, và bản thân danh mục cần ít nhất sáu sản phẩm có từ 10 review trở lên và tổng cộng 150 review. Hãy tìm quy tắc tương đương ở bất cứ nơi nào bạn đọc một điểm số, và tìm trạng thái "chưa đánh giá" hiển thị rõ khi quy tắc không được đáp ứng.
4. Phán đoán biên tập và cảm nhận của đám đông được tách riêng
Đánh giá của chuyên gia và cảm nhận của người dùng đều hữu ích, và chúng là hai phép đo khác nhau. Gộp thành một con số thì không cái nào kiểm chứng được. Trang của G2 về review, dữ liệu và xếp hạng vạch ranh giới từ phía đám đông: trang nói review là lời kể chủ quan về trải nghiệm của từng người dùng, không phải đánh giá chuyên gia, và G2 không thêm đầu vào chủ quan nào vào điểm số. RTINGS vạch ranh giới từ phía phòng thí nghiệm. Độc giả của họ bình chọn màn hình nào sẽ được mua và kiểm thử tiếp theo, nên đám đông ảnh hưởng đến việc chọn mẫu, còn điểm số đến từ test bench.
5. Vị trí trả tiền được gắn nhãn và không thể thay đổi thứ hạng
Hầu hết bên đánh giá cần doanh thu, nên câu hỏi là tiền có thể chạm tới đâu. Cũng trang G2 đó nói họ bán quảng cáo ở các vị trí được tài trợ, điều này không ảnh hưởng đến thứ hạng tự nhiên của sản phẩm, và huy hiệu không thể mua. Trang của RTINGS nói họ mua mọi thiết bị ở cửa hàng bán lẻ và không nhận mẫu review từ các thương hiệu, điều này đóng hoàn toàn một kênh gây ảnh hưởng. Dù mô hình kinh doanh là gì, bạn cũng nên tìm được một câu nói rõ vendor có thể mua gì và không thể mua gì.
6. Có ngày tháng, đính chính và quyền phản hồi
Một đánh giá không có ngày thì không thể xét độ cũ. RTINGS liệt kê các phiên bản test bench màn hình kèm ngày, từ 1.0 vào tháng 10/2017 đến 2.1.2 vào tháng 3/2026, và nói họ kiểm thử lại màn hình khi bench thay đổi. G2 yêu cầu bất kỳ ai trích dẫn xếp hạng danh mục phải ghi ngày truy xuất. Chính sách biên tập của Catalora nói mỗi trang công cụ đều ghi ngày các sự kiện được xác minh lần gần nhất, các đính chính quan trọng được thực hiện ngay trên trang và được đánh dấu khi chúng thay đổi nhận định, và vendor không thể xem trước hay duyệt một bài đánh giá nhưng có thể gửi bằng chứng sau đó để một sự kiện được kiểm tra lại.
Không phép thử nào trong sáu phép thử cho bạn biết một đánh giá là đúng. Chúng cho bạn biết đánh giá đó có kiểm chứng được hay không, nghĩa là khi nó sai, bạn có cách để phát hiện. Một bên đánh giá cũng có thể đạt cả sáu mà đơn giản là không bao phủ danh mục của bạn. Trong trường hợp đó, phương pháp vẫn đáng để mượn.
Áp dụng cùng kỷ luật đó trong nội bộ
Các phép thử này cũng áp dụng cho chính đánh giá của bạn. Khác biệt là bạn có thể tạo ra loại bằng chứng thứ năm, bản pilot, thứ mà không bên đánh giá bên ngoài nào làm giúp bạn được.
Đặt trọng số trước khi nhìn vào vendor. Với mỗi use case, hãy quyết định điều gì quan trọng và quan trọng đến đâu, và ghi ra trước buổi demo đầu tiên. Trọng số chọn sau khi có danh sách rút gọn có xu hướng mô tả công cụ mà đội vốn đã ưa thích.
Viết quy trình pilot. Cố định một tập đầu vào lấy từ công việc thật, bao gồm cả các ca khó chịu. Chạy mỗi đầu vào nhiều lần, vì đầu ra không tất định, và ghi lại mọi đầu ra chứ không chỉ kết quả tốt nhất. Khi có thể, hãy để người review chấm điểm đầu ra mà không biết công cụ nào đã tạo ra. Trong hướng dẫn tích hợp AI của chúng tôi, chúng tôi mô tả dạng liên tục của việc này: một evaluation suite chạy mỗi khi prompt hoặc model thay đổi.
Tính chi phí ở gói bạn thực sự sẽ mua. Lấy gói đáp ứng khối lượng của bạn, không phải mức giá đầu vào, và chia cho số đầu ra bạn chấp nhận, không phải số bạn đã tạo. Với công cụ tính phí theo credit, các lần thử lại chính là hóa đơn.
Đặt ngày đánh giá lại. Model, giá và giới hạn thay đổi chỉ trong vài tháng. Một bản đánh giá không có ngày hết hạn sẽ dần biến thành một giả định.
Một scorecard gọn cho một use case có thể trông như sau. Các giá trị chỉ là ví dụ; giá trị của bạn nên xuất phát từ use case.
- Use case và người chịu trách nhiệm: một câu mô tả công việc, và một người được nêu tên ký xác nhận kết quả.
- Trọng số, cố định trước khi có danh sách rút gọn: chất lượng đầu ra 40%, chi phí trên mỗi đầu ra được chấp nhận 25%, dễ áp dụng 15%, tốc độ 10%, hỗ trợ và tài liệu 10%.
- Bằng chứng cho từng tiêu chí: chất lượng từ các đầu ra được chấm mù trên 20 đầu vào cố định, mỗi đầu vào chạy ba lần; chi phí từ gói bạn sẽ mua chia cho số đầu ra được chấp nhận; tốc độ được đo thời gian trên cùng các đầu vào.
- Quy tắc giữ lại không chấm: tiêu chí không có bằng chứng được ghi là chưa đánh giá, và công cụ thiếu một tiêu chí thì không có tổng điểm.
- Điều kiện loại: điều khoản xử lý dữ liệu mà bộ phận rà soát bảo mật của bạn từ chối, hoặc không có cách xuất công việc của bạn ra.
- Ngày đánh giá lại: 90 ngày sau, hoặc sớm hơn khi model hay giá có thay đổi lớn.
Kỷ luật này cũng chính là kỷ luật chúng tôi áp dụng với AI trong công việc giao hàng của mình: một senior engineer viết đặc tả, một senior engineer review mọi đầu ra, và người chịu trách nhiệm kết quả ký duyệt. Một đợt đánh giá công cụ xứng đáng có cùng một người chịu trách nhiệm được nêu tên và cùng một bước review như vậy.
Điều rút ra từ bài viết này
Nguồn cung công cụ AI giờ vượt quá khả năng thử của bất kỳ ai, nên kỹ năng khan hiếm là đánh giá. Hãy biết bạn đang nhìn loại bằng chứng nào trong năm loại và nó chứng minh được gì. Trước khi tin một đánh giá đã công bố, hãy kiểm tra sáu điều mà chính các trang của nó nên cho bạn biết. Sau đó chạy một bản pilot nhỏ, bằng văn bản, trên đầu vào của chính bạn, vì đó là bằng chứng duy nhất về use case của bạn. Trang phương pháp của chúng tôi mô tả cách iPlus áp dụng review của senior vào giao hàng có AI hỗ trợ cho khách hàng.
Cần hỗ trợ về chủ đề này?
Các dịch vụ của iPlus liên quan nhất đến bài viết.
