LangSmith, Braintrust và Langfuse đứng trước cách tiếp cận kiểm tra AI mới

Một hệ thống trí tuệ nhân tạo có thể trả lời cùng một câu hỏi theo cách nhất quán, nhưng toàn bộ ứng dụng sử dụng nó vẫn có thể đưa ra những quyết định khác nhau. Đây là vấn đề đáng quan tâm khi doanh nghiệp chuyển AI từ công cụ hỗ trợ soạn thảo sang hệ thống có khả năng phân loại hồ sơ, đánh dấu rủi ro, phê duyệt yêu cầu hoặc ghi nhận quyết định chính thức.

CTGT, một công ty nghiên cứu cách các mô hình AI và phần mềm xung quanh chúng hoạt động, vừa công bố Concordance, công cụ mã nguồn mở giúp truy tìm nguyên nhân khiến ứng dụng AI đưa ra những kết quả không nhất quán. Phần mềm được phát hành theo giấy phép Apache 2.0, cho phép doanh nghiệp sử dụng và sửa đổi cho mục đích thương mại.

Lý do đằng sau công cụ này đến từ một thử nghiệm nội bộ có kết quả đáng chú ý. Khi xử lý cùng một sổ tay ngân hàng bán lẻ dài chín trang bốn lần, ứng dụng tuân thủ của CTGT tạo ra bốn danh sách nghĩa vụ khác nhau. Một lần chạy bỏ sót yêu cầu chuyển một vấn đề nghiêm trọng lên người đứng đầu bộ phận tuân thủ.

Vấn đề không đơn giản là mô hình AI ngẫu nhiên trả lời khác nhau. CTGT phát hiện rằng ngay cả khi mô hình nhận được những yêu cầu giống hệt nhau và trả lời nhất quán, phần mềm điều phối phía trước vẫn có thể thay đổi dữ liệu đầu vào. Kết quả là toàn bộ ứng dụng đưa ra quyết định khác biệt.

CTGT phát hành Concordance theo giấy phép mã nguồn mở

Concordance được thiết kế để giúp doanh nghiệp điều tra những khác biệt trong hoạt động của ứng dụng AI. Theo CTGT, bản phát hành bao gồm quy trình kiểm thử, phần triển khai tham chiếu và dữ liệu thử nghiệm.

Công ty cho biết chưa có kế hoạch cung cấp phiên bản Concordance trả phí hoặc phiên bản được lưu trữ như một dịch vụ riêng. Điều này giúp công cụ có thể được doanh nghiệp đưa vào quy trình kiểm tra hiện tại mà không phải mua một gói dịch vụ Concordance thương mại.

CTGT tự mô tả mình là một phòng nghiên cứu về khả năng diễn giải AI trong môi trường ứng dụng thực tế, đặc biệt ở những lĩnh vực như ngân hàng và bảo hiểm. Hoạt động kinh doanh thương mại của công ty còn bao gồm một công cụ thực thi chính sách dành cho doanh nghiệp chịu sự quản lý chặt chẽ. Sản phẩm này tách biệt với Concordance.

Điểm đáng chú ý là công cụ mới không cố gắng thay thế toàn bộ hệ thống giám sát AI hiện có. Thay vào đó, Concordance tập trung vào một câu hỏi cụ thể: nếu cùng một công việc tạo ra những kết quả khác nhau, sự khác biệt bắt đầu xuất hiện ở bước nào?

Câu hỏi này quan trọng bởi một ứng dụng AI thường gồm nhiều thành phần. Ngoài mô hình, hệ thống còn có thể bao gồm bước tải tài liệu lên, xử lý dữ liệu, sắp xếp thông tin, lựa chọn công cụ, xây dựng yêu cầu gửi đến mô hình và chuyển kết quả thành hành động nghiệp vụ.

Nếu chỉ kiểm tra câu trả lời cuối cùng, doanh nghiệp có thể nhìn thấy lỗi nhưng không biết lỗi bắt nguồn từ đâu.

Bốn lần xử lý một tài liệu tạo ra bốn danh sách nghĩa vụ khác nhau

Trong thử nghiệm được CTGT công bố, ứng dụng của công ty xử lý một sổ tay ngân hàng bán lẻ dài chín trang bằng mô hình Qwen3.8-27B, sử dụng chế độ suy luận xác định của hệ thống phục vụ mô hình SGLang.

