Hashline so với Replace: Định dạng chỉnh sửa có quan trọng không?

nội dung

Bài Vấn đề về harness của Can Bölük cho thấy các thao tác chỉnh sửa kiểu hashline (neo theo số dòng, như 4#WB) đạt kết quả tốt hơn các thao tác chỉnh sửa bằng chế độ replace truyền thống (so khớp old_string/new_string) đối với các tác nhân lập trình. Tôi đang thử tự xây dựng harness của mình (tau), và muốn kiểm chứng kết quả này cũng như xem liệu tôi có nên cân nhắc dùng hashline làm chiến lược chỉnh sửa mặc định trong đó hay không. Vì vậy, tôi đã xây dựng edit-bench để tự kiểm tra trên nhiều ngôn ngữ và mô hình.

Thiết lập

edit-bench tạo các bài kiểm thử dựa trên đột biến từ những cơ sở mã nguồn sẵn có. Bạn cho một tập lệnh trỏ đến một thư mục, và nó sẽ tạo các đột biến như xóa một câu lệnh, đảo giá trị boolean, hoán đổi đối số, v.v.

Ngôn ngữ: Python (từ hive), TypeScript (từ oh-my-pi), Rust (từ irradiate)
Mô hình: gpt-4.1-mini, google/gemini-3-flash-preview, qwen/qwen3.5-397b-a17b
Chế độ chỉnh sửa: replace (old_string/new_string) so với hashline (neo theo số dòng)
20 tác vụ cho mỗi ngôn ngữ, mỗi lần chạy chỉ có một lượt thử, theo kiểu one-shot
Gần đây tôi cũng đã thêm tính năng so khớp gần đúng vào tau (chuỗi bước cắt khoảng trắng: trim_end → trim_both → unicode normalization) và muốn xem tính năng này có giúp ích không

Kết quả

Chế độ replace:

Mô hình	Python	TypeScript	Rust
gemini-3-flash	95%	80%	95%
qwen3.5-397b	90%	85%	85%
gpt-4.1-mini	65%	75%	45%

Chế độ hashline (từ các lần chạy trước):

Mô hình	Python	TypeScript	Rust
gemini-3-flash	70%	85%	90%
qwen3.5-397b	85%	85%	90%
gpt-4.1-mini	50%	70%	55%

Hashline làm giảm hiệu quả rõ rệt với Python, còn với TypeScript và Rust thì có vẻ gần như không tạo ra khác biệt. Sự phụ thuộc vào ngôn ngữ này khá thú vị — việc khoảng trắng có ý nghĩa cú pháp trong Python có thể khiến các thao tác chỉnh sửa neo theo dòng dễ gây lỗi hơn.

So khớp gần đúng có giúp ích không?

Có vẻ là không.

Tôi đã thêm tính năng thu thập dấu vết thực thi để xem chuỗi bước cắt khoảng trắng nhằm so khớp gần đúng của tau có bao giờ được kích hoạt trong các lần chạy ở chế độ replace hay không. Trong 114 lần chỉnh sửa thành công và 20 lần chỉnh sửa thất bại (3 mô hình × 3 ngôn ngữ), tính năng so khớp gần đúng được kích hoạt 0 lần.

Trong 20 lần chỉnh sửa thất bại:

1 lần có khoảng trắng ở cuối dòng (về lý thuyết có thể khắc phục)
~8 lần đưa cả số dòng vào old_string (lỗi của mô hình)
~11 lần chứa nội dung hoàn toàn do mô hình bịa ra

Khi các mô hình tái tạo đúng old_string, chúng cũng tái tạo đúng khoảng trắng. Khi làm sai, chúng sai lệch rất nhiều — chuỗi bước cắt khoảng trắng không giúp được gì.

(Chi tiết phân tích dấu vết thực thi)

Những điều rút ra

Không có bên nào thắng rõ ràng khi so sánh hashline với replace. Tác động phụ thuộc vào ngôn ngữ và mô hình. Với Python, hashline kém hiệu quả hơn; với TypeScript thì không có khác biệt; với Rust thì khó phân thắng bại.
Khó khái quát hóa kết quả của Can. react-edit-benchmark chỉ dùng JavaScript và sử dụng một LSP để phản hồi kết quả kiểm tra. Thiết lập của chúng tôi (không có LSP, nhiều ngôn ngữ) cho thấy một bức tranh khác. Đặc biệt, vòng lặp phản hồi từ LSP nhiều khả năng là một yếu tố gây nhiễu. Việc cung cấp các lỗi kiểu dữ liệu để mô hình dựa vào đó thử lại mang lại mức cải thiện đáng kể, có tác động qua lại với định dạng chỉnh sửa.
So khớp gần đúng không phải là vấn đề cần giải quyết với các mô hình hiện nay. Các LLM hoặc tái tạo chính xác văn bản nguồn, hoặc bịa ra thứ gì đó hoàn toàn khác. Trường hợp gần khớp nhưng lệch khoảng trắng mà so khớp gần đúng nhắm đến về cơ bản không xảy ra trong thực tế.
Với các mô hình thế hệ hiện tại trong các harness hiện nay, định dạng chỉnh sửa không phải là nút thắt. Khoảng cách giữa các mô hình (gemini-3-flash đạt 90%+ so với gpt-4.1-mini đạt 55-65%) lớn hơn rất nhiều so với khoảng cách giữa các định dạng chỉnh sửa. Hãy đầu tư vào việc lựa chọn mô hình và kỹ thuật thiết kế prompt trước khi lo đến định dạng chỉnh sửa.

Lời lưu ý không thể thiếu: cỡ mẫu nhỏ, không chặt chẽ về mặt thống kê, nên cân nhắc những giới hạn này khi đánh giá kết quả.

Toàn bộ dữ liệu: nwyin/edit-bench, các issue #13 và #14.