Perplexity Decider

Cách chúng tôi huấn luyện, đánh giá và sử dụng nó.

Tác giảPerplexity Research

Chúng tôi phát hành Decider v1.3 và Decider Flash v1.3, phiên bản kế nhiệm của các mô hình quyết định trước đây: v1, v1.1, v1.2 và Flash v1.2.

Decider Flash v1.3 là một mô hình nhỏ hơn được chưng cất từ Decider v1.3. Cả hai mô hình đều có sẵn trên Hugging Face theo giấy phép Apache, qua OpenRouter và Perplexity Decisions API.

Perplexity Decider được lấy cảm hứng từ Jev, System One Model của TypeSafe AI. Mô hình hỗ trợ phân loại nhị phân và đa lớp với nhãn có thứ tự hoặc không có thứ tự, trả về các xác suất mà ứng dụng có thể dùng để phân loại, định tuyến, xếp hạng và đánh giá đầu vào.

Cả hai mô hình v1.3 đều cải thiện hiệu suất và độ bền vững trên nhiều tác vụ văn bản và thị giác nhờ attention hai chiều, dữ liệu huấn luyện được tuyển chọn kỹ hơn và quy trình huấn luyện được tinh chỉnh. Chúng tôi cũng giới thiệu locate, một tính năng mới giúp làm nổi bật nội dung được chọn cho các tác vụ nhận dạng thực thể có tên, nhận diện thông tin cá nhân và hỏi đáp trích xuất.

Trong bài viết này, chúng tôi giải thích cách huấn luyện và đánh giá Decider, đồng thời chia sẻ cách chúng tôi sử dụng mô hình này trong nội bộ tại Perplexity.

Mô hình quyết định là gì?

Mô hình quyết định là một bộ phân loại đa dụng. Bạn cung cấp cho mô hình một đầu vào và một tập hợp câu hỏi, mỗi câu hỏi kèm các câu trả lời khả dĩ. Với mỗi câu hỏi, mô hình trả về một phân phối xác suất trên các câu trả lời. Mô hình hỗ trợ 3 loại câu hỏi:

  • Có / Không: quyết định nhị phân.
  • Trắc nghiệm: nhãn đa lớp tùy chỉnh.
  • Điểm số: các mức có thứ tự.

Mô hình quyết định hỗ trợ nhiều loại tác vụ phân loại và chấm điểm:

  • Đánh giá đầu ra: đánh giá độ trung thực, chất lượng và độ an toàn.
  • Định tuyến: chuyển yêu cầu đến mô hình nhỏ hơn hoặc lớn hơn dựa trên độ khó.
  • Kiểm duyệt và bảo mật: phát hiện nội dung độc hại, lừa đảo phishing và prompt injection trong đầu ra của công cụ.
  • Lọc và gắn thẻ: sắp xếp các bộ sưu tập nội dung lớn.
  • Truy xuất và xếp hạng lại: chấm điểm kết quả tìm kiếm theo mức độ liên quan.

Nhiều tác vụ trong số này trước đây được xử lý bằng các mô hình tạo sinh như LLM, dù chúng không đòi hỏi tạo văn bản dạng tự do. Mô hình quyết định nằm giữa LLM và các bộ phân loại chuyên biệt cho từng tác vụ. Chúng trả về xác suất cho nhiều câu hỏi về cùng một đầu vào trong một lượt truyền xuôi duy nhất, nhờ đó tránh việc tạo câu trả lời theo từng token và chia sẻ phép tính giữa các câu hỏi. Khác với các bộ phân loại chuyên biệt cho từng tác vụ, chúng có thể xử lý tác vụ mới thông qua prompt bằng ngôn ngữ tự nhiên, một sự linh hoạt có được nhờ huấn luyện trên nhiều tác vụ đa dạng theo một định dạng hỏi–đáp chung.

Huấn luyện

Biến một LLM sinh thành mô hình quyết định

Chúng tôi xây dựng Decider bằng cách điều chỉnh các mô hình nền LLM tạo sinh mạnh mẽ. Để giải thích quá trình điều chỉnh này, trước tiên chúng tôi mô tả cách biểu diễn một yêu cầu. Như minh họa bên dưới, một yêu cầu bao gồm một ngữ cảnh dùng chung (trạng thái) và một số câu hỏi. Trạng thái sẽ được tái sử dụng cho tất cả các câu hỏi.

Ví dụ, với một tài liệu và bản tóm tắt của nó, một yêu cầu duy nhất có thể hỏi liệu bản tóm tắt có phản ánh trung thực tài liệu không và liệu bản tóm tắt dành cho chuyên gia hay cho đại chúng. Sau trạng thái, mỗi khối câu hỏi chứa một câu hỏi và các câu trả lời khả dĩ, mỗi câu trả lời được gán một token nhãn định sẵn như A, B hoặc C. Một token đặc biệt <|marker|> cho biết vị trí đọc ra dự đoán của mô hình. Tại vị trí này, một lớp đầu ra tuyến tính đã học (decision head) ánh xạ trạng thái ẩn thành điểm số cho các tùy chọn trả lời của câu hỏi, sau đó các điểm số này được chuyển thành xác suất.