Bốn lần chạy trích xuất lần lượt 32, 31, 33 và 33 nghĩa vụ. Ngay cả khi hai lần chạy tạo ra cùng số lượng nghĩa vụ, nội dung bên trong vẫn không giống nhau. Cả bốn kết quả đều khác biệt.

Điều này cho thấy số lượng mục được trích xuất không phải thước đo đầy đủ về độ tin cậy. Hai danh sách có cùng số dòng vẫn có thể chứa những nghĩa vụ khác nhau, và một nghĩa vụ bị bỏ sót có thể quan trọng hơn nhiều mục được trích xuất chính xác.

Trong trường hợp cụ thể này, một lần chạy bỏ qua yêu cầu chuyển vấn đề nghiêm trọng lên người đứng đầu bộ phận tuân thủ. Với quy trình ngân hàng, sự khác biệt đó có thể ảnh hưởng đến việc một trường hợp được chuyển cấp xử lý hay bị giữ lại ở bước thông thường.

Cần nhấn mạnh rằng đây là thử nghiệm trên ứng dụng nội bộ của CTGT với một tài liệu cụ thể. Dữ liệu được công bố không chứng minh hiện tượng xảy ra với cùng tần suất ở mọi ứng dụng AI doanh nghiệp, cũng không cho phép kết luận rằng tất cả mô hình AI đều có vấn đề tương tự.

Tuy nhiên, thử nghiệm cung cấp một ví dụ rõ ràng về cách một lỗi trong phần mềm ứng dụng có thể làm thay đổi kết quả, ngay cả khi mô hình bên dưới hoạt động nhất quán.

Ba lỗi trong phần mềm đã làm thay đổi kết quả AI

Theo CTGT, nguyên nhân không nằm ở việc mô hình liên tục thay đổi câu trả lời cho cùng một yêu cầu. Trong 74 yêu cầu giống hệt nhau xuất hiện lặp lại giữa các lần chạy, mô hình trả về phản hồi nhất quán.

Sự khác biệt xuất hiện vì ứng dụng đã gửi những yêu cầu không hoàn toàn giống nhau. CTGT xác định ba nguyên nhân chính.

Thứ nhất, các mã định danh được tạo riêng cho từng lần tải tài liệu xuất hiện trong nội dung yêu cầu gửi đến mô hình. Dù những mã này không nhất thiết thay đổi ý nghĩa nghiệp vụ, sự xuất hiện của chúng làm cho yêu cầu khác biệt ở cấp độ văn bản.

Thứ hai, một danh sách điều hướng gồm 30 mục thay đổi thứ tự giữa các lần chạy. Việc sắp xếp khác nhau khiến nội dung gửi đi không còn giống nhau hoàn toàn.

Thứ ba, danh mục chủ đề được mở rộng giữa các lần chạy, làm thay đổi những yêu cầu được tạo ở các bước tiếp theo.

Trong một ví dụ so sánh, chỉ bốn dòng chứa mã định danh khác nhau trong yêu cầu dài 12.525 ký tự. Tuy nhiên, sự khác biệt nhỏ này đi cùng với thay đổi trong cách mô hình phân loại năm quy tắc giải quyết xung đột. Những quy tắc đó bị xem là thông tin nền thay vì nghĩa vụ phải giữ lại, khiến một kết quả bỏ sót nội dung mà lần chạy khác vẫn trích xuất được.

Đây là bài học quan trọng về kiến trúc ứng dụng AI. Một thay đổi nhỏ trong dữ liệu đầu vào có thể lan truyền qua nhiều bước xử lý và cuối cùng làm thay đổi quyết định nghiệp vụ.

Không phải mọi khác biệt văn bản đều gây ra sai lệch. Nhưng trong những hệ thống cần kết quả có thể kiểm tra và giải thích, doanh nghiệp cần biết sự khác biệt nào là vô hại, sự khác biệt nào làm thay đổi ý nghĩa và sự khác biệt nào có thể gây hậu quả.

Sau khi sửa lỗi, năm lần thử nghiệm tạo ra cùng 34 nghĩa vụ

