కోడ్ జనరేషన్‌గా శోధనను పునరాలోచించడం

ఏజెంట్ హార్నెస్‌ల యుగం కోసం మోనోలిథిక్ సేవల నుండి ప్రోగ్రామబుల్ ప్రిమిటివ్‌ల వరకు శోధనను అభివృద్ధి చేయడం.

రచయితలుPerplexity Research

AI సిస్టమ్‌లకు శోధన అనేది ఒక ముఖ్యమైన ప్రాథమిక అంశం. ఫ్రాంటియర్ మోడల్‌లు నెలల తరబడి మరింత సామర్థ్యాన్ని పొందుతున్నాయి, అయినప్పటికీ వాటికి విస్తృత ప్రపంచం నుండి తాజా, కచ్చితమైన మరియు చక్కగా క్యూరేట్ చేయబడిన జ్ఞానం ఇప్పటికీ అవసరం. AI సిస్టమ్‌లు ఆ జ్ఞానాన్ని పొందడానికి శోధన అనేది ప్రాథమిక మార్గం, అందువల్ల తీర్మానాలు చేయడానికి, చర్యలు తీసుకోవడానికి మరియు వాస్తవ ప్రపంచ పనిని నిర్వహించడానికి అవసరమైన ఏదైనా ఉత్పత్తికి ఇది ఒక పునాది భాగం.

ఏజెంట్ల యుగంలో సాంప్రదాయ శోధన వర్క్‌ఫ్లోలు క్రమంగా కాలం చెల్లినవిగా మారుతున్నాయని మేము నమ్ముతున్నాము. సాంప్రదాయ శోధన ప్రశ్నలకు సమాధానమిస్తుంది, కానీ నేటి ఏజెంట్లు అనంతమైన రూపాలను తీసుకోగల పనులను పూర్తి చేస్తాయి. ఈ పనులకు ఏజెంట్లు తమ హార్నెస్‌లలో నేరుగా టాస్క్- నిర్దిష్ట పునరుద్ధరణ వ్యూహాలను నిర్వచించడం అవసరం. Perplexity Computerలో, ఒకే టాస్క్ కొన్ని నిమిషాలలో వందల లేదా వేల కొద్దీ పునరుద్ధరణ ఆపరేషన్‌లను ప్రేరేపించడాన్ని మేము చూశాము: ఇది మానవులకు అసాధ్యమైనది కానీ ఏజెంట్లకు పూర్తిగా సహజమైన వర్క్‌ఫ్లో.

ఈ ప్రపంచంలో, శోధన అనేది ఏజెంట్‌గా మారాలి, దాని బిల్డింగ్ బ్లాక్‌లు ఏజెంట్ హార్నెస్ లోపల SDKలుగా నేరుగా అందుబాటులో ఉంటాయి. Perplexity యొక్క కొత్త రిఫరెన్స్ శోధన ఆర్కిటెక్చర్‌గా మేము Search as Code (SaC)ని పరిచయం చేస్తున్నాము.

పరిచయం

Perplexity యొక్క శోధన స్టాక్ మా అప్లికేషన్‌లు మరియు API ప్లాట్‌ఫారమ్‌లో ప్రతి సెకనుకు వేల కొద్దీ ప్రశ్నలకు సేవనందిస్తుంది. సెప్టెంబరు 2025లో, మేము మా శోధన సిస్టమ్‌ల యొక్క మొదటి ఆర్కిటెక్చరల్ అవలోకనాన్ని ప్రచురించాము. ఈ సిస్టమ్‌లలో స్థిరమైన ఆవిష్కరణ Search API, Agent API మరియు Computer వంటి కొత్త ఆఫర్‌ల లాంచ్‌కు మద్దతు ఇచ్చింది, ప్రతి రోజు గడిచేకొద్దీ వినియోగదారులకు మెరుగ్గా సేవనందించడానికి స్వీయ-మెరుగుదల లూప్‌లు శోధన స్టాక్‌ను ఆప్టిమైజ్ చేస్తాయి.

సాంప్రదాయకంగా, AI సిస్టమ్‌లు శోధనను ఒక మోనోలిత్‌గా పరిగణించాయి: ఒక AI మోడల్ ప్రశ్నను జారీ చేస్తుంది, శోధన ఇంజిన్ దాని ముందే నిర్వచించిన వర్క్‌ఫ్లోను అమలు చేస్తుంది మరియు మోడల్ ఫలితాలను సందర్భం వలె వినియోగిస్తుంది. చాలా వరకు, ఇది ప్రారంభ AI వినియోగదారుల అవసరాలను తీర్చడానికి బాగా పనిచేసింది. వారి అభ్యర్థనల యొక్క సాపేక్ష సరళతను బట్టి, శోధన వర్క్‌ఫ్లో ఎలా రూపొందించబడిందో లేదా వర్క్‌ఫ్లో ఆర్కిటెక్చర్ చేతిలో ఉన్న టాస్క్‌కు ఆప్టిమల్‌గా ఉందా లేదా అని ఖచ్చితంగా ఆందోళన చెందడానికి ఎటువంటి కారణం లేదు. డిఫాల్ట్ ఇంటర్‌ఫేస్‌లు (ఫంక్షన్ కాలింగ్ మరియు MCPలు) లాగానే డిఫాల్ట్‌లు కూడా సరిపోతాయని ఊహించబడ్డాయి.

సాంప్రదాయ శోధన ఆర్కిటెక్చర్‌లు మోడల్‌లు వరుసగా కాల్ చేసే ఒకే ఫిక్స్‌డ్ సిస్టమ్‌ను బహిర్గతం చేస్తాయి, అయితే Search as Code ఏజెంట్‌లు జెనరేట్ చేసిన కోడ్ ద్వారా కంపోజ్ చేసే అటామైజ్డ్ శోధన ప్రిమిటివ్‌లను బహిర్గతం చేస్తుంది.

అయినప్పటికీ నేడు ఈ విధానం ప్రతి గడిచే నెలా మరింత కాలం చెల్లినదిగా మారుతోంది. వినియోగదారులు AI నుండి సింగిల్-షాట్ విశ్లేషణ కంటే చాలా ఎక్కువ డిమాండ్ చేస్తున్నారు. వారు గంటల కొద్దీ లేదా రోజుల తరబడి ఏజెంట్లు ఎండ్-టు-ఎండ్ పనులను పూర్తి చేయాలని ఆశిస్తున్నారు. ఈ పనులు సంక్లిష్టంగా, ఓపెన్-ఎండెడ్‌గా మరియు వాటి సమాచార అవసరాలలో అత్యంత వైవిధ్యంగా ఉంటాయి మరియు ఈ డిమాండ్ల బరువు క్రింద మోనోలిథిక్ ఆర్కిటెక్చర్‌లు కుప్పకూలుతున్నాయి.

ప్రధాన బాటిల్‌నెక్ అంతిమంగా నియంత్రణకు సంబంధించినది. ఫిక్స్‌డ్ కాంటెక్స్ట్ పై రీజనింగ్ చేయడంలో ఫ్రాంటియర్ మోడల్స్ ఇప్పటికే చాలా మంచివి. అయినప్పటికీ, అత్యంత శక్తివంతమైన AI సిస్టమ్‌లకు ఆ కాంటెక్స్ట్ ఎలా పునరుద్ధరించబడుతుందో, ప్రాసెస్ చేయబడుతుందో, ఏకీకృతం చేయబడుతుందో మరియు మోడల్‌కు రెండర్ చేయబడుతుందో నియంత్రించే సామర్థ్యం అవసరం.

సాంప్రదాయ శోధన సిస్టమ్‌లు ఈ స్థాయి నియంత్రణను దృష్టిలో ఉంచుకుని రూపొందించబడలేదు. అన్ని తరువాత, మానవ వినియోగదారులు అందించబడినప్పటికీ శోధన వర్క్‌ఫ్లో ఇంటర్నల్స్పై చక్కటి నియంత్రణను ప్రదర్శించలేరు. ప్రారంభ AI మోడల్‌లు ఫంక్షన్ కాల్‌లు మరియు MCPల లీనియర్ ట్రాజెక్టరీ ద్వారా మాత్రమే శోధనను నియంత్రించగలవు. కానీ నేటి ఫ్రాంటియర్ మోడల్‌లు, కోడ్-సమర్థులైన ఏజెంట్ హార్నెస్‌ల ద్వారా నడపబడుతున్నాయి, కంప్యూటర్ కోడ్ ద్వారా ఊహించదగిన ఏ టెర్రస్ ప్రిమిటివ్‌లపై అయినా చక్కటి నియంత్రణను ప్రయోగించగలవు. సరైన ప్రిమిటివ్‌లను అందించడం మా పని అవుతుంది.

ఈ అవసరాన్ని తీర్చడానికి, మేము మా ఉత్పత్తులలో కొత్త శోధన ఆర్కిటెక్చర్‌ను పరిచయం చేస్తున్నాము: Search as Code (SaC). ఈ కొత్త ఆర్కిటెక్చర్ మోడల్‌లు కేవలం చివరి అవుట్‌పుట్‌లను వినియోగించకుండా శోధన స్టాక్‌లోకి వెళ్లేందుకు అధికారం ఇస్తుంది. ప్రధాన ఆలోచన సూటిగా ఉంటుంది: మేము శోధన స్టాక్ యొక్క భాగాలను SDK లోపల ప్రిమిటివ్‌లుగా బహిర్గతం చేస్తాము. శోధన అవసరమయ్యే ఏ అభ్యర్థనకైనా, మోడల్ ఈ ప్రిమిటివ్‌లను ఆన్-డిమాండ్‌లో ఆ నిర్దిష్ట అభ్యర్థనకు తగినట్లుగా రిట్రీవల్ వర్క్‌ఫ్లోగా సమీకరించుకుంటుంది.

