Photon: בניית מנוע אחזור ודירוג מאפס

מבוא

מחסנית החיפוש המקורית לבינה מלאכותית של Perplexity מאחר ומדרגת עמודי מועמדים, ומציפה את התוכן הרלוונטי ביותר עבור המודל כדי לבסס את תשובותיו. במקור, שלב זה פעל על מנוע קוד פתוח שהתאמנו למערכת שלנו. עם זאת, ככל שהאינדקס ועומסי העבודה שלנו גדלו, הגענו למגבלות קשות בעלויות, השהיית זנב וזמן התאוששות צמתים שלא יכולנו לפתור בתוך פלטפורמת צד שלישי קיימת.

כדי להתגבר על אתגרים אלו, בנינו את Photon, מנוע אחזור ודירוג חדש פנימי. דבר גישה זו ממשיך את הגישה שלנו של בניית תשתית חיפוש מבוססת-בינה מלאכותית מאפס, כפי שעשינו עם CobbleDB, חנות מפתח-ערך המבוזרת שלנו להגשת רשומות עמודים, ו-Search API שלנו.

Photon משתמש בפורמטים קומפקטיים של נתונים כדי לקרוא ולפענח רק את מה שכל שאילתה דורשת, תוך שימוש במטמון מודע-אצוות ובקריאות אסינכרוניות כדי להפחית את הגישה לדיסק ולחפוף המתנות. בניית האינדקס פועלת בנפרד מהגשת השאילתות, ומעעדכנת קבוצת הגשה אחת בכל פעם תוך חימום המטמונים שלה לפני ניתוב שאילתות חיות אליה.

פוטון מניע כעת את צנרת החיפוש שלנו ומהווה גם את הבסיס להגדרה מוקדמת מהירה חדשה עבור ממשק ה-API לחיפוש שלנו, עם השהיה של קריאת חיפוש יחידה של 160 אלפיות השנייה ב-p50 ו-230 אלפיות השנייה ב-p95. על פני שישה מדדי השוואה ציבוריים, ההגדרה המוקדמת המהירה הפחיתה את עלות המודל והחיפוש המשוערת למשימה ב-68% תוך שמירה על איכות משימה מצטברת הדומה להגדרה המוקדמת ברירת המחדל. אנו משחררים זאת היום כדי שמפתחים יוכלו לגשת לשיפורים אלו.

הגדלה

הגדלה

מה שמנוע האחזור והדירוג דורש

עבור כל שאילתות, מנוע האיתור והדירוג מחפש באינדקס מבוזר גדול כדי לבחור ולדרג קבוצה קטנה של עמודים רלוונטיים בתוך תקציב ההשהיה של מחסנית החיפוש. המערכת חייבת גם לשמור על האינדקס מעודכן ככל שמגיעים עמודים חדשים ועמודים קיימים משתנים, מבלי לאפשר לעבודה זו להאט שאילתות חיות.

הערכנו מספר אפשרויות קוד פתוח ובחרנו מנוע אחזור ודירוג כללי ובוגר שענה על הצרכים הראשוניים שלנו. לאחר מכן התאמנו אותו לארכיטקטורה ולעומסי העבודה שלנו, תוך שמירה על השהייה ותפוקה יציבות בקנה מידה של ייצור.

היכן שהמערכת הקודמת שלנו נפלה קצרה

שמרנו על מזלג משלנו כדי להתאים את המנוע לאינדקס הצומח שלנו, אך טיפול במגבלות מפתח דרש יותר ויותר עיצוב מחדש של חלקים גדולים מהפלטפורמה. מספר אילוצים התגלו כקשים לפתרון ללא שינויים ארכיטקטוניים בסיסיים:

1. עלויות סקיילביליות. הן מספר המסמכים שאנו מאחסנים והן כמות נתוני לכל-מסמך שאנו צריכים לאחזור ולדרג צמחו לאורך זמן. סקיילביליות זו הפעילה לחץ על החומרה שלנו, במיוחד על כמות ה-RAM הזמינה. כדי לשלוט בעלויות, נדרשנו לייצוגי נתונים קומפקטיים יותר ולשליטה מדויקת יותר במה שנשאר בזיכרון ובמה שנקרא מהדיסק לפי דרישה.