CTGT đã thay mã định danh thay đổi theo từng lần tải bằng những nhãn ổn định, sắp xếp danh sách theo thứ tự cố định và cô lập từng thử nghiệm trong một môi trường tổ chức mới.

Sau những điều chỉnh này, năm lần chạy tiếp theo đều tạo ra cùng một danh sách gồm 34 nghĩa vụ.

Kết quả cho thấy việc kiểm soát phần mềm xung quanh mô hình có thể cải thiện tính nhất quán của toàn bộ quy trình. Không phải lúc nào doanh nghiệp cũng cần thay mô hình để giải quyết vấn đề. Đôi khi, điều cần sửa là cách ứng dụng chuẩn bị dữ liệu và xây dựng yêu cầu.

Tuy nhiên, kết quả nhất quán không đồng nghĩa với kết quả chính xác. CTGT cho biết khi phát lại yêu cầu đứng sau một lần phân loại sai, hệ thống lặp lại chính sai lầm đó tám lần.

Đây là sự khác biệt căn bản giữa khả năng tái lập và tính đúng đắn.

Một hệ thống có khả năng tái lập sẽ đưa ra cùng kết quả khi được chạy lại trong điều kiện tương ứng. Nhưng nếu kết quả ban đầu sai, việc lặp lại nó nhiều lần chỉ khiến sai lầm trở nên ổn định hơn.

Trong thử nghiệm phục vụ mô hình riêng của CTGT, Qwen3.8-27B khớp chính xác với phản hồi đối chứng ở cả 800 yêu cầu khi chạy với cấu hình xác định. Con số này đo mức độ giống nhau của văn bản đầu ra, không chứng minh rằng tất cả 800 câu trả lời đều đúng.

Vì vậy, doanh nghiệp cần hai loại kiểm tra khác nhau. Một loại xác định hệ thống có tái tạo được quyết định hay không. Loại còn lại xác định quyết định đó có phù hợp với quy định, dữ liệu nguồn và mục tiêu nghiệp vụ hay không.

Concordance tìm điểm khác biệt đầu tiên trong toàn bộ quy trình

Concordance kiểm tra cả lớp phần mềm phục vụ mô hình lẫn ứng dụng sử dụng mô hình. Công cụ ghi lại chính xác các yêu cầu và phản hồi, so sánh đầu ra ở những giai đoạn kế tiếp rồi xác định điểm đầu tiên mà kết quả bắt đầu khác nhau.

Cách tiếp cận này giúp tách biệt hai loại vấn đề.

Loại thứ nhất xảy ra khi mô hình nhận yêu cầu giống hệt nhau nhưng trả về câu trả lời khác nhau. Nguyên nhân có thể liên quan đến cách sinh văn bản hoặc những yếu tố kỹ thuật trong quá trình phục vụ mô hình.

Loại thứ hai xảy ra khi phần mềm ứng dụng thay đổi yêu cầu trước khi gửi đến mô hình. Khi đó, mô hình có thể đang phản hồi nhất quán với những đầu vào khác nhau, trong khi đội ngũ phát triển chỉ nhìn thấy kết quả cuối cùng không nhất quán.

Nghiên cứu của Thinking Machines Lab được nhắc đến trong bài viết gốc giúp giải thích rằng ngay cả khi đặt mức độ ngẫu nhiên ở mức thấp nhất, việc sinh câu trả lời vẫn không nhất thiết tạo ra kết quả giống hệt. Những thay đổi trong cách máy chủ gom các yêu cầu xử lý cùng lúc có thể ảnh hưởng đến phép tính số học và đầu ra.

CTGT sử dụng chế độ suy luận xác định của SGLang, được công ty cho biết có xây dựng dựa trên hướng nghiên cứu này. Tuy vậy, khả năng kiểm soát tính nhất quán của mô hình chỉ xử lý một phần vấn đề. Nếu ứng dụng gửi dữ liệu khác nhau, đầu ra cuối cùng vẫn có thể khác nhau.

Concordance được thiết kế để tìm ra sự khác biệt ở đâu trong chuỗi xử lý, chứ không tự động chứng minh rằng mọi quyết định đều đúng hoặc ngăn chặn mọi vi phạm chính sách.

Mô hình ra quyết định có thể giảm một phần rủi ro

