Nhiệt độ trong LLM là gì?

Scrapeless Agent Browser cung cấp một trình duyệt đám mây cho tự động hóa web.

Nhiệt độ trong LLM là một tham số giải mã làm thay đổi các xác suất tương đối được sử dụng khi lấy mẫu token tiếp theo. Các giá trị dương thấp hơn tập trung xác suất vào những ứng viên có điểm số cao hơn. Các giá trị cao hơn làm phẳng phân phối và cho phép những ứng viên ít khả năng hơn được chọn thường xuyên hơn. Nhiệt độ thay đổi hành vi chọn lựa; nó không bổ sung kiến thức cho mô hình.

Sự phân biệt đó quan trọng khi bạn cấu hình một trợ lý chạy thực tế. Cách diễn đạt đa dạng hơn có thể hữu ích cho việc động não, trong khi định dạng nhất quán có thể quan trọng hơn cho trích xuất. Không mục tiêu nào trong số đó có thể được rút gọn thành một con số tối ưu mang tính phổ quát. Hãy chọn thiết lập thông qua đánh giá trên chính mô hình, lời nhắc và tác vụ thực tế của bạn.

Nhiệt độ thay đổi xác suất token như thế nào

Nhiệt độ tái chuẩn hóa điểm số token trước khi phân phối lấy mẫu được tính toán. Trong công thức phổ biến, logit của mỗi ứng viên được chia cho một nhiệt độ dương và kết quả được đưa qua softmax. Ở giá trị một, nhiệt độ không tái chuẩn hóa các logit. Giá trị dưới một làm cho các khác biệt điểm số hiện có trở nên rõ ràng hơn; giá trị trên một làm giảm ảnh hưởng tương đối của chúng.

Hãy tưởng tượng một lựa chọn token tiếp theo giả định trong đó một ứng viên có điểm số cao hơn ứng viên khác. Hạ nhiệt độ làm tăng lợi thế tương đối của token có điểm số cao hơn. Nó không đưa vào một bước kiểm tra bằng chứng hay quyết định liệu token đó có đúng hay không. Cơ chế này vận hành trên phần tiếp diễn được mô hình dự đoán, vốn có thể ưu tiên một phát biểu đầy tự tin nhưng thiếu căn cứ.

nghiên cứu về giải mã văn bản thần kinh phân biệt mục tiêu huấn luyện với hành vi sinh văn bản và xem xét lý do tại sao các lựa chọn giải mã ảnh hưởng đến chất lượng văn bản. Đối với thiết kế ứng dụng, hệ quả hữu ích rất đơn giản: hãy đánh giá các đầu ra hoàn chỉnh. Một thay đổi ở mức token có thể làm thay đổi một câu sau đó, lựa chọn công cụ, hoặc quyết định dừng theo những cách mà một ví dụ đơn lẻ sẽ không thể bộc lộ.

Nhiệt độ thấp có thể và không thể làm gì

Nhiệt độ thấp thường giảm biến thiên khi lấy mẫu bằng cách ưu tiên các phần tiếp nối có khả năng cao. Điều này có thể hữu ích khi tác vụ cần nhãn ổn định, trích xuất ngắn gọn hoặc cách diễn đạt nhất quán. Nó vẫn là một thiết lập sinh ngẫu nhiên dựa trên xác suất chứ không phải bảo đảm tính đúng đắn, và hiệu ứng của nó phụ thuộc vào cách mô hình và hệ thống phục vụ triển khai việc giải mã.

Một giá trị được hiển thị là 0 thường được xử lý như một trường hợp giải mã đặc biệt chứ không phải phép chia cho 0 theo nghĩa đen. Hãy kiểm tra giao diện của mô hình đã chọn trước khi dựa vào hành vi đó. Ngay cả một chính sách chọn tham lam cũng không nên được mô tả như một lời hứa về các đầu ra hoàn toàn giống nhau trong mọi điều kiện triển khai. Cập nhật mô hình và chi tiết phục vụ có thể ảnh hưởng đến khả năng tái lập một cách độc lập với các điều khiển lấy mẫu hiển thị.

Đối với một tác vụ giả định trích xuất sản phẩm, một thiết lập thấp hơn có thể làm cho định dạng đầu ra ổn định hơn trong khi vẫn liên tục trả về sai loại tiền tệ. Cách khắc phục là cải thiện xử lý bằng chứng và xác thực. Giảm nhiệt độ thêm nữa không thể cung cấp một loại tiền tệ mà đầu vào đã bỏ sót. Hãy giữ các giá trị thiếu ở dạng hiển thị rõ ràng thay vì khuyến khích mô hình tự hoàn thiện chúng từ kỳ vọng.

Vì sao nhiệt độ cao hơn không phải là đảm bảo sáng tạo