ఈ వర్క్‌ఫ్లోను సమీకరించడం సురక్షితమైన శాండ్‌బాక్స్ లోపల కోడ్ జనరేషన్ మరియు ఎగ్జిక్యూషన్ ద్వారా చేయబడుతుంది. శోధన కోసం కోడ్‌జెన్-డ్రైవెన్ విధానాల వలె కాకుండా, మేము షెల్ లేదా లాంగ్వేజ్ రన్‌టైమ్‌లో సాంప్రదాయ శోధన APIని ఉంచము. బదులుగా, సాధ్యమైనంత అత్యంత అటామిక్ స్థాయిలో శోధన యొక్క వ్యక్తిగత బిల్డింగ్ బ్లాక్‌లను బహిర్గతం చేసే ఏజెంటిక్ సెర్చ్ SDKని మేము జాగ్రత్తగా ఇంజనీర్ చేసాము.

Search as Code (SaC) వివిధ రకాల బెంచ్‌మార్క్‌లలో ఏజెంటిక్ శోధన యొక్క పనితీరు సరిహద్దును ముందుకు తెస్తుంది.

ఈ బిల్డింగ్ బ్లాక్‌లతో సాయం చేయబడిన SaC, ప్రతి వ్యక్తిగత శోధన దశపై మోడళ్లకు ప్రత్యక్ష నియంత్రణను ఇస్తుంది: రిట్రీవల్, ర్యాంకింగ్, ఫిల్టరింగ్, ఫ్యానౌట్‌లు, రెండరింగ్ మరియు మరెన్నో. ఇది అభ్యర్థి జాబితాలు మరియు ర్యాంకింగ్ సిగ్నల్స్ వంటి మధ్యంతర స్థితికి మోడల్‌కు సమర్థవంతమైన యాక్సెస్‌ను కూడా ఇస్తుంది. కలిసి, నియంత్రణ మరియు చదవగలిగే సామర్థ్యం యొక్క ఈ జంట లీవర్‌లు ఏజెంట్‌లకు వేలకొద్దీ రిట్రీవల్ ఆపరేషన్‌లను విస్తరించే అనుకూల శోధన వర్క్‌ఫ్లోలను రూపొందించడానికి, ఫ్లైట్‌లో ఆ వర్క్‌ఫ్లోలను ఆప్టిమైజ్ చేయడానికి మరియు మోడల్ కాంటెక్స్ట్‌గా అత్యంత ఉపయోగకరమైన సమాచారాన్ని మాత్రమే వినియోగించుకోవడానికి అనుమతిస్తాయి.

ఈ కథనం ఉనికిలో ఉన్న మరియు కొత్త బెంచ్‌మార్క్‌లపై అనుభవపూర్వక ఫలితాలతో పాటు SaC యొక్క ప్రేరణ, డిజైన్ మరియు అమలును వివరిస్తుంది. SaC ఏజెంటిక్ శోధన కోసం కొత్త కాస్ట్-పెర్ఫార్మెన్స్ సరిహద్దును ఏర్పాటు చేస్తుంది మరియు మా వినియోగదారులతో మరియు విస్తృత AI కమ్యూనిటీతో దీన్ని పంచుకోవడానికి మేము సంతోషిస్తున్నాము.

సాంప్రదాయ శోధన యొక్క దృఢత్వం

ప్రపంచపు మొదటి శోధన ఇంజిన్‌లు మానవ వినియోగదారుల కోసం నిర్మించబడ్డాయి. ఈ వినియోగదారులు ఊహించదగిన అనుభవాన్ని ఆశించడం ప్రారంభించారు, సాధారణంగా స్థిర సంఖ్యలో రిలవెన్స్-ర్యాంక్ చేయబడిన డాక్యుమెంట్‌లను కలిగి ఉంటాయి. వినియోగదారులు శోధన ప్రక్రియను మైక్రోమేనేజ్ చేయాలనుకోలేదు; వారు ఒక ప్రశ్నను నమోదు చేసి ఉపయోగకరమైన ఫలితాన్ని కనుగొనాలనుకున్నారు.

ఫలితంగా, మానవ-ముఖ శోధన ఇంజిన్‌లు కామన్ మోనోలిథిక్ ఆర్కిటెక్చర్‌పై ఏకమయ్యా యి, ఇన్‌పుట్ ప్రశ్న కోసం టాప్ n హిట్‌లను కలిగి ఉన్న మానవ-స్నేహపూర్వక శోధన ఇంజిన్ ఫలితాల పేజీలను (SERPలు) రూపొందించడానికి గియర్ చేయబడ్డాయి. ఈ నమూనా కన్స్యూమర్ శోధనలో దశాబ్దాల పురోగతికి శక్తినిచ్చింది. ఇది మానవ బ్రౌజింగ్‌కు వేగవంతమైనది, సుపరిచితమైనది మరియు అత్యంత ప్రభావవంతమైనది.

తరువాత LLMలు వచ్చాయి, మరియు AI సిస్టమ్‌లు కూడా శోధన వినియోగదారులుగా మారాయి. 2022లో మా ఆన్సర్ ఇంజిన్ ప్రారంభంతో Perplexity ఈ మార్పుకు మార్గదర్శకత్వం వహించింది. అప్పటి నుండి, మా శోధన ఇంజనీరింగ్ ప్రయత్నాలు AI మోడల్‌ల కోసం శోధన ఫలితాల విలువను ఎలా ఆప్టిమైజ్ చేయాలో దానిపై దృష్టి సారించాయి. ప్రపంచంలోని అత్యంత ఖచ్చితమైన మరియు నమ్మదగిన AIని నిర్మించడానికి, ప్రతి టోకెన్‌ను వీలైనంత సమాచార-దట్టంగా ఉండేలా చేయడానికి దృష్టి केंद्रित చేసిన శోధన సిస్టమ్‌ను మేము ఇంజనీర్ చేయాల్సి వచ్చింది. ఫలితంగా సబ్-డాక్యుమెంట్ రిట్రీవల్, కాంటెక్స్ట్ ఎఫిషియెన్సీ, సెమాంటిక్ అండర్‌స్టాండింగ్ మరియు ఇతర కీలక రంగాలలో ఆవిష్కరణలు సమాచారాన్ని పునరుద్ధరించడానికి మరియు దానిపై చర్య తీసుకోవడానికి AI సిస్టమ్‌ల సామర్థ్యంలో నాటకీయ మెరుగుదలలకు దారితీశాయి.

అయినప్పటికీ, AI- ఆప్టిమైజ్ చేయబడిన సిస్టమ్‌లు కూడా సాంప్రదాయ శోధన ఇంజిన్‌ల వలె అదే ప్రాథమిక ఒప్పందాన్ని ఎక్కువగా వారసత్వంగా పొందాయి: ప్రశ్నను అంగీకరించండి, ముందే నిర్వచించిన శోధన వర్క్‌ఫ్లోను అమలు చేయండి, పూర్తిగా ప్రాసెస్ చేయబడిన రిజల్ట్‌సెట్‌ను తిరిగి ఇవ్వండి. సాధారణ అభ్యర్థనల కోసం, ఈ విధానం బాగా పనిచేస్తుంది. కానీ మరింత సంక్లిష్టమైన అభ్యర్థనల కోసం, ఇది పనితీరు, లేటెన్సీ మరియు ఖర్చును తగ్గించే పెరుగుతున్న పరిమితం చేసే బాటిల్‌నెక్ అవుతుంది.

సాంప్రదాయ శోధన సిస్టమ్‌లు మోడల్-గోచరమైన టర్న్‌ల ద్వారా శోధనను సీక్వెన్స్ చేయడానికి ఏజెంటిక్ వర్క్‌ఫ్లోలను బలవంతం చేస్తాయి. మోడల్‌లు వేర్వేరు క్వెరీ పారామీర్‌లలో ఒకే శోధన వర్క్‌ఫ్లోలను పదేపదే కాల్ చేయాలి మరియు అన్ని ఫలితాలను మోడల్ కాంటెక్స్ట్‌లో పరిచయం చేయాలి.

దృఢత్వం నుండి వైఫల్య మోడ్‌లు

సాంప్రదాయ శోధన వర్క్‌ఫ్లోలు ఒకే నియంత్రణ బిైందువు చుట్టూ రూపొందించబడ్డాయి: క్వెరీ పారామీర్‌లు. శోధన ఇంజిన్ దాని ముందే నిర్వచించిన లాజిక్ ప్రకారం వర్క్‌ఫ్లో యొక్క మిగిలిన భాగాలను కలిగి ఉంటుంది మరియు మోడల్ దానికి అనుగుణంగా ఉండాలి. మోడల్‌కు, క్వెరీ పారామీర్‌ల డౌన్‌స్ట్రీమ్‌లో ఉన్న ఏదైనా దృఢంగా ఉంటుంది - వాస్తవ కంప్యూటేషన్ యొక్క ఆకారం మోడల్ నియంత్రణలో ఉండదు.

వినియోగదారు లింక్‌లను స్కాన్ చేసే మానవుడు అయినప్పుడు ఇది సహేతుకమైన సరిహద్దు. వినియోగదారు క్లోజ్డ్ లూప్‌లో నాలెడ్జ్-ఇంటెన్సివ్ పనులను పరిష్కరించడానికి ప్రయత్నిస్తున్న AI మోడల్ అయినప్పుడు ఇది పేలవమైన సరిహద్దు. మా అనుభవంలో, ఈ దృఢత్వం మూడు పునరావృత వైఫల్య మోడ్‌లను సృష్టిస్తుంది:

మోటా సందర్భం. AI మోడళ్లు సందర్భం యొక్క నాణ్యత మరియు సంక్షిప్తత పట్ల సున్నితంగా స్పందిస్తాయి. నాణ్యత, సంక్షిప్తత రెండూ క్వెరీపై అత్యంతగా ఆధారపడతాయి, మరియు మోనోలిథిక్ శోధన పైప్‌లైన్లు అన్ని క్వెరీలలో ఉత్తమంగా పనిచేసేలా రూపొందించబడలేదు. ఉదాహరణకు, ఒక మోడల్‌కు ఒకే, అత్యంత సూక్ష్మమైన సమాచారం కావాలి కానీ recall‌కు ప్రాధాన్యమిచ్చే end-to-end search endpoint‌కు మాత్రమే ప్రాప్యత ఉంటే, ఆ endpoint‌ను ఉపయోగించడం వల్ల మోడల్ సందర్భంలో అనవసర సమాచారానికి పెద్ద మొత్తంలో ప్రవేశం కలుగుతుంది. మరోవైపు, ఒక మోడల్‌కు ఒక్కొక్కదానికి వేర్వేరు శోధన వ్యూహాలు అవసరమైన అనేక సమాచార భాగాలు కావాలంటే, అది వాటన్నింటికీ ఒకే ఉపోత్తమం కాని పైప్‌లైన్‌ను వరుసగా పిలవాల్సి రావచ్చు, ఫలితంగా ఖర్చులు పెరిగిపోవడం మరియు సందర్భం శబ్దభరితంగా మారడం జరుగుతుంది.

డొమైన్ జ్ఞానాన్ని ఉపయోగించడంలో వైఫల్యం. అనేక సందర్భాల్లో, మోడల్ శోధన వ్యూహానికి మార్గనిర్దేశం చేయవలసిన డొమైన్ జ్ఞానాన్ని (దాని శిక్షణ, ఏజెంట్ నైపుణ్యం, మెమరీ లేదా LLM ట్రాజెక్టరీలోని మునుపటి టోకెన్‌ల నుండి) కలిగి ఉండవచ్చు. అయితే, దృఢమైన శోధన ఇంటర్‌ఫేస్ ఆ జ్ఞానాన్ని ఉపయోగించుకోకుండా మోడల్‌ను నిరోధిస్తుంది. ఉదాహరణకు, ఒక నిర్దిష్ట అభ్యర్థన కోసం అది లెక్సికల్ మరియు సెమాంటిక్ సిగ్నల్స్‌ను నిర్దిష్ట మార్గంలో మిళితం చేయాలని, కొన్ని మూలాలకు ప్రాధాన్యత ఇవ్వాలని లేదా నిర్దిష్ట కీ ద్వారా ఫలితాలను ఏకీకృతం చేయాలని మోడల్ గ్రహించవచ్చు. ఆ అంతర్దృష్టులు క్వెరీ పారామీర్‌ల ద్వారా అమలు చేయబడేవి కాకపోతే, మోడల్ వాస్తవంగా వాటిపై చర్య తీసుకోలేదు.

అసమర్థ నియంత్రణ ప్రవాహం మరియు కాంటెక్స్ట్ కాలుష్యం. అనేక శోధన వర్క్‌ఫ్లోలు సహజంగా సీరియల్ కావు. వాటికి క్వెరీ వేరియంట్లపై ఫ్యాన్-అవుట్, సమాంతరంగా ఫెచింగ్, డూప్లికేషన్ మరియు నాన్‌లీనియర్ మరియు అసమకాలిక నియంత్రణ ప్రవాహం అవసరమయ్యే ఇతర ఆపరేషన్‌లు అవసరపడవచ్చు. పునరావృత మోడల్ టర్న్‌ల ద్వారా ఈ దశలను బలవంతం చేయడం లేటెన్సీని జోడిస్తుంది మరియు వర్క్‌ఫ్లోను ఆప్టిమైజ్ చేయడం కష్టతరం చేస్తుంది. ఇది మోడల్ రీజనింగ్‌కు ఉపయోగపడకపోవచ్చు మరియు మరింత తరచుగా కాంపాక్షన్‌లకు దారితీసే నాయిసీ ఇంటర్మీడియట్ స్టేట్‌తో మోడల్ కాంటెక్స్ట్‌ను కలుషితం చేస్తుంది.

AI యొక్క ఫంక్షన్ కాలింగ్ & MCP యుగాలలో ఈ సవాళ్ల గురించి పెద్దగా ఏమీ చేయలేము. ప్రతి శోధన ఆపరేషన్‌కు LLM ఇన్‌ఫరెన్స్‌కు దాని స్వంత రౌండ్‌ట్రిప్ అవసరమైనప్పుడు, డెవలపర్‌లు ఆ రౌండ్‌ట్రిప్‌లో వీలైనంత ఎక్కువ పూర్తి చేయడానికి సహజంగా ఇష్టపడతారు. అంటే మోడల్ ద్వారా ప్రత్యక్ష వినియోగం కోసం పూర్తిగా ప్రాసెస్ చేయబడిన రిజల్ట్‌సెట్‌లను తిరిగి ఇచ్చే ఎండ్-టు-ఎండ్ శోధన వర్క్‌ఫ్లోలు.

ఫలితంగా, నేటి చాలా AI-ముఖ శోధన సిస్టమ్‌లు ఇప్పటికీ ఈ మోనోలిథిక్ ఒప్పందం క్రిందే పనిచేస్తున్నాయి. అయినప్పటికీ, మోడల్ ఇంటెలిజెన్స్ మరియు వినియోగదారు డిమాండ్లలో నిరంతర వృద్ధితో, ఆ ఒప్పందం యొక్క లోపాలు మరింత స్పష్టంగా కనిపిస్తాయి. కోడ్-ఫస్ట్ హార్నెస్‌లపై నిర్మించబడిన నేటి అత్యంత అధునాతన AI సిస్టమ్‌లు, ప్రతి నిమిషం వేలకొద్దీ చర్యలను అమలు చేసే టాస్క్-నిర్దిష్ట వర్క్‌ఫ్లోలను కంపోజ్ చేయగలవు. శోధన సిస్టమ్‌లు ఇంకా ఈ సామర్థ్యాన్ని పూర్తిగా గ్రహించలేదు.

AI- స్థానిక శోధన కోసం సరైన సరిహద్దు స్టాక్‌లో దిగువన ఉంటుందని మేము చాలాకాలంగా అనుమానించాము. మోడల్‌లు కేవలం శోధన ఇంజిన్‌ను కాల్ చేయకూడదు. నిర్దిష్ట టాస్క్ డిమాండ్ చేసిన విధంగా వారు శోధన స్టాక్ యొక్క వ్యక్తిగత భాగాలను ఆర్కెస్ట్రేట్ చేయగలగాలి. దానికి ప్రాథమికంగా భిన్నమైన ఆర్కిటెక్చర్ అవసరం.

ప్రోగ్రామబుల్ శోధన ఆర్కిటెక్చర్‌ను డిజైన్ చేయడం

తదుపరి తరం శోధన ఆర్కిటెక్చర్‌లు ఒక ప్రధాన సూత్రంపై ఆధారపడి ఉంటాయి: శోధన అనేది AI ఏజెంట్ల ద్వారా స్థానికంగా ప్రోగ్రామబుల్‌గా ఉండాలి. ఏజెంట్ ముందే నిర్ణయించిన శోధన వర్క్‌ఫ్లోల సెట్‌కు పరిమితం కాకూడదు. బదులుగా, వివిధ స్థాయిల అమూర్తత వద్ద రూపొందించబడిన కంపోజబుల్ బిల్డింగ్ బ్లాక్‌లను ఉపయోగించి, నిర్దిష్ట టాస్క్ అవసరమయ్యే వర్క్‌ఫ్లోను ఏజెంట్ నిర్మించగలగాలి.

మా కొత్త Search as Code (SaC) ఆర్కిటెక్చర్ ఈ సూత్రాన్ని కలిగి ఉంటుంది. SaCలో, ఫంక్షన్ కాలింగ్ లేదా MCP ఇంటర్‌ఫేస్ ద్వారా ఒక్క రిట్రీవల్ ఆపరేషన్ కూడా పంపబడదు. బదులుగా అన్ని ఆపరేషన్‌లు మోడల్-జనరేటెడ్ పైథాన్ కోడ్ ద్వారా ఆర్కెస్ట్రేట్ చేయబడతాయి. అత్యంత సరళమైన శోధన అవసరాల కోసం, ఈ కోడ్ హై-లేవెల్ శోధన ఎండ్‌పాయింట్‌కు కొన్ని అభ్యర్థనలను కలిగి ఉండవచ్చు. కానీ సంక్లిష్టమైన పనుల కోసం, కోడ్ ఎంత క్లిష్టంగా ఉంటుందో అంత క్లిష్టంగా ఉంటుంది, ఇందులో కండిషనల్ ఎగ్జిక్యూషన్, అసమకాలికత, సమాంతరత మరియు అనేక రకాల లో-లేవెల్ ప్రిమిటివ్‌లకు కాల్‌లు ఉంటాయి.

Search as Code (SaC) ఆర్కిటెక్చర్ మోడల్‌లు, కంప్యూట్ శాండ్‌బాక్స్‌లు మరియు Perplexity యొక్క శోధన ఇన్‌ఫ్రాస్ట్రక్చర్ పైన కూర్చున్న Agentic Search SDKని కలిగి ఉన్న స్టాక్‌పై ఆధారపడి ఉంటుంది.

SaC మూడు గట్టిగా కప్ చేయబడిన పొరలను కలిగి ఉంటుంది:

