കോഡ് ജനറേഷനായി തിരച്ചിൽ പുനർവിചിന്തനം ചെയ്യുന്നു

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-ൽ നിന്ന് ഒറ്റത്തവണയുള്ള വിശകലനത്തേക്കാൾ ഉപയോക്താക്കൾ കൂടുതൽ ആവശ്യപ്പെടുന്നു. മണിക്കൂറുകളോ ദിവസങ്ങളോ എടുത്തുകൊണ്ട് ഏജന്റുകൾ ടാസ്കുകൾ എൻഡ്-ടു-എൻഡ് ആയി പൂർത്തിയാക്കുമെന്ന് അവർ പ്രതീക്ഷിക്കുന്നു. ഈ ടാസ്കുകൾ സങ്കീർണ്ണവും തുറന്ന അവസാനമുള്ളതും (open-ended) വിവരങ്ങളുടെ ആവശ്യകതകളിൽ ഉയർന്ന വ്യതിയാനമുള്ളതുമാകാം, കൂടാതെ ഈ ആവശ്യങ്ങളുടെ ഭാരത്തിന് കീഴിൽ മോണോലിത്തിക് ആർക്കിടെക്ചറുകൾ തകരുന്നു.

പ്രധാന തടസ്സം ആത്യന്തികമായി നിയന്ത്രണത്തിന്‍റേതാണ് (control). നിശ്ചിത സന്ദർഭങ്ങളിൽ ന്യായവാദങ്ങൾ നടത്തുന്നതിൽ ഫ്രണ്ടിയർ മോഡലുകൾ ഇതിനകം തന്നെ വളരെ മികച്ചതാണ്. എന്നിരുന്നാലും, ഏറ്റവും ശക്തമായ AI സിസ്റ്റങ്ങൾക്ക് ആ സന്ദർഭം എങ്ങനെ വീണ്ടെടുക്കപ്പെടുന്നു, പ്രോസസ്സ് ചെയ്യപ്പെടുന്നു, മൊത്തത്തിൽ ശേഖരിക്കപ്പെടുന്നു, മോഡലിന് റെൻഡർ ചെയ്യപ്പെടുന്നു എന്നത് നിയന്ത്രിക്കാനുള്ള കഴിവ് ആവശ്യമാണ്.

ഈ അളവിലുള്ള നിയന്ത്രണക്ഷമത മനസ്സിൽ വെച്ചല്ല പരമ്പരാഗത സെർച്ച് സിസ്റ്റങ്ങൾ രൂപകൽപ്പന ചെയ്തിട്ടുള്ളത്. എല്ലാത്തിനുമുപരി, സെർച്ച് പൈപ്പ്‌ലൈൻ ഇന്റേണലുകൾക്ക് മേൽ സൂക്ഷ്മമായ നിയന്ത്രണം പ്രയോഗിക്കാൻ മനുഷ്യരായ ഉപയോക്താക്കൾക്ക് കഴിഞ്ഞേക്കില്ല, അത് വാഗ്ദാനം ചെയ്താൽ പോലും. ആദ്യകാല AI മോഡലുകൾക്ക് ഫങ്ഷൻ കോളുകളുടെയും MCP-കളുടെയും ലീനിയർ പാതയിലൂടെ മാത്രമേ തിരച്ചിൽ നിയന്ത്രിക്കാൻ കഴിയൂ. എന്നാൽ ഇന്നത്തെ ഫ്രണ്ടിയർ മോഡലുകൾ, കോഡ്-കാപ്പബിൾ ഏജന്റ് ഹാർനസുകളാൽ നയിക്കപ്പെടുന്നു, കമ്പ്യൂട്ടർ കോഡിലൂടെ സങ്കൽപ്പിക്കാവുന്ന ഏത് കമ്പ്യൂട്ടേഷണൽ പ്രിമിറ്റീവുകളിലും സൂക്ഷ്മമായ നിയന്ത്രണം പ്രയോഗിക്കാൻ കഴിയും. ശരിയായ പ്രിമിറ്റീവുകൾ നൽകുക എന്നതാണ് നമ്മുടെ ചുമതല.

ഈ ആവശ്യം നിറവേറ്റുന്നതിനായി, ഞങ്ങളുടെ ഉൽപ്പന്നങ്ങളിൽ ഉടനീളം ഞങ്ങൾ ഒരു പുതിയ സെർച്ച് ആർക്കിടെക്ചർ അവതരിപ്പിക്കുന്നു: Search as Code (SaC). ഈ പുതിയ ആർക്കിടെക്ചർ മോഡലുകളെ അതിന്റെ അന്തിമ ഔട്ട്പുട്ടുകൾ മാത്രം ഉപയോഗിക്കുന്നതിന് പകരം സെർച്ച് സ്റ്റാക്കിലേക്ക് തന്നെ കടന്നുചെല്ലാൻ പ്രാപ്തമാക്കുന്നു. പ്രധാന ആശയം ലളിതമാണ്: SDK-ക്കുള്ളിലെ പ്രിമിറ്റീവുകളായി ഞങ്ങൾ സെർച്ച് സ്റ്റാക്കിന്റെ ഘടകങ്ങളെ തുറന്നുകാട്ടുന്നു. തിരച്ചിൽ ആവശ്യമുള്ള ഏത് അഭ്യർത്ഥനയ്ക്കും, ഒരു മോഡൽ ഈ പ്രിമിറ്റീവുകളെ ഓൺ-ഡിമാൻഡ് ആയി ആ നിർദ്ദിഷ്ട അഭ്യർത്ഥനയ്ക്ക് അനുയോജ്യമായ ഒരു റിട്രീവൽ പൈപ്പ്‌ലൈനിലേക്ക് ഒരുമിച്ച് ചേർക്കുന്നു.

സുരക്ഷിതമായ ഒരു സാൻഡ്‌ബോക്സിനുള്ളിലെ കോഡ് ജനറേഷനിലൂടെയും എക്സിക്യൂഷനിലൂടെയുമാണ് ഈ പൈപ്പ്‌ലൈൻ കൂട്ടിച്ചേർക്കുന്നത്. തിരച്ചിലിനായുള്ള മറ്റ് കോഡെജൻ-ഡ്രിവൻ സമീപനങ്ങളിൽ നിന്ന് വ്യത്യസ്തമായി, ഞങ്ങൾ പരമ്പരാഗത സെർച്ച് API ഒരു ഷെല്ലിനോ ലാംഗ്വേജ് റൺടൈമിനോ ഉള്ളിൽ വെറുതെ ഒട്ടിക്കുകയല്ല ചെയ്യുന്നത്. പകരം, സാധ്യമായ ഏറ്റവും ആറ്റോമിക തലത്തിൽ തിരച്ചിലിന്റെ വ്യക്തിഗത നിർമ്മാണ ബ്ലോക്കുകൾ തുറന്നുകാട്ടുന്ന ഒരു Agentic Search SDK ഞങ്ങൾ ശ്രദ്ധാപൂർവ്വം എഞ്ചിനീയർ ചെയ്തിട്ടുണ്ട്.

Search as Code (SaC) വിവിധതരം ബെഞ്ച്മാർക്കുകളിൽ ഏജന്റിക് തിരച്ചിലിന്റെ പ്രകടന അതിരുകൾ മുന്നോട്ട് നയിക്കുന്നു.

ഈ ബിൽഡിംഗ് ബ്ലോക്കുകൾ ഉപയോഗിച്ച്, റിട്രീവൽ, റാങ്കിംഗ്, ഫിൽട്ടറിംഗ്, ഫാനൗട്ടുകൾ, റെൻഡറിംഗ് എന്നിവയും അതിലേറെയും പോലുള്ള ഓരോ വ്യക്തിഗത സെർച്ച് ഘട്ടത്തിനും മേൽ നേരിട്ടുള്ള നിയന്ത്രണം SaC മോഡലുകൾക്ക് നൽകുന്നു. കാൻഡിഡേറ്റ് ലിസ്റ്റുകൾ, റാങ്കിംഗ് സിഗ്നലുകൾ തുടങ്ങിയ ഇടക്കാല അവസ്ഥകളിലേക്ക് (intermediate state) ഇത് മോഡലിന് കാര്യക്ഷമമായ ആക്‌സസ് നൽകുന്നു. നിയന്ത്രണത്തിന്റെയും വ്യക്തതയുടെയും ഈ ഇരട്ട ലിവറുകൾ ഒരുമിച്ച്, ആയിരക്കണക്കിന് റിട്രീവൽ പ്രവർത്തനങ്ങൾ ഉൾക്കൊള്ളുന്ന ബെസ്പോക്ക് സെർച്ച് പൈപ്പ്‌ലൈനുകൾ രൂപകൽപ്പന ചെയ്യാനും, ഇൻ-ഫ്ലൈറ്റ് ആയി ആ പൈപ്പ്‌ലൈനുകൾ ഒപ്റ്റിമൈസ് ചെയ്യാനും, മോഡൽ സന്ദർഭമായി ഏറ്റവും ഉപയോഗപ്രദമായ വിവരങ്ങൾ മാത്രം ഉപയോോഗിക്കാനും ഏജന്റുകളെ അനുവദിക്കുന്നു.

ഈ ലേഖനം SaC-ന്റെ പ്രചോദനം, രൂപകൽപ്പന, നടപ്പിലാക്കൽ എന്നിവ നിലവിലുള്ളതും പുതിയതുമായ ബെഞ്ച്മാർക്കുകളിലെ അനുഭവപരമായ ഫലങ്ങൾക്കൊപ്പം വിവരിക്കുന്നു. SaC ഏജന്റിക് തിരച്ചിലിനായി ഒരു പുതിയ ചെലവ്-പ്രകടന അതിർത്തി സ്ഥാപിക്കുന്നു, ഒപ്പം ഞങ്ങളുടെ ഉപയോക്താക്കളുമായും വിശാലമായ AI കമ്മ്യൂണിറ്റിയുമായും ഇത് പങ്കിടുന്നതിൽ ഞങ്ങൾക്ക് സന്തോഷമുണ്ട്.