Nhiệt độ cao hơn làm tăng khả năng chọn các phần tiếp nối có xác suất thấp hơn, điều này có thể tạo ra các đầu ra đa dạng hơn. Sự đa dạng đó có thể hữu ích để khám phá tên gọi, cách diễn đạt thay thế hoặc những diễn giải có thể có. Nó cũng có thể tạo ra văn bản không liên quan hoặc không nhất quán. Hãy quyết định thế nào là biến thiên hữu ích trước khi đo lường xem một thiết lập có cải thiện được nó hay không.

Một đánh giá cho động não có thể chấm điểm cao cho những ý tưởng khác biệt một cách có ý nghĩa đồng thời vẫn thỏa các ràng buộc. Một đánh giá tóm tắt sự kiện có thể phạt các tuyên bố thiếu căn cứ ngay cả khi văn phong rất lôi cuốn. Những tác vụ đó cần các tiêu chí đánh giá khác nhau. Việc đếm xem có bao nhiêu từ độc nhất xuất hiện là một thay thế yếu cho việc đánh giá xem đầu ra có hữu ích hay không.

Nghiên cứu về nhiệt độ và hiệu suất giải quyết vấn đề cho thấy hành vi phụ thuộc vào tác vụ và mô hình hơn là một quy tắc độ chính xác mang tính phổ quát. Tránh coi nhiệt độ thấp là thiết lập sự thật hoặc nhiệt độ cao là thiết lập trí tuệ. Hãy đánh giá đúng hành vi mà bạn quan tâm và lưu giữ bằng chứng cho lựa chọn đó.

Nhiệt độ so với top-p và các điều khiển khác

Nhiệt độ tái chuẩn hóa các điểm số tương đối, trong khi top-p giới hạn việc lấy mẫu vào tập các token có xác suất tích lũy đạt tới một ngưỡng. Những điều khiển này ảnh hưởng đến các phần khác nhau trong quá trình chọn lựa. Hành vi kết hợp của chúng phụ thuộc vào thứ tự và chi tiết được giao diện mô hình triển khai.

Giới hạn độ dài đầu ra giải quyết một vấn đề khác: lượng văn bản có thể được sinh ra. Một ràng buộc định dạng xử lý cấu trúc đầu ra chấp nhận được. Một hướng dẫn hệ thống mô tả hành vi mong muốn. Thay đổi một trong các điều khiển này không khiến các điều khiển khác trở nên dư thừa. Một câu trả lời với nhiệt độ thấp vẫn có thể quá dài, không hợp lệ với bộ phân tích phía sau, hoặc không được nguồn dữ liệu hỗ trợ.

Khi chẩn đoán vấn đề, hãy thay đổi một điều khiển tại một thời điểm. Nếu bạn đồng thời viết lại prompt, thay thế tài liệu được truy hồi và thay đổi cách lấy mẫu, một kết quả được cải thiện sẽ không cho bạn biết can thiệp nào đã giúp. Hãy ghi lại đầu vào, danh tính mô hình, thiết lập và quyết định chấm điểm cho mỗi lần đánh giá để phép so sánh vẫn có thể diễn giải được.

Chọn một thiết lập với quy trình đánh giá có thể lặp lại

Việc lựa chọn temperature nên bắt đầu với một bộ đánh giá theo tác vụ cụ thể và một định nghĩa về hành vi chấp nhận được. Bao gồm cả các yêu cầu thông thường và những trường hợp khó như đầu vào mơ hồ, thiếu bằng chứng, nguồn mâu thuẫn và tài liệu dài bất thường. Giữ nguyên cùng các đầu vào đánh giá giữa các thiết lập ứng viên.

Chạy mỗi thiết lập trên nhiều yêu cầu và kiểm tra cả chất lượng lẫn sự biến thiên. Lấy mẫu lặp lại có thể bộc lộ sự không ổn định mà một câu trả lời thành công duy nhất che giấu. Đặt số lần chạy theo chi phí của quyết định và mức độ biến thiên quan sát được, thay vì áp đặt một yêu cầu chung tùy tiện. Giữ các ví dụ thất bại trong hồ sơ; lọc chúng ra sẽ làm cho thiết lập có vẻ mạnh hơn thực tế.

Đối với trích xuất có cấu trúc, hãy chấm điểm riêng cho độ chính xác của từng trường, cách xử lý giá trị thiếu và tính hợp lệ của đầu ra. Đối với viết, đánh giá mức độ tuân thủ ràng buộc và sự đa dạng hữu ích. Đối với một agent, hãy đánh giá tham số truyền cho công cụ và điều kiện hoàn thành. Một thiết lập cải thiện độ đa dạng văn bản có thể khiến tác vụ chọn công cụ trở nên kém dự đoán hơn, vì vậy hãy kiểm thử các bề mặt đó một cách độc lập khi ứng dụng cho phép cấu hình tách biệt.

