Perplexity Decider

เราเปิดตัว Decider v1.3 และ Decider Flash v1.3 ซึ่งเป็นรุ่นต่อจากโมเดลการตัดสินใจรุ่นก่อนหน้าของเรา ได้แก่ v1 v1.1 v1.2 และ Flash v1.2

Decider Flash v1.3 เป็นโมเดลขนาดเล็กที่ distill มาจาก Decider v1.3 โมเดลทั้งสองพร้อมใช้งานบน Hugging Face ภายใต้สัญญาอนุญาต Apache รวมถึงผ่าน OpenRouter และ Perplexity Decisions API

Perplexity Decider ได้รับแรงบันดาลใจจาก Jev ซึ่งเป็น System One Model ของ TypeSafe AI โดยรองรับการจำแนกประเภทแบบไบนารีและแบบหลายคลาสที่มีป้ายกำกับแบบมีลำดับหรือไม่มีลำดับ และส่งคืนความน่าจะเป็นที่แอปพลิเคชันสามารถใช้เพื่อจำแนกประเภท กำหนดเส้นทาง จัดอันดับ และประเมินอินพุต

โมเดล v1.3 ทั้งสองรุ่นมีประสิทธิภาพและความทนทานดีขึ้นในงานข้อความและงานภาพที่หลากหลาย ด้วย attention แบบสองทิศทาง ข้อมูลฝึกที่คัดสรรมาดีขึ้น และสูตรการฝึกที่ปรับปรุงแล้ว นอกจากนี้เรายังเปิดตัว locate ฟีเจอร์ใหม่ที่ไฮไลต์เนื้อหาที่เลือกสำหรับงานการรู้จำเอนทิตีที่มีชื่อ การระบุข้อมูลส่วนบุคคล และการตอบคำถามแบบดึงข้อความ

ในโพสต์นี้ เราจะอธิบายวิธีที่เราฝึกและประเมิน Decider และแบ่งปันวิธีที่เราใช้งาน Decider ภายใน Perplexity

โมเดลการตัดสินใจคืออะไร

โมเดลการตัดสินใจคือตัวจำแนกประเภทอเนกประสงค์ คุณป้อนอินพุตและชุดคำถามพร้อมคำตอบที่เป็นไปได้ของแต่ละคำถาม สำหรับแต่ละคำถาม โมเดลจะส่งคืนการแจกแจงความน่าจะเป็นของคำตอบ โมเดลรองรับคำถาม 3 ประเภท:

• ใช่ / ไม่ใช่: การตัดสินใจแบบไบนารี
• หลายตัวเลือก: ป้ายกำกับแบบหลายคลาสที่กำหนดเอง
• คะแนน: ระดับที่มีลำดับ

โมเดลการตัดสินใจรองรับงานจำแนกประเภทและการให้คะแนนได้หลากหลาย:

• การตัดสินเอาต์พุต: ประเมินความถูกต้องตรงตามต้นฉบับ คุณภาพ และความปลอดภัย
• การกำหนดเส้นทาง: ส่งคำขอไปยังโมเดลที่เล็กกว่าหรือใหญ่กว่าตามระดับความยาก
• การกลั่นกรองและความปลอดภัย: ตรวจจับเนื้อหาที่เป็นอันตราย ฟิชชิง และ prompt injection ในเอาต์พุตของเครื่องมือ
• การกรองและการติดแท็ก: การจัดระเบียบคอลเลกชันเนื้อหาขนาดใหญ่
• การค้นคืนและการจัดอันดับใหม่: การให้คะแนนผลการค้นหาตามความเกี่ยวข้อง

ก่อนหน้านี้ งานหลายอย่างเหล่านี้จัดการโดยโมเดลเชิงสร้างสรรค์อย่าง LLM แม้ว่างานเหล่านี้จะไม่จำเป็นต้องสร้างข้อความในรูปแบบอิสระก็ตาม โมเดลการตัดสินใจ (decision model) อยู่ระหว่าง LLM กับตัวจำแนกประเภทเฉพาะงาน โมเดลเหล่านี้ส่งคืนค่าความน่าจะเป็นสำหรับคำถามหลายข้อเกี่ยวกับอินพุตเดียวกันภายใน forward pass เดียว จึงไม่ต้องสร้างคำตอบทีละโทเค็นและใช้การคำนวณร่วมกันระหว่างคำถามต่าง ๆ ได้ โมเดลเหล่านี้ต่างจากตัวจำแนกประเภทเฉพาะงานตรงที่สามารถรองรับงานใหม่ผ่านพรอมต์ภาษาธรรมชาติ ซึ่งเป็นความยืดหยุ่นที่ได้เรียนรู้จากการฝึกกับงานที่หลากหลายในรูปแบบถาม-ตอบที่ใช้ร่วมกัน

การฝึก

เปลี่ยน LLM เชิงกำเนิดให้เป็นโมเดลการตัดสินใจ

เราสร้าง Decider โดยดัดแปลงโมเดลแกนหลัก LLM เชิงสร้างสรรค์ (generative) ที่มีประสิทธิภาพสูง เพื่ออธิบายการดัดแปลงนี้ เราจะอธิบายก่อนว่าคำขอหนึ่งรายการถูกแทนอย่างไร ดังที่แสดงด้านล่าง คำขอประกอบด้วยบริบทที่ใช้ร่วมกัน (สถานะ) และคำถามจำนวนหนึ่ง สถานะจะถูกนำกลับมาใช้ซ้ำโดยคำถามทั้งหมด

ตัวอย่างเช่น เมื่อมีเอกสารและบทสรุปของเอกสารนั้น คำขอเดียวสามารถถามได้ว่าบทสรุปแสดงเนื้อหาของเอกสารอย่างถูกต้องตรงตามต้นฉบับหรือไม่ และมีไว้สำหรับผู้เชี่ยวชาญหรือผู้อ่านทั่วไป ถัดจาก state แต่ละบล็อกคำถามจะประกอบด้วยคำถามและคำตอบที่เป็นไปได้ โดยแต่ละคำตอบจะได้รับโทเค็นป้ายกำกับที่กำหนดไว้ล่วงหน้า เช่น A, B หรือ C โทเค็นพิเศษ <|marker|> ระบุตำแหน่งที่จะอ่านผลการทำนายของโมเดล ณ ตำแหน่งนี้ เลเยอร์เอาต์พุตเชิงเส้นที่เรียนรู้แล้ว (decision head) จะแปลง hidden state เป็นคะแนนสำหรับตัวเลือกคำตอบของคำถาม จากนั้นจึงแปลงเป็นความน่าจะเป็น