మోడల్‌లు కంట్రోల్ ప్లేన్‌గా పనిచేస్తాయి. వారు వినియోగదారు (లేదా పేరెంట్ ఏజెంట్) ఆదేశం గురించి రీజనింగ్ చేస్తారు, ఆదేశాన్ని పనులుగా విడదీస్తారు, ప్రతి టాస్క్‌కు ఏ రిట్రీవల్ మరియు ప్రాసెసింగ్ వర్క్‌ఫ్లోలు అవసరమో నిర్ణయించుకుంటారు మరియు ఆ వర్క్‌ఫ్లోలను అమలు చేయడానికి కోడ్‌ను జనరేట్ చేస్తారు.

కంప్యూట్ శాండ్‌బాక్స్‌లు సురక్షిత కోడ్ ఎగ్జిక్యూషన్ రన్‌టైమ్ ద్వారా నిర్ణయాత్మక కంప్యూట్‌ను అందిస్తాయి. నియంత్రణ ప్రవాహం, బ్యాచింగ్, పునఃప్రయత్నాలు, ఫిల్టరింగ్, జాయినింగ్, అగ్రిగేషన్ మరియు ఇతర నిర్ణయాత్మక ఆపరేషన్‌లను అమలు చేయడానికి మోడల్‌లకు అవి కాన్వాస్‌ను అందిస్తాయి.

మా Agentic Search SDK Perplexity యొక్క శోధన స్టాక్‌ను కంపోజబుల్ ప్రిమిటివ్‌లుగా బహిర్గతం చేస్తుంది. ఇది లో-లేవెల్ రిట్రీవల్ ఆపరేషన్‌ల నుండి హై-లేవెల్ సెమాంటిక్ పార్సింగ్ వరకు బిల్డింగ్ బ్లాక్‌లను అందిస్తుంది. SDK శాండ్‌బాక్స్‌ల ఎగ్జిక్యూషన్ రన్‌టైమ్‌లలో పొందుపరచబడింది, ఇది మోడల్‌లు ఒకే ఇన్‌ఫరెన్స్ టర్న్ లోపల వేలకొద్దీ ఆపరేషన్‌లను ఆర్కెస్ట్రేట్ చేయడానికి అనుమతిస్తుంది. క్రింద, మేము ప్రతి పొరకు మా డిజైన్ నిర్ణయాలను చర్చిస్తాము.

Agentic Search SDK

Agentic Search SDK ప్రోగ్రామబుల్ శోధన కోసం బిల్డింగ్ బ్లాక్‌లను నిర్వచిస్తుంది. ముఖ్యం ఏమిటంటే, మా SDK లైబ్రరీగా ప్యాక్ చేయబడిన ముందుగా ఉన్న శోధన API కాదు. గత కొన్ని నెలలుగా, మా ఇంజనీరింగ్ టీమ్ మా శోధన స్టాక్‌ను మాడ్యులర్, కంపోజబుల్ ప్రిమిటివ్‌లుగా రీఆర్కిటెక్ట్ చేసింది. మోడల్ టాస్క్-నిర్దిష్ట రిట్రీవల్ వర్క్‌ఫ్లోలను ఆర్కెస్ట్రేట్ చేయగల మరింత శక్తివంతమైన కాన్వాస్‌ను అందించడానికి మేము Agentic Search SDKని నిర్మించాము.

హై-లేవెల్, ఎండ్-టు-ఎండ్ శోధన వర్క్‌ఫ్లోలు ఇప్పటికీ SDK లోపల అందుబాటులో ఉన్నాయి, అయితే అవి ఇకపై ఏకైక ఎంపిక కాదు. బదులుగా, అవి సాధారణ శోధన నమూనాల కోసం షార్ట్‌హ్యాండ్ రూపంగా పనిచేస్తాయి. టాస్క్ డిమాండ్ చేసిన విధంగా మోడల్ వాటిని ఉపయోగించడానికి లేదా దాటవేయడానికి స్వేచ్ఛగా ఉంటుంది.

రన్‌టైమ్ ఎంపిక: మేము SDK రన్‌టైమ్‌గా పైథాన్, రస్ట్, టైప్‌స్క్రిప్ట్ మరియు బాష్‌లను పరిశీలించాము. పైథాన్ దాని సర్వవ్యాప్తి మరియు డేటా ప్రాసెసింగ్ లైబ్రరీల పర్యావరణ వ్యవస్థను బట్టి అత్యంత సహజమైన సరిపోలిక అని మేము అనుమానించాము. అంతర్గత పరీక్ష దీనిని ధృవీకరించింది మరియు నేడు అందుబాటులోకి వస్తున్న SDK వెర్షన్ పైథాన్-ఆధారితమైనది. ఇది ఉత్తమ ఏజెంట్ అనుభవాన్ని தொடர்ந்து అందిస్తుందని నిర్ధారించుకోవడానికి రన్‌టైమ్ ఎంపికను ఎప్పటికప్పుడు పునఃమూల్యాంకనం చేయాలని మేము ఆశిస్తున్నాము.

ఆటోరీసెర్చ్ ద్వారా నిరంతర మెరుగుదల: ఇటరేటివ్ ఆటోరీసెర్చ్ లూప్ ద్వారా ఫ్రాంటియర్ LLMల కోసం SDK యొక్క వినియోగ సామర్థ్యాన్ని కూడా మేము ఆప్టిమైజ్ చేసాము. ఈ లూప్, వారాల తరబడి నిరంతరం నడుస్తుంది, లేటెన్సీ, కోడ్‌జెన్ నాణ్యత మరియు మొత్తం టాస్క్ పనితీరుతో సహా మెట్రిక్‌లకు వ్యతిరేకంగా SDK మెరుగుదలలను ప్రతిపాదిస్తుంది మరియు ధృవీకరిస్తుంది. ఆటోరీసెర్చ్ లూప్ ఇప్పటికే SDK యొక్క నిర్మాణం మరియు సౌందర్యం రెండింటిలోనూ అనేక మార్పులను చేసింది, అన్ని కొలమానాలలో గణనీయమైన లాభాలను సాధించింది. కొత్త ఫ్రాంటియర్ మోడల్‌లు మరియు శోధన భాగాలు ఉద్భవించినప్పుడు ఆటోరీసెర్చ్ ద్వారా SDKని మరింత మెరుగుపరచాలని మేము ప్రణాళిక చేస్తున్నాము.

శాండ్‌బాక్స్‌లు

శాండ్‌బాక్స్‌లు SaC వర్క్‌ఫ్లోలను నిర్వచించడానికి మరియు అమలు చేయడానికి సురక్షితమైన వాతావరణాలను అందిస్తాయి. ఇవి వ్యక్తిగత శోధన ప్రిమిటివ్‌లతో పరస్పర చర్యను సులభతరం చేయడానికి Agentic Search SDKకి యాక్సెస్‌ను అందిస్తూ, మోడల్-జనరేటెడ్ కోడ్‌ను అమలు చేస్తాయి.

మా శాండ్‌బాక్స్‌లను ఆప్టిమైజ్ చేయడంలో మరియు హార్డెన్ చేయడంలో మేము గణనీయమైన పెట్టుబడులు పెట్టాము మరియు వాటి సమగ్ర సిస్టమ్ డిజైన్ దాని స్వంత కథనానికి అర్హమైనది. ఇక్కడ, మేము SaCకి అత్యంత ముఖ్యమైన డిజైన్ పరిశీలనపై దృష్టి పెడతాము: ఇంటర్మీడియట్ స్టేట్‌లను నిర్వహించడం.

SaC ఏజెంట్లను ఒకే inference turn లో సంక్లిష్ట పైప్‌లైన్లను సమన్వయం చేయడానికి శక్తివంతం చేస్తుంది. అయితే, కొన్ని మధ్యవర్తి స్థితులను turns మధ్యగా తెలియజేయాల్సి ఉంటుంది. ఉదాహరణకు, ఒక మోడల్ turn 1 లో కొన్ని documents‌ను తెచ్చుకుని, turn 2 లో ఆ documents లోని ఒక subsample‌ను పరిశీలించి తర్వాత ఏమి చేయాలో నిర్ణయించుకోవచ్చు, ఆపై turn 3 నుండి ఆ documents‌ను మరింతగా పరిశీలించడానికి downstream search pipeline‌ను అభివృద్ధి చేయవచ్చు. పైగా చర్చించినట్లుగా, token space ద్వారా మధ్యవర్తి స్థితులను పంపించడం ప్రభావవంతమైన వ్యూహం కాదు.

టర్న్‌ల అంతటా మధ్యంతర స్టేట్‌లను నిర్వహించడానికి మేము రెండు విధానాలను పరిశీలించాము:

పర్‌సిస్టెంట్ ఫైల్‌సిస్టమ్ + ఎప్లిసిట్ సెర్డే: టర్న్‌ల అంతటా ఉపయోగించడానికి మోడల్‌ల కోసం శాండ్‌బాక్స్‌లు పర్‌సిస్టెంట్ ఫైల్‌సిస్టమ్‌లను బహిర్గతం చేయగలవు. మధ్యంతర స్థితిని నిల్వ ఉంచాలనుకునే మోడల్‌లు ఒక టర్న్ కోసం జెనరేట్ చేయబడిన కోడ్ లోపల సీరియలైజేషన్ దశను కలిగి ఉండవచ్చు, తదుపరి టర్న్‌లో డిసీరియలైజేషన్ దశతో పాటు (మోడల్‌ల స్వంత తనిఖీ కోసం లేదా డౌన్‌స్ట్రీమ్ ఉపయోగం కోసం). మధ్యంతర స్థితి టర్న్‌ల అంతటా ఎలా తెలియజేయబడుతుందో నేరుగా మరియు స్పష్టంగా నియంత్రించడానికి ఫైల్‌సిస్టమ్ విధానం మోడల్‌లను అనుమతిస్తుంది. ఇది మోడల్ ఉపయోగించే సమాచారం యొక్క స్పష్టమైన గుర్తింపు మరియు పర్‌సిస్టెన్స్‌ను అమలు చేయడం ద్వారా ట్రేసబిలిటీని కూడా నిర్ధారిస్తుంది. ఒక ప్రతికూలత ఏమిటంటే సెర్డే కోడ్‌ను జనరేట్ చేయడం వల్ల వచ్చే లేటెన్సీ & కాంటెక్స్ట్ ఓవర్‌హెడ్, అయినప్పటికీ చక్కగా రూపొందించబడిన యుటిలిటీ ఫంక్షన్‌లు ఈ ఓవర్‌హెడ్‌ను తగ్గించగలవు.

REPL: ప్రత్యామ్నాయంగా, శాండ్‌బాక్స్ REPL-శైలి వాతావరణంలో టర్న్‌ల అంతటా ఎగ్జిక్యూషన్ రన్‌టైమ్‌ను స్వయంగా పర్‌సిస్ట్ చేయగలదు. ఇది మునుపటి టర్న్‌లలో నిర్వచించబడిన లేదా సవరించబడిన వేరియబుల్స్‌ను తదుపరి టర్న్‌లలో పేరు ద్వారా సులభంగా సూచించవచ్చు కాబట్టి, మధ్యంతర స్థితిని సీరియలైజ్ చేయకుండానే ఇన్-మెమరీలో నిర్వహించడానికి మోడల్‌లను అనుమతిస్తుంది. సెర్డే కోడ్‌ను జనరేట్ చేయవలసిన అవసరాన్ని నివారిస్తుంది కాబట్టి REPL విధానం మరింత టోకెన్-సమర్థవంతమైనది. అయినప్పటికీ, స్పష్టమైన సీరియలైజేషన్ దశ లేకపోవడం వల్ల 100-సెల్ జుపిటర్ నోట్‌బుక్‌తో పని చేసిన ఎవరికైనా తెలిసిన కారణాల వల్ల డౌన్‌స్ట్రీమ్ పనితీరు దెబ్బతింటుంది: వేరియబుల్ నేమ్‌స్పేస్ అస్తవ్యస్తంగా మారినందున, టర్న్‌ల అంతటా ఖచ్చితంగా ఏమి నిల్వ ఉంచబడుతుంది మరియు ఎందుకు అనేదానిని ట్రాక్ చేయడం మరింత కష్టమవుతుంది.

మేము రెండు approaches‌ను పరీక్షించాము మరియు సాధారణ వినియోగంలో అవి సమానంగా పనిచేసినా, filesystem-based serde ముఖ్యంగా పొడవైన trajectories‌లో మెరుగైన reliability‌ను అందిస్తుందని గుర్తించాము. అందువల్ల మేము filesystem-based serde‌ను మా solution‌గా స్వీకరించాము. state‌ను implicit‌గా కాకుండా declaratively తెలియజేయాలని మోడళ్లను కోరడం వాటిని ఆ state‌ను మరింత సమర్థవంతంగా నిర్వహించడానికి సహాయపడుతుందని మేము ఊహిస్తున్నాము. ఇది తాత్కాలికమైన కనుగొనం, మరియు మేము రెండు approaches‌పై కూడా iteration కొనసాగిస్తాము.

మోడల్‌లు

ఏజెంట్ హార్నెస్‌లకు శక్తినిచ్చే మోడల్‌లు SaC యొక్క కంట్రోల్ ప్లేన్‌గా పనిచేస్తాయి: ప్రతి టాస్క్ యొక్క అవసరాలను తీర్చడానికి Agentic Search SDK యొక్క బిల్డింగ్ బ్లాక్‌ల నుండి శోధన వర్క్‌ఫ్లోలను డైనమిక్‌గా సమీకరించడం, ఆపై శాండ్‌బాక్స్ అమలు కోసం ఆ వర్క్‌ఫ్లోలను కోడ్‌గా పంపడం.

Perplexity మా ఏజెంట్ హార్నెస్‌లలో వివిధ రకాల మోడల్‌లను ఉపయోగిస్తుంది, మరియు జనరల్-పర్పస్ కోడ్ జనరేషన్‌పై తాజా ఫ్రాంటియర్ మోడల్‌లు అన్ని విధాలుగా చాలా ప్రభావవంతంగా ఉన్నట్లు మేము కనుగొన్నాము. ఏజెంటిక్ సెర్చ్ SDK కోసం ప్రత్యేకంగా ప్రభావవంతమైన కోడ్ జనరేషన్‌ను ప్రేరేపించడం ప్రధాన సవాలు. అనగా, మా SDK యొక్క బిల్డింగ్ బ్లాక్‌లను టాస్క్-ఆప్టిమైజ్ చేయబడిన వర్క్‌ఫ్లోలుగా మోడల్‌లు ఎలా ప్రభావవంతంగా మిళితం చేయగలవు?

భాష యొక్క స్టాండర్డ్ లైబ్రరీ వలె కాకుండా, కస్టమ్-బిల్ట్ SDK ప్రీట్రైనింగ్ డేటాలో ప్రాతినిధ్యం వహించే అవకాశం లేదు. ఆటోరీసెర్చ్ నుండి SDK వినియోగ సామర్థ్య మెరుగులతో కూడా, అనేక మోడల్‌లు ఇప్పటికీ ఫంక్షన్ కాల్‌లు మరియు ప్రత్యక్ష MCP ఇన్‌వోకేషన్ ద్వారా శోధన సిస్టమ్‌లతో ఇంటరాక్ట్ అవ్వడానికి శిక్షణ పొందాయి. ఈ మోడల్‌లు సోర్స్ కోడ్ మరియు ఆటోజెనరేటెడ్ డాక్స్‌తో మాత్రమే SDKని నిపుణుడిగా ఉపయోగించే అవకాశం లేదు.

ఈ సవాలును పరిష్కరించడానికి, మా SDKని సమర్థవంతంగా ఉపయోగించుకోవడానికి మోడళ్లకు నేర్పించడానికి మేము అత్యంత-ట్యూన్ చేయబడిన ఏజెంట్ నైపుణ్యాలను అభివృద్ధి చేసాము. ప్రారంభ వెర్షన్‌లు నైపుణ్యాల కోసం Perplexity యొక్క డిజైన్ సూత్రాల ప్రకారం అభివృద్ధి చేయబడ్డాయి, ఆపై SDK ఆప్టిమైజేషన్‌లో ఉపయోగించిన అదే మెట్రిక్‌లపై దృష్టి సారించిన అంకితమైన ఆటోరీసెర్చ్ లూప్ ద్వారా ఆప్టిమైజ్ చేయబడ్డాయి. కాంటెక్స్ట్ బ్లోట్‌ను రక్షించడానికి మేము నైపుణ్యం పరిమాణాన్ని కూడా పరిమితం చేస్తాము మరియు మా తుది వెర్షన్‌లు వాటి రూట్ SKILL.md ఫైళ్లలో 2000 టోకెన్‌ల కంటే తక్కువ కలిగి ఉంటాయి.

Optimized Skills SDK యొక్క అందుబాటులో ఉన్న building blocks‌ను జాబితా చేయడానికంటే ముందుకు వెళ్తాయి (ఇది runtime reflection ద్వారా కూడా సులభంగా పొందవచ్చు). టోకెన్లలో ఎక్కువ భాగం ఈ blocks‌ను సంక్లిష్ట patterns‌గా సమీకరించడానికి సంక్షిప్త, సాధారణీకరించదగిన guidance మరియు few-shot examples‌ను అందించడంలో ఖర్చవుతుంది. ఈ Skills‌తో సన్నద్ధమై, మేము మోడళ్లు వేలాది discrete operations వరకు స్కేలు అయ్యే search pipelines‌ను సమన్వయం చేయడానికి SDK‌ను సమర్థవంతంగా ఉపయోగిస్తున్నట్లు గమనిస్తాము.

ఆర్కెస్ట్రేటర్ మరియు గ్యాప్ ఫిల్లర్‌గా కోడ్

ఈ పొరలను కలపడం ద్వారా, SaC మోడల్‌లు మరియు శోధన స్టాక్ మధ్య సంబంధాన్ని మారుస్తుంది. ఫిక్స్‌డ్-వర్క్‌ఫ్లో శోధన సిస్టమ్‌లలో, మోడల్ శోధన పైన కూర్చుంటుంది మరియు ఇరుకైన సీరియల్ కాలర్ ఇంటర్‌ఫేస్ ద్వారా దానితో ఇంటరాక్ట్ అవుతుంది. SaCలో, శోధన ప్రక్రియను ఆర్కెస్ట్రేట్ చేయడంలో మోడల్ సక్రియ భాగస్వామి అవుతుంది. శోధన స్టాక్ యొక్క అన్ని మూలాలు మోడల్ ద్వారా నేరుగా ప్రోగ్రామబుల్ అవుతాయి, శాండ్‌బాక్స్ మరియు Agentic Search SDK ఆ మూలాలకు అవసరమైన ఇంటర్‌ఫేస్‌లను అందిస్తాయి.