Ngoài việc kiểm tra đầu ra, doanh nghiệp còn có thể thay đổi cách thiết kế ứng dụng để giảm khả năng AI đưa ra những lựa chọn ngoài phạm vi dự kiến.

Một ví dụ là hướng tiếp cận System One của TypeSafe, được thể hiện trong sản phẩm Jev. Thay vì yêu cầu mô hình tạo ra câu trả lời tự do, nhà phát triển xác định trước những lựa chọn hợp lệ. Mô hình trả về lựa chọn, điểm số hoặc xác suất để phần mềm tiếp tục xử lý.

Kiến trúc này cho phép giữ các quy tắc nghiệp vụ và quyền điều khiển quy trình trong mã phần mềm, đồng thời dùng AI để đánh giá những thông tin khó xử lý bằng quy tắc cứng.

Trong một quy trình tuân thủ, mô hình có thể phân loại một trường hợp xung đột, còn phần mềm bắt buộc chuyển cấp xử lý khi điều kiện tương ứng được đáp ứng. Như vậy, việc chuyển cấp không còn phụ thuộc hoàn toàn vào việc tác nhân AI có tự lựa chọn thực hiện bước đó hay không.

Đây là một hàm ý về thiết kế hệ thống, không phải cấu hình đã được CTGT kiểm nghiệm trong thử nghiệm ngân hàng nói trên.

Mô hình ra quyết định và Concordance giải quyết những lớp vấn đề khác nhau. Mô hình ra quyết định giới hạn dạng lựa chọn mà AI có thể đưa ra. Concordance kiểm tra xem toàn bộ ứng dụng có lặp lại quyết định hay không và xác định điểm phát sinh sai lệch.

Tuy nhiên, giới hạn câu trả lời trong một danh sách lựa chọn không bảo đảm mô hình chọn đúng phương án. Nếu bước xử lý tài liệu phía trước đã bỏ sót một nghĩa vụ, bộ phân loại ở phía sau cũng khó có thể thực thi chính xác quy tắc mà nó chưa nhận được.

TypeSafe cũng nêu những hạn chế của Jev phiên bản 1.13, gồm độ nhạy với thứ tự các lựa chọn và khó khăn khi xử lý ngữ cảnh không liên quan. Trong một thử nghiệm về tính nhất quán, nhãn kết quả thay đổi ở hai trong tám câu hỏi khi các yêu cầu lặp lại có thêm mã định danh mới. Vì đầu vào đã thay đổi, thử nghiệm này không chứng minh mô hình bất ổn khi nhận đầu vào hoàn toàn giống nhau; nó cho thấy chỉ giữ nguyên ý nghĩa nhiệm vụ chưa chắc đã đủ.

Với doanh nghiệp, cách tiếp cận hợp lý là kết hợp nhiều lớp bảo vệ. Giới hạn lựa chọn để giảm phạm vi lỗi, dùng mã phần mềm thực thi những quy tắc bắt buộc, sau đó kiểm tra toàn bộ quy trình để phát hiện khác biệt và đánh giá tính chính xác.

Dữ liệu hiện có không cung cấp phép so sánh trực tiếp giữa Concordance và Jev trên thử nghiệm ngân hàng của CTGT. Vì vậy, chưa có cơ sở để kết luận một phương pháp sẽ vượt trội hơn phương pháp còn lại.

Concordance bổ sung cho những công cụ giám sát AI hiện có

Thị trường đã có nhiều công cụ hỗ trợ theo dõi và kiểm tra ứng dụng AI. LangSmith cho phép đánh giá lặp lại, kiểm tra các quyết định trung gian của tác nhân và so sánh những phiên bản ứng dụng. Braintrust hỗ trợ chạy nhiều lần thử nghiệm, theo dõi lời gọi mô hình, chức năng ứng dụng và công cụ được sử dụng. Langfuse ghi nhận yêu cầu, phản hồi, các bước truy xuất dữ liệu, hoạt động của công cụ, mức sử dụng và thời gian xử lý. Arize Phoenix kết hợp theo dõi, đánh giá và thử nghiệm thông qua những chuẩn công cụ mở như OpenTelemetry và OpenInference.

CTGT định vị Concordance như một công cụ bổ sung cho các hệ thống này. Điểm khác biệt mà công ty nhấn mạnh là quy trình so sánh tập trung vào việc chạy lại nhiệm vụ, căn chỉnh các giai đoạn và xác định liệu sai lệch đến từ đầu vào hay phản hồi.

