การบีบอัดบริบทที่รับรู้การสืบค้นเพื่อให้ได้ข้อความตัดตอนที่ดีขึ้น

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

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

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

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

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

ขยาย

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

ดังนั้น ข้อความตัดตอนที่ดีควรทำ 3 สิ่งดังนี้:

ส่งเสริมความแม่นยำโดยการนำเสนอหลักฐานที่แม่นยำซึ่งจำเป็นสำหรับการอ้างอิงคำตอบของโมเดล

ลดความหน่วงและต้นทุนโดยการลบ1บริบทที่ไม่เกี่ยวข้องออกก่อนการเรียกใช้งาน LLM

รับประกันความสามารถในการตรวจสอบย้อนกลับโดยรักษากลุ่มคำอ้างอิงและความสมบูรณ์ของข้อความต้นฉบับไว้

เดือนนี้ เราได้ปรับ ใช้งานตัวสร้างข้อความตัดตอนรุ่นใหม่ล่าสุดภายในแอปพลิเคชันและ API Platform ของเรา หัวใจสำคัญของโมดูลนี้คือโมเดลการบีบอัดบริบทที่รับรู้การสืบค้น (query-aware context compression model) ซึ่งทำหน้าที่ตัดสินใจสำหรับแต่ละการสืบค้นและผลลัพธ์ที่เป็นไปได้ ว่าช่วงข้อความย่อยใดที่ควรได้รับการเก็บรักษาไว้ บทความนี้อธิบายแนวทางของเราในการสร้างและฝึกฝนโมเดลเพื่อให้บรรลุประสิทธิภาพที่ดีที่สุดในระดับเดียวกันสำหรับงานที่สำคัญนี้

ข้อความตัดตอนในฐานะการบีบอัดที่รับรู้การสืบค้น

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

วิธีการสร้างข้อความตัดตอนแบ่งออกเป็น 2 กลุ่มใหญ่ๆ กลุ่มแรกคือแบบอิงการเลือก (selection-based): ค้นหาหน้าต่าง ชิ้นส่วน ประโยค หรือย่อหน้าที่เกี่ยวข้อง แล้วส่งต่อไปยังขั้นตอนถัดไป กลุ่มที่สองคือแบบอิงการสร้าง (generation-based): ขอให้โมเดลเขียนบทสรุปที่เน้นการสืบค้นจากหน้าเว็บนั้น

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

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

ตัวอย่างเช่น ลองพิจารณาการสืบค้นและผลลัพธ์ที่ดึงออกมานี้:

ขยาย

เอาต์พุตของโมเดลที่เป็นไปได้คือการเลือกประโยคที่ทำตัวหนา: “ใน Comet ผู้ช่วยสามารถ ...”

แนวทางของเราดำเนินตามแนวคิดกว้างๆ เช่นเดียวกับงานบีบอัดบริบทก่อนหน้า เช่น FliCo, Provence และ LooComp ซึ่งได้รับการปรับ Adaptation สำหรับการสร้างข้อความตัดตอนในระบบค้นหาสำหรับการใช้งานจริง สิ่งสำคัญคือ โมเดลนี้ทำงานเป็นขั้นตอนความแม่นยำหลังจากขั้นตอนการดึงข้อมูลดิบของเรา ดังที่ได้กล่าวไว้ในบทความวิจัย Perplexity ก่อนหน้านี้ของเรา Introducing the Perplexity Search API เราออกแบบระบบการดึงข้อมูลของเราให้ทำงานในระดับย่อยของเอกสาร (sub-document) หรือระดับข้อความตัดตอน (snippet) ตามธรรมชาติ ซึ่งช่วยให้เราสามารถสร้างความสมดุลระหว่างความแม่นยำและการเรียกคืน (precision and recall) ได้ค่อนข้างดีอยู่แล้ว การแนะนำโมเดลการบีบอัดบริบทที่รับรู้การสืบค้นช่วยผลักดันพรมแดนพาเรโต (Pareto frontier) ของความแม่นยำและการเรียกคืนให้กว้างขึ้นไปอีก

การสร้างและการฝึกฝนโมเดลการบีบอัดบริบท