ലോകത്തിലെ ആദ്യത്തെ സെർച്ച് എഞ്ചിനുകൾ മനുഷ്യരായ ഉപയോക്താക്കൾക്കായി നിർമ്മിച്ചവയാണ്. ഈ ഉപയോക്താക്കൾ പ്രവചനാതീതമായ ഒരു അനുഭവം പ്രതീക്ഷിക്കാൻ തുടങ്ങി, സാധാരണയായി ഇത് മുൻകൂട്ടി നിശ്ചയിച്ച പ്രസക്തിയാൽ റാങ്ക് ചെയ്യപ്പെട്ട ഡോക്യുമെന്റുകൾ അടങ്ങിയതായിരുന്നു. ഉപയോക്താക്കൾ സെർച്ച് പ്രക്രിയ മൈക്രോമാനേജ് ചെയ്യാൻ ആഗ്രഹിച്ചില്ല; അവർ ഒരു ചോദ്യം നൽകാനും ഉപയോഗപ്രദമായ ഒരു ഫലം കണ്ടെത്താനും ആഗ്രഹിച്ചു.

ഫലമായി, മനുഷ്യർക്ക് അനുയോജ്യമായ സെർച്ച് എഞ്ചിനുകൾ ഒരു പൊതു മോണോലിത്തിക് ആർക്കിടെക്ചറിലേക്ക് വന്നുചേർന്നു, ഇത് ഇൻപുട്ട് ചോദ്യത്തിനായി മികച്ച n ഹിറ്റുകൾ അടങ്ങിയ മനുഷ്യർക്ക് അനുയോജ്യമായ സെർച്ച് എഞ്ചിൻ ഫല പേജുകൾ (SERPs) നിർമ്മിക്കുന്നതിന് ലക്ഷ്യമിട്ടുള്ളതാണ്. കൺസ്യൂമർ സെർച്ചിൽ പതിറ്റാടുകളുടെ പുരോഗതിക്ക് ഈ മാതൃക കരുത്തുപകർന്നു. ഇത് വേഗതയേറിയതും പരിചിതവും മനുഷ്യരുടെ ബ്രൗസിംഗിന് വളരെ ഫലപ്രദവുമാണ്.

തുടർന്ന് LLM-കൾ വന്നു, AI സിസ്റ്റങ്ങളും തിരച്ചിലിന്റെ ഉപയോക്താക്കളായി മാറി. 2022-ൽ ഞങ്ങളുടെ ആൻസർ എഞ്ചിൻ സമാരംഭിച്ചുകൊണ്ട് Perplexity ഈ മാറ്റത്തിന് തുടക്കമിട്ടു. അന്നുമുതൽ, AI മോഡലുകൾക്കായി തിരച്ചിൽ ഫലങ്ങളുടെ മൂല്യം ഒപ്റ്റിമൈസ് ചെയ്യുന്നത് എങ്ങനെയെന്നതിലാണ് ഞങ്ങളുടെ സെർച്ച് എഞ്ചിനീയറിംഗ് ശ്രമങ്ങൾ ശ്രദ്ധ കേന്ദ്രീകരിച്ചിരിക്കുന്നത്. ലോകത്തിലെ ഏറ്റവും കൃത്യവും വിശ്വസനീയവുമായ AI നിർമ്മിക്കാൻ, ഓരോ ടോക്കണും വിവരങ്ങൾ കൊണ്ട് കഴിയത്ര സമ്പന്നമാക്കുന്നതിൽ ശ്രദ്ധ കേന്ദ്രീകരിച്ച ഒരു സെർച്ച് സിസ്റ്റം ഞങ്ങൾ എഞ്ചിനീയർ ചെയ്യേണ്ടതുണ്ട്. സബ്-ഡോക്യുമെന്റ് റിട്രീവൽ, സന്ദർഭ കാര്യക്ഷമത, സെമാന്റിക് മനസ്സിലാക്കൽ, മറ്റ് പ്രധാന മേഖലകൾ എന്നിവയിലെ ഫലമായുണ്ടായ നവീകരണങ്ങൾ വിവരങ്ങൾ വീണ്ടെടുക്കാനും അതിൽ പ്രവർത്തിക്കാനുമുള്ള AI സിസ്റ്റങ്ങളുടെ കഴിവിൽ നാടകീയമായ പുരോഗതിക്ക് കാരണമായി.

എന്നിരുന്നാലും, AI- ഒപ്റ്റിമൈസ് ചെയ്ത സിസ്റ്റങ്ങൾ പോലും പരമ്പരാഗത സെർച്ച് എഞ്ചിനുകളുടെ അതേ അടിസ്ഥാന കരാർ വലിയതോതിൽ പാരമ്പര്യമായി സ്വീകരിച്ചിരിക്കുന്നു: ഒരു ചോദ്യം സ്വീകരിക്കുക, മുൻകൂട്ടി നിശ്ചയിച്ച സെർച്ച് പൈപ്പ്‌ലൈൻ പ്രവർത്തിപ്പിക്കുക, പൂർണ്ണമായി പ്രോസസ്സ് ചെയ്ത റിസൾട്ട്സെറ്റ് തിരികെ നൽകുക. ലളിതമായ അഭ്യർത്ഥനകൾക്ക്, ഈ സമീപനം നന്നായി പ്രവർത്തിക്കുന്നു. എന്നാൽ കൂടുതൽ സങ്കീർണ്ണമായ അഭ്യർത്ഥനകൾക്ക്, ഇത് പ്രകടനം, ലേറ്റൻസി, ചെലവ് എന്നിവ കുറയ്ക്കുന്ന വർദ്ധിച്ചുവരുന്ന പരിമിതമായ തടസ്സമായി മാറുന്നു.

പരമ്പരാഗത സെർച്ച് സിസ്റ്റങ്ങൾ മോഡലിന് ദൃശ്യമാകുന്ന ടേണുകളിലൂടെ തിരച്ചിൽ ക്രമീകരിക്കാൻ ഏജന്റിക് വർക്ക്ഫ്ലോകളെ നിർബന്ധിക്കുന്നു. മോഡലുകൾ വ്യത്യസ്ത ചോദ്യ പാരാമീറ്ററുകളിലുടനീളം ഒരേ സെർച്ച് പൈപ്പ്‌ലൈനുകൾ ആവർത്തിച്ച് കോൾ ചെയ്യുകയും എല്ലാ ഫലങ്ങളും മോഡൽ സന്ദർഭത്തിലേക്ക് കൊണ്ടുവരുകയും വേണം.

പരമ്പരാഗത സെർച്ച് പൈപ്പ്‌ലൈനുകൾ ഒരു നിയന്ത്രണ ബിന്ദിന ചുറ്റും രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നു: ചോദ്യ പാരാമീറ്ററുകൾ. സെർച്ച് എഞ്ചിൻ അതിന്റെ മുൻകൂട്ടി നിശ്ചയിച്ച ലോജിക് അനുസരിച്ച് പൈപ്പ്‌ലൈനിന്റെ ബാക്കി ഭാഗങ്ങൾ സ്വന്തമാക്കുന്നു, കൂടാതെ മോഡൽ അതിനോട് പൊരുത്തപ്പെടണം. മോഡലിനെ സംബന്ധിച്ചിടത്തോളം, ചോദ്യ പാരാമീറ്ററുകളുടെ ഡൗൺസ്ട്രീം ആയിട്ടുള്ള ഏതും കടുപ്പമേറിയതാണ് - യഥാർത്ഥ കമ്പ്യൂട്ടേഷന്റെ ആകൃതി മോഡലിന്റെ നിയന്ത്രണത്തിന് പുറത്താണ്.

ഉപയോക്താവ് ലിങ്കുകൾ സ്കാൻ ചെയ്യുന്ന ഒരു മനുഷ്യനാകുമ്പോൾ ഇതൊരു സെൻസിബിൾ അതിർത്തിയാണ്. ക്ലോസ്ഡ് ലൂപ്പിൽ അറിവ് ആവശ്യപ്പെടുന്ന ടാസ്കുകൾ പരിഹരിക്കാൻ ശ്രമിക്കുന്ന ഒരു AI മോഡലാണ് ഉപയോക്താവ് എങ്കിൽ ഇത് മോശമായ ഒരു അതിർത്തിയാണ്. ഞങ്ങളുടെ അനുഭവത്തിൽ, ഈ കാഠിന്യം ആവർത്തിച്ചുള്ള മൂന്ന് പരാജയ മോഡുകൾ സൃഷ്ടിക്കുന്നു:

കരടായ കോൺടെക്സ്‌റ്റ്. എഐ മോഡലുകൾ കോൺടെക്സ്‌റ്റിന്റെ ഗുണനിലവാരത്തോടും സങ്കുചിതത്വത്തോടും സംവേദനശീലമാണ്. ഗുണനിലവാരവും സങ്കുചിതത്വവും രണ്ടും ചോദ്യം-ആശ്രിതമായി വളരെ മാറുന്നതാണ്, കൂടാതെ ഏകശിലാസദൃശമായ സെർച്ച് പൈപ്പ്‌ലൈനുകൾ എല്ലാ ചോദ്യങ്ങളിലും മികച്ച പ്രകടനം നൽകാനായി രൂപകൽപ്പന ചെയ്തിട്ടില്ല. ഉദാഹരണത്തിന്, ഒരു മോഡലിന് വളരെ ശസ്ത്രക്രിയാസമമായ ഒരു വിവരഭാഗം മാത്രം ആവശ്യമാണെങ്കിലും, റിക്കോൾ മുൻഗണന നൽകുന്ന ഒരു എൻഡ്-ടു-എൻഡ് സെർച്ച് എൻഡ്പോയിന്റിലേക്കാണ് അതിന് പ്രവേശനം ഉള്ളത് എങ്കിൽ, ആ എൻഡ്പോയിന്റ് ഉപയോഗിക്കുന്നത് മോഡലിന്റെ കോൺടെക്സ്‌റ്റിലേക്ക് വലിയ തോതിൽ അസംബന്ധമായ വിവരങ്ങൾ കൊണ്ടുവരും. മറുവശത്ത്, ഒരു മോഡലിന് ഓരോന്നിനും വ്യത്യസ്ത സെർച്ച് തന്ത്രങ്ങൾ ആവശ്യമായ നിരവധി വിവരഭാഗങ്ങൾ വേണമെങ്കിൽ, അവയ്‌ക്കെല്ലാം ഒരേ ഉപോത്തമമല്ലാത്ത പൈപ്പ്‌ലൈൻ അനുക്രമമായി വിളിക്കാൻ അത് നിർബന്ധിതമാകാം; ഇതിന്റെ ഫലമായി ചെലവുകൾ കുതിച്ചുയരുകയും കോൺടെക്സ്‌റ്റ് ശബ്ദമേറിയതാകുകയും ചെയ്യും.