ขยาย

เรากำหนดค่าเริ่มต้นของเลเยอร์เอาต์พุตจากโมเดลฐาน ซึ่งปกติจะให้คะแนนโทเค็นถัดไปจากคำศัพท์ทั้งหมด และเก็บไว้เฉพาะแถวที่สอดคล้องกับโทเค็นตัวเลือกที่กำหนดไว้ล่วงหน้า เช่น A, B หรือ C จากนั้นจึงฝึกเลเยอร์ที่ตัดแต่งแล้วนี้ให้แปลง hidden state ของ <|marker|> เป็นคะแนนคำตอบ วิธีนี้ครอบคลุมคำถามการจำแนกประเภททั้งหมด เพราะคำถามเหล่านั้นสามารถเขียนในรูปแบบหลายตัวเลือกได้ทั้งหมด

สำหรับการฝึก เรานำชุดข้อมูลสาธารณะหลายร้อยชุดที่ครอบคลุมงานหลากหลาย (ความรู้สึก การอนุมานภาษาธรรมชาติ การตรวจจับเจตนา การจับคู่เอนทิตี การกลั่นกรอง การตรวจสอบข้อเท็จจริง การให้คะแนน ฯลฯ) มาแปลงแต่ละตัวอย่างให้อยู่ในรูปแบบเดียวกันที่อธิบายไว้ข้างต้น ได้แก่ state คำถามหนึ่งข้อหรือมากกว่า ตัวเลือกของคำถามเหล่านั้น และเป้าหมาย เป้าหมายอาจเป็นตัวเลือกที่ถูกต้องเพียงตัวเดียวหากเรามี gold label หรือเป็นการแจกแจงความน่าจะเป็นบนตัวเลือกต่าง ๆ

ใน v1.3 เราเปิดตัว locate ซึ่งดึงข้อความจาก state แทนการเลือกจากตัวเลือกที่กำหนดไว้ล่วงหน้า คำถาม locate จะอธิบายสิ่งที่ต้องค้นหา โดยใช้ป้ายกำกับสั้น ๆ เช่น “ตำแหน่งที่ตั้ง” หรือคำสั่ง เช่น “ดึงชื่อเมืองที่งานนี้ตั้งอยู่” โมเดลจะส่งคืนข้อความที่ตรงกันทุกตัวอักษรจาก state พร้อมตำแหน่งอักขระเริ่มต้นและสิ้นสุด หากไม่พบรายการที่ตรงกัน โมเดลจะส่งคืนรายการว่าง

ขยาย

ด้วย state ที่ใช้ร่วมกัน คำขอเดียวจึงรวมคำถาม locate การจำแนกประเภท และการให้คะแนนเกี่ยวกับอินพุตเดียวกันได้ ตัวอย่างเช่น สามารถถามว่างานหนึ่งต้องการประสบการณ์ระดับอาวุโสหรือไม่ และดึงทักษะที่จำเป็นออกมาได้

attention แบบสองทิศทาง: ให้โมเดลอ่านได้ทั้งสองทาง

โมเดลของเราเริ่มต้นจากแบ็กโบนเชิงกำเนิดที่ผ่านการฝึกล่วงหน้ามาอย่างดี ซึ่ง causal attention ของแบ็กโบนเหล่านี้ทำให้แต่ละโทเค็นให้ความสนใจได้เฉพาะตัวเองและโทเค็นก่อนหน้าเท่านั้น การศึกษาแบบ ablation ของเราแสดงให้เห็นว่าการทำให้เลเยอร์ full-attention ของแบ็กโบนเป็นแบบสองทิศทางช่วยเพิ่มประสิทธิภาพ เราจึงนำการออกแบบนี้มาใช้เพื่อให้แต่ละโทเค็นรับบริบทจากอินพุตทั้งหมดได้

attention แบบสองทิศทางทำให้เกิดตัวเลือกการออกแบบอีกข้อหนึ่ง: state และคำถามควรมีปฏิสัมพันธ์กันอย่างไร เราพิจารณารูปแบบ attention สามแบบ ซึ่งส่งผลต่อประสิทธิภาพ ความเสถียรของคำตอบ และการนำแคชกลับมาใช้ใหม่แตกต่างกัน:

• ทุกส่วนเห็นทุกส่วน (v1.2): state และคำถามทั้งหมดได้รับการประมวลผลร่วมกันด้วย attention แบบสองทิศทางเต็มรูปแบบ การคำนวณบน state ใช้ร่วมกัน แต่คำตอบของคำถามหนึ่งอาจเปลี่ยนไปขึ้นอยู่กับคำถามอื่นที่ถามพร้อมกัน
• คำถามแบบแยกกัน (v1.3): state ให้ความสนใจกับคำถามทั้งหมด ขณะที่แต่ละคำถามให้ความสนใจเฉพาะ state และโทเค็นของตัวเองเท่านั้น คำถามยังคงส่งผลต่อกันทางอ้อมผ่าน state ที่ใช้ร่วมกันได้ แต่ผลลัพธ์มีความเสถียรมากกว่า
• แคชได้ทั้งหมด: สถานะจะ attend เฉพาะกับตัวเอง ขณะที่แต่ละคำถามจะ attend ไปยังสถานะและโทเค็นของตัวเอง สถานะไม่ขึ้นอยู่กับคำถามและนำกลับมาใช้ซ้ำข้ามคำขอต่าง ๆ ได้ เพื่อใช้ประโยชน์จาก prompt caching เราไม่ได้ใช้โหมดนี้เป็นค่าเริ่มต้น เนื่องจากการให้สถานะมองเห็นคำถามมีความสำคัญอย่างมากสำหรับงานหลายประเภท แต่การไฟน์จูนเพียงเล็กน้อยก็สามารถเปลี่ยนโมเดลให้ใช้โหมดนี้ได้

ท้ายที่สุดเราเลือกใช้คำถามแบบแยกกันเพราะให้ประสิทธิภาพและความเสถียรที่ดี

ขยาย

สูตรการฝึก