2. השהיית זנב גרועה. בתעבורת ייצור, זמן התגובה p99 של המערכת הישנה היה כ-800 אלפיות השנייה. מערך הנתונים חרג מה-RAM הזמין, כך שלא יכולנו להשתמש ב-mlock כדי לשמור אותו כולו בזיכרון. גישה לנתונים שאינם תושבים עלולה לעורר שגיאות עמוד עיקריות, ולעצור את ביצוע השאילתות בזמן שמערכת ההפעלה קוראת מהדיסק.

המנוע גם מיזג תקופתית את אינדקס הדיסק הראשי שלו עם אינדקסים קטנים יותר שנשטפו מהזיכרון. במהלך תהליך איחוד אינדקס דיסק זה, מספר שגיאות העמוד עלה אפילו יותר, כאשר השהיית p99 הגיעה לכ-1.2 שניות במשך 10–15 דקות. ככל שהמטמונים התחממו, תדירות שגיאות העמוד וההשהיה ירדו שתיהן, מה שמעיד על כך שקריאות קרות היו תורם מרכזי לשיאים. טעינת נתונים מראש וחימום האינדקס הפחיתו את השיאים אך לא טיפלו כראוי בהשהיית קצה גבוהה.

3. התאוששות וסנכרון ארוכים. במערכת הקודמת, פריסת אשכול נוסף וסנכרון הנתונים שלו עשויים לקחת יותר משבוע. סנכרון נדרש גם בעת הוספת קבוצות צמתים להחזקת עותקי נתונים נוספים או התאוששות מכשלים בצמתים. במהלך ההתאוששות, חלק גדול יותר מתשובות החיפוש היה חלקי, מה שהוריד את ציוני איכות התשובה הסופית.

בסופו של דבר, הגענו למסקנה שיהיה פשוט וזול יותר לבנות מאפס מאשר להמשיך להתאים ולתחזק את המזלג שלנו. תוך הסתמכות על הניסיון שלנו בהפעלת המערכת הקודמת, צוות הנדסה קטן עבד לצד נחיל של סוכני קידוד מתמשכים כדי לבנות את Photon.

היכן Photon משתלב במחסנית החיפוש

פוטון מתוכנן לשתי תהליך עבודה עיקריות: מתן מענה לבקשות חיפוש וקליטת עדכונים מצינור העיבוד.

בקשה משירות החיפוש ברמה הגבוהה יותר מגיעה לברוקר של פוטון דרך מאזן עומסים. הברוקר בוחר קבוצת שארדים ומעביר את הבקשה לכל שארד, תוך ניטור פסקי זמן והוצאת בקשות נוספות בעת הצורך.

כל שארד מבצע אחזור, דירוג ראשוני ודירוג שלב שני, ואז מחזיר את המועמדים הטובים ביותר שלו לברוקר. הברוקר משלב מועמדים אלו לרשימה מדורגת אחת ומביא שדות מסמכים מרכזיים עבור העמודים שנבחרו מהשארדים הרלוונטיים. לאחר מכן הוא מחזיר תוצאות אלו לשירות החיפוש ברמה הגבוהה יותר, המרכז את תוכן העמודים הנדרש לסוכן כדי לייצר תשובה מבוססת.

עדכוני אינדקס עוקבים אחר נתיב נפרד. Pillar, שכבת הפרסום שלנו, מכינה את הנתונים ומאחסנת אותם בטבלאות YTsaurus. מעדכני אינדקס ממירים טבלאות אלו למבני אינדקס ששארדים יכולים לטעון לצורך חיפוש. הבקר מתאם את הכנת הנתונים, בניית האינדקס ופריסת גרסאות אינדקס חדשות לקבוצות ההגשה. לפני טיפול בתנועה חיה, כל שארד משחזר שאילתות חיפוש אמיתיות כדי לחמם את המטמונים שלו.

הגדלה

תכנון פוטון עבור תהליך עבודה שלנו

שלוש בחירות עיצוב הופכות את Photon למתאים היטב לעומס העבודה שלנו: ייצוגי נתונים קומפקטיים, שמירה במטמון וקריאות דיסק אסינכרוניות, והפרדת עדכוני אינדקס מהגשת שאילתות.

ייצוגי נתונים לאחזור ודירוג

אחזור ודירוג ניגשים לנתוני מסמכים בצורה שונה. אחזור לקסיקלי מתחיל במונחי שאילתה ומוצא מסמכים המכילים אותם. הדירוג זקוק לאחר מכן למידע מפורט על כל מסמך שנבחר, כולל תדרי מונחים ומיקומים.