Chúng tôi khởi tạo lớp đầu ra từ mô hình gốc, vốn thường chấm điểm token tiếp theo trên toàn bộ từ vựng, và chỉ giữ lại các hàng tương ứng với những token tùy chọn định sẵn như A, B hoặc C. Lớp đã được cắt tỉa này sau đó được huấn luyện để chuyển trạng thái ẩn của <|marker|> thành điểm số câu trả lời. Cách tiếp cận này áp dụng được cho mọi câu hỏi phân loại vì tất cả đều có thể được diễn đạt dưới dạng trắc nghiệm.

Để huấn luyện, chúng tôi lấy hàng trăm bộ dữ liệu công khai bao quát nhiều tác vụ đa dạng (cảm xúc, suy luận ngôn ngữ tự nhiên, nhận diện ý định, đối sánh thực thể, kiểm duyệt, kiểm chứng thông tin, chấm điểm xếp hạng, v.v.) và chuyển đổi từng ví dụ sang định dạng thống nhất được mô tả ở trên: một trạng thái, một hoặc nhiều câu hỏi, các tùy chọn của chúng và một mục tiêu. Mục tiêu có thể là tùy chọn đúng duy nhất nếu chúng tôi có nhãn chuẩn, hoặc một phân phối xác suất trên các tùy chọn.

Trong v1.3, chúng tôi giới thiệu locate, tính năng trích xuất văn bản từ trạng thái thay vì chọn từ các tùy chọn định sẵn. Một câu hỏi locate mô tả nội dung cần tìm, bằng một nhãn ngắn như “vị trí” hoặc một chỉ dẫn như “Trích xuất tên thành phố nơi có công việc.” Mô hình trả về đoạn văn bản khớp chính xác từ trạng thái, cùng với vị trí ký tự bắt đầu và kết thúc của đoạn đó. Nếu không tìm thấy kết quả khớp nào, mô hình trả về một danh sách rỗng.

Nhờ trạng thái dùng chung, một yêu cầu duy nhất có thể kết hợp các câu hỏi locate, phân loại và chấm điểm về cùng một đầu vào. Ví dụ, yêu cầu có thể hỏi liệu một công việc có đòi hỏi kinh nghiệm cấp cao không và trích xuất các kỹ năng cần thiết.

Attention hai chiều: cho phép mô hình đọc theo cả hai hướng

Các mô hình của chúng tôi bắt đầu từ những backbone sinh mạnh đã được tiền huấn luyện, với causal attention chỉ cho phép mỗi token chú ý đến chính nó và các token đứng trước. Các thử nghiệm ablation của chúng tôi cho thấy việc chuyển các lớp full attention của backbone sang hai chiều giúp cải thiện hiệu suất, vì vậy chúng tôi áp dụng thiết kế này để mỗi token có thể kết hợp ngữ cảnh từ toàn bộ đầu vào.

Attention hai chiều đặt ra một lựa chọn thiết kế khác: trạng thái và câu hỏi nên tương tác với nhau như thế nào? Chúng tôi đã cân nhắc ba mẫu attention, mỗi mẫu có tác động khác nhau đến hiệu suất, độ ổn định của câu trả lời và khả năng tái sử dụng bộ nhớ đệm:

  • Mọi thứ thấy mọi thứ (v1.2): Trạng thái và tất cả câu hỏi được xử lý cùng nhau với attention hai chiều đầy đủ. Phép tính trên trạng thái được dùng chung, nhưng câu trả lời cho một câu hỏi có thể thay đổi tùy thuộc vào những câu hỏi khác được hỏi cùng.
  • Câu hỏi tách biệt (v1.3): Trạng thái chú ý đến tất cả các câu hỏi, trong khi mỗi câu hỏi chỉ chú ý đến trạng thái và các token của chính nó. Các câu hỏi vẫn có thể ảnh hưởng gián tiếp lẫn nhau thông qua trạng thái dùng chung nhưng kết quả ổn định hơn.
  • Hoàn toàn có thể lưu vào bộ nhớ đệm: Trạng thái chỉ chú ý đến chính nó, trong khi mỗi câu hỏi chú ý đến trạng thái và các token của riêng câu hỏi đó. Trạng thái không phụ thuộc vào câu hỏi và có thể tái sử dụng giữa các yêu cầu để tận dụng cơ chế lưu prompt vào bộ nhớ đệm. Chúng tôi không dùng chế độ này theo mặc định, vì việc cho trạng thái nhìn thấy các câu hỏi rất quan trọng đối với nhiều tác vụ, nhưng chỉ cần tinh chỉnh nhẹ là có thể chuyển một mô hình sang chế độ này.

Cuối cùng, chúng tôi chọn câu hỏi tách biệt nhờ hiệu suất và độ ổn định vượt trội.

Quy trình huấn luyện