การฝึกโมเดลทั้งสองขนาดดำเนินไปในสามขั้นตอน เราเริ่มจากฝึกโมเดลที่ใหญ่กว่าซึ่งพัฒนาบนพื้นฐานของ Qwen3.8-27B โดยใช้ cross-entropy กับชุดข้อมูลขนาดใหญ่ จากนั้นจึงกลั่น (distill) โมเดลนี้ลงสู่โมเดล Qwen3.5-4B ที่เล็กกว่า

ขั้นแรกคือการฝึกแบบทั่วไป ซึ่งเรา fine-tune โมเดลทั้งหมดด้วยคลังข้อมูลขนาดใหญ่ ในขั้นนี้ เรายอมรับเฉพาะข้อมูลที่ช่วยโมเดลได้ในทุกด้านและไม่เฉพาะเจาะจงกับเบนช์มาร์กใด ๆ เราจึงไม่รวมส่วนข้อมูลฝึกของเบนช์มาร์กใด ๆ

หลังจากฝึกโมเดลแบบทั่วไป (generalist) นี้แล้ว เราจะดำเนินการขั้นตอนที่สองซึ่งละเอียดยิ่งขึ้นโดยใช้ LoRA ข้อมูลที่ใช้ในขั้นตอนนี้มุ่งเป้าไปที่โดเมนและงานเฉพาะ เราจะเพิ่มข้อมูลในขั้นตอนที่สองแทนขั้นตอนแรก หากพบว่าผลลัพธ์ดีขึ้นเพียงในวงแคบ หรือพบว่าประสิทธิภาพในงานอื่นถดถอยลง เราใช้ LoRA เพื่อไม่ให้โมเดลเบี่ยงเบนไปจากโมเดลแบบทั่วไปมากเกินไปจนเสี่ยงสูญเสียประสิทธิภาพเพื่อปรับให้เข้ากับโดเมนเฉพาะเหล่านั้น เป้าหมายคือการปรับปรุงประสิทธิภาพโดยยังคงความรู้ทั่วไปของโมเดลแกนหลัก (backbone) ไว้ นอกจากนี้ เรายังใช้ค่าน้ำหนักเมื่อรวม LoRA กลับเข้าไปในโมเดลพื้นฐาน เพื่อควบคุมการเบี่ยงเบนได้แม่นยำยิ่งขึ้น และให้ความสำคัญกับเมตริกบนข้อมูล held-out มากกว่าผลลัพธ์ที่ดีขึ้นภายในโดเมน

สุดท้าย เราเพิ่มขั้นตอนเฉพาะด้านภาพ ขั้นตอนนี้ถือเป็นอีกขั้นตอนหนึ่งของการปรับให้เชี่ยวชาญเฉพาะทางอย่างละเอียดเช่นเดียวกับขั้นที่สอง โดยใช้ LoRA adapter ที่รวมกลับเข้าสู่โมเดลฐานพร้อมค่าน้ำหนัก ความสามารถด้านภาพบางอย่างอาจต้องแลกมาด้วยประสิทธิภาพด้านข้อความ และเนื่องจากเราพบว่ามีการใช้งานโมเดลกับข้อความมากกว่ามาก เราจึงให้ความสำคัญกับตัวชี้วัดด้านข้อความมากกว่าตัวชี้วัดด้านภาพ

สำหรับการฝึกข้อความทั้งสองขั้น เราใช้ค่าเฉลี่ยของน้ำหนักจากการรันสามครั้ง โดยแต่ละครั้งใช้ random seed ต่างกัน เราพบว่าวิธีนี้ช่วยเพิ่มประสิทธิภาพและความทนทานของโมเดลที่รวมกัน

เมื่อได้โมเดลขนาดใหญ่ขั้นสุดท้ายแล้ว เราจะใช้กระบวนการฝึกสามขั้นตอนเดียวกันกับโมเดลที่เล็กกว่า ในขั้นนี้ โมเดลขนาดใหญ่ทำหน้าที่เป็นครู (teacher) โดยการแจกแจงผลลัพธ์ที่โมเดลครูทำนายจะใช้แทนป้ายกำกับมาตรฐาน (gold label) และโมเดลที่เล็กกว่าจะถูกฝึกให้ลด KL divergence ระหว่างการทำนายของตนเองกับการทำนายของโมเดลครูให้น้อยที่สุด วัตถุประสงค์การกลั่นนี้ให้ผลดีกว่า cross-entropy บนข้อมูลฝึกชุดเดียวกัน แม้ว่า cross-entropy จะทำได้ดีกว่าบนเบนช์มาร์กที่มีข้อมูลฝึกเฉพาะ แต่ก็สรุปทั่วไป (generalize) ไปยังข้อมูล held-out ได้ไม่ดีเท่า เราตั้งสมมติฐานว่าการกลั่นถ่ายทอดการแจกแจงผลลัพธ์ของโมเดลครูได้ดีกว่า รวมถึงความมั่นใจต่อทางเลือกอื่นที่ไม่ใช่คำตอบมาตรฐาน ขณะที่ cross-entropy ส่งเสริมให้เกิดการโอเวอร์ฟิตกับการแจกแจงของข้อมูลฝึกที่เฉพาะเจาะจงกับเบนช์มาร์ก ดังนั้นเราจึงเลือกใช้วัตถุประสงค์การกลั่นที่อิงกับ KL

เพื่อลดการปนเปื้อนระหว่างข้อมูลฝึกและข้อมูลทดสอบ เราจะนำตัวอย่างข้อมูลฝึกใด ๆ ที่อาจทับซ้อนกับการประเมินที่เราใช้ออก ซึ่งเป็นสิ่งสำคัญเนื่องจากชุดข้อมูลฝึกสาธารณะบางชุดมีเนื้อหาจำนวนมากจากชุดข้อมูลประเมินบางชุด เรายังตรวจสอบและขจัดอคติอย่างละเอียด เพื่อให้มั่นใจว่าผลลัพธ์ที่ดีขึ้นมีความน่าเชื่อถือ และไม่ได้เกิดจากอคติที่โมเดลเรียนรู้มาเท่านั้น

การเพิ่มความสามารถในการดึงข้อมูล