פוטון משתמש בשני ייצוגים משלימים כדי לתמוך בדפוסי גישה אלו. אינדקס הפוך מאחסן רשימת מסמכים תואמים לכל מונח, הנקראת רשימת פוסטים, כדי לתמוך בבחירת מועמדים. רשומות נפרדות לכל מסמך מספקות את הנתונים הדרושים לדירוג. אנו גם ממטבים את האופן שבו רשימות פוסטים מאוחסנות ועוברות עליהן כדי לשפר את הבחירה במסגרת תקציב עבודה קבוע.

ייצוגי נתונים מתמחים מאפשרים לנו לאחסן נתוני מפתח ביעילות רבה יותר. אינדקס הפוך קומפקטי יותר מפחית את כמות הנתונים שנקראת או מועברת לכל שאילתה, ומשפר את ההשהיה על ידי ביטול פעולות קלט/פלט מיותרות. פורמטים אלה גם מאפשרים לבדוק אם מסמך מופיע ברשימה מבלי לפענח אותו במלואו, תכונה שעליה לוגיקת המעבר שלנו מסתמכת כדי לשלוט בכמות העבודה ששאילתה מבצעת במסגרת תקציב קבוע. אופטימיזציה של רשומות לכל מסמך מאפשרת לנו לאחסן יותר נתונים לכל מסמך לצורך דירוג, ובמקביל מפחיתה את עלויות ההתרחבות הקשורות למערכת הקודמת שלנו.

האינדקס ההפוך

עבור כל מונח, האינדקס ההפוך מאחסן רשימת מופעים. רשימות אלה יכולות לנוע ממספר קטן של מסמכים ועד מיליונים, ולכן אף פורמט יחיד אינו מתאים היטב לכל רשימה. Photon בוחר את הפורמט על סמך מספר המסמכים שמכילים את המונח.

רשימות קצרות משתמשות בייצוג מוטבע שמתאים בתוך עמוד בודד ואינו דורש טבלת בלוקים. רשימות ארוכות יותר שאינן מתאימות לפורמט המוטבע מחולקות לבלוקים המכסים טווחים קבועים של מזהי מסמכים. הייצוג של כל בלוק תלוי בצפיפות שלו: בלוקים דלילים שומרים מערכים ממוינים של היסטים מזהי מסמכים, בעוד בלוקים צפופים משתמשים במפות סיביות. בלוקים דלילים משתמשים בחיפוש דילוג, המתקדם בצעדים הולכים וגדלים כדי לדלג על אזורים ברשימה. בלוקים צפופים מאפשרים בדיקות חברות על ידי חיפוש הסיביות המתאימות למסמך.

תדר השאילתות של מונח קובע היכן רשימת הפוסטים שלו ממוקמת בדיסק. רשימות הנשאלות לעתים קרובות מאוחסנות קרוב זו לזו, וממצות נתונים חמים באזור אחסון קטן יותר. בתוך כל רשימה, מסמכים מסודרים לפי אות שימושיות נפרד כך שמועמדים מבטיחים יותר נתקלים בהם מוקדם יותר.

הגדלה

מעבר על רשימות במסגרת תקציב עבודה

בחירת מועמדים דורשת מעבר על רשימות פרסום כדי למצוא מסמכים רלוונטיים פוטנציאליים. סריקה ממצה של כל רשימה יקרה, כך ש-Photon משתמש באלגוריתם דמוי-WAND שעובר רק על חלק מהרשימות תוך התחשבות עדיין בהתאמות באחרות.

האלגוריתם מחלק רשימות לשתי קבוצות. רשימות נהיגה מקדמות את המעבר ומציעות מסמכי מועמדים. רשימות בדיקה תורמות לציונים של מועמדים אלו אך אינן מייצרות מועמדים בעצמן.

ניקוד המועמדים משלב כיסוי מונחי שאילתות משוקלל ותרומת תדר, עם נורמליזציה של אורך המסמך ומגבלה על הרווחים ממונים חוזרים. פוטון בודק תחילה את נוכחות המונחים במערכים ובמפות סיביות כדי לתחום את הציון המרבי האפשרי של כל מועמד. הוא קורא תדרי מונחים מדויקים רק עבור מועמדים שעדיין עשויים לעמוד בסף הבחירה.