కానీ స్థానికంగా లేని సామర్థ్యాల మాటేమిటి? ముందుగా ఉన్న సామర్థ్యాలను ఆర్కెస్ట్రేట్ చేయడానికి కోడ్ శక్తివంతమైన మాధ్యమం. అయినప్పటికీ కోడ్ యొక్క శక్తి ఆర్కెస్ట్రేషన్‌కు మించి ఉంటుంది. శోధన స్టాక్ లేదా SDKలో లేని సామర్థ్యాలకు ఇది గ్యాప్-ఫిల్లర్‌గా కూడా పనిచేస్తుంది. ఏజెంట్లు పార్సిమనీ నుండి ప్రయోజనం పొందుతాయి మరియు ప్రతి సంభావ్య ఆపరేషన్‌ను అంకితమైన ఫంక్షన్‌తో SDK కవర్ చేయడం అసమర్థంగా ఉంటుంది. బదులుగా, SDK అత్యంత ప్రాథమిక ప్రిమిటివ్‌లను అందిస్తుంది మరియు మోడల్ కోడ్‌తో ఆన్-ది-ఫ్లైలో ఏ అదనపు భాగాలనైనా నిర్మించగలదు.

ఉదాహరణకు, శోధన సిస్టమ్ యొక్క స్వంత క్వెరీ సింటాక్స్ ద్వారా సమర్థవంతంగా అమలు చేయలేని సంక్లిష్టమైన రెగెక్స్‌ను పరిగణించండి. కోడింగ్ సామర్థ్యాలు లేకుండా, మోడల్ దాని ఉత్తమ అప్రాక్సిమేషన్‌ను జెనరేట్ చేయడానికి, క్వెరీ చేయడానికి మరియు చాలా నాయిసీ రిజల్ట్‌సెట్‌పై టోకెన్-స్పేస్ ఫిల్టరింగ్‌ను నిర్వహించడానికి బలవంతం చేయబడుతుంది. SaCతో, మోడల్ కావలసిన రెగెక్స్ యొక్క రిజల్ట్‌సెట్ యొక్క సూపర్‌సెట్‌ను సేకరించడానికి సమాంతర SDK కాల్‌లను చేసే ప్రోగ్రామ్‌ను జనరేట్ చేయవచ్చు. SDK ద్వారా డెడప్ చేసిన తర్వాత, మోడల్ ఫలితాలను ఖచ్చితమైన రెగెక్స్‌కు నిర్ణయాత్మకంగా తగ్గించడానికి అదనపు కోడ్‌ను వ్రాయవచ్చు. ఈ విధంగా, ఓవర్‌లీ నిచ్ సబ్‌ప్రొటోగ్రామ్‌లతో SDKని ఉబ్బకుండా ఏజెంట్లు కస్టమ్ శోధన సామర్థ్యాలను అమలు చేయగలరు.

కేస్ స్టడీ: CVE వెండర్ అడ్వైజరీలు

మా టెస్టింగ్ సూట్ లోపల వాస్తవ ప్రపంచ టాస్క్ ఆధారంగా మేము కేస్ స్టడీని అందిస్తున్నాము. ఈ టాస్క్ 2023–2025 నుండి 200కి పైగా అధిక-తీవ్రత గల CVEలను గుర్తించి వర్ణించమని ఏజెంట్‌ను కోరుతుంది. ప్రతి రికార్డు ప్రభావిత వెండర్ యొక్క స్వంత అడ్వైజరీని ఉద్ధరించాలి, ఉత్పత్తి మరియు ఫిక్స్ వెర్షన్‌కు పేరు పెట్టాలి మరియు ఫిక్స్ వెర్షన్ నిర్దిష్ట CVEకి టై చేయబడిందని చూపాలి.

నాన్-SaC బేస్‌లైన్‌తో పోలిస్తే మొత్తం టోకెన్ వినియోగం 85.1% తగ్గిపోవడంతో (288.7K టోకెన్‌ల నుండి 42.9K టోకెన్‌లకు), SaC యొక్క సమాధానం ఖచ్చితత్వంలో 100% స్కోర్ చేసింది. సెక్షన్ 4లో మరింత వివరంగా చర్చించబడిన పరీక్షించబడిన నాన్-Perplexity సిస్టమ్‌లు అన్నీ 25% కంటే తక్కువ స్కోర్ చేశాయి.

SaC యొక్క ప్రోగ్రామబిలిటీ మోడల్‌ను ప్రభావవంతమైన వ్యూహాలను అమలు చేయడానికి ఎలా అనుమతిస్తుందో వివరించడానికి మేము ట్రాజెక్టరీ నుండి మూడు స్టైలైజ్ చేయబడిన కోడ్ బ్లాక్‌లను అందిస్తున్నాము.

python
# Part 1 of 3: fan out over official advisory formats. templates = [ ("Mozilla", 'site:mozilla.org/en-US/security/advisories/mfsa{year} ' '"CVE-{year}-" "Fixed in" "Impact high"'), ("Jenkins", 'site:jenkins.io/security/advisory/{year} ' '"CVE-{year}" "Severity" "High" "Fix"'), ("Chrome", 'site:chromereleases.googleblog.com/{year} ' '"High CVE-{year}" "Stable channel has been updated"'), ("Android", 'source.android.com/docs/security/bulletin/{year}-{month:02d}-01 ' '"High" "CVE-{year}"'), ... ] queries = [ {"vendor": vendor, "query": pattern.format(year=year, month=month)} for year in [2023, 2024, 2025] for vendor, pattern in templates for month in ([1] if "{month" not in pattern else range(1, 13)) ] seed_hits = sdk.search.web_many(queries, limit_per_query=8, concurrency=12) pages = [ {"vendor": q["vendor"], "url": h.url, "text": join_result_fields(h)} for q, hits in zip(queries, seed_hits) for h in hits if official_vendor_advisory(h.url, q["vendor"]) ]

ఈ మొదటి బ్లాక్ స్వచ్ఛమైన ఆర్కెస్ట్రేషన్. జెనరేట్ చేయబడిన ప్రోగ్రామ్ సోర్స్-క్లాస్ నియమాన్ని నేరుగా క్వెరీ ప్లాన్‌లో ఎన్కోడ్ చేయడం ద్వారా ప్రారంభమవుతుంది: వెండర్-యాొన్డ్ అడ్వైజరీ ఫార్మాట్‌లు మాత్రమే సంబంధితమైనవి. NVD, MITRE, CVE డీటెయిల్స్, వార్తా కథనాలు, CERT పేజీలు మరియు థర్డ్-పార్టీ డేటాబేస్‌లతో సహా నాన్-వెండర్ సోర్సులు నిర్మాణాత్మకంగా పరిధికి వెలుపల ఉన్నాయి. ఎక్జాక్ట్-ఫ్రేజ్ కన్‌స్ట్రైంట్స్ కూడా ఇండెక్స్ చేయబడిన టెక్స్ట్ డౌన్‌స్ట్రీమ్ అవసరమైన ఖచ్చితమైన CVE వివరాలను ఇప్పటికే కలిగి ఉన్న పేజీల వైపు శోధనను నెట్టివేస్తాయి.

python
# Part 2 of 3: synthesize refinements for sparse vendor-years. coverage = summarize(pages, by=["vendor", "year", "url_kind"]) prompt = """ Goal: 230+ high or critical CVEs from official vendor advisories. Avoid aggregators, CERTs, news, NVD, MITRE, and CVE databases. Current coverage: {coverage} Suggest more site-scoped exact-phrase queries for sparse vendor-years. Prefer per-advisory pages over archive or month-index pages. Return JSON lines with vendor and query. """.format(coverage=coverage) raw = query_llm(prompt) expanded_queries = [ row for row in parse_jsonl(raw) if official_scope(row["query"]) and mentions_cve_year(row["query"]) ] expanded_hits = sdk.search.web_many( unique(expanded_queries), limit_per_query=8, concurrency=12, )

రెండవ block ఒక LLM‌ను మధ్యవర్తి planning subroutine‌గా ఉపయోగిస్తుంది. code తగిన candidate pages‌ను ఉత్పత్తి చేస్తున్న vendor-year pairs ఏవో సారాంశంగా చెబుతుంది, లక్ష్యిత refinements‌ను అడుగుతుంది, మరియు అమలు ముందు ప్రతిపాదిత query ప్రతి ఒక్కదాన్ని ధృవీకరిస్తుంది. ఇది trajectory నుండి ఉపయోగకరమైన patterns‌ను నిలుపుకుంటుంది, ఉదాహరణకు site-scoped exact-phrase probes మరియు adaptive backfilling, అయితే SDK‌లో bespoke CVE-advisory crawler‌ను hardcode చేయకుండా.

python
# Part 3 of 3: verify CVE-to-version binding. all_hits = dedupe_by_url(flatten(seed_hits) + flatten(expanded_hits)) items = [ {"url": h.url, "vendor_hint": infer_vendor(h.url), "text": join_result_fields(h)} for h in all_hits if official_vendor_advisory(h.url, infer_vendor(h.url)) ] verified = sdk.llm.extract_many( items, instruction=( "Keep only vendor advisories where the page ties a high or critical " "CVE to a specific fixed version, build, patch, or security level." ), schema={ "matches": bool, "cve": str, "vendor": str, "product": str, "fix_version": str, "severity": str, "source_url": str, "evidence": str, "version_bound_to_cve": bool, "confidence": float, }, ) records = [ to_cve_record(x) for x in verified if x.matches and x.version_bound_to_cve if high_or_critical(x.severity) and x.confidence > 0.75 ] records = dedupe_by(records, key="cve")

