Giờ cứ vài tuần lại có một model mới xuất hiện trong ô chọn của công cụ bạn dùng. Model nào cũng kèm điểm benchmark, và điểm benchmark không trả lời câu hỏi của bạn, vì câu hỏi của bạn không phải "model này có giỏi không" — mà là "model này có tốt hơn trên code của tôi, với loại việc tôi thật sự làm hay không".
Câu hỏi đó trả lời rất rẻ. Đây là quy trình mất một buổi chiều và cho bạn thứ đáng tin hơn mọi bảng xếp hạng.
Vì sao benchmark không giúp được bạn
Benchmark công khai đo hiệu năng trên những bài toán được chọn vì đo được: khép kín, không mơ hồ, có đáp án kiểm tra được. Gần như không việc nào trong tuần làm việc của bạn có được những tính chất đó.
Đầu việc thật của bạn đi kèm ngữ cảnh mà benchmark cắt bỏ — một phong cách viết code, ba năm quyết định không ai ghi lại, một bộ test có cá tính riêng, và một định nghĩa "đúng" bao gồm cả việc không làm hỏng thứ gì đó nằm cách hai thư mục.
Một model có thể đứng đầu bảng xếp hạng mà vẫn tệ hơn với bạn, và lý do không hề bí ẩn. Nó được tối ưu cho giá trị trung bình của một phân phối mà codebase của bạn không nằm trong đó.
Dựng bộ kiểm thử từ việc bạn đã từng chứng kiến
Đây là toàn bộ mẹo. Đừng nghĩ ra đầu việc kiểm thử — hãy lấy ba việc bạn đã tận mắt xem một model làm trong tháng này, vì bạn đã biết câu trả lời tốt trông ra sao. Chính kiến thức có sẵn đó khiến phép so sánh trở nên trung thực.
Chọn mỗi loại một việc:
- Một lần refactor — nhiều file, không thêm hành vi mới, rủi ro nằm ở chỗ hỏng ngầm. Đo xem model có thực sự hiểu cấu trúc của bạn không
- Một bug có test tái hiện được — đã tồn tại một kết quả đúng, nên đây là đầu việc duy nhất bạn khách quan được
- Một lần giải thích code lạ — lấy một module bạn hiểu rõ, yêu cầu giải thích, rồi đối chiếu với hiểu biết của mình. Đo xem nó có "sai một cách tự tin" không, và đây là kiểu hỏng gây tốn kém nhất về sau
Ghi lại bốn thứ cho mỗi lần chạy
Không phải điểm số. Bốn quan sát, vì thứ bạn cần tìm là hình dạng của các lần hỏng chứ không phải một con số.
- Nó có tới đích không — có, không, hay có-sau-khi-bạn-can-thiệp. Đáp án thứ ba mới là đáp án thú vị, và một điểm số sẽ che mất nó
- Bạn đã sửa bao nhiêu lần, và có phải cùng một lỗi sửa đi sửa lại không. Model cần cùng một cú nhắc mỗi lần là model chưa hiểu điều gì đó mang tính cấu trúc trong dự án của bạn
- Nó làm gì khi không chắc — hỏi lại, đoán bừa trong im lặng, hay bịa ra một API. Đây là tín hiệu dự báo tốt nhất cho việc có nên trao quyền tự chủ cho model đó không
- Đại khái nó tốn bao nhiêu, theo đúng đơn vị công cụ của bạn tính tiền. Một model tốt hơn 10% mà đắt gấp 4 lần thì không phải là tốt hơn
Phán đoán mà không tự lừa mình
Ba kiểu thiên lệch phá hỏng phần lớn các đợt đánh giá không chính thức, và cả ba đều tránh được.
Thiên lệch vì cái mới: model mới được viết câu lệnh cẩn thận hơn vì bạn đang chú ý tới nó. Hãy viết sẵn câu lệnh trước khi biết model nào sẽ chạy, rồi dùng lại nguyên văn.
Thiên lệch vì văn hay: đầu ra viết mượt đọc như thể đúng hơn. Đặc biệt ở đầu việc giải thích code, hãy đối chiếu từng khẳng định với điều bạn đã biết thay vì đánh giá theo giọng văn. Tự tin mà sai còn tệ hơn ngập ngừng mà đúng.
Thiên lệch vì chạy một lần: các phiên agent không tất định. Nếu kết quả sát nhau, hãy chạy lại đầu việc sửa bug thêm hai lần. Nếu một model thắng với khoảng cách mà lần chạy thứ hai xóa sạch, kết luận trung thực là không có khác biệt.
Câu trả lời thường là "không quan trọng"
Đó là một kết quả thật và nó nên khiến bạn nhẹ nhõm. Nếu cả hai model đều hoàn thành ba đầu việc với mức can thiệp tương đương, thì việc chọn model không phải nút thắt của bạn, và đánh giá tiếp chỉ là trì hoãn khoác áo cẩn trọng.
Khi rơi vào tình huống đó, hãy chọn theo các trục khác: chi phí, việc quản trị viên có phải bật chính sách cho nó không, nó có sẵn trong mọi editor đội bạn dùng không, và khả năng một năm nữa nó còn tồn tại. Đó đều là những câu hỏi trả lời được và câu trả lời có tuổi thọ dài — nhiều hơn những gì phép so sánh năng lực mang lại cho bạn.
Ghi kết quả lại
Ba câu trong một tài liệu dùng chung: bạn đã thử gì, thấy gì, quyết định gì. Ghi ngày tháng.
Vài tuần nữa model tiếp theo sẽ tới và sẽ có người hỏi đúng câu hỏi cũ. Không có ghi chú, đội bạn tranh luận lại từ đầu mỗi lần, và chi phí tích lũy của việc đó lớn hơn nhiều so với một buổi chiều bỏ ra để kiểm thử.