Học hỏi từ trải nghiệm thực tế

Hậu đào tạo mô hình Perplexity Computer để bắt chước hành vi thành công, giảm nhu cầu chỉnh sửa của người dùng và tránh lỗi công cụ.

Tác giảPerplexity Research

Cách người dùng tương tác với các sản phẩm của chúng tôi trong thế giới thực là một nguồn có giá trị để huấn luyện mô hình. Dữ liệu phong phú, phản ánh phân phối thực tế của các tác vụ của người dùng và nắm bắt các bản sửa lỗi của người dùng và lỗi công cụ mà môi trường tổng hợp có thể bỏ sót.

Một cách phổ biến để học hỏi từ dữ liệu thế giới thực là tinh chỉnh lấy mẫu từ chối: đánh giá kết quả của từng phiên, giữ lại những phiên thành công và huấn luyện mô hình bắt chước chúng. Nhưng kết quả thành công không có nghĩa là mọi bước đều chính xác, vì vậy việc bắt chước toàn bộ quỹ đạo có nguy cơ củng cố các hành vi trung gian tồi bên cạnh những hành vi tốt. Việc loại bỏ các phiên không thành công cũng làm mất đi bằng chứng quan trọng về nơi mô hình không đạt yêu cầu.

Chúng tôi kết hợp tinh chỉnh lấy mẫu từ chối với phương pháp tự chưng cất có hướng dẫn bằng gợi ý để học hỏi từ cả các phiên thành công và không thành công. Gợi ý là một hướng dẫn khắc phục ngắn dựa trên thông tin mà mô hình đã có khi nó mắc lỗi. Các bước hữu ích từ các phiên thành công vẫn là mục tiêu bắt chước, trong khi các gợi ý có cơ sở biến những sai lầm có thể tránh được thành mục tiêu chỉnh sửa.

Các bản sửa lỗi của người dùng và lỗi công cụ bổ sung sự giám sát về những gì đã sai dọc đường, ngoài việc liệu tác vụ có cuối cùng thành công hay không. Chúng tôi áp dụng giai đoạn này sau học tăng cường trong môi trường tổng hợp để giúp thu hẹp khoảng cách giữa các môi trường đó và việc sử dụng trong thế giới thực.

Trong quá trình sử dụng thực tế, một điểm kiểm tra GLM-5.2 được đào tạo sau đó đã giảm tỷ lệ gọi công cụ thất bại xuống 21,2% so với điểm kiểm tra được đào tạo trước đó. Đối với GLM-5.3, quá trình đào tạo sau đã giúp giảm tỷ lệ gọi công cụ thất bại 33,0% và xác suất ước tính trung bình về mức độ không hài lòng của người dùng từ trung bình đến cao là 17,2% so với mô hình gốc.

Từ dữ liệu tổng hợp đến thế giới thực

Các tác vụ tổng hợp cho phép chúng tôi tạo ra các vấn đề được kiểm soát với các kết quả dễ xác minh, nhưng chúng thường bị giới hạn trong một lời nhắc duy nhất và chỉ có thể bao gồm các kịch bản mà chúng tôi thiết kế rõ ràng.

Ngược lại, người dùng trong các phiên thế giới thực mang theo các hướng dẫn, ngữ cảnh và tổ hợp công cụ đa dạng vào các phiên diễn ra qua nhiều lượt tương tác. Việc sử dụng trong thế giới thực như vậy mang lại một cách tự nhiên hai tín hiệu giá trị về lỗi: các bản sửa lỗi của người dùng tiết lộ nơi tác nhân không cung cấp được những gì họ muốn, và lỗi công cụ cho thấy các hành động của nó sụp đổ ở đâu trong môi trường thực. Đường ống lấy mẫu của chúng tôi tôn trọng quyền riêng tư và lựa chọn huấn luyện của người dùng bằng cách loại trừ các phiên có thông tin nhận dạng cá nhân (PII) và từ những người dùng đã chọn không tham gia.

Do đó, dữ liệu thế giới thực cung cấp cho chúng ta các trường hợp lỗi mà môi trường tổng hợp có thể không phơi bày và thường đi kèm với việc lỗi đã xảy ra sẵn ở đó.

Bắt chước các bước tốt, sửa các bước xấu

Khi huấn luyện trên dữ liệu thế giới thực, tinh chỉnh lấy mẫu từ chối (RFT) tiêu chuẩn chọn các phiên thành công dựa trên kết quả cuối cùng của chúng, mà không sử dụng rõ ràng phản hồi của người dùng và công cụ để phân biệt các hành động trung gian tốt với các hành động tồi. Một tác nhân có thể phục hồi từ một lệnh gọi công cụ tồi hoặc sửa lỗi sau phản hồi của người dùng và vẫn cung cấp đầu ra đúng ở cuối.