చివరి బ్లాక్ ఒక ఫలిత వెరిఫైయర్, దీని లాజిక్ పూర్తిగా కోడ్‌జెన్ ద్వారా ఏజెంట్ ద్వారా నిర్వచించబడుతుంది. శోధన సబ్‌ప్రొగ్రామ్‌లు ఆమోదయోగ్యమైన అడ్వైజరీ పేజీలను కనుగొనగలిగినప్పటికీ, టాస్క్‌కు కఠినమైన సంబంధం అవసరం: అడ్వైజరీ వెండర్-రచించిన టెక్స్ట్‌లో ఒక CVEని ఒక ప్రభావిత ఉత్పత్తికి మరియు ఒక ఫిక్స్ వెర్షన్‌కు బైండ్ చేయాలి. స్కీమా ఆ సంబంధాన్ని స్పష్టంగా తెలియజేస్తుంది, కాబట్టి డౌన్‌స్ట్రీమ్ కోడ్ CVE ద్వారా డెడప్ చేయవచ్చు, అగ్రిగేటర్ URLలను తిరస్కరించవచ్చు, బలహీనమైన వెర్షన్ సాక్ష్యాలను తీసివేయవచ్చు మరియు రికార్డ్-కౌంట్ ఫ్లోర్ నెరవేరే వరకు బ్యాక్‌ఫిల్లింగ్‌ను కొనసాగించవచ్చు.

మూల్యాంకన ఫలితాలు

సంపూర్ణ పనితీరు మరియు కాస్ట్-పెర్ఫార్మెన్స్ సరిహద్దు రెండింటిపై దృష్టి కేంద్రీకరించి, సమగ్ర బెంచ్‌మార్క్ సూట్‌పై SaC యొక్క ప్రభావాన్ని మేము మూల్యాంకనం చేస్తాము.

బెంచ్‌మార్క్‌లు మరియు సిస్టమ్‌లు

మా benchmark suite మొత్తం ఐదు benchmarks‌ను కలిగి ఉంది, వీటిని వివిధ domains, task formats, మరియు complexity levels అంతటా search-dependent AI workflows‌ను stress test చేయడానికి రూపొందించారు. మేము నాలుగు ఇప్పటికే ఉన్న benchmarks‌ను ఉపయోగిస్తున్నాము: DeepSearchQA (DSQA), BrowseComp, Humanity's Last Exam (HLE), మరియు WideSearch. తొలి మూడు benchmarks (DSQA, BrowseComp, మరియు HLE) కోసం, మేము accuracy‌ను topline metric‌గా నివేదిస్తాము. WideSearch కోసం, మేము row వారీగా F1 score‌ను నివేదిస్తాము.

మేము కొత్తగా అభివృద్ధి చేసిన WANDR బెంచ్‌మార్క్‌ను కూడా ఉపయోగిస్తాము, ఇది శోధన, కంప్యూట్ మరియు మోడల్ రీజనింగ్ యొక్క జాగ్రత్తగా ఆర్కెస్ట్రేషన్ అవసరమయ్యే కష్టమైన “వైడ్ రీసెర్చ్” పనులపై దృష్టి పెడుతుంది. WANDR వినియోగదారుల కోసం Perplexity Computer నిర్వహించే జ్ఞాన-ఇంటెన్సివ్ ప్రొఫెషనల్ పనుల ద్వారా ప్రేరణ పొందింది. ఇది WideSearch మరియు ఇలాంటి బెంచ్‌మార్క్‌లపై పునరావృతమవుతుంది, కానీ మరింత సంక్లిష్టమైన పనులు మరియు టాస్క్ నిర్మాణాలను నొక్కి చెబుతుంది. రాబోయే వారాల్లో మేము WANDR బెంచ్‌మార్క్‌ను ప్రచురిస్తాము.

మేము ఐదు ఏజెంట్-ఆధారిత సిస్టమ్‌లను మూల్యాంకనం చేస్తాము. సమాంతరీకరణ యొక్క ప్రయోజనాల కంటే అంతర్లీన ఆర్కిటెక్చర్ యొక్క పనితీరును వేరు చేయడానికి మేము “బెస్ట్-ఆఫ్-N” స్కోర్‌ల కంటే వ్యక్తిగత పరుగులను పరిగణలోకి తీసుకుంటాము. ప్రతి సిస్టమ్ యొక్క కాన్ఫిగరేషన్ క్రింద వివరించబడింది:

Perplexity (SaC): మేము Perplexity యొక్క ప్రొడక్షన్ Agent API లోపల SaC ఆర్కిటెక్చర్‌ను మూల్యాంకనం చేస్తాము. GPT 5.5 (అధిక రీజనింగ్) అంతర్లీన మోడల్‌గా పనిచేస్తుంది.

OpenAI: మేము శోధన (web_search) మరియు పైథాన్ రన్‌టైమ్ (code_interpreter) రెండూ ప్రారంభించబడిన OpenAI రెస్పాన్సెస్ APIని మూల్యాంకనం చేస్తాము. GPT 5.5 (అధిక రీజనింగ్) అంతర్లీన మోడల్‌గా పనిచేస్తుంది.

Anthropic: మేము 20260401 ఏజెంట్ టూల్‌సెట్ మరియు ఆటో-అలౌడ్ కమాండ్‌లతో ఆంథ్రోపిక్ మేనేజ్డ్ ఏజెంట్‌లను మూల్యాంకనం చేస్తాము. ఓపస్ 4.7 (అధిక రీజనింగ్) అంతర్లీన మోడల్‌గా పనిచేస్తుంది.

Exa: ఎఫర్ట్ హైకి సెట్ చేయబడి, మేము ప్రొడక్షన్ API ద్వారా Exa ఏజెంట్‌ను మూల్యాంకనం చేస్తాము.

Parallel: మేము Parallel Tasks‌ను production API ద్వారా మూల్యాంకనం చేస్తాము, processor‌ను ultra4x‌కు సెట్ చేసి.

పోలిక పనితీరు

పట్టిక 1 ప్రతి సిస్టమ్ కోసం బెంచ్‌మార్క్ స్కోర్‌లను నివేదిస్తుంది. ఐదు బెంచ్‌మార్క్‌లలో నాలుగింటిలో SaC ఇతర అన్ని సిస్టమ్‌ల కంటే మెరుగ్గా పని చేస్తుంది. మిగిలిన బెంచ్‌మార్క్‌లో (HLE), SaC OpenAI రెస్పాన్సెస్‌తో మొదటి స్థానం కోసం అవసరమైన విధంగా టై చేయబడింది. పరిచయం నుండి చిత్రం 2 ఈ స్కోర్‌లను గ్రాఫికల్ రూపంలో విజువలైజ్ చేస్తుంది.

బెంచ్‌మార్క్

Perplexity (SaC)

OpenAI

Anthropic

Exa

సమాంతర

DSQA

0.871

0.733

0.815

0.530

0.810

BrowseComp

0.805

0.720

0.598

0.380

0.560

HLE

0.612

0.614

0.566

0.387

0.515

WideSearch

0.651

0.522

0.590

0.471

0.584

WANDR

0.386

0.130

0.152

0.057

0.126

పట్టిక 1 | మూల్యాంకనం చేయబడిన ప్రతి సిస్టమ్ కోసం బెంచ్‌మార్క్ స్కోర్‌లు. వరుసకు ఉత్తమ స్కోరు బోల్డ్‌లో.

SaC benchmark suite అంతటా state-of-the-art performance‌ను సాధించినప్పటికీ, దాని ఆధిక్యం ముఖ్యంగా WANDR‌లో మరింత స్పష్టంగా కనిపిస్తుంది. Figure 5 WANDR scores‌ను విభజించి చూపుతుంది, అందులో Perplexity యొక్క SaC implementation తదుపరి ఉత్తమ వ్యవస్థను 2.5× రెట్లు అధిగమిస్తుందని చూపిస్తుంది. ఈ పెద్ద తేడా ఉన్నప్పటికీ, WANDR ఇంకా unsaturated‌గా ఉంది మరియు SaC‌కైనా సవాలుగానే ఉంది. WANDR యొక్క tasks‌కు అవసరమైన సంక్లిష్ట, అత్యంత horizontal search workflows‌కు నిరంతరం అధిక performance‌ను సాధించడానికి పరిశోధన మరియు search engineering‌లో అదనపు పురోగతులు అవసరమని మేము నమ్ముతున్నాము.

మూల్యాంకనం చేయబడిన సిస్టమ్‌లలో WANDR స్కోర్‌లు. Perplexity ఏజెంట్ API తదుపరి-ఉత్తమ సిస్టమ్ కంటే 2.5× కారకంతో ముందుంది.

చివరగా, అదే Perplexity శోధన ఇన్‌ఫ్రాస్ట్రక్చర్‌ను ఉపయోగించుకునే మరింత సాంప్రదాయ శోధన వర్క్‌ఫ్లోతో పోలిస్తే SaC యొక్క సాపేక్ష లాభాలను మేము కొలుస్తాము. చిత్రం 6 ప్రతి బెంచ్‌మార్క్‌లో SaC మరియు నాన్-SaC ఆర్కిటెక్చర్‌ల మధ్య స్కోర్‌లలో వ్యత్యాసాన్ని నివేదిస్తుంది. అన్నింటిలోనూ, SaC పనితీరులో గణనీయమైన ప్రోత్సాహాన్ని అందిస్తుంది, DSQAపై అతిపెద్ద సంపూర్ణ లాభం (+19.77 pp, 29%) మరియు WANDRపై అతిపెద్ద సాపేక్ష లాభం (+12.00 pp, 45%) ఉంది.

ప్రతి బెంచ్‌మార్క్‌పై Perplexity బేస్‌లైన్ vs. SaC స్కోర్, సంపూర్ణ మరియు సాపేక్ష డెల్టాలు అన్వయించబడ్డాయి.

కాస్ట్-పెర్ఫార్మెన్స్ సరిహద్దు