Quá trình huấn luyện diễn ra qua ba giai đoạn cho cả hai kích thước mô hình. Trước tiên, chúng tôi huấn luyện mô hình lớn hơn, dựa trên Qwen3.8-27B, bằng cross-entropy trên các tập dữ liệu lớn, sau đó chưng cất nó thành mô hình Qwen3.5-4B nhỏ hơn.

Giai đoạn đầu tiên là huấn luyện tổng quát, trong đó chúng tôi tinh chỉnh toàn bộ mô hình trên các kho ngữ liệu quy mô lớn. Ở giai đoạn này, chúng tôi chỉ chấp nhận dữ liệu giúp ích cho mô hình trên mọi phương diện và không dành riêng cho bất kỳ benchmark nào; do đó, chúng tôi loại trừ mọi tập huấn luyện của benchmark.

Sau khi huấn luyện xong mô hình tổng quát này, chúng tôi thực hiện giai đoạn thứ hai, chi tiết hơn, bằng LoRA. Dữ liệu dùng trong giai đoạn này nhắm vào các lĩnh vực và tác vụ cụ thể. Chúng tôi bổ sung dữ liệu ở giai đoạn thứ hai thay vì giai đoạn đầu nếu nhận thấy mức cải thiện chỉ trong phạm vi hẹp hoặc thấy có sự suy giảm trên các tác vụ khác. Chúng tôi dùng LoRA để tránh việc mô hình lệch quá xa khỏi mô hình tổng quát và có nguy cơ giảm hiệu năng khi cố khớp với những lĩnh vực cụ thể đó. Mục tiêu là cải thiện hiệu năng trong khi vẫn giữ được kiến thức tổng quát của mô hình nền (backbone). Chúng tôi cũng sử dụng một trọng số khi hợp nhất LoRA trở lại mô hình cơ sở để kiểm soát độ lệch chính xác hơn và ưu tiên các chỉ số trên dữ liệu held-out hơn mọi mức cải thiện trong miền.

Cuối cùng, chúng tôi bổ sung một bước dành riêng cho thị giác. Tương tự giai đoạn thứ hai, bước thị giác được xem như một bước chuyên biệt hóa chi tiết khác, sử dụng adapter LoRA được hợp nhất trở lại vào mô hình gốc với một trọng số. Một số khả năng thị giác có thể phải đánh đổi bằng hiệu suất văn bản. Vì chúng tôi nhận thấy các mô hình được sử dụng cho văn bản nhiều hơn hẳn, chúng tôi ưu tiên các chỉ số văn bản hơn chỉ số thị giác.

Đối với cả hai giai đoạn văn bản, chúng tôi sử dụng trọng số trung bình từ ba lần chạy, mỗi lần dùng một seed ngẫu nhiên khác nhau. Chúng tôi nhận thấy cách này cải thiện hiệu suất và độ bền vững của mô hình tổng hợp.

Sau khi có được mô hình lớn cuối cùng, chúng tôi áp dụng cùng quy trình huấn luyện ba giai đoạn cho mô hình nhỏ hơn. Ở đây, mô hình lớn đóng vai trò mô hình thầy: phân phối đầu ra dự đoán của nó thay thế cho các nhãn chuẩn (gold label), và mô hình nhỏ hơn được huấn luyện để giảm thiểu độ phân kỳ KL giữa dự đoán của nó và dự đoán của mô hình thầy. Mục tiêu chưng cất này cho kết quả tốt hơn cross-entropy trên cùng dữ liệu huấn luyện. Mặc dù cross-entropy hoạt động tốt hơn trên các benchmark có dữ liệu huấn luyện riêng, nó lại khái quát hóa kém hơn trên dữ liệu held-out. Chúng tôi giả thuyết rằng chưng cất truyền tải tốt hơn phân phối đầu ra của mô hình thầy, bao gồm cả mức độ tin cậy của nó đối với các phương án không phải nhãn chuẩn, trong khi cross-entropy khuyến khích việc quá khớp với phân phối huấn luyện đặc thù của benchmark. Vì vậy, chúng tôi chọn mục tiêu chưng cất dựa trên KL.

Để giảm thiểu tình trạng nhiễm chéo giữa dữ liệu huấn luyện và kiểm thử, chúng tôi loại bỏ mọi mẫu huấn luyện có thể trùng lặp với bất kỳ bộ đánh giá nào chúng tôi sử dụng. Điều này rất quan trọng vì một số tập dữ liệu huấn luyện công khai chứa phần lớn nội dung của một số tập dữ liệu đánh giá. Chúng tôi cũng tiến hành kiểm tra và loại bỏ thiên lệch một cách toàn diện để đảm bảo các cải thiện là đáng tin cậy và không chỉ xuất phát từ những thiên lệch mà mô hình đã học được.

Bổ sung khả năng trích xuất thông tin

Tính năng locate trích xuất thông tin như các thực thể có tên từ văn bản mà không thay đổi cách mô hình trả lời các yêu cầu thông thường. Để làm được điều đó, chúng tôi bổ sung một giai đoạn huấn luyện: thêm vào Decider một token đặc biệt mới, <|locate|>, một span head và adapter LoRA.