Việc loại bỏ các phiên thất bại cũng làm hạn chế hiệu quả mẫu. Một phiên không bao giờ đạt được kết quả tốt vẫn có thể tiết lộ một lỗi rõ ràng, có thể tránh được như các tín hiệu huấn luyện hữu ích.

Chúng tôi giải quyết những hạn chế này bằng cách tách biệt hai quyết định: phiên nào chứa hành vi đáng bắt chước và lượt nào chứa sai lầm đáng sửa. Đường ống dữ liệu đưa ra các quyết định này một cách riêng biệt, sau đó gán cho các lượt của mô hình một trong ba cách xử lý:

  • Bắt chước: các lượt không có lỗi trong các phiên thành công nhận được hàm mất mát entropy chéo (CE) thông thường, làm tăng xác suất của các token được ghi lại.
  • Đúng: ở cả phiên thành công và không thành công, các lượt lỗi có gợi ý hợp lệ nhận được hàm mất mát phân kỳ Kullback–Leibler (KL), dịch chuyển mô hình hướng tới các dự đoán token tiếp theo mà nó tạo ra khi thấy gợi ý.
  • Giữ làm ngữ cảnh: các lượt trong phiên không thành công thiếu gợi ý được xác thực, và các lượt bị đánh dấu là kém mà không có gợi ý được xác thực ở cả hai loại phiên, đóng vai trò là ngữ cảnh nhưng không nhận được bất kỳ hàm mất mát nào.

Do đó, các phiên thành công có thể cung cấp cả mục tiêu bắt chước và sửa lỗi, trong khi các phiên không thành công chỉ cung cấp mục tiêu sửa lỗi. Tất cả các lượt còn lại, bao gồm đầu ra của hệ thống, người dùng và công cụ, vẫn giữ nguyên làm ngữ cảnh.

Định tuyến phiên hiện tại và mặt nạ nội dung trợ lý. Các phiên thành công đóng góp các mục tiêu bắt chước; các bản ghi phản hồi được giữ lại có thể đóng góp các bản sửa lỗi có gợi ý ngay cả khi phiên không thành công. Nội dung khác giữ nguyên làm ngữ cảnh. Các phiên chưa hoàn chỉnh bị loại trừ. Ngoại lệ CE yield/stop-token không phải cuối cùng không được vẽ và sơ đồ này không thiết lập hỗn hợp được sử dụng bởi điểm kiểm tra trước đó.

Phần bắt chước sử dụng RFT tiêu chuẩn. Phần khắc phục sử dụng Tự chưng cất theo chính sách (OPSD): cùng một mô hình đóng vai trò là giáo viên và học sinh, với giáo viên được cung cấp thông tin đặc quyền. Ở đây, thông tin đặc quyền đó là một gợi ý ngắn giải thích một lỗi có thể tránh được. Chúng tôi huấn luyện học sinh khớp với các dự đoán token tiếp theo của giáo viên mà không được giao gợi ý.

Cả hai phần đều quan trọng. Huấn luyện chỉ sửa lỗi có thể làm lộ ra một lối tắt: giáo viên và học sinh có thể đồng ý bằng cách bỏ qua ngữ cảnh thay vì học cách sửa lỗi. Thành phần CE neo quá trình huấn luyện vào hành vi hữu ích, giúp ngăn chặn sự đồng thuận xuất phát từ việc bỏ qua ngữ cảnh.

Học sinh sau huấn luyện sau đó trở thành một tùy chọn mô hình trong Computer. Các phiên mới từ việc sử dụng trực tiếp đi qua các bộ lọc đủ điều kiện và quyền riêng tư tương tự trước khi bước vào vòng tiếp theo của đường ống huấn luyện.

Một ví dụ: một phiên có thể dạy cả hai bài học

Tiếp theo, chúng tôi xem xét một ví dụ cụ thể chứa cả sự bắt chước và sửa lỗi.

Hãy xem xét một phiên thành công cuối cùng trong đó người dùng yêu cầu so sánh các thay đổi asyncio trong Python 3.13 bằng cách sử dụng tài liệu chính thức. Tài liệu công cụ của chúng tôi nêu rõ rằng search.web trả về một danh sách các kết quả khớp, mỗi kết quả có một trường url.

Mô hình đầu tiên chạy một tìm kiếm hợp lệ cho một phiên bản như một phần của việc thu thập bằng chứng cho việc so sánh, đó là một hành vi tốt để bắt chước.