הבחירה ממשיכה בשלושה שלבים:

• מעבר: התחל עם דרישת כיסוי שאילתה קפדנית. אם נמצאים מעט מדי מועמדים, חזור על הפעולה עם דרישה מקלה.
• שימור: מועמדים מוחזקים בקבוצה תחומה באמצעות ציון המשלב כיסוי ותדירות. ככל שהמועמדים המובילים שנאספו משתפרים, סף הקבלה עולה.
• בחירה סופית: התוצאות הסופיות עבור המעבר נבחרו מתוך הקבוצה השמורה על בסיס ציוני התדירות. כל שדה מריץ מעבר משלו, והתוצאות מתמזגות באמצעות משקלי שדות.

האלגוריתם מייצר קבוצת מועמדים של מסמכים רלוונטיים לשימוש בדירוג נוסף.

הגדלה

Docblob

לאחר בחירת עמודי המועמדים, שלב הדירוג זקוק לתדרי מונחים, כיסוי שדות, והמיקומים והקרבה של הופעות. השגת נתונים אלו דרך האינדקס ההפוך דורשת גישות מבוזורות על פני זוגות מונח-מסמך רבים. בפוטון, אנו מאחסנים רשומה קומפקטית לכל מסמך בשם docblob המכילה תדרי מונחים, באילו שדות הופיע מונח, והיכן במסמך הוא התרחש. כתוצאה מכך, דירוג מועמד דורש רק חיפוש אחד לכל מסמך.

הפורמט בנוי כדי להימנע מפענוח מעבר לנדרש. בתוך docblob, השדות מקובצים לפי מנתח טקסט. כל קבוצה מאחסנת רשימת מונחים ממוינת המקודדת ב-Elias-Fano, כך שניתן לחפש מונח שאילתות ישירות מבלי להרחיב תחילה את כל הרשימה. מסכת שדה מסמנת היכן הופיע מונח, ספירת תדר עוקבת אחר התדירות, ומיקומים בפועל נמצאים בלוקים נפרדים לכל זוג מונח-שדה המקודדים כהפרשי מיקום. רק הבלוקים עבור מונחים שתאמו בפועל מפוענחים, בעוד שכל השאר ברשומה נשאר בפורמט הדחוס.

פענוח סלקטיבי זה מאפשר ל-docblob לתמוך באחסון נתונים רבים יותר לכל מסמך ללא עלייה פרופורציונלית בעלויות. הגדלת הרשומה אינה מחייבת עבודה רבה יותר לכל חיפוש, מכיוון שהדירוג נוגע תמיד רק בחלקים הרלוונטיים למונחים המותאמים ולא לרשומה כולה.

הגדלה

קריאות באצוות ועבודה עם זיכרון

אפילו עם ייצוגי הנתונים היעילים יותר, ה-RAM עדיין נגמר לפני משאבים אחרים, כך שאנו צריכים לגשת בתדירות גבוהה לנתונים המאוחסנים בדיסק. Photon משתמש בקריאות דיסק אסינכרוניות ובמטמון המותאם לקריאות אצוות כדי להאיץ גישות אלו, תוך קיצוץ זמן ההמתנה לכל בקשה. דבר זה תורם לשיפור משמעותי בהשהיית הזנב בהשוואה למערכת הקודמת.

הגדלה

חפיפת המתנות דיסק

דירוג דורש השגת תכונות של מאה מסמכים הממוקמים בחלקים שונים של קובץ. המערכת הקודמת שלנו השתמשה ב-mmap כדי למפות את הקובץ למרחב כתובות וירטואלי כך שניתן יהיה לקרוא אותו דרך מצביעי זיכרון. עם זאת, גישה לעמוד שלא היה נוכח בזיכרון עדיין דרשה קריאת דיסק. השרשור נאלץ להמתין לנתונים לפני המשך החישוב, וזמן המתנה זה הצטבר כאשר התהליך נדרש לקרוא רשומות קרות ברצף.

Photon מנצל את העובדה שמיקומי הרשומות ידועים מראש, כך שאנו יכולים להגיש כמה קריאות בבת אחת. הדבר מנוהל על ידי ה־reactor: שרשורי עבודה ייעודיים מגישים אצוות דרך io_uring ומעבירים את הנתונים שקראו לקוד הקורא. כל שרשור מחזיק io_uring משלו; האצוות נשלחות ל־reactor הפחות עמוס. מזהי קבצים רשומים מראש ומאגרי חוצצים מפחיתים את התקורה של קריאות חוזרות ונשנות. ביצוע אסינכרוני זה מאפשר לחכות לכמה פעולות בו־זמנית, וכך מפחית את השהיית הזנב.