เราพัฒนาโมเดลของเราโดยคำนึงถึงข้อพิจารณาหลัก 3 ประการ ได้แก่ ความเข้าใจร่วมกันเกี่ยวกับการสืบค้นและบริบท การเลือกในระดับประโยคที่มีความละเอียดย่อย และประสิทธิภาพเพื่อให้พอดีกับงบประมาณด้านความหน่วงที่จำกัดมากๆ

สถาปัตยกรรมของโมเดล

เราใช้โมเดล pplx-diffusion เป็นแบ็คโบน (backbone) นี่คือตระกูลโมเดลเดียวกันกับที่อยู่เบื้องหลัง pplx-embed-v1 และทั้งงานวิชาการก่อนหน้าของเรา Diffusion-Pretrained Dense and Contextual Embeddings รวมถึงเบนช์มาร์กสำหรับการใช้งานจริงของเรา ยืนยันว่ามันเป็นตัวเข้ารหัสแบบสองทิศทาง (bidirectional encoder) ที่แข็งแกร่งสำหรับคู่การสืบค้น-บริบท คุณสมบัติหลักประการหนึ่งจากตระกูลโมเดลนี้คือบริบทแบบสองทิศทาง: การแทนค่าโทเค็นแต่ละตัวสามารถให้ความสนใจ (attend) ต่อการสืบค้นทั้งหมดและบริบทของผู้สมัครทั้งหมดได้ ก่อนที่โมเดลจะตัดสินใจว่าสิ่งใดควรเก็บรักษาไว้

บนแบ็คโบนนี้ เราได้ฝึกฝนส่วนหัวการบีบอัดที่มีน้ำหนักเบา (lightweight compression head) ซึ่งทำหน้าที่ทำนายว่าส่วนใดของบริบทที่ควรเก็บรักษาไว้ เนื่องจากไม่มีการสร้างข้อความใหม่ การทำนายเหล่านี้จึงเกิดขึ้นแบบคู่ขนานทั่วทั้งบริบท ในเวลาที่ให้บริการ (serving time) เอนจิ้นข้อความตัดตอนจะรวบรวมการทำนายเหล่านี้ในระดับประโยค ใช้เกณฑ์ (threshold) และตัดแต่งผลลัพธ์ให้ตรงกับงบประมาณโทเค็นที่ร้องขอ

ท่อส่งการกำกับดูแล (Supervision pipeline)

การฝึกฝนตัวบีบอัดนี้จำเป็นต้องมีการกำกับดูแลในระดับความละเอียดที่ถูกต้อง ป้ายกำกับความเกี่ยวข้องในระดับเอกสารไม่เหมาะสมอย่างยิ่งสำหรับงานบีบอัดแบบสกัดของเรา เพื่อสร้างข้อมูลที่มีความละเอียดย่อยเพียงพอสำหรับการเรียนรู้แบบมีผู้สอน (supervised learning) เราจึงได้สร้างท่อส่งการติดป้ายกำกับช่วงข้อความ (span labeling pipeline) ซึ่งทำหน้าที่ทำ1เครื่องหมายช่วงหลักฐานที่เกี่ยวข้องกับการสืบค้น รวมถึงช่วงข้อมูลรบกวนที่ควรถูกลบออก

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

จากนั้นเราได้จับคู่ช่วงข้อความที่ส่งคืนกลับไปยังข้อความต้นฉบับ ไม่น่าแปลกใจเลยที่เอาต์พุตส่วนใหญ่ของผู้ประเมินเป็นการคัดลอกที่ตรงกันอยู่แล้ว: การจับคู่สตริงแบบง่าย (naive string matching) สามารถกู้คืนช่วงข้อความได้ 98% การเพิ่มขั้นตอนการจับคู่แบบใช้เร็กซ์ (regex-based matching pass) อย่างง่ายทำให้การกู้คืนช่วงข้อความเพิ่มขึ้นเป็น 100% สิ่งนี้ทำให้เราได้ช่วงข้อความที่มีความละเอียดและเชื่อถือได้ ซึ่งสามารถแปลงเป็นการกำกับดูแลการเก็บรักษา/การทิ้งในระดับโทเค็นได้

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