ഡൊമെയ്ൻ അറിവ് പ്രയോജനപ്പെടുത്തുന്നതിൽ പരാജയപ്പെടുന്നു. പല സാഹചര്യങ്ങളിലും, സെർച്ച് തന്ത്രത്തെ നയിക്കേണ്ട ഡൊമെയ്ൻ അറിവ് (അതിന്റെ പരിശീലനം, ഒരു ഏജന്റ് നൈപുണ്യം, മെമ്മറി അല്ലെങ്കിൽ LLM പാതയിലെ മുൻ ടോക്കണുകൾ എന്നിവയിൽ നിന്ന്) മോഡലിന് ഉണ്ടായേക്കാം. എന്നിരുന്നാലും, കടുപ്പമേറിയ ഒരു സെർച്ച് ഇന്റർഫേസ് ആ അറിവ് പ്രയോജനപ്പെടുത്തുന്നതിൽ നിന്ന് മോഡലിനെ തടയുന്നു. ഉദാഹരണത്തിന്, ഒരു നിർദ്ദിഷ്ട അഭ്യർത്ഥനയ്ക്കായി, ലെക്സിക്കൽ, സെമാന്റിക് സിഗ്നലുകൾ ഒരു പ്രത്യേക രീതിയിൽ മിശ്രിതം ചെയ്യണമെന്നോ, ചില ഉറവിടങ്ങൾക്ക് മുൻഗണന നൽകണമെന്നോ അല്ലെങ്കിൽ ഒരു പ്രത്യേക കീ പ്രകാരം ഫലങ്ങൾ ശേഖരിക്കണമെന്നോ മോഡൽ മനസ്സിലാക്കിയേക്കാം. ചോദ്യ പാരാമീറ്ററുകളിലൂടെ ആ ഉൾക്കാഴ്ചകൾ നടപ്പിലാക്കാൻ കഴിയുന്നില്ലെങ്കിൽ, മോഡലിന് യഥാർത്ഥത്തിൽ അവയിൽ പ്രവർത്തിക്കാൻ കഴിയില്ല.

അക്ഷമമായ നിയന്ത്രണ പ്രവാഹവും സന്ദർഭ മലിനീകരണവും (Inefficient control flow and context pollution). പല സെർച്ച് വർക്ക്ഫ്ലോകളും സ്വാഭാവികമായും സീരിയൽ അല്ല. ചോദ്യ വേരിയന്റുകളിലൂടെ ഫാൻ-ഔട്ട്, സമാന്തര ഫെച്ചിംഗ്, ഡ്യൂപ്ലിക്കേഷൻ നീക്കംചെയ്യൽ, നോൺ-ലീനിയർ, അസിൻക്രണസ് കൺട്രോൾ ഫ്ലോ എന്നിവ ആവശ്യപ്പെടുന്ന മറ്റ് പ്രവർത്തനങ്ങൾ അവയ്ക്ക് ആവശ്യമായി വന്നേക്കാം. ആവർത്തിച്ചുള്ള മോഡൽ ടേണുകളിലൂടെ ഈ ഘട്ടങ്ങൾ നിർബന്ധിക്കുന്നത് ലേറ്റൻസി വർദ്ധിപ്പിക്കുകയും വർക്ക്ഫ്ലോ ഒപ്റ്റിമൈസ് ചെയ്യുന്നത് പ്രയാസകരമാക്കുകയും ചെയ്യുന്നു. മോഡലിന്റെ ന്യായവാദത്തിന് ഉപയോഗപ്രദമല്ലാത്ത ശബ്ദമുണ്ടാക്കുന്ന ഇടക്കാല അവസ്ഥ ഉപയോഗിച്ച് ഇത് മോഡൽ സന്ദർഭത്തെ മലിനമാക്കുകയും ചെയ്യുന്നു, ഇത് മോശമായ പ്രകടനത്തിലേക്കും കൂടുതൽ തവണ കോമ്പാക്ഷനുകളിലേക്കും നയിക്കുന്നു.

AI-യുടെ ഫങ്ഷൻ കോളിംഗ് & MCP യുഗങ്ങളിൽ ഈ വെല്ലുവിളികളെക്കുറിച്ച് കാര്യമായൊന്നും ചെയ്യാൻ കഴിഞ്ഞിരുന്നില്ല. ഓരോ സെർച്ച് പ്രവർത്തനത്തിനും LLM ഇൻഫറൻസിലേക്ക് സ്വന്തം റൗണ്ട് ട്രിപ്പ് ആവശ്യപ്പെടുമ്പോൾ, ഡെവലപ്പർമാർ സ്വാഭാവികമായും ആ റൗണ്ട് ട്രിപ്പിൽ പരമാവധി കാര്യങ്ങൾ ചെയ്തുതീർക്കാൻ താല്പര്യപ്പെടുന്നു. ഇതിനർത്ഥം ഒരു മോഡലിന് നേരിട്ട് ഉപയോഗിക്കുന്നതിനായി പൂർണ്ണമായി പ്രോസസ്സ് ചെയ്ത റിസൾട്ട്സെറ്റുകൾ തിരികെ നൽകുന്ന എൻഡ്-ടു-എൻഡ് സെർച്ച് പൈപ്പ്‌ലൈനുകൾ എന്നാണ്.

ഫലമായി, ഇന്നത്തെ മിക്ക AI-കേന്ദ്രീകൃത സെർച്ച് സിസ്റ്റങ്ങളും ഈ മോണോലിത്തിക് കരാറിന് കീഴിലാണ് പ്രവർത്തിക്കുന്നത്. എന്നിരുന്നാലും, മോഡൽ ബുദ്ധിശക്തിയിലും ഉപയോക്താക്കളുടെ ആവശ്യങ്ങളിലും തുടർച്ചയായ വളർച്ചയോടെ, ആ കരാറിന്റെ പോരായ്മകൾ കൂടുതൽ പ്രകടമാകുന്നു. കോഡ്-ഫസ്റ്റ് ഹാർനസുകൾക്ക് മുകളിൽ നിർമ്മിച്ച ഇന്നത്തെ ഏറ്റവും നൂതനമായ AI സിസ്റ്റങ്ങൾക്ക്, ഓരോ മിനിറ്റിലും ആയിരക്കണക്കിന് പ്രവർത്തനങ്ങൾ നടപ്പിലാക്കുന്ന ടാസ്ക്-നിർദ്ദിഷ്ട വർക്ക്ഫ്ലോകൾ കമ്പോസ് ചെയ്യാൻ കഴിയും. സെർച്ച് സിസ്റ്റങ്ങൾ ഈ സാധ്യത ഇതുവരെ പൂർണ്ണമായി മനസ്സിലാക്കിയിട്ടില്ല.

AI- നേറ്റീവ് തിരച്ചിലിനുള്ള ശരിയായ അതിർത്തി സ്റ്റാക്കിൽ താഴെയാണെന്ന് ഞങ്ങൾ দীর্ঘদিন ধরে സംശയിച്ചിരുന്നു. മോഡലുകൾ ഒരു സെർച്ച് എഞ്ചിനെ വെറുതെ കോൾ ചെയ്യുകയല്ല വേണ്ടത്. നിർദ്ദിഷ്ട ടാസ്ക് ആവശ്യപ്പെടുന്നതനുസരിച്ച് സെർച്ച് സ്റ്റാക്കിന്റെ വ്യക്തിഗത ഭാഗങ്ങൾ ഓർക്കസ്ട്രേറ്റ് ചെയ്യാൻ അവയ്ക്ക് കഴിയണം. അതിന് അടിസ്ഥാനപരമായി വ്യത്യസ്തമായ ഒരു ആർക്കിടെക്ചർ ആവശ്യമാണ്.

അടുത്ത തലമുറയിലെ സെർച്ച് ആർക്കിടെക്ചറുകൾ ഒരു പ്രധാന തത്വത്തെ ആശ്രയിച്ചിരിക്കും: AI ഏജന്റുകൾക്ക് നേറ്റീവ് ആയി പ്രോഗ്രാം ചെയ്യാവുന്നതായിരിക്കണം തിരച്ചിൽ. ഒരു ഏജന്റ് മുൻകൂട്ടി നിശ്ചയിച്ച സെർച്ച് പൈപ്പ്‌ലൈനുകളുടെ ഒരു കൂട്ടത്തിൽ മാത്രമായി പരിമിതപ്പെടുത്തരുത്. മറിച്ച്, വൈവിധ്യമാർന്ന അമൂർത്തീകരണ തലങ്ങളിൽ രൂപകൽപ്പന ചെയ്ത കമ്പോസബിൾ ബിൽഡിംഗ് ബ്ലോക്കുകൾ ഉപയോഗിച്ച്, നിർദ്ദിഷ്ട ടാസ്ക് ആവശ്യപ്പെടുന്ന പൈപ്പ്‌ലൈൻ നിർമ്മിക്കാൻ ഒരു ഏജന്റിന് കഴിയണം.

ഞങ്ങളുടെ പുതിയ Search as Code (SaC) ആർക്കിടെക്ചർ ഈ തത്വത്തെ ഉൾക്കൊള്ളുന്നു. SaC-ൽ, ഫങ്ഷൻ കോളിംഗ് അല്ലെങ്കിൽ MCP ഇന്റർഫേസ് വഴി ഒരു റിട്രീവൽ പ്രവർത്തനം പോലും അയക്കുന്നില്ല. പകരം എല്ലാ പ്രവർത്തനങ്ങളും മോഡൽ ജനറേറ്റഡ് പൈത്തൺ കോഡ് വഴി ഓർക്കസ്ട്രേറ്റ് ചെയ്യപ്പെടുന്നു. ഏറ്റവും ലളിതമായ തിരച്ചിൽ ആവശ്യങ്ങൾക്ക്, ഈ കോഡിൽ ഉയർന്ന തലത്തിലുള്ള സെർച്ച് എൻഡ്‌പോയിന്റിലേക്കുള്ള ഏതാനും അഭ്യർത്ഥനകൾ അടങ്ങിയിരിക്കാം. എന്നാൽ സങ്കീർണ്ണമായ ടാസ്കുകൾക്ക്, സോപാധികമായ എക്സിക്യൂഷൻ (conditional execution), അസിൻക്രണസി, പാരലലിസം, താഴ്ന്ന നിലയിലുള്ള പ്രിമിറ്റീവുകളുടെ വിശാലമായ ശ്രേണിയിലേക്കുള്ള കോളുകൾ എന്നിവ ഉൾപ്പെടുത്തിക്കൊണ്ട് കോഡ് ആവശ്യാനുസരണം സങ്കീർണ്ണമാകാം.