Tách Vấn đề Lấy Mẫu khỏi Vấn đề Bằng Chứng

Vấn đề lấy mẫu liên quan đến sự biến thiên trong cách mô hình chọn câu trả lời; vấn đề bằng chứng liên quan đến việc liệu thông tin cần thiết có sẵn và đáng tin cậy hay không. Chẩn đoán bằng chứng trước khi một câu trả lời chứa một sự kiện hiện tại không được hỗ trợ. Một temperature khác không thể cập nhật tri thức đã lưu trữ của mô hình.

Quy trình tìm kiếm web thời gian thực giải quyết việc thu thập tài liệu nguồn hiện tại. Ứng dụng của bạn vẫn cần kiểm tra tài liệu đó và quyết định phần nào hỗ trợ câu trả lời. Quyền truy cập trình duyệt và các thiết lập giải mã hoạt động ở các lớp khác nhau, vì vậy hãy đánh giá từng lớp dựa trên trách nhiệm riêng của nó.

Ngữ cảnh bổ sung có thể mang lại sao lãng cũng như thông tin. Các thí nghiệm về ngữ cảnh không liên quan trong các tác vụ mô hình ngôn ngữ cho thấy lý do tại sao việc lựa chọn ngữ cảnh xứng đáng được chú ý riêng. Trước khi điều chỉnh lấy mẫu để sửa các câu trả lời không nhất quán, hãy kiểm tra xem prompt có trộn lẫn bằng chứng liên quan với điều hướng không liên quan, nội dung trùng lặp, hoặc các chỉ dẫn mâu thuẫn từ các trang được truy xuất hay không.

Cấu hình Agent theo Loại Quyết định

Một agent có thể thực hiện nhiều loại quyết định mô hình, và một temperature dùng chung có thể ảnh hưởng chúng theo những cách khác nhau. Soạn thảo truy vấn tìm kiếm, chọn một công cụ, trích xuất một mức giá và soạn một lời giải thích cuối cùng không có yêu cầu giống hệt nhau. Khi kiến trúc của bạn hỗ trợ, hãy đánh giá các cấu hình cho từng loại quyết định thay vì giả định một thiết lập phù hợp với toàn bộ tác vụ.

Giữ các ràng buộc thực thi tách khỏi việc lấy mẫu. Danh sách công cụ được phép, xác thực tham số và giới hạn chi tiêu phải vẫn hiệu lực bất kể văn bản mô hình tạo ra là gì. Nếu một agent đề xuất một hành động không được phép, môi trường chạy nên từ chối hành động đó. Việc lấy mẫu thận trọng hơn có thể giảm một số đề xuất không mong muốn, nhưng không nên gánh vác nhiệm vụ kiểm soát truy cập.

Đối với các tác vụ dựa trên trình duyệt, Agent Browser cung cấp bề mặt tương tác. Cấu hình mô hình thuộc về ứng dụng bao quanh. So sánh chi phí các lần gọi mô hình và công việc của trình duyệt một cách riêng rẽ, sử dụng Scrapeless pricing cho phần sau thay vì coi mọi chi phí thời gian chạy đều là token.

Ghi lại Giới hạn của Kết quả

Một khuyến nghị về temperature nên nêu rõ phạm vi đánh giá hỗ trợ nó. Ghi lại cấu hình mô hình, bộ tác vụ, phiên bản prompt và các tiêu chí chất lượng. Nếu bất kỳ yếu tố nào trong số đó thay đổi, hãy kiểm tra xem thiết lập đó còn đáp ứng cùng các yêu cầu hay không trước khi coi kết quả trước đó là hiện hành.

Tránh báo cáo một đánh giá hẹp như một quy tắc chung cho mọi mô hình ngôn ngữ. Hai hệ thống có thể cung cấp một tham số cùng tên nhưng khác nhau về hỗ trợ, mặc định và cách tương tác với các điều khiển khác. Một ghi chú kỹ thuật hữu ích sẽ nêu rõ điều gì đã được đánh giá và các trường hợp lỗi còn lại. Nó không cần khẳng định rằng một giá trị là an toàn nhất hoặc sáng tạo nhất trong mọi trường hợp.

Tóm Lại

Temperature điều khiển phân phối được dùng cho việc lấy mẫu token. Hãy chọn nó bằng cách đo lường hành vi mà ứng dụng của bạn cần, và điều tra riêng các vấn đề thiếu bằng chứng hoặc xác thực kém. Bắt đầu với một rubric tác vụ rõ ràng, so sánh các thiết lập ứng viên trên đầu vào cố định, và giữ lại các ví dụ giải thích vì sao thiết lập đã chọn là phù hợp.