Tuy nhiên, CTGT chưa công bố một phép thử đối đầu chứng minh các nền tảng hiện có không thể phát hiện những lỗi tương tự. Những tính năng đã được công bố của các công cụ khác có phần giao nhau với các khả năng cần thiết để điều tra sai lệch.

Do đó, giá trị của Concordance sẽ phụ thuộc vào việc nó có giúp đội ngũ kỹ thuật tìm ra nguyên nhân nhanh hơn, làm cho quá trình điều tra dễ tái lập hơn và tích hợp thuận tiện với quy trình đang vận hành hay không.

CTGT cũng kể về một công ty tư vấn từng phát hiện những trường hợp cảnh báo sai bị bỏ qua bằng bộ công cụ LineageEval trước đây. Nhưng đó là câu chuyện liên quan đến một công cụ khác, không phải bằng chứng về kết quả triển khai Concordance tại khách hàng.

Doanh nghiệp nên ưu tiên những quyết định có hậu quả thực tế

Không phải mọi ứng dụng AI đều cần được kiểm tra với cùng mức độ nghiêm ngặt. Một công cụ soạn thảo nội dung mà con người luôn xem lại trước khi sử dụng có mức rủi ro khác với một tác nhân tự phê duyệt hồ sơ hoặc ghi nhận kết quả vào hệ thống chính thức.

Người sáng lập CTGT khuyến nghị doanh nghiệp ưu tiên những quyết định có hệ quả vận hành, như phê duyệt, đánh dấu rủi ro, xác định nghĩa vụ tuân thủ và xử lý yêu cầu bảo hiểm.

Đối với các quyết định này, doanh nghiệp nên lưu giữ đầy đủ yêu cầu và phản hồi tại những điểm mô hình thực sự đưa ra quyết định. Khi mô hình, câu lệnh, tài liệu nguồn hoặc phần mềm thay đổi, đội ngũ cần chạy lại các trường hợp kiểm thử đã biết kết quả mong đợi để xác định liệu hành vi có thay đổi hay không.

Một quy trình kiểm thử tốt cần có những ví dụ đáng tin cậy, trong đó doanh nghiệp biết trước kết quả phù hợp với chính sách. Việc so sánh đầu ra thực tế với các ví dụ này giúp phát hiện sự suy giảm chất lượng mà chỉ số tổng hợp có thể bỏ qua.

Doanh nghiệp cũng không nhất thiết phải tiếp cận được các trọng số mô hình hoặc thông tin nội bộ của nhà cung cấp mới có thể điều tra mọi vấn đề. Với mô hình được cung cấp qua giao diện lập trình ứng dụng, việc so sánh yêu cầu, phản hồi và quyết định vẫn có thể giúp tìm ra nhiều nguyên nhân ở cấp ứng dụng. Nếu có quyền tiếp cận trọng số mô hình, đội ngũ kỹ thuật có thể tiến hành những phân tích sâu hơn.

Điều quan trọng là không xem khả năng lặp lại như bằng chứng duy nhất của độ tin cậy. Một quyết định phải vừa có thể kiểm tra, vừa phù hợp với quy tắc và dữ liệu nguồn.

Doanh nghiệp Việt Nam có thể áp dụng cách tiếp cận này như thế nào?

Đối với doanh nghiệp Việt Nam đang đưa AI vào chăm sóc khách hàng, xử lý hồ sơ, tài chính hoặc quản lý vận hành, vấn đề không chỉ nằm ở việc chọn mô hình mạnh nhất. Cách ứng dụng chuẩn bị dữ liệu, gọi mô hình và chuyển câu trả lời thành hành động cũng quyết định độ tin cậy của toàn hệ thống.

Bước đầu tiên là xác định những quyết định nào có hậu quả thực tế. Nếu AI chỉ đề xuất nội dung để nhân viên xem xét, doanh nghiệp có thể bắt đầu bằng kiểm tra mẫu. Nếu AI tự động phân loại khiếu nại, đánh dấu giao dịch hoặc cập nhật hồ sơ, cần có nhật ký chi tiết và những trường hợp kiểm thử được xác nhận trước.