Search as Code (SaC) ആർക്കിടെക്ചർ Perplexity-യുടെ സെർച്ച് ഇൻഫ്രാസ്ട്രക്ചറിന് മുകളിൽ ഇരിക്കുന്ന മോഡലുകൾ, കമ്പ്യൂട്ട് സാൻഡ്‌ബോക്സുകൾ, ഒരു Agentic Search SDK എന്നിവ അടങ്ങിയ ഒരു സ്റ്റാക്കിനെ ആശ്രയിച്ചിരിക്കുന്നു.

SaC-ൽ പരസ്പരം ഇണചേർന്ന മൂന്ന് പാളികൾ ഉൾപ്പെടുന്നു:

മോഡലുകൾ (Models) കൺട്രോൾ പ്ലേനായി പ്രവർത്തിക്കുന്നു. അവർ ഉപയോക്താവിന്റെ (അല്ലെങ്കിൽ പാരന്റ് ഏജന്റിന്റെ) നിർദ്ദേശത്തെക്കുറിച്ച് ചിന്തിക്കുകയും, നിർദ്ദേശത്തെ ടാസ്കുകളായി വിഭജിക്കുകയും, ഓരോ ടാസ്കിനും ഏത് റിട്രീവൽ, പ്രോസസ്സിംഗ് പൈപ്പ്‌ലൈനുകളാണ് വേണ്ടതെന്ന് തീരുമാനിക്കുകയും, ആ പൈപ്പ്‌ലൈനുകൾ നടപ്പിലാക്കാൻ കോഡ് ജനറേറ്റുചെയ്യുകയും ചെയ്യുന്നു.

കമ്പ്യൂട്ട് സാൻഡ്‌ബോക്സുകൾ (Compute sandboxes) സുരക്ഷിതമായ കോഡ് എക്സിക്യൂഷൻ റൺടൈം വഴി ഡിറ്റർമിനിസ്റ്റിക് കമ്പ്യൂട്ട് നൽകുന്നു. കൺട്രോൾ ഫ്ലോ, ബാച്ചിങ്, റീട്രൈകൾ, ഫിൽട്ടറിംഗ്, ജോയിനിങ്, അഗ്രഗേഷൻ, മറ്റ് ഡിറ്റർമിനിസ്റ്റിക് പ്രവർത്തനങ്ങൾ എന്നിവ നടപ്പിലാക്കാൻ മോഡലുകൾക്ക് അവ ഒരു ക്യാൻവാസ് നൽകുന്നു.

ഞങ്ങളുടെ Agentic Search SDK Perplexity-യുടെ സെർച്ച് സ്റ്റാക്കിനെ കമ്പോസബിൾ പ്രിമിറ്റീവുകളായി തുറന്നുകാട്ടുന്നു. ഇത് താഴ്ന്ന നിലയിലുള്ള റിട്രീവൽ പ്രവർത്തനങ്ങൾ മുതൽ ഉയർന്ന തലത്തിലുള്ള സെമാന്റിക് പാഴ്സിങ് വരെയുള്ള നിർമ്മാണ ബ്ലോക്കുകൾ നൽകുന്നു. സാൻഡ്‌ബോക്സുകളുടെ എക്സിക്യൂഷൻ റൺടൈമുകൾക്കുള്ളിൽ SDK ഉൾച്ചേർത്തിരിക്കുന്നു, ഇത് ഒ ഒറ്റ ഇൻഫറൻസ് ടേണിനുള്ളിൽ ആയിരക്കണക്കിന് പ്രവർത്തനങ്ങൾ വരെ ഓർക്കസ്ട്രേറ്റ് ചെയ്യാൻ മോഡലുകളെ അനുവദിക്കുന്നു. താഴെ, ഓരോ പാളിക്കും ഞങ്ങൾ ഞങ്ങളുടെ ഡിസൈൻ തീരുമാനങ്ങൾ ചർച്ച ചെയ്യുന്നു.

പ്രോഗ്രാം ചെയ്യാവുന്ന തിരച്ചിലിനായുള്ള ബിൽഡിംഗ് ബ്ലോക്കുകൾ Agentic Search SDK നിർവ്വചിക്കുന്നു. പ്രധാനപ്പെട്ട കാര്യം, ഞങ്ങളുടെ SDK ഒരു ലൈബ്രറിയായി പാക്കേജ് ചെയ്തിട്ടുള്ള നിലവിലുള്ള സെർച്ച് API അല്ല. കഴിഞ്ഞ കുറച്ച് മാസങ്ങളായി, ഞങ്ങളുടെ എഞ്ചിനീയറിംഗ് ടീം ഞങ്ങളുടെ സെർച്ച് സ്റ്റാക്കിനെ മോഡുലറും കമ്പോസബിളായ പ്രിമിറ്റീവുകളുമായി പുനർരൂപകൽപ്പന ചെയ്തിട്ടുണ്ട്. ടാസ്ക്-നിർദ്ദിഷ്ട റിട്രീവൽ പൈപ്പ്‌ലൈനുകൾ മോഡലിന് ഓർക്കസ്ട്രേറ്റ് ചെയ്യാൻ കഴിയുന്ന വളരെ ശക്തമായ ഒരു ക്യാൻവാസ് നൽകുന്നതിനായി ഞങ്ങൾ Agentic Search SDK നിർമ്മിച്ചിട്ടുണ്ട്.

ഉയർന്ന തലത്തിലുള്ള, എൻഡ്-ടു-എൻഡ് സെർച്ച് പൈപ്പ്‌ലൈനുകൾ SDK-ൽ ഇപ്പോഴും ലഭ്യമാണ്, പക്ഷേ അവ ഇനി ഏക ഓപ്ഷനല്ല. പകരം, അവ പൊതുവായ സെർച്ച് പാറ്റേണുകൾക്കുള്ള ഒരുതരം ചുരുക്കരൂപമായി പ്രവർത്തിക്കുന്നു. ടാസ്ക് ആവശ്യപ്പെടുന്നതനുസരിച്ച് അവ ഉപയോഗിക്കാനോ ഒഴിവാക്കാനോ മോഡലിന് സ്വാതന്ത്ര്യമുണ്ട്.

റൺടൈമിന്റെ തിരഞ്ഞെടുപ്പ്: SDK റൺടൈമായി ഞങ്ങൾ പൈത്തൺ (Python), റസ്റ്റ്, ടൈപ്പ്സ്ക്രിപ്റ്റ്, ബാഷ് എന്നിവ പരിഗണിച്ചു. ഡാറ്റ പ്രോസസ്സിംഗ് ലൈബ്രറികളുടെ സർവ്വവ്യാപകത്വവും ആവാസവ്യവസ്ഥയും കാരണം പൈത്തൺ ഏറ്റവും സ്വാഭാവികമായ ഇണക്കമായിരിക്കുമെന്ന് ഞങ്ങൾ സംശയിച്ചു. ആന്തരിക പരിശോധന ഇത് സ്ഥിരീകരിച്ചു, ഇന്ന് പുറത്തിറങ്ങുന്ന SDK-യുടെ പതിപ്പ് പൈത്തൺ അടിസ്ഥാനമാക്കിയുള്ളതാണ്. ഏജന്റിന് മികച്ച അനുഭവം தொடர்ந்து നൽകുന്നുണ്ടെന്ന് ഉറപ്പാക്കാൻ റൺടൈമിന്റെ തിരഞ്ഞെടുപ്പ് ഇടയ്ക്കിടെ പുനർമൂല്യനിർണ്ണയം ചെയ്യുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു.

ഓട്ടോസെർച്ച് വഴിയുള്ള തുടർച്ചയായ പുരോഗതി: ഒരു ആവർത്തന ഓട്ടോസെർച്ച് ലൂപ്പിലൂടെ ഫ്രണ്ടിയർ LLM-കൾക്കായി SDK-യുടെ ഉപയോഗക്ഷമതയും ഞങ്ങൾ ഒപ്റ്റിമൈസ് ചെയ്തിട്ടുണ്ട്. ആഴ്ചകളോളം തുടർച്ചയായി പ്രവർത്തിക്കുന്ന ഈ ലൂപ്പ്, ലേറ്റൻസി, കോഡെജൻ ഗുണനിലവാരം, മൊത്തത്തിലുള്ള ടാസ്ക് പ്രകടനം എന്നിവയുൾപ്പെടെയുള്ള മെട്രിക്സുകൾക്ക് എതിരായി SDK മെച്ചപ്പെടുത്തലുകൾ നിർദ്ദേശിക്കുകയും സാധൂകരിക്കുകയും ചെയ്യുന്നു. ഓട്ടോസെർച്ച് ലൂപ്പ് ഇതിനകം തന്നെ SDK-യുടെ ഘടനയിലും സൗന്ദര്യശാസ്ത്രത്തിലും നിരവധി മാറ്റങ്ങൾ വരുത്തിയിട്ടുണ്ട്, എല്ലാ അളവുകളിലും കാര്യമായ നേട്ടങ്ങൾ കൈവരിച്ചു. പുതിയ ഫ്രണ്ടിയർ മോഡലുകളും സെർച്ച് ഘടകങ്ങളും ഉയർന്നുവരുമ്പോൾ ഓട്ടോസെർച്ച് വഴി SDK കൂടുതൽ പരിഷ്കരിക്കാൻ ഞങ്ങൾ പദ്ധതിയിടുന്നു.

SaC പൈപ്പ്‌ലൈനുകൾ നിർവ്വചിക്കുന്നതിനും പ്രവർത്തിപ്പിക്കുന്നതിനും സാൻഡ്‌ബോക്സുകൾ സുരക്ഷിതമായ പരിതസ്ഥിതികൾ നൽകുന്നു. വ്യക്തിഗത സെർച്ച് പ്രിമിറ്റീവുകളുമായുള്ള ഇടപെടൽ സുഗമമാക്കുന്നതിന് Agentic Search SDK-യിലേക്ക് പ്രവേശനം നൽകിക്കൊണ്ട് അവ മോഡൽ ജനറേറ്റഡ് കോഡ് എക്സിക്യൂട്ട് ചെയ്യുന്നു.

ഞങ്ങളുടെ സാൻഡ്‌ബോക്സുകൾ ഒപ്റ്റിമൈസ് ചെയ്യുന്നതിലും ഹാർഡനിങ് ചെയ്യുന്നതിലും ഞങ്ങൾ കാര്യമായ നിക്ഷേപം നടത്തിയിട്ടുണ്ട്, കൂടാതെ അവയുടെ മൊത്തത്തിലുള്ള സിസ്റ്റം ഡിസൈൻ സ്വന്തമായി ഒരു ലേഖനം അർഹിക്കുന്നു. ഇവിടെ, SaC-യുമായി ഏറ്റവും പ്രസക്തമായ ഡിസൈൻ പരിഗണനയിൽ ഞങ്ങൾ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നു: ഇടക്കാല അവസ്ഥകൾ കൈകാര്യം ചെയ്യുക (managing intermediate states).