Tuy nhiên, lệnh gọi thực thi mã tiếp theo xử lý nhầm danh sách đó như một từ điển. Công cụ mã trả về TypeError: list indices must be integers or slices, not str. Vì kiểu trả về đã được ghi lại tài liệu trước lệnh gọi, đây là một lỗi mà mô hình đáng lẽ phải có thể tránh được. Một gợi ý với lệnh gọi đúng có thể được tạo để sửa hành động đó.

Một phiên mã minh họa cho thấy ba vai trò huấn luyện: đầu vào chỉ có ngữ cảnh và đầu ra của công cụ (màu xám), bắt chước CE của các cuộc gọi được ghi lại hữu ích (màu tối) và sửa lỗi KL của một lỗi được đánh dấu (màu mòng két). Ở đây, mô hình xử lý nhầm danh sách kết quả tìm kiếm như một từ điển; một gợi ý chỉ dành cho giáo viên có căn cứ trong tài liệu công cụ trước đó hướng dẫn việc sửa lỗi. Các mục tiêu CE chỉ áp dụng khi phiên hoàn thành được đánh giá là thành công, trong khi một phiên không thành công vẫn có thể cung cấp một mục tiêu sửa lỗi KL đủ điều kiện.

Quá trình huấn luyện hoạt động như thế nào

Đường ống huấn luyện có bốn giai đoạn: chọn phiên và đánh giá kết quả của chúng, xác định lỗi và tạo gợi ý từ phản hồi của người dùng và lỗi công cụ, tạo xác suất token tiếp theo từ cả giáo viên và học sinh, và huấn luyện mô hình với tổn thất CE và KL kết hợp.

Chọn phiên, sau đó đánh giá kết quả

Quy trình lấy mẫu lấy từ một tập con đủ điều kiện huấn luyện của các phiên Computer thực tế được phục vụ bởi GLM 5.2. Các lượt từ chối tham gia huấn luyện và các բացառ loại liên quan đến PII của quy trình được áp dụng trước khi chọn các ví dụ cho quy trình làm việc này.

Quy trình sàng lọc ban đầu chọn các ứng cử viên được đánh giá là 4 hoặc 5 trên thang độ khó tác vụ năm điểm bởi trọng tài LLM và chia chúng thành 2 nhóm:

  • Nhóm phản hồi của người dùng chứa các phiên có phản hồi thực sự của người dùng hoặc cờ bất mãn trung bình đến cao. Chúng tôi thấy các phản hồi có ý định cao này đặc biệt hữu ích cho việc học tập: người dùng đang tích cực cố gắng hoàn thành một tác vụ và các bản sửa lỗi của họ chỉ ra chính xác những gì mô hình đã bỏ lỡ.
  • Nhóm lỗi công cụ chứa các phiên có lệnh gọi thất bại được gắn cờ bằng các kiểm tra dựa trên quy tắc, loại trừ các sự cố cơ sở hạ tầng được công nhận và ủy quyền bị từ chối.

Hai trọng tài LLM sau đó đánh giá kết quả giao cuối cùng dựa trên yêu cầu của người dùng; cả hai trọng tài phải đưa ra phán quyết tích cực để gắn nhãn phiên là "thành công". Đối với các trường hợp tạo ra tạo phẩm, giai đoạn kết quả có thể tái tạo và kiểm tra phần giao, chuyển sang các phán quyết dựa trên văn bản nếu giai đoạn đó thất bại. Các phiên được phân loại là chưa hoàn chỉnh, chẳng hạn như công việc đang chờ người dùng, sẽ bị loại trừ.

Bước này xác định các nguồn tiềm năng của tín hiệu huấn luyện; tuy nhiên, không phải mọi lỗi đều có thể quy cho mô hình, vì một số phát sinh từ hướng dẫn mơ hồ hoặc sự cố cơ sở hạ tầng. Chú thích sau đó xác định những sai lầm ứng cử viên nào thực sự có thể tránh được và phù hợp để huấn luyện.

Tìm lỗi từ phản hồi của người dùng

Hãy xem xét một phiên mẫu trong nhóm phản hồi của người dùng, nơi người dùng hỏi, "How do I find my w3 on paychex". Mô hình coi "w3" là lỗi đánh máy của W-2, tìm kiếm hướng dẫn về W-2 và giải thích cách tìm biểu mẫu đó. Câu hỏi tiếp theo của người dùng, "I meant the W-3 transmittal form," xác định lỗi, ngay cả khi phiên đó cuối cùng thành công.

Lời phàn nàn giúp định vị lỗi, nhưng nguyên nhân gốc rễ là quyết định trước đó diễn giải lại “w3” thành W-2. Yêu cầu ban đầu làm cho lỗi có thể tránh được: mô hình có thể đã bảo lưu W-3 hoặc yêu cầu làm rõ. Hóa ra lượt trợ lý cuối cùng trước lời phàn nàn chỉ là nguyên nhân gốc rễ trong khoảng một nửa thời gian.

