ఫోటాన్: మొదటి నుండి రిట్రీవల్ మరియు ర్యాంకింగ్ ఇంజిన్ను బిల్డ్ చేయడం
ప్రత్యేకమైన డేటా ఫార్మాట్లు, బ్యాచ్డ్ రీడ్లు మరియు ఇండెక్స్ బిల్డింగ్ను క్వెరీ సర్వింగ్ నుండి వేరు చేయడం AI-నేటివ్ శోధనను ఎలా మెరుగుపరుస్తాయో తెలుసుకోండి.
పరిచయం
Perplexity యొక్క AI-నేటివ్ సెర్చ్ స్టాక్ అభ్యర్థి పేజీలను పునరుద్ధరిస్తుంది మరియు ర్యాంక్ చేస్తుంది, మోడల్ తన సమాధానాలను గ్రౌండ్ చేయడానికి అత్యంత సంబంధిత కంటెంట్ను పైకి తెస్తుంది. మొదట, ఈ దశ మేము మా సిస్టమ్కు అడాప్ట్ చేసిన ఓపెన్-సోర్స్ ఇంజిన్పై రన్ అయింది. అయితే, మా ఇండెక్స్ మరియు వర్క్లోడ్లు పెరిగేకొద్దీ, మేము ఇప్పటికే ఉన్న థర్డ్-పార్టీ ప్లాట్ఫారమ్ లోపల పరిష్కరించలేని ఖర్చులు, టెయిల్ లేటెన్సీ మరియు నోడ్ రికవరీ సమయంపై కఠినమైన పరిమితులను ఎదుర్కొన్నాము.
ఈ సవాళ్లను అధిగమించడానికి, మేము కొత్త ఇన్-హౌస్ రిట్రీవల్ మరియు ర్యాంకింగ్ ఇంజిన్ అయిన ఫోటాన్ను బిల్డ్ చేసాము. పేజ్ రికార్డులను సర్వ్ చేయడానికి మా డిస్ట్రిబ్యూటెడ్ కీ-వాల్యూ స్టోర్ అయిన CobbleDB మరియు మా Search APIతో మేము చేసినట్లుగా, AI-ఫస్ట్ సెర్చ్ ఇన్ఫ్రాస్ట్రక్చర్ను మొదటి నుండి బిల్డ్ చేసే మా విధానాన్ని ఇది కొనసాగిస్తుంది.
ప్రతి క్వెరీకి ఏది అవసరమో దాన్ని మాత్రమే చదవడానికి మరియు డీకోడ్ చేయడానికి ఫోటాన్ కాంపాక్ట్ డేటా ఫార్మాట్లను ఉపయోగిస్తుంది. డిస్క్ యాక్సెస్ను తగ్గించడానికి మరియు వేచి ఉండే సమయాలను అతివ్యాప్తం చేయడానికి ఇది బ్యాచ్-అవేర్ కాషింగ్ మరియు అసమకాలిక రీడ్లను ఉపయోగిస్తుంది. ఇండెక్స్ బిల్డింగ్ అనేది క్వెరీ సర్వింగ్ నుండి విడిగా రన్ అవుతుంది, ఒక సమయంలో ఒక సర్వింగ్ గ్రూప్ను అప్డేట్ చేస్తుంది మరియు లైవ్ క్వెరీలను దానికి రూట్ చేయడానికి ముందు దాని కాష్లను వార్మ్ చేస్తుంది.
ఫోటాన్ ఇప్పుడు మా సెర్చ్ పైప్లైన్కు శక్తినిస్తుంది మరియు మా సెర్చ్ API కోసం కొత్త ఫాస్ట్ ప్రీసెట్కు ఆధారం కూడా, p50 వద్ద 160 ms మరియు p95 వద్ద 230 ms సింగిల్-సెర్చ్-కాల్ లేటెన్సీని కలిగి ఉంది. ఆరు పబ్లిక్ బెంచ్మార్క్లలో, డిఫాల్ట్ ప్రీసెట్తో పోల్చదగిన సగటు టాస్క్ నాణ్యతను నిర్వహిస్తూనే, ఫాస్ట్ ప్రీసెట్ టాస్క్కు అంచనా వేయబడిన మోడల్-ప్లస్-సెర్చ్ ఖర్చును 68% తగ్గించింది. డెవలపర్లు ఈ మెరుగుదలలను యాక్సెస్ చేయడానికి వీలుగా మేము దీన్ని ఈరోజే విడుదల చేస్తున్నాము.
పునరుద్ధరణ (Retrieval) మరియు ర్యాంకింగ్ ఇంజిన్కు ఏమి అవసరం
ప్రతి క్వెరీ కోసం, రిట్రీవల్ మరియు ర్యాంకింగ్ ఇంజిన్ సెర్చ్ స్టాక్ యొక్క లేటెన్సీ బడ్జెట్ లోపు తగినన్ని చిన్న సెట్ పేజీలను ఎంచుకోవడానికి మరియు ఆర్డర్ చేయడానికి పెద్ద, డిస్ట్రిబ్యూటెడ్ ఇండెక్స్ను శోధిస్తుంది. లైవ్ క్వెరీలు నెమ్మదించేలా చేయకుండా, కొత్త పేజీలు వచ్చినప్పుడు మరియు ఇప్పటికే ఉన్న పేజీలు మారినప్పుడు సిస్టమ్ ఇండెక్స్ను తాజాగా ఉంచాలి.
మేము అనేక ఓపెన్-సోర్స్ ఎంపికలను మూల్యాంకనం చేసాము మరియు మా ప్రారంభ అవసరాలను తీర్చిన పరిణతి చెందిన, జనరల్-పర్పస్ రిట్రీవల్ మరియు ర్యాంకింగ్ ఇంజిన్ను ఎంచుకున్నాము. ఆ తర్వాత మేము ప్రొడక్షన్ స్థాయిలో స్థిరమైన లేటెన్సీ మరియు త్రూపుట్ను నిర్వహిస్తూ, దానిని మా ఆర్కిటెక్చర్ మరియు వర్క్లోడ్లకు అడాప్ట్ చేసాము.
మా మునుపటి సిస్టమ్ ఎక్కడ వెనుకబడింది
పెరుగుతున్న మా ఇండెక్స్కు ఇంజిన్ను అడాప్ట్ చేయడానికి మేము మా స్వంత ఫోర్క్ను మెయింటైన్ చేసాము, అయితే కీలకమైన పరిమితులను పరిష్కరించడానికి ప్లాట్ఫారమ్లోని పెద్ద భాగాలను రీడిజైన్ చేయడం ఎక్కువగా అవసరమైంది. ప్రాథమిక ఆర్కిటెక్చరల్ మార్పులు లేకుండా అనేక నిరోధకాలను పరిష్కరించడం కష్టమని తేలింది:
1. స్కేలింగ్ ఖర్చులు. మేము నిల్వ చేసే డాక్యుమెంట్ల సంఖ్య మరియు మేము పునరుద్ధరించాల్సిన మరియు ర్యాంక్ చేయాల్సిన పర్-డాక్యుమెంట్ డేటా మొత్తం కాలక్రమేణా పెరుగుతున్నాయి. ఈ స్కేలింగ్ మా హార్డ్వేర్పై ఒత్తిడి తెచ్చింది, ముఖ్యంగా అందుబాటులో ఉన్న RAM మొత్తంపై. ఖర్చులను నియంత్రించడానికి, మరింత కాంపాక్ట్ డేటా రిప్రజెంటేషన్లు మరియు మెమరీలో ఏది ఉండాలి మరియు డిస్క్ నుండి డిమాండ్పై ఏది చదవాలి అనేదానిపై చక్కటి నియంత్రణ మాకు అవసరమైంది.
2. పేలవమైన టెయిల్ లేటెన్సీ. ప్రొడక్షన్ ట్రాఫిక్పై, పాత సిస్టమ్ యొక్క p99 రెస్పాన్స్ సమయం సుమారు 800 msగా ఉంది. డేటాసెట్ అందుబాటులో ఉన్న RAMను మించిపోయింది, కాబట్టి దానిని పూర్తిగా మెమరీలో ఉంచడానికి మేము mlockని ఉపయోగించలేకపోయాము. నాన్-రెసిడెంట్ డేటాను యాక్సెస్ చేయడం వల్ల మేజర్ పేజ్ ఫాల్ట్లు ట్రిగ్గర్ కావచ్చు, ఆపరేటింగ్ సిస్టమ్ డిస్క్ నుండి చదివే సమయంలో క్వెరీ ఎగ్జిక్యూషన్ను నిలిపివేయవచ్చు.
ఇంజిన్ కూడా కాలానుగుణంగా దాని ప్రధాన డిస్క్ ఇండెక్స్ను మెమరీ నుండి ఫ్లష్ చేయబడిన చిన్న ఇండెక్స్లతో మర్జ్ చేసింది. ఈ డిస్క్ ఇండెక్స్ ఫ్యూషన్ ప్రక్రియలో, పేజ్ ఫాల్ట్ల సంఖ్య మరింత పెరిగింది, 10-15 నిమిషాల పాటు p99 లేటెన్సీ సుమారు 1.2 సెకనులకు చేరుకుంది. కాష్లు వార్మ్ అయినప్పుడు, పేజ్ ఫాల్ట్ల ఫ్రీక్వెన్సీ మరియు లేటెన్సీ రెండూ తగ్గాయి, కోల్డ్ రీడ్లు స్పైక్లకు ప్రధాన కారణమని సూచిస్తున్నాయి. డేటాను ముందే లోడ్ చేయడం మరియు ఇండెక్స్ను వార్మ్ చేయడం వల్ల స్పైక్లు తగ్గాయి కానీ అధిక టెయిల్ లేటెన్సీని తగిన విధంగా పరిష్కరించలేదు.
3. సుదీర్ఘమైన రికవరీ మరియు సింక్రొనైజేషన్. మునుపటి సిస్టమ్లో, అదనపు క్లస్టర్ను డిప్లాయ్ చేయడానికి మరియు దాని డేటాను సింక్రొనైజ్ చేయడానికి ఒక వారానికి పైగా పట్టవచ్చు. అదనపు డేటా కాపీలను ఉంచడానికి నోడ్ల సమూహాలను జోడించేటప్పుడు లేదా నోడ్ వైఫల్యాల నుండి కోలుకునేటప్పుడు కూడా సింక్రొనైజేషన్ అవసరమవుతుంది. రికవరీ సమయంలో, శోధన ప్రతిస్పందనలలో ఎక్కువ భాగం పాక్షికంగా ఉండేవి, ఇది తుది-సమాధాన నాణ్యత స్కోర్లను తగ్గించింది.
అంతిమంగా, మా ఫోర్క్ను అడాప్ట్ చేయడం మరియు మెయింటైన్ చేయడం కొనసాగించడం కంటే మొదటి నుండి బిల్డ్ చేయడం సులభం మరియు చౌకైనది అని మేము నిర్ధారణకు వచ్చాము. మునుపటి సిస్టమ్ను ఆపరేట్ చేయడంలో మా అనుభవాన్ని ఉపయోగించుకుని, ఒక చిన్న ఇంజనీరింగ్ టీమ్ పర్సిస్టెంట్ కోడింగ్ ఏజెంట్లతో కలిసి ఫోటాన్ను రూపొందించింది.
సెర్చ్ స్టాక్లో ఫోటాన్ ఎక్కడ సరిపోతుంది
ఫోటాన్ రెండు ప్రాథమిక వర్క్ఫ్లోల కోసం రూపొందించబడింది: శోధన అభ్యర్థనలను సర్వ్ చేయడం మరియు ప్రాసెసింగ్ పైప్లైన్ నుండి అప్డేట్లను ఇన్జెస్ట్ చేయడం.
హై-లెవెల్ సెర్చ్ సర్వీస్ నుండి వచ్చే అభ్యర్థన లోడ్ బ్యాలెన్సర్ ద్వారా ఫోటాన్ బ్రోకర్ను చేరుకుంటుంది. బ్రోకర్ షార్డ్ గ్రూప్ను ఎంచుకుని, అభ్యర్థనను ప్రతి షార్డ్కు ఫార్వార్డ్ చేస్తుంది, టైమ్అవుట్లను పర్యవేక్షిస్తుంది మరియు అవసరమైనప్పుడు అదనపు అభ్యర్థనలను జారీ చేస్తుంది.
ప్రతి షార్డ్ పునరుద్ధరణ (Retrieval), ప్రారంభ ర్యాంకింగ్ మరియు రెండవ-దశ ర్యాంకింగ్ను నిర్వహిస్తుంది, ఆపై దాని ఉత్తమ అభ్యర్థులను బ్రోకర్కు తిరిగి ఇస్తుంది. బ్రోకర్ ఈ అభ్యర్థులను ఒకే ర్యాంక్ చేయబడిన జాబితాలోకి మిళితం చేస్తుంది మరియు సంబంధిత షార్డ్ల నుండి ఎంచుకున్న పేజీల కోసం కీలకమైన డాక్యుమెంట్ ఫీల్డ్లను ఫెచ్ చేస్తుంది. ఆపై అది ఈ ఫలితాలను హై-లెవెల్ సెర్చ్ సర్వీస్కు తిరిగి ఇస్తుంది, ఇది ఏజెంట్ గ్రౌండెడ్ సమాధానాన్ని రూపొందించడానికి అవసరమైన పేజీ కంటెంట్ను సేకరిస్తుంది.
ఇండెక్స్ అప్డేట్లు ప్రత్యేక మార్గాన్ని అనుసరిస్తాయి. మా పబ్లిషింగ్ లేయర్ అయిన పిల్లర్ డేటాను సిద్ధం చేసి YTsaurus టేబుళ్లలో నిల్వ చేస్తుంది. ఇండెక్సర్లు ఈ టేబుళ్లను శోధన కోసం షార్డ్లు లోడ్ చేయగల ఇండెక్స్ స్ట్రక్చర్లుగా మారుస్తాయి. కంట్రోలర్ డేటా ప్రిపరేషన్, ఇండెక్స్ బిల్డింగ్ మరియు సర్వింగ్ గ్రూప్లకు కొత్త ఇండెక్స్ వెర్షన్ల డిప్లాయ్మెంట్ను సమన్వయం చేస్తుంది. లైవ్ ట్రాఫిక్ను నిర్వహించే ముందు, ప్రతి షార్డ్ దాని కాష్లను వార్మ్ చేయడానికి నిజమైన సెర్చ్ క్వెరీలను రీప్లే చేస్తుంది.
మా వర్క్ఫ్లోల కోసం ఫోటాన్ను డిజైన్ చేయడం
మూడు డిజైన్ ఎంపికలు ఫోటాన్ను మా వర్క్లోడ్కు బాగా సరిపోయేలా చేస్తాయి: కాంపాక్ట్ డేటా రిప్రజెంటేషన్లు, కాషింగ్ మరియు అసమకాలిక డిస్క్ రీడ్లు, మరియు ఇండెక్స్ అప్డేట్లను క్వెరీ సర్వింగ్ నుండి వేరు చేయడం.
పునరుద్ధరణ (Retrieval) మరియు ర్యాంకింగ్ కోసం డేటా ప్రాతినిధ్యాలు
పునరుద్ధరణ (Retrieval) మరియు ర్యాంకింగ్ డాక్యుమెంట్ డేటాను భిన్నంగా యాక్సెస్ చేస్తాయి. లెక్సికల్ రిట్రీవల్ క్వెరీ టర్మ్లతో ప్రారంభమవుతుంది మరియు వాటిని కలిగి ఉన్న డాక్యుమెంట్లను కనుగొంటుంది. అప్పుడు ర్యాంకింగ్కు పదం యొక్క ఫ్రీక్వెన్సీలు మరియు స్థానాలతో సహా ఎంచుకున్న ప్రతి డాక్యుమెంట్ గురించిన వివరణాత్మక సమాచారం అవసరం.
ఫోటాన్ ఈ యాక్సెస్ నమూనాలను మద్దతు ఇవ్వడానికి పరస్పరం పూరకమైన రెండు ప్రతినిధీకరణలను ఉపయోగిస్తుంది. ఒక ఇన్వర్టెడ్ ఇండెక్స్ ప్రతి టర్మ్కు సరిపోలిన పత్రాల జాబితాను, పోస్టింగ్ లిస్ట్గా పిలువబడేది, candidate selectionను మద్దతు ఇవ్వడానికి నిల్వ చేస్తుంది. వేర్వేరు ప్రతి-పత్రం రికార్డులు ర్యాంకింగ్కు అవసరమైన డేటాను అందిస్తాయి. ఫిక్స్డ్ వర్క్ బడ్జెట్లో selectionను మెరుగుపరచడానికి పోస్టింగ్ లిస్టులు ఎలా నిల్వ చేయబడతాయి మరియు ఎలా traversal చేయబడతాయన్నదాన్నీ మేము ఆప్టిమైజ్ చేస్తాము.
ప్రత్యేకీకృత డేటా ప్రతినిధీకరణలు కీలక డేటాను మరింత సమర్థవంతంగా నిల్వ చేయడానికి మాకు సహాయపడతాయి. మరింత సంక్షిప్తమైన ఇన్వర్టెడ్ ఇండెక్స్ ప్రతి ప్రశ్నకు చదవబడే లేదా తరలించబడే డేటా పరిమాణాన్ని తగ్గించి, అవసరం లేని I/O కార్యకలాపాలను తొలగించడం ద్వారా లేటెన్సీని మెరుగుపరుస్తుంది. ఈ ఫార్మాట్లు ఒక పత్రం పూర్తిగా డీకోడ్ చేయకుండా జాబితాలో కనిపిస్తుందా లేదా అన్నది తనిఖీ చేయడాన్ని కూడా సాధ్యంగా చేస్తాయి; ఫిక్స్డ్ బడ్జెట్ కింద ఒక ప్రశ్న ఎంత పని చేస్తుందో నియంత్రించడానికి మా ట్రావర్సల్ లాజిక్ ఈ లక్షణంపై ఆధారపడుతుంది. ప్రతి పత్రానికి సంబంధించిన రికార్డులను ఆప్టిమైజ్ చేయడం వల్ల ర్యాంకింగ్ కోసం ప్రతి పత్రానికి మరింత డేటాను నిల్వ చేయగలుగుతాము, అలాగే మా పూర్వ వ్యవస్థతో సంబంధించి ఉన్న స్కేలింగ్ ఖర్చులను కూడా తగ్గిస్తుంది.
ఇన్వర్టెడ్ ఇండెక్స్
ప్రతి పదం కోసం, ఇన్వర్టెడ్ ఇండెక్స్ ఒక పోస్టింగ్ జాబితాను నిల్వ చేస్తుంది. ఈ జాబితాలు కొన్ని డాక్యుమెంట్ల నుండి మిలియన్ల కొద్దీ ఉండవచ్చు, కాబట్టి ఏ ఒక్క ఫార్మాట్ ప్రతి జాబితాకు బాగా పనిచేయదు. పదాన్ని కలిగి ఉన్న డాక్యుమెంట్ల సంఖ్య ఆధారంగా ఫోటాన్ ఫార్మాట్ను ఎంచుకుంటుంది.
చిన్న జాబితాలు ఒకే పేజీలో సరిపోయే మరియు బ్లాక్ టేబుల్ అవసరం లేని ఇన్లైన్ రిప్రజెంటేషన్ను ఉపయోగిస్తాయి. ఇన్లైన్ ఫార్మాట్కు సరిపోని పొడవైన జాబితాలు డాక్యుమెంట్ ఐడెంటిఫైయర్ల నిర్దిష్ట శ్రేధులను కవర్ చేసే బ్లాక్లుగా విభజించబడ్డాయి. ప్రతి బ్లాక్ యొక్క రిప్రజెంటేషన్ దాని డెన్సిటీపై ఆధారపడి ఉంటుంది: స్పార్స్ బ్లాక్లు డాక్యుమెంట్-ID ఆఫ్సెట్ల సార్ట్ చేయబడిన అర్రేలను నిల్వ చేస్తాయి, అయితే డెన్సర్ బ్లాక్లు బిట్మ్యాప్లను ఉపయోగిస్తాయి. స్పార్స్ బ్లాక్లు గ్యాల్పింగ్ సెర్చ్ను ఉపయోగిస్తాయి, ఇది జాబితా యొక్క ప్రాంతాలను దాటవేయడానికి పెరుగుతున్న పెద్ద దశల్లో ముందుకు సాగుతుంది. డెన్స్ బ్లాక్లు డాక్యుమెంట్కు అనుగుణమైన బిట్ను లుకప్ చేయడం ద్వారా మెంబర్షిప్ చెక్లను అనుమతిస్తాయి.
ఒక పదం యొక్క క్వెరీ ఫ్రీక్వెన్సీ దాని పోస్టింగ్ జాబితా డిస్క్లో ఎక్కడ ఉంచబడుతుందో నిర్ణయిస్తుంది. తరచుగా క్వెరీ చేయబడే జాబితాలు ఒకదానికొకటి దగ్గరగా నిల్వ చేయబడతాయి, హాట్ డేటాను చిన్న నిల్వ ప్రాంతంలో కేంద్రీకరిస్తాయి. ప్రతి జాబితాలో, డాక్యుమెంట్లు వేర్వేరు ఉపయోగకరమైన సిగ్నల్ ద్వారా ఆర్డర్ చేయబడతాయి, తద్వారా మరింత వాగ్దానం చేసే అభ్యర్థులు ముందుగా ఎదురవుతారు.
వర్క్ బడ్జెట్లో జాబితాలను ట్రావర్స్ చేయడం
అభ్యర్థి ఎంపికకు సంభావ్యంగా సంబంధిత డాక్యుమెంట్లను కనుగొనడానికి పోస్టింగ్ జాబితాలను ట్రావర్స్ చేయడం అవసరం. ప్రతి జాబితాను సమగ్రంగా స్కాన్ చేయడం ఖర్చుతో కూడుకున్నది, కాబట్టి ఫోటాన్ WAND లాంటి అల్గోరిథిమ్ను ఉపయోగిస్తుంది, ఇది కొన్ని జాబితాలను మాత్రమే ట్రావర్స్ చేస్తుంది కానీ మిగిలిన వాటిలో మ్యాచ్లను లెక్కలోకి తీసుకుంటుంది.
అల్గోరిథం జాబితాలను రెండు గ్రూప్లుగా విభజిస్తుంది. డ్రైవింగ్ జాబితాలు ట్రావెర్సల్ను ముందుకు నడిపిస్తాయి మరియు అభ్యర్థి డాక్యుమెంట్లను ప్రతిపాదిస్తాయి. ప్రోబ్ జాబితాలు ఆ అభ్యర్థుల స్కోర్లకు సహకరిస్తాయి కానీ అభ్యర్థులను అవే స్వయంగా సృష్టించవు.
అభ్యర్థి స్కోరింగ్ అనేది వెయిటెడ్ క్వెరీ-టర్మ్ కవరేజ్ మరియు ఫ్రీక్వెన్సీ కాంట్రిబ్యూషన్ను కలుపుతుంది, డాక్యుమెంట్-పొడవు సాధారణీకరణ మరియు పునరావృత పదాల నుండి లాభాలపై క్యాప్తో కూడి ఉంటుంది. ప్రతి అభ్యర్థి యొక్క గరిష్ట సాధ్యమైన స్కోర్ను బౌండ్ చేయడానికి ఫోటాన్ మొదట అర్రేలు మరియు బిట్మ్యాప్లలో పదాల ఉనికిని తనిఖీ చేస్తుంది. సెలక్షన్ థ్రెషోల్డ్ను చేరుకోగల అభ్యర్థుల కోసం మాత్రమే ఇది ఖచ్చితమైన పదం యొక్క ఫ్రీక్వెన్సీలను చదువుతుంది.
అప్పుడు ఎంపిక మూడు దశల్లో కొనసాగుతుంది:
- ట్రావెర్సల్ (Traversal): కఠినమైన క్వెరీ-కవరేజ్ అవసరంతో ప్రారంభించండి. చాలా తక్కువ అభ్యర్థులు కనుగొనబడితే, సడలించిన అవసరంతో పునరావృతం చేయండి.
- నిలుపుదల (Retention): కవరేజ్ మరియు ఫ్రీక్వెన్సీని మిళితం చేసే స్కోర్ను ఉపయోగించి అభ్యర్థులు బౌండెడ్ సెట్లో ఉంచబడతాయి. సేకరించబడిన టాప్ అభ్యర్థులు మెరుగుపడిన కొద్దీ, అడ్మిషన్ థ్రెషోల్డ్ పెరుగుతుంది.
- తుది ఎంపిక (Final selection): ఫ్రీక్వెన్సీ స్కోర్ల ఆధారంగా రిటైన్ చేయబడిన సెట్ నుండి పాస్ కోసం తుది ఫలితాలు ఎంచుకోబడతాయి. ప్రతి ఫీల్డ్ దాని స్వంత పాస్ను రన్ చేస్తుంది, మరియు ఫలితాలు ఫీల్డ్ వెయిట్లను ఉపయోగించి మర్జ్ చేయబడతాయి.
అల్గోరిథం తదుపరి ర్యాంకింగ్లో ఉపయోగించాల్సిన సంబంధిత డాక్యుమెంట్ల అభ్యర్థి సెట్ను ఉత్పత్తి చేస్తుంది.
డాక్బ్లాబ్ (Docblob)
అభ్యర్థి పేజీలు ఎంపిక చేయబడిన తర్వాత, ర్యాంకింగ్ దశకు టర్మ్ ఫ్రీక్వెన్సీలు, ఫీల్డ్ కవరేజ్ మరియు సంభవించిన స్థానాలు మరియు సామీప్యత అవసరం. ఇన్వర్టెడ్ ఇండెక్స్ ద్వారా ఈ డేటాను పొందడం వలన అనేక టర్మ్-డాక్యుమెంట్ జతల জুড়ে చెల్లాచెదురుగా ఉన్న యాక్సెస్లు అవసరమవుతాయి. ఫోటాన్లో, మేము డాక్బ్లాబ్ అనే కాంపాక్ట్ పర్-డాక్యుమెంట్ రికార్డ్ను నిల్వ చేస్తాము, ఇందులో టర్మ్ ఫ్రీక్వెన్సీలు, ఒక పదం ఏ ఫీల్డ్లలో కనిపించింది మరియు డాక్యుమెంట్లో ఎక్కడ సంభవించిందో ఉంటాయి. ఫలితంగా, ఒక అభ్యర్థిని ర్యాంక్ చేయడానికి డాక్యుమెంట్కు ఒక లుకప్ మాత్రమే అవసరం.
అవసరానికి మించి డీకోడింగ్ చేయడాన్ని నివారించడానికి ఈ ఫార్మాట్ రూపొందించబడింది. డాక్బ్లాబ్ లోపల, ఫీల్డ్లు టెక్స్ట్ అనలైజర్ ద్వారా గ్రూప్ చేయబడతాయి. ప్రతి గ్రూప్ Elias-Fanoతో ఎన్కోడ్ చేయబడిన సార్ట్ చేయబడిన టర్మ్ జాబితాను నిల్వ చేస్తుంది, తద్వారా మొత్తం జాబితాను ముందుగా ఎక్స్పాండ్ చేయకుండానే క్వెరీ టర్మ్ను నేరుగా లుకప్ చేయవచ్చు. ఒక పదం ఎక్కడ సంభవించిందో ఫీల్డ్ మాస్క్ సూచిస్తుంది, ఫ్రీక్వెన్సీ కౌంట్ ఎంత తరచుగా జరిగిందో ట్రాక్ చేస్తుంది, మరియు వాస్తవ స్థానాలు పొజిషన్ వ్యత్యాసాలుగా ఎన్కోడ్ చేయబడిన టర్మ్-ఫీల్డ్ జతకి వేర్వేరు బ్లాక్లలో ఉంటాయి. నిజంగా మ్యాచ్ అయిన పదాల కోసం బ్లాక్లు మాత్రమే డీకోడ్ చేయబడతాయి, అయితే రికార్డ్లోని మిగతావన్నీ కంప్రెస్డ్ ఫార్మాట్లోనే ఉంటాయి.
ఆ సెలెక్టివ్ డీకోడింగ్ వల్ల డాక్బ్లాబ్ దామాషా ఖర్చు పెరుగుదల లేకుండా ప్రతి డాక్యుమెంట్కు ఎక్కువ డేటాను నిల్వ చేయడానికి మద్దతు ఇస్తుంది. రికార్డ్ను పెంచడం వలన ప్రతి లుకప్కు ఎక్కువ పని చేయడం బలవంతం చేయబడదు, ఎందుకంటే ర్యాంకింగ్ మొత్తం రికార్డ్కు బదులుగా మ్యాచ్ అయిన పదాలకు సంబంధించి భాగాలను మాత్రమే తాకుతుంది.
బ్యాచ్డ్ రీడ్లు మరియు మెమరీతో పని చేయడం
మరింత సమర్థవంతమైన డేటా రిప్రజెంటేషన్లతో కూడా, ఇతర వనరుల కంటే ముందే RAM అయిపోతుంది, కాబట్టి మేము డిస్క్లో నిల్వ చేయబడిన డేటాను తరచుగా యాక్సెస్ చేయాల్సి ఉంటుంది. ఈ యాక్సెస్లను వేగవంతం చేయడానికి ఫోటాన్ అసమకాలిక డిస్క్ రీడ్లు మరియు బ్యాచ్ రీడ్ల కోసం ఆప్టిమైజ్ చేయబడిన కాష్ను ఉపయోగిస్తుంది, ఇది ప్రతి-అభ్యర్థన వేచి ఉండే సమయాన్ని తగ్గిస్తుంది. మునుపటి సిస్టమ్తో పోలిస్తే ఇది టెయిల్ లేటెన్సీలో గణనీయమైన మెరుగుదలకు దోహదం చేస్తుంది.
అతివ్యాప్తి చెందుతున్న డిస్క్ వేచి ఉండే సమయాలు (Overlapping disk waits)
ర్యాంకింగ్కు ఫైల్లోని వివిధ భాగాలలో ఉన్న వంద డాక్యుమెంట్ల ఫీచర్లను పొందడం అవసరం. మా మునుపటి సిస్టమ్ ఫైల్ను వర్చువల్ అడ్రస్ స్పేస్లోకి మ్యాప్ చేయడానికి mmapని ఉపయోగించింది, తద్వారా మెమరీ పాయింటర్ల ద్వారా దానిని చదవవచ్చు. అయితే, మెమరీలో లేని పేజీని యాక్సెస్ చేయడానికి ఇప్పటికీ డిస్క్ రీడ్ అవసరమైంది. కంప్యూటేషన్ను కొనసాగించడానికి ముందు థ్రెడ్ డేటా కోసం వేచి ఉండాల్సి వచ్చింది, మరియు కోల్డ్ రికార్డ్లను వరుసగా చదవాల్సిన అవసరం వచ్చినప్పుడు ఈ వేచి ఉండే సమయం పెరిగింది.
రికార్డ్ ఆఫ్సెట్లు ముందే తెలుసనే వాస్తనాన్ని ఫోటాన్ సద్వినియోగం చేసుకుంటుంది, కాబట్టి మనం ఒకేసారి అనేక రీడ్లను సమర్పించవచ్చు. దీన్ని రియాక్టర్ నిర్వహిస్తుంది: అంకితమైన వర్కర్ థ్రెడ్ లు io_uring ద్వారా బ్యాచ్లను సమర్పిస్తాయి మరియు అవి చదివిన డేటాను కాలింగ్ కోడ్కు పంపుతాయి. ప్రతి థ్రెడ్ దాని స్వంత io_uringని నిర్వహిస్తుంది; అత్యంత తక్కువ లోడ్ ఉన్న రియాక్టర్కు బ్యాచ్లు పంపబడతాయి. ముందే రిజిస్టర్ చేయబడిన ఫైల్ డిస్క్రిప్టర్లు మరియు బఫర్ పూల్లు పునరావృత రీడ్ల ఓవర్హెడ్ను తగ్గిస్తాయి. ఈ అసమకాలిక ఎగ్జిక్యూషన్ బహుళ ఆపరేషన్ల కోసం వేచి ఉండే సమయాలు అతివ్యాప్తం (overlap) కావడానికి అనుమతిస్తుంది, తద్వారా టెయిల్ లేటెన్సీ తగ్గుతుంది.
డ్రైవ్ యాక్సెస్ల సంఖ్యను తగ్గించడం
రీడ్లను సమర్పించడానికి ముందు, ఫోటాన్ ఇన్-మెమరీ కాష్లో మొత్తం బ్యాచ్ను తనిఖీ చేస్తుంది. మిస్ అయిన రికార్డుల కోసం అభ్యర్థనలు మాత్రమే డిస్క్కి వెళ్తాయి; చదివిన డేటా ఆ తర్వాత కాష్ను నింపుతుంది.
కాష్ బ్యాచ్డ్ రీడ్ల కోసం రూపొందించబడింది. ప్రత్యేకంగా:
- హిట్ అయినప్పుడు ప్రత్యేక కేటాయింపు ఉండదు. బదులుగా, కాలింగ్ కోడ్ ద్వారా ముందే సిద్ధం చేయబడిన బఫర్లోకి డేటా కాపీ చేయబడుతుంది.
- రీడర్ ద్వారా లాక్ అక్విజిషన్ ఉండదు. బదులుగా, ఇది డేటా వెర్షన్ను తనిఖీ చేస్తుంది మరియు అది రైట్తో విభేదిస్తే మళ్లీ ప్రయత్నిస్తుంది.
- ఇది ప్రతి రీడ్లో షేర్ చేయబడిన LRU జాబితాకు అప్డేట్లు అవసరం కాకుండా, CLOCK ఎవిక్షన్ను ఉపయోగిస్తుంది.
- ఇది CPU కాష్ ప్రీఫెచింగ్ను ఉపయోగిస్తుంది, ఇక్కడ రాబోయే రికార్డ్ల కోసం మెటాడేటా మరియు డేటా ముందే అభ్యర్థించబడతాయి.
ఈ ఆప్టిమైజేషన్లు మనం శ్రద్ధ వహించే వర్క్లోడ్లపై పనితీరును దెబ్బతీయకుండా లేటెన్సీని తగ్గిస్తాయి.
సర్వింగ్ నుండి విడిగా ఇండెక్స్ను బిల్డ్ చేయడం మరియు అప్డేట్ చేయడం
ఫోటాన్లో, ఇండెక్స్ బిల్డింగ్ మరియు క్వెరీ సర్వింగ్ వేర్వేరు నోడ్లలో రన్ అవుతాయి. ఇండెక్సర్లు డేటాను సిద్ధంగా ఉన్న నిల్వ స్ట్రక్చర్లుగా మారుస్తాయి, అయితే సర్వింగ్ నోడ్లు వాటిని చదివి రిట్రీవల్ మరియు ర్యాంకింగ్ను నిర్వహిస్తాయి. ఫలితంగా, ఇండెక్స్ బిల్డింగ్ CPU కోసం సెర్చ్ క్వెరీలతో పోటీ పడదు, మరియు ఈ టాస్క్ల కోసం వనరులను స్వతంత్రంగా స్కేల్ చేయవచ్చు.
ఈ విభజన మునుపటి అమలులో ఉన్న రికవరీ మరియు సింక్రొనైజేషన్ బాటిల్నెక్లను పరిష్కరిస్తుంది. ఇండెక్స్ బిల్డింగ్ క్వెరీలకు సేవలను అందించిన అదే క్లస్టర్ లోపల రన్ అయినందున, విఫలమైన నోడ్ను పునరుద్ధరించడం లేదా డేటా యొక్క కొత్త కాపీని జోడించడం అంటే డాక్యుమెంట్లను అక్కడికక్కడే రీఇండెక్సింగ్ చేయడం కావచ్చు, ఈ ప్రక్రియకు రోజులు పట్టేది మరియు రికవరీ సమయంలో పాక్షిక ప్రతిస్పందనలను పెంచేది. ఫోటాన్ ఆ కప్లింగ్ను తొలగిస్తుంది; ఇండెక్సర్లు సర్వింగ్ నోడ్లతో సంబంధం లేకుండా స్వతంత్రంగా వెర్షన్ చేయబడిన, సర్వ్ చేయడానికి సిద్ధంగా ఉన్న ఇండెక్స్ స్ట్రక్చర్లను ఉత్పత్తి చేసే డిస్ట్రిబ్యూటెడ్ జాబ్లుగా రన్ అవుతాయి, కాబట్టి ఇండెక్స్ యొక్క తదుపరి వెర్షన్ను బిల్డ్ చేయడం ఇకపై లైవ్ ట్రాఫిక్తో పోటీ పడదు.
ప్రిపరేషన్ మరియు డిస్ట్రిబ్యూటెడ్ బిల్డింగ్
యాక్టివ్ ఇండెక్స్ కోసం డాక్యుమెంట్లను ఎంచుకోవడం మరియు సోర్స్ ఎక్స్పోర్ట్ను రూపొందించడంతో ఒక బిల్డ్ ప్రారంభమవుతుంది. కంట్రోలర్ సోర్స్ వెర్షన్, ఇన్పుట్ టేబుల్లు మరియు షార్డ్ల ఆశించిన సంఖ్యను రికార్డ్ చేస్తుంది. YTsaurusలోని MapReduce జాబ్ లు షార్డ్ ద్వారా విభజించబడిన వెర్షన్ చేయబడిన టేబుల్లలోకి టెక్స్ట్, మెటాడేటా, ఫ్రాగ్మెంట్లు, ఫీచర్లు మరియు ముందే లెక్కించబడిన ఎంబెడ్డింగ్లను సిద్ధం చేస్తాయి. ప్రతి ఇండెక్సర్ సిద్ధం చేసిన టేబుల్ను స్ట్రీమ్ చేస్తుంది, దాని షార్డ్ కోసం స్ట్రక్చర్లను బిల్డ్ చేస్తుంది మరియు టెక్స్ట్ సెగ్మెంట్లను మర్జ్ చేస్తుంది. సిద్ధంగా ఉన్న ఇండెక్స్, దాని భాగాల వివరణతో పాటు, ఆబ్జెక్ట్ స్టోరేజ్కి అప్లోడ్ చేయబడుతుంది.
షాడ్ కౌంట్ మరియు ఏకకాలంలో రన్ అయ్యే ఇండెక్సర్ల సంఖ్య స్వతంత్రంగా కాన్ఫిగర్ చేయబడతాయి, కాబట్టి బిల్డ్ అనేక వేవ్లలో రన్ కావచ్చు లేదా సమాంతరంగా పని చేయడానికి ఎక్కువ మెషీన్లను కేటాయించవచ్చు. డిస్ట్రిబ్యూటెడ్ ప్రిపరేషన్ మరియు సమాంతర ఇండెక్సర్లు పూర్తి వెబ్ ఇండెక్స్ను సింగిల్-డిజిట్ గంటలలో బిల్డ్ చేయడానికి అనుమతిస్తాయి, ఇది మునుపటి సిస్టమ్తో పోలిస్తే గణనీయమైన మెరుగుదల.
కొత్త వెర్షన్ను డిప్లాయ్ చేయడం
డిప్లాయ్మెంట్కు ముందు, కొత్త ఇండెక్స్ సిద్ధంగా ఉందో లేదో కంట్రోలర్ తనిఖీ చేస్తుంది. డేటా అసంపూర్తిగా ఉంటే, డిప్లాయ్మెంట్ ఆటోమేటిక్గా బ్లాక్ చేయబడుతుంది.
బహుళ సర్వింగ్ గ్రూప్లు ఉన్నప్పుడు, కంట్రోలర్ వాటిని ఒక్కసారిగా అప్డేట్ చేస్తుంది. ఇది మొదట బ్రోకర్ రూటింగ్ నుండి ఒక గ్రూప్ను తొలగిస్తుంది మరియు కొత్త ఇండెక్స్ వెర్షన్లో దానిని ప్రారంభిస్తుంది. అభ్యర్థనలను సర్వ్ చేయడానికి ముందు, షార్డ్లు సెర్చ్ లాగ్ల ఆధారంగా ప్రత్యేక వార్మప్ దశ గుండా వెళతాయి, ఇది ప్రారంభ స్థితిని ముందే జనాభా చేస్తుంది మరియు నిజమైన ట్రాఫిక్కు మారడాన్ని సులభతరం చేస్తుంది. వార్మప్ తర్వాత, కంట్రోలర్ ఇండెక్స్ స్థితి మరియు సిద్ధంగా ఉందో లేదో తనిఖీ చేస్తుంది, ఆపై గ్రూప్ను రూటింగ్కు తిరిగి ఇస్తుంది. ఈ సమయంలో ఇతర గ్రూప్లు అభ్యర్థనలను సర్వ్ చేయడాన్ని కొనసాగిస్తాయి. ఆపరేషన్ స్టేట్ సేవ్ చేయబడినందున, రీస్టార్ట్ చేయడం వల్ల బిల్డ్ను మొదటి నుండి ప్రారంభించమని బలవంతం చేయదు; కంట్రోలర్ ఇప్పటికే జరుగుతున్న ప్రిపరేషన్కు మళ్లీ అటాచ్ చేయవచ్చు, సిద్ధంగా ఉన్న ఫలితాన్ని మళ్లీ ఉపయోగించవచ్చు లేదా సేవ్ చేయబడిన దశ నుండి అంతరాయం ఏర్పడిన రొటేషన్ను కొనసాగించవచ్చు.
డేటా అప్డేట్ సమయాలు సెర్చ్ వర్టికల్స్లో మారుతుంటాయి. అధిక ఫ్రెష్నెస్ అవసరాలు ఉన్న వర్టికల్స్ కోసం, డాక్యుమెంట్ డెలివరీకి సింగిల్-డిజిట్ నిమిషాలు పడుతుంది. డేటా యొక్క అదనపు కాపీని సుమారు అర్ధ గంటలో డిప్లాయ్ చేయవచ్చు; సోర్స్ డాక్యుమెంట్లను మళ్లీ ఇండెక్స్ చేయకుండానే రెడీ ఇండెక్స్లు లోడ్ చేయబడి షార్డ్లకు అటాచ్ చేయబడతాయి.
మా సెర్చ్ స్టాక్లో మైగ్రేషన్ మరియు ధృవీకరణ
రెస్పాన్స్ సమయాలను తగ్గిస్తూనే ఫంక్షనాలిటీని మరియు శోధన నాణ్యతను సంరక్షించే ఇంజిన్తో పాత సిస్టమ్ను భర్తీ చేయడమే మా మొదటి లక్ష్యం. లైవ్ ట్రాఫిక్కు వెళ్లే ముందు పునరుత్పత్తి చేయగల లోడ్ టెస్ట్లు మరియు ఆఫ్లైన్ నాణ్యత మూల్యాంకనాలతో ప్రారంభించి, మేము దశలవారీగా ఫోటాన్ను ధృవీకరించాము. పాత సిస్టమ్ కంటే గణనీయంగా తక్కువ రెస్పాన్స్ సమయాలతో, ఫోటాన్ ఇప్పుడు మా ప్రొడక్షన్ సెర్చ్ స్టాక్లో రిట్రీవల్ మరియు ర్యాంకింగ్కు శక్తినిస్తుంది.
లోడ్ టెస్టింగ్ మరియు మూల్యాంకనాలు
పనితీరు పరీక్ష కోసం, కాన్ఫిగర్ చేయదగిన అరైవల్ రేట్ల వద్ద మా సెర్చ్ లాగ్ల నుండి క్వెరీలను రీప్లే చేసే లోడ్-టెస్టింగ్ టూల్ను మేము బిల్డ్ చేసాము. ఇది రన్ల అంతటా ఫలితాలను సరిపోల్చుతుంది మరియు గమనించిన పనితీరు వ్యత్యాసాలు స్థిరంగా ఉన్నాయో లేదో అంచనా వేయడానికి గణాంక పరీక్షలను వర్తింపజేస్తుంది. విడిగా, నాణ్యత రిగ్రెషన్ల కోసం తనిఖీ చేయడానికి మా అంతర్గత ఆఫ్లైన్ మూల్యాంకన సిస్టమ్లలో అదే డేటాసెట్లపై మేము ఫోటాన్ మరియు పాత సిస్టమ్ను మూల్యాంకనం చేసాము.
ఈ తనిఖీల తర్వాత, మేము షాడో ట్రాఫిక్ని ఉపయోగించి రెండు ఇంజిన్లకు ఏకకాలంలో లైవ్ క్వెరీలను పంపాము. వినియోగదారులకు ఏ ఇంజిన్ సేవలను అందించాలో మార్చడానికి ముందు ప్రొడక్షన్ వర్క్లోడ్లపై వాటి పనితీరును మరియు ఫలితాలను సరిపోల్చడానికి ఇది మాకు అనుమతించింది. ఆ తర్వాత మేము కొద్దిమంది వినియోగదారుల ఉపసమితుల కోసం ఫోటాన్ను ప్రారంభించాము మరియు క్రమంగా రోల్అవుట్ను విస్తరించాము, తద్వారా నాణ్యతను మరియు పనితీరును నిరంతరం పర్యవేక్షించాము. మొదటి వెర్షన్ నాణ్యత రిగ్రెషన్లు లేకుండా అక్సెప్టెన్స్ టెస్టింగ్లో పాస్ అయింది, మరియు ఫోటాన్ ప్రొడక్షన్ ట్రాఫిక్ మొత్తానికి సేవలను అందించే వరకు మేము రోల్అవుట్ను కొనసాగించాము.
ప్రొడక్షన్లో కొలవబడిన మెరుగుదలలు
మా ప్రొడక్షన్ వర్క్ఫ్లోలో, పాత వ్యవస్థలో p99 స్పందన సమయం సుమారు 800 ms నుండి Photonలో సుమారు 65 msకు పడిపోయింది. ఈ కొలత Photon లోని అన్ని దశలను కవర్ చేస్తుంది, కానీ ఉన్నత-స్థాయి సెర్చ్ స్టాక్లోని తర్వాతి దశలను మినహాయిస్తుంది. ఇండెక్స్ వెర్షన్లను మార్చేటప్పుడు గతంలో కనిపించిన లేటెన్సీ స్పైక్లను కూడా మేము ఇకపై గమనించడం లేదు.
పాత సిస్టమ్ యొక్క కంటెంట్ నోడ్ల కంటే ఫోటాన్ సుమారు 20% తక్కువ సమానమైన సర్వింగ్ మెషీన్లను ఉపయోగిస్తుంది, అదే సమయంలో ప్రతి డాక్యుమెంట్కు సుమారు 2.5 రెట్లు ఎక్కువ డేటాను నిల్వ చేస్తుంది. మైగ్రేషన్ తర్వాత, పాత సిస్టమ్ కంటే ర్యాంకింగ్ నాణ్యతను మెరుగుపరచడానికి మేము ఈ అదనపు డేటాను ఉపయోగించాము.
మెమరీలో ఉండవలసిన డేటా మొత్తాన్ని కూడా ఫోటాన్ తగ్గిస్తుంది. mlockతో RAMలో అదే ఫోటాన్ డేటాసెట్ను పిన్ చేయడానికి ప్రస్తుతం ఫోటాన్ ఉపయోగిస్తున్న రెసిడెంట్ మెమరీ కంటే సుమారు 4.6 రెట్లు ఎక్కువ అవసరం అవుతుంది.
ఫాస్ట్ సెర్చ్ API ప్రీసెట్ యొక్క మూల్యాంకనం
లేటెన్సీ-సెన్సిటివ్ వర్క్ఫ్లోల కోసం రూపొందించబడిన మా సెర్చ్ API కోసం కొత్త ఫాస్ట్ ప్రీసెట్కు ప్రాతిపదికగా మేము ఫోటాన్ను కూడా ఉపయోగించాము. మా కొలతల ప్రకారం, ఫాస్ట్ ప్రీసెట్ కోసం సింగిల్-సెర్చ్-కాల్ లేటెన్సీ p50 వద్ద 160 ms మరియు p95 వద్ద 230 ms, ఇది ఇతర సెర్చ్ API ప్రొవైడర్లు స్వయంగా నివేదించిన సంఖ్యల కంటే తక్కువగా లేదా వాటితో పోల్చదగినదిగా ఉంటుంది, అయితే నివేదించబడిన టెయిల్ పర్సంటైల్స్ భిన్నంగా ఉంటాయి.
ఆరు ఏజెంటిక్ బెంచ్మార్క్లపై మేము ఫాస్ట్ ప్రీసెట్ను మూల్యాంకనం చేసాము: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 మరియు SEAL-Hard. ఈ మూల్యాంకనాలలో, పరీక్షించిన కాన్ఫిగరేషన్లలో ఇది అత్యల్ప అంచనా వేయబడిన మొత్తం మోడల్-ప్లస్-సెర్చ్ ఖర్చు మరియు అత్యధిక సగటు టాస్క్ స్కోర్ను కలిగి ఉంది.
ఫాస్ట్ ప్రీసెట్ ఫోటాన్ను ఏజెంటిక్ వర్క్ఫ్లోల కోసం ఆప్టిమైజ్ చేయబడిన ర్యాంకింగ్తో జత చేస్తుంది, గణనీయంగా తక్కువ ఖర్చుతో డిఫాల్ట్ ప్రీసెట్కు పోల్చదగిన పనితీరును అందిస్తుంది. అయితే, ఇది విస్తృత శోధన నాణ్యతలో ట్రేడ్-ఆఫ్తో వస్తుంది. ఫాస్ట్ ప్రీసెట్ డిఫాల్ట్ ప్రీసెట్ కంటే ర్యాంకింగ్ కోసం తక్కువ కంప్యూట్ను ఉపయోగిస్తుంది. లాంగ్-టెయిల్ క్వెరీలు, విస్తృత కవరేజ్ మరియు ఫలితాల వైవిధ్యాన్ని కవర్ చేసే అంతర్గత బెంచ్మార్క్లపై, ఇది రిలెవెన్స్పై 0.24 పాయింట్లు తక్కువగా మరియు సమాధాన లభ్యతపై దాదాపు 3 శాతం పాయింట్లు తక్కువగా స్కోర్ చేస్తుంది. మోడల్ యొక్క స్వంత రీజనింగ్ మరియు జ్ఞానం వ్యత్యాసాన్ని భర్తీ చేయడానికి సహాయపడతాయి కాబట్టి, ఏజెంటిక్ వర్క్ఫ్లోలకు ఇది సరైన ట్రేడ్-ఆఫ్ అని మేము నమ్ముతున్నాము.
రోజువారీ ఏజెంటిక్ టాస్క్ల కోసం మేము ఫాస్ట్ ప్రీసెట్ను సిఫార్సు చేస్తున్నాము. సమయంతో కూడుకున్నవి కాని మరింత సవాలుతో కూడిన లేదా అస్పష్టమైన ప్రశ్నల కోసం, డిఫాల్ట్ ప్రీసెట్ మరింత బలమైన నాణ్యతను అందిస్తుంది, ఇది దాని అధిక లేటెన్సీ మరియు ఖర్చును సమర్థిస్తుంది.
ముగింపు
మేము మా సెర్చ్ స్టాక్ను క్రమంగా రస్ట్-ఆధారిత, ఇన్-హౌస్ ఇన్ఫ్రాస్ట్రక్చర్కు మారుస్తున్నాము. ఓపెన్-సోర్స్ ఇంజిన్ను మా కస్టమ్ రిట్రీవల్ మరియు ర్యాంకింగ్ ఇంజిన్ అయిన ఫోటాన్తో భర్తీ చేయడం తాజా అడుగు. ఫోటాన్ మాకు డేటా రిప్రజెంటేషన్లు, రీడ్లు ఎలా నిర్వహించబడతాయి మరియు కొత్త ఇండెక్స్లు ఎలా డిప్లాయ్ చేయబడతాయి అనేదానిపై పూర్తి నియంత్రణను ఇస్తుంది, మా వర్క్లోడ్ల కోసం ప్రతి లేయర్ను ఆప్టిమైజ్ చేయడానికి ఇది అనుమతిస్తుంది.
Perplexity యొక్క ఉత్పత్తులలో వేగవంతమైన శోధనను ఫోటాన్ ప్రారంభించింది మరియు సెర్చ్ APIలో మా కొత్త ఫాస్ట్ ప్రీసెట్కు ఆధారాన్ని అందిస్తుంది. మైగ్రేషన్ తర్వాత, p99 రిట్రీవల్-అండ్-ర్యాంకింగ్ లేటెన్సీ దాదాపు 800 ms నుండి 65 msకి పడిపోయింది. మా కాంపాక్ట్ డేటా ఫార్మాట్లు ప్రతి డాక్యుమెంట్కు 2.5 రెట్లు ఎక్కువ డేటాను నిల్వ చేయడానికి మాకు అనుమతిస్తాయి, ఇది రిట్రీవల్ మరియు ర్యాంకింగ్కు రిచ్ డాక్యుమెంట్ సమాచారాన్ని యాక్సెస్ చేయడానికి వీలు కల్పిస్తుంది.
ఫాస్ట్ ప్రీసెట్ p50 వద్ద 160 ms మరియు p95 వద్ద 230 ms సింగిల్-సెర్చ్-కాల్ లేటెన్సీని అందిస్తుంది. మూల్యాంకనం చేయబడిన ఆరు ఏజెంటిక్ బెంచ్మార్క్లలో, డిఫాల్ట్ ప్రీసెట్తో పోలిస్తే ఇది టాస్క్కు అంచనా వేయబడిన మోడల్-ప్లస్-సెర్చ్ ఖర్చును 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}
}