ഒ ഒറ്റ ഇൻഫറൻസ് ടേണിനുള്ളിൽ സങ്കീർണ്ണമായ പൈപ്പ്‌ലൈനുകൾ ഓർക്കസ്ട്രേറ്റ് ചെയ്യാൻ SaC ഏജന്റുകളെ പ്രാപ്തരാക്കുന്നു. എന്നിരുന്നാലും, ചില ഇടക്കാല അവസ്ഥകൾ ടേണുകളിലുടനീളം അറിയിക്കേണ്ടതുണ്ട്. ഉദാഹരണത്തിന്, ടേൺ 1-ൽ ചില ഡോക്യുമെന്റുകൾ ഫെച്ച് ചെയ്യാനും, അടുത്തത് എന്തുചെയ്യണമെന്ന് തീരുമാനിക്കാൻ ടേൺ 2-ൽ ആ ഡോക്യുമെന്റുകളുടെ ഒരു ഉപമാതൃക പരിശോധിക്കാനും, തുടർന്ന് ടേൺ 3 മുതൽ ആ ഡോക്യുമെന്റുകൾ കൂടുതൽ അന്വേഷിക്കുന്നതിനായി ഒരു ഡൗൺസ്ട്രീം സെർച്ച് പൈപ്പ്‌ലൈൻ വികസിപ്പിക്കാനും ഒരു മോഡൽ ആഗ്രഹിച്ചേക്കാം. മുകളിൽ ചർച്ച ചെയ്തതുപോലെ, ടോക്കൺ സ്പേസ് വഴി ഇടക്കാല അവസ്ഥകൾ കൈമാറുന്നത് ഫലപ്രദമായ ഒരു തന്ത്രമല്ല.

ടേണുകളിലുടനീളം ഇടക്കാല അവസ്ഥകൾ കൈകാര്യം ചെയ്യുന്നതിനായി ഞങ്ങൾ രണ്ട് സമീപനങ്ങൾ പരിഗണിച്ചു:

പെർസിസ്റ്റന്റ് ഫയൽസിസ്റ്റം + എക്സ്പ്ലിസിറ്റ് serde: ടേണുകളിലുടനീളം ഉപയോഗിക്കുന്നതിന് മോഡലുകൾക്കായി സാൻഡ്‌ബോക്സുകൾക്ക് പെർസിസ്റ്റന്റ് ഫയൽസിസ്റ്റങ്ങൾ തുറന്നുകാട്ടാൻ കഴിയും. ഇടക്കാല അവസ്ഥ നിലനിർത്താൻ ആഗ്രഹിക്കുന്ന മോഡലുകൾക്ക് ഒരു ടേണിനായി ജനറേറ്റഡ് കോഡിനുള്ളിൽ ഒരു സീരിയലൈസേഷൻ ഘട്ടവും, തുടർന്ന് വരുന്ന ഒരു ടേണിനുള്ളിൽ ഒരു ഡെസീരിയലൈസേഷൻ ഘട്ടവും ഉൾപ്പെടുത്താം (മോഡലുകളുടെ സ്വന്തം പരിശോധനയ്ക്കോ ഡൗൺസ്ട്രീം ഉപയോഗത്തിനോ വേണ്ടി). ടേണുകളിലുടനീളം ഇടക്കാല അവസ്ഥ എങ്ങനെ കൈമാറുന്നു എന്ന് നേരിട്ടും വ്യക്തമായും നിയന്ത്രിക്കാൻ ഫയൽസിസ്റ്റം സമീപനം മോഡലുകളെ അനുവദിക്കുന്നു. മോഡൽ ഉപയോഗിക്കുന്ന വിവരങ്ങളുടെ വ്യക്തമായ തിരിച്ചറിയലും സ്ഥിരതയും നടപ്പിലാക്കുന്നതിലൂടെ ഇത് കണ്ടെത്താനാകുന്നതും ഉറപ്പാക്കുന്നു. serde കോഡ് ജനറേറ്റുചെയ്യുന്നതിൽ നിന്ന് ഉണ്ടാകുന്ന ലേറ്റൻസിയും സന്ദർഭ ഓവർഹെഡുമാണ് ഒരു പോരായ്മ, എങ്കിലും നന്നായി രൂപകൽപ്പന ചെയ്‌ത യൂട്ടിലിറ്റി ഫംഗ്ഷനുകൾക്ക് ഈ ഓവർഹെഡ് ലഘൂകരിക്കാനാകും.

REPL: പകരമായി, ഒരു REPL-ശൈലിയിലുള്ള പരിതസ്ഥിതിയിൽ ടേണുകളിലുടനീളം എക്സിക്യൂഷൻ റൺടൈം തന്നെ ഒരു സാൻഡ്‌ബോക്സിന് നിലനിർത്താൻ കഴിയും. മുമ്പത്തെ ടേണുകളിൽ നിർവചിച്ചതോ പരിഷ്‌കരിച്ചതോ ആയ വേരിയബിളുകൾ തുടർന്നുള്ള ടേണുകളിൽ പേരുകൊണ്ട് റഫറൻസുചെയ്യാൻ കഴിയുന്നതിനാൽ, സീരിയലൈസ് ചെയ്യാതെ തന്നെ മെമ്മറിയിൽ ഇടക്കാല അവസ്ഥ നിലനിർത്താൻ ഇത് മോഡലുകളെ അനുവദിക്കുന്നു. serde കോഡ് ജനറേറ്റുചെയ്യേണ്ട ആവശ്യം ഒഴിവാക്കുന്നതിനാൽ REPL സമീപനം കൂടുതൽ ടോക്കൺ-കാര്യക്ഷമമാണ്. എന്നിരുന്നാലും, വ്യക്തമായ സീരിയലൈസേഷൻ ഘട്ടത്തിന്റെ അഭാവം 100-സെൽ ജുപിറ്റർ നോട്ട്ബുക്കിൽ പ്രവർത്തിച്ചിട്ടുള്ള ആർക്കും പരിചിതമായ കാരണങ്ങളാൽ ഡൗൺസ്ട്രീം പ്രകടനത്തെ ബാധിച്ചേക്കാം: വേരിയബിൾ നെയിംസ്‌പേസ് അലങ്കോലപ്പെടുന്നതിനാൽ, ടേണുകളിലുടനീളം കൃത്യമായി എന്താണ് നിലനിൽക്കുന്നതെന്നും എന്തുകൊണ്ടാണെന്നും ട്രാക്ക് സൂക്ഷിക്കുന്നത് കൂടുതൽ ബുദ്ധിമുട്ടായി മാറുന്നു.

ഞങ്ങൾ രണ്ട് സമീപനങ്ങളും പരിശോധിക്കുകയും സാധാരണ ഉപയോഗത്തിൽ അവ സമാനമായി പ്രവർത്തിക്കുമ്പോൾ, ഫയൽസിസ്റ്റം അധിഷ്ഠിത serde പ്രത്യേകിച്ച് ദീർഘമായ പാതകളിൽ മികച്ച വിശ്വാസ്യത നൽകുന്നുവെന്ന് കണ്ടെത്തുകയും ചെയ്തു. അതിനാൽ ഞങ്ങൾ ഫയൽസിസ്റ്റം അധിഷ്ഠിത serde ഞങ്ങളുടെ പരിഹാരമായി സ്വീകരിക്കുന്നു. മോഡലുകൾ അവസ്ഥയെ അവ്യക്തമായിട്ടല്ലാതെ പ്രഖ്യാപനപരമായി കൈമാറാൻ ആവശ്യപ്പെടുന്നത് ആ അവസ്ഥ കൂടുതൽ ഫലപ്രദമായി കൈകാര്യം ചെയ്യാൻ അവരെ സഹായിക്കുമെന്ന് ഞങ്ങൾ ഊഹിക്കുന്നു. ഇതൊരു താൽക്കാലിക കണ്ടെത്തലാണ്, രണ്ട് സമീപനങ്ങളിലും ഞങ്ങൾ ആവർത്തിക്കുന്നത് തുടരും.

ഏജന്റ് ഹാർനസുകൾക്ക് ശക്തി പകരുന്ന മോഡലുകൾ SaC-ന്റെ കൺട്രോൾ പ്ലേനായി പ്രവർത്തിക്കുന്നു: ഓരോ ടാസ്കിന്റെയും ആവശ്യങ്ങൾ നിറവേറ്റുന്നതിനായി Agentic Search SDK-യുടെ ബിൽഡിംഗ് ബ്ലോക്കുകളിൽ നിന്ന് സെർച്ച് പൈപ്പ്‌ലൈനുകൾ ഡൈനാമിക് ആയി കൂട്ടിച്ചേർക്കുകയും, തുടർന്ന് സാൻഡ്‌ബോക്സ് എക്സിക്യൂഷനായി ആ പൈപ്പ്‌ലൈനുകൾ കോഡായി അയക്കുകയും ചെയ്യുന്നു.

Perplexity ഞങ്ങളുടെ ഏജന്റ് ഹാർനസുകൾക്കുള്ളിൽ വിവിധതരം മോഡലുകൾ ഉപയോഗിക്കുന്നു, കൂടാതെ പൊതുവായ ആവശ്യങ്ങൾക്കായുള്ള കോഡ് ജനറേഷനിൽ ഏറ്റവും പുതിയ ഫ്രണ്ടിയർ മോഡലുകൾ എല്ലാത്തിലും വളരെ ഫലപ്രദമാണെന്ന് ഞങ്ങൾ കണ്ടെത്തിയിട്ടുണ്ട്. Agentic Search SDK-ക്കായി പ്രത്യേകം ഫലപ്രദമായ കോഡ് ജനറേഷൻ ഉണ്ടാക്കുക എന്നതാണ് പ്രധാന വെല്ലുവിളി. അതായത്, ടാസ്ക്-ഒപ്റ്റിമൈസ് ചെയ്ത പൈപ്പ്‌ലൈനുകളിലേക്ക് ഞങ്ങളുടെ SDK-യുടെ ബിൽഡിംഗ് ബ്ലോക്കുകൾ മോഡലുകൾക്ക് എങ്ങനെ ഫലപ്രദമായി ഒരുമിച്ച് ചേർക്കാം?