Chúng tôi khởi tạo embedding của <|locate|> từ <|marker|> đã học được trong các giai đoạn huấn luyện trước. Chúng tôi chỉ huấn luyện embedding mới này, span head và các adapter LoRA, trong khi giữ nguyên (đóng băng) trọng số backbone gốc và decision head. Mỗi trường được yêu cầu có một token <|locate|> riêng.

Đầu dự đoán span (span head) sử dụng biểu diễn của <|locate|> cùng với biểu diễn của các token trạng thái để chấm điểm vị trí bắt đầu và kết thúc của các span khớp, cũng như những cặp bắt đầu–kết thúc nào đi cùng nhau. Nó cũng sử dụng biểu diễn của token <|locate|> để dự đoán các ngưỡng riêng cho từng trường đối với những điểm số này. Các span được chọn sẽ được trả về dưới dạng vị trí ký tự trong văn bản gốc.

Chúng tôi huấn luyện đầu dự đoán span bằng một hàm mất mát InfoNCE được điều chỉnh, giúp đẩy mọi span chuẩn lên trên ngưỡng và đẩy ngưỡng lên trên mọi span khác. Hàm mất mát gồm hai thành phần: Thành phần thứ nhất đẩy điểm số của các span đúng lên trên ngưỡng và trên các span sai. Thành phần thứ hai đẩy ngưỡng lên trên điểm số của các span sai. Các trường không có câu trả lời chỉ nhận thành phần thứ hai, giúp mô hình học cách trả về danh sách rỗng.

Chúng tôi huấn luyện trên tổ hợp các tác vụ trích xuất đoạn (span), bao gồm nhận dạng thực thể có tên, phát hiện PII và hỏi đáp trích xuất. Chúng tôi thay đổi mô tả trường từ nhãn ngắn đến chỉ dẫn chi tiết để mô hình học cách làm theo yêu cầu thay vì ghi nhớ một tập nhãn cố định.

Locate dạy cho mô hình một tác vụ có cấu trúc khác biệt, và chúng tôi muốn bổ sung tác vụ này mà không làm mất đi những gì mô hình vốn đã làm tốt. Việc hợp nhất các adapter locate vào mô hình nền gây ra một số suy giảm trên các yêu cầu quyết định. Để hạn chế điều này, chúng tôi đang thử nghiệm các hướng như bổ sung thêm dữ liệu phát lại từ các giai đoạn trước và các mục tiêu phụ trợ giúp giữ đầu ra của mô hình trên các yêu cầu quyết định gần với đầu ra của mô hình ban đầu. Tuy nhiên, chúng tôi nhận thấy việc hợp nhất hiện vẫn gây tổn hao, vì vậy chúng tôi giữ các adapter ở trạng thái chưa hợp nhất và chỉ kích hoạt chúng cho các yêu cầu locate.

Đánh giá

Chúng tôi đánh giá Decider v1.3 và Decider Flash v1.3 trên các benchmark bên ngoài từ Hugging Face Decision Index, ClaimBench của Vals AI và Artificial Analysis Decision Index.

Trên các bộ đánh giá này, các mô hình của chúng tôi thể hiện hiệu năng mạnh mẽ. Mặc dù các bảng xếp hạng này có bao gồm những tác vụ được giữ kín, chúng vẫn có thể bị lợi dụng thông qua việc gửi kết quả nhiều lần và tinh chỉnh lặp đi lặp lại dựa trên phản hồi từ bảng xếp hạng. Để bổ sung cho các bảng xếp hạng này, chúng tôi đánh giá các mô hình trên một bộ đánh giá nội bộ kết hợp các tác vụ sản xuất riêng tư với các bài đánh giá held-out lấy từ những tập dữ liệu công khai không phải benchmark. Những đánh giá này cung cấp thêm một bước kiểm tra về khả năng khái quát hóa ngoài các benchmark công khai, giúp chúng tôi phân biệt những cải thiện trên diện rộng với những mức tăng chỉ đặc thù cho các bộ đánh giá quen thuộc.

Trong nội bộ, chúng tôi đã xây dựng một bộ gồm hơn 200 tác vụ trải rộng trên nhiều lĩnh vực và loại tác vụ như phân loại, chấm điểm, xếp hạng lại và trích xuất thực thể. Để đánh giá trung thực hiệu suất thực tế của Decider, mọi đánh giá đều được thực hiện theo cách zero-shot, không tinh chỉnh riêng cho từng tác vụ, giúp chúng tôi thấy rõ cần cải thiện mô hình ở đâu.

Phân loại truy vấn

Tại Perplexity, chúng tôi sử dụng một hệ thống phân loại nhiều đầu (multi-head) để xử lý từng truy vấn của người dùng. Trước tiên, mỗi truy vấn được đưa qua một mô hình embedding đóng vai trò bộ trích xuất đặc trưng. Embedding thu được sau đó được đưa vào nhiều đầu phân loại riêng biệt, bao gồm cả bộ phân loại nhị phân và bộ phân loại đa nhãn. Ví dụ, một đầu phân loại xác định liệu truy vấn của người dùng có nên kích hoạt tìm kiếm trên web hay không.