ฟีเจอร์ locate ดึงข้อมูล เช่น เอนทิตีที่มีชื่อ จากข้อความ โดยไม่เปลี่ยนวิธีที่โมเดลตอบคำขอทั่วไป เพื่อการนี้ เราได้เพิ่มขั้นการฝึกอีกหนึ่งขั้น: เราเพิ่มโทเค็นพิเศษใหม่ <|locate|>, span head และ LoRA adapter ให้กับ Decider

เรากำหนดค่าเริ่มต้นของ embedding ของ <|locate|> จาก <|marker|> ที่เรียนรู้ในขั้นการฝึกก่อนหน้า เราฝึกเฉพาะ embedding ใหม่นี้ span head และ LoRA adapter โดยคงน้ำหนักเดิมของแบ็กโบนและ decision head ไว้ไม่เปลี่ยนแปลง แต่ละฟิลด์ที่ร้องขอจะมีโทเค็น <|locate|> ของตัวเอง

span head ใช้การแทนค่า (representation) ของ <|locate|> ร่วมกับการแทนค่าของโทเค็นสถานะ เพื่อให้คะแนนว่า span ที่ตรงกันเริ่มต้นและสิ้นสุดที่ใด และคู่จุดเริ่มต้น-จุดสิ้นสุดใดที่เข้าคู่กัน นอกจากนี้ยังใช้การแทนค่าของโทเค็น <|locate|> เพื่อทำนายค่าเกณฑ์ (threshold) เฉพาะของแต่ละฟิลด์สำหรับคะแนนเหล่านี้ span ที่ถูกเลือกจะถูกส่งคืนเป็นตำแหน่งอักขระในข้อความต้นฉบับ

เราฝึก span head ด้วย InfoNCE loss ที่ดัดแปลง ซึ่งผลักให้ gold span ทุกตัวมีคะแนนสูงกว่าค่าเกณฑ์ และให้ค่าเกณฑ์สูงกว่า span อื่นทั้งหมด ฟังก์ชัน loss นี้มีสองพจน์: พจน์แรกผลักคะแนนของ span ที่ถูกต้องให้สูงกว่าค่าเกณฑ์และ span ที่ผิด พจน์ที่สองผลักค่าเกณฑ์ให้สูงกว่าคะแนนของ span ที่ผิด ฟิลด์ที่ไม่มีคำตอบจะได้รับเพียงพจน์ที่สอง ซึ่งสอนให้โมเดลส่งคืนรายการว่าง

เราฝึกด้วยงานดึงช่วงข้อความ (span extraction) หลากหลายประเภท ได้แก่ การรู้จำเอนทิตีที่มีชื่อ การตรวจจับ PII และการตอบคำถามแบบดึงข้อความ เราปรับคำอธิบายฟิลด์ให้หลากหลายตั้งแต่ป้ายกำกับสั้น ๆ ไปจนถึงคำสั่งโดยละเอียด เพื่อให้โมเดลเรียนรู้ที่จะทำตามคำขอแทนที่จะจดจำชุดป้ายกำกับที่ตายตัว

Locate สอนให้โมเดลทำงานที่มีโครงสร้างแตกต่างออกไป และเราต้องการเพิ่มความสามารถนี้โดยไม่สูญเสียสิ่งที่โมเดลทำได้ดีอยู่แล้ว การรวมอะแดปเตอร์ locate เข้ากับโมเดลแกนหลักทำให้ประสิทธิภาพในคำขอการตัดสินใจถดถอยลงบางส่วน เพื่อจำกัดผลกระทบนี้ เรากำลังศึกษาแนวทางต่าง ๆ เช่น การใช้ข้อมูล replay จากขั้นตอนก่อนหน้าเพิ่มขึ้น และวัตถุประสงค์เสริมที่ช่วยให้ผลลัพธ์ของโมเดลในคำขอการตัดสินใจใกล้เคียงกับของโมเดลดั้งเดิม อย่างไรก็ตาม เราพบว่าในปัจจุบันการรวมยังคงทำให้สูญเสียประสิทธิภาพอยู่ เราจึงไม่รวมอะแดปเตอร์เข้าไป และเปิดใช้งานอะแดปเตอร์เฉพาะสำหรับคำขอ locate เท่านั้น

การประเมิน

เราประเมิน Decider v1.3 และ Decider Flash v1.3 บนเบนช์มาร์กภายนอกจาก Hugging Face Decision Index ClaimBench ของ Vals AI และ Artificial Analysis Decision Index

จากการประเมินเหล่านี้ โมเดลของเราแสดงประสิทธิภาพที่แข็งแกร่ง แม้ว่าลีดเดอร์บอร์ดเหล่านี้จะมีงานที่เก็บไว้เป็นส่วนตัว แต่ก็ยังถูกโกงได้ผ่านการส่งผลซ้ำ ๆ และการปรับจูนแบบวนซ้ำตามผลตอบรับจากลีดเดอร์บอร์ด เพื่อเสริมลีดเดอร์บอร์ดเหล่านี้ เราประเมินโมเดลด้วยชุดการประเมินภายในที่รวมงานใช้งานจริงแบบส่วนตัวเข้ากับการประเมินแบบ held-out ที่ดึงมาจากชุดข้อมูลสาธารณะที่ไม่ใช่เบนช์มาร์ก การประเมินเหล่านี้ช่วยตรวจสอบความสามารถในการสรุปทั่วไปเพิ่มเติมนอกเหนือจากเบนช์มาร์กสาธารณะ และช่วยให้เราแยกแยะการพัฒนาในวงกว้างออกจากผลลัพธ์ที่ดีขึ้นเฉพาะกับชุดการประเมินที่คุ้นเคย

ภายในองค์กร เราได้สร้างชุดงานมากกว่า 200 งาน ครอบคลุมหลายโดเมนและประเภทงาน เช่น การจำแนกประเภท การให้คะแนน การจัดอันดับใหม่ และการดึงเอนทิตี เพื่อประเมินประสิทธิภาพของ Decider ในโลกจริงอย่างตรงไปตรงมา การประเมินทั้งหมดจึงทำแบบ zero-shot โดยไม่มีการ fine-tune เฉพาะงาน ซึ่งทำให้เราเห็นสัญญาณที่ชัดเจนว่าควรปรับปรุงโมเดลตรงจุดใด

การจำแนกประเภทคำค้นหา