โดยใช้ท่อส่งนี้ เราได้ติดป้ายกำกับคู่การสืบค้น-เอกสารจำนวน 750k คู่ และใช้ช่วงข้อความที่ได้มาเพื่อฝึกฝนส่วนหัวการบีบอัดด้วยไบนารีครอสโทรปี้ (binary cross-entropy) กระบวนการนี้ช่วยให้โมเดลการบีบอัดที่รับรู้การสืบค้นของเราสามารถรักษาข้อความต้นฉบับไว้ได้ในขณะที่ลบบริบทที่มีแนวโน้มว่าจะไม่ช่วยให้โมเดลในลำดับถัดไปให้บริการตามคำขอของผู้ใช้

การรับประกันความหน่วงแบบเรียลไทม์

การบีบอัดบริบทจะอยู่ก่อนโมเดลในลำดับถัดไป ทำให้เป็นปฏิบัติการแบบบล็อก (blocking operation) ยิ่งไปกว่านั้น การบีบอัดแต่ละครั้งยังขึ้นอยู่กับการสืบค้น ดังนั้น เส้นทางออนไลน์จึงต้องให้คะแนนคู่การสืบค้น-บริบทสำหรับเอกสารผู้สมัครแต่ละฉบับภายในขอบเขตความหน่วงที่กำหนดอย่างเข้มงวด โมเดลการบีบอัดที่ทำงานช้าจะส่งผลเสียต่อตัวเอง เนื่องจากประโยชน์ด้านความหน่วงจากความแม่นยำที่สูงขึ้นจะถูกหักล้างด้วยความหน่วงจากการบีบอัดเอง ในขณะเดียวกัน โมเดลการบีบอัดที่มีความฉลาดน้อยกว่าจะทำการตัดสินใจได้แย่ลงในเรื่องสิ่งที่ควรตัดทิ้งและสิ่งที่ควรเก็บรักษาไว้

คำถามในทางปฏิบัติคือเราสามารถถอดความจุของโมเดลออกได้มากแค่ไหนอย่างปลอดภัยก่อนที่คุณภาพการบีบอัดจะเริ่มเสื่อมถอย เราเปรียบเทียบแบ็คโบน pplx-diffusion 28 เลเยอร์เต็มรูปแบบ กับตัวเลือกย่อย 11 เลเยอร์และ 17 เลเยอร์ที่สร้างขึ้นจากการตัดทอนเลเยอร์ (layer pruning) และมุ่งเป้าไปที่เส้นทางการค้นหา สำหรับแต่ละตัว เรากวาดผ่านเกณฑ์การบีบอัดและวัดปริมาณสองค่า ได้แก่ จำนวนเฉลี่ยของโทเค็นบริบทที่ส่งไปยังขั้นตอนถัดไปต่อหนึ่งการสืบค้น และสัดส่วนของหลักฐานที่เป็นประโยชน์ที่ถูกเก็บรักษาไว้หลังจากการบีบอัด

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

เพื่อปิดช่องว่างดังกล่าว เราใช้การกลั่นความรู้ในระดับโทเค็น (token-level knowledge distillation) แนวทางของเราเป็นไปตามปกติ: เราเพิ่มข้อกำหนดการสูญเสียมาตรฐาน (standard loss) ด้วยข้อกำหนดซอฟต์ครอสโทรปี้ (soft cross-entropy term) สำหรับการทำนายของโมเดลครู (teacher model) ซึ่งถ่วงน้ำหนักด้วยสัมประสิทธิ์การกลั่น (distillation coefficient) สิ่งนี้เพียงพอที่จะทำให้โมเดลนักเรียน (student model) มีความเท่าเทียมกัน ทำให้เราสามารถเปลี่ยนมาใช้โมเดล 17 เลเยอร์ที่ผ่านการกลั่นในการผลิตได้อย่างเต็มรูปแบบ โมเดลการผลิตใหม่นี้ช่วยลดความหน่วงในการอนุมาน (inference latency) ลง 35-40% และลดการประมวลผล GPU รวมลง 40-45% โดยไม่มีคุณภาพลดลงเมื่อเทียบกับครู 28 เลเยอร์ ความหน่วงในการผลิตอยู่ที่ต่ำกว่า 20 มิลลิวินาที (p99): น้อยพอที่จะเพิ่มเข้าไปในเส้นทางการให้บริการในขณะที่ลดจำนวนโทเค็นทั้งหมดที่ส่งไปยังโมเดลคำตอบได้อย่างมาก

