การปรับปรุงระดับความพยายามทุกระดับของ Agent API

ระดับความพยายามใน Perplexity Agent API ช่วยให้นักพัฒนาเลือกความสมดุลระหว่างต้นทุน ความเร็ว และความลึกของการวิจัยสำหรับแต่ละงานได้ วันนี้ ระดับความพยายามทุกระดับมีต้นทุนต่อคำค้นหาที่ต่ำลง โดยคุณภาพการวิจัยสูงขึ้นหรือเท่าเดิม ระดับ ultra ใหม่พร้อมให้ใช้งานแล้วสำหรับการวิจัยที่ครอบคลุมกว้างขวางและรอบด้านที่สุด คำขอใดก็ตามที่เลือกระดับด้วยชื่อ เช่น effort="fast", จะได้รับการกำหนดค่าที่อัปเดตแล้วโดยอัตโนมัติ

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

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

ประสิทธิภาพของ medium บน BrowseComp และ DSQA เพิ่มขึ้นจาก 55% เป็น 77% ขณะที่ต้นทุนลดลงเกือบ 90% BrowseComp และ DSQA เป็นเบนช์มาร์กการวิจัยสาธารณะ ส่วน WANDR เป็นเบนช์มาร์กของ Perplexity สำหรับงานวิจัยขนาดยาวที่เกี่ยวข้องกับหลายเอนทิตี xhigh ทำงานแบบเอเจนต์ เช่น การรันโค้ดในแซนด์บ็อกซ์ การรักษาลูปการใช้เครื่องมือที่ยาวต่อเนื่อง และการทำงานกับแหล่งข้อมูลจำนวนมากพร้อมกัน xhigh รักษาคะแนน WANDR ไว้ที่ 76.5% ขณะที่มีต้นทุนประมาณ 25% ของการกำหนดค่าเมื่อเดือนสิงหาคม 2026

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

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

การแก้ปัญหาแต่ละข้อเหล่านี้ช่วยลดต้นทุนของระดับความพยายามแต่ละระดับโดยไม่ลดประสิทธิภาพ

ระดับความพยายามแต่ละระดับมีงบประมาณการวิจัยที่กำหนดไว้ตายตัว ซึ่งประกอบด้วยสามส่วน:

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

งบประมาณคือจุดแลกเปลี่ยนสำคัญ ยิ่งมีขั้นตอนมากขึ้นก็ยิ่งได้คำตอบที่ดีขึ้น และทุกขั้นตอนก็มีต้นทุน เมื่อใช้ openai/gpt-6-luna การเพิ่มขีดจำกัดขั้นตอนจาก 1 เป็น 15 ช่วยเพิ่มความแม่นยำบน BrowseComp + DSQA จาก 41% เป็น 80% ขณะที่ต้นทุนต่อคำค้นหาเพิ่มขึ้นจาก $0.0017 เป็น $0.0152 หรือคิดเป็นต้นทุนราว 9 เท่าเพื่อคะแนนที่สูงขึ้นราว 2 เท่า

ขีดจำกัดขั้นตอนเพียงอย่างเดียวไม่สามารถควบคุมต้นทุนการวิจัยได้ ภายใต้งบประมาณห้าขั้นตอนเท่ากัน openai/gpt-6.1-terra เรียกใช้เครื่องมือมากกว่า openai/gpt-6-luna เนื่องจากโมเดลที่มีความสามารถสูงกว่ามักเรียกใช้หลายครั้งในขั้นตอนเดียว ระดับความพยายามจึงจำกัดทั้งการเรียกใช้เครื่องมือและจำนวนขั้นตอน สำหรับโมเดลเหล่านี้ ขีดจำกัดการเรียกใช้เครื่องมือมีความสำคัญพอๆ กับขีดจำกัดขั้นตอน

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

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

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

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

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

ทุกหน้าที่เอเจนต์อ่านจะเพิ่มเข้าไปในบริบท และเอเจนต์ต้องแบกบริบทนั้นไปในทุกขั้นตอนถัดไป หน้าเว็บมีข้อมูลที่ไม่เกี่ยวข้องกับคำถาม เช่น ส่วนนำทาง ข้อความสำเร็จรูป (boilerplate) และเนื้อหาอื่นๆ

แทนที่จะส่งทั้งหน้าให้เอเจนต์ fetch_url จะรันขั้นตอนการสกัดข้อมูลก่อน ข้อความในหน้าจะถูกส่งไปยังโมเดลที่เล็กกว่าพร้อมกับงานปัจจุบันของเอเจนต์ โมเดลจะส่งคืนเฉพาะข้อความส่วนที่เกี่ยวข้อง โดยยกมาแบบคำต่อคำเพื่อให้เอเจนต์อ้างอิงได้ ในระหว่างการประเมิน หน้าขนาด 5,561 โทเค็นถูกลดเหลือ 293 โทเค็น ทำให้มีพื้นที่ว่างสำหรับบริบทที่เกี่ยวข้องเพิ่มเติม

