Mô hình lớn thường giỏi việc khó và nhiều bước hơn nhưng chậm và tốn hơn; mô hình nhỏ nhanh, rẻ, đủ tốt cho việc lặp khuôn; mô hình suy luận dành thêm thời gian "nghĩ" trước khi trả lời nên hợp với gỡ lỗi khó và thiết kế. Chọn đúng loại cho từng việc giúp bạn vừa nhanh vừa đỡ tốn, thay vì dùng một mô hình mạnh nhất cho mọi thứ hoặc một mô hình nhanh nhất rồi thất vọng.
Bài này giải thích khác biệt ở mức người dùng, kèm bảng ghép việc với loại mô hình và cách tự thử. Không có xếp hạng hãng, vì danh sách mô hình đổi theo tháng; điều bền hơn là biết đặt câu hỏi gì khi chọn.
Lớn và nhỏ khác nhau ở đâu
Kích cỡ mô hình thường nói tới số tham số, tức số con số mà mô hình điều chỉnh trong lúc học. Mô hình nhiều tham số hơn, được huấn luyện tốt, thường nắm được nhiều kiến thức hơn và giữ được mạch lập luận dài hơn. Trong lập trình, điều đó thể hiện ở khả năng hiểu yêu cầu mơ hồ, giữ nhiều ràng buộc cùng lúc, và viết mã đúng ở những chỗ hiếm gặp.
Cái giá là tốc độ và chi phí. Mỗi token sinh ra đòi nhiều tính toán hơn, nên câu trả lời chậm hơn và đơn giá cao hơn. Mô hình nhỏ thì ngược lại: trả lời gần như tức thì, đủ để làm gợi ý dòng theo nhịp gõ, và rẻ đến mức dùng cho hàng nghìn lượt mỗi ngày không đáng lo. Chúng thường được tinh chỉnh riêng cho mã nên với việc lặp khuôn, kết quả không thua bao nhiêu.
Cần nói thêm rằng kích cỡ không phải thứ duy nhất quyết định chất lượng. Dữ liệu huấn luyện, cách tinh chỉnh, và lớp công cụ bao quanh ảnh hưởng không kém. Một mô hình vừa phải được gắn vào tác tử biết chạy kiểm thử có thể cho kết quả cuối tốt hơn một mô hình lớn chỉ trả lời trong khung trò chuyện.
Mô hình suy luận là gì
Mô hình suy luận (reasoning model, có nơi gọi là chế độ suy nghĩ mở rộng) là mô hình được huấn luyện để sinh ra một chuỗi lập luận trung gian trước khi đưa câu trả lời cuối. Thay vì viết ngay đoạn mã, nó có thể phân tích yêu cầu, liệt kê các trường hợp, thử một hướng, phát hiện chỗ mâu thuẫn, rồi mới viết. Tuỳ công cụ, bạn được xem toàn bộ, một bản tóm tắt, hoặc không xem được phần lập luận này.
Lợi ích rõ nhất ở những việc cần nhiều bước suy nghĩ: tìm nguyên nhân một lỗi chỉ xảy ra khi hai luồng chạy song song, thiết kế cấu trúc dữ liệu thoả nhiều ràng buộc, viết thuật toán có ca biên phức tạp. Với những việc này, lập luận trung gian giúp mô hình bắt được chỗ sai của chính nó trước khi trả lời.
Đổi lại, mô hình suy luận tốn nhiều token hơn vì phần lập luận cũng là token được sinh ra, và thời gian chờ dài hơn, có khi vài chục giây hoặc hơn. Với câu hỏi đơn giản như đổi tên biến hay viết một hàm định dạng ngày, phần suy nghĩ thêm thường không đem lại gì ngoài sự chậm. Nhiều công cụ cho bật tắt hoặc chỉnh mức suy nghĩ; cách gọi và vị trí tuỳ chọn khác nhau theo sản phẩm, cần xem tài liệu hiện hành.
Ghép việc lập trình với loại mô hình
Bảng dưới là gợi ý khởi đầu, không phải luật. Ranh giới giữa các loại mô hình thay đổi nhanh, nên hãy coi đây là câu hỏi để tự thử.
| Việc | Loại thường hợp | Lý do |
|---|---|---|
| Gợi ý dòng khi gõ | Nhỏ, nhanh | Cần phản hồi trong nhịp gõ; việc chủ yếu là lặp khuôn |
| Viết hàm đơn giản, đổi định dạng dữ liệu, viết biểu thức chính quy có ví dụ | Nhỏ hoặc vừa | Việc rõ ràng, kiểm nhanh, không đáng chờ lâu |
| Giải thích mã lạ, tóm tắt một tệp dài | Vừa hoặc lớn | Cần hiểu mạch và giữ nhiều chi tiết cùng lúc |
| Gỡ lỗi khó, lỗi chập chờn, lỗi đồng thời | Lớn, có suy luận | Cần lập giả thuyết, loại trừ, lần nguyên nhân qua nhiều bước |
| Thiết kế kiến trúc, chọn cấu trúc dữ liệu | Lớn, có suy luận | Cần cân nhắc nhiều ràng buộc và trường hợp |
| Tác tử làm việc nhiều bước trong dự án | Vừa hoặc lớn | Phải tự quyết bước tiếp theo; mô hình yếu dễ lạc hướng |
| Xử lý hàng loạt trong sản phẩm, như phân loại phản hồi | Nhỏ, sau khi đã thử chất lượng | Số lượt lớn, chi phí và độ trễ cộng dồn |
Một số công cụ tự chọn mô hình cho bạn theo loại việc. Điều đó tiện, nhưng khi kết quả kém, hãy kiểm xem việc vừa rồi đã được giao cho mô hình nào.
Dấu hiệu bạn đang dùng sai cỡ mô hình
Quá nhỏ: trả lời đúng khuôn nhưng bỏ qua ràng buộc. Bạn dặn ba điều, mã chỉ làm theo hai. Hoặc mô hình viết lại đúng đoạn bạn đưa mà không sửa gì, kèm lời giải thích nghe hợp lý.
Quá nhỏ: lặp đi lặp lại cùng một hướng sửa sai. Khi được báo lỗi, nó sửa một chi tiết bề mặt rồi lại gặp lỗi cũ. Mô hình không đủ sức lùi lại xem xét giả thuyết khác.
Quá lớn: chờ lâu cho việc vặt. Bạn đợi hai mươi giây để nhận một hàm định dạng số tiền ba dòng. Nhân với hàng chục lượt mỗi ngày, đó là thời gian đáng kể.
Quá nhỏ: hiểu sai câu hỏi tiếng Việt dài. Với yêu cầu nhiều mệnh đề, mô hình nhỏ dễ bỏ qua một vế hoặc hiểu ngược điều kiện. Chia yêu cầu thành các ý gạch đầu dòng giúp được phần nào, nhưng nếu vẫn sai thì nên đổi mô hình.
Quá lớn: câu trả lời dài và cầu kỳ hơn mức cần. Mô hình mạnh, nhất là khi bật suy luận, đôi khi đề xuất kiến trúc phức tạp cho một việc đơn giản. Nói rõ phạm vi và yêu cầu cách đơn giản nhất thường giải quyết được.
Phối hợp hai cỡ mô hình trong một việc: ví dụ giả định
Ví dụ giả định: một nhóm hai người ở Đà Nẵng cần thêm chức năng đặt lịch hẹn có kiểm trùng giờ cho một ứng dụng sẵn có. Một cách chia việc hợp lý:
- Dùng mô hình lớn có suy luận để phân tích yêu cầu: các trường hợp trùng giờ, múi giờ, lịch lặp lại, huỷ và đặt lại. Yêu cầu nó đưa danh sách ca cần xử lý và đề xuất cấu trúc dữ liệu, chưa viết mã.
- Người trong nhóm rà danh sách, bổ sung quy tắc nghiệp vụ mà chỉ họ biết, chốt thiết kế.
- Dùng mô hình vừa trong tác tử để viết kiểm thử theo danh sách ca đã chốt, rồi viết mã cho tới khi kiểm thử qua.
- Dùng gợi ý dòng với mô hình nhỏ khi tự viết phần giao diện và các đoạn lặp khuôn.
- Khi gặp một lỗi khó hiểu, quay lại mô hình có suy luận, đưa đủ thông báo lỗi và đoạn mã liên quan.
Điểm mấu chốt là tách phần cần suy nghĩ khỏi phần cần gõ nhanh. Mỗi phần dùng một loại mô hình, và người vẫn giữ quyết định ở giữa. Cách chia này cũng giúp kiểm soát chi phí: phần tốn token nhất là vòng lặp viết và chạy kiểm thử của tác tử, nên đặt nó ở mô hình vừa thay vì mô hình đắt nhất thường hợp lý.
Lập một bộ thử nhỏ cho riêng nhóm mình
Từ ý tự thử ở trên, một bộ thử dùng lại được có thể gồm những việc sau. Giữ chúng trong một thư mục riêng để mỗi khi có mô hình mới, bạn chạy lại trong một buổi chiều.
- Một lỗi thật đã sửa trong dự án, kèm thông báo lỗi gốc và cách sửa đúng để đối chiếu.
- Một hàm nghiệp vụ có quy tắc riêng của công ty, như cách tính phí hay chiết khấu, kèm bộ kiểm thử sẵn có.
- Một đoạn mã cũ khó đọc, cùng bản giải thích do người trong nhóm viết, để so độ chính xác của phần giải thích.
- Một yêu cầu viết truy vấn SQL trên đúng cấu trúc bảng của dự án, dữ liệu đã thay bằng dữ liệu giả.
- Một yêu cầu có bẫy: thư viện dự án không hỗ trợ chức năng được hỏi, để xem mô hình nói thật hay tự bịa.
- Một việc cho tác tử làm trọn: thêm một trường dữ liệu đi qua ba tầng của ứng dụng, có kiểm thử chấm đúng sai.
Ghi kết quả vào một bảng đơn giản: đúng hay sai, thời gian, số lần phải sửa, ghi chú. Sau vài lần chạy, nhóm sẽ có cảm nhận rõ mô hình nào hợp với mã của mình, thay vì tranh luận theo cảm giác.
Đừng chọn mô hình chỉ theo bảng xếp hạng
Các bảng điểm chuẩn cho mô hình lập trình đo trên những bộ bài tập công khai. Chúng hữu ích để biết xu hướng, nhưng có ba giới hạn. Một, bài tập công khai có thể đã lọt vào dữ liệu huấn luyện, làm điểm cao hơn năng lực thật. Hai, bài tập chuẩn thường là thuật toán gọn hoặc sửa lỗi trong kho mã nguồn mở nổi tiếng, khác xa dự án PHP mười năm tuổi của công ty bạn. Ba, kết quả phụ thuộc rất nhiều vào công cụ bao quanh và cách đặt câu lệnh khi đo.
Vì vậy cách đáng tin nhất là tự thử trên việc thật của mình. Chọn năm đến mười việc tiêu biểu bạn từng làm, đã biết đáp án đúng: một lỗi đã sửa, một hàm đã viết, một đoạn mã cần giải thích. Đưa cùng một yêu cầu cho các mô hình bạn đang cân nhắc, so kết quả theo ba tiêu chí: đúng hay sai, mất bao lâu, bạn phải sửa bao nhiêu. Vài giờ thử như vậy cho thông tin sát hơn bất kỳ bảng xếp hạng nào.
Khi thử, nhớ dùng dữ liệu và mã đã che thông tin nhạy cảm, và nhớ rằng kết quả mỗi lần chạy có thể khác nhau đôi chút, nên chạy mỗi việc vài lần nếu muốn so công bằng.
Câu hỏi thường gặp
Mô hình suy luận có luôn tốt hơn mô hình thường không?
Không. Với việc nhiều bước, mô hình suy luận thường tốt hơn rõ. Với việc đơn giản, nó chậm hơn và tốn hơn mà kết quả gần như giống nhau, có khi còn làm phức tạp hoá vấn đề.
Mô hình nhỏ có dùng được cho tác tử không?
Dùng được với việc đơn giản và có kiểm thử rõ ràng. Với việc nhiều bước trong dự án lớn, mô hình nhỏ dễ lạc hướng hoặc lặp lại, nên thường cần mô hình vừa hoặc lớn.
Có nên đọc phần lập luận của mô hình suy luận không?
Nên đọc lướt khi kết quả có vấn đề, để biết mô hình hiểu sai ở đâu. Nhưng đừng coi phần lập luận là bằng chứng mã đúng; chỉ có chạy kiểm thử mới chứng minh được.
Mô hình mới ra có nên chuyển sang ngay không?
Nên thử trên bộ việc tiêu biểu của bạn trước. Mô hình mới thường tốt hơn ở nhiều mặt nhưng có thể khác về phong cách, độ dài câu trả lời, cách làm theo chỉ dẫn, ảnh hưởng tới quy trình đang chạy.
Kích cỡ mô hình có liên quan tới cửa sổ ngữ cảnh không?
Không trực tiếp. Có mô hình nhỏ với cửa sổ ngữ cảnh rất lớn và mô hình lớn với cửa sổ vừa phải. Hai thông số này cần xem riêng trong tài liệu của từng mô hình.
Dùng nhiều mô hình cùng lúc có rắc rối không?
Có chút chi phí học cách dùng và đổi qua lại. Nhưng với phần lớn người viết mã, hai lựa chọn là đủ: một mô hình nhanh cho việc vặt và một mô hình mạnh cho việc khó.