ഒരു ഭാഷയുടെ സ്റ്റാൻഡേർഡ് ലൈബ്രറിയിൽ നിന്ന് വ്യത്യസ്തമായി, കസ്റ്റം-ബിൽറ്റ് SDK പ്രീട്രെയിനിംഗ് ഡാറ്റയിൽ പ്രതിനിധീകരിക്കാൻ സാധ്യതയില്ല. ഓട്ടോസെർച്ചിൽ നിന്നുള്ള SDK ഉപയോഗക്ഷമത മെച്ചപ്പെടുത്തലുകൾക്കൊപ്പം പോലും, പല മോഡലുകളും ഫങ്ഷൻ കോളുകളിലൂടെയും നേരിട്ടുള്ള MCP ഇൻവോക്കേഷനിലൂടെയും സെർച്ച് സിസ്റ്റങ്ങളുമായി സംവദിക്കാൻ ഇപ്പോഴും പരിശീലിപ്പിക്കപ്പെടുന്നു. ഉറവിട കോഡും സ്വയം ജനറേറ്റുചെയ്ത ഡോക്യുമെന്റുകളും മാത്രം ഉപയോഗിച്ച് മോഡലുകൾ വിദഗ്ദ്ധമായി SDK ഉപയോഗിക്കാൻ സാധ്യതയില്ല.

ഈ വെല്ലുവിളി പരിഹരിക്കുന്നതിന്, ഞങ്ങളുടെ SDK ഫലപ്രദമായി പ്രയോജനപ്പെടുത്താൻ മോഡലുകളെ പഠിപ്പിക്കുന്നതിനായി ഞങ്ങൾ ഉയർന്ന തലത്തിലുള്ള Agent Skills വികസിപ്പിച്ചെടുത്തിട്ടുണ്ട്. Perplexity-യുടെ സ്കില്ലുകൾക്കായുള്ള ഡിസൈൻ തത്വങ്ങൾ അനുസരിച്ചാണ് പ്രാരംഭ പതിപ്പുകൾ വികസിപ്പിച്ചത്, തുടർന്ന് SDK ഒപ്റ്റിമൈസേഷനിൽ ഉപയോഗിച്ച അതേ മെട്രിക്സുകളിൽ ശ്രദ്ധ കേന്ദ്രീകരിച്ചുകൊണ്ട് സമർപ്പിതമായ ഒരു ഓട്ടോസെർച്ച് ലൂപ്പിലൂടെ ഒപ്റ്റിമൈസ് ചെയ്യപ്പെട്ടു. സന്ദർഭം വർദ്ധിക്കുന്നത് തടയാൻ ഞങ്ങൾ സ്കിൽ വലുപ്പവും പരിമിതപ്പെടുത്തുന്നു, കൂടാതെ ഞങ്ങളുടെ അന്തിമ പതിപ്പുകളിൽ അവയുടെ റൂട്ട് SKILL.md ഫയലുകളിൽ 2000-ൽ താഴെ ടോക്കണുകൾ ഉണ്ട്.

ഒപ്റ്റിമൈസ് ചെയ്ത സ്കില്ലുകൾ SDK-യുടെ ലഭ്യമായ ബിൽഡിംഗ് ബ്ലോക്കുകൾ ലിസ്റ്റുചെയ്യുന്നതിനേക്കാൾ അപ്പുറത്തേക്ക് പോകുന്നു (റൺടൈം റിഫ്ലക്ഷൻ വഴി എളുപ്പത്തിൽ ലഭിക്കുന്ന ഒന്ന്). ഈ ബ്ലോക്കുകൾ സങ്കീർണ്ണമായ പാറ്റേണുകളിലേക്ക് സംയോജിപ്പിക്കുന്നതിനുള്ള സംക്ഷിപ്തമായ, പൊതുവായി ബാധകമായ മാർഗ്ഗനിർദ്ദേശങ്ങളും ഫ്യൂ-ഷോട്ട് ഉദാഹരണങ്ങളും നൽകുന്നതിനാണ് ടോക്കണുകളുടെ ഭൂരിഭാഗവും ചെലവഴിക്കുന്നത്. ഈ സ്കില്ലുകൾ ഉപയോഗിച്ച്, ആയിരക്കണക്കിന് പ്രത്യേക പ്രവർത്തനങ്ങളിലേക്ക് സ്കെയിൽ ചെയ്യുന്ന സെർച്ച് പൈപ്പ്‌ലൈനുകൾ ഓർക്കസ്ട്രേറ്റ് ചെയ്യാൻ മോഡലുകൾ SDK ഫലപ്രദമായി പ്രയോജനപ്പെടുത്തുന്നത് ഞങ്ങൾ നിരീക്ഷിക്കുന്നു.

ഈ പാളികൾ സംയോജിപ്പിച്ചുകൊണ്ട്, SaC മോഡലുകളും സെർച്ച് സ്റ്റാക്കും തമ്മിലുള്ള ബന്ധം മാറ്റുന്നു. ഫിക്സഡ്-പൈപ്പ്‌ലൈൻ സെർച്ച് സിസ്റ്റങ്ങളിൽ, മോഡൽ തിരച്ചിലിന് മുകളിൽ ഇരിക്കുകയും ഇടുങ്ങിയ സീരിയൽ കോളർ ഇന്റർഫേസ് വഴി അതിലൂടെ സംവദിക്കുകയും ചെയ്യുന്നു. SaC-ൽ, സെർച്ച് പ്രക്രിയ തന്നെ ഓർക്കസ്ട്രേറ്റ് ചെയ്യുന്നതിൽ മോഡൽ സജീവമായ ഒരു പങ്കാളിയായി മാറുന്നു. സെർച്ച് സ്റ്റാക്കിന്റെ എല്ലാ ഘടകങ്ങളും മോഡലിന് നേരിട്ട് പ്രോഗ്രാം ചെയ്യാവുന്നതായി മാറുന്നു, സാൻഡ്‌ബോക്സും Agentic Search SDK-യും ആ ഘടകങ്ങളിലേക്ക് ആവശ്യമായ ഇന്റർഫേസുകൾ നൽകുന്നു.

എന്നാൽ നേറ്റീവ് ആയി നിലവിലില്ലാത്ത കഴിവുകളെക്കുറിച്ച് എന്ത് പറയാം? മുൻകൂട്ടി നിലവിലുള്ള കഴിവുകൾ ഓർക്കസ്ട്രേറ്റ് ചെയ്യുന്നതിനുള്ള ശക്തമായ ഒരു മാധ്യമമാണ് കോഡ്. എന്നിരുന്നാലും കോഡിന്റെ ശക്തി ഓർക്കസ്ട്രേഷനപ്പുറത്തേക്ക് പോകുന്നു. സെർച്ച് സ്റ്റാക്കിലോ SDK-യിലോ ഇല്ലാത്ത കഴിവുകൾക്കായി ഇതിന് ഒരു ഗ്യാപ് ഫില്ലറായും പ്രവർത്തിക്കാൻ കഴിയും. ഏജന്റുകൾക്ക് മിതത്വം (parsimony) പ്രയോജനകരമാണ്, കൂടാതെ സമർപ്പിതമായ ഒരു ഫംഗ്ഷൻ ഉപയോഗിച്ച് സാധ്യതയുള്ള എല്ലാ പ്രവർത്തനങ്ങളും SDK ഉൾക്കൊള്ളുന്നത് കാര്യക്ഷമമല്ല. പകരം, SDK ഏറ്റവും അടിസ്ഥാനപരമായ പ്രിമിറ്റീവുകൾ നൽകുന്നു, കൂടാതെ മോഡലിന് കോഡ് ഉപയോഗിച്ച് ഓൺ-ദി-ഫ്ലൈ ആയി ഏതെങ്കിലും അധിക ഘടകങ്ങൾ നിർമ്മിക്കാൻ കഴിയും.

സെർച്ച് സിസ്റ്റത്തിന്റെ സ്വന്തം ചോദ്യ സിന്റാക്സ് വഴി കാര്യക്ഷമമായി നടപ്പിലാക്കാൻ കഴിയാത്ത ഒരു സങ്കീർണ്ണമായ റെജെക്സ് (regex) പരിഗണിക്കുക, ഉദാഹരണത്തിന്. കോഡിംഗ് കഴിവുകൾ ഇല്ലെങ്കിൽ, മോഡൽ അതിന്റെ മികച്ച ആ സന്നദ്ധത സൃഷ്ടിക്കാനും, ഒരു ചോദ്യം നടത്താനും, വളരെ ശബ്ദമുള്ള ഒരു റിസൾട്ട്സെറ്റിൽ ടോക്കൺ-സ്പേസ് ഫിൽട്ടറിംഗ് നടത്താനും നിർബന്ധിതനാകും. SaC ഉപയോഗിച്ച്, ആവശ്യമുള്ള റെജെക്സിന്റെ റിസൾട്ട്സെറ്റിന്റെ ഒരു സൂപ്പർസെറ്റ് ശേഖരിക്കുന്നതിന് സമാന്തര SDK കോളുകൾ ചെയ്യുന്ന ഒരു പ്രോഗ്രാം മോഡലിന് പകരം നിർമ്മിക്കാൻ കഴിയും. SDK വഴി ഡ്യൂപ്ലിക്കേഷൻ നീക്കംചെയ്തതിന് ശേഷം, ഫലങ്ങൾ കൃത്യമായ റെജെക്സിലേക്ക് നിർണ്ണായകമായി ചുരുക്കാൻ മോഡലിന് അധിക കോഡ് എഴുതാം. ഈ രീതിയിൽ, അമിതമായി നിച്ച് ആയ സബ്‌റൗട്ടുകൾ ഉപയോഗിച്ച് SDK അലങ്കോലപ്പെടുത്താതെ ഏജന്റുകൾക്ക് കസ്റ്റം സെർച്ച് കഴിവുകൾ നടപ്പിലാക്കാൻ കഴിയും.