Đường ống chú thích của chúng tôi ánh xạ nguyên nhân và kết quả một cách có hệ thống trong mỗi phiên phản hồi của người dùng. Người chú thích trước tiên lọc tìm kiếm một yêu cầu bị bỏ lỡ hoặc một ý định được hỗ trợ bởi ngữ cảnh trước đó. Ba trọng tài LLM sau đó xác định các lượt chịu trách nhiệm, yêu cầu ít nhất hai trọng tài đồng ý về một lượt nhất định. đôi khi một tuyên bố trước đó thiết lập rõ ràng yêu cầu. Trong các trường hợp khác, không có tuyên bố trước đơn lẻ nào làm như vậy, nhưng nhiều phần của cuộc trò chuyện trước đó cùng nhau làm cho hành vi dự định có thể suy ra được. Thiết kế này cho phép họ kết nối một lời phàn nàn với một lỗi gốc trước đó thay vì chỉ quy cho câu trả lời cuối cùng.

Trước khi chấp nhận gợi ý, đường ống cũng kiểm tra xem các tuyên bố khắc phục của nó có tuân theo thông tin có sẵn trước lượt được đánh dấu hay không. Các kiểm tra này nhằm mục đích giảm độ lệch nhận thức muộn, trong đó một sở thích mới được tiết lộ trong lời phàn nàn được coi là điều mà mô hình đáng lẽ phải biết.

Trong ví dụ này, gợi ý bảo mô hình tìm kiếm biểu mẫu truyền tải W-3 trên Paychex thay vì W-2, hoặc hỏi xem người dùng có ý định biểu mẫu nào nếu yêu cầu mơ hồ. Bản sửa lỗi nhắm mục tiêu vào việc giải thích trước đó và quyết định tìm kiếm, không chỉ câu trả lời cuối cùng. Lượt gốc vẫn không thay đổi; chú thích thêm is_bad_turn: true và một gợi ý không rỗng.

Một phiên thực tế cho thấy cách một lời phàn nàn được truy nguyên về một lỗi trước đó, với quy trình chú thích được phủ lên. Người dùng yêu cầu "w3" trên Paychex, nhưng mô hình coi đó là lỗi đánh máy cho W-2 và tìm kiếm biểu mẫu sai. Sự đồng thuận của người đề xuất xác định nguyên nhân gốc rễ, trong khi hai bước kiểm tra có căn cứ đánh giá xem bằng chứng có trước lỗi hay không và các tuyên bố của gợi ý có tuân theo thông tin có sẵn tại thời điểm đó hay không. Các chú thích được chấp nhận giữ nguyên văn bản gốc và thêm các dấu và gợi ý, thay vì các mục tiêu được viết lại.

Tìm lỗi từ lỗi công cụ

Hãy xem xét một phiên khác trong nhóm lỗi công cụ với một lệnh gọi tìm kiếm trong đó tác nhân tìm kiếm với recency_filter: "year", nhưng công cụ từ chối nó vì các giá trị được phép là “day,” “week,” hoặc “month”. Đây là một vi phạm lược đồ rõ ràng.

Đường dẫn lỗi công cụ sử dụng các quy tắc tất định cho các lỗi đã biết và phán quyết của mô hình cho các trường hợp mơ hồ. Chỉ riêng thông báo lỗi cũng không đủ để đổ lỗi cho mô hình; một bản sửa lỗi được đánh giá phải chỉ ra điều gì đó mà mô hình có thể biết được từ lược đồ công cụ, hướng dẫn hệ thống hoặc cuộc trò chuyện trước đó.

Đối số tìm kiếm không hợp lệ của báo cáo minh họa quy trình lỗi công cụ hiện tại. Lược đồ làm cho lỗi này có thể tránh được; một mình sự cố ngừng hoạt động thì không. Lệnh gọi ban đầu được giữ lại trong bản ghi và nhận được một gợi ý có căn cứ. Gợi ý cho phép một giá trị được liệt kê hoặc bỏ qua nếu trường là tùy chọn; nó không yêu cầu "month" cho mọi yêu cầu.

Ở đây, gợi ý đặt tên cho lệnh gọi thất bại, bao gồm lỗi xác thực và hướng dẫn mô hình sử dụng giá trị được phép hoặc bỏ qua trường nếu nó là tùy chọn.

Hai lượt truyền chuyển tiếp