Trên 63 tác vụ phân loại có tham chiếu được một LLM tiên tiến gán nhãn lại độc lập, Decider v1.3 đạt độ chính xác trung bình 91,6%, vượt các bộ phân loại đang vận hành của chúng tôi 6,54 điểm phần trăm. Decider Flash v1.3 cũng vượt mô hình cơ sở đang vận hành, còn Decider v1.3 vượt Jev 1.14.

Phân loại chuyên biệt theo lĩnh vực

Chúng tôi xây dựng một bộ đánh giá chuyên biệt theo lĩnh vực từ các bộ dữ liệu công khai để đánh giá hiệu suất phân loại của các mô hình quyết định trên bảy lĩnh vực: xác minh nhận định (6 tác vụ), chăm sóc sức khỏe (7), an ninh mạng (8), lập trình (16), chính phủ (7), luật (9) và tài chính (9).

Ví dụ: “đánh giá độ phức tạp thời gian của một chương trình Python”, hoặc “dùng báo cáo tài chính thường niên để xác định liệu tiền mặt không bị hạn chế của một công ty có đủ trang trải nợ gốc đến hạn trong mười hai tháng tới hay không”. Decider v1.3 dẫn đầu trên cả bảy lĩnh vực, vượt Jev 1.14 tới 12,9 điểm phần trăm trong lĩnh vực tài chính và 9,3 điểm trong lĩnh vực luật. Decider Flash v1.3 kém Jev 1.14 ở tài chính, lập trình và luật, và có hiệu suất tương đương ở các lĩnh vực khác.

Truy xuất và xếp hạng lại

Tìm kiếm là cốt lõi của Perplexity. Chúng tôi duy trì một bộ tác vụ truy xuất phong phú để đánh giá hiệu suất xếp hạng lại của các mô hình. Với mỗi tác vụ, trước tiên chúng tôi dùng một nhóm mô hình embedding để truy xuất 50 tài liệu ứng viên hàng đầu từ mỗi kho ngữ liệu. Sau đó, chúng tôi xếp hạng lại các ứng viên này bằng Decider và so sánh hiệu suất của Decider với một mô hình xếp hạng lại cơ sở mạnh là Qwen3-Reranker-8B.

Chúng tôi đánh giá Decider trong thiết lập zero-shot, theo từng điểm (pointwise), dùng mô hình để chấm điểm trực tiếp từng cặp truy vấn–tài liệu một cách độc lập và xếp hạng tài liệu theo mức độ liên quan. Trên 72 tác vụ truy xuất, Decider v1.3 đạt nDCG@10 trung bình 83,99, vượt Qwen3-Reranker-8B 1,81 điểm và Jev 1.14 2,24 điểm.

Trên benchmark BEIR, cả hai mô hình lần lượt vượt Qwen3-Reranker-8B 8,78 và 7,05 điểm nDCG@10. So với Jev 1.14, Decider v1.3 cao hơn 1,33 điểm, trong khi phiên bản Flash thấp hơn 0,4 điểm.

Phân loại đa ngôn ngữ

Để đánh giá các mô hình quyết định ngoài tiếng Anh, chúng tôi xây dựng một benchmark phân loại đa ngôn ngữ gồm 19 tác vụ theo từng ngôn ngữ từ 8 bộ dữ liệu công khai, với 46.484 ví dụ trên tám ngôn ngữ: tiếng Đức, tiếng Tây Ban Nha, tiếng Pháp, tiếng Ý, tiếng Nga, tiếng Nhật, tiếng Hàn và tiếng Trung. Benchmark này bao gồm nhận diện ý định, phân loại chủ đề, phân tích cảm xúc, suy luận ngôn ngữ tự nhiên, nhận diện diễn đạt lại, phát hiện ngôn ngữ xúc phạm và tính chấp nhận được về ngữ pháp.

Chúng tôi báo cáo độ chính xác trung bình trên các tác vụ trong từng ngôn ngữ, với trọng số như nhau cho mỗi tác vụ. Decider v1.3 vượt Jev 1.14 ở cả tám ngôn ngữ và Decider Flash v1.3 vượt ở sáu ngôn ngữ, với độ chính xác tác vụ trung bình là 88,16% đối với Decider v1.3 và 86,50% đối với Decider Flash v1.3, so với 85,41% của Jev 1.14.

NER, PII và hỏi đáp trích xuất

Chúng tôi đánh giá tính năng locate trên 17 tác vụ ngoài miền (out-of-domain) nhằm kiểm tra khả năng trích xuất trên nhiều lĩnh vực, định dạng đầu vào (văn bản, bảng, tài liệu có cấu trúc) và chỉ dẫn (nhãn ngắn, câu hỏi và mô tả chi tiết). Các lĩnh vực trải dài từ Wikipedia đến bài báo khoa học, báo cáo mối đe dọa an ninh mạng, hỗ trợ kỹ thuật, chính sách quyền riêng tư, sơ yếu lý lịch và hợp đồng pháp lý. Các yêu cầu đa dạng từ tên nhãn ngắn như “người” hoặc “địa chỉ email”, đến câu hỏi về một bảng hoặc một phiếu hỗ trợ, cho tới mô tả trường chi tiết để trích xuất có cấu trúc, chẳng hạn các bên trong một NDA hoặc tổng tiền trên một hóa đơn.

