Chi phí xác minh mới là chi phí lập trình AI thực sự

Tôi từng đặt ra một câu hỏi khi chọn một mô hình AI để lập trình.

Mô hình nào đủ mạnh cho tác vụ này?

Câu hỏi đó cũng ổn. Nhưng nó không còn là câu hỏi đầu tiên của tôi nữa.

Câu hỏi hay hơn là: Tôi có thể xác minh kết quả đầu ra nhanh đến mức nào?

Tư duy này thay đổi cách bạn sử dụng các mô hình chi phí thấp. Đừng coi chúng là những phiên bản yếu hơn của các mô hình lớn. Hãy coi chúng là những nhân viên cho các tác vụ có quy trình xác minh ngắn.

Một số tác vụ có chi phí kiểm tra rẻ vì bạn có thể thấy kết quả ngay lập tức.

• Dọn dẹp README • Ví dụ sử dụng • Chú thích mã nguồn • Ghi chú thay đổi (Changelog) • Các script định dạng nhỏ • Các mẫu issue (Issue templates)

Nếu một mô hình viết một đoạn README tồi, bạn sẽ thấy ngay. Bạn chỉ cần xóa phần đó đi. Lỗi đó tuy gây khó chịu, nhưng hầu như không tốn kém gì. Đây là cách sử dụng tốt nhất cho các mô hình giá rẻ.

Danh mục tiếp theo là các công việc có thể kiểm thử (testable work).

Nếu bạn có thể xác định hành vi mong đợi và chạy một bộ kiểm thử (test suite), hãy sử dụng mô hình rẻ hơn cho bản nháp đầu tiên. Bạn phải đưa ra các ranh giới rõ ràng cho mô hình.

Đừng nói: Add tests for this helper.

Hãy nói: Add tests for empty input, null input, duplicate values, invalid config, default config, and normal input. Do not change runtime code.

Điều này buộc mô hình phải làm việc trong một khuôn khổ xác minh.

Một số tác vụ thiếu các bài kiểm tra tự động nhưng cho phép kiểm tra thủ công rõ ràng.

• Định dạng đầu ra CLI • Ví dụ cấu hình • Ghi chú chạy thử di trú (Migration dry run) • Các script chuyển đổi dữ liệu nhỏ

Đối với những việc này, hãy yêu cầu mô hình bao gồm:

  • Cách chạy mã
  • Sử dụng đầu vào nào
  • Kết quả đầu ra mong đợi là gì
  • Cần kiểm tra những trường hợp biên (edge cases) nào

Nếu một mô hình không thể giải thích cách xác minh chính công việc của nó, đừng tin tưởng vào mã đó.

Các đợt tái cấu trúc (refactor) nhỏ rất nguy hiểm. Một bản diff có thể trông ngắn gọn và sạch sẽ. Nhưng hành vi có thể thay đổi trong một luồng ẩn, một giá trị mặc định hoặc một bước kiểm tra quyền hạn.

Hãy tăng mức độ rủi ro khi một tác vụ chạm đến:

  • Các phương án dự phòng (Fallbacks)
  • Các giá trị mặc định (Defaults)
  • Định tuyến (Routing)
  • Quyền hạn (Permissions)
  • Thanh toán (Billing)
  • Giới hạn tốc độ (Rate limits)
  • Di trú (Migrations)
  • Khả năng tương thích ngược (Backwards compatibility)

Những lỗi này rất khó nhận ra trong một đợt kiểm tra mã (code review) tiêu chuẩn. Chúng đòi hỏi ngữ cảnh sâu.

Hãy phân loại công việc theo chi phí xác minh:

  • Chi phí xác minh thấp: Sử dụng mô hình giá rẻ để soạn bản nháp.
  • Chi phí xác minh trung bình: Sử dụng mô hình giá rẻ, sau đó con người chỉnh sửa.
  • Chi phí xác minh cao: Sử dụng mô hình mạnh mẽ kèm theo các bài kiểm tra và sự xem xét của con người.

Quy mô không quan trọng. Một tác vụ nhỏ sẽ trở nên đắt đỏ nếu nó khó xác minh.

Phần đắt đỏ của lập trình AI không phải là việc tạo mã. Đó là sự tin tưởng.

Source: https://dev.to/zephyrelabs369/verification-cost-is-the-real-ai-coding-cost-1354

Optional learning community: https://t.me/GyaanSetuAi