Một nghiên cứu gần đây về các mô hình ngôn ngữ mã nguồn mở dành cho hỗ trợ lập trình đã tiết lộ những khoảng cách đáng kể giữa kỳ vọng và thực tế. Mặc dù những mô hình này hứa hẹn sự tự do khỏi việc phụ thuộc vào nhà cung cấp và lo ngại về chi phí, hiệu suất thực tế của chúng trong các tác vụ phát triển vẫn còn đáng thất vọng so với các giải pháp thương mại.
Hiệu Suất Mô Hình Không Đáp Ứng Kỳ Vọng
Thử nghiệm cho thấy các mô hình mã nguồn mở phổ biến gặp khó khăn với những tác vụ lập trình cơ bản. Mô hình Deepseek R1 8B được thảo luận rộng rãi, mặc dù có các chỉ số benchmark ấn tượng, thường xuyên bị kẹt trong các vòng lặp suy luận và không thể hoàn thành các yêu cầu lập trình đơn giản. Trong khi đó, Mistral 7B có xu hướng tạo ra các hàm ảo và thay đổi ngẫu nhiên các phần code không liên quan. Chỉ có Qwen3 8B cho thấy hiệu suất tương đối đáng tin cậy, mặc dù vẫn còn xa mới lý tưởng.
Cộng đồng đã lưu ý một sự phân biệt quan trọng ở đây - nhiều mô hình nhỏ hơn này thực chất là các phiên bản chưng cất từ những mô hình lớn hơn, điều này có thể giải thích cho khả năng hạn chế của chúng. Như một người quan sát đã chỉ ra, mô hình Deepseek 8B về cơ bản là phiên bản nén của Qwen2, gợi ý rằng người dùng có thể đạt được kết quả tốt hơn với các mô hình Qwen3 gốc ở kích thước lớn hơn.
Bảng So Sánh Các Mô Hình
| Mô Hình | Kích Thước | Hiệu Suất | Vấn Đề Chính |
|---|---|---|---|
| Deepseek R1 8B | 5.2 GB | Kém | Bị mắc kẹt trong vòng lặp suy luận, thất bại với các tác vụ đơn giản |
| Mistral 7B | ~7B tham số | Dưới trung bình | Ảo giác các hàm, xóa code một cách ngẫu nhiên |
| Qwen3 8B | ~8B tham số | Chấp nhận được | Hiệu suất tốt nhất nhưng vẫn còn hạn chế, hỗ trợ cả chế độ suy luận và không suy luận |
Cuộc Tranh Luận Về Mã Nguồn Mở Ngày Càng Gay Gắt
Một cuộc thảo luận sôi nổi đã nổi lên xung quanh việc điều gì thực sự cấu thành mã nguồn mở trong thế giới AI. Các nhà phê bình cho rằng nhiều mô hình được gọi là mã nguồn mở chỉ đơn thuần là phần mềm miễn phí, thiếu các thành phần thiết yếu cần thiết cho sự mở thực sự - bao gồm dữ liệu huấn luyện, code huấn luyện và giấy phép phù hợp.
Quyết định gần đây của Open Source Initiative về việc nới lỏng tiêu chuẩn cho các mô hình AI đã gây ra tranh cãi. Mặc dù họ không còn yêu cầu việc công bố dữ liệu huấn luyện, nhiều thành viên cộng đồng tin rằng điều này làm suy yếu các nguyên tắc cốt lõi của phần mềm mã nguồn mở. Mối quan tâm mở rộng từ các yêu cầu kỹ thuật đến những tác động thực tế - không có dữ liệu huấn luyện, người dùng không thể kiểm toán mô hình về độ thiên vị, tái tạo kết quả, hoặc thực hiện các cải tiến có ý nghĩa.
Dữ liệu huấn luyện nên được yêu cầu công bố để được coi là một mô hình mã nguồn mở. Không có nó, tất cả những gì tôi có thể làm là thiết lập trọng số, v.v. Không có dữ liệu huấn luyện, tôi không thể thực sự tái tạo mô hình, kiểm tra dữ liệu về độ thiên vị/kiểm toán mô hình về tính công bằng.
Yêu cầu cho Mô hình AI Mã nguồn Mở (Thang điểm 10)
- Mã nguồn mô hình ( PyTorch , v.v.)
- Mã nguồn tiền huấn luyện
- Mã nguồn tinh chỉnh
- Mã nguồn suy luận
- Dữ liệu huấn luyện thô
- Dữ liệu huấn luyện đã xử lý
- Trọng số mô hình
- Đầu vào/đầu ra suy luận với giấy phép phù hợp
- Các bài báo nghiên cứu và tài liệu
- Thông tin bằng sáng chế hoặc việc không có bằng sáng chế
Thử Nghiệm Thực Tế Cho Thấy Kết Quả Trái Chiều
Thử nghiệm thực tế với các công cụ như Aider cho thấy rằng mặc dù những mô hình này có thể xử lý các tác vụ tái cấu trúc đơn giản khi được đưa ra hướng dẫn rõ ràng, chúng thường mất nhiều thời gian hơn so với việc code thủ công. Trường hợp sử dụng hứa hẹn nhất xuất hiện trong việc khắc phục sự cố - các mô hình xuất sắc trong việc giải thích thông báo lỗi khi được cung cấp ngữ cảnh code liên quan, có thể giảm một nửa thời gian debug.
Tuy nhiên, các nỗ lực phát triển từ đầu đã tỏ ra thảm họa, với các mô hình tạo ra code không hoạt động đầy rẫy các ảo giác. Việc thiếu ngữ cảnh code hiện có dường như làm cản trở đáng kể hiệu suất của mô hình, gợi ý rằng những công cụ này hoạt động tốt nhất như các trợ lý thay vì các nhà phát triển tự động.
Kết quả hiệu suất công cụ Aider
- Tái cấu trúc: Thành công nhưng chậm hơn so với lập trình thủ công (hơn 10 phút so với công việc thủ công)
- Phát triển Greenfield: Thất bại hoàn toàn với mã code ảo tưởng, không hoạt động
- Khắc phục sự cố: Trường hợp sử dụng thành công nhất, có thể giảm thời gian debug khoảng ~50%
- Yêu cầu ngữ cảnh: Hoạt động tốt nhất với ngữ cảnh mã code hiện có, gặp khó khăn khi thiếu ngữ cảnh
Hạn Chế Phần Cứng Tạo Ra Các Rào Cản Bổ Sung
Thực tế của việc chạy những mô hình này cục bộ đặt ra một thách thức khác. Hầu hết các mô hình mã nguồn mở được tối ưu hóa cho các triển khai lớn hơn, dựa trên đám mây với các cửa sổ ngữ cảnh mở rộng. Các thiết lập cục bộ với phần cứng hạn chế gặp khó khăn với các hạn chế về kích thước ngữ cảnh, thường dẫn đến thất bại khi xử lý toàn bộ kho code.
Các công cụ như Qwen Code, được thiết kế cho hoạt động tự động, thường xuyên thất bại trên phần cứng cục bộ do những hạn chế này. Giới hạn ngữ cảnh 40,000 token của các mô hình cục bộ trở nên nhỏ bé so với khả năng 1 triệu token mà những công cụ này mong đợi từ các dịch vụ thương mại.
Tình trạng hiện tại của các công cụ lập trình AI mã nguồn mở cho thấy chúng chưa sẵn sàng để thay thế các giải pháp thương mại cho công việc phát triển nghiêm túc. Mặc dù chúng cho thấy tiềm năng trong các lĩnh vực cụ thể như hỗ trợ debug, những hạn chế trong lập trình tự động và các vấn đề về độ tin cậy khiến chúng phù hợp hơn cho thử nghiệm thay vì sử dụng trong sản xuất. Cuộc tranh luận đang diễn ra về tính mở thực sự trong các mô hình AI thêm một lớp phức tạp khác cho các nhà phát triển đang tìm kiếm các giải pháp thay thế thực sự cho các giải pháp độc quyền.
Tham khảo: Playing with open source LLMs