𝗧𝗿𝘂𝘀𝘁 𝗧𝗵𝗲 𝗛𝗮𝗿𝗻𝗲𝘀𝘀, 𝗡𝗼𝘁 𝗧𝗵𝗲 𝗠𝗼𝗱𝗲𝗹
Một mô hình lập trình 27B chạy cục bộ trên phần cứng tại nhà tôi giống như một trò chơi may rủi. Đôi khi nó sửa lỗi code chỉ trong hai mươi phút. Những lúc khác, nó lại chỉnh sửa sai file hoặc viết một bài kiểm tra (test) mà kết quả luôn luôn vượt qua bất kể thế nào.
Mục tiêu của Foreman thuộc LLMKube không phải là tìm ra một mô hình hoàn hảo. Mục tiêu là xây dựng một khung kiểm soát (harness) mà bạn tin tưởng hơn cả mô hình đó.
Cuối tuần này, khung kiểm soát đã tự kiểm tra chính nó bằng cách xây dựng các hàng rào bảo vệ (guardrails) riêng. Đây là những gì đã xảy ra:
• Coder cục bộ của tôi đã tự xây dựng ba cổng kiểm soát mới cho chính nó. • Một cổng kiểm soát xuất hiện cùng với chính lỗi mà nó được thiết kế để phát hiện. Quy trình đánh giá đã bắt được lỗi đó. • Ba người đóng góp mới đã gửi bốn pull request sạch sẽ trong khi các máy móc đang làm việc. • Cùng một mô hình chạy trên một máy AMD và một máy Mac Apple Silicon. Chiếc Mac đã thắng một hiệp đấu mà không ai ngờ tới. • Không có dữ liệu nào chạm tới API đám mây.
Một tác nhân lập trình (coding agent) trên mô hình cục bộ cho ra chất lượng không ổn định. Không có lượng tinh chỉnh câu lệnh (prompt tuning) nào có thể khiến một mô hình nhỏ trở nên đáng tin cậy như một mô hình tiên phong (frontier model).
Foreman không yêu cầu mô hình phải đáng tin cậy. Nó bao bọc mô hình trong một quy trình (pipeline):
- Coder làm việc trong một không gian làm việc được nhân bản (cloned workspace).
- Một cổng kiểm soát nhanh chạy
gofmt,vet,build,lint, và các bài kiểm tra đơn vị (unit tests). - Một người đánh giá (reviewer) đọc sự khác biệt (diff) so với vấn đề (issue) đang giải quyết.
- Một Kubernetes Job trong môi trường sạch (clean-room) sẽ chạy lại toàn bộ bộ kiểm tra trước khi bất kỳ mã nguồn nào được phê duyệt.
- Các rào cản mang tính xác định (deterministic rails) như kiểm tra phạm vi (scope checks) và ngữ cảnh bản đồ kho lưu trữ (repo-map context) bao quanh toàn bộ quy trình.
Mô hình là một phần ngẫu nhiên của một hệ thống. Nhiệm vụ của hệ thống là làm cho kết luận trở nên đáng tin cậy ngay cả khi mô hình không như vậy.
Câu hỏi thực sự không phải là "mô hình có tốt không". Câu hỏi là "liệu khung kiểm soát có bắt được lỗi của mô hình khi nó hoạt động kém hay không".
Cuối tuần này, khung kiểm soát đã bắt được hai lỗi lớn. Cả hai đều là các bài kiểm tra tự xác nhận (self-confirming tests). Các bài kiểm tra này vượt qua vì bản thân chúng được viết để luôn vượt qua. Chúng không thực sự kiểm tra mã nguồn.
Tôi đã chuyển những thất bại này lại cho Foreman. Tôi để khung kiểm soát tự xây dựng các cổng kiểm soát để khắc phục chúng:
- Một trình bảo vệ phạm vi (scope guard): Nó từ chối bất kỳ chỉnh sửa nào chạm vào sai phân hệ (subsystem).
- Một tiêu chí đánh giá (reviewer rubric): Nó đảm bảo các bài kiểm tra sử dụng các giá trị thực tế trong môi trường production thay vì các giá trị giữ chỗ (placeholders).
- Một kiểm tra "vết cắn" (bite check): Một bài kiểm tra mới phải thất bại khi chạy trên mã nguồn cũ. Nếu nó vượt qua cả hai, thì đó không phải là một bài kiểm tra thực sự.
Kiểm tra "vết cắn" đã thất bại ngay trong bài kiểm tra đầu tiên của chính nó. Cổng kiểm soát mà nó xây dựng đã bị lỗi. Nhưng quy trình đánh giá đã bắt được lỗi trước khi nó được hợp nhất (merge). Đó chính là cách thiết kế vận hành.
Bạn không cần một mô hình tiên phong khổng lồ để thực hiện các công việc kỹ thuật tại địa phương. Bạn cần một khung kiểm soát mà bạn tin tưởng. Hãy xây dựng nó, và một mô hình nhỏ sẽ trở thành một cộng sự hữu ích. Nó trở thành một hệ thống giúp bắt lỗi thay vì buộc bạn phải đọc từng dòng mã vào lúc nửa đêm.
Optional learning community: https://t.me/GyaanSetuAi