การใช้ fetch_url ร่วมกับการสกัดข้อมูล ที่ระดับความพยายาม high ช่วยลดโทเค็นอินพุตต่อคำค้นหาได้ประมาณ 50% การสกัดข้อมูลยังช่วยปรับปรุงประสิทธิภาพในเบนช์มาร์ก โดยทำได้ 88.0% ที่ $0.073 ต่อคำค้นหา เทียบกับ 83.5% ที่ $0.094 เมื่อไม่ใช้การสกัดข้อมูล

การค้นหาเว็บเป็นหัวใจสำคัญของทุกคำขอการวิจัยของเอเจนต์ โดยมีการเปลี่ยนแปลงสามประการในวิธีที่เอเจนต์ค้นหา:

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

เอนจินสนิปเพ็ตใหม่: ผลการค้นหาจะได้รับสนิปเพ็ตที่ตรงกับคำค้นหามากขึ้น เอเจนต์จึงไม่ต้องรับภาระจากข้อความที่ไม่เกี่ยวข้องมากเกินไป
การค้นหาแบบเร็ว: ด้วยราคา $1.00 ต่อ 1K คำขอ Fast Search ช่วยลดทั้งต้นทุนและเวลาแฝงของการเรียกค้นหาแต่ละครั้ง

ทีม Perplexity Search ปรับปรุงคุณภาพการดึงข้อมูลอย่างต่อเนื่องในงานหลากหลายประเภท การอัปเดตล่าสุดช่วยให้ผลลัพธ์ดีขึ้นในเนื้อหาด้านโค้ด เอกสารสำหรับนักพัฒนา หน้าอ้างอิง กฎหมาย และกฎระเบียบ

บางงานต้องรันการค้นหาจำนวนมากพร้อมกัน ขณะที่บางงานต้องอ่านเอกสารขนาดยาวเพียงไม่กี่ฉบับอย่างละเอียด

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

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

การรันเบนช์มาร์ก WANDR ด้านล่างแสดงให้เห็นเอเจนต์ที่เลือกเวิร์กโฟลว์ที่ถูกต้องสำหรับงานที่เจาะจง คำแนะนำสำหรับ wide-search และ fanout ถูกโหลดในทุกงาน ซึ่งสะท้อนถึงความจำเป็นในการตรวจสอบหลายเอนทิตี ส่วน people-search ถูกโหลดในงานเพียง 6% และเฉพาะเมื่อคำถามเกี่ยวข้องกับบุคคลเท่านั้น

เมื่อทดสอบงาน WANDR อีกงานหนึ่ง เอเจนต์ได้โหลด Skill people-search พร้อมรูปแบบ fanout เพื่อค้นหาวิศวกรด้าน inference ในลอนดอน เอเจนต์ขยายคำที่เกี่ยวกับตำแหน่งงาน 39 คำเป็นคำค้นหา 117 รายการ แล้วรวมผลลัพธ์รอบแรกเป็นโปรไฟล์ที่ไม่ซ้ำกัน 43 รายการเพื่อคัดกรองต่อ Skill people-search ช่วยชี้นำเอเจนต์ตลอดการขยายนี้โดยไม่เพิ่มบริบทที่ไม่เกี่ยวข้อง ข้อความที่ตัดตอนมาด้านล่างดัดแปลงมาจากสคริปต์ของเอเจนต์ ส่วนชื่อฟังก์ชันตัวช่วยเป็นเพียงตัวอย่างประกอบ

code1

text

Python

# roles contains the 39 role variants selected by the agent.
queries = []
for role in roles:
    queries.extend([
        {"query": f"Google DeepMind {role} London"},
        {"query": f"Google {role} London"},
        {"query": role, "company": "Google", "location": "London"},
    ])

results = pplx_sdk.search.people_many(
    queries, limit_per_query=50, concurrency=8
)

profiles = {}
for result in results:
    if not result.ok:
        continue
    for profile in result.result:
        if "linkedin.com/in/" not in profile.url:
            continue
        url = profile.url.split("?")[0].rstrip("/")
        previous = profiles.get(url, {})
        if url not in profiles or len(profile.summary or "") > len(
            previous.get("summary") or ""
        ):
            profiles[url] = {
                "url": url,
                "title": profile.title,
                "summary": profile.summary,
            }

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

ในงาน WANDR อีกงานหนึ่ง เอเจนต์ต้องคัดกรองโปรไฟล์ของวิศวกร 188 คน เอเจนต์จึงโหลดรูปแบบเช็กพอยต์เพื่อบันทึกผลลัพธ์แต่ละรายการระหว่างทำงาน รอบแรกดึงโปรไฟล์ได้ 160 รายการแต่ล้มเหลว 28 รายการ เมื่อเอเจนต์รันสคริปต์อีกครั้ง ก็ข้ามโปรไฟล์ที่บันทึกไว้แล้วและลองใหม่เฉพาะ 28 รายการที่เหลือ หากไม่มีเช็กพอยต์ ระเบียนที่ผิดพลาดเพียงรายการเดียวจะหมายถึงต้องดึงข้อมูลทั้ง 188 รายการใหม่อีกครั้งตัวอย่างโค้ด Python ที่ตัดตอนและดัดแปลงแล้ว โดยละเว้นหน้าอินพุต คำสั่งคัดกรอง สคีมา และการนำเข้า (imports) ส่วนชื่อฟังก์ชันตัวช่วยเป็นเพียงตัวอย่างประกอบ