הפחתת מספר הגישות לכונן

לפני שליחת קריאות, Photon בודק את כל האצווה במטמון שבזיכרון. רק בקשות לרשומות חסרות נשלחות לדיסק; הנתונים שנקראים ממלאים לאחר מכן את המטמון.

המטמון מיועד לקריאות באצווה. באופן ספציפי:

• אין הקצאה נפרדת בלחיצה. במקום זאת, הנתונים מועתקים למאגר שהוכן מראש על ידי הקוד הקורא.
• אין רכישת נעילה על ידי הקורא. במקום זאת, הוא בודק את גרסת הנתונים ומנסה שוב אם היא מתנגשת עם כתיבה.
• הוא מששתמש בפינוי CLOCK, במקום לדרוש עדכונים לרשימת LRU משותפת בכל קריאה.
• הוא משתמש בטעינה מקדימה של מטמון המעבד, שבו נתונים ומטא-נתונים עבור רשומות עתידיות מתבקשים מראש.

אופטימיזציות אלו מקטינות את ההשהיה מבלי לפגוע בביצועים בעומסי העבודה שאינם מעניינים אותנו.

בנייה ועדכון של האינדקס בנפרד מההגשה

ב-Photon, בניית אינדקס והגשת שאילתות פועלות על צמתים שונים. מאנדקסים מתירים נתונים למבני אחסון מוכנים, בזמן שצמתי הגשה קוראים אותם ומבצעים אחזור ודירוג. כתוצאה מכך, בניית אינדקס אינה מתחרה עם שאילתות חיפוש על מעבד, וניתן לשנות קנה מידה של משאבים עבור משימות אלו באופן עצמאי.

הפרדה זו מטפלת בצווארי הבקבוק של ההתאוששות והסנכרון הקיימים במימוש הקודם. מכיוון שבניית האינדקס פועלת בתוך אותו אשכול שהגיש שאילתות, התאוששות צומת שנכשל או הוספת עותק חדש של הנתונים עלולה להיות משמעה אינדוקס מחדש של מסמכים במקום, תהליך שלקח ימים והגדיל את התשובות החלקות במהלך ההתאוששות. פוטון מסיר צימוד זה; מעדכני אינדקס פועלים כמשרות מבוזורות המייצרות מבני אינדקס מוכנים להגשה בגרסאות באופן עצמאי מצומתי ההגשה, כך שבניית הגרסה הבאה של האינדקס אינה מתחרה עוד בתנועה חיה.

הגדלה

הכנה ובנייה מבוזרת

הבנייה מתחילה בבחירת מסמכים עבור האינדקס הפעיל והפקת ייצוא המקור. הבקר רושם את גרסת המקור, טבלאות הקלט ומספר השארדים הצפוי. משרות MapReduce ב-YTsaurus מכינות טקסט, מטא-דאטה, קטעים, מאפיינים ותיאורים מחושבים מראש לתוך טבלאות מנוסחות המחולקות לשארדים. כל מעדכן אינדקס מזרים את הטבלה שהוכנה, בונה את המבנים עבור השארד שלו וממזג מקטעי טקסט. האינדקס המוכן, יחד עם תיאור הרכיבים שלו, מועלה לאחסון האובייקטים.

מספר השארדים ומספר מעדכני האינדקס הפועלים במקביל מוגדרים באופן עצמאי, כך שבנייה יכולה לפעול בכמה גלים, או שניתן להקצות מחשבים נוספים לעבודה במקביל. הכנה מבוזרת ומעדכני אינדקס מקביליים מאפשרים לבנות את אינדקס האינטרנט המלא במספר חד-ספרתי של שעות, שיפור משמעותי לעומת המערכת הקודמת.

פריסת גרסה חדשה

לפני פריסה, הבקר בודק שהאינדקס החדש מוכן. אם הנתונים אינם שלמים, הפריסה נחסמת באופן אוטומטי.