ที่ Perplexity เราใช้ระบบจำแนกประเภทแบบหลายหัว (multi-head) เพื่อประมวลผลคำค้นหาของผู้ใช้แต่ละรายการ คำค้นหาแต่ละรายการจะผ่านโมเดล embedding ซึ่งทำหน้าที่เป็นตัวดึงฟีเจอร์ก่อน จากนั้น embedding ที่ได้จะถูกป้อนเข้าสู่หัวจำแนกประเภทหลายหัวที่แยกจากกัน ซึ่งมีทั้งตัวจำแนกแบบไบนารีและแบบหลายป้ายกำกับ ตัวอย่างเช่น หัวหนึ่งจะตัดสินว่าคำค้นหาของผู้ใช้ควรเรียกใช้การค้นหาเว็บหรือไม่

ในงานจำแนกประเภท 63 งานที่ LLM ระดับแนวหน้ากำหนดป้ายกำกับอ้างอิงใหม่อย่างอิสระ Decider v1.3 ได้ความแม่นยำเฉลี่ย 91.6% สูงกว่าตัวจำแนกประเภทที่ใช้งานจริงของเรา 6.54 จุดเปอร์เซ็นต์ Decider Flash v1.3 ก็เหนือกว่า baseline ที่ใช้งานจริงเช่นกัน ขณะที่ Decider v1.3 เหนือกว่า Jev 1.14

ขยาย

การจำแนกประเภทเฉพาะโดเมน

เราได้รวบรวมชุดการประเมินเฉพาะโดเมนจากชุดข้อมูลสาธารณะ เพื่อประเมินประสิทธิภาพการจำแนกประเภทของโมเดลการตัดสินใจในเจ็ดโดเมน ได้แก่ การตรวจสอบข้อกล่าวอ้าง (6 งาน) การดูแลสุขภาพ (7) ความปลอดภัยไซเบอร์ (8) การเขียนโปรแกรม (16) ภาครัฐ (7) กฎหมาย (9) และการเงิน (9)

ตัวอย่างเช่น “ประเมินความซับซ้อนด้านเวลาของโปรแกรม Python” หรือ “ใช้รายงานทางการเงินประจำปีเพื่อพิจารณาว่าเงินสดที่ไม่มีข้อจำกัดของบริษัทเพียงพอสำหรับชำระเงินต้นของหนี้ที่ครบกำหนดภายในสิบสองเดือนข้างหน้าหรือไม่” Decider v1.3 นำในทั้งเจ็ดโดเมน โดยเหนือกว่า Jev 1.14 สูงสุด 12.9 จุดเปอร์เซ็นต์ในด้านการเงิน และ 9.3 จุดในด้านกฎหมาย Decider Flash v1.3 ตามหลัง Jev 1.14 ในด้านการเงิน การเขียนโปรแกรม และกฎหมาย และมีประสิทธิภาพใกล้เคียงกันในโดเมนอื่น ๆ

ขยาย

การค้นคืนและการจัดอันดับใหม่

การค้นหาคือหัวใจของ Perplexity เรามีชุดงานค้นคืนที่ครอบคลุมกว้างขวางเพื่อประเมินประสิทธิภาพการจัดอันดับใหม่ของโมเดล สำหรับแต่ละงาน ขั้นแรกเราใช้กลุ่มโมเดล embedding เพื่อค้นคืนเอกสารตัวเลือก 50 อันดับแรกจากแต่ละคลังข้อมูล จากนั้นเราจัดอันดับเอกสารตัวเลือกเหล่านี้ใหม่โดยใช้ Decider และเปรียบเทียบประสิทธิภาพกับ reranker พื้นฐานที่แข็งแกร่งอย่าง Qwen3-Reranker-8B

เราประเมิน Decider ในการตั้งค่าแบบ zero-shot และ pointwise โดยใช้โมเดลให้คะแนนแต่ละคู่คำค้นหา–เอกสารโดยตรงอย่างเป็นอิสระต่อกัน และจัดอันดับเอกสารตามความเกี่ยวข้อง ในงานค้นคืน 72 งาน Decider v1.3 ได้ค่า nDCG@10 เฉลี่ย 83.99 เหนือกว่า Qwen3-Reranker-8B 1.81 จุด และเหนือกว่า Jev 1.14 2.24 จุด

บน เบนช์มาร์ก BEIR โมเดลทั้งสองเหนือกว่า Qwen3-Reranker-8B 8.78 และ 7.05 nDCG@10 ตามลำดับ เมื่อเทียบกับ Jev 1.14 Decider v1.3 สูงกว่า 1.33 จุด ขณะที่เวอร์ชัน Flash ได้คะแนนต่ำกว่า 0.4 จุด

ขยาย

การจำแนกประเภทหลายภาษา

เพื่อประเมินโมเดลการตัดสินใจนอกเหนือจากภาษาอังกฤษ เราได้รวบรวมเบนช์มาร์กการจำแนกประเภทหลายภาษา ซึ่งประกอบด้วยงานเฉพาะภาษา 19 งานจากชุดข้อมูลสาธารณะ 8 ชุด มีตัวอย่าง 46,484 ตัวอย่างในแปดภาษา ได้แก่ เยอรมัน สเปน ฝรั่งเศส อิตาลี รัสเซีย ญี่ปุ่น เกาหลี และจีน เบนช์มาร์กนี้ครอบคลุมการตรวจจับเจตนา การจำแนกหัวข้อ การวิเคราะห์ความรู้สึก การอนุมานภาษาธรรมชาติ การตรวจจับการถอดความ การตรวจจับภาษาที่ไม่เหมาะสม และความถูกต้องทางไวยากรณ์

เรารายงานความแม่นยำเฉลี่ยของงานทั้งหมดในแต่ละภาษา โดยให้น้ำหนักแต่ละงานเท่ากัน Decider v1.3 เหนือกว่า Jev 1.14 ในทั้งแปดภาษา และ Decider Flash v1.3 เหนือกว่าในหกภาษา โดยมีความแม่นยำเฉลี่ยต่องาน 88.16% สำหรับ Decider v1.3 และ 86.50% สำหรับ Decider Flash v1.3 เทียบกับ 85.41% สำหรับ Jev 1.14

ขยาย

NER, PII และการตอบคำถามแบบดึงข้อความ

