Trí tuệ nhân tạo có thể tự cải tiến bằng kiến thức khoa học mới đến đâu

Một mô hình trí tuệ nhân tạo mạnh vẫn có thể thất bại khi gọi sai giao diện lập trình, quên thông tin quan trọng trong cuộc hội thoại hoặc không biết cách phục hồi sau một lỗi thực thi. Điều đáng chú ý là để giải quyết những vấn đề này, các nhà nghiên cứu không nhất thiết phải huấn luyện lại mô hình từ đầu.

Một nhóm nghiên cứu thuộc Đại học California, Santa Barbara và Microsoft đã phát triển ScholarEvolve, một khuôn khổ có khả năng tìm kiếm kiến thức trong các bài báo khoa học, chuyển những kỹ thuật phù hợp thành mã nâng cấp hệ thống vận hành của tác nhân trí tuệ nhân tạo, sau đó kiểm tra xem các thay đổi có thực sự cải thiện hiệu quả hay không.

Trong thử nghiệm trên bộ đánh giá AppWorld Normal, hệ thống giúp mô hình Qwen3.5-27B tăng tỷ lệ hoàn thành nhiệm vụ từ 69% lên 81,4%, mà không cần thay đổi trọng số của mô hình. Theo nhóm nghiên cứu, kết quả này thu hẹp khoảng 74% khoảng cách hiệu năng với GPT-5.4 trong phép so sánh được báo cáo.

Đây là một hướng phát triển đáng chú ý của trí tuệ nhân tạo doanh nghiệp. Thay vì chỉ tìm cách tạo ra mô hình lớn hơn, doanh nghiệp có thể nâng cấp cách mô hình sử dụng công cụ, quản lý thông tin và thực hiện công việc. Giá trị nằm ở việc biến kiến thức khoa học thành những cải tiến kỹ thuật có thể kiểm tra và sử dụng trong thực tế.

Điều gì đang thay đổi trong cách cải tiến tác nhân trí tuệ nhân tạo

Trong thời gian qua, các hệ thống tự động tối ưu tác nhân trí tuệ nhân tạo thường đi theo hai hướng.

Hướng thứ nhất tập trung vào từng thành phần riêng lẻ, chẳng hạn thư viện kỹ năng hoặc bộ nhớ. Những công cụ được bài nghiên cứu đề cập gồm WikiSkill của Google, SkillOpt của Microsoft và Memento-Skills.

Hướng thứ hai sử dụng một tác nhân chuyên viết mã để phân tích các lần thực thi thất bại rồi sửa đổi hệ thống vận hành của tác nhân. Những ví dụ được nêu gồm DarwinX của Salesforce, HarnessX của Xiaomi, Self-Harness và Meta-Harness của Đại học Stanford.

Cả hai hướng đều có thể tạo ra cải tiến. Tuy nhiên, theo nhóm nghiên cứu, chúng có một giới hạn chung khi quá phụ thuộc vào kết quả thực thi đã quan sát được.

Nếu tác nhân liên tục thất bại khi gọi một giao diện lập trình, hệ thống tối ưu có thể bổ sung bước kiểm tra hoặc yêu cầu một tác nhân khác đánh giá hành động trước khi thực hiện. Nhưng cách sửa chữa quen thuộc này không phải lúc nào cũng giải quyết đúng nguyên nhân.

Trong một ví dụ của nghiên cứu, tác nhân chuyên viết mã nhận thấy các lỗi lặp lại khi sử dụng công cụ tìm kiếm và Python. Nó bổ sung một mô-đun kiểm tra có điều kiện để xác minh mọi hành động. Mặc dù cơ chế này phát hiện được các lệnh gọi sai, nó cũng trở nên quá thận trọng và chặn cả những lệnh gọi giao diện lập trình hợp lệ cần thiết để hoàn thành nhiệm vụ.

Đó là một vấn đề quan trọng của việc cải tiến dựa trên lỗi. Một hệ thống có thể giảm lỗi theo cách này nhưng lại tạo ra một loại lỗi khác.

ScholarEvolve hoạt động như thế nào

Điểm khác biệt của ScholarEvolve là bổ sung nghiên cứu khoa học bên ngoài lịch sử thực thi của tác nhân. Hệ thống không chỉ hỏi vì sao một nhiệm vụ thất bại, mà còn tìm kiếm những kỹ thuật đã được nghiên cứu có thể giúp giải quyết nguyên nhân đó.

Quy trình được tổ chức thành nhiều bước liên kết với nhau.

Cấu trúc này giúp hạn chế nguy cơ một thay đổi ở thành phần này làm hỏng thành phần khác. Nó cũng biến việc nâng cấp tác nhân thành một quy trình có thể đánh giá, thay vì để một hệ thống tự viết lại mã rồi lập tức đưa thay đổi vào sử dụng.

Năm thành phần quyết định hiệu quả của hệ thống

ScholarEvolve chia hệ thống vận hành của tác nhân thành năm mô-đun có giao diện đầu vào và đầu ra được xác định chặt chẽ.

• Giao diện công cụ quản lý cách tác nhân gọi các công cụ và giao diện lập trình.

• Quản lý ngữ cảnh quyết định thông tin nào cần được giữ lại trong giới hạn bộ nhớ.

• Kỹ năng lưu trữ những phương thức giải quyết công việc có thể tái sử dụng.

• Bộ nhớ hỗ trợ lưu giữ thông tin từ các lần tương tác.

• Quy trình tác nhân điều phối các bước suy luận và hành động để hoàn thành nhiệm vụ.

Việc tách thành phần có ý nghĩa lớn đối với kỹ thuật phần mềm. Khi một tác nhân thường xuyên gọi sai giao diện lập trình, nhóm phát triển có thể tập trung cải tiến giao diện công cụ. Nếu hệ thống mất dấu thông tin cũ trong một chuỗi tương tác dài, nhóm có thể điều chỉnh cách quản lý ngữ cảnh mà không cần thay đổi toàn bộ kiến trúc.

Tuy nhiên, nghiên cứu cũng cho thấy không nên đánh giá một mô-đun chỉ dựa trên kết quả khi nó hoạt động độc lập. Một thành phần có điểm số riêng cao hơn chưa chắc tạo ra hệ thống tốt nhất khi kết hợp với những thành phần còn lại.

Những cải tiến cụ thể tạo ra khác biệt

Nghiên cứu đưa ra ba ví dụ minh họa cách kiến thức khoa học được chuyển thành cải tiến kỹ thuật cho Qwen3.5-27B trong môi trường AppWorld.

Kiểm tra lời gọi giao diện lập trình trước khi thực thi

Tác nhân ban đầu thường tạo mã Python sai cú pháp hoặc đoán tham số giao diện lập trình mà không kiểm tra tài liệu hướng dẫn.

ScholarEvolve sử dụng một cơ chế từ nghiên cứu ToolACE-R để bổ sung bước kiểm tra cây cú pháp trừu tượng, đồng thời xây dựng một đoạn mã có thể hiển thị tài liệu giao diện lập trình ngay trong quá trình thực thi.

Thay vì chờ lỗi xuất hiện rồi mới sửa, hệ thống có thể phát hiện một số vấn đề trước khi gửi lệnh. Điều này đặc biệt hữu ích khi tác nhân phải phối hợp nhiều ứng dụng, mỗi ứng dụng có cách gọi và bộ tham số riêng.

Giữ lại thông tin quan trọng trong chuỗi tương tác dài

Khi lịch sử tương tác tăng lên, tác nhân có thể vượt giới hạn ngữ cảnh hoặc đánh mất bằng chứng đã thu thập trước đó.

Dựa trên nghiên cứu về giới hạn nén câu lệnh, ScholarEvolve tạo một mô-đun phân bổ ngân sách ký tự theo truy vấn. Mô-đun giữ nguyên các chính sách hệ thống, đánh giá lịch sử hội thoại dựa trên mức độ liên quan và độ mới, rồi phân bổ dung lượng phù hợp trong khi vẫn duy trì thứ tự thời gian.

Điểm quan trọng là không phải thông tin nào cũng có giá trị như nhau. Một dữ kiện xuất hiện từ sớm nhưng quyết định kết quả cuối cùng có thể quan trọng hơn nhiều thông tin mới nhưng không liên quan.

Tái sử dụng những chuỗi thao tác đã thành công

Tác nhân thông thường có thể phải tự tìm lại trình tự gọi giao diện lập trình nhiều bước trong mỗi lần chạy.

Từ nghiên cứu Skill-as-Pseudocode, ScholarEvolve trích xuất những chuỗi thao tác lặp lại trong các lần thực thi thành công rồi biên dịch chúng thành mẫu giả mã có kiểu dữ liệu xác định.

Điều này giúp tác nhân tận dụng kinh nghiệm đã được kiểm chứng thay vì liên tục phát minh lại cách thực hiện cùng một nhiệm vụ. Với những quy trình có cấu trúc lặp lại, khả năng tái sử dụng này có thể giảm sai sót và làm cho hành vi của hệ thống nhất quán hơn.

Dữ liệu thử nghiệm cho thấy mức cải thiện ra sao

Nhóm nghiên cứu đánh giá ScholarEvolve trên hai môi trường tương tác mô phỏng những phần việc thường gặp trong doanh nghiệp.

AppWorld yêu cầu tác nhân viết mã và gọi giao diện lập trình xuyên qua nhiều ứng dụng. Trong khi đó, tau-Bench Telecom mô phỏng các tình huống chăm sóc khách hàng liên quan đến xử lý sự cố, dữ liệu di động và tin nhắn.

Hệ thống được thử nghiệm với hai mô hình nền là Qwen3.5-27B và GPT-5.4-mini, sau đó so sánh với các hệ thống ban đầu, Meta-Harness và một nhóm mô hình tiên tiến.

Một kết quả đáng chú ý khác xuất hiện trong thử nghiệm kết hợp mô-đun. Bản nâng cấp kỹ năng riêng lẻ đạt 75,4%, trong khi mô-đun Skill-as-Pseudocode đạt 73,7%. Tuy nhiên, khi kết hợp với các mô-đun giao diện công cụ, ngữ cảnh, bộ nhớ và quy trình đã được cải tiến, phương án thứ hai giúp hệ thống đạt tỷ lệ hoàn thành 84,8%, so với 80,7% của phương án còn lại.

Điều này cho thấy hiệu quả của một hệ thống không chỉ là tổng điểm của các bộ phận riêng lẻ. Những thành phần có thể phối hợp tốt với nhau đôi khi tạo ra kết quả tổng thể vượt trội hơn.

Cần lưu ý rằng đây là kết quả trong các môi trường đánh giá được mô phỏng. Chúng cung cấp bằng chứng về tiềm năng kỹ thuật, nhưng chưa chứng minh rằng mức cải thiện tương tự sẽ xuất hiện trong mọi hệ thống doanh nghiệp thực tế.

Doanh nghiệp có thể tạo giá trị kinh tế từ cách tiếp cận này như thế nào

Một trong những rào cản lớn của việc triển khai trí tuệ nhân tạo là chi phí duy trì độ tin cậy sau khi đưa hệ thống vào hoạt động.

Một tác nhân có thể hoạt động tốt trong thử nghiệm nhưng gặp vấn đề khi phải sử dụng giao diện lập trình mới, xử lý lịch sử tương tác dài hoặc phục hồi sau lỗi ngoài dự kiến. Mỗi vấn đề có thể đòi hỏi kỹ sư kiểm tra nhật ký, sửa mã, chạy thử và triển khai lại.

ScholarEvolve gợi mở một cách tiếp cận khác. Nếu các cải tiến có thể được rút ra từ nghiên cứu khoa học và chuyển thành mô-đun có thể kiểm tra, doanh nghiệp có cơ hội tái sử dụng kiến thức kỹ thuật mà không phải huấn luyện lại mô hình nền.

Điều này có thể giảm nhu cầu quản lý nhiều phiên bản trọng số tùy chỉnh và tập trung nguồn lực vào chất lượng hệ thống vận hành.

Trong thực tế, giá trị kinh tế cần được đo bằng tổng chi phí sở hữu. Doanh nghiệp phải tính đến chi phí tìm kiếm và thẩm định nghiên cứu, viết mã, kiểm thử, bảo mật, giám sát và bảo trì. Việc không phải huấn luyện lại mô hình là một lợi thế tiềm năng, nhưng không có nghĩa toàn bộ quá trình nâng cấp trở nên miễn phí.

Cũng chưa có số liệu trong nghiên cứu được cung cấp để xác định mức tiết kiệm tài chính cụ thể. Do đó, doanh nghiệp cần thử nghiệm trên một quy trình có thể đo lường trước khi mở rộng.

Nền tảng hay sản phẩm mới là hướng phát triển quan trọng

ScholarEvolve không chỉ đưa ra một cách sửa lỗi cho một mô hình cụ thể. Điểm đáng quan tâm là kiến trúc của nó có thể được áp dụng để nâng cấp nhiều thành phần trong hệ thống tác nhân.

Một sản phẩm đơn lẻ có thể giải quyết một nhiệm vụ, nhưng doanh nghiệp thường cần tác nhân phối hợp trên nhiều ứng dụng, hệ thống dữ liệu và quy trình khác nhau. Khi số lượng tác nhân tăng lên, khả năng tái sử dụng mô-đun, chuẩn hóa giao diện và kiểm tra hồi quy trở nên quan trọng hơn.

Trong kiến trúc này, mô hình nền vẫn đảm nhiệm khả năng suy luận, còn lớp vận hành quyết định cách mô hình tiếp cận công cụ, duy trì ngữ cảnh và tổ chức hành động.

Đó là một sự phân biệt có ý nghĩa. Nâng cấp hệ thống vận hành không thay thế mô hình nền, nhưng có thể giúp mô hình sử dụng năng lực sẵn có hiệu quả hơn.

Nếu phương pháp này được phát triển thêm, các tổ chức có thể xây dựng quy trình cải tiến định kỳ, trong đó những nghiên cứu mới được đánh giá trên bộ kiểm thử nội bộ trước khi bất kỳ thay đổi nào được chấp nhận.

Lợi thế cạnh tranh không chỉ nằm ở mô hình mạnh nhất

Kết quả của ScholarEvolve gợi ý rằng việc so sánh các hệ thống trí tuệ nhân tạo chỉ bằng tên mô hình hoặc quy mô tham số có thể bỏ qua một phần quan trọng của hiệu năng.

Hai hệ thống dùng cùng một mô hình nền vẫn có thể khác nhau đáng kể vì cách quản lý ngữ cảnh, sử dụng công cụ, tái sử dụng kỹ năng và phục hồi lỗi không giống nhau.

Đối với doanh nghiệp, đây là cơ hội để tối ưu hệ thống hiện có thay vì luôn phải chuyển sang một mô hình đắt tiền hơn.

Tuy nhiên, không thể suy ra rằng mô hình nhỏ sau khi tối ưu sẽ luôn vượt trội mô hình lớn. Hiệu quả còn phụ thuộc vào loại nhiệm vụ, dữ liệu, độ phức tạp của giao diện lập trình và chất lượng các mô-đun được kết hợp.

Lợi thế thực sự nằm ở khả năng thiết kế một hệ thống phù hợp với công việc cụ thể, có thể kiểm tra và cải tiến theo thời gian.

Rủi ro khi để trí tuệ nhân tạo tự nâng cấp mã nguồn

Một hệ thống có khả năng đọc nghiên cứu rồi viết mã không chỉ tạo ra cơ hội mà còn mở ra một bề mặt rủi ro mới.

Nhóm nghiên cứu lưu ý rằng các phép kiểm tra của ScholarEvolve tập trung vào khả năng nhập mã, tính tương thích của giao diện, cấu trúc tạo tác và định dạng hành động hợp lệ. Bài nghiên cứu không mô tả cơ chế quét bảo mật để phát hiện thư viện độc hại, mẫu thực thi không an toàn hoặc lỗ hổng chèn chỉ dẫn trong các bài báo và mã nguồn bên thứ ba.

Đây là giới hạn quan trọng. Một đoạn mã chạy được chưa chắc là đoạn mã an toàn. Một bài báo có phương pháp hữu ích cũng không có nghĩa mọi mã nguồn đi kèm đều phù hợp để triển khai trong môi trường sản xuất.

Doanh nghiệp không nên cho phép tác nhân tự động đưa mã nâng cấp chưa được thẩm định vào hệ thống đang phục vụ khách hàng.

Thay vào đó, cần có một cổng kiểm tra bảo mật, kho tài liệu nội bộ đã được tuyển chọn, kiểm thử hồi quy, rà soát phụ thuộc phần mềm và cơ chế phê duyệt trước khi triển khai.

Ngoài ra, cải tiến lớp vận hành không thể giải quyết mọi vấn đề của hệ thống. Nó không thay thế các quy tắc bảo vệ bắt buộc tại cổng giao diện lập trình và không thể tự khắc phục một quy trình truy xuất dữ liệu đầu vào yếu.

Tác động đối với kinh tế Việt Nam

Đối với doanh nghiệp Việt Nam, đặc biệt là các công ty phát triển phần mềm, thương mại điện tử, logistics và dịch vụ khách hàng, cách tiếp cận này mở ra một hướng tối ưu hóa đáng quan tâm.

Nhiều quy trình có thể được mô tả bằng chuỗi thao tác rõ ràng. Một tác nhân có thể tra cứu đơn hàng, kiểm tra trạng thái giao nhận, đối chiếu thông tin khách hàng hoặc cập nhật dữ liệu qua giao diện lập trình. Nhưng khi hệ thống gọi sai tham số, bỏ sót thông tin cũ hoặc gặp lỗi giữa chừng, toàn bộ quy trình có thể bị gián đoạn.

Khả năng cải tiến lớp vận hành giúp doanh nghiệp tập trung xử lý những điểm yếu cụ thể này.

Đối với các công ty phần mềm cung cấp dịch vụ cho khách hàng châu Âu và Hoa Kỳ, việc kiểm soát phiên bản mã, kiểm thử hồi quy và quản trị quyền truy cập còn có ý nghĩa đối với độ tin cậy của sản phẩm. Tuy nhiên, mức độ tuân thủ cần được đánh giá theo yêu cầu thực tế của từng khách hàng và thị trường; không thể mặc định rằng một khuôn khổ kỹ thuật tự động đáp ứng mọi nghĩa vụ pháp lý.

Cơ hội không nhất thiết nằm ở việc xây dựng mô hình nền riêng. Một doanh nghiệp có thể tạo lợi thế bằng cách tích hợp mô hình sẵn có với quy trình đặc thù, bộ kiểm thử chất lượng và hệ thống vận hành được cải tiến liên tục.

Doanh nghiệp nhỏ và siêu nhỏ nên bắt đầu từ đâu

Doanh nghiệp nhỏ không cần xây dựng ngay một hệ thống tự cải tiến phức tạp. Bước đầu tiên là chọn một quy trình lặp lại, có tiêu chí thành công rõ ràng và có thể kiểm tra kết quả.

Ví dụ, một đơn vị thương mại điện tử có thể thử nghiệm tác nhân tra cứu đơn hàng và xử lý yêu cầu khách hàng. Một công ty dịch vụ có thể tự động hóa việc tổng hợp thông tin từ nhiều ứng dụng. Một nhóm phát triển phần mềm có thể dùng tác nhân để thực hiện những thao tác kiểm thử hoặc gọi giao diện lập trình theo mẫu đã xác định.

Trước khi cho phép hệ thống tự sửa mã, doanh nghiệp nên lưu lại những lần thực thi thành công và thất bại, xây dựng bộ kiểm thử đại diện, đồng thời đo tỷ lệ hoàn thành nhiệm vụ và mức độ can thiệp thủ công.

Sau đó, có thể thử nghiệm từng thay đổi trong môi trường tách biệt. Nếu cải tiến không làm giảm chất lượng ở những nhiệm vụ khác và vượt qua các kiểm tra an toàn, doanh nghiệp mới cân nhắc triển khai.

Cách tiếp cận này giúp tránh một sai lầm phổ biến: xem việc tác nhân tự viết mã là bằng chứng rằng hệ thống đã có thể tự quản lý chất lượng của chính mình.

Doanh nghiệp Việt Nam nên chuẩn bị gì

Có ba ưu tiên đáng thực hiện trước khi mở rộng tự động hóa bằng tác nhân.

Thứ nhất, chuẩn hóa giao diện và dữ liệu. Các hệ thống cần có tài liệu giao diện lập trình rõ ràng, thông số đầu vào và đầu ra nhất quán, cùng cơ chế xử lý lỗi có thể kiểm tra.

Thứ hai, xây dựng bộ kiểm thử thực tế. Bộ kiểm thử cần bao gồm cả nhiệm vụ thông thường, trường hợp dữ liệu thiếu, lỗi giao diện và tình huống phải phục hồi sau khi một bước thất bại. Một thay đổi chỉ cải thiện điểm số trên vài nhiệm vụ riêng lẻ chưa đủ để kết luận toàn bộ hệ thống tốt hơn.

Thứ ba, tách biệt khả năng tự cải tiến khỏi quyền triển khai. Tác nhân có thể đề xuất hoặc tạo mã mới, nhưng quyền chấp nhận và đưa mã vào môi trường sản xuất nên thuộc về một quy trình kiểm soát riêng. Những thay đổi ảnh hưởng đến dữ liệu khách hàng, giao dịch hoặc hệ thống quan trọng cần được đánh giá kỹ hơn.

Nhóm nghiên cứu cũng thử nghiệm ba vòng cập nhật liên tiếp dựa trên tài liệu nghiên cứu mới mà không thay đổi trọng số Qwen và không sử dụng thêm dữ liệu nhiệm vụ đã thu thập trước đó. Hiệu năng trên AppWorld Normal tăng qua cả ba vòng. Dù vậy, thử nghiệm này chưa đánh giá khả năng thích nghi liên tục trong môi trường sản xuất thực tế.

Đây là một tín hiệu đáng chú ý, nhưng vẫn cần thêm bằng chứng trước khi xem việc tự cải tiến định kỳ là một quy trình có thể triển khai an toàn ở mọi doanh nghiệp.

ScholarEvolve đưa ra một hướng phát triển quan trọng cho trí tuệ nhân tạo doanh nghiệp. Thay vì chỉ phụ thuộc vào khả năng vốn có của mô hình hoặc chờ các lỗi tích lũy sau khi triển khai, hệ thống tìm kiếm kỹ thuật từ nghiên cứu khoa học, chuyển chúng thành những thay đổi có mục tiêu và đánh giá kết quả trước khi lựa chọn phương án tốt hơn.

Những con số từ AppWorld và tau-Bench Telecom cho thấy cách cải tiến lớp vận hành có thể nâng tỷ lệ hoàn thành nhiệm vụ, tăng khả năng xử lý các giao diện chưa từng gặp và giúp tác nhân phục hồi tốt hơn sau lỗi thực thi.

Nhưng điều quan trọng không kém là giới hạn của phương pháp. Mã nguồn cần được kiểm tra bảo mật. Các thay đổi phải vượt qua kiểm thử hồi quy. Quy tắc bảo vệ bắt buộc vẫn phải được duy trì độc lập. Và hiệu năng trong môi trường mô phỏng không thể thay thế đánh giá thực tế.

Đối với doanh nghiệp, bài học cốt lõi là không phải mọi bước tiến của trí tuệ nhân tạo đều đòi hỏi một mô hình mới. Đôi khi, cơ hội lớn nằm ở cách tổ chức công cụ, quản lý thông tin và biến kiến thức kỹ thuật thành những cải tiến có thể kiểm chứng.

Trong cuộc đua tự động hóa, mô hình mạnh là một lợi thế. Nhưng một hệ thống biết sử dụng công cụ đúng cách, phục hồi sau lỗi và cải tiến có kiểm soát mới có cơ hội tạo ra giá trị bền vững.

Trí tuệ nhân tạo có thể tự cải tiến bằng kiến thức khoa học mới đến đâu

ScholarEvolve, tác nhân trí tuệ nhân tạo, tự cải tiến AI, Qwen3.5-27B, tối ưu tác nhân AI, huấn luyện mô hình, nghiên cứu trí tuệ nhân tạo, giao diện lập trình, quản lý ngữ cảnh, tự động hóa doanh nghiệp, kiểm thử trí tuệ nhân tạo, mã nguồn an toàn, AI doanh nghiệp, doanh nghiệp Việt Nam