Chúng tôi đánh giá NER và PII bằng F1 khớp chính xác span (exact-span F1), yêu cầu các span dự đoán phải khớp hoàn toàn với ranh giới tham chiếu. QA trích xuất sử dụng F1 ở cấp ký tự, cho điểm một phần đối với phần văn bản câu trả lời trùng lặp, trong khi trích xuất có cấu trúc sử dụng độ chính xác theo trường, tức là tỷ lệ các trường được trích xuất đúng. Với tác vụ phân tích CV, chúng tôi lấy trung bình điểm F1 khớp chính xác span của NER và PII.

Chúng tôi so sánh các mô hình của mình với các mô hình trích xuất đa dụng có kích thước khác nhau: GLiNER large v2.5 (0,5B), Liquid d1 (2B) và Clairic của Cloudflare (không công bố). Decider v1.3 đạt điểm trung bình 69,0 (dùng chỉ số chính của từng tác vụ) và Decider Flash v1.3 đạt 63,6, so với 43,3 của Liquid d1, 41,5 của Clairic và 33,6 của GLiNER large v2.5. Cả hai mô hình Decider đều dẫn đầu ở mọi hạng mục.

Phân loại hình ảnh

Decider đã hỗ trợ sẵn các tác vụ thị giác kể từ v1. Để đánh giá hiệu suất ngoài văn bản, chúng tôi xây dựng một bộ benchmark gồm năm tác vụ, đặc biệt chú trọng phân loại tài liệu, bao gồm hóa đơn, thư từ và sơ yếu lý lịch. Bộ này cũng bao gồm phân loại ảnh vệ tinh, phân loại kết cấu bề mặt, phân loại giống thú cưng và đếm động vật.

Decider v1.3 đạt độ chính xác trung bình 76,99% trên năm tác vụ thị giác, vượt Jev 1.14 1,47 điểm phần trăm. Decider Flash v1.3 đạt 72,77%, cho thấy khả năng phân loại hình ảnh trong một mô hình nhỏ hơn.

Các yêu cầu quyết định trong thực tế

Chúng tôi lấy mẫu một triệu yêu cầu đã loại bỏ trùng lặp và che PII được gửi đến Perplexity Decision API trong 18 ngày đầu tiên ra mắt. Vì mỗi yêu cầu có thể chứa nhiều câu hỏi về cùng một trạng thái, mẫu này bao gồm 2.318.887 câu hỏi riêng lẻ. Tất cả yêu cầu đều được đưa vào với sự cho phép rõ ràng của người dùng cho mục đích nghiên cứu.

Các yêu cầu từ môi trường vận hành thực tế không đi kèm nhãn chuẩn (ground truth), vì vậy chúng tôi dùng các LLM tiên tiến làm giám khảo để tạo câu trả lời tham chiếu và đo mức độ đồng thuận của từng mô hình với các câu trả lời đó. Chúng tôi cũng nhóm các yêu cầu thành 10 hạng mục tác vụ, bao gồm trích xuất thông tin, phân loại lĩnh vực, phân tích cảm xúc, ý định và định tuyến, xếp hạng mức độ liên quan, kiểm duyệt nội dung, đánh giá chất lượng và tuân thủ, đối sánh thực thể, phân tích kinh doanh và hạng mục “Khác”. Cách phân chia này cho thấy hiệu suất thay đổi như thế nào giữa các trường hợp sử dụng thực tế.

Tỷ lệ các loại tác vụ không đồng đều: trích xuất thông tin chiếm 425.402 câu hỏi, phân loại lĩnh vực chiếm 409.564 và phân tích cảm xúc chiếm 344.158. Gộp lại, ba hạng mục này chiếm 50,8% số câu hỏi được lấy mẫu.

Decider v1.3 đạt mức đồng thuận cao nhất với giám khảo ở 93,98%, so với 93,68% của Decider v1.2 và 93,35% của Jev 1.14. Decider v1.3 và Jev 1.14 ngang ngửa nhau ở phân loại lĩnh vực và phân tích cảm xúc, với mức chênh lệch lần lượt là 0,34 và 0,07 điểm phần trăm. Jev dẫn trước 0,69 điểm ở xếp hạng mức độ liên quan, trong khi Decider v1.3 dẫn trước 0,93 điểm ở trích xuất thông tin (tác vụ phổ biến nhất trong mẫu) và 1,21 điểm ở ý định và định tuyến.

Biểu đồ dưới đây so sánh chi phí được báo cáo khi chạy cùng một triệu yêu cầu thực tế. Mỗi yêu cầu có thể chứa nhiều câu hỏi, vì vậy đơn vị ở đây là yêu cầu, không phải từng câu hỏi riêng lẻ.