เราประเมินฟีเจอร์ locate กับงานนอกโดเมน 17 งาน ซึ่งทดสอบความสามารถในการดึงข้อมูลในหลายโดเมน รูปแบบอินพุต (ข้อความ ตาราง เอกสารที่มีโครงสร้าง) และคำสั่ง (ป้ายกำกับสั้น ๆ คำถาม และคำอธิบายโดยละเอียด) โดเมนมีตั้งแต่ Wikipedia ไปจนถึงบทความวิทยาศาสตร์ รายงานภัยคุกคามทางไซเบอร์ การสนับสนุนทางเทคนิค นโยบายความเป็นส่วนตัว เรซูเม่ และสัญญาทางกฎหมาย คำขอมีตั้งแต่ชื่อป้ายกำกับสั้น ๆ เช่น “บุคคล” หรือ “ที่อยู่อีเมล” คำถามเกี่ยวกับตารางหรือตั๋วการสนับสนุน ไปจนถึงคำอธิบายฟิลด์โดยละเอียดสำหรับการดึงข้อมูลแบบมีโครงสร้าง เช่น คู่สัญญาของ NDA หรือยอดรวมในใบแจ้งหนี้

เราประเมิน NER และ PII โดยใช้ exact-span F1 ซึ่งกำหนดให้ span ที่ทำนายต้องตรงกับขอบเขตอ้างอิงทุกประการ ส่วน Extractive QA ใช้ F1 ระดับอักขระ ซึ่งให้คะแนนบางส่วนสำหรับข้อความคำตอบที่ทับซ้อนกัน ขณะที่การดึงข้อมูลแบบมีโครงสร้างใช้ความแม่นยำระดับฟิลด์ ซึ่งคือสัดส่วนของฟิลด์ที่ดึงข้อมูลได้ถูกต้อง สำหรับการแยกวิเคราะห์ CV เราใช้ค่าเฉลี่ยของคะแนน exact-span F1 ของ NER และ PII

เราเปรียบเทียบโมเดลของเรากับโมเดลดึงข้อมูลอเนกประสงค์ขนาดต่าง ๆ ได้แก่ GLiNER large v2.5 (0.5B), Liquid d1 (2B) และ Clairic ของ Cloudflare (ไม่เปิดเผยขนาด) Decider v1.3 ได้คะแนนเฉลี่ย 69.0 (โดยใช้ตัวชี้วัดหลักของแต่ละงาน) และ Decider Flash v1.3 ได้ 63.6 เทียบกับ 43.3 สำหรับ Liquid d1, 41.5 สำหรับ Clairic และ 33.6 สำหรับ GLiNER large v2.5 โมเดล Decider ทั้งสองรุ่นนำในทุกหมวดหมู่

ขยาย

การจำแนกประเภทรูปภาพ

Decider รองรับงานด้านภาพโดยกำเนิดมาตั้งแต่ v1 เพื่อประเมินประสิทธิภาพนอกเหนือจากข้อความ เราได้รวบรวมชุดเบนช์มาร์กห้างานที่เน้นการจำแนกประเภทเอกสารเป็นพิเศษ รวมถึงใบแจ้งหนี้ จดหมาย และเรซูเม่ ชุดนี้ยังครอบคลุมการจำแนกภาพถ่ายดาวเทียม การจำแนกพื้นผิว การจำแนกสายพันธุ์สัตว์เลี้ยง และการนับจำนวนสัตว์

Decider v1.3 ได้ความแม่นยำเฉลี่ย 76.99% ในงานด้านภาพทั้งห้างาน เหนือกว่า Jev 1.14 1.47 จุดเปอร์เซ็นต์ ส่วน Decider Flash v1.3 ได้ 72.77% แสดงให้เห็นถึงความสามารถในการจำแนกภาพในโมเดลที่เล็กกว่า

ขยาย

คำขอการตัดสินใจในโลกจริง

เราสุ่มตัวอย่างคำขอหนึ่งล้านรายการที่ตัดรายการซ้ำและปกปิด PII แล้ว ซึ่งส่งไปยัง Perplexity Decision API ในช่วง 18 วันแรกที่เปิดให้บริการ เนื่องจากคำขอแต่ละรายการอาจมีหลายคำถามเกี่ยวกับ state เดียวกัน ตัวอย่างนี้จึงประกอบด้วยคำถามรายข้อทั้งหมด 2,318,887 ข้อ คำขอทั้งหมดถูกนำมาใช้โดยได้รับอนุญาตอย่างชัดแจ้งจากผู้ใช้เพื่อการวิจัย

คำขอจริงในระบบใช้งานไม่มีป้ายกำกับ ground truth มาด้วย เราจึงใช้ LLM ระดับแนวหน้าเป็นผู้ตัดสินเพื่อสร้างคำตอบอ้างอิง และวัดความสอดคล้องของแต่ละโมเดลกับคำตอบเหล่านั้น นอกจากนี้เรายังจัดกลุ่มคำขอออกเป็น 10 หมวดหมู่งาน ได้แก่ การดึงข้อมูล การจำแนกโดเมน การวิเคราะห์ความรู้สึก เจตนาและการกำหนดเส้นทาง การจัดอันดับความเกี่ยวข้อง การกลั่นกรองเนื้อหา การตรวจสอบคุณภาพและการปฏิบัติตามข้อกำหนด การจับคู่เอนทิตี การวิเคราะห์ธุรกิจ และหมวดหมู่ “อื่น ๆ” การแยกย่อยนี้แสดงให้เห็นว่าประสิทธิภาพแตกต่างกันอย่างไรในกรณีการใช้งานจริง

สัดส่วนงานไม่สม่ำเสมอ: การดึงข้อมูลมี 425,402 คำถาม การจำแนกโดเมนมี 409,564 คำถาม และการวิเคราะห์ความรู้สึกมี 344,158 คำถาม เมื่อรวมกัน สามหมวดหมู่นี้คิดเป็น 50.8% ของคำถามในตัวอย่าง

Decider v1.3 มีความสอดคล้องกับผู้ตัดสินสูงสุดที่ 93.98% เทียบกับ 93.68% สำหรับ Decider v1.2 และ 93.35% สำหรับ Jev 1.14 Decider v1.3 และ Jev 1.14 ทำได้ใกล้เคียงกันในการจำแนกโดเมนและการวิเคราะห์ความรู้สึก โดยมีส่วนต่าง 0.34 และ 0.07 จุดเปอร์เซ็นต์ตามลำดับ Jev นำ 0.69 จุดในการจัดอันดับความเกี่ยวข้อง ขณะที่ Decider v1.3 นำ 0.93 จุดในการดึงข้อมูล (งานที่พบบ่อยที่สุดในตัวอย่าง) และนำ 1.21 จุดในด้านเจตนาและการกำหนดเส้นทาง

