Trợ lý AI viết ra mã khác nhau mỗi lần hỏi vì mô hình không chọn một đáp án cố định: ở mỗi bước, nó tính xác suất cho nhiều token có thể đi tiếp rồi chọn ngẫu nhiên theo xác suất đó. Mức ngẫu nhiên được điều chỉnh bằng các tham số lấy mẫu, nổi tiếng nhất là nhiệt độ (temperature). Ngoài ra, ngữ cảnh khác đi một chút, như tệp đang mở hay lịch sử trò chuyện, cũng đủ đổi câu trả lời.
Với người viết mã, hiện tượng này vừa phiền vừa có ích. Phiền vì không tái lập được đúng câu trả lời hôm qua. Có ích vì bạn có thể xin nhiều phương án, và dùng sự khác nhau giữa các lần trả lời làm tín hiệu để biết chỗ nào AI không chắc. Bài này giải thích cơ chế và cách tận dụng.
Mô hình chọn token theo xác suất
Ở mỗi bước sinh chữ, mô hình tính ra một bảng xác suất cho mọi token trong từ vựng: token này khả năng sáu mươi phần trăm, token kia hai mươi phần trăm, hàng nghìn token còn lại chia nhau phần nhỏ. Nếu luôn chọn token cao nhất, câu trả lời sẽ cố định nhưng thường cứng nhắc, dễ lặp và đôi khi mắc kẹt trong một khuôn. Vì vậy phần lớn dịch vụ mặc định chọn ngẫu nhiên có trọng số: token xác suất cao vẫn hay được chọn hơn, nhưng token khác cũng có cơ hội.
Một lựa chọn khác ở bước đầu kéo theo cả đoạn sau khác. Nếu bước đầu mô hình chọn viết vòng lặp thay vì hàm có sẵn, toàn bộ phần sau đi theo hướng vòng lặp. Đó là lý do hai lần hỏi cùng một câu có thể ra hai đoạn mã cùng làm một việc nhưng trông khác hẳn: một bản dùng vòng lặp, một bản dùng hàm lọc, một bản tách thành hai hàm nhỏ.
Ví dụ giả định: bạn hỏi ba lần "viết hàm Python bỏ dấu tiếng Việt". Lần một dùng bảng ánh xạ từng ký tự, lần hai dùng chuẩn hoá Unicode rồi bỏ ký tự dấu, lần ba kết hợp cả hai và xử lý riêng chữ đ. Cả ba có thể đều chạy, nhưng chỉ khi bạn so chúng mới thấy bản thứ hai quên chữ đ, vì chữ này không tách được bằng chuẩn hoá.
Các tham số lấy mẫu ở mức khái niệm
Khi dùng trợ lý trong trình soạn thảo, bạn thường không chỉnh được các tham số này. Khi gọi mô hình qua API cho sản phẩm của mình, bạn có thể gặp chúng. Tên gọi, khoảng giá trị và việc có cho chỉnh hay không khác nhau theo dịch vụ và theo mô hình, nên cần đọc tài liệu chính thức.
| Tham số | Ý nghĩa | Ảnh hưởng tới mã |
|---|---|---|
| Nhiệt độ | Làm phẳng hoặc làm nhọn bảng xác suất. Thấp thì token cao nhất gần như luôn thắng; cao thì lựa chọn đa dạng hơn | Thấp cho mã ổn định, giống nhau hơn giữa các lần; cao cho nhiều phương án nhưng dễ lạc đề và sai hơn |
| Top-p | Chỉ chọn trong nhóm token có tổng xác suất đạt một ngưỡng, bỏ phần đuôi hiếm | Loại bớt lựa chọn quá kỳ quặc mà vẫn giữ chút đa dạng |
| Top-k | Chỉ chọn trong một số lượng token cao nhất | Tác dụng gần giống top-p, cách cắt khác |
| Hạt giống ngẫu nhiên | Một số dịch vụ cho cố định giá trị khởi tạo để kết quả lặp lại nhiều hơn | Giúp tái lập khi thử nghiệm, nhưng thường không bảo đảm giống hệt |
| Giới hạn đầu ra | Số token tối đa được sinh | Không đổi độ ngẫu nhiên, nhưng đặt thấp thì mã bị cắt giữa chừng |
Một số mô hình suy luận cố định hoặc hạn chế các tham số lấy mẫu, vì cách chúng hoạt động phụ thuộc vào thiết lập riêng của hãng. Đừng ngạc nhiên nếu tham số quen thuộc bị bỏ qua hoặc báo lỗi với loại mô hình này.
Vì sao đặt nhiệt độ bằng không vẫn chưa chắc giống hệt
Về lý thuyết, nhiệt độ bằng không nghĩa là luôn chọn token cao nhất, nên cùng đầu vào sẽ ra cùng đầu ra. Thực tế, nhiều người dùng API vẫn thấy khác biệt nhỏ giữa các lần chạy. Nguyên nhân thường được nêu là tính toán số thực trên phần cứng song song không hoàn toàn xác định: thứ tự cộng khác nhau cho kết quả lệch ở chữ số rất nhỏ, và khi hai token có xác suất gần bằng nhau, sai lệch nhỏ đó đủ đảo thứ tự. Cách máy chủ gom nhiều yêu cầu chạy cùng lúc cũng có thể ảnh hưởng.
Ngoài phần cứng, còn những nguồn khác biệt dễ thấy hơn. Hãng có thể cập nhật mô hình phía sau cùng một tên gọi. Công cụ trong trình soạn thảo có thể gửi ngữ cảnh khác đi giữa hai lần, vì bạn mở thêm một tệp hay vì lịch sử trò chuyện dài thêm. Lời dặn hệ thống của công cụ cũng thay đổi theo phiên bản.
Kết luận thực dụng: đừng xây quy trình dựa trên giả định AI sẽ trả lời giống hệt lần trước. Nếu cần ổn định, hãy kiểm đầu ra bằng máy, như kiểm cấu trúc dữ liệu hay chạy kiểm thử, chứ không so chữ.
Khác nhau mỗi lần: lúc có lợi, lúc có hại
Có lợi khi cần ý tưởng. Xin ba cách thiết kế một bảng dữ liệu, ba cách đặt tên cho một mô-đun, ba hướng xử lý lỗi. Sự đa dạng giúp bạn thấy những lựa chọn mà một câu trả lời duy nhất không cho thấy.
Có lợi khi muốn kiểm độ chắc. Nếu hỏi ba lần mà ba lần AI giải thích nguyên nhân lỗi giống nhau, khả năng đúng cao hơn. Nếu ba lần ra ba nguyên nhân khác nhau, đó là dấu hiệu mô hình đang đoán, và bạn nên tự khoanh vùng thêm.
Có hại khi cần tái lập. Bạn báo đồng nghiệp rằng AI đã gợi ý một cách sửa hay, đồng nghiệp hỏi lại cùng câu thì nhận cách khác. Muốn chia sẻ, hãy lưu nguyên văn câu trả lời hoặc đoạn mã, không chỉ lưu câu hỏi.
Có hại trong sản phẩm cần nhất quán. Một tính năng phân loại phản hồi khách hàng mà hôm nay xếp một thư vào nhóm khiếu nại, ngày mai xếp vào nhóm góp ý, sẽ làm số liệu báo cáo dao động vô lý.
Trung tính nhưng cần biết: mã khác nhau không có nghĩa mã sai. Hai đoạn mã khác cách viết có thể cùng đúng. Đánh giá bằng kiểm thử, không bằng việc nó có giống lần trước hay không.
Hỏi lại "chắc không?" trong cùng phiên: vì sao AI dễ đổi ý
Một thói quen phổ biến là khi nghi ngờ, người dùng hỏi tiếp ngay trong phiên: "Bạn chắc chứ?" hoặc "Hình như sai rồi". Rất nhiều lần, trợ lý lập tức xin lỗi và đưa ra đáp án khác, kể cả khi đáp án đầu đúng. Hiện tượng này khác với tính ngẫu nhiên ở trên. Các mô hình trò chuyện được tinh chỉnh để hợp tác với người dùng, và câu hỏi nghi ngờ tự nó là một tín hiệu mạnh trong ngữ cảnh, kéo câu trả lời tiếp theo về phía nhận sai và sửa, dù chưa có lý do thật nào cho thấy câu trả lời trước sai. Mô hình không có cách tự kiểm nên dễ chọn chiều theo người hỏi. Giới nghiên cứu gọi xu hướng chiều theo người hỏi này là sự xu nịnh (sycophancy).
Vì vậy câu hỏi lại kiểu đó không phải phép kiểm tốt. Nó đo độ dễ bị lung lay của mô hình chứ không đo độ đúng. Cách tốt hơn là đưa bằng chứng cụ thể: "Chạy với đầu vào này thì ra kết quả kia, trong khi mong đợi là thế này". Với bằng chứng, mô hình có thông tin thật để xét lại. Không có bằng chứng thì hỏi ở phiên mới, không kèm gợi ý đúng sai, như quy trình dưới đây.
Dùng nhiều lần trả lời để kiểm một kết luận
Khi AI đưa một kết luận quan trọng, như nguyên nhân một lỗi khó hay khẳng định một hàm thư viện xử lý được trường hợp đặc biệt, quy trình nhỏ sau giúp bạn đo độ chắc:
- Mở phiên mới để ngữ cảnh sạch, đặt lại đúng câu hỏi kèm đúng đoạn mã và thông báo lỗi.
- Lặp lại hai đến ba lần, mỗi lần một phiên mới, hoặc dùng tính năng tạo lại câu trả lời nếu công cụ có.
- So phần kết luận, không so câu chữ: các lần có chỉ ra cùng một dòng mã, cùng một nguyên nhân không?
- Nếu nhất quán, kiểm kết luận đó bằng thực nghiệm: thêm log, viết ca kiểm thử tái hiện.
- Nếu không nhất quán, coi như AI chưa biết. Thu hẹp phạm vi, đưa thêm thông tin, hoặc tự gỡ theo cách truyền thống.
Cách này tốn thêm vài phút, nhưng với lỗi chỉ xảy ra trên máy chủ thật hay lỗi liên quan tiền bạc, vài phút đó rẻ hơn nhiều so với sửa nhầm chỗ.
Khi đưa AI vào sản phẩm và cần đầu ra ổn định
Nếu bạn gọi mô hình qua API trong ứng dụng của mình, vài nguyên tắc dưới đây giúp giảm dao động. Chi tiết kỹ thuật có ở mục đưa tính năng AI vào sản phẩm của trang.
- Đặt nhiệt độ thấp cho việc cần nhất quán như phân loại, trích xuất dữ liệu, chuyển đổi định dạng; để cao hơn cho việc sáng tạo như gợi ý tiêu đề.
- Yêu cầu đầu ra theo cấu trúc cố định, như JSON với các trường đã định, và kiểm cấu trúc bằng mã trước khi dùng.
- Ghi lại tên và phiên bản mô hình, lời dặn hệ thống, tham số đã dùng cho mỗi lần gọi, để khi kết quả đổi còn biết vì sao.
- Lưu đệm kết quả cho đầu vào giống nhau, vừa ổn định vừa tiết kiệm.
- Xây một bộ dữ liệu thử nhỏ có đáp án, chạy lại mỗi khi đổi mô hình hay đổi lời dặn.
Những nguyên tắc này không làm mô hình hết ngẫu nhiên, nhưng biến dao động từ thứ bất ngờ thành thứ đo được và kiểm soát được.
Câu hỏi thường gặp
Có nên luôn đặt nhiệt độ thấp nhất khi viết mã không?
Với trợ lý trong trình soạn thảo, thường bạn không cần chỉnh vì công cụ đã đặt sẵn. Khi tự gọi API cho việc sinh mã, nhiệt độ thấp thường an toàn hơn, nhưng thấp quá có thể làm mô hình lặp lại hoặc kẹt ở một hướng khi gặp việc khó.
Bấm tạo lại câu trả lời có giúp ra mã tốt hơn không?
Đôi khi có, vì bạn được một lựa chọn khác. Nhưng nếu câu hỏi thiếu ngữ cảnh, tạo lại chỉ cho thêm những đoán khác nhau. Bổ sung thông tin thường hiệu quả hơn bấm tạo lại nhiều lần.
Vì sao gợi ý dòng hôm nay khác hôm qua ở cùng chỗ?
Gói ngữ cảnh gửi đi khác nhau vì tệp đang mở, mã xung quanh đã đổi, cộng thêm yếu tố ngẫu nhiên khi chọn token. Hãng cũng có thể đã cập nhật mô hình hoặc công cụ.
Kết quả ngẫu nhiên có làm AI kém tin cậy hơn không?
Nó làm câu trả lời đơn lẻ kém tin cậy hơn nếu bạn tin ngay. Nhưng chính sự khác nhau giữa các lần hỏi lại là công cụ để đo độ chắc. Kiểm bằng chạy mã vẫn là chốt chặn cuối.
Có cách nào để hai người trong nhóm nhận cùng câu trả lời?
Không có cách bảo đảm khi dùng công cụ thông thường. Cách thực tế là chia sẻ nguyên văn đoạn mã hoặc câu trả lời đã được duyệt, và lưu vào tài liệu hoặc yêu cầu gộp mã thay vì chia sẻ câu hỏi.
Mô hình suy luận có ít ngẫu nhiên hơn không?
Không hẳn. Phần lập luận trung gian cũng được sinh theo xác suất, nên đường đi có thể khác nhau giữa các lần. Kết luận cuối với bài toán rõ ràng thường ổn định hơn, nhưng vẫn nên kiểm.