ఆచరణలో, వినియోగదారులు ఖర్చు సంబంధిత పనితీరు గురించి శ్రద్ధ వహిస్తారు. అందువల్ల మేము DSQA మరియు WideSearchపై కాస్ట్-పెర్ఫార్మెన్స్ సరిహద్దును మూల్యాంకనం చేస్తాము. ఇతర సిస్టమ్‌లతో పాటు తక్కువ, మధ్యస్థ మరియు అధిక మోడల్ రీజనింగ్ స్థాయిలలో SaC యొక్క ఖర్చు మరియు పనితీరును మేము కొలుస్తాము. చిత్రాలు 7 మరియు 8 ప్రతి-టాస్క్ ధరకు వ్యతిరేకంగా బెంచ్‌మార్క్ స్కోర్‌ను ప్లాట్ చేస్తాయి, x-అక్షం రివర్స్ చేయబడింది కాబట్టి మరింత కుడివైపు ఉన్న పాయింట్లు చౌకగా ఉంటాయి మరియు ఎక్కువ పాయింట్లు మెరుగైన పనితీరును సూచిస్తాయి.

DSQA స్కోర్ వర్సెస్ ప్రతి-టాస్క్ ధర. డాష్ చేయబడిన లైన్ SaC మోడల్ రీజనింగ్ కాన్ఫిగరేషన్‌లను కనెక్ట్ చేస్తుంది.

DSQAలో, మూడు SaC సెట్టింగ్‌లు ఎప్పర్-రైట్ సరిహద్దుపై ఉంటాయి. తక్కువ రీజనింగ్ సెట్టింగ్ వాటిలో రెండింటి కంటే మెరుగ్గా పని చేస్తున్నప్పుడు ఇతర అన్ని సిస్టమ్‌ల కంటే చౌకైనది. మీడియం రీజనింగ్ సెట్టింగ్ ప్రతి టాస్క్‌కు $1 కంటే తక్కువ ధరలో నాన్-SaC సిస్టమ్‌లన్నింటి కంటే మెరుగ్గా పనిచేస్తుంది. హై రీజనింగ్ సెట్టింగ్ పోటీ ధరతో అగ్ర పనితీరును సాధిస్తుంది.

WideSearch స్కోర్ వర్సెస్ ప్రతి-టాస్క్ ధర. డాష్ చేయబడిన లైన్ SaC మోడల్ రీజనింగ్ కాన్ఫిగరేషన్‌లను కనెక్ట్ చేస్తుంది.

WideSearch అదే విధంగా రూపుదిద్దుకున్న సరిహద్దును చూపుతుంది. DSQA వలె, తక్కువ రీజనింగ్ సెట్టింగ్ అన్ని నాన్-SaC సిస్టమ్‌ల కంటే తక్కువ ఖర్చుతో పోటీ పనితీరును సాధిస్తుంది, అయితే మీడియం మరియు హై రీజనింగ్ రెండూ టాస్క్ పనితీరులో నాన్-SaC సిస్టమ్‌ల కంటే మెరుగ్గా పనిచేస్తాయి.

కంప్యూటింగ్ యొక్క కొత్త ఆర్కిటెక్చర్ వైపు

Search as Code సాఫ్ట్‌వేర్ డిజైన్‌లో విస్తృతమైన మార్పును ప్రతిబింబిస్తుంది. దశాబ్దాలుగా, సాఫ్ట్‌వేర్ సిస్టమ్‌లు CPUలపై సాంప్రదాయ రన్‌టైమ్‌ల ద్వారా అమలు చేయబడే నిర్ణయాత్మక సూచనల చుట్టూ నిర్వహించబడ్డాయి. ఫ్రాంటియర్ మోడల్‌లు కంప్యూట్ యొక్క కొత్త రూపాన్ని పరిచయం చేస్తాయి: టోకెన్-స్పేస్ రీజనింగ్, ఇది సూచనలను అనుసరించగలదు మరియు జనరేట్ చేయగలదు. అత్యంత సామర్థ్యం గల కంప్యూటేషనల్ సిస్టమ్‌లు వాటి మధ్య ఎంచుకోవడం కంటే కంప్యూట్ యొక్క ఈ రెండు రూపాలను మిళితం చేస్తాయి.

ఈ హైబ్రిడ్ ఆర్కిటెక్చర్‌కు శోధన అనేది సహజమైన నిరూపణ మైదానం. ఏ సాక్ష్యం అవసరమో మరియు అనిశ్చితి ఎలా పరిష్కరించబడాలో నిర్ణయించడంలో మోడల్స్ సరిగ్గా సరిపోతాయి. నిర్ణయాత్మక రన్‌టైమ్‌లు బ్యాచింగ్, సమాంతరత, ఫిల్టరింగ్, ర్యాంకింగ్ మరియు అగ్రిగేషన్‌కు సరిగ్గా సరిపోతాయి. శోధన ఇన్‌ఫ్రాస్ట్రక్చర్ సార్వత్రిక I/O పొరగా పనిచేస్తుంది, నిమిషానికి వేలకొద్దీ ఆపరేషన్‌లను నిర్వహించగల ప్రపంచ సమాచారానికి రన్‌టైమ్‌కు ఉపయోగకరమైన హ్యాండిల్స్‌ను అందిస్తుంది. ఈ భాగాలు ఏకీకృతం చేయబడినప్పుడు, ఫలితంగా వచ్చే సిస్టమ్ వాస్తవ ప్రపంచ పనులను సాధించడంలో మరింత శక్తివంతమైనది మరియు సమర్థవంతమైనది.

ఈ సామర్థ్యాలను అన్‌లాక్ చేయడానికి ఈ ఆర్కిటెక్చర్ యొక్క ప్రతి భాగం అవసరం. తెలివైన మోడల్‌లు లేకుండా, సిస్టమ్ శోధన వ్యూహంపై రీజనింగ్ చేయలేదు. శాండ్‌బాక్స్‌లు లేకుండా, మోడల్‌లు సీరియల్ I/O మరియు అసమర్థమైన టోకెన్-స్పేస్ ప్రాసెసింగ్‌లోకి బలవంతం చేయబడతాయి. మరియు అటామైజ్డ్ శోధన స్టాక్ లేకుండా, మోడల్‌కు ఆర్కెస్ట్రేట్ చేయడానికి ఏమీ ఉండదు. SaC పనిచేస్తుంది ఎందుకంటే రీజనింగ్, డిటర్మినిస్టిక్ కంప్యూట్ మరియు I/O ప్రతి పొర యొక్క బలాన్ని నొక్కి చెప్పడానికి ఉమ్మడిగా రూపొందించబడ్డాయి.

నిరంతర మెరుగుదల లూప్‌ల అభివృద్ధి ద్వారా ఈ కోడిజైన్‌ను మరింత ముందుకు తీసుకెళ్లవచ్చు. ఉదాహరణకు, Agentic Search SDK మరియు SaC ఏజెంట్ నైపుణ్యాలు సాధారణ ఆటోరీసెర్చ్ లూప్‌లో సంయుక్తంగా ఆప్టిమైజ్ చేయబడతాయి. మరింత ప్రతిష్టాత్మకంగా, SDK వలె బహిర్గతం చేయబడిన లో-లేవెల్ శోధన ప్రిమిటివ్‌ల ప్రయోజనాన్ని పొందడానికి మోడల్‌లకు శిక్షణ ఇవ్వవచ్చు. మోడల్ శిక్షణ ప్రక్రియలోనే SDK డిజైన్‌ను కోఎవల్యూవ్ చేయడానికి కూడా ప్రయత్నించవచ్చు. భవిష్యత్ పనిలో మరింత आक्रामक కోడిజైన్ వ్యూహాలను అనుసరించడానికి మేము ఎదురుచూస్తున్నాము.

మోడల్‌లు శోధన ఫలితాలను కేవలం వినియోగించకుండా, శోధన ప్రక్రియను నియంత్రించడానికి అనుమతించడానికి మేము SaCని నిర్మించాము. మా ఫలితాలు ఈ నియంత్రణ యొక్క శక్తిని రుజువు చేస్తాయి: నాలెడ్జ్-ఇంటెన్సివ్ ఏజెంట్ బెంచ్‌మార్క్‌లపై SaC సంపూర్ణ పనితీరు మరియు కాస్ట్-పెర్ఫార్మెన్స్ సరిహద్దు రెండింటినీ ముందుకు తెస్తుంది. Perplexity Computer మరియు Agent APIతో నేటి నుండి ప్రారంభించి, మా వినియోగదారులకు SaC యొక్క సామర్థ్యాలను అందించడానికి మేము సంతోషిస్తున్నాము. మా వినియోగదారులకు (మరియు వారికి సేవనందిస్తున్న ఏజెంట్లకు) సాధ్యమైనంత అత్యంత శక్తివంతమైన మరియు సమర్థవంతమైన శోధన సామర్థ్యాలు ఉండేలా చూసుకోవడానికి స్టాక్ యొక్క అన్ని పొరలలో SaC ఆర్కిటెక్చర్‌ను ఆప్టిమైజ్ చేయడం మేము కొనసాగిస్తాము.

ఉదాహరణ

BibTeX
@online{perplexity2026RethinkingSearchAsCodeGeneration,
  author = {{Perplexity} and Denis Bykov and Aleksandr Nikolenko and Artur Zayats and Maksim Gaiduk and Vitalii Polshkov and Akshay Nair and James Liounis and Kirill Priemko and Ryan Buchmayer and Phi Hoang and Jerry Ma},
  title = {{Rethinking search as code generation}},
  date = {2026-06-01},
  url = {https://perplexity.coolkeypoint.com/hub/blog/rethinking-search-as-code-generation}
}