Anthropic cho biết Frontier Red Team của họ phối hợp với Theorem, một đối tác về phương pháp hình thức, đã dùng Claude tạo bằng chứng được kiểm tra bằng máy cho 239 điểm vào của các bài kiểm thử fuzzing thuộc 123 thư viện mã nguồn mở. Các bằng chứng xét những thuộc tính cụ thể về lỗi dừng chương trình và an toàn bộ nhớ trên mã RISC-V đã biên dịch, trong những điều kiện xác định. Đây không phải là kết luận rằng các thư viện ấy hoàn toàn không có lỗi.
9
5
Quy mô dự án là điểm đáng chú ý: nhóm cho biết họ hoàn thành trong vài tuần và tạo khoảng 180 triệu dòng mã chứng minh bằng Rocq. Ý nghĩa rộng hơn nằm ở khả năng dùng AI hỗ trợ áp dụng kiểm chứng hình thức cho phần mềm thực tế trên quy mô lớn hơn, đồng thời vẫn giới hạn kết luận vào đúng điều đã được mô tả và kiểm tra.
3
13
Từ kiểm thử fuzzing đến bằng chứng hình thức
Fuzzing là cách tự động đưa nhiều đầu vào khác nhau vào chương trình để tìm lỗi. Trong dự án này, nhóm tận dụng các điểm vào kiểm thử có sẵn của Google OSS-Fuzz — một dự án kiểm thử fuzzing cho phần mềm mã nguồn mở — làm cơ sở cho đặc tả hình thức. Thay vì chỉ thử một tập hợp đầu vào, Claude tạo bằng chứng về hành vi của từng chương trình trong toàn bộ miền đầu vào được nêu trong định lý.
3
13
Theo Anthropic, với mọi đầu vào nhỏ hơn 64 MB, các chương trình được xét sẽ kết thúc bình thường, không gặp lỗi an toàn bộ nhớ hay làm thất bại các assertion, trong phạm vi những phản hồi của hệ điều hành Linux và cách bố trí bộ nhớ đã được mô hình hóa, cùng các giả định đi kèm. Đối tượng được kiểm chứng là các tệp thực thi RISC-V đã biên dịch — không phải bảo đảm trừu tượng cho mọi phiên bản hay môi trường triển khai của từng thư viện.
9
12
Anthropic mô tả đây là nỗ lực quy mô lớn đầu tiên dùng AI để kiểm chứng hình thức phần mềm sản xuất ở cấp mã máy. Đây là cách nhóm nghiên cứu nói về tính mới của dự án, chứ không nên hiểu là một kết luận lịch sử đã được xác lập độc lập.
7
13
Vì sao bộ kiểm tra Rocq quan trọng?
Claude tạo bằng chứng; bộ nhân kiểm tra của Rocq xác minh chúng. Nhờ vậy, để kiểm tra cơ học một bằng chứng, nhà phát triển không phải mặc nhiên tin vào lập luận của Claude hay tự đọc thủ công từng dòng. Tuy nhiên, việc kiểm tra bằng máy không xóa bỏ mọi giả định: định lý vẫn phải mô tả đúng thuộc tính cần quan tâm, còn các mô hình hình thức và bộ kiểm tra vẫn thuộc nền tảng cần được tin cậy.
9
5
Anthropic và các bài tường thuật khác ước tính sản phẩm của dự án vào khoảng 180 triệu dòng bằng chứng Rocq, trung bình gần 600.000 dòng cho mỗi chương trình. Quy mô ấy cho thấy khối lượng công việc, nhưng chỉ đếm dòng không thể cho biết một thuộc tính áp dụng rộng đến đâu, hay có đáp ứng nhu cầu của phần mềm khi vận hành thực tế hay không.
3
12
Kiểm thử bỏ sót gì — và dự án báo cáo đã tìm thấy gì?
Fuzzing có thể thử rất nhiều đầu vào, nhưng tự nó không chứng minh hành vi của chương trình với mọi đầu vào trong một miền xác định. Các tường thuật về dự án cho biết Claude đã tìm và vá hàng trăm lỗi, trong đó có những lỗi vẫn chưa bị phát hiện sau hàng nghìn tỷ lượt fuzzing. Đây là số liệu được báo cáo về dự án này, không phải phép đo độc lập cho thấy kiểm chứng hình thức luôn hiệu quả hơn kiểm thử ở những dự án khác.
2
11
Bài học thực tế không phải là bỏ kiểm thử. Bằng chứng hình thức bổ sung một loại cơ sở khác: trong phạm vi thuộc tính và điều kiện đã nêu, nó có thể xác lập hành vi trên toàn bộ đầu vào thỏa đặc tả, thay vì chỉ trên những trường hợp đã được chạy thử.
9
2
“Đã kiểm chứng” không có nghĩa là “không còn lỗi”
Các bảo đảm chỉ áp dụng cho những điểm vào được chọn và những tệp thực thi cụ thể đã biên dịch. Chúng không tự động bao phủ mọi hàm trong thư viện, mọi cấu hình dựng, kiến trúc phần cứng hay cách sử dụng thư viện.
9
5
Điều kiện chạy cũng quan trọng. Các tường thuật mô tả những bằng chứng này trong phạm vi chương trình RISC-V tĩnh, đơn luồng, chạy trên Linux mô hình hóa với ngân sách bộ nhớ cố định. Phần lớn phần mềm được triển khai cho những kiến trúc hoặc cấu hình khác, nên không thể xem kết quả là bảo đảm cho các bản dựng đó.
12
27
34
Cuối cùng, bằng chứng chỉ xác lập định lý đã viết — không phải mọi thuộc tính mà nhà phát triển có thể mong muốn. Lỗi vẫn có thể nằm ngoài phạm vi kiểm chứng, hoặc trong chính các mô hình hình thức và nền tảng kiểm tra bằng chứng mà kết quả dựa vào.
5
31
Nhà phát triển nên rút ra điều gì?
Đóng góp cốt lõi của dự án là bằng chứng cho thấy AI có thể giúp việc kiểm chứng hình thức ở cấp mã máy trở nên khả thi trên nhiều phần mềm thực tế hơn, so với cách làm vốn đòi hỏi nhiều công sức chuyên môn. Kết quả không đưa ra ước tính chi phí phổ quát, cũng không bảo đảm phương pháp này sẽ thành công với mọi kho mã.
7
13
Một phần bằng chứng đã được công khai; một bài tường thuật cho biết phần phát hành gồm 25 thư viện và 60 điểm vào, không phải toàn bộ kết quả dự án. Theorem cũng công bố chương trình OSS Verify dành cho các dự án mã nguồn mở.
32
16
38
Với nhà phát triển, cách dùng thận trọng là xem mỗi bằng chứng như một cam kết có phạm vi: hãy kiểm tra chính xác điểm vào, tệp thực thi, giả định và thuộc tính được chứng minh trước khi dựa vào nó. Kết quả khiến việc đánh giá kiểm chứng hình thức có AI hỗ trợ trở nên đáng cân nhắc bên cạnh kiểm thử — chứ không phải lý do để ngừng kiểm thử hoặc cho rằng phần mềm đã hết lỗi.
9
5