การออกแบบสถาปัตยกรรมและการประเมิน AI-first Search API
การสร้าง Search API ที่ปรับขนาดได้ซึ่งรองรับคำค้นหา 200 ล้านครั้งต่อวันโดยใช้การดึงข้อมูลแบบไฮบริดและการคัดสรรบริบทอัจฉริยะสำหรับโมเดล AI
การสร้าง Search API ที่สามารถปรับขนาดได้และขับเคลื่อนด้วย AI ถือเป็นความท้าทายด้านการวิจัยที่มีเอกลักษณ์เฉพาะตัว ณ จุดตัดของการดึงข้อมูล AI และการออกแบบระบบ API ค้นหาต่างจากบริการทั่วไปที่ทำงานบนข้อมูลจำกัด ตรงที่จะต้องทำดัชนีเอกสารนับพันล้านฉบับอย่างต่อเนื่อง ทำความเข้าใจเจตนาของผู้ใช้ข้ามภาษาและโดเมน และแสดงผลลัพธ์ที่เกี่ยวข้องภายในไม่กี่มิลลิวินาที ในยุคของ AI agent นั้น API ค้นหาจะต้องคัดสรร บริบท ที่ให้กับโมเดลของนักพัฒนาอย่างพิถีพิถันด้วย เพื่อให้มั่นใจว่าโมเดลเหล่านั้นทำงานได้อย่างเต็มประสิทธิภาพและรวมข้อมูลที่มีความแม่นยำสูงสุด วิศวกรรมบริบทที่มีประสิทธิภาพกำหนดให้ API ไม่เพียงแต่ต้องจับความเกี่ยวข้องในระดับเอกสารเท่านั้น แต่ยังต้องปฏิบัติต่อส่วนต่างๆ และช่วงเนื้อหาของเอกสารในฐานะหน่วยหลักที่มีความสำคัญในตัวเองด้วย
ในบทความนี้ เราจะนำเสนอการออกแบบและการประเมิน Perplexity Search API เริ่มแรกเราจะสำรวจสถาปัตยกรรมและการตัดสินใจทางเทคนิคที่สำคัญเบื้องหลังโครงสร้างพื้นฐานการค้นหาในระดับโปรดักชันของเรา ซึ่งประมวลผลคำค้นหา 200 ล้านครั้งต่อวัน สถาปัตยกรรมของเราผสมผสานกลไกการดึงข้อมูลแบบไฮบริด ท่อส่งการจัดอันดับหลายขั้นตอน การทำดัชนีแบบกระจาย และการแยกวิเคราะห์แบบไดนามิกผ่านโมดูลทำความเข้าใจเนื้อหาที่ปรับปรุงตัวเองได้
จากนั้นเราจะอธิบายแนวทางของเราในการประเมินประสิทธิภาพของ Search API เชิงประจักษ์ผ่านกรอบการประเมินแบบโอเพนซอร์สที่สร้างขึ้นใหม่ ผ่านการทำเบนช์มาร์กอย่างครอบคลุมควบคู่ไปกับ API เชิงพาณิชย์ที่มีอยู่ เราแสดงให้เห็นถึงประสิทธิภาพระดับล้ำสมัยทั้งในด้านคุณภาพและความหน่วง Perplexity Search API เปิดให้ใช้งานสำหรับนักพัฒนาทั่วโลกตั้งแต่วันนี้เป็นต้นไป
[ค้นหา search_evals บน GitHub]}
การสร้างระบบค้นหาที่ปรับให้เหมาะสมสำหรับโมเดล AI
นับตั้งแต่ก่อตั้ง เราเข้าใจดีว่าความสามารถในการค้นหาที่แข็งแกร่งจะมีความสำคัญอย่างยิ่งต่อการเปิดตัวผลิตภัณฑ์ AI ที่กำหนดนิยามใหม่ให้กับหมวดหมู่นั้นๆ ซึ่งเราต้องการส่งมอบ เดิมทีเราหวังว่าความสามารถเหล่านี้จะมีอยู่แล้วในรูปแบบที่เปิดให้ใช้งานสาธารณะ เราได้ทดลองกับพอร์ตโฟลิโอของ Search APIs ที่มีอยู่ในช่วงปลายปี 2022 และเอ็นจิ้นคำตอบของ Perplexity ใน เวอร์ชันแรกสุด ก็ได้นำข้อเสนอเหล่านี้มารวมไว้ด้วยเช่นกัน โดยเฉพาะอย่างยิ่ง เราจะวิเคราะห์คำค้นหาของผู้ใช้ กำหนดและส่งคำขอไปยัง API เหล่านั้น และรวบรวมผลลัพธ์เพื่อใช้เป็นบริบทสำหรับไปป์ไลน์การสร้างผลลัพธ์ในลำดับถัดไป
อย่างไรก็ตาม เมื่อผู้ใช้หลั่งไหลเข้ามาใช้งาน Perplexity เราก็ตระหนักได้อย่างรวดเร็วว่า API เหล่านี้ไม่สามารถปรับขนาดตามการเติบโตของเราได้ ราคาที่เราพบนั้นสูงลิ่ว โดยผู้ให้บริการ API ชั้นหน้ารายหนึ่งเรียกเก็บเงินสูงถึง 200 ดอลลาร์ต่อการค้นหาหนึ่งพันครั้ง แต่ที่แยไปกว่านั้นคือ API รุ่นเก่าเหล่านี้ไม่ได้ถูกออกแบบมาสำหรับกระบวนการดึงข้อมูลรูปแบบใหม่ที่นำเสนอโดยระบบ AI ยุคใหม่
เริ่มต้นด้วย รูปแบบคำขอและคำตอบของ API รุ่นเก่าเหล่านี้ถูกออกแบบมาสำหรับโลกที่มนุษย์เป็นผู้บริโภคผลลัพธ์การค้นหาแต่เพียงผู้เดียว ส่งผลให้ API เหล่านี้ให้ความสำคัญกับผลลัพธ์ในระดับเอกสาร โดยละเลยข้อมูลที่มีความละเอียดมากกว่าซึ่งเปิดเผยโดยหน่วยย่อยภายในเอกสาร ความสำเร็จของโมเดล AI ขึ้นอยู่กับคุณภาพและความกะทัดรัดของบริบทที่มีให้ และเราได้เห็นด้วยตาตัวเองแล้วว่าการดึงข้อมูลที่กว้างเกินไปสามารถทำให้โมเดล AI ออกนอกลู่นอกทางได้อย่างไร ไม่ว่าเอกสารที่ดึงมาโดยรวมจะดูเกี่ยวข้องมากแค่ไหนก็ตาม ความพยายามของเราในการยัดเยียดความแม่นยำลงในผลลัพธ์ที่ไม่แม่นยำนั้นประสบความสำเร็จอย่างจำกัด
นอกจากนี้เรายังสังเกตเห็นว่า API รุ่นเก่ามีความล้าสมัยหรือช้าเกินไป Search API ที่พัฒนาขึ้นอย่างอิสระอาศัยดัชนีที่ไม่สมบูรณ์และได้รับการอัปเดตไม่บ่อยนัก API ที่อาศัยการดึงข้อมูลเว็บ (Scraping) เช่น API SERP นอกทางการค้าต่างๆ สำหรับ Google Search ได้ประโยชน์จากดัชนีที่ครอบคลุมมากกว่า แต่ก็มีความหน่วงที่สูงจนยอมรับไม่ได้อันเนื่องมาจากความไม่มีประสิทธิภาพที่มีอยู่ในตัวเมื่อต้องสืบค้นเครื่องมือค้นหาของบุคคลที่สาม ความหน่วงที่สูงทำให้ API ไม่เหมาะสำหรับแอปพลิเคชันที่ผู้ใช้ต้องใช้งานโดยตรง ในขณะที่ความล้าสมัยทำให้ชุดผลลัพธ์ไม่สามารถใช้งานได้สำหรับระบบ AI ใดๆ ที่ต้องการความถูกต้องและน่าเชื่อถือ
ในที่สุด เราสังเกตเห็นว่าระบบนิเวศของ AI แบ่งออกเป็นสองแนวทางระหว่างการค้นหาแบบคำสำคัญ (lexical search) และการค้นหาแบบความหมาย (semantic search) โดยมีระบบต่างๆ เกิดขึ้นที่ปรับแต่งมากเกินไปสำหรับรูปแบบใดรูปแบบหนึ่งโดยเฉพาะ เราเห็นการเติบโตของฐานข้อมูลเวกเตอร์ที่ไม่สามารถรองรับแม้กระทั่งตัวกรองบูลีนอย่างง่ายได้อย่างเพียงพอ แบ็คเอนด์การค้นหาแบบดั้งเดิมก็ไม่ได้ทำได้ดีไปกว่ากันนัก ด้วยการสนับสนุนที่ยังจำกัดสำหรับการจัดอันดับเชิงความหมายและโอกาสในการดึงข้อมูลที่ปลดล็อกโดย AI
เมื่อเราตระหนักว่าการทำให้ Perplexity ยิ่งดีขึ้นจะต้องอาศัยการสร้างโครงสร้างพื้นฐานการค้นหาเฉพาะของเราเอง เราจึงได้กลั่นกรองข้อสังเกตของเราออกเป็น 3 เกณฑ์สำคัญ:
ความครบถ้วน ความสดใหม่ และความเร็ว: ดัชนีการค้นหาต้องครอบคลุม ได้รับการอัปเดตตลอดเวลา และได้รับการออกแบบมาเพื่อให้มีความหน่วงในระดับเรียลไทม์
ความเข้าใจเนื้อหาในระดับละเอียด: ความเปราะบางของโมเดล AI และหน้าต่างบริบทที่จำกัดกำหนดให้ผลลัพธ์การค้นหาต้องแสดงและจัดอันดับในระดับที่มีความละเอียดถี่ถ้วนที่สุดเท่าที่จะเป็นไปได้
การดึงข้อมูลและจัดอันดับแบบผสม: ทั้งไปป์ไลน์การดึงข้อมูลและการจัดอันดับต้องผสานรวมสัญญาณแบบคำสำคัญและแบบความหมายเข้าด้วยกันเพื่อให้ผลลัพธ์มีประโยชน์สำหรับ AI
โครงสร้างพื้นฐานการรวบรวมข้อมูลและการทำดัชนี
การดำเนินงานในสเกลของ Perplexity ต้องอาศัยโครงสร้างพื้นฐานที่สามารถทำแผนที่เว็บได้อย่างครอบคลุมและตอบสนองต่อการเปลี่ยนแปลงตลอดเวลา ดัชนีการค้นหาของเราติดตาม URL ที่ไม่ซ้ำกันมากกว่า 200,000 ล้านรายการ พร้อมความจุในการติดตามเพิ่มอีกหลายแสนล้านรายการ
การทำให้อินเด็กซ์ของเราครอบคลุมพื้นที่ของอินเทอร์เน็ตอย่างกว้างขวางเพียงพอ และทำให้เอกสารแต่ละฉบับสะท้อนสถานะล่าสุดอยู่เสมอ เป็นงานที่ท้าทายอย่างยิ่ง มีความตึงเครียดโดยธรรมชาติระหว่างความสมบูรณ์และความสดใหม่: สำหรับงบประมาณการจัดทำดัชนีที่กำหนดไว้ การรีเฟรชหน้าเว็บที่มีอยู่ต้องแข่งขันกับการจัดทำดัชนีหน้าใหม่ที่ยังไม่เคยเข้าชม เราสร้างสมดุลให้กับความตึงเครียดนี้ผ่านการผสมผสานระหว่างการขยายขนาด (ซึ่งผ่อนคลายข้อจำกัดในการเพิ่มประสิทธิภาพโดยเพิ่มงบประมาณการจัดทำดัชนี) และการจัดลำดับความสำคัญที่ขับเคลื่อนด้วย ML (ซึ่งทำให้มั่นใจได้ว่าการจัดทำดัชนีแต่ละครั้งมีคุณค่าต่ออินเด็กซ์โดยรวมมากที่สุด)
เราได้สร้างดัชนีและอุปกรณ์รวบรวมข้อมูลระดับเอกซาไบต์ที่ปรับขนาดในแนวนอนได้ทั้งในด้านขนาดและปริมาณคำค้นหา ฟลีตตัวรวบรวมข้อมูลและทำดัชนีของ Perplexity ประกอบด้วย CPU หลายหมื่นตัวและหน่วยความจำ RAM หลายร้อยเทราไบต์โดยรวม พร้อมพื้นที่สำรองสำหรับขยายขนาดเพิ่มเติมได้อย่างมาก เราผสานโครงสร้างพื้นฐานการประมวลผลนี้เข้ากับความสมดุลระหว่างพื้นที่จัดเก็บข้อมูลแบบเย็นและแบบอุ่น เราใช้ทั้งโมเดลที่เรียนรู้ได้และฮิวทริสติกส์ที่ปรับแต่งแล้วเพื่อพิจารณาว่าควรเก็บบันทึกเอกสารใดไว้ในสถานะอุ่น โดยจัดลำดับความสำคัญของเอกสารจากโดเมนที่มีความน่าเชื่อถือ เอกสารที่เกี่ยวข้องกับหัวข้อที่ยังไม่ได้รับการครอบคลุมถึง และหมวดหมู่อื่นๆ ที่มีศักยภาพสูงในการเติมเต็มดัชนีของเรา
โครงสร้างพื้นฐานนี้ช่วยให้ Perplexity สามารถประมวลผลการดำเนินการทำดัชนีได้หลายหมื่นครั้งต่อวินาที แต่ถึงแม้จะมีงบประมาณที่ค่อนข้างมากนี้ สเกลของอินเทอร์เน็ตก็ยังคงใหญ่โตเกินกว่าที่จะทำดัชนี URL ทุกๆ รายการได้อย่างถี่ถ้วนและเกิดขึ้นซ้ำๆ นี่คือจุดที่ ML เข้ามามีบทบาท เราฝึกฝนโมเดล ML เพื่อคาดการณ์ว่า URL ตัวเต็งรายการใดที่จำเป็นต้องได้รับการทำดัชนี วัตถุประสงค์ในการฝึกอบรมถูกสร้างขึ้นเพื่อให้แน่ใจว่าเราปรับเทียบการตัดสินใจทำดัชนีของเราให้สอดคล้องกับทั้งความสำคัญและความถี่ในการอัปเดตที่น่าจะเป็นของ URL เฉพาะนั้นๆ นอกจากนี้เรายังอาศัย ML เพื่อบอกเราอย่างแม่นยำว่าควรตั้งเวลาการดำเนินการทำดัชนีเมื่อใด สำหรับเว็บไซต์ที่มีการเผยแพร่และรอบการรีเฟรชเป็นกิจวัตร วิธีนี้ช่วยให้เราสามารถเลื่อนการดำเนินการไปจนถึงช่วงเวลาที่น่าจะมีประโยชน์มากที่สุดได้ ผ่านการปรับปรุงโมเดล ML เหล่านี้อย่างต่อเนื่อง เราจึงสามารถรักษาดัชนีที่ตรงตามมาตรฐานทั้งในด้านความครบถ้วนและความสดใหม่ได้
แม้ว่าโครงสร้างพื้นฐานการรวบรวมข้อมูลของเราจะปรับขนาดในแนวนอนได้อย่างง่ายดาย แต่เราก็ตระหนักดีว่าผู้ให้บริการเว็บไซต์ต้องเผชิญกับข้อจำกัดทางเทคนิคที่แตกต่างกัน เราใช้ความระมัดระวังในการรักษาอัตราคำขอไปยังโดเมนใดๆ ให้คาดเดาได้และจัดการได้ PerplexityBot ซึ่งเป็นตัวรวบรวมข้อมูลสำหรับการค้นหาของเรา ปฏิบัติตามขีดจำกัดที่ระบุไว้อย่างชัดเจนในไฟล์ robots.txt หรือในกรณีที่ไม่มีขีดจำกัดที่ระบุโดยโดเมน ก็จะปฏิบัติตามมาตรฐานอุตสาหกรรมเกี่ยวกับอัตราคำขอ นอกจากนี้เรายังปรับพฤติกรรมการรวบรวมข้อมูลเมื่อเราตรวจพบว่าเว็บไซต์ไม่สามารถใช้งานได้ ระบบแบบกระจายของเราได้รับการออกแบบมาเพื่อบังคับใช้ขีดจำกัดเหล่านี้แม้ว่าจะมีการดำเนินการพร้อมกันนับหมื่นรายการก็ตาม
ความเข้าใจเนื้อหาที่ปรับปรุงตัวเองได้ในสเกลอินเทอร์เน็ต
แม้จะมีดัชนีการค้นหาที่ใหญ่ที่สุดและสดใหม่ที่สุดแห่งหนึ่งบนโลก แต่คุณภาพผลลัพธ์ของคำค้นหาแต่ละรายการก็ยังขึ้นอยู่กับความเข้าใจของระบบเราที่มีต่อเนื้อหาในเอกสารแต่ละฉบับ ในจุดนี้ เราต้องเผชิญกับความท้าทายพื้นฐาน: อินเทอร์เน็ตเป็นพื้นที่ที่ยุ่งเหยิง ไม่มีกฎการแยกวิเคราะห์ชุดใดชุดหนึ่งที่จะจัดการกับความหลากหลายอันไม่สิ้นสุดของเลย์เอาต์ โครงสร้าง และสไตล์ที่พบได้ทั่วทั้งอินเทอร์เน็ตได้
เราแก้ปัญหานี้ได้ด้วยการพัฒนาโมดูลทำความเข้าใจเนื้อหาที่แยกวิเคราะห์เว็บไซต์และดึงข้อมูลที่มีความหมายเชิงความหมายโดยใช้ชุดกฎแบบไดนามิก เว็บไซต์ที่อุดมไปด้วยข้อมูลที่มีโครงสร้างดีในรูปแบบรายการหรือตารางอาจได้รับประโยชน์จากกฎการแยกวิเคราะห์และการดึงข้อมูลที่เป็นทางการมากกว่า ในขณะที่เว็บไซต์อื่น ๆ ที่เน้นเนื้อหาที่ผู้ใช้สร้างขึ้นแบบอิสระอาจต้องใช้ชุดกฎที่ยืดหยุ่นกว่า เนื่องจากอินเทอร์เน็ตส่วนใหญ่มีความคงที่ในช่วงเวลาสั้น ๆ เราจึงพบว่าอายุการใช้งานของกฎใดกฎหนึ่งค่อนข้างยาวนาน แต่ในขณะที่เว็บไซต์ต่าง ๆ พัฒนาไปตามกาลเวลาและในขณะที่เราเรียนรู้เพิ่มเติมเกี่ยวกับวิธีที่ดีที่สุดในการดึงข้อมูล ชุดกฎของเราจึงจำเป็นต้องได้รับการดูแลรักษาอย่างต่อเนื่องเช่นกัน
เพื่ออำนวยความสะดวกในการปรับตัวแบบไดนามิกนี้ แน่นอนว่าเราหันไปพึ่ง AI ในสเกลของ Perplexity เราสังเกตเห็นภาคตัดขวางของอินเทอร์เน็ตที่อุดมสมบูรณ์อย่างเหลือเชื่อในระหว่างการให้บริการคำค้นหาของผู้หลายล้านรายการต่อชั่วโมง สิ่งนี้ถือเป็นรากฐานสำหรับวงจรการปรับปรุงตัวเองแบบวนซ้ำ เราสังเกตพฤติกรรมการแยกวิเคราะห์และผลลัพธ์ที่ดึงออกมาของชุดกฎปัจจุบันของเราทั่วทั้งจักรวาลคำค้นหาของเรา จากนั้นเราใช้ LLM ยุคใหม่เพื่อประเมินประสิทธิภาพใน 2 มิติหลัก:
ความครบถ้วน: ดัชนีของเราควรได้รับเนื้อหาที่มีความหมายเชิงความหมายให้มากที่สุดเท่าที่จะเป็นไปได้ พร้อมทั้งหลีกเลี่ยงการดึงข้อมูลที่ไม่มีสาระสำคัญหรือเรื่องไร้สาระออกมาโดยไม่ตั้งใจ
คุณภาพ: ดัชนีของเราอาศัยเนื้อหาที่มีคุณภาพสูงทั้งในด้านเนื้อหาและรูปแบบ ข้อมูลควรถูกบันทึกในลักษณะที่ยังคงโครงสร้างและเลย์เอาต์ดั้งเดิมของเนื้อหาไว้
โปรดสังเกตว่าความครบถ้วนและคุณภาพยังแสดงถึงความขัดแย้งอีกประการหนึ่งในตัว: การปรับแต่งคุณภาพด้วยตนเองเป็นสิ่งที่เป็นไปได้ แต่กฎการแยกวิเคราะห์ที่ได้อาจไม่สามารถจับเนื้อหาที่สำคัญไว้ได้ ในทำนองเดียวกัน เราอาจเขียนกฎแบบผ่อนปรนด้วยมือซึ่งใช้การกรองเนื้อหาดิบให้น้อยที่สุด ซึ่งอาจปรับปรุงความครบถ้วนได้แต่ต้องแลกมาด้วยคุณภาพ นี่คือเหตุผลที่เราหันมาใช้การปรับปรุงตัวเองที่ขับเคลื่อนด้วย AI เพื่อพัฒนาชุดกฎของเราในลักษณะที่สามารถปรับให้เหมาะสมกับทั้งสองอย่างพร้อมกันในแบบที่ปรับเปลี่ยนตามโดเมนได้
โดยเฉพาะอย่างยิ่ง หลังจากการประเมินประสิทธิภาพการแยกวิเคราะห์ที่ขับเคลื่อนด้วย LLM แต่ละครั้ง ระบบของเราจะกำหนดชุดการเปลี่ยนแปลงชุดกฎที่เสนอเพื่อจัดการกับประเภทข้อผิดพลาดที่สำคัญที่สุด ชุดกฎเหล่านี้จะผ่านการตรวจสอบเพิ่มเติม หลังจากนั้นเราจึงปรับ ใช้งานเวอร์ชันใหม่ไปยังตัวทำดัชนีของเรา เนื่องจากความปรับปรุงในตรรกะการแยกวิเคราะห์และการดึงข้อมูลสามารถเป็นประโยชน์ต่อการดำเนินการทำดัชนีในอนาคตเท่านั้น การลงทุนของเราในการทำดัชนีใหม่ที่ปรับแต่งด้วย ML จึงมีความสำคัญเป็นพิเศษ: การรีเฟรชเอกสารที่มีปริมาณการใช้งานสูงอย่างต่อเนื่องโดยใช้ตรรกะเวอร์ชันล่าสุดนี้ช่วยให้มั่นใจได้ถึงวงจรการปรับปรุงตัวเองที่รัดกุม
กฎเหล่านี้มีความสำคัญไม่เพียงแต่สำหรับประสิทธิภาพการแยกวิเคราะห์พื้นฐานเท่านั้น แต่ยังรวมถึงการแบ่งส่วนออกเป็นหน่วยย่อยของเอกสารด้วย เมื่อพูดถึง LLM ยุคใหม่ โทเค็นบริบทแต่ละโทเค็นถือเป็นสิ่งมีค่า งานวิจัยก่อนหน้านี้จำนวนมากได้บันทึกไว้ว่าประสิทธิภาพของ LLM ลดลงอย่างไรเมื่อขนาดบริบทเพิ่มขึ้นและเกิดมลพิษในบริบทด้วยข้อมูลที่ไม่เกี่ยวข้อง การมีตัววิเคราะห์ที่จัดโครงสร้างมาเป็นอย่างดีและครอบคลุมช่วยให้เราสามารถแบ่งย่อยเอกสารออกเป็นช่วงข้อมูลที่มีเนื้อหาครบถ้วนในตัวเอง ซึ่งแต่ละช่วงสามารถดึงข้อมูลและจัดอันดับทีละรายการได้ในเวลาที่มีการสืบค้น
ไปป์ไลน์การดึงข้อมูลและการจัดอันดับ
การค้นหาที่ทันสมัยกำหนดให้ต้องรับประกันทั้งความครบถ้วนและความเกี่ยวข้องภายใครงบประมาณความหน่วงที่จำกัด ไปป์ไลน์การดึงข้อมูลและการจัดอันดับของ Perplexity บรรลุสิ่งนี้ผ่านสถาปัตยกรรมแบบหลายขั้นตอนที่ค่อยๆ ปรับปรุงผลลัพธ์ให้ดีขึ้นด้วยชุดโมดูลที่มีความซับซ้อนเพิ่มขึ้นเรื่อยๆ เราแก้ปัญหาคอขวดที่อาจเกิดขึ้นด้วยการปรับขนาดจุดอุดตันที่อาจเกิดขึ้นในแนวนอนให้มากที่สุดเท่าที่จะเป็นไปได้
ไปป์ไลน์เริ่มต้นด้วยการดึงข้อมูลจากดัชนีของเรา เราไม่บังคับให้ต้องเลือกระหว่างการดึงข้อมูลแบบคำสำคัญหรือแบบความหมาย แต่เราสืบค้นดัชนีการค้นหาผ่านทั้งสองรูปแบบและผสานผลลัพธ์เข้าเป็นชุดตัวเต็งแบบไฮบริด ในขั้นตอนนี้ ลำดับความสำคัญคือความครอบคลุมมากกว่าความแม่นยำ โดยขั้นตอนต่อๆ ไปของไปป์ไลน์จะปรับแต่งเพื่อความแม่นยำ
ไปป์ไลน์ดำเนินต่อไปด้วยขั้นตอนการกรองล่วงหน้า ซึ่งเราใช้ฮิวทริสติกส์พื้นฐานและตัวกรองเบื้องต้นเพื่อลบเนื้อหาที่ไม่ตอบสนองหรือล้าสมัยออกจากชุดตัวเต็งอย่างชัดเจน
จากนั้นเราใช้ขั้นตอนการจัดอันดับที่มีความซับซ้อนขึ้นเรื่อยๆ หลายขั้นตอน ขั้นตอนแรกๆ อาศัยคะแนนตามคำสำคัญและตามการฝังตัวที่ปรับแต่งเพื่อความเร็ว ในขณะที่ชุดตัวเต็งค่อยๆ ถูกคัดกรองให้แคบลง เราจึงใช้โมดูลจัดอันดับใหม่แบบ cross-encoder ที่ทรงพลังยิ่งขึ้นเพื่อทำการปรับแต่งชุดผลลัพธ์ขั้นสุดท้าย ต้องขอบคุณการลงทุนมากมายของเราในด้านประสิทธิภาพการอนุมาน ทำให้เราสามารถใช้ประโยชน์จากสถาปัตยกรรมโมเดลล้ำสมัยสำหรับขั้นตอนหลังๆ เหล่านี้ ในขณะเดียวกันก็รักษาความหน่วงในการจัดอันดับโดยรวมให้อยู่ในระดับต่ำได้
ตลอดไปป์ไลน์นี้ เราจะดึงข้อมูลและให้คะแนนผลลัพธ์ทั้งในระดับเอกสารและระดับย่อยของเอกสาร ดังที่ได้กล่าวไว้ข้างต้น AI จำเป็นต้องมีการออกแบบวิศวกรรมบริบทอย่างระมัดระวัง ไปป์ไลน์ของเราได้รับการออกแบบมาเพื่อแสดงหน่วยย่อยที่สุดเท่าที่จะเป็นไปได้ให้กับโมเดล เพื่อให้ผู้บริโภคปลายทางสามารถนำหน่วยที่แม่นยำเหล่านั้นไปใช้ได้โดยไม่ต้องดึงบริบทที่ไม่เกี่ยวข้องจากส่วนอื่นในเอกสารต้นฉบับเข้ามา
การรับประกันคุณภาพสูงในแต่ละขั้นตอนของไปป์ไลน์นี้เป็นไปได้ผ่านการออกแบบร่วมกับพอร์ตโฟลิโอผลิตภัณฑ์ของ Perplexity เท่านั้น ทุกรายละเอียดของสแต็กการจัดอันดับได้รับการออกแบบมาเพื่อใช้ประโยชน์จากสัญญาณอันอุดมสมบูรณ์ที่ผลิตโดยคำขอของผู้ใช้หลายล้านรายการที่เราให้บริการในแต่ละชั่วโมงของวัน สัญญาณส่วนใหญ่เหล่านี้เป็นแบบอัตโนมัติ โดยคำตอบของ Perplexity แต่ละรายการที่สร้างขึ้นจะให้จุดข้อมูลเชิงประจักษ์เกี่ยวกับคุณภาพการค้นหาตามที่ใช้ในเวิร์กโฟลว์ของเอ็นจิ้นจริง เราผสมผสานการประเมินที่ขับเคลื่อนด้วย AI เข้ากับการป้อนกลับจากมนุษย์แบบเรียลไทม์เพื่อเติมเต็มข้อมูลการฝึกอบรมสำหรับโมเดลการฝังตัวและการจัดอันดับของเราให้เกินกว่าที่ชุดข้อมูลที่สร้างขึ้นด้วยตนเองใดๆ จะสามารถมอบให้ได้
การทำงานร่วมกันระหว่างการค้นหาและผลิตภัณฑ์นี้มีเพียง Perplexity เท่านั้นที่มี เอ็นจิ้นการค้นหารุ่นเก่าจำกัดอยู่เพียงสัญญาณหยาบๆ ที่ให้มาจากเทเลเมทรีลิงก์สีน้ำเงิน ข้อเสนอการค้นหาใหม่ๆ พยายามนำแนวคิดที่ขับเคลื่อนด้วย AI เหล่านี้มาใช้บางส่วน แต่ขาดสภาพแวดล้อมในโลกความเป็นจริงที่สามารถตรวจสอบคุณภาพการค้นหาและให้ความอุดมสมบูรณ์ของสัญญาณที่จำเป็นสำหรับวงจรการปรับปรุงอย่างรวดเร็ว เราโชคดีที่มีส่วนผสมที่ขาดหายไป นั่นคือ สนามทดสอบจริงสำหรับคุณภาพการค้นหา ซึ่งขับเคลื่อนด้วย LLM ยุคใหม่และผ่านการทดสอบในสนามรบอย่างต่อเนื่องโดยผู้ใช้ที่อยากรู้อยากเห็นหลายล้านคนทั่วโลก
การสร้างมาตรฐานใหม่สำหรับคุณภาพและประสิทธิภาพ
หลังจากสร้าง Perplexity Search API และ SDK เพื่อให้โครงสร้างพื้นฐานการค้นหาของเราใช้งานได้สำหรับนักพัฒนาทั่วโลก เราต้องการทำความเข้าใจว่าข้อเสนอ API เชิงพาณิชย์ต่างๆ มีผลงานเป็นอย่างไรในกรณีการใช้งาน AI ในโลกความเป็นจริง กลายเป็นเรื่องปกติที่จะประเมินตัวโมเดล AI เอง แต่เราต้องการมุมมองใหม่ที่แตกต่างออกไปจากรูปแบบนี้ นั่นคือการประเมินคุณภาพของ Search API เมื่อถูกเรียกใช้งานโดยโมเดล AI
เรามองหาระบบนิเวศแบบโอเพนซอร์สก่อนเพื่อทำความเข้าใจเกี่ยวกับผลงานก่อนหน้านี้ เราพบส่วนประกอบสำคัญมากมายสำหรับการประเมินอย่างเข้มงวด แต่ไม่มีเฟรมเวิร์กใดที่รวมส่วนประกอบเหล่านี้เข้าเป็นโซลูชันการทำเบนช์มาร์กแบบเสียบปลั๊กแล้วใช้งานได้ทันที ดังนั้นเราจึงตั้งใจพัฒนาเฟรมเวิร์กการประเมินที่สามารถใช้งานได้ไม่เพียงแต่โดย Perplexity เท่านั้น แต่ยังรวมถึงนักวิจัยหรือนักพัฒนาใดๆ ที่ต้องการทำเบนช์มาร์ก Search API ด้วย
ด้วยกรอบการประเมินนี้ เราได้ทำการเปรียบเทียบมาตรฐานของ Perplexity Search API อย่างเข้มงวดควบคู่ไปกับข้อเสนออื่น ๆ การปรับแต่งประสิทธิภาพการค้นหาเป็นเรื่องซับซ้อน โดยมีการแลกเปลี่ยนที่ละเอียดอ่อนมากมายระหว่างคุณภาพและความเร็ว ในความสำเร็จสำหรับนักพัฒนา เราพบว่า Perplexity Search API ได้สร้างมาตรฐานใหม่ระดับแนวหน้าสำหรับทั้งคุณภาพและเวลาแฝง นักพัฒนาไม่จำเป็นต้องเลือกระหว่างการสร้างแอปพลิเคชันที่รวดเร็วสุดขีดและการรับรองผลลัพธ์คุณภาพสูงอีกต่อไป: ด้วย Perplexity พวกเขาสามารถมีได้ทั้งสองอย่าง
การออกแบบการประเมินที่เชื่อถือได้สำหรับเวิร์กโฟลว์การค้นหาของเอ็นจิ้น AI
เราเริ่มต้นด้วยการกำหนดหลักการชี้นำ 3 ประการสำหรับเฟรมเวิร์กการประเมินของเรา:
สเปกตรัมของความซับซ้อน: เฟรมเวิร์กการประเมินควรวัดประสิทธิภาพทั้งในกรณีการใช้งาน AI แบบเอ็นจิ้นที่ตรงไปตรงมาและซับซ้อน
ความเป็นกลาง: เฟรมเวิร์กการประเมินควรประเมิน API ทั้งหมดบนพื้นฐานที่เท่าเทียมกัน
ความเรียบง่าย: แม้ว่าบางกรณีการใช้งานอาจมีความซับซ้อน แต่ตัวเฟรมเวิร์กควรเรียบง่ายที่สุดเท่าที่จะเป็นไปได้ เพื่อให้ผู้อื่นสามารถเข้าใจ ทำซ้ำผลลัพธ์ และขยายเฟรมเวิร์กด้วยความน่าเบื่อหน่ายที่น้อยที่สุด
เฟรมเวิร์กการประเมินน้ำหนักเบาของเรา search_evals บรรลุเป้าหมายเหล่านี้ผ่านการออกแบบโมดูลาร์ที่เรียบง่าย เราได้พัฒนาชุดเครื่องมือเอ็นจิ้น AI สองชุดเพื่อรวบรวมทั้งกรณีการใช้งานการค้นหาแบบยิงครั้งเดียวแบบคลาสสิกและเวิร์กโฟลว์เอ็นจิ้นขั้นสูง (ซึ่งแสดงตัวอย่างโดยผลิตภัณฑ์ “การวิจัยเชิงลึก” ต่างๆ ที่มีใช้อย่างแพร่หลายในตลาดผู้บริโภค) ชุดเครื่องมือทั้งสองถูกใช้งานในลักษณะที่ตรงไปตรงมาซึ่งเปิดโอกาสน้อยมากให้เกิดความได้เปรียบที่ซ่อนอยู่
เพื่อขับเคลื่อนการประเมินของเรา เราได้นำเบนช์มาร์ก 4 รายการมาใช้: SimpleQA และ FRAMES สำหรับการค้นหาแบบขั้นตอนเดียว พร้อมด้วย BrowseComp และ HLE สำหรับการวิจัยเชิงลึก โดยรวมแล้ว เบนช์มาร์กเหล่านี้เป็นเกณฑ์มาตรฐานที่เป็นที่ยอมรับอย่างดีสำหรับเอ็นจิ้นความรู้ ตามธรรมเนียมปฏิบัติที่กำหนดไว้ เราให้คะแนนเบนช์มาร์กทั้งหมดโดยใช้ระเบียบวิธีตัวจำแนกประเภทที่มีการกำหนดพร้อมท์แบบเดียวกันกับที่ใช้ในงานต้นฉบับ การใช้งานเบนช์มาร์กที่แม่นยำ (รวมถึงตรรกะตัวให้คะแนน) สามารถ ตรวจสอบ ได้ในรีโป GitHub ของเรา
เราออกแบบเฟรมเวิร์กโดยคำนึงถึงความสามารถในการทำซ้ำและการขยายต่อได้ คะแนนระดับงานและผลลัพธ์ของเอ็นจิ้นเบื้องหลังจะถูกจัดเก็บไว้กับการเรียกใช้แต่ละครั้ง ชุดเครื่องมือ เบนช์มาร์ก และข้อเสนอ Search API เพิ่มเติมสามารถผสานรวมได้อย่างง่ายดาย นักวิจัยและนักพัฒนาสามารถอ่าน เอกสาร GitHub ของเราสำหรับข้อมูลเพิ่มเติมเกี่ยวกับการขยายเฟรมเวิร์กเพื่อตอบสนองความต้องการที่แม่นยำของคุณ
ผลลัพธ์การประเมิน
ด้วยเฟรมเวิร์กการประเมินนี้ เราจึงเริ่มต้นประเมิน Search API ของเราเมื่อเทียบกับข้อเสนอ API อื่นๆ ในบรรดาเบนช์มาร์กทั้งหมดที่ทดสอบ Perplexity โดดเด่นในฐานะ API ที่เร็วที่สุดและมีคุณภาพสูงสุดในตลาด
เราพบว่าการลงทุนที่เรากล่าวถึงข้างต้นในด้านดัชนี การดึงข้อมูล และประสิทธิภาพการจัดอันดับนั้นคุ้มค่าอย่างยิ่ง ความหน่วงมัธยฐานของ Perplexity อยู่ที่ 358 มิลลิวินาที ซึ่งเร็วกว่าผู้ให้บริการที่เร็วเป็นอันดับสองถึงกว่า 150 มิลลิวินาที ความหน่วงเปอร์เซ็นไทล์ที่ 95 ยังคงอยู่ต่ำกว่า 800 มิลลิวินาทีได้อย่างสบาย ด้วยเมตริก TTFT (เวลาในการแสดงโทเค็นแรก) ที่ยาวนานของโมเดลล้ำสมัยในปัจจุบัน ทุกมิลลิวินาทีจึงมีความสำคัญในการสร้างประสบการณ์ผู้ใช้ที่น่าประทับใจ เราใช้เวลาสองปีที่ผ่านมาในการเพิ่มประสิทธิภาพความหน่วงสำหรับผู้ใช้ของเราเอง และเรารู้สึกยินดีเป็นอย่างยิ่งที่การลงทุนเดียวกันนี้จะช่วยเป็นประโยชน์แก่ชุมชนนักพัฒนาด้วยเช่นกัน
ความหน่วงของ Search API
(คำขอที่ริเริ่มจาก AWS us-east-1)
p50 | p75 | p90 | p95 | |
Perplexity | 358ms | 443ms | 604ms | 763ms |
Exa | 1375ms | 1499ms | 1798ms | 2188ms |
Brave | 513ms | 637ms | 728ms | 808ms |
อิงตาม SERP* | 1342ms | 1586ms | 1743ms | 1790ms |
เปอร์เซ็นไทล์เวลาแฝงของ Search API สำหรับคำขอที่เริ่มต้นจาก AWS us-east-1
* ผู้ให้บริการ Search API หลายรายใช้การขูดข้อมูล SERP เป็นพื้นฐานสำหรับผลลัพธ์ของตน เพื่อเก็บรักษาประสิทธิภาพของแนวทางดังกล่าว เราจึงใช้ API ที่อิงตาม Google SERP ที่เป็นตัวแทนซึ่งให้บริการโดย Tavily
ข้อได้เปรียบด้านความเร็วนี้ไม่ได้แลกมาด้วยคุณภาพที่ลดลง Perplexity Search API ให้ผลลัพธ์ระดับล้ำสมัยทั้งในการตั้งค่าการค้นหาแบบขั้นตอนเดียวและการวิจัยเชิงลึก บนเบนช์มาร์กแต่ละรายการที่ทดสอบ Perplexity เป็นผู้นำในการให้ผลลัพธ์คุณภาพสูงที่สามารถขับเคลื่อนเวิร์กโฟลว์ AI ที่มีความซับซ้อนแตกต่างกันได้ ระยะห่างระหว่าง Perplexity กับตัวเลือกที่ดีที่สุดเป็นที่ประจักษ์อย่างชัดเจนโดยเฉพาะใน SimpleQA และ HLE ซึ่งบ่งชี้ว่าผลลัพธ์เหล่านี้มีความทนทานทั่วทั้งสเปกตรัมของความซับซ้อนของงาน
เช่นเดียวกับความหน่วง ความเป็นผู้นำของเราในด้านคุณภาพการค้นหาไหลลื่นมาจากความเป็นผู้นำของเราในการสร้างผลิตภัณฑ์ AI ที่น่าประทับใจและมีผู้ใช้งานหนาแน่น ผู้ใช้หลายล้านคนของเราใช้ Perplexity เพื่อเติมเต็มความอยากรู้อยากเห็นในทุกหัวข้อที่เป็นไปได้ และสัญญาณคุณภาพและความเกี่ยวข้องที่ได้ช่วยให้โมเดลการค้นหาของเราพัฒนาขึ้นในทุกๆ ชั่วโมงที่ผ่านไป
เบนช์มาร์กคุณภาพ Search API
การค้นหาแบบขั้นตอนเดียว | การวิจัยเชิงลึก | |||
SimpleQA | FRAMES | BrowseComp | HLE | |
Perplexity | .930 | .453 | .371 | .288 |
Exa | .781 | .399 | .265 | .242 |
Brave | .822 | .320 | .221 | .191 |
อิงตาม SERP* | .890 | .437 | .348 | .248 |
คะแนนคุณภาพของ Search API บน SimpleQA, FRAMES, BrowseComp และ HLE
เรายังคงอยู่ในช่วงเริ่มต้นของเอ็นจิ้นการค้นหาแบบเนทีฟ AI และศิลปะและวิทยาศาสตร์แห่งการวัดผลจะพัฒนาขึ้นอย่างไม่ต้องสงสัย เราขอเชิญชวนชุมชนให้มาร่วมมีส่วนร่วมด้วยการพัฒนาวิธีการที่เข้มงวดและสร้างสรรค์สำหรับการประเมินเอ็นจิ้นการค้นหาในยุคของเอ็นจิ้น AI
รากฐานสำคัญสำหรับบทถัดไปของ AI
อนาคตของระบบเอ็นจิ้นและผู้ช่วยอัจฉริยะจะขึ้นอยู่กับความพร้อมใช้งานของอินเทอร์เฟซโปรแกรมที่อุดมสมบูรณ์ซึ่งเข้าถึงความรู้ส่วนรวมของโลก เอ็นจิ้นการค้นหารุ่นเก่าในปัจจุบันอิ่มตัวในการใช้งานที่ประมาณ 10¹⁰ คำค้นหาต่อวัน ซึ่งเป็นตัวเลขที่น่าจะถึงจุดสูงสุดแล้ว ระบบค้นหาและดึงข้อมูลรุ่นถัดไปจะให้บริการคำขอในปริมาณที่มากกว่าเป็นทวีคูณ เนื่องจากจักรวาลของเอ็นจิ้น AI ที่เติบโตอย่างต่อเนื่องอาศัยระบบเหล่านี้สำหรับข้อมูลเรียลไทม์ที่ถูกต้อง
ความพยายามของเราจนถึงปัจจุบันทำให้เราอยู่ในตำแหน่งเอ็นจิ้นการค้นหาที่เร็วที่สุดและมีประสิทธิภาพสูงสุดที่สามารถเข้าถึงได้ผ่าน API แต่จะต้องมีนวัตกรรมที่มีความทะเยอทะยานยิ่งขึ้นเพื่อให้เราขับเคลื่อนบทถัดไปของ AI เราจะปรับขนาดระบบเหล่านี้อย่างมีประสิทธิภาพได้อย่างไรท่ามกลางความต้องการที่เพิ่มขึ้นอย่างต่อเนื่อง? ระบบค้นหาเหล่านี้จะได้รับการปรับให้เหมาะสมอย่างไรในแง่ของแนวทางใหม่ๆ ต่อวิศวกรรมบริบทและการฝึกอบรมภายหลัง? และเราจะนำทางผ่านความขัดแย้งที่มีอยู่เสมอระหว่างความครบถ้วน ความสดใหม่ และความหน่วงได้อย่างไร? สิ่งเหล่านี้คือคำถามปลายเปิดที่ Perplexity ด้วยการผสมผสานระหว่างรอยเท้าผลิตภัณฑ์ สเกล และ ความสามารถทางเทคนิค ทำให้เราอยู่ในตำแหน่งที่มีความพร้อมเป็นพิเศษในการจัดการ
การอ้างอิง
@online{perplexity2025ArchitectingAndEvaluatingAnAiFirstSearchApi,
author = {{Perplexity} and Aleksandr Bogutskii and Aleksandr Nikolenko and Aleksei Bykov and Alexander Pecheny and Alexandr Yarats and Arsenii Shevchenko and Denis Bykov and Dmitry Pervukhin and Ismail Gadzhiev and James Liounis and Kevin Hu and Kirill Priemko and Maksim Gaiduk and Maksim Morozov and Marko Kevac and Michael Liang and Mikhail Galanin and Nandor Licker and Nataliya Pevgova and Nikita Kireev and Nikolai Tretiak and Paul Schofield and Saif Ali Raja and Saleh Alghusson and Sebastian Sepulveda and Sergei Miller and Svyatoslav Feldsherov and Vitalii Polshkov and Vladimir Zaytsev and Denis Yarats},
title = {{Architecting and evaluating an AI-first Search API}},
date = {2025-09-25},
url = {https://www.perplexity.ai/hub/blog/architecting-and-evaluating-an-ai-first-search-api}
}