ഞങ്ങളുടെ ടെസ്റ്റിംഗ് സ്യൂട്ടിലെ യഥാർത്ഥ ലോകത്തിലെ ഒരു ടാസ്കിനെ അടിസ്ഥാനമാക്കിയുള്ള ഒരു കേസ് സ്റ്റഡി ഞങ്ങൾ അവതരിപ്പിക്കുന്നു. 2023–2025 കാലഘട്ടത്തിൽ നിന്നുള്ള ഉയർന്ന തീവ്രതയുള്ള 200-ലധികം CVE-കൾ തിരിച്ചറിയാനും സവിശേഷതകൾ വിവരിക്കാനും ഈ ടാസ്ക് ഒരു ഏജന്റിനോട് ആവശ്യപ്പെടുന്നു. ഓരോ റെക്കോർഡും ബാധിക്കപ്പെട്ട വെണ്ടറുടെ സ്വന്തം ഉപദേശം ഉദ്ധരിക്കുകയും, ഉൽപ്പന്നത്തിന്റെയും ഫിക്സ് പതിപ്പിന്റെയും പേര് നൽകുകയും, ഫിക്സ് പതിപ്പ് നിർദ്ദിഷ്ട CVE-യുമായി ബന്ധപ്പെട്ടിരിക്കുന്നുവെന്ന് കാണിക്കുകയും വേണം.

SaC-ന്റെ ഉത്തരം കൃത്യതയിൽ 100% സ്കോർ ചെയ്തു, നോൺ-SaC അടിസ്ഥാനരേഖയുമായി താരതമ്യം ചെയ്യുമ്പോൾ മൊത്തത്തിലുള്ള ടോക്കൺ ഉപയോഗം 85.1% കുറഞ്ഞു (288.7K ടോക്കണുകളിൽ നിന്ന് 42.9K ടോക്കണുകളായി). സെക്ഷൻ 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,
)

രണ്ടാമത്തെ ബ്ലോക്ക് ഒരു ഇടനില പ്ലാനിംഗ് സബ്‌റൂട്ടീനായി ഒരു LLM ഉപയോഗിക്കുന്നു. കോഡ് ഏത് വെൻഡർ-വർഷ ജോഡികളാണ് മതിയായ സ്ഥാനാർഥി പേജുകൾ സൃഷ്ടിക്കുന്നത് എന്നത് സംഗ്രഹിക്കുന്നു, ലക്ഷ്യമിട്ട മെച്ചപ്പെടുത്തലുകൾ ആവശ്യപ്പെടുന്നു, കൂടാതെ നിർവഹണത്തിന് മുമ്പ് ഓരോ നിർദ്ദേശിച്ച ക്വറിയും സാധൂകരിക്കുന്നു. ഇതിലൂടെ trajectory-യിലെ പ്രയോജനകരമായ മാതൃകകൾ, ഉദാഹരണത്തിന് സൈറ്റ്-സ്കോപ്പ് ചെയ്ത കൃത്യ-വാചക പ്രോബുകളും അനുയോജ്യമായ ബാക്ക്ഫില്ലിംഗും, SDK-യിൽ ഒരു പ്രത്യേക CVE-അഡ്വൈസറി ക്രോളറെ ഹാർഡ്‌കോഡ് ചെയ്യാതെ തന്നെ സംരക്ഷിക്കപ്പെടുന്നു.

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")

അവസാന ബ്ലോക്ക് ഒരു ഫലം പരിശോധിക്കുന്നയാളാണ് (result verifier), അതിന്റെ ലോജിക് കോഡെജൻ വഴി ഏജന്റ് പൂർണ്ണമായും നിർവചിക്കുന്നു. സെർച്ച് സബ്‌റൗട്ടുകൾക്ക് വിശ്വസനീയമായ ഉപദേശക പേജുകൾ കണ്ടെത്താൻ കഴിയുമെങ്കിലും, ടാസ്കിന് കർശനമായ ഒരു ബന്ധം ആവശ്യമാണ്: ഉപദേശം വെണ്ടർ എഴുതിയ ടെക്സ്റ്റിൽ ഒരു CVE-യെ ഒരു ബാധിക്കപ്പെട്ട ഉൽപ്പന്നത്തിലേക്കും ഒരു ഫിക്സ് പതിപ്പിലേക്കും ബന്ധിപ്പിക്കണം. സ്കീമ ആ ബന്ധം വ്യക്തമാക്കുന്നു, അതിനാൽ ഡൗൺസ്ട്രീം കോഡിന് CVE പ്രകാരം ഡ്യൂപ്ലിക്കേഷൻ നീക്കംചെയ്യാനും, അഗ്രഗേറ്റർ URL-കൾ നിരസിക്കാനും, ദുർബലമായ പതിപ്പ് തെളിവുകൾ ഒഴിവാക്കാനും, റെക്കോർഡ്-എണ്ണ അടിത്തറ നിറവേറ്റുന്നത് വരെ ബാക്ക്ഫില്ലിംഗ് തുടരാനും കഴിയും.

കേവല പ്രകടനത്തിലും ചെലവ്-പ്രകടന അതിർത്തിയിലും ശ്രദ്ധ കേന്ദ്രീകരിച്ചുകൊണ്ട് സമഗ്രമായ ഒരു ബെഞ്ച്മാർക്ക് സ്യൂട്ടിൽ SaC-യുടെ ഫലപ്രാപ്തി ഞങ്ങൾ വിലയിരുത്തുന്നു.

ഞങ്ങളുടെ ബെഞ്ച്മാർക്ക് സ്യൂട്ടിൽ മൊത്തത്തിൽ അഞ്ച് ബെഞ്ച്മാർക്കുകൾ ഉൾപ്പെടുന്നു, വൈവിധ്യമാർന്ന ഡൊമെയ്‌നുകൾ, ടാസ്ക് ഫോർമാറ്റുകൾ, സങ്കീർണ്ണതാ ലെവലുകൾ എന്നിവയിലുടനീളം സെർച്ച്-ഡിപെൻഡന്റ് AI വർക്ക്ഫ്ലോകളെ സ്ട്രെസ് ടെസ്റ്റ് ചെയ്യാൻ രൂപകൽപ്പന ചെയ്തിട്ടുള്ളതാണ് അവ. ഞങ്ങൾ നിലവിലുള്ള നാല് ബെഞ്ച്മാർക്കുകൾ ഉപയോഗിക്കുന്നു: DeepSearchQA (DSQA), BrowseComp, Humanity's Last Exam (HLE), WideSearch. ആദ്യത്തെ മൂന്ന് ബെഞ്ച്മാർക്കുകൾക്കായി (DSQA, BrowseComp, HLE), ഞങ്ങൾ ടോപ്‌ലൈൻ മെട്രിക്കായി കൃത്യത റിപ്പോർട്ട് ചെയ്യുന്നു. WideSearch-നായി, ഞങ്ങൾ വരികളിലൂടെ F1 സ്കോർ റിപ്പോർട്ട് ചെയ്യുന്നു.

തിരച്ചിൽ, കമ്പ്യൂട്ട്, മോഡൽ ന്യായവാദം എന്നിവയുടെ ശ്രദ്ധാപൂർവ്വമായ ഓർക്കസ്ട്രേഷൻ ആവശ്യമുള്ള ബുദ്ധിമുട്ടുള്ള “വൈഡ് റിസർച്ച്” ടാസ്കുകളിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്ന പുതുതായി വികസിപ്പിച്ച WANDR ബെഞ്ച്മാർക്കും ഞങ്ങൾ ഉപയോഗിക്കുന്നു. Perplexity Computer ഉപയോക്താക്കൾക്കായി കൈകാര്യം ചെയ്യുന്ന അറിവ് തീവ്രമായ പ്രൊഫഷണൽ ടാസ്കുകളിൽ നിന്നാണ് WANDR പ്രചോദനം ഉൾക്കൊള്ളുന്നത്. ഇത് WideSearch-ലും സമാനമായ ബെഞ്ച്മാർക്കുകളിലും ആവർത്തിക്കുന്നു, എന്നാൽ കൂടുതൽ സങ്കീർണ്ണമായ ടാസ്കുകൾക്കും ടാസ്ക് ഘടനകൾക്കും ഊന്നൽ നൽകുന്നു. വരുന്ന ആഴ്ചകളിൽ ഞങ്ങൾ WANDR ബെഞ്ച്മാർക്ക് പ്രസിദ്ധീകരിക്കും.

ഞങ്ങൾ അഞ്ച് ഏജന്റ്-ആധാരിത സംവിധാനങ്ങളെ വിലയിരുത്തുന്നു. സമാന്തരീകരണത്തിന്റെ നേട്ടങ്ങളല്ല, അടിസ്ഥാന ശിൽപത്തിന്റെ പ്രകടനമാണ് വേർതിരിച്ച് മനസ്സിലാക്കേണ്ടതെന്നതിനാൽ, “best-of-N” സ്കോറുകൾക്കുപകരം വ്യക്തിഗത റൺസുകളെയാണ് ഞങ്ങൾ പരിഗണിക്കുന്നത്. ഓരോ സംവിധാനത്തിന്റെയും കോൺഫിഗറേഷൻ താഴെ വിവരിച്ചിരിക്കുന്നു:

Perplexity (SaC): Perplexity-യുടെ പ്രൊഡക്ഷൻ Agent API-ക്കുള്ളിൽ ഞങ്ങൾ SaC ആർക്കിടെക്ചർ വിലയിരുത്തുന്നു. GPT 5.5 (ഉയർന്ന ന്യായവാദം) അടിസ്ഥാന മോഡലായി സേവനം നൽകുന്നു.

OpenAI: സെർച്ച് (web_search), പൈത്തൺ റൺടൈം (code_interpreter) എന്നിവ പ്രവർത്തനക്ഷമമാക്കി ഞങ്ങൾ OpenAI Responses API വിലയിരുത്തുന്നു. GPT 5.5 (ഉയർന്ന ന്യായവാദം) അടിസ്ഥാന മോഡലായി സേവനം നൽകുന്നു.

Anthropic: 20260401 ഏജന്റ് ടൂൾസെറ്റും ഓട്ടോ-അലോയ്ഡ് കമാൻഡുകളും ഉപയോഗിച്ച് ഞങ്ങൾ Anthropic Managed Agents വിലയിരുത്തുന്നു. Opus 4.7 (ഉയർന്ന ന്യായവാദം) അടിസ്ഥാന മോഡലായി സേവനം നൽകുന്നു.

Exa: പ്രൊഡക്ഷൻ API വഴി ഞങ്ങൾ Exa Agent വിലയിരുത്തുന്നു, എഫർട്ട് ഉയർന്നതായി സജ്ജീകരിച്ചിരിക്കുന്നു.

Parallel: പ്രൊഡക്ഷൻ API വഴി ഞങ്ങൾ Parallel Tasks വിലയിരുത്തുന്നു, പ്രൊസസ്സർ ultra4x ആയി സജ്ജീകരിച്ചിരിക്കുന്നു.