ขยาย

คุณภาพและประสิทธิภาพของโทเค็น

เราใช้ Agent API ของ Perplexity เป็นศูนย์ทดสอบเพื่อวิเคราะห์ประสิทธิภาพของการบีบอัดบริบท เราประเมินพรีเซ็ต Agent API 3 รายการ:

พรีเซ็ตบริบท “ต่ำ” (low) ซึ่งจำกัดงบประมาณโทเค็นสำหรับแต่ละชุดผลลัพธ์ไว้ที่ 1000 โทเค็น

พรีเซ็ตบริบท “ปานกลาง” (medium) ซึ่งจำกัดงบประมาณโทเค็นสำหรับแต่ละชุดผลลัพธ์ไว้ที่ 4000 โทเค็น

พรีเซ็ตบริบท “สูง” (high) ซึ่งจำกัดงบประมาณโทเค็นสำหรับแต่ละชุดผลลัพธ์ไว้ที่ 10000 โทเค็น

ทั้งการตั้งค่ามาตรฐาน แบบไม่มีการบีบอัด และการตั้งค่าการบีบอัด ได้รับการกำหนดค่าให้เคารส่งบประมาณโทเค็นเหล่านี้

การค้นหาแบบหลายขั้นตอนของเอเจนต์ (BrowseComp)

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

มิติข้อมูลสองมิติที่สนใจคือความแม่นยำของเบนช์มาร์กและการใช้งานโทเค็น สิ่งสำคัญคือ เราวัดการใช้งานโทเค็นในระดับการสืบค้นแทนที่จะเป็นระดับขั้นตอนแต่ละขั้นตอน เพื่อวัดภาระโทเค็นจริงที่เกิดขึ้นตลอดวงจรชีวิตของคำขอ รูปที่ 3 แสดงพรมแดน “คะแนน-โทเค็น” (score-token) ซึ่งเป็นการเปรียบเทียบระหว่างคะแนนความแม่นยำกับการใช้งานโทเค็น

ขยาย

การบีบอัดมอบพรมแดนพาเรโตแบบใหม่ในทุกด้าน สำหรับแต่ละการตั้งค่า การนำการบีบอัดมาใช้ช่วยลดการใช้งานโทเค็นในระดับการสืบค้นลงตั้งแต่ 10% ถึง 70% โดยที่คะแนนความแม่นยำเพิ่มขึ้นระหว่าง 4 ถึง 4.81 เปอร์เซ็นต์พอยต์ การนำการบีบอัดมาใช้ช่วยให้แม้แต่พรีเซ็ต “ต่ำ” ของเราก็สามารถทำผลงานได้เหนือกว่าพรีเซ็ต “สูง” แบบไม่มีการบีบอัด พร้อมทั้งลดการใช้งานโทเค็นลงมากกว่าสามเท่า

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

SimpleQA: ความเป็นจริงเชิงข้อเท็จจริงแบบขั้นตอนเดียว

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

เช่นเดียวกับก่อนหน้านี้ เราพล็อตกราฟความแม่นยำเทียบกับจำนวนโทเค็นรวมเฉลี่ยต่อหนึ่งงานโดยใช้พรอมต์ผู้ประเมินมาตรฐาน รูปที่ 4 แสดงพรมแดนคะแนน-โทเค็นในการตั้งค่าแบบขั้นตอนเดียวนี้น แม้ว่าขนาดของผลกระทบจะถูกบีบอัดมากกว่าในการตั้งค่าแบบขั้นตอนเดียว แต่เราก็สังเกตอีกครั้งว่าการบีบอัดช่วยปรับปรุงทั้งความแม่นยำและประสิทธิภาพไปพร้อมๆ กันในทุกพรีเซ็ต จึงเป็นการแนะนำพรมแดนพาเรโตแบบใหม่ เมื่อเปิดใช้งานการบีบอัด พรีเซ็ตปานกลางจะบรรลุความแม่นยำ 95% ด้วยค่าเฉลี่ยเพียง 200 โทเค็นต่อเอกสาร เมื่อพิจารณาจากความยาวเอกสารเฉลี่ยที่มากกว่า 10,000 โทเค็น สิ่งนี้แสดงถึงประสิทธิภาพระดับพรมแดนที่อัตราส่วนการบีบอัดมากกว่า 50 เท่า

ขยาย

อะไรคือสิ่งที่อยู่ในข้อความตัดตอน?

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

สำคัญ (Vital): หลักฐานที่จำเป็นสำหรับการตอบคำถามของผู้ใช้

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

โฆษณา (Ads): โฆษณาที่ไม่เกี่ยวข้องซึ่งเบี่ยงเบนความสนใจจากการตอบคำถามของผู้ใช้

เมทาดาทา (Metadata): เมทาดาถเกี่ยวกับเนื้อหาของเอกสาร

UI และการนำทาง (UI & navigation): องค์ประกอบสำหรับการแสดงผลส่วนหน้า (frontend) และการนำทาง

ข้อมูลซ้ำ (Duplicate): การทำซ้ำของข้อมูลที่รวมไว้ก่อนหน้านี้

การประเมินของเราดำเนินการกับการสืบค้นจากโดเมนผสม 1,000 รายการจากชุดข้อมูลการตรวจสอบความถูกต้องของเรา โดยเปรียบเทียบสแต็กการผลิตกับเบสไลน์ที่เหมือนกันทุกประการแต่ปิดการใช้งานการบีบอัด ดังแสดงในรูปที่ 5 การบีบอัดช่วยเพิ่มสัดส่วนของโทเค็นสำคัญต่อข้อความตัดตอนขึ้นเฉลี่ย 63% เมื่อเทียบกับเบสไลน์ที่ไม่มีการบีบอัด เราสังเกตเห็นการลดลงที่สอดคล้องกัน 29% ในโทเค็นที่ไม่เกี่ยวข้อง โดยมีการลดลงอย่างมากเป็นพิเศษในส่วนของ UI/การนำทาง (-58%), เมทาดาทา (-46%) และโฆษณา (-43%) ผลลัพธ์เหล่านี้ยืนยันกลไกสำหรับการปรับปรุงคุณภาพต่อประสิทธิภาพที่กล่าวถึงข้างต้น: การบีบอัดช่วยปรับปรุงประสิทธิภาพในทั้งสองมิติด้วยการเพิ่มอัตราส่วนสัญญาณต่อสัญญาณรบกวนของข้อความตัดตอนแต่ละอันอย่างมาก

ขยาย

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

ขยาย

บทสรุป

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

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

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

เอกสารอ้างอิง

N. Chirkova, T. Formal, V. Nikoulina, and S. Clinchant. Provence: Efficient and Robust Context Pruning for Retrieval-Augmented Generation, 2025. Accepted to ICLR 2025. arXiv:2501.16214.

T. Do, D. P. Tran, A. Vo, S. K. Kim, and D. Kim. LooComp: Leverage Leave-One-Out Strategy to Encoder-only Transformer for Efficient Query-Aware Context Compression, 2026. arXiv:2603.09222.

S. Eslami, M. Gaiduk, M. Krimmel, L. Milliken, B. Wang, and D. Bykov. Diffusion-Pretrained Dense and Contextual Embeddings, 2026. arXiv:2602.11151.

Z. Wang, J. Araki, Z. Jiang, M. R. Parvez, and G. Neubig. Learning to Filter Context for Retrieval-Augmented Generation, 2023. arXiv:2311.08377.

การอ้างอิง

@online{perplexity2026QueryAwareContextCompressionForBetterSnippets,
  author = {{Perplexity} and Bo Wang and Hao Zhang and Ismail Gadzhiev and Kirill Priemko and Markus Krimmel and Nandor Licker and Vitalii Polshkov and Sarah Eslami and Louis Milliken and Maksim Gaiduk and Nikita Kireev and Jerry Ma},
  title = {{Query-aware context compression for better snippets}},
  date = {2026-05-14},
  url = {https://www.perplexity.ai/hub/blog/query-aware-context-compression-for-better-snippets}
}