Decider chạy cục bộ; GLM và DeepSeek dùng llm-api; Jev dùng OpenRouter. Chi phí được báo cáo chỉ áp dụng cho khối lượng công việc cụ thể này, không nêu rõ cách tính chi phí phần cứng cục bộ và không có so sánh độ trễ trong điều kiện tương đương.

Độ bền vững

Chúng tôi đánh giá độ nhạy với nhãn trên 372 câu hỏi trắc nghiệm, gửi 4.788 yêu cầu cho mỗi mô hình. Chúng tôi sắp xếp lại các tùy chọn, gán lại nhãn cho các nội dung trả lời và đổi tên nhãn trong khi vẫn giữ nguyên ý nghĩa của từng câu hỏi, rồi kiểm tra xem câu trả lời về mặt ngữ nghĩa của mô hình có thay đổi không. Tỷ lệ đảo ngược càng thấp cho thấy độ ổn định càng cao.

Decider v1.3 chỉ thay đổi câu trả lời ở 0,27% số câu hỏi dưới mỗi phép biến đổi, so với 2,69–4,84% của Jev 1.14. Chúng tôi cũng lặp lại các đầu vào giống hệt nhau để đo mức biến động khi phục vụ: Decider v1.3 không có thay đổi nào, trong khi Jev 1.14 thay đổi ở 1,88% số câu hỏi.

Cách chúng tôi sử dụng Decider

Decider được xây dựng cho các quy trình làm việc cần đưa ra quyết định nhanh và có cấu trúc. Trong phần này, chúng tôi tìm hiểu cách tận dụng các mô hình này để tạo ra tác động có ý nghĩa đến cách chúng tôi làm việc. Dưới đây là một số trường hợp nổi bật.

Quy tắc bảo mật tự cải thiện

Trong nội bộ, chúng tôi đã và đang sử dụng Decider để cải thiện các chính sách bảo mật của mình.

Hoạt động của các tác nhân của chúng tôi được ghi lại và một loạt kiểm tra dựa trên quy tắc được thực hiện để xác định mọi hành vi có vấn đề. Cách tiếp cận dựa trên quy tắc cho phép chúng tôi giám sát các tác nhân theo thời gian thực với độ trễ tăng thêm không đáng kể. Ngoại tuyến, chúng tôi dùng Decider để xem xét các mẫu từ nhật ký tác nhân đã ghi lại này. Trong trường hợp không có hành vi có vấn đề nào bị gắn cờ, Decider kiểm tra xem có điều gì mà bộ quy tắc của chúng tôi bỏ sót không; còn trong trường hợp có cảnh báo được phát ra, Decider kiểm tra xem đó có phải là cảnh báo nhầm không. Mọi bản ghi mà bộ quy tắc của chúng tôi thất bại trong một trong hai trường hợp đều được gửi đến một tác nhân để phân loại xử lý, và một bản sửa cho các quy tắc sẽ được đề xuất để một thành viên trong nhóm bảo mật của chúng tôi phê duyệt.

Trong một ngày, Decider đã đọc 1 tỷ token trên 7.000 phiên tác nhân và xác định các lỗi dẫn đến 14 bản sửa quy tắc, trong đó 6 bản đã được phê duyệt và triển khai trong vòng hai ngày. Khi chạy lại trên nhật ký của một tuần, các bản sửa đã giảm 52% khối lượng của quy tắc hoạt động nhiều nhất, và các quy tắc được mở rộng đã phát hiện thêm khoảng 40% hành động hợp lệ cần điều tra.

Giám sát rollout RL

Khi hậu huấn luyện mô hình bằng học tăng cường, các chỉ số tổng hợp như phần thưởng cuối không giải thích được vì sao một rollout (một lần thử thực hiện tác vụ) thành công hay thất bại. Rollout có thể bị mất phần thưởng một cách không công bằng do dịch vụ công cụ hoặc sandbox gặp lỗi, hoặc nhận phần thưởng không xứng đáng nếu bộ đánh giá bỏ sót một khẳng định không có căn cứ, chẳng hạn một giá trị bịa đặt mà không công cụ nào trả về.

Chúng tôi dùng Decider để giám sát các rollout cho những trường hợp này. Trước tiên, mã sẽ xác định những phần của rollout cần được kiểm tra kỹ hơn: một lệnh gọi công cụ thất bại và phần suy luận xung quanh, đoạn mã chạy không lỗi, hoặc câu trả lời cuối cùng. Sau đó, Decider trả lời các câu hỏi trắc nghiệm về từng phần, chẳng hạn điều gì đã thất bại trong một bước (một dịch vụ công cụ, một trang web bên ngoài, sandbox, harness hay chính mã của tác nhân) và liệu tác nhân có diễn giải kết quả đúng hay không. Chúng tôi gộp tất cả câu hỏi về một phần nhất định vào một yêu cầu duy nhất và lưu trữ các xác suất thay vì một kết luận, nhờ đó có thể điều chỉnh ngưỡng sau này mà không cần truy vấn lại Decider. Bộ giám sát chỉ quan sát và chẩn đoán: nó không bao giờ thay đổi phần thưởng hay dừng một lượt chạy.

