Khi hiện đại hóa làm hỏng code đang chạy: nghiên cứu về LLM trên PHP legacy

Dán một file legacy vào LLM và yêu cầu nó "hiện đại hóa cái này" là một lối tắt dễ dàng. Nhưng kết quả có tốt hơn là giữ nguyên code không? Trong bài báo này, chúng tôi nghiên cứu thiết lập một file với năm LLM, mỗi LLM được yêu cầu hiện đại hóa 100 file WordPress 4.0 PHP lên PHP 8.3 mà vẫn giữ nguyên hành vi, không có context dự án hay phản hồi thực thi. Chúng tôi đánh giá mọi output bằng 630 behavioral checks ẩn và 511 Rector-detected modernization findings. Chúng tôi so sánh với hai baseline: bản gốc không thay đổi và công cụ rule-based Rector. Thường thì câu trả lời là không. 83 file không đụng chạm đã vượt qua mọi check; LLM tốt nhất chỉ để lại 59. Mỗi model làm hỏng 32-51 file đang chạy trong khi sửa tối đa 10, còn Rector làm hỏng 7 và sửa 6. Phần lớn thiệt hại này là không cần thiết. Chỉ 37 findings (7 phần trăm) cần thay đổi dưới PHP 8.3, nhưng trong các file tương thích không cần thay đổi, LLM làm hỏng 36-60 phần trăm (Rector: 8 phần trăm). Model có điểm hiện đại hóa cao nhất không tương thích hơn các đối thủ gần nhất. Hầu hết các check bị thoái lui đến từ các file không còn tải được, thường là do PHP tự từ chối các type declarations. Đây là lỗi không cần context dự án để tránh. Do đó, đánh giá hiện đại hóa dựa trên LLM nên đo lường so với baseline không thay đổi và báo cáo hiện đại hóa cùng bảo toàn hành vi một cách riêng biệt.