כאשר ישנן מספר קבוצות הגשה, הבקר מעדכן אותן אחת אחת. הוא תחילה מסיר קבוצה מניתוב הברוקר ומתחיל אותה בגרסת האינדקס החדשה. לפני מתן מענה לבקשות, השארדים עוברים שלב חימום נפרד המבוסס על יומני חיפוש, המאכלס מראש את המצב הראשוני והופך את המעבר לתנועה אמיתית לחלק יותר. לאחר החימום, הבקר בודק את מצב האינדקס והמוכנות, ואז מחזיר את הקבוצה לניתוב. שאר הקבוצות ממשיכות להגיש בקשות במהלך זמן זה. מכיוון שמצב הפעולה נשמר, הפעלה מחדש אינה מאלצת בנייה להתחיל מחדש; הבקר יכול לחבר מחדש להכנה שכבר בעיצומה, לעשות שימוש חוזר בתוצאה מוכנה, או להמשיך סיבוב מופרע מהשלב השמור.

זמני עדכון הנתונים שונים בין תחומי חיפוש. עבור תחומים בעלי דרישות רעננות גבוהות, אספקת המסמכים לוקחת מספר חד-ספרתי של דקות. עותק נוסף של הנתונים ניתן לפרוס תוך כשחצי שעה; אינדקסים מוכנים נטענים ומחוברים לשארדים מבלי לאנדקס מחדש את מסמכי המקור.

הגדלה

הגירה ואימות בתוך מחסנית החיפוש שלנו

המטרה הראשונה שלנו הייתה להחליף את המערכת הישנה במנוע ששמר על הפונקציונליות ועל איכות החיפוש, תוך הפחתת זמני התגובה. אימתנו את Photon בשלבים, החל מבדיקות עומס שניתן לשחזר והערכות איכות לא מקוונות, לפני שעברנו לתעבורה חיה. Photon מפעיל כעת את השליפה ואת הדירוג בערימת החיפוש בייצור שלנו, עם זמני תגובה נמוכים משמעותית מהמערכת הישנה.

בדיקות עומס והערכות

לצורך בדיקות ביצועים, בנינו כלי בדיקת עומסים המשחזר שאילתות מיומני החיפוש שלנו בקצבי הגעה ניתנים להגדרה. הוא משווה תוצאות בין ריצות ומחיל מבחנים סטטיסטיים כדי להעריך האם הבדלי הביצועים הנצפים עקביים. בנפרד, הערכנו את Photon ואת המערכת הישנה על אותם מערכי נתונים במערכות ההערכה הלא מקוונות הפנימיות שלנו כדי לבדק נסיגות איכות.

לאחר בדיקות אלו, שלחנו שאילתות חי לשתי המנועים בו-זמנית תוך שימוש בתעבורת צל. דבר זה אפשר לנו להשוות את הביצועים והתוצאות שלהם בעומסי עבודה של ייצור לפני שינוי המנוע ששימש את המשתמשים. לאחר מכן הפעלנו את Photon עבור קבוצות משתמשים קטנות והרחבנו בהדרגה את הפריסה, תוך ניטור איכות וביצועים לאורך כל הדרך. הגרסה הראשונה עברה את בדיקות הקבלה ללא נסיגות איכות, והמשכנו את הפריסה עד ש-Photon שירת את כל תעבורת הייצור.

שיפורים נמדדים בייצור

בתהליך העבודה של הייצור שלנו, זמן התגובה p99 ירד בקירוב מ-800 אלפיות השנייה במערכת הישנה לכ-65 אלפיות השנייה ב-Photon. מדידה זו מכסה את כל השלבים בתוך Photon, אך מוציאה מכלל זה שלבים עוקבים במחסנית החיפוש ברמה הגבוהה יותר. אנו גם לא מבחינים עוד בשיאי ההשהייה שהיו קשורים בעבר להחלפת גרסאות אינדקס.

Photon משתמש בכ-20% פחות מכונות הגשה שקולות מאשר צמתי התוכן של המערכת הישנה תוך אחסון של כ-2.5 יותר נתונים לכל מסמך. לאחר ההגירה, השתמשנו בנתונים נוספים אלו כדי לשפר את איכות הדירוג מעבר לזו של המערכת הישנה.

Photon מפחית גם את כמות הנתונים שחייבים להישאר בזיכרון. הצמדת אותו מערך נתונים של Photon ב-RAM עם mlock הייתה דורשת זיכרון תושב מוערך פי 4.6 ממה ש-Photon משתמש בו כיום.