code 2

text

Python

checkpoint = Checkpoint("research/profile-screening")
config = instruction + json.dumps(schema)
config_id = hashlib.md5(config.encode()).hexdigest()[:6]

def checkpoint_key(page):
    url_id = hashlib.md5(page["url_in"].encode()).hexdigest()[:10]
    return config_id + url_id

pending = [
    page for page in pages if not checkpoint.has(checkpoint_key(page))
]
for offset in range(0, len(pending), 20):
    batch = pending[offset : offset + 20]
    inputs = [
        json.dumps({
            "url": page["url_in"], "content": page["content"][:30_000]
        })
        for page in batch
    ]
    results = pplx_sdk.llm.extract_many(
        inputs,
        instruction=instruction,
        output_schema=schema,
        chunk_size=5,
        concurrency=4,
    )
    for page, result in zip(batch, results):
        if not result.ok or result.result.error:
            continue
        checkpoint.record(
            checkpoint_key(page),
            [{"url": page["url_in"], **result.result.result}],
        )

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

ไม่ใช่ทุกการทดสอบที่ทำให้คุณภาพและประสิทธิภาพดีขึ้น มีการประเมินการโหลด Skill ทั้งหมดไว้ล่วงหน้าให้เอเจนต์ก่อนเริ่มงาน บน BrowseComp และ DSQA การโหลดล่วงหน้าทำให้ต้นทุนเพิ่มขึ้น 13% บน WANDR ซึ่งเส้นทางการวิจัยที่ยาวกว่าทำให้เนื้อหาที่ดึงมามีสัดส่วนในโทเค็นอินพุตมากขึ้น การโหลดล่วงหน้ายังทำให้คะแนนลดลงด้วย ผลลัพธ์เหล่านี้สนับสนุนให้ใช้การเปิดเผยข้อมูลแบบค่อยเป็นค่อยไป (progressive disclosure) ต่อไป

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

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

เบนช์มาร์กสาธารณะมีประโยชน์ แต่คะแนนจากเบนช์มาร์กเหล่านี้ไม่ได้สะท้อนผลลัพธ์ในงานจริงเสมอไป ตัวอย่างเช่น แผนภูมิด้านล่างแสดงโมเดลตัวเลือกที่ทำคะแนนบน BrowseComp ได้สูงกว่าค่าพื้นฐาน 13.3 คะแนน แต่กลับได้คะแนนต่ำกว่าค่าพื้นฐานที่สอดคล้องกันอยู่มากในงานวิจัยภายในด้านองค์กร กฎหมาย และการเงิน

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

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

Agent API รองรับบทบาทเอเจนต์ที่กำหนดไว้ล่วงหน้า และผู้ประสานงานสามารถสร้างเอเจนต์ลูกพร้อมคำสั่งที่กำหนดเองได้

ระดับความพยายาม ultra จะรันเอเจนต์สามตัวคู่ขนานกันในงานเดียว เอเจนต์แต่ละตัวจะวิจัยทั้งงานอย่างอิสระ ทำให้ได้หลักฐานที่แตกต่างกัน จากนั้นเอเจนต์ตัวที่สี่จะรวมสิ่งที่ค้นพบ ตัดส่วนที่ซ้ำกันออก และเขียนคำตอบสุดท้าย

บน WANDR ultra ทำคะแนนได้ 85.9% ที่ $21.71 ต่องาน ซึ่งเป็นคะแนนสูงสุดในบรรดาการกำหนดค่าที่ทดสอบ

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

ระดับความพยายามแต่ละระดับจะพัฒนาต่อไปเรื่อยๆ เมื่อโมเดลและการกำหนดค่าใหม่ๆ พิสูจน์ตัวเองในการประเมิน การเรียกระดับด้วยชื่อจะได้รับการปรับปรุงเหล่านั้นโดยอัตโนมัติ ส่วนการปักหมุดเวอร์ชันจะคงการกำหนดค่าไว้ตามเดิม

ลองใช้ Agent API และเปรียบเทียบระดับความพยายามกับเวิร์กโหลดของคุณเอง ดูรายละเอียดของระดับความพยายามได้ในเอกสารเรื่อง effort ของ Agent API

ต้นทุนของการวิจัย

การควบคุมงบประมาณการวิจัย

การจัดการบริบท

การบีบอัดบริบท

ดึงเฉพาะสิ่งที่สำคัญ

การค้นหาเว็บแบบมุ่งเป้า

การเลือกเวิร์กโฟลว์ที่ถูกต้อง

การเลือกโมเดล

การขยายขนาดด้วยหลายเอเจนต์

ก้าวต่อไป