ขยาย

แผนภูมิด้านล่างเปรียบเทียบต้นทุนที่รายงานของการรันคำขอที่ใช้งานจริงชุดเดียวกันหนึ่งล้านรายการ คำขอแต่ละรายการอาจมีหลายคำถาม หน่วยในที่นี้จึงเป็นคำขอ ไม่ใช่คำถามแต่ละข้อ

ขยาย

ความทนทาน

เราประเมินความอ่อนไหวต่อป้ายกำกับด้วยคำถามแบบหลายตัวเลือก 372 ข้อ โดยส่งคำขอ 4,788 รายการต่อโมเดล เราสลับลำดับตัวเลือก กำหนดป้ายกำกับใหม่ให้กับข้อความคำตอบ และเปลี่ยนชื่อป้ายกำกับ โดยยังคงความหมายของแต่ละคำถามไว้ จากนั้นตรวจสอบว่าคำตอบเชิงความหมายของโมเดลเปลี่ยนไปหรือไม่ อัตราการเปลี่ยนคำตอบที่ต่ำกว่าบ่งชี้ถึงความเสถียรที่มากกว่า

Decider v1.3 เปลี่ยนคำตอบเพียง 0.27% ของคำถามภายใต้การแปลงแต่ละแบบ เทียบกับ 2.69–4.84% สำหรับ Jev 1.14 นอกจากนี้เรายังป้อนอินพุตเดิมซ้ำเพื่อวัดความแปรปรวนในการให้บริการ: Decider v1.3 ไม่มีการเปลี่ยนแปลงเลย ขณะที่ Jev 1.14 เปลี่ยนคำตอบใน 1.88% ของคำถาม

ขยาย

วิธีที่เราใช้ Decider

Decider สร้างขึ้นสำหรับเวิร์กโฟลว์ที่ต้องการการตัดสินใจที่รวดเร็วและมีโครงสร้าง ในส่วนนี้ เราจะสำรวจวิธีใช้ประโยชน์จากโมเดลเหล่านี้เพื่อสร้างผลกระทบที่มีความหมายต่อวิธีการทำงานของเรา ต่อไปนี้คือกรณีที่โดดเด่น

กฎความปลอดภัยที่ปรับปรุงตัวเองได้

ภายในองค์กร เราใช้ Decider เพื่อปรับปรุงนโยบายด้านความปลอดภัยของเราอยู่แล้ว

กิจกรรมของเอเจนต์ของเราจะถูกบันทึกไว้ และมีการตรวจสอบตามกฎหลายชุดเพื่อระบุพฤติกรรมที่เป็นปัญหา แนวทางแบบอิงกฎทำให้เราตรวจสอบเอเจนต์ได้แบบเรียลไทม์โดยเพิ่มเวลาแฝงเพียงเล็กน้อยจนแทบไม่มีผล ในโหมดออฟไลน์ เราใช้ Decider ตรวจดูตัวอย่างจากบันทึกของเอเจนต์เหล่านี้ ในกรณีที่ไม่มีการตั้งค่าสถานะพฤติกรรมที่เป็นปัญหา Decider จะตรวจสอบว่ามีสิ่งใดที่ชุดกฎของเราตรวจไม่พบหรือไม่ และในกรณีที่มีการแจ้งเตือน Decider จะตรวจสอบว่าเป็นการแจ้งเตือนผิดพลาดหรือไม่ บันทึกใดก็ตามที่ชุดกฎของเราทำงานผิดพลาดในกรณีใดกรณีหนึ่งจะถูกส่งไปยังเอเจนต์เพื่อคัดแยก และมีการเสนอวิธีแก้ไขกฎ ซึ่งต้องได้รับการอนุมัติจากสมาชิกทีมความปลอดภัยของเรา

ในหนึ่งวัน Decider อ่านโทเค็น 1 พันล้านโทเค็นจากเซสชันของเอเจนต์ 7,000 เซสชัน และระบุข้อบกพร่องที่นำไปสู่การแก้ไขกฎ 14 รายการ ซึ่ง 6 รายการได้รับการอนุมัติและนำไปใช้จริงภายในสองวัน เมื่อนำไปทดสอบซ้ำกับบันทึกหนึ่งสัปดาห์ การแก้ไขเหล่านี้ลดปริมาณของกฎที่ทำงานหนักที่สุดของเราลง 52% และกฎที่ขยายขอบเขตแล้วตรวจพบการกระทำที่ควรตรวจสอบจริงได้มากขึ้นประมาณ 40%

ขยาย

การตรวจสอบ rollout ของ RL

เมื่อเราทำ post-training โมเดลด้วยการเรียนรู้แบบเสริมกำลัง ตัวชี้วัดแบบรวม เช่น รางวัลสุดท้าย ไม่ได้อธิบายว่าเหตุใด rollout (ความพยายามแต่ละครั้งในการทำงานหนึ่ง) จึงสำเร็จหรือล้มเหลว rollout อาจเสียรางวัลอย่างไม่เป็นธรรมเพราะบริการเครื่องมือหรือแซนด์บ็อกซ์ล้มเหลว หรือได้รับรางวัลที่ไม่สมควรได้หากผู้ประเมินมองข้ามข้อกล่าวอ้างที่ไม่มีหลักฐานรองรับ เช่น ค่าที่แต่งขึ้นซึ่งไม่มีเครื่องมือใดส่งคืน