הערכת ההגדרה המהירה של Search API

השתמשנו ב-Photon גם כבסיס להגדרה מוקדמת מהירה חדשה עבור ה-API של החיפוש שלנו, המיועדת לעומסי עבודה רגישים להשהייה. לפי מדידותינו, השהיית קריאת-חיפוש בודדת עבור ההגדרה המהירה היא 160 אלפיות השנייה ב-p50 ו-230 אלפיות השנייה ב-p95, נמוכה או שוות ערך למספרים המדווחים עצמית של ספקי API חיפוש אחרים, למרות שאחוזוני הזנב המדווחים שונים.

הערכנו את ההגדרה המוקדמת המהירה בשישה מדדי ביצוע סוכנים: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 ו-SEAL-Hard. על פני הערכות אלו, הייתה לה עלות המודל והחיפוש הכוללת המשוערת הנמוכה ביותר וציון המשימה המצטברת הגבוה ביותר בין התצורות שנבדקו.

ההגדרה המהירה משדכת את Photon לדירוג המותאם לתהליכי עבודה סוכניים, ומספקת ביצועים מקבילים להגדרת ברירת המחדל בעלות נמוכה משמעותית. עם זאת, היא מגיעה עם פשרה באיכות חיפוש רחבה יותר. ההגדרה המהירה משתמשת בפחות חישוב לדירוג מאשר הגדרת ברירת המחדל. במדדי השוואה פנימיים המכסים שאילתות זנב ארוך, כיסוי רחב וגיוון תוצאות, היא מקבלת ציון נמוך ב-0.24 נקודות ברלוונטיות וכ-3 אחוזים נמוך יותר בזמינות תשובות. אנו מאמינים שזו פשרה הגיונית לתהליכי עבודה סוכניים, מכיוון שההנמקה והידע של המודל עצמו יכולים לעזור לפצות על ההבדל.

הגדלה

אנו ממליצים על ההגדרה המהירה למשימות סוכניות שגרתיות. עבור שאלות מאתגרות או מעורפלות יותר שאינן רגישות לזמן, הגדרת ברירת המחדל מציעה איכות חסונה יותר, הצדקת השהות והעלות הגבוהות יותר שלה.

סיכום

אנו מעבירים בהתמדה את מחסנית החיפוש שלנו לתשתית פנימית מבוססת-Rust. החלפת מנוע הקוד הפתוח ב-Photon, מנוע האחזור והדירוג המותאם אישית שלנו, היא השלב האחרון. Photon מעניק לנו שליטה מלאה על ייצוגי הנתונים, אופן ארגון הקריאות, ופריסת אינדקסים חדשים, ומאפשר לנו לייעל כל שכבה עבור עומסי העבודה שלנו.

פוטון אפשר חיפוש מהיר יותר במוצרים של Perplexity ומספק את הבסיס להגדרה המוקדמת המהירה החדשה שלנו ב-Search API. בעקבות המיגרציה, השהיית האיתור והדירוג של p99 ירדה בערך מ-800 אלפיות השנייה ל-65 אלפיות השנייה. פורמטי הנתונים הקומפקטיים שלנו גם מאפשרים לנו לאחסן פי 2.5 יותר נתונים לכל מסמך, מה שמעניק לאיתור ודירוג גישה למידע מסמכים עשיר יותר.

ההגדרה המוקדמת המהירה מספקת השהיית קריאת-חיפוש בודדת של 160 אלפיות השנייה ב-p50 ו-230 אלפיות השנייה ב-p95. על פני ששת מדדי ההשוואה הסוכניים שנבחנו, היא הפחיתה את עלות המודל-פלוס-חיפוש המשוערת למשימה ב-68% ביחס להגדרת הברירת המחדל תוך שמירה על איכות משימה כוללת מקבילה. תוצאות אלו מדגימות את היתרונות המעשיים של תשתית המתוכננת סביב עומסי העבודה של החיפוש שלנו, הן עבור המוצרים של Perplexity והן עבור מפתחים הבונים באמצעות ה-API שלנו.

אנו ממשיכים לשפר את הביצועים ויעילות האחסון של פוטון. המטרה שלנו היא לתמוך באינדקס גדול יותר ובנתוני מסמכים עשירים יותר באותו חומרה תוך שמירה על חיפוש מהיר ככל שעומסי העבודה שלנו גדלים.

ציטוט

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