Photon: การสร้างเอนจิ้นการดึงข้อมูลและการจัดอันดับตั้งแต่เริ่มต้น

บทนำ

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

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

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

ปัจจุบัน Photon เป็นเบื้องหลังของไปพไลน์การค้นหาของเรา และยังเป็นรากฐานของค่าพรีเซ็ตแบบเร็วใหม่สำหรับ Search API ของเราด้วย โดยมีค่าความหน่วงของการเรียกค้นหาครั้งเดียวที่ 160 มิลลิวินาทีที่ p50 และ 230 มิลลิวินาทีที่ p95 จากการประเมินบนเกณฑ์มาตรฐานสาธารณะหกรายการ ค่าพรีเซ็ตแบบเร็วช่วยลดต้นทุนโดยประมาณของโมเดลรวมกับการค้นหาต่อหนึ่งงานลง 68% ในขณะที่ยังคงรักษาคุณภาพงานรวมให้เทียบเคียงได้กับค่าพรีเซ็ตเริ่มต้น เรากำลังปล่อยให้ใช้งานในวันนี้ เพื่อให้นักพัฒนาสามารถเข้าถึงการปรับปรุงเหล่านี้ได้

ขยาย

ขยาย

สิ่งที่เอนจิ้นการดึงข้อมูลและการจัดอันดับต้องการ

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

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

จุดบกพร่องของระบบเดิมของเรา

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

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

2. ค่าความหน่วงหางที่ย่ำแย่ บนทราฟฟิกจริง เวลาในการตอบสนอง p99 ของระบบเดิมอยู่ที่ประมาณ 800 มิลลิวินาที ชุดข้อมูลมีขนาดเกินกว่า RAM ที่มีอยู่ เราจึงไม่สามารถใช้ mlock เพื่อเก็บบันทึกไว้ในหน่วยความจำทั้งหมดได้ การเข้าถึงข้อมูลที่ไม่ได้อยู่ในหน่วยความจำอาจทำให้เกิดเพจฟอลต์ (Page Fault) ครั้งใหญ่ ซึ่งส่งผลให้การดำเนินการคิวรีต้องหยุดชะงักในขณะที่ระบบปฏิบัติการอ่านข้อมูลจากดิสก์

นอกจากนี้ เอนจิ้นยังทำการผสานดัชนีดิสก์หลักเข้ากับดัชนีขนาดเล็กที่ถูกล้างออกจากหน่วยความจำอย่างสม่ำเสมอ ในระหว่างกระบวนการรวมดัชนีดิสก์นี้ จำนวนเพจฟอลต์จะพุ่งสูงขึ้นไปอีก โดยความหน่วง p99 สูงถึงประมาณ 1.2 วินาทีเป็นเวลา 10–15 นาที เมื่อแคชอุ่นขึ้น ความถี่ของเพจฟอลต์และค่าความหน่วงก็ลดลง ซึ่งบ่งชี้ว่าการอ่านแบบเย็น (Cold Reads) เป็นสาเหตุสำคัญของความผิดปกตินี้ การโหลดข้อมูลล่วงหน้าและการอุ่นเครื่องดัชนีช่วยลดความผิดปกติเหล่านี้ได้ แต่ยังไม่สามารถแก้ไขปัญหาค่าความหน่วงหางสูงได้อย่างเพียงพอ

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

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

ตำแหน่งที่ Photon เข้ามามีบทบาทในสแต็กการค้นหา

Photon ถูกออกแบบมาเพื่อเวิร์กโฟลว์หลักสองประการ ได้แก่ การให้บริการคำขอค้นหาและการนำเข้าการอัปเดตจากไปพไลน์ประมวลผล

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

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

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

ขยาย

การออกแบบ Photon สำหรับเวิร์กโฟลว์ของเรา

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

การแสดงแทนข้อมูลสำหรับการดึงข้อมูลและการจัดอันดับ