Tiếp theo, doanh nghiệp nên kiểm soát dữ liệu đầu vào. Các mã định danh không cần thiết nên được giữ ổn định hoặc loại bỏ khỏi nội dung gửi đến mô hình. Danh sách, cấu hình và dữ liệu tham chiếu cần có thứ tự nhất quán khi thứ tự đó có thể ảnh hưởng đến kết quả.

Thứ ba, hãy xây dựng bộ kiểm thử gồm những trường hợp bình thường và những tình huống dễ bị bỏ sót. Đối với quy trình tuân thủ, bộ kiểm thử cần bao gồm những nghĩa vụ bắt buộc, điều kiện chuyển cấp xử lý và các trường hợp có thông tin mâu thuẫn.

Thứ tư, tách những quy tắc bắt buộc khỏi phần phán đoán của mô hình. Nếu một điều kiện luôn yêu cầu chuyển cấp xử lý, phần mềm nên thực thi quy tắc đó trực tiếp thay vì chỉ hy vọng AI nhớ thực hiện.

Cuối cùng, doanh nghiệp có thể đánh giá Concordance cùng những công cụ theo dõi hiện có trong một quy trình thử nghiệm nhỏ. Vì phần mềm được phát hành theo giấy phép Apache 2.0, doanh nghiệp có thể sử dụng và sửa đổi theo các điều khoản của giấy phép. Tuy nhiên, việc tích hợp vẫn cần công sức kỹ thuật, lưu trữ dữ liệu và thiết kế quy trình kiểm thử. Công cụ cũng không thay thế việc xác minh kết quả theo chính sách của tổ chức.

Độ tin cậy của AI bắt đầu từ khả năng giải thích và kiểm tra

Concordance đưa ra một thông điệp quan trọng đối với doanh nghiệp đang triển khai AI: không thể chỉ đánh giá mô hình bằng câu trả lời cuối cùng rồi mặc định toàn bộ hệ thống sẽ hoạt động ổn định.

Một ứng dụng AI là chuỗi nhiều bước. Mã định danh thay đổi, danh sách bị sắp xếp lại hoặc dữ liệu tham chiếu được mở rộng đều có thể làm thay đổi yêu cầu gửi đến mô hình. Nếu không theo dõi những bước trung gian, đội ngũ kỹ thuật có thể mất nhiều thời gian điều tra nhầm nguyên nhân.

Thử nghiệm của CTGT cho thấy việc ổn định đầu vào có thể giúp tạo ra kết quả lặp lại. Nhưng việc một lỗi được lặp lại nhất quán cũng nhắc nhở rằng khả năng tái lập không đồng nghĩa với tính chính xác.

Trong những hệ thống có tác động đến khách hàng, tài chính hoặc nghĩa vụ tuân thủ, doanh nghiệp cần đồng thời kiểm soát đầu vào, lưu giữ bằng chứng, kiểm tra tính nhất quán và đối chiếu kết quả với những quy tắc đã xác định. Mô hình ra quyết định có thể giới hạn lựa chọn, mã phần mềm có thể thực thi hành động bắt buộc và công cụ như Concordance có thể hỗ trợ truy tìm điểm sai lệch.

Không có một lớp công nghệ đơn lẻ nào giải quyết được mọi vấn đề. Độ tin cậy đến từ cách các lớp đó phối hợp với nhau.

Khi AI chuyển từ vai trò trợ lý sang hệ thống trực tiếp đưa ra quyết định, khả năng trả lời câu hỏi “vì sao hệ thống làm như vậy” sẽ ngày càng quan trọng. Doanh nghiệp không chỉ cần AI hoạt động tốt trong một lần chạy. Họ cần biết hệ thống đã nhận dữ liệu gì, xử lý ra sao, vì sao kết quả thay đổi và liệu quyết định cuối cùng có đúng hay không.

LangSmith, Braintrust và Langfuse đứng trước cách tiếp cận kiểm tra AI mới

Concordance, CTGT, kiểm thử AI, độ tin cậy AI, AI doanh nghiệp, mã nguồn mở, quản trị AI, kiểm toán AI, mô hình ra quyết định, Qwen3.8-27B, an toàn AI, tự động hóa doanh nghiệp, giám sát AI, tuân thủ ngân hàng