เราใช้ Decider ตรวจสอบ rollout สำหรับกรณีเหล่านี้ ขั้นแรก โค้ดจะระบุส่วนของ rollout ที่ควรตรวจสอบอย่างใกล้ชิด เช่น การเรียกใช้เครื่องมือที่ล้มเหลวและการให้เหตุผลรอบ ๆ โค้ดที่รันโดยไม่มีข้อผิดพลาด หรือคำตอบสุดท้าย จากนั้น Decider จะตอบคำถามแบบหลายตัวเลือกเกี่ยวกับแต่ละส่วน เช่น สิ่งใดล้มเหลวในขั้นตอนหนึ่ง (บริการเครื่องมือ เว็บไซต์ภายนอก แซนด์บ็อกซ์ harness หรือโค้ดของเอเจนต์เอง) และเอเจนต์ตีความผลลัพธ์ได้ถูกต้องหรือไม่ เรารวมคำถามทั้งหมดเกี่ยวกับส่วนหนึ่ง ๆ ไว้ในคำขอเดียว และจัดเก็บความน่าจะเป็นแทนคำตัดสิน เพื่อให้ปรับเกณฑ์ภายหลังได้โดยไม่ต้องสอบถาม Decider อีกครั้ง ตัวตรวจสอบนี้ทำหน้าที่เพียงสังเกตและวินิจฉัยเท่านั้น โดยจะไม่เปลี่ยนรางวัลหรือหยุดการรันใด ๆ

ขยาย

การกรองคุณภาพหน้าเว็บ

เมื่อรวบรวมข้อมูลหน้าเว็บเพื่อจัดทำดัชนีและให้บริการแก่ผู้ใช้ หน้าเว็บจำนวนมากมีคุณภาพต่ำเกินกว่าจะมีประโยชน์ ซึ่งรวมถึงหน้ากั้นป้องกันบอต CAPTCHA และหน้าข้อผิดพลาด ตลอดจนหน้าเว็บที่โหลดได้อย่างถูกต้องแต่ไม่มีข้อมูลที่เป็นประโยชน์ เช่น สแปม เนื้อหาเติมเพื่อ SEO หรือหน้าที่มีเพียงเมนูนำทาง หน้าคุณภาพต่ำเหล่านี้จำเป็นต้องถูกระบุและกรองออกจากดัชนีของเรา

เมื่อใช้ Decider เราสามารถตัดสินคุณภาพของหน้าเว็บได้ขณะที่ทำการรวบรวมข้อมูล (crawl) หน้าเหล่านั้น ใน forward pass เดียวกัน เรายังทำงานจำแนกประเภทอื่น ๆ อีกชุดหนึ่ง เช่น การระบุโดเมนและกลุ่มเป้าหมายของเนื้อหา และตรวจสอบว่าเนื้อหามีข้อมูลที่เป็นอันตราย ผิดกฎหมาย หรือข้อมูลที่ระบุตัวบุคคลได้หรือไม่ เมื่อเทียบกับการใช้ LLM เป็นผู้ตัดสิน Decider เร็วกว่าและประหยัดกว่าอย่างมาก

ขยาย

นอกเหนือจากการใช้งานภายในเหล่านี้ Decider ยังเหมาะกับเวิร์กโฟลว์ต่าง ๆ ดังต่อไปนี้

การตอบคำถามจากภาพ (Visual QA)

เนื่องจาก Decider อ่านรูปภาพได้ จึงทำหน้าที่เป็นตัวตรวจสอบภาพได้ด้วย โดยตรวจทานการเปลี่ยนแปลงสไตล์ของหน้าเว็บหรือแอปและระบุข้อบกพร่อง Decider สามารถตรวจภาพหน้าจอเพื่อหาข้อความที่ถูกตัด องค์ประกอบที่ซ้อนทับกัน และเลย์เอาต์ที่เสียหายก่อนที่การเปลี่ยนแปลงจะเผยแพร่ หรือตั้งค่าสถานะแผนภูมิที่การออกแบบอาจทำให้ผู้อ่านเข้าใจผิดหรือขัดกับแนวทางแบรนด์

ขยาย

การนำทางในเบราว์เซอร์

เอเจนต์สามารถใช้ Decider สำหรับการตัดสินใจเล็ก ๆ ภายในงานที่ใหญ่กว่าได้ เอเจนต์เบราว์เซอร์สามารถส่งภาพหน้าจอในแต่ละขั้นตอน และรับข้อมูลโดยละเอียดเกี่ยวกับสถานะของหน้าเว็บและผลลัพธ์ที่คาดว่าจะเกิดขึ้นจากการกระทำแต่ละอย่างที่เป็นไปได้

ขยาย

การวางแผนงานวิจัย

คำถามของผู้ใช้อาจมีความซับซ้อนแตกต่างกันอย่างมาก เช่นเดียวกับความลึกของการค้นหาที่ต้องดำเนินการเพื่อหาคำตอบ Decider สามารถประเมินสิ่งนี้ได้ก่อนเริ่มการค้นหา ทำให้ใช้ทรัพยากรกับคำถามง่าย ๆ น้อยลง

ขยาย

เริ่มต้นใช้งาน

Decider ส่งคืนความน่าจะเป็น เกณฑ์การตัดสินใจที่เหมาะสมขึ้นอยู่กับแอปพลิเคชัน ความถี่ของป้ายกำกับและต้นทุนสัมพัทธ์ของผลบวกลวงและผลลบลวงแตกต่างกันไปตามกรณีการใช้งาน ดังนั้นเราจึงแนะนำให้ผู้ใช้ปรับเกณฑ์บนชุดข้อมูลพัฒนาขนาดเล็กที่มีป้ายกำกับและเป็นตัวแทนที่ดี แทนที่จะสันนิษฐานว่าค่าตัดที่ตายตัวจะใช้ได้ดีเท่ากันในทุกงาน

เราแนะนำให้ใช้ Decider v1.3 สำหรับการตัดสินที่ต้องอาศัยความละเอียดอ่อน รูบริกที่มีรายละเอียด และเวิร์กโฟลว์ที่ข้อผิดพลาดมีต้นทุนสูง เลือก Decider Flash v1.3 สำหรับการกำหนดเส้นทาง การติดป้ายกำกับ และการกรองในปริมาณมาก ซึ่งมีเวลาแฝงและต้นทุนเป็นข้อจำกัดหลัก ประเมินโมเดลทั้งสองด้วยตัวอย่างที่เป็นตัวแทนจากเวิร์กโหลดของคุณ จากนั้นเลือกโมเดลที่ตรงตามข้อกำหนดด้านคุณภาพ เวลาแฝง และงบประมาณของคุณ

โมเดลทั้งสองพร้อมใช้งานในรูปแบบน้ำหนักที่ดาวน์โหลดได้บน Hugging Face ภายใต้สัญญาอนุญาต Apache รวมถึงผ่าน OpenRouter และ Perplexity Decisions API

การอ้างอิง

@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}
}