Lọc chất lượng trang

Khi thu thập dữ liệu các trang web để lập chỉ mục và cung cấp cho người dùng, nhiều trang có chất lượng quá thấp đến mức không có ích gì. Điều này bao gồm các tường chặn bot, CAPTCHA và trang lỗi, cũng như những trang web tải đúng nhưng không chứa thông tin hữu ích nào, chẳng hạn như spam, nội dung độn SEO hoặc các trang chỉ có điều hướng. Những trang chất lượng thấp này cần được xác định và lọc khỏi chỉ mục của chúng tôi.

Với Decider, chúng tôi có thể đánh giá chất lượng của các trang ngay trong lúc thu thập dữ liệu (crawl) chúng. Trong cùng một lượt truyền xuôi (forward pass), chúng tôi thực hiện một loạt tác vụ phân loại khác, chẳng hạn như xác định lĩnh vực và đối tượng hướng đến của nội dung, cũng như liệu nội dung đó có chứa thông tin độc hại, bất hợp pháp hoặc thông tin nhận dạng cá nhân hay không. So với việc dùng LLM làm giám khảo, Decider nhanh hơn và rẻ hơn đáng kể.

Minh họa yêu cầu đánh giá chất lượng trang: Thông tin hữu ích, đối tượng mục tiêu, nội dung có hại hoặc bất hợp pháp và thông tin nhận dạng cá nhân được đánh giá từ cùng một trang.

Ngoài các ứng dụng nội bộ này, Decider cũng phù hợp với những quy trình làm việc như sau.

Hỏi đáp hình ảnh

Vì Decider đọc được hình ảnh, mô hình này cũng hoạt động như một công cụ kiểm tra trực quan, xem xét các thay đổi về giao diện của trang web hoặc ứng dụng và xác định lỗi. Decider có thể xem xét ảnh chụp màn hình trang để phát hiện văn bản bị cắt, phần tử chồng lấn, bố cục bị vỡ trước khi một thay đổi được phát hành, hoặc gắn cờ các biểu đồ có thiết kế dễ gây hiểu lầm cho người đọc hoặc vi phạm hướng dẫn thương hiệu.

Điều hướng trình duyệt

Các tác nhân có thể dùng Decider cho những quyết định nhỏ bên trong các tác vụ lớn hơn. Một tác nhân trình duyệt có thể gửi ảnh chụp màn hình ở mỗi bước và nhận thông tin chi tiết về trạng thái của trang cũng như kết quả dự kiến của từng hành động khả thi.

Lập kế hoạch tác vụ nghiên cứu

Câu hỏi của người dùng có thể khác nhau rất nhiều về độ phức tạp, và độ sâu tìm kiếm cần thực hiện để tìm ra câu trả lời cũng vậy. Decider có thể ước tính điều này trước khi bắt đầu tìm kiếm, nhờ đó tốn ít tài nguyên hơn cho những câu hỏi đơn giản.

Bắt đầu

Decider trả về xác suất. Ngưỡng quyết định phù hợp phụ thuộc vào ứng dụng. Tần suất nhãn và chi phí tương đối của dương tính giả và âm tính giả khác nhau giữa các trường hợp sử dụng. Vì vậy, chúng tôi khuyến khích người dùng tinh chỉnh ngưỡng trên một tập phát triển nhỏ, có gán nhãn và mang tính đại diện, thay vì cho rằng một ngưỡng cố định sẽ hoạt động tốt như nhau trên mọi tác vụ.

Chúng tôi khuyên dùng Decider v1.3 cho các đánh giá đòi hỏi sự tinh tế, các bộ tiêu chí chi tiết và những quy trình làm việc mà lỗi sẽ gây tốn kém. Hãy chọn Decider Flash v1.3 cho việc định tuyến, gắn nhãn và lọc với khối lượng lớn, khi độ trễ và chi phí là những ràng buộc chính. Hãy đánh giá cả hai mô hình trên các ví dụ tiêu biểu từ khối lượng công việc của bạn, rồi chọn mô hình đáp ứng yêu cầu về chất lượng, độ trễ và ngân sách của bạn.

Cả hai mô hình đều có sẵn dưới dạng trọng số có thể tải xuống trên Hugging Face theo giấy phép Apache, qua OpenRouter và Perplexity Decisions API.

Trích dẫn

BibTeX
@online{perplexity2026PerplexityDecider,
  author = {{Perplexity} and Antoine Chaffin and Jonas Golde and Louis Milliken and Sarah Eslami and Markus Krimmel and Nandor Licker and Aleksandr Nikolenko and Ron Heichman and Bo Wang and Jarrod Bryan and Jeremy Yang and Denis Yarats},
  title = {{Perplexity Decider}},
  date = {2026-11-12},
  url = {https://www.perplexity.ai/hub/blog/perplexity-decider}
}