การดึงข้อมูลและการจัดอันดับเข้าถึงข้อมูลเอกสารในลักษณะที่แตกต่างกัน การดึงข้อมูลแบบคำศัพท์ (Lexical Retrieval) จะเริ่มต้นด้วยคำในคิวรีและค้นหาเอกสารที่มีคำเหล่านั้น จากนั้นการจัดอันดับจะต้องการข้อมูลโดยละเอียดเกี่ยวกับเอกสารที่เลือกแต่ละฉบับ รวมถึงความถี่และตำแหน่งของคำด้วย

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

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

ดัชนีผกผัน (Inverted Index)

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

รายการสั้นจะใช้การแสดงแทนแบบอินไลน์ (Inline Representation) ซึ่งพอดีกับหน้าเดียวและไม่ต้องใช้ตารางบล็อก รายการที่ยาวกว่าซึ่งไม่พอดีกับรูปแบบอินไลน์จะถูกแบ่งออกเป็นบล็อกซึ่งครอบคลุมช่วงของตัวระบุเอกสาร (Document Identifier) ที่กำหนดไว้ การแสดงแทนของแต่ละบล็อกจะขึ้นอยู่กับความหนาแน่น: บล็อกแบบสแปรส (Sparse Block) จะจัดเก็บอาร์เรย์ของออฟเซ็ต ID เอกสารที่เรียงลำดับแล้ว ในขณะที่บล็อกแบบเดนส์ (Dense Block) จะใช้บิตแมป บล็อกแบบสแปรสใช้การค้นหาแบบก้าวกระโดด (Galloping Search) ซึ่งจะเลื่อนไปข้างหน้าด้วยขั้นตอนที่ใหญ่ขึ้นเรื่อยๆ เพื่อข้ามส่วนของรายการ บล็อกแบบเดนส์ช่วยให้สามารถตรวจสอบความเป็นสมาชิกได้โดยการค้นหาบิตที่สอดคล้องกับเอกสารนั้นๆ

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

ขยาย

การท่องผ่านรายการภายในงบประมาณการทำงาน

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

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

การให้คะแนนตัวเต็งจะรวมเอาความครอบคลุมของคำในคิวรีที่มีการถ่วงน้ำหนักและการมีส่วนร่วมของความถี่เข้าด้วยกัน พร้อมกับการปรับมาตรฐานความยาวเอกสาร (Document-Length Normalization) และการจำกัดกำไรสูงสุดจากคำที่ซ้ำกัน Photon จะตรวจสอบการมีอยู่ของคำในอาร์เรย์และบิตแมปก่อน เพื่อจำกัดคะแนนสูงสุดที่เป็นไปได้ของตัวเต็งแต่ละรายการ โดยจะอ่านความถี่ของคำที่แน่นอนเฉพาะสำหรับตัวเต็งที่มีโอกาสผ่านเกณฑ์การคัดเลือกเท่านั้น

จากนั้นการคัดเลือกจะดำเนินการในสามขั้นตอน:

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

อัลกอริทึมสร้างชุดตัวเต็งของเอกสารที่เกี่ยวข้องเพื่อนำไปใช้ในการจัดอันดับเพิ่มเติม

ขยาย

Docblob

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

รูปแบบนี้ถูกสร้างขึ้นเพื่อหลีกเลี่ยงการถอดรหัสเกินความจำเป็น ภายใน docblob ฟิลด์ต่างๆ จะถูกจัดกลุ่มตามตัววิเคราะห์ข้อความ แต่ละกลุ่มจะเก็บรายการคำที่เรียงลำดับแล้วซึ่งเข้ารหัสด้วย Elias-Fano ทำให้สามารถค้นหาคำในคิวรีได้โดยตรงโดยไม่ต้องขยายรายการทั้งหมดก่อน หน้ากากฟิลด์จะทำ 1 ตำแหน่งที่คำปรากฏ การนับความถี่จะติดตามความถี่ และตำแหน่งจริงจะอยู่ในบล็อกแยกต่างหากสำหรับแต่ละคู่คำ-ฟิลด์ที่เข้ารหัสเป็นความแตกต่างของตำแหน่ง เฉพาะบล็อกสำหรับคำที่ตรงกันจริงๆ เท่านั้นที่จะถูกถอดรหัส ในขณะที่ข้อมูลอื่นๆ ทั้งหมดในเรกคอร์ดจะยังคงอยู่ในรูปแบบที่บีบอัด

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