പട്ടിക 1 ഓരോ സംവിധാനത്തിന്റെയും ബെഞ്ച്മാർക്ക് സ്കോറുകൾ റിപ്പോർട്ട് ചെയ്യുന്നു. അഞ്ച് ബെഞ്ച്മാർക്കുകളിൽ നാലിലും SaC മറ്റു എല്ലാ സംവിധാനങ്ങളെയും മറികടക്കുന്നു. ശേഷിക്കുന്ന ബെഞ്ച്മാർക്കിൽ (HLE), SaC OpenAI Responses-നൊപ്പം ആദ്യ സ്ഥാനത്തിന് കാര്യക്ഷമമായി സമനിലയിലാണ്. പരിചയപ്പെരുന്നിലെയുള്ള ഫിഗർ 2 ഈ സ്കോറുകൾ ഗ്രാഫിക്കൽ രൂപത്തിൽ ദൃശ്യമാക്കുന്നു.

ബെഞ്ച്മാർക്ക്	Perplexity (SaC)	OpenAI	Anthropic	Exa	Parallel
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 അത്യാധുനിക പ്രകടനം കൈവരിക്കുന്നുണ്ടെങ്കിലും, WANDR-ൽ അതിന്റെ നേട്ടം പ്രത്യേകിച്ചും പ്രകടമാണ്. WANDR സ്കോറുകൾ ചിത്രം 5 തരംതിരിക്കുന്നു, Perplexity-യുടെ SaC നടപ്പിലാക്കൽ അടുത്ത മികച്ച സിസ്റ്റത്തെ 2.5 മടങ്ങ് വ്യത്യാസത്തിൽ മറികടക്കുന്നു എന്ന് കാണിക്കുന്നു. ഈ വലിയ വ്യത്യാസമുണ്ടെങ്കിലും, WANDR പൂരിതമാകാതെ തുടരുന്നു കൂടാതെ SaC-ക്ക് പോലും വെല്ലുവിളിയാണെന്ന് തെളിയിക്കുന്നു. സ്ഥിരമായി ഉയർന്ന പ്രകടനം കൈവരിക്കുന്നതിന് ഗവേഷണത്തിലും സെർച്ച് എഞ്ചിനീയറിംഗിലും അധിക പുരോഗതി ആവശ്യമായി വരുന്ന WANDR-ന്റെ ടാസ്കുകൾക്ക് ആവശ്യമായ സങ്കീർണ്ണവും ഉയർന്ന തിരശ്ചീനവുമായ സെർച്ച് വർക്ക്ഫ്ലോകൾ ഞങ്ങൾ വിശ്വസിക്കുന്നു.

വിലയിരുത്തിയ സിസ്റ്റങ്ങളിലുടനീളമുള്ള WANDR സ്കോറുകൾ. Perplexity Agent API അടുത്ത മികച്ച സിസ്റ്റത്തെ 2.5× ഘടകത്തിൽ നയിക്കുന്നു.

അവസാനമായി, അതേ Perplexity സെർച്ച് ഇൻഫ്രാസ്ട്രക്ചർ പ്രയോജനപ്പെടുത്തുന്ന പരമ്പരാഗത സെർച്ച് പൈപ്പ്‌ലൈനുമായി താര୍സത്യപ്പെടുത്തുമ്പോൾ SaC-യുടെ ആപേക്ഷിക നേട്ടങ്ങൾ ഞങ്ങൾ അളക്കുന്നു. ഓരോ ബെഞ്ച്മാർക്കിലുടനീളം SaC, നോൺ-SaC ആർക്കിടെക്ചറുകൾ തമ്മിലുള്ള സ്കോറുകളിലെ വ്യത്യാസം ചിത്രം 6 റിപ്പോർട്ട് ചെയ്യുന്നു. ഉടനീളം, 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 പ്രതിഫലിപ്പിക്കുന്നു. പതിറ്റാടുകളായി, സിപിയുകളിലെ പരമ്പരാഗത റൺടൈമുകൾ എക്സിക്യൂട്ട് ചെയ്യുന്ന ഡിറ്റർമിനിസ്റ്റിക് നിർദ്ദേശങ്ങൾക്ക് ചുറ്റും സോഫ്റ്റ്‌വെയർ സിസ്റ്റങ്ങൾ സംഘടിപ്പിക്കപ്പെട്ടു. ഫ്രണ്ടിയർ മോഡലുകൾ കമ്പ്യൂട്ടിന്റെ ഒരു പുതിയ രൂപം അവതരിപ്പിക്കുന്നു: നിർദ്ദേശങ്ങൾ പാലിക്കാനും ജനറേറ്റുചെയ്യാനും കഴിയുന്ന ടോക്കൺ-സ്പേസ് ന്യായവാദം. ഏറ്റവും ശക്തമായ കമ്പ്യൂട്ടേഷണൽ സിസ്റ്റങ്ങൾ അവയ്ക്കിടയിൽ തിരഞ്ഞെടുക്കുന്നതിന് പകരം കമ്പ്യൂട്ടിന്റെ ഈ രണ്ട് രൂപങ്ങളും സംയോജിപ്പിക്കും.

ഈ ഹൈബ്രിഡ് ആർക്കിടെക്ചറിനുള്ള സ്വാഭാവികമായ ഒരു പരീക്ഷണ വേദിയാണ് തിരച്ചിൽ. എന്ത് തെളിവാണ് ആവശ്യമെന്നും അനിശ്ചിതത്വം എങ്ങനെ പരിഹരിക്കണമെന്നും തീരുമാനിക്കുന്നതിൽ മോഡലുകൾ അനുയോജ്യമാണ്. ബാച്ചിങ്, പാരലലിസം, ഫിൽട്ടറിംഗ്, റാങ്കിംഗ്, അഗ്രഗേഷൻ എന്നിവയ്ക്ക് ഡിറ്റർമിനിസ്റ്റിക് റൺടൈമുകൾ അനുയോജ്യമാണ്. സെർച്ച് ഇൻഫ്രാസ്ട്രക്ചർ ഒരു യൂണിവേഴ്സൽ I/O പാളിയായി പ്രവർത്തിക്കുന്നു, മിനിറ്റിൽ ആയിരക്കണക്കിന് പ്രവർത്തനങ്ങളെ നിലനിർത്താൻ കഴിയുന്ന ലോകത്തിലെ വിവരങ്ങളിലേക്ക് റൺടൈമിന് ഉപയോഗപ്രദമായ ഹാൻഡിലുകൾ നൽകുന്നു. ഈ ഭാഗങ്ങൾ സംയോജിപ്പിക്കുമ്പോൾ, ഫലമായുണ്ടാകുന്ന സിസ്റ്റം യഥാർത്ഥ ലോകത്തിലെ ടാസ്കുകൾ പൂർത്തിയാക്കുന്നതിൽ വളരെ ശക്തവും കാര്യക്ഷമവുമാണ്.

ഈ കഴിവുകൾ അൺലോക്ക് ചെയ്യുന്നതിന് ഈ ആർക്കിടെക്ചറിന്റെ ഓരോ ഭാഗവും ആവശ്യമാണ്. ബുദ്ധിമാനായ മോഡലുകൾ ഇല്ലെങ്കിൽ, സിസ്റ്റത്തിന് സെർച്ച് തന്ത്രത്തെക്കുറിച്ച് ന്യായവാദം ചെയ്യാൻ കഴിയില്ല. സാൻഡ്‌ബോക്സുകൾ ഇല്ലാതെ, മോഡലുകൾ സീരിയൽ I/O-യിലേക്കും കാര്യക്ഷമമല്ലാത്ത ടോക്കൺ-സ്പേസ് പ്രോസസ്സിംഗിലേക്കും നിർബന്ധിതരാകുന്നു. ആറ്റോമൈസ്ഡ് സെർച്ച് സ്റ്റാക്ക് ഇല്ലെങ്കിൽ, മോഡലിന് ഓർക്കസ്ട്രേറ്റ് ചെയ്യാൻ ഒന്നുമില്ല. SaC പ്രവർത്തിക്കുന്നത് ന്യായവാദം, ഡിറ്റർമിനിസ്റ്റിക് കമ്പ്യൂട്ട്, I/O എന്നിവ ഓരോ പാളിയുടെയും ശക്തികളെ പ്രകടമാക്കുന്നതിന് സംയുക്തമായി രൂപകൽപ്പന ചെയ്തിട്ടുള്ളതുകൊണ്ടാണ്.

തുടർച്ചയായ മെച്ചപ്പെടുത്തൽ ലൂപ്പുകളുടെ വികസനത്തിലൂടെ ഈ സഹരൂപകൽപ്പനയെ ഇനിയും മുന്നോട്ട് കൊണ്ടുപോകാൻ കഴിയും. ഉദാഹരണത്തിന്, Agentic Search SDK-യും SaC Agent Skills-ഉം ഒരു പൊതുവായ ഓട്ടോറിയിസർച്ച് ലൂപ്പിൽ സംയുക്തമായി ഓപ്റ്റിമൈസ് ചെയ്യാം. കൂടുതൽ ആകാംക്ഷയോടെ, 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}
}

ആമുഖം

പരമ്പരാഗത തിരച്ചിലിന്റെ കാഠിന്യം (Rigidity)

കാഠിന്യത്തിൽ നിന്നുള്ള പരാജയ മോഡുകൾ (Failure Modes from Rigidity)

പ്രോഗ്രാം ചെയ്യാവുന്ന ഒരു സെർച്ച് ആർക്കിടെക്ചർ രൂപകൽപ്പന ചെയ്യുന്നു

Agentic Search SDK

സാൻഡ്‌ബോക്സുകൾ (Sandboxes)

മോഡലുകൾ (Models)

ഓർക്കസ്ട്രേറ്ററും ഗ്യാപ് ഫില്ലറുമായി കോഡ് (Code as Orchestrator and Gap Filler)

കേസ് സ്റ്റഡി: CVE വെണ്ടർ ഉപദേശങ്ങൾ (CVE Vendor Advisories)

मूल्यांकन परिणाम (Evaluation Results)

ബെഞ്ച്മാർക്കുകളും സിസ്റ്റങ്ങളും (Benchmarks and Systems)

താരതമ്യ പ്രകടനം (Comparative Performance)

ചെലവ്-പ്രകടന അതിർത്തി (Cost-Performance Frontier)

കമ്പ്യൂട്ടിന്റെ ഒരു പുതിയ ആർക്കിടെക്ചറിലേക്ക് (Toward a New Architecture of Computing)

ഉദ്ധരണി