Sau khi một lượt tương tác được đánh dấu, trình huấn luyện sẽ chạy cùng một điểm kiểm tra hai lần: một lần với tư cách là giáo viên và một lần với tư cách là học sinh. Giáo viên nhìn thấy gợi ý; học sinh thì không.

Cả hai lượt truyền đều sử dụng kỹ thuật ép buộc giáo viên, trong đó chúng tôi cung cấp cho mô hình phiên được ghi lại thay vì để nó chọn token mới. Lượt truyền chuyển tiếp vẫn tạo ra phân phối token tiếp theo đầy đủ ở mỗi bước, nhưng nó luôn được điều kiện hóa theo tiền tố cố định từ bản ghi, không phải trên các token triển khai.

Đối với ví dụ tìm kiếm, cùng một mô hình gán xác suất cao hơn nhiều cho "month" và thấp hơn cho "year" khi nhận được gợi ý. Quá trình huấn luyện sử dụng sự dịch chuyển phân phối này làm mục tiêu mềm.

Hai lượt truyền, một tập hợp trọng số. Cả hai lượt truyền đều chấm điểm phần tiếp theo được ghi lại; chỉ có giáo viên nhận được gợi ý. Xác suất token tiếp theo được tách rời của nó hướng dẫn học sinh thông qua KL chuyển tiếp. Các mục tiêu CE riêng biệt neo việc bắt chước. Cả hai hàm mất mát đều cung cấp cho một bản cập nhật trọng số. Các gợi ý trước đó có thể vẫn còn trong phân đoạn hiện tại của giáo viên; không có lượt truyền nào tạo ra câu trả lời huấn luyện thay thế.

Các dự đoán của giáo viên được tách rời hoặc dừng gradient: chúng cung cấp mục tiêu nhưng không nhận được bản cập nhật thông qua lượt truyền của giáo viên. Sau lượt truyền của học sinh, một bước tối ưu hóa sẽ cập nhật mô hình được chia sẻ.

Hàm mất mát

Tổn thất CE

Hỗn thất CE coi các token được ghi lại được chọn để bắt chước là các mục tiêu sự thật mặt đất và phạt mô hình vì đã gán cho chúng xác suất thấp. Điều này tạo ra một mục tiêu bắt chước cứng.

Ở vị trí token ii, gọi pi(v)p_i(v) là xác suất token vv của học sinh trong toàn bộ từ vựng VV. Token tiếp theo được ghi lại trong phản hồi hoặc lệnh gọi công cụ là yiy_i, phân phối mục tiêu one-hot là rir_i.

ri(v)=1[v=yi]r_i(v)=\mathbf{1}[v=y_i]

Độ lệch chéo đo lường mức độ học sinh dự đoán token được ghi lại đó. Với mục tiêu one-hot, nó rút gọn thành log-xác suất âm được gán cho yiy_i.

H(ri,pi)=−∑v∈Vri(v)log⁡pi(v)=−log⁡pi(yi)H(r_i,p_i)=-\sum_{v\in V}r_i(v)\log p_i(v)=-\log p_i(y_i)

Mặt nạ CE miCEm_i^{\mathrm{CE}} là 11 ở nơi token nên được bắt chước và 00 ở các nơi khác. Tổng hợp trên các vị trí được chọn sẽ cho ra tổn thất bắt chước.

LCE=∑imiCEH(ri,pi)\mathcal{L}_{\mathrm{CE}}=\sum_i m_i^{\mathrm{CE}}H(r_i,p_i)

Hàm mất mát KL

Thay vào đó, hàm mất mát KL sử dụng toàn bộ phân phối xác suất token tiếp theo của giáo viên qiq_i làm mục tiêu hiệu chỉnh mềm. Ngữ cảnh của giáo viên bao gồm gợi ý hiện tại và bất kỳ gợi ý nào trước đó được giữ lại trong phân đoạn huấn luyện đó; ngữ cảnh của học sinh luôn không có gợi ý.

Mặt nạ KL miKLm_i^{\mathrm{KL}} là 11 ở nơi token nên được sửa và 00 ở các nơi khác; mặt nạ CE và KL không chồng chéo. Ở các vị trí này, KL chuyển tiếp phạt sự bất đồng giữa giáo viên và học sinh trên toàn bộ từ vựng:

LKL=∑imiKLDKL(qi∥pi)=∑imiKL∑v∈Vqi(v)log⁡qi(v)pi(v)\mathcal{L}_{\mathrm{KL}}=\sum_i m_i^{\mathrm{KL}}D_{\mathrm{KL}}(q_i\Vert p_i)=\sum_i m_i^{\mathrm{KL}}\sum_{v\in V}q_i(v)\log\frac{q_i(v)}{p_i(v)}

Hàm mất mát kết hợp

Cả hai thuật ngữ đều chia sẻ một mẫu số thay vì được chuẩn hóa riêng biệt. Mẫu số này đếm tổng số token được chọn để bắt chước trên toàn bộ lô huấn luyện toàn cục. Trọng số λ\lambda kiểm soát đóng góp của việc huấn luyện khắc phục tương نسبت với việc bắt chước.

Việc chuẩn hóa được chia sẻ này phù hợp với giao diện mẫu số đơn của cơ sở hạ tầng huấn luyện của chúng tôi và khôi phục tổn thất SFT tiêu chuẩn khi λ=0\lambda=0, đơn giản hóa các so sánh cơ sở. Do các token CE phong phú hơn nhiều so với các token KL, việc sử dụng mẫu số chung cũng tránh việc gán trọng số lớn bất thường cho các token KL riêng lẻ trong các lô có ít token được đánh dấu.

L=LCE+λLKL∑imiCE\mathcal{L}=\frac{\mathcal{L}_{\mathrm{CE}}+\lambda\mathcal{L}_{\mathrm{KL}}}{\sum_i m_i^{\mathrm{CE}}}

Áp dụng cho các ví dụ trước, các lượt chứa sự nhầm lẫn W-3/W-2 và lệnh gọi tìm kiếm không hợp lệ nhận được KL. Nội dung trợ lý chưa đánh dấu khác trong một phiên thành công vẫn nhận được CE. Nội dung trợ lý khác trong một phiên không thành công được giữ lại làm ngữ cảnh nhưng không nhận được CE cũng như KL.

Các đánh giá cho thấy gì

Các đánh giá của chúng tôi trả lời hai câu hỏi riêng biệt. Đầu tiên, gợi ý có thực sự giúp mô hình sửa lỗi khi có gợi ý không? Thứ hai, việc huấn luyện có giúp mô hình tránh được lỗi đó sau này mà không cần gợi ý không? Phần đầu tiên kiểm tra xem các gợi ý có cung cấp tín hiệu huấn luyện hữu ích hay không. Phần thứ hai kiểm tra xem mô hình có học hỏi từ chúng hay không.

Gợi ý có thể hướng mô hình tránh xa các sai lầm

Chúng tôi kiểm tra câu hỏi đầu tiên trước khi chạy huấn luyện để đảm bảo rằng các gợi ý thực sự có thể hướng mô hình tránh xa các lỗi.

Phản hồi của người dùng

Chúng tôi đã tạo lại các lượt phản hồi của người dùng được đánh dấu có và không có gợi ý, sử dụng cùng một mô hình cơ sở GLM-5.2 ở nhiệt độ bằng không. Một trọng tài mù nhìn thấy lời phàn nàn sau, nhưng không thấy gợi ý cũng như điều kiện nào đã tạo ra câu trả lời.

Trong ví dụ W-3, gợi ý chuyển xác suất token tiếp theo về phía "3" và cách xa "2" sau tiền tố "W-".

Gợi ý bảo lưu biểu mẫu W-3 được yêu cầu. Các thanh hiển thị xác suất token tiếp theo trung bình qua tám lượt truyền chuyển tiếp; các râu biểu đồ hiển thị phạm vi quan sát được, không phải khoảng tin cậy. Cả hai điều kiện đều sử dụng mô hình cơ sở không đổi.

Trên một mẫu giữ lại lớn hơn 40 lượt được hỗ trợ bởi bằng chứng trước đó được nêu rõ ràng, tỷ lệ được đánh giá là đã sửa hoặc đúng hướng tăng từ 40.0% không có gợi ý lên 75.0% có gợi ý. Trên 40 lượt khác được hỗ trợ bởi ý định được suy ra, tỷ lệ này tăng từ 32.5% lên 80.0%.

Xác thực gợi ý, không phải đánh giá hậu huấn luyện. 40 lượt được đánh dấu tương tự trong mỗi nhóm bằng chứng được tạo lại có và không có gợi ý bằng cách sử dụng GLM-5.2 không đổi ở nhiệt độ bằng không. Trọng tài thấy lời phàn nàn nhưng không thấy gợi ý hoặc điều kiện. Số lượng được lấy từ tỷ lệ và quy mô mẫu của báo cáo; khoảng tin cậy không được báo cáo.

Lỗi công cụ

Trong ví dụ về lỗi công cụ tìm kiếm, gợi ý thực sự chuyển khối lượng xác suất từ token year sang token month.

Gợi ý chuyển xác suất về phía giá trị được phép. Các thanh hiển thị xác suất token tiếp theo trung bình qua tám lượt truyền chuyển tiếp; các râu biểu đồ hiển thị phạm vi quan sát được, không phải khoảng tin cậy. Cả hai điều kiện đều sử dụng cùng một mô hình cơ sở; không có điểm kiểm tra đã được huấn luyện nào được so sánh.

Trên mẫu 985 lượt giữ lại lớn hơn, chúng tôi tạo lại mỗi lượt bốn lần có và không có gợi ý bằng cách sử dụng cùng một mô hình cơ sở. Một trọng tài mù đánh giá xem mỗi lần tạo lại có tránh được lỗi ban đầu hay không. Các gợi ý làm tăng khả năng tránh lỗi từ 75.1% lên 93.7%, mức tăng theo cặp là 18.6 điểm phần trăm và làm tăng tỷ lệ thực hiện hành động đã sửa từ 60.6% lên 82.3%. Mức tăng lớn nhất đối với các lỗi mà chỉ việc lấy mẫu lặp lại khó có thể khắc phục.

Xác thực gợi ý lỗi công cụ trên 985 lượt được đánh dấu giữ lại, với bốn lần tạo lại cho mỗi điều kiện. Các thanh hiển thị tỷ lệ tránh lỗi và hành động được sửa cho mô hình cơ sở không đổi, có và không có gợi ý. Việc tránh sai lầm được nhắm mục tiêu không thiết lập được lệnh gọi công cụ hoặc thành công tác vụ.

Độ tin cậy của công cụ và phản hồi của người dùng sau khi đào tạo

Tiếp theo, chúng tôi kiểm tra xem mô hình đã huấn luyện có mắc ít lỗi hơn mà không nhận được gợi ý hay không. Chúng tôi đánh giá mô hình gốc và các checkpoint sau huấn luyện khác nhau trên các tác vụ benchmark ngoại tuyến và trong các phiên người dùng trực tiếp, đồng thời kiểm tra xem có ít lỗi công cụ hơn và mức độ không hài lòng của người dùng thấp hơn hay không.

Đánh giá ngoại tuyến

Đánh giá ngoại tuyến sử dụng BrowseComp, Finch, WideSearch, DRACO, DSQA, SpreadsheetBench, HLE, một tập hợp tác vụ Computer đại diện, đồng thời kiểm tra việc tải Skill, xem xét tài liệu và trích dẫn nội tuyến. Chúng tôi đo lường tỷ lệ các lệnh gọi công cụ có kết quả được gắn cờ rõ ràng là lỗi trên các quỹ đạo đánh giá.

Trong các đánh giá này, tỷ lệ lỗi công cụ được ghi lại là 2.79% đối với GLM 5.2 gốc, 1.35% đối với điểm kiểm tra chỉ RFT và 0.87% đối với điểm kiểm tra RFT cộng với OPSD. Các điểm kiểm tra này được huấn luyện trên dữ liệu khác nhau, vì vậy đây không phải là phép cắt bỏ dữ liệu khớp của OPSD. Kết quả điểm chuẩn cấp độ tác vụ hỗn hợp, vì vậy ít lỗi công cụ hơn không nhất thiết chuyển thành cải thiện rộng rãi trong sự thành công của tác vụ.

Tỷ lệ lỗi công cụ ngoại tuyến cho các điểm kiểm tra GLM-5.2 gốc, chỉ RFT và RFT-cộng-OPSD. Dữ liệu huấn luyện khác nhau giữa các điểm kiểm tra; đây không phải là phép cắt bỏ dữ liệu có đối chứng.

Đánh giá trực tuyến: GLM-5.2

Đối với GLM-5.2, chúng tôi đã chạy hai thử nghiệm A/B riêng biệt với khoảng một trăm nghìn người dùng trong mỗi điều kiện. Ở thử nghiệm đầu tiên, điểm kiểm tra RFT-kết hợp-OPSD ban đầu có tỷ lệ lỗi công cụ thấp hơn một chút so với GLM 5.2 gốc, 2,82% so với 2,94%, nhưng sự khác biệt không có ý nghĩa thống kê.

Trong thử nghiệm sau đó, chúng tôi đã so sánh hai điểm kiểm tra RFT-plus-OPSD: điểm kiểm tra trước đó (điểm kiểm tra một) và điểm kiểm tra sau đó (điểm kiểm tra hai). Lỗi lệnh gọi công cụ giảm từ 2.24% xuống 1.77% số lệnh gọi có trạng thái được ghi lại. Đây là mức giảm tương đối 21.2% có ý nghĩa thống kê. Chúng tôi không so sánh trực tiếp điểm kiểm tra hai với GLM 5.2 gốc trực tuyến.

Kết quả phản hồi của người dùng ít mang tính kết luận hơn. Trong thí nghiệm GLM-5.2 thứ hai, xác suất trung bình của sự không hài lòng mạnh (trung bình hoặc cao) là 2,58% đối với điểm kiểm tra thứ nhất và 2,54% đối với điểm kiểm tra thứ hai, không có sự khác biệt có ý nghĩa thống kê.

Hai thử nghiệm A/B trực tiếp GLM-5.2 riêng biệt. Điểm kiểm tra 1 được so sánh với GLM-5.2 gốc; điểm kiểm tra 2 được so sánh với điểm kiểm tra 1. Trong hai thử nghiệm này, chỉ có việc giảm lỗi công cụ ở giai đoạn sau là có ý nghĩa thống kê. Tỷ lệ MID+ tính toán các xác suất trung bình của mức độ không hài lòng trung bình hoặc cao, chứ không phải số lượng khiếu nại.

Đánh giá trực tuyến: GLM-5.3

Đối với GLM-5.3, chúng tôi đã so sánh trực tiếp một điểm kiểm tra được đào tạo sau với GLM-5.3 gốc. Tỷ lệ gọi công cụ thất bại giảm từ 3,56% xuống 2,38% số cuộc gọi có trạng thái được ghi lại, tương ứng với mức giảm tương đối 33,04%. Tỷ lệ MID+, xác suất ước tính trung bình về mức độ không hài lòng từ trung bình đến cao, giảm từ 4,12% xuống 3,41%, tương ứng với mức giảm tương đối 17,2%. Cả hai mức giảm đều có ý nghĩa thống kê.

GLM-5.3 đã được đào tạo sau so với GLM-5.3 gốc trong một thử nghiệm A/B trực tuyến riêng biệt. Tỷ lệ lỗi công cụ và MID+, các thay đổi tương đối, và khoảng tin cậy tuần tự 95% sử dụng phương pháp điều chỉnh CUPED. Cả hai mức giảm đều có ý nghĩa thống kê. Tỷ lệ MID+ là xác suất ước tính trung bình về mức độ không hài lòng từ trung bình đến cao trên các chuỗi tiếp theo đủ điều kiện được tính điểm, không phải số lượng khiếu nại. Tỷ lệ lỗi công cụ không tính các cuộc gọi không có trạng thái thành công hoặc thất bại được ghi lại.

Kết luận

Ý tưởng cốt lõi là học ở cấp độ quyết định chứ không chỉ phiên.

Kết quả thành công có thể che giấu lỗi, và một phiên không thành công vẫn có thể tiết lộ cách cải thiện. Chúng tôi giữ lại hành vi hữu ích từ các phiên thành công làm mốc neo, sử dụng các phàn nàn và lỗi công cụ để xác định các thất bại có thể tránh được, và huấn luyện mô hình hướng tới các dự đoán mà nó tạo ra khi những sai lầm và bản sửa lỗi đó được làm rõ. Thành công cung cấp hành vi để bảo tồn; thất bại cung cấp định hướng để cải thiện.

Việc sử dụng trong thế giới thực làm cho phương pháp này đặc biệt hữu ích. Người dùng thực mang theo các mục tiêu, ràng buộc và quy trình làm việc khó lường trước trong một môi trường tổng hợp. Các bản sửa lỗi của họ tiết lộ các yêu cầu mà mô hình đã bỏ lỡ, trong khi lỗi công cụ phơi bày khoảng cách giữa những gì mô hình đã cố gắng và những gì môi trường cho phép. Các tín hiệu này bổ sung cho việc huấn luyện dựa trên kết quả: thay vì chỉ hỏi liệu một tác vụ có thành công hay không, chúng ta có thể hỏi mô hình đã sai ở đâu và thông tin nào có thể giúp nó đưa ra quyết định tốt hơn.

Các giới hạn cũng quan trọng không kém. Người đánh giá có thể sai, và việc sửa một lượt tương tác không đảm bảo rằng toàn bộ tác vụ sẽ thành công. Mục tiêu không chỉ đơn thuần là một tác nhân có thể phục hồi sau khi được chỉnh sửa. Đó là một tác nhân ít cần chỉnh sửa hơn.

Trích dẫn

BibTeX
@online{perplexity2026LearningFromRealWorldExperience,
  author = {{Perplexity} and Senzeyu Zhang and Chuan Wang and Hang Wu and Hao Zhang and Yuan Liang and Yunfan Zhong and Phi Hoang and Claire Beamer and Jeremy Yang and Andrew Wilson and Denis Yarats},
  title = {{Learning from real-world experience}},
  date = {2026-09-21},
  url = {https://www.perplexity.ai/hub/blog/learning-from-real-world-experience}
}