ขยาย

การอ่านแบบเป็นชุดและการทำงานกับหน่วยความจำ

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

ขยาย

การรอคอยดิสก์ที่ทับซ้อนกัน

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

Photon อาศัยข้อเท็จจริงที่ว่าออฟเซ็ตเรกคอร์ดเป็นสิ่งที่ทราบล่วงหน้า เราจึงสามารถส่งคำสั่งอ่านหลายรายการได้พร้อมกัน การดำเนินการนี้จัดการโดยรีแอคเตอร์ (Reactor): เธรดผู้ปฏิบัติงานเฉพาะกิจจะส่งชุดข้อมูลผ่าน io_uring และส่งข้อมูลที่อ่านไปยังโค้ดที่เรียกใช้ แต่ละเธรดจะจัดการ io_uring ของตนเอง โดยจะส่งชุดข้อมูลไปยังรีแอคเตอร์ที่มีภาระงานน้อยที่สุด ตัวอธิบายไฟล์ที่ลงทะเบียนไว้ล่วงหน้าและพูลบัฟเฟอร์ช่วยลดโอเวอร์เฮดของการอ่านซ้ำๆ การทำงานแบบอะซิงโครนัสนี้ช่วยให้การรอการดำเนินการหลายรายการทับซ้อนกันได้ ซึ่งช่วยลดค่าความหน่วงหาง (Tail Latency)

การลดจำนวนครั้งในการเข้าถึงไดรฟ์

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

แคชถูกออกแบบมาสำหรับการอ่านแบบเป็นชุด โดยเฉพาะอย่างยิ่ง:

• ไม่มีการจัดสรรแยกต่างหากเมื่อฮิต แต่ข้อมูลจะถูกคัดลอกลงในบัฟเฟอร์ที่เตรียมไว้ล่วงหน้าโดยโค้ดที่เรียกใช้
• ไม่มีการเข้าถึงล็อกโดยผู้อ่าน แต่จะตรวจสอบเวอร์ชันข้อมูลและลองใหม่หากขัดแย้งกับการเขียน
• ระบบนี้ใช้การขับออก (Eviction) แบบ CLOCK แทนที่จะต้องอัปเดตรายการ LRU ที่ใช้ร่วมกันในการอ่านทุกครั้ง
• ระบบนี้ใช้การดึงแคช CPU ล่วงหน้า (Prefetching) โดยเมทาดาต้าและข้อมูลสำหรับเรกคอร์ดที่กำลังจะมาถึงจะถูกร้องขอล่วงหน้า

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

การสร้างและการอัปเดตดัชนีแยกจากการให้บริการ

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

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

ขยาย

การเตรียมการและการสร้างแบบกระจาย

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

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

การปรับใช้เวอร์ชันใหม่

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

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

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

ขยาย

การย้ายระบบและการตรวจสอบความถูกต้องภายในสแต็กการค้นหาของเรา

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

การทดสอบโหลดและการประเมินผล

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

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

การปรับปรุงที่วัดได้จริงในการผลิตจริง

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

Photon ใช้เครื่องจักรให้บริการน้อยกว่าโหนดเนื้อหาของระบบเดิมประมาณ 20% ในขณะที่จัดเก็บข้อมูลต่อเอกสารมากกว่าประมาณ 2.5 เท่า หลังจากการย้ายระบบ เราได้ใช้ข้อมูลเพิ่มเติมนี้เพื่อปรับปรุงคุณภาพการจัดอันดับให้เหนือกว่าระบบเดิม

Photon ยังช่วยลดปริมาณข้อมูลที่ต้องเก็บไว้ในหน่วยความจำอีกด้วย การตรึง (Pinning) ชุดข้อมูล Photon เดียวกันใน RAM ด้วย mlock จะต้องใช้หน่วยความจำสำรองประมาณ 4.6 เท่าของหน่วยความจำที่ Photon ใช้ในปัจจุบัน

การประเมินค่าพรีเซ็ต Search API แบบเร็ว

นอกจากนี้ เรายังใช้ Photon เป็นพื้นฐานสำหรับค่าพรีเซ็ตแบบเร็วใหม่สำหรับ Search API ของเรา ซึ่งออกแบบมาสำหรับเวิร์กโหลดที่ไวต่อความหน่วง จากการวัดของเรา ค่าความหน่วงของการเรียกค้นหาครั้งเดียวสำหรับค่าพรีเซ็ตแบบเร็วคือ 160 มิลลิวินาทีที่ p50 และ 230 มิลลิวินาทีที่ p95 ซึ่งต่ำกว่าหรือเทียบเคียงได้กับตัวเลขที่ผู้ให้บริการ Search API รายอื่นรายงานด้วยตนเอง แม้ว่าเปอร์เซ็นต์ไทล์ส่วนหางที่รายงานจะมีความแตกต่างกันก็ตาม

เราได้ประเมินค่าพรีเซ็ตแบบเร็วบนเบนช์มาร์กแบบเอเจนต์หกรายการ ได้แก่ WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 และ SEAL-Hard จากการประเมินเหล่านี้ ระบบมี ต้นทุนรวมโดยประมาณของโมเดลและการค้นหาต่ำที่สุด และคะแนนงานรวมสูงสุด ในบรรดาการกำหนดค่าทั้งหมดที่ได้รับการทดสอบ

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

ขยาย

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

บทสรุป

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

Photon ช่วยให้การค้นหาเร็วขึ้นในผลิตภัณฑ์ของ Perplexity และเป็นรากฐานสำหรับค่าพรีเซ็ตแบบเร็วใหม่ของเราใน Search API หลังจากการย้ายระบบ ความหน่วงในการดึงข้อมูลและการจัดอันดับ p99 ลดลงจากประมาณ 800 มิลลิวินาทีเหลือ 65 มิลลิวินาที รูปแบบข้อมูลที่มีความหนาแน่นของเรายังช่วยให้เราสามารถจัดเก็บข้อมูลต่อเอกสารได้มากกว่าเดิม 2.5 เท่า ทำให้การดึงข้อมูลและการจัดอันดับสามารถเข้าถึงข้อมูลเอกสารที่สมบูรณ์ยิ่งขึ้น

ค่าพรีเซ็ตแบบเร็ว (Fast Preset) ให้ค่าความหน่วงของการเรียกค้นหาครั้งเดียวที่ 160 มิลลิวินาทีที่ p50 และ 230 มิลลิวินาทีที่ p95 จากการประเมินเบนช์มาร์กแบบเอเจนต์ทั้งหกรายการ ระบบนี้ช่วยลดต้นทุนโดยประมาณของโมเดลรวมกับการค้นหาต่อหนึ่งงานลง 68% เมื่อเทียบกับค่าพรีเซ็ตเริ่มต้น ในขณะที่ยังคงรักษาคุณภาพงานรวมที่เทียบเคียงกันได้ ผลลัพธ์เหล่านี้แสดงให้เห็นถึงประโยชน์เชิงปฏิบัติของโครงสร้างพื้นฐานที่ออกแบบมาเพื่อเวิร์กโหลดการค้นหาของเรา ทั้งสำหรับผลิตภัณฑ์ของ Perplexity และสำหรับนักพัฒนาที่สร้างสรรค์ผลงานด้วย API ของเรา

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

การอ้างอิง

@online{perplexity2026Photon,
  author = {{Perplexity} and Maksim Morozov and Bogdan Savko and Ruslan Kovalev and Aleksei Bykov and Artur Zayats and Denis Bykov and Nikita Kireev and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Photon: Building a retrieval and ranking engine from scratch}},
  date = {2026-09-24},
  url = {https://www.perplexity.ai/hub/blog/photon}
}