The Decoder: AI News
85

Thủ thuật

AI lập trình giúp hiện đại hóa phần mềm nghiên cứu nhưng vẫn 'mù' về tính đúng đắn khoa học

(giờ Việt Nam)

Tóm tắt AI

Các AI lập trình như Codex hay Claude Code có thể tăng tốc phần mềm nghiên cứu cũ lên gấp 60 lần, nhưng vẫn thường xuyên tạo ra mã lỗi và không thể tự kiểm chứng độ chính xác về mặt khoa học, đòi hỏi sự giám sát chặt chẽ từ con người.

Bản dịch AI

AI coding agents can modernize research software but can't judge if the science is right

Báo cáo ghi lại tám nghiên cứu điển hình, chủ yếu trong lĩnh vực sinh học, nơi các nhóm nghiên cứu đã sử dụng các tác nhân lập trình (coding agents) như Codex và Claude Code. Các dự án này trải dài từ việc bảo trì cơ bản và tối ưu hóa có mục tiêu cho đến viết lại toàn bộ bằng các ngôn ngữ lập trình hiện đại.

A timeline categorizes eight case studies by scope, from maintenance and local optimization to compatibility migration, reimplementation, workflow redesign, and new system development. The projects ar

Các tác nhân lập trình đã mang lại tốc độ xử lý nhanh hơn gấp 60 lần.

Một trong những dự án đơn giản hơn liên quan đến việc hiện đại hóa cyvcf2, một thư viện Python dùng để đọc dữ liệu di truyền. GPT-5.5 đã thay thế quy trình xây dựng và cài đặt lỗi thời của nó bằng một quy trình hiện đại.

Quá trình chuyển đổi MHCflurry phức tạp hơn nhiều. MHCflurry là một mô hình miễn dịch học dự đoán các mục tiêu mà tế bào miễn dịch sẽ nhận diện. Claude Code và Codex đã luân phiên đảm nhận vai trò lập trình viên và người đánh giá trong khi chuyển đổi khoảng 10.000 dòng mã từ TensorFlow sang PyTorch.

Dự án rustar-aligner đầy tham vọng hơn. Nó xây dựng lại STAR từ đầu bằng ngôn ngữ Rust. STAR thực hiện ánh xạ các đoạn trình tự (sequencing reads) từ tế bào sang các vị trí tương ứng trong bộ gen. Bản gốc chứa hơn 20.000 dòng mã C và C++ và không còn được duy trì tích cực, mặc dù nó vẫn là một phần trong nhiều quy trình nghiên cứu.

Để kiểm tra xem bản viết lại có hoạt động giống như bản gốc hay không, nhóm đã thử nghiệm cả hai công cụ trên 10.000 đoạn trình tự ngắn từ tế bào nấm men. Đối với các đoạn trình tự đơn (single-end reads), rustar-aligner cho kết quả giống hệt STAR trong 99,815% trường hợp. Đối với các đoạn trình tự cặp (paired-end reads), tỷ lệ tương đồng là 99,883%.

Việc so sánh không chỉ dừng lại ở vị trí ánh xạ trong bộ gen mà còn bao gồm một số trường thông tin quan trọng khác mà cả hai chương trình tạo ra cho mỗi đoạn trình tự. Không công cụ nào ánh xạ được các đoạn trình tự mà công cụ kia thất bại.

RustQC mang lại mức tăng tốc lớn nhất bằng cách kết hợp 15 công cụ kiểm soát chất lượng riêng biệt vào một chương trình duy nhất. Trên một tập dữ liệu lớn, thời gian chạy đã giảm từ 15 giờ 34 phút xuống còn 14 phút 54 giây, mức tăng tốc nhanh hơn gấp 60 lần.

Một dự án khác, HelixForge, đã thay thế một công cụ tạo dữ liệu gen tổng hợp bằng một phiên bản chạy trên GPU. Trong một thử nghiệm sử dụng dữ liệu từ một người hiến tặng và một phần bộ gen dài mười triệu cặp base, HelixForge đã hoàn thành toàn bộ quy trình nhanh hơn 59,6 lần so với BamSurgeon. Riêng bước tính toán chính đã chạy nhanh hơn 98,6 lần.

Five bar charts compare BamSurgeon and HelixForge. Runtime per 10 Mb window falls from 1,610 seconds to 27 seconds, mean VAF error drops from 0.076 to 0.034, and INDEL correlation rises from 0.80 to 0

Mã nguồn nhanh vẫn có thể tạo ra khoa học sai lệch.

Qua các nghiên cứu điển hình, các tác nhân hoàn thành nhanh chóng các nhiệm vụ được xác định rõ ràng nhưng không thể đánh giá một cách đáng tin cậy liệu công việc của chúng có chính xác về mặt khoa học hay không. Ngay cả khi mã của chúng chứa lỗi, các hệ thống này thường trình bày với sự tự tin tuyệt đối.

"Với các tác nhân lập trình, việc đi nhanh là khá dễ dàng; nhưng hiện tại, để đi xa trong khoa học, vẫn cần sự hướng dẫn, hiểu biết, tư duy thẩm mỹ và sự cẩn trọng của chuyên gia," Brent Pedersen, nhà phát triển của cyvcf2, viết.

Philip Ewels, người đứng đầu dự án RustQC, mô tả các tác nhân này là "hùng hồn, thuyết phục và tự tin một cách sai lầm theo những cách khó nhận ra." Ông không bao giờ cho phép các mô hình tự đánh giá độ chính xác công việc của chính chúng mà thay vào đó xây dựng một bộ kiểm thử độc lập.

A bar chart breaks down the runtime gains from rewriting bayesm in Rust across eight implementation stages. The largest gain comes from replacing the original R version with a Rust baseline, which run

Nghiên cứu điển hình về bayesm cho thấy những lỗi này khó phát hiện đến mức nào. Bản viết lại bằng Rust của nó chạy nhanh hơn từ hai đến hai mươi lần so với bản gốc, nhưng các phiên bản đầu tiên của hai phương pháp nâng cao lại chứa những lỗi khó phát hiện chỉ bằng cách nhìn vào kết quả đầu ra.

Trong một phương pháp, tác nhân đã đảo ngược một tham số điều khiển chính, khiến chương trình sử dụng giá trị nghịch đảo thay vì giá trị dự định. Một lỗi khác ảnh hưởng đến chính phép tính. Các nhà nghiên cứu chỉ phát hiện ra điều này sau khi chạy một bài kiểm tra hiệu chuẩn chi tiết đối với hàng ngàn tập dữ liệu tổng hợp đã biết trước kết quả.

Two rank histograms show results from a simulation-based calibration before and after a bug fix. Before the fix, the distribution slopes downward and extends beyond the expected range. After the fix,

Một phương pháp khác, gọi là HART, tạo ra kết quả có vẻ hợp lý nhưng vẫn chứa một số thiếu sót. Những thiếu sót này bao gồm các phép tính tốn kém không cần thiết và một hệ số hiệu chỉnh bị chia tỷ lệ không chính xác. Kết quả kiểm tra hợp lý đơn thuần không thể khẳng định rằng mã nguồn là chính xác.

Một nỗ lực trước đó nhằm chuyển đổi MHCflurry sang PyTorch đã thất bại vào đầu năm 2025. Nhà phát triển Sergey Feldman hiện cho rằng sự thất bại đó là do các mô hình có sẵn vào thời điểm đó chứ không phải do bản thân các công cụ lập trình. Theo quan điểm của ông, chỉ những thế hệ mô hình mới hơn mới trở nên đủ tin cậy để tự mình xử lý phần lớn công việc này.

Con người xác định các bài kiểm tra trong khi các tác nhân viết mã.

Các dự án tuân theo sự phân công lao động nhất quán. Con người xác định mục tiêu, tiêu chí thành công và phương pháp xác thực, trong khi các tác nhân xử lý việc triển khai.

Dự án hifiasm cho thấy cách thức này hoạt động trong thực tế. Hifiasm lắp ráp một bộ gen hoàn chỉnh từ nhiều đoạn ngắn. Trước khi yêu cầu GPT-5.5 tối ưu hóa, nhà nghiên cứu đã xây dựng một thiết lập kiểm tra với các tập dữ liệu huấn luyện và xác thực riêng biệt. Sau đó, mô hình đã tìm ra các thay đổi giúp giảm thời gian chạy trên dữ liệu bộ gen người thực tế gần 15%.

HI.SIM, một thư viện mô phỏng dữ liệu di truyền, đòi hỏi ít sự tham gia của con người hơn nữa. GPT-5.2 đã tìm ra các cách để tối ưu hóa từng phần của chương trình trong một lần chạy. Lần chạy thứ hai với một mô hình mới hơn đã tìm thấy nhiều cải tiến hơn. Tổng hợp lại, các thay đổi đã giảm thời gian chạy khoảng 31% mà không làm thay đổi kết quả đầu ra.

Việc viết lại mã giá rẻ tạo ra vấn đề bảo trì.

Các tác giả cũng đưa ra những ước tính sơ bộ về khả năng tiết kiệm. Nếu các tác nhân có thể giải quyết từ một phần tư đến một nửa tất cả các vấn đề cài đặt ảnh hưởng đến phần mềm nghiên cứu, thời gian nghiên cứu tiết kiệm được trên 100 gói phần mềm sẽ có giá trị từ 600.000 USD đến gần 5 triệu USD. Chỉ riêng đối với NumPy, báo cáo ước tính rằng các tác nhân có thể tiết kiệm khoảng 650 giờ bảo trì mỗi năm.

Bảo trì dài hạn vẫn là một vấn đề lớn chưa được giải quyết, bên cạnh việc xác thực và độ chính xác khoa học. Những bản viết lại chi phí thấp có thể làm phân mảnh cộng đồng người dùng và khiến thời gian vốn đã hạn hẹp của các nhà bảo trì giàu kinh nghiệm càng trở nên khan hiếm hơn.

Các nhóm đã áp dụng những cách tiếp cận khác nhau đối với quyền sở hữu và bảo trì. Một số thay đổi được đưa trực tiếp vào các dự án gốc. Vì STAR không còn được bảo trì, rustar-aligner đã chuyển sang tập đoàn nghiên cứu scverse. Tác giả của FastQC đã từ chối thay thế công cụ gốc bằng bản viết lại bằng Rust. Thay vào đó, nhóm đã thêm các cải tiến tìm được vào phiên bản Java gốc, vốn đã đạt được mức tăng tốc gấp ba lần tương tự.

Báo cáo thực địa nhìn lại các dự án đã hoàn thành và dựa trên lời kể từ những người tham gia. Các tác giả nhấn mạnh rằng những phát hiện này không đến từ một nghiên cứu mang tính đại diện. Họ vẫn thấy nút thắt chính đang chuyển dịch từ việc lập trình sang xác thực, đánh giá khoa học và trách nhiệm rõ ràng đối với việc bảo trì và phát triển trong tương lai.

Mô hình tương tự xuất hiện trong phát triển phần mềm bên ngoài lĩnh vực nghiên cứu. Một nghiên cứu của METR cho thấy các nhà bảo trì dự án thực tế sẽ từ chối khoảng một nửa số giải pháp mà tiêu chuẩn SWE-bench Verified (được sử dụng rộng rãi) đánh giá là đạt yêu cầu.

Một nghiên cứu về sự thất vọng của các nhà phát triển đối với mã do AI tạo ra đã tìm thấy sự đánh đổi tương tự. Thời gian tiết kiệm được khi tạo mã có thể lại bị tiêu tốn vào việc xem xét lại nó. Dự án curl đã đóng chương trình săn lỗi (bug bounty) sau khi các báo cáo lỗ hổng do AI tạo ra tiêu tốn thời gian của các nhà bảo trì mà không mang lại kết quả hữu ích.

Báo cáo thực địa này là một phần trong nỗ lực rộng lớn hơn của OpenAI nhằm tiến vào lĩnh vực khoa học. Công ty đã thành lập một nhóm khoa học chuyên trách do Kevin Weil dẫn dắt, người kỳ vọng năm 2026 sẽ là năm của khoa học giống như năm 2025 là năm của kỹ thuật phần mềm. Vào tháng 4, OpenAI đã giới thiệu GPT-Rosalind, một mô hình dành cho nghiên cứu khoa học sự sống và phát hành một plugin khoa học sự sống miễn phí cho Codex, giúp kết nối các mô hình với hơn 50 cơ sở dữ liệu công cộng và công cụ sinh học.

AI lập trìnhNghiên cứu khoa họcTối ưu hóa phần mềmCông nghệ AI
Đọc bài gốc

Bài viết được AI dịch và tổng hợp tự động từ The Decoder: AI News. Liên kết bài gốc ở phía trên. Dữ liệu đồng bộ qua API công khai được ghi nguồn tại AI HOT (canonical) ↗. AIHOT.vn luôn dẫn nguồn đầy đủ — nếu bạn thấy điểm cần chỉnh sửa, hãy gửi ý kiến tại trang phản hồi.