മോഡലിൽ നിന്ന് ഏജന്റിലേക്ക്: കമ്പ്യൂട്ടർ പരിതസ്ഥിതിയോടെ Responses API-യെ സജ്ജമാക്കുന്നു
ബോ സു, ഡാനി ഷാങ്, റോഹിത് അരുണാചലം
ഞങ്ങൾ നിലവിൽ പ്രത്യേക ടാസ്കുകളിൽ മികവ് പുലർത്തുന്ന മോഡലുകൾ ഉപയോഗിക്കുന്നതിൽ നിന്ന് സങ്കീർണ്ണമായ വർക്ക്ഫ്ലോകൾ കൈകാര്യം ചെയ്യാൻ കഴിവുള്ള ഏജൻ്റുകൾ ഉപയോഗിക്കുന്നതിലേക്കുള്ള ഒരു മാറ്റത്തിലൂടെയാണ് കടന്നുപോകുന്നത്. മോഡലുകൾക്ക് പ്രോംപ്റ്റ് നൽകുന്നതിലൂടെ, നിങ്ങൾക്ക് പരിശീലിപ്പിച്ച ബുദ്ധിയിലേക്ക് മാത്രമേ ആക്സസ് ചെയ്യാൻ കഴിയൂ. എന്നിരുന്നാലും, മോഡലിന് ഒരു കമ്പ്യൂട്ടർ എൻവയോൺമെന്റ് നൽകുന്നത് സേവനങ്ങൾ പ്രവർത്തിപ്പിക്കൽ, API-കളിൽ നിന്ന് ഡാറ്റ അഭ്യർത്ഥിക്കൽ, അല്ലെങ്കിൽ സ്പ്രെഡ്ഷീറ്റുകൾ അല്ലെങ്കിൽ റിപ്പോർട്ടുകൾ പോലുള്ള കൂടുതൽ ഉപകാരപ്രദമായ ആർട്ടിഫാക്റ്റുകൾ സൃഷ്ടിക്കൽ എന്നിവ പോലുള്ള വളരെ വിപുലമായ ഉപയോഗ കേസുകൾ സാധ്യമാക്കും.
ഏജന്റുകൾ നിർമ്മിക്കാൻ ശ്രമിക്കുമ്പോൾ ചില പ്രായോഗിക പ്രശ്നങ്ങൾ ഉയർന്നുവരുന്നു: ഇടക്കാല ഫയലുകൾ എവിടെ വെക്കണം, വലിയ പട്ടികകൾ ഒരു പ്രോംപ്റ്റിലേക്ക് പേസ്റ്റ് ചെയ്യുന്നത് എങ്ങനെ ഒഴിവാക്കാം, സുരക്ഷാ തലവേദന സൃഷ്ടിക്കാതെ വർക്ക്ഫ്ലോയ്ക്ക് നെറ്റ്വർക്ക് ആക്സസ് എങ്ങനെ നൽകാം, കൂടാതെ ഒരു വർക്ക്ഫ്ലോ സിസ്റ്റം തന്നെ നിർമ്മിക്കാതെ ടൈംഔട്ടുകളും റിട്രൈകളും എങ്ങനെ കൈകാര്യം ചെയ്യാം.
ഡെവലപ്പർമാർക്ക് അവരുടെ സ്വന്തം എക്സിക്യൂഷൻ പരിതസ്ഥിതികൾ നിർമ്മിക്കേണ്ട ബാധ്യത ഏൽപ്പിക്കുന്നതിന് പകരം, യഥാർത്ഥ ലോക ടാസ്കുകൾ വിശ്വസനീയമായി നിർവഹിക്കാൻ കമ്പ്യൂട്ടർ പരിതസ്ഥിതിയോടെ Responses API(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) -യെ സജ്ജമാക്കുന്നതിനാവശ്യമായ ഘടകങ്ങൾ ഞങ്ങൾ നിർമ്മിച്ചു.
OpenAIയുടെ Responses API, ഷെൽ ടൂളിനോടും ഹോസ്റ്റുചെയ്ത കണ്ടെയ്നർ വർക്ക്സ്പേസ്-നോടും കൂടി, ഈ പ്രായോഗിക പ്രശ്നങ്ങളെ പരിഹരിക്കാൻ രൂപകൽപ്പന ചെയ്തതാണ്. മോഡൽ ഘട്ടങ്ങളും കമാൻഡുകളും നിർദ്ദേശിക്കുന്നു; പ്ലാറ്റ്ഫോം അവയെ ഇൻപുട്ടുകൾക്കും ഔട്ട്പുട്ടുകൾക്കും വേണ്ടി ഒരു ഫയൽസിസ്റ്റം, ഐച്ഛിക സ്ട്രക്ചേർഡ് സ്റ്റോറേജ് (SQLite പോലുള്ളത്), കൂടാതെ നിയന്ത്രിത നെറ്റ്വർക്ക് ആക്സസ് എന്നിവയുള്ള ഒരു ഒറ്റപ്പെട്ട പരിതസ്ഥിതിയിൽ പ്രവർത്തിപ്പിക്കുന്നു.
ഈ പോസ്റ്റിൽ, ഏജന്റുകൾക്കായി ഒരു കമ്പ്യൂട്ടർ പരിതസ്ഥിതി എങ്ങനെ നിർമ്മിക്കാമെന്ന് വിശദീകരിക്കുകയും, അതിനെ ഉപയോഗിച്ച് വേഗതയുള്ളതും ആവർത്തിക്കാവുന്നതുമായ സുരക്ഷിത പ്രൊഡക്ഷൻ പ്രവാഹങ്ങൾ എങ്ങനെ സാധ്യമാക്കാമെന്ന് കുറച്ച് പ്രാരംഭ പാഠങ്ങൾ പങ്കുവെക്കുകയും ചെയ്യും.
ഒരു നല്ല ഏജന്റ് പ്രവാഹം കർശനമായ നിർവഹണ ലൂപ്പോടെ ആരംഭിക്കുന്നു: മോഡൽ ഫയലുകൾ വായിക്കുക അല്ലെങ്കിൽ API ഉപയോഗിച്ച് ഡാറ്റ ഫെച്ച് ചെയ്യുക പോലുള്ള ഒരു നടപടി നിർദ്ദേശിക്കുന്നു, പ്ലാറ്റ്ഫോം അത് പ്രവർത്തിപ്പിക്കുന്നു, ഫലം അടുത്ത ഘട്ടത്തിലേക്ക് നൽകുന്നു. നാം ഷെൽ ടൂളിൽ നിന്ന് തുടങ്ങും—ഈ ലൂപ്പ് പ്രവർത്തനത്തിൽ കാണാനുള്ള ഏറ്റവും ലളിതമായ മാർഗം—അതിനുശേഷം കണ്ടെയ്നർ വർക്ക്സ്പേസ്, നെറ്റ്വർക്കിംഗ്, പുനരുപയോഗിക്കാവുന്ന സ്കിൽസ്, കോൺടെക്സ്റ്റ് കമ്പാക്ഷൻ എന്നിവ ഉൾക്കൊള്ളും.
ഷെൽ ടൂൾ മനസ്സിലാക്കാൻ, ആദ്യം ഒരു ഭാഷാ മോഡൽ പൊതുവെ ടൂളുകൾ എങ്ങനെ ഉപയോഗിക്കുന്നു എന്ന് മനസ്സിലാക്കുന്നത് ഉപകാരപ്രദമാണ്: ഒരു ഫംഗ്ഷൻ വിളിക്കുക അല്ലെങ്കിൽ ഒരു കമ്പ്യൂട്ടറുമായി ഇടപെടുക പോലുള്ള കാര്യങ്ങൾ ചെയ്യാൻ. പരിശീലനത്തിനിടെ, ടൂളുകൾ എങ്ങനെ ഉപയോഗിക്കുന്നു എന്നും അതിന്റെ ഫലമായി ഉണ്ടാകുന്ന പ്രഭാവങ്ങൾ എന്തൊക്കെയാണെന്നും ഘട്ടം ഘട്ടമായി കാണിക്കുന്ന ഉദാഹരണങ്ങൾ ഒരു മോഡലിനെ കാണിക്കുന്നു. മോഡൽ എപ്പോൾ ഒരു ഉപകരണം ഉപയോഗിക്കണം, എങ്ങനെ ഉപയോഗിക്കണം എന്ന് തീരുമാനിക്കാൻ പഠിക്കുന്നതിന് ഇത് സഹായിക്കുന്നു. ഞങ്ങൾ “ഒരു ഉപകരണം ഉപയോഗിക്കുന്നു” എന്ന് പറയുമ്പോൾ, മോഡൽ യഥാർത്ഥത്തിൽ ഒരു ഉപകരണ കോൾ മാത്രമാണ് നിർദ്ദേശിക്കുന്നത് എന്നതാണ് ഞങ്ങൾ ഉദ്ദേശിക്കുന്നത്. അതിന് സ്വയം ആ കോൾ നിർവഹിക്കാൻ കഴിയില്ല.
ഷെൽ ഉപകരണം മോഡലിനെ ഗണ്യമായി കൂടുതൽ ശക്തമാക്കുന്നു: കമാൻഡ് ലൈനിലൂടെ ഒരു കമ്പ്യൂട്ടറുമായി ആശയവിനിമയം നടത്തി, ടെക്സ്റ്റ് തിരയുന്നതിൽ നിന്ന് നിങ്ങളുടെ കമ്പ്യൂട്ടറിൽ API അഭ്യർത്ഥനകൾ അയയ്ക്കുന്നതുവരെ, വിപുലമായ ജോലികൾ നിർവഹിക്കുന്നു. പരിചിതമായ Unix ടൂളിംഗിനെ അടിസ്ഥാനമാക്കി നിർമ്മിച്ചിരിക്കുന്ന ഞങ്ങളുടെ ഷെൽ ടൂൾ, നിങ്ങൾ പ്രതീക്ഷിക്കുന്നതെല്ലാം ചെയ്യാൻ കഴിയും; grep, curl, awk പോലുള്ള യൂട്ടിലിറ്റികൾ ഔട്ട് ഓഫ് ദ ബോക്സ് തന്നെ ലഭ്യമാണ്.
ഞങ്ങളുടെ നിലവിലുള്ള കോഡ് ഇന്റർപ്രറ്ററുമായി താരതമ്യം ചെയ്യുമ്പോൾ, അത് Python മാത്രം നിർവഹിക്കുന്നതിനാൽ, ഷെൽ ടൂൾ Go അല്ലെങ്കിൽ Java പ്രോഗ്രാമുകൾ പ്രവർത്തിപ്പിക്കൽ അല്ലെങ്കിൽ ഒരു NodeJS സർവർ ആരംഭിക്കൽ പോലുള്ള വളരെ വിപുലമായ ഉപയോഗ കേസുകൾ പ്രാപ്തമാക്കുന്നു. ഈ വഴക്കം മോഡൽ സങ്കീർണ്ണമായ ഏജന്റിക് ടാസ്കുകൾ നിറവേറ്റാൻ അനുവദിക്കുന്നു.
സ്വയം, ഒരു മോഡലിന് ഷെൽ കമാൻഡുകൾ മാത്രമേ നിർദ്ദേശിക്കാൻ കഴിയൂ, പക്ഷേ ഈ കമാൻഡുകൾ എങ്ങനെ എക്സിക്യൂട്ട് ചെയ്യപ്പെടുന്നു? ടാസ്ക് പൂർത്തിയാകുന്നതുവരെ, മോഡൽ ഔട്ട്പുട്ട് ലഭിക്കാൻ, ടൂളുകൾ വിളിക്കാൻ, ടൂൾ പ്രതികരണം ലൂപ്പിൽ തിരികെ മോഡലിലേക്ക് പാസ് ചെയ്യാൻ ഒരു ഓർക്കസ്ട്രേറ്റർ ഞങ്ങൾക്ക് ആവശ്യമാണ്.
Responses API എന്നത് ഡെവലപ്പർമാർ OpenAI മോഡലുകളുമായി ഇടപെടുന്ന രീതിയാണ്. കസ്റ്റം ടൂളുകളുമായി ഉപയോഗിക്കുമ്പോൾ, Responses API നിയന്ത്രണം ക്ലയന്റിന് തിരികെ നൽകുന്നു, കൂടാതെ ടൂളുകൾ പ്രവർത്തിപ്പിക്കാൻ ക്ലയന്റിന് സ്വന്തം ഹാർനെസ് ആവശ്യമാണ്. എന്നിരുന്നാലും, ഈ API ഔട്ട് ഓഫ് ദ ബോക്സ് തന്നെ മോഡലിനും ഹോസ്റ്റുചെയ്ത ടൂളുകൾക്കും ഇടയിൽ ഏകോപിപ്പിക്കാനും കഴിയും.
Responses API ഒരു പ്രോംപ്റ്റ് സ്വീകരിക്കുമ്പോൾ, അത് മോഡൽ കോൺടെക്സ്റ്റ് സമാഹരിക്കുന്നു: ഉപയോക്തൃ പ്രോംപ്റ്റ്, മുൻ സംഭാഷണ നില, കൂടാതെ ടൂൾ നിർദ്ദേശങ്ങൾ. ഷെൽ എക്സിക്യൂഷൻ പ്രവർത്തിക്കാൻ, പ്രോംപ്റ്റ് ഷെൽ ഉപകരണം ഉപയോഗിക്കുന്നതായി പരാമർശിക്കണം കൂടാതെ, തിരഞ്ഞെടുത്ത മോഡൽ ഷെൽ കമാൻഡുകൾ നിർദ്ദേശിക്കാൻ പരിശീലിപ്പിച്ചിരിക്കണം—GPT‑5.2 മുതലുള്ള മോഡലുകൾ ഇതിനായി പരിശീലിപ്പിച്ചിരിക്കുന്നു. ഈ എല്ലാ സന്ദർഭങ്ങളോടും കൂടി, മോഡൽ തുടർന്ന് അടുത്ത നടപടി തീരുമാനിക്കുന്നു. ഇത് ഷെൽ എക്സിക്യൂഷൻ തിരഞ്ഞെടുക്കുകയാണെങ്കിൽ, ഇത് Responses API സേവനത്തിലേക്ക് ഒരു അല്ലെങ്കിൽ കൂടുതൽ ഷെൽ കമാൻഡുകൾ തിരികെ നൽകുന്നു. API സേവനം ആ കമാൻഡുകൾ കണ്ടെയ്നർ റൺടൈമിലേക്ക് ഫോർവേഡ് ചെയ്യുന്നു, ഷെൽ ഔട്ട്പുട്ട് സ്ട്രീം ചെയ്ത് തിരികെ നൽകുന്നു, കൂടാതെ അടുത്ത അഭ്യർത്ഥനയുടെ കോൺടെക്സ്റ്റിൽ അത് മോഡലിന് നൽകുന്നു. മോഡൽ തുടർന്ന് ഫലങ്ങൾ പരിശോധിക്കാനും, ഫോളോ-അപ്പ് കമാൻഡുകൾ നൽകാനും, അല്ലെങ്കിൽ ഒരു അന്തിമ ഉത്തരം നൽകാനും കഴിയും. Responses API, മോഡൽ അധിക ഷെൽ കമാൻഡുകൾ ഇല്ലാതെ ഒരു completion തിരികെ നൽകുന്നതുവരെ ഈ ലൂപ്പ് ആവർത്തിക്കുന്നു.
Responses API ഒരു ഷെൽ കമാൻഡ് എക്സിക്യൂട്ട് ചെയ്യുമ്പോൾ, അത് കണ്ടെയ്നർ സേവനത്തിലേക്ക് ഒരു സ്ട്രീമിംഗ് കണക്ഷൻ നിലനിർത്തുന്നു. ഔട്ട്പുട്ട് സൃഷ്ടിക്കപ്പെടുമ്പോൾ, മോഡൽ കൂടുതൽ ഔട്ട്പുട്ടിനായി കാത്തിരിക്കണമോ, മറ്റൊരു കമാൻഡ് പ്രവർത്തിപ്പിക്കണമോ, അല്ലെങ്കിൽ അന്തിമ പ്രതികരണത്തിലേക്ക് നീങ്ങണമോ എന്ന് തീരുമാനിക്കാൻ കഴിയുന്ന വിധത്തിൽ API അത് തത്സമയം തന്നെ അടുത്ത രീതിയിൽ മോഡലിലേക്ക് റീലേ ചെയ്യുന്നു.
Responses API ഷെൽ കമാൻഡ് ഔട്ട്പുട്ട് സ്ട്രീം ചെയ്യുന്നു
മോഡലിന് ഒരേ ഘട്ടത്തിൽ ഒന്നിലധികം ഷെൽ കമാൻഡുകൾ നിർദ്ദേശിക്കാനും, Responses API-ക്ക് വേർതിരിച്ച കണ്ടെയ്നർ സെഷനുകൾ ഉപയോഗിച്ച് അവ ഒരേസമയം പ്രവർത്തിപ്പിക്കാനും കഴിയും. ഓരോ സെഷനും ഔട്ട്പുട്ട് സ്വതന്ത്രമായി സ്ട്രീം ചെയ്യുന്നു, API ആ സ്ട്രീമുകൾ സ്ട്രക്ചേർഡ് ടൂൾ ഔട്ട്പുട്ടുകളാക്കി മൾട്ടിപ്ലെക്സ് ചെയ്യുന്നു. മറ്റൊരു രീതിയിൽ പറഞ്ഞാൽ, ഫയലുകൾ തിരയുക, ഡാറ്റ ഫെച്ച് ചെയ്യുക, ഇടക്കാല ഫലങ്ങൾ സാധൂകരിക്കുക എന്നിവ ഏജന്റ് ലൂപ്പിന് സമാന്തരമായി നടത്താൻ കഴിയും.
കമാൻഡിൽ ഫയൽ പ്രവർത്തനങ്ങളോ ഡാറ്റ പ്രോസസ്സിംഗോ ഉൾപ്പെടുമ്പോൾ, ഷെൽ ഔട്ട്പുട്ട് വളരെ വലുതാകുകയും പ്രയോജനകരമായ സിഗ്നലുകൾ ചേർക്കാതെ കോൺടെക്സ്റ്റ് ബജറ്റുകൾ ഉപഭോഗിക്കുകയും ചെയ്യാം. ഇത് നിയന്ത്രിക്കാൻ, മോഡൽ ഓരോ കമാൻഡിനും ഒരു ഔട്ട്പുട്ട് പരിധി നിർദ്ദേശിക്കുന്നു. Responses API ആ പരിധി നിർബന്ധിതമാക്കുകയും ഒഴിവാക്കിയ ഉള്ളടക്കം അടയാളപ്പെടുത്തിക്കൊണ്ട്, ഔട്ട്പുട്ടിന്റെ തുടക്കവും അവസാനവും രണ്ടും സംരക്ഷിക്കുന്ന പരിധിബദ്ധമായ ഒരു ഫലം തിരികെ നൽകുകയും ചെയ്യുന്നു. ഉദാഹരണത്തിന്, സംരക്ഷിച്ച തുടക്കവും അവസാനവും സഹിതം ഔട്ട്പുട്ട് 1,000 അക്ഷരങ്ങളിലേക്ക് നിങ്ങൾക്ക് പരിമിതപ്പെടുത്താം:
ആരംഭത്തിലെ ടെക്സ്റ്റ് ... 1000 അക്ഷരങ്ങൾ വെട്ടിച്ചുരുക്കി ... അവസാനം ഉള്ള ടെക്സ്റ്റ്
ഒരുമിച്ച്, സമകാലിക നിർവഹണവും പരിധിയുള്ള ഔട്ട്പുട്ടും ഏജന്റ് ലൂപ്പിനെ വേഗത്തിലും സന്ദർഭ-കാര്യക്ഷമവുമാക്കുന്നു, അതിനാൽ മോഡലിന് അസംസ്കൃത ടെർമിനൽ ലോഗ് ഭാരം ഒഴിവാക്കി പ്രസക്തമായ ഫലങ്ങളെ അടിസ്ഥാനമാക്കി റീസണിംഗ് തുടരാൻ കഴിയും.
ഏജന്റ് ലൂപ്പുകളുമായി ബന്ധപ്പെട്ട ഒരു സാധ്യതയുള്ള പ്രശ്നം ടാസ്കുകൾ ദീർഘകാലം പ്രവർത്തിക്കാനിടയുണ്ട്. ദീർഘകാലമായി പ്രവർത്തിക്കുന്ന ടാസ്കുകൾ സന്ദര്ഭത്തിന്റെ വിൻഡോ നിറയ്ക്കുന്നു, ഇത് ടേണുകളിലുടനീളവും ഏജൻ്റുകളിലുടനീളവും സന്ദർഭം നൽകുന്നതിനായി പ്രധാനമാണ്. ഒരു ഏജന്റ് ഒരു സ്കിൽ വിളിക്കുകയും, ഒരു പ്രതികരണം ലഭിക്കുകയും, ടൂൾ കോളുകളും റീസണിംഗ് സംഗ്രഹങ്ങളും ചേർക്കുകയും ചെയ്യുന്നതായി സങ്കൽപ്പിക്കുക—the പരിമിതമായ കോൺടെക്സ്റ്റ് വിൻഡോ വേഗത്തിൽ നിറഞ്ഞുപോകും. ഏജന്റ് തുടർച്ചയായി പ്രവർത്തിക്കുമ്പോൾ പ്രധാനപ്പെട്ട സന്ദർഭം നഷ്ടപ്പെടാതിരിക്കാൻ, പ്രധാന വിവരങ്ങൾ നിലനിർത്താനും അനാവശ്യമായതെല്ലാം നീക്കം ചെയ്യാനും ഒരു മാർഗം നമുക്ക് ആവശ്യമാണ്. ഡെവലപ്പർമാർക്ക് കസ്റ്റം സംഗ്രഹീകരണ അല്ലെങ്കിൽ സ്റ്റേറ്റ്-ക്യാരിയിംഗ് സിസ്റ്റങ്ങൾ രൂപകൽപ്പന ചെയ്ത് പരിപാലിക്കേണ്ടതായി വരുന്നതിനുപകരം, മോഡൽ എങ്ങനെ പെരുമാറുന്നു എന്നും അത് എങ്ങനെ പരിശീലിപ്പിക്കപ്പെട്ടിരിക്കുന്നു എന്നും അനുസരിച്ച് പൊരുത്തപ്പെടുന്ന തരത്തിൽ രൂപകൽപ്പന ചെയ്ത Responses API-യിൽ ഞങ്ങൾ നേറ്റീവ് കംപാക്ഷൻ ചേർത്തു.
ഞങ്ങളുടെ ഏറ്റവും പുതിയ മോഡലുകൾ മുൻ സംഭാഷണ അവസ്ഥ വിശകലനം ചെയ്യാനും എൻക്രിപ്റ്റ് ചെയ്ത ടോക്കൺ-കാര്യക്ഷമമായ പ്രതിനിധാനത്തിൽ പ്രധാന മുൻ അവസ്ഥ സംരക്ഷിക്കുന്ന ഒരു കോംപാക്ഷൻ ഇനം സൃഷ്ടിക്കാനും പരിശീലിപ്പിച്ചിരിക്കുന്നു. കോംപാക്ഷൻ കഴിഞ്ഞാൽ, അടുത്ത സന്ദർഭം വിൻഡോയിൽ ഈ കോംപാക്ഷൻ ഇനവും മുൻ വിൻഡോയിലെ ഉയർന്ന മൂല്യമുള്ള ഭാഗങ്ങളും ഉൾപ്പെടും. ഇത് വിൻഡോ അതിരുകൾക്കപ്പുറവും വർക്ക്ഫ്ലോകൾ ഏകോപിതമായി തുടരാൻ അനുവദിക്കുന്നു, വിപുലമായ മൾട്ടി-സ്റ്റെപ്പ്, ടൂൾ-നയിത സെഷനുകളിലുപോലും. ദീർഘകാലം നീണ്ടുനിൽക്കുന്ന കോഡിംഗ് ടാസ്കുകളും ആവർത്തനപരമായ ടൂൾ നിർവഹണവും ഗുണനിലവാരം കുറയാതെ നിലനിർത്താൻ Codex ഈ സംവിധാനത്തെ ആശ്രയിക്കുന്നു.
കോംപാക്ഷൻ സെർവറിൽ ബിൽറ്റ്-ഇൻ ആയി അല്ലെങ്കിൽ സ്റ്റാൻഡ്എലോൺ `/compact` എൻഡ്പോയിന്റ് വഴി ലഭ്യമാണ്. സെർവർ-സൈഡ് കോംപാക്ഷൻ നിങ്ങളെ ഒരു ത്രെഷോൾഡ് കോൺഫിഗർ ചെയ്യാൻ അനുവദിക്കുന്നു, കൂടാതെ സിസ്റ്റം കോംപാക്ഷൻ ടൈമിംഗ് യാന്ത്രികമായി കൈകാര്യം ചെയ്യുന്നതിനാൽ, സങ്കീർണ്ണമായ ക്ലയന്റ്-സൈഡ് ലജിക്കിന്റെ ആവശ്യം ഇല്ലാതാക്കുന്നു. കോംപാക്ഷന് നടത്തുന്നതിന് തൊട്ടുമുമ്പ് ചെറിയ അധികങ്ങള് സഹിക്കാന് കഴിയുന്ന വിധത്തില് ഇത് അല്പം വലുതായ ഫലപ്രദമായ ഇൻപുട്ട് സന്ദർഭ വിൻഡോ അനുവദിക്കുന്നു, അതിനാൽ പരിധിക്കടുത്തുള്ള അഭ്യർത്ഥനകൾ നിരസിക്കപ്പെടുന്നതിനുപകരം ഇപ്പോഴും പ്രോസസ്സ് ചെയ്ത് കോംപാക്റ്റ് ചെയ്യാൻ കഴിയും. മോഡൽ പരിശീലനം വികസിക്കുമ്പോൾ, ഓരോ OpenAI മോഡൽ റിലീസിനോടും കൂടി നേറ്റീവ് സംക്ഷിപ്തമാക്കൽ പരിഹാരവും അതിനൊപ്പം വികസിക്കുന്നു.
Codex ഞങ്ങൾക്ക് കോംപാക്ഷൻ സിസ്റ്റം നിർമ്മിക്കാൻ സഹായിച്ചു, അതേസമയം അതിന്റെ ഒരു പ്രാരംഭ ഉപയോക്താവായും പ്രവർത്തിച്ചു. ഒരു Codex ഇൻസ്റ്റൻസിന് കമ്പാക്ഷൻ പിശക് സംഭവിക്കുമ്പോൾ, അന്വേഷിക്കാൻ ഞങ്ങൾ രണ്ടാമത്തെ ഇൻസ്റ്റൻസ് സ്പിൻ അപ്പ് ചെയ്യും. ഫലം ഇതായിരുന്നു: പ്രശ്നത്തിൽ പ്രവർത്തിച്ചതിലൂടെ മാത്രം Codex-ന് ഒരു നേറ്റീവ്, ഫലപ്രദമായ കമ്പാക്ഷൻ സിസ്റ്റം ലഭിച്ചു. Codex-ന് സ്വയം പരിശോധിക്കുകയും മെച്ചപ്പെടുത്തുകയും ചെയ്യാനുള്ള ഈ കഴിവ് OpenAI-യിൽ പ്രവർത്തിക്കുന്നതിലെ പ്രത്യേകിച്ച് ശ്രദ്ധേയമായ ഒരു ഭാഗമായി മാറിയിരിക്കുന്നു. മിക്ക ഉപകരണങ്ങൾക്കും ഉപയോക്താവ് അവ എങ്ങനെ ഉപയോഗിക്കാമെന്ന് പഠിക്കണമെന്നതാണ് ആവശ്യമായത്; Codex നമ്മോടൊപ്പം പഠിക്കുന്നു.
ഇപ്പോൾ, നമുക്ക് സ്റ്റേറ്റും വിഭവങ്ങളും ഉൾക്കൊള്ളാം. കണ്ടെയ്നർ കമാൻഡുകൾ പ്രവർത്തിപ്പിക്കുന്നതിനുള്ള ഒരു സ്ഥലമാത്രമല്ല, മോഡലിനുള്ള പ്രവർത്തന സന്ദർഭവുമാണ്. കണ്ടെയ്നറിനുള്ളിൽ, മോഡലിന് ഫയലുകൾ വായിക്കാനും ഡാറ്റാബേസുകൾ ക്വറി ചെയ്യാനും നെറ്റ്വർക്ക് നയ നിയന്ത്രണങ്ങൾക്ക് കീഴിൽ ബാഹ്യ സിസ്റ്റങ്ങളിലേക്ക് ആക്സസ് ചെയ്യാനും കഴിയും.
കണ്ടെയ്നർ കോൺടെക്സ്റ്റിന്റെ ആദ്യ ഭാഗം വിഭവങ്ങൾ അപ്ലോഡ് ചെയ്യാനും ക്രമീകരിക്കാനും നിയന്ത്രിക്കാനും ഉള്ള ഫയൽ സിസ്റ്റമാണ്. ലഭ്യമായ ഡാറ്റയുടെ ഒരു മാപ്പ് മോഡലിന് നൽകാനും, വ്യാപകവും ശബ്ദമുള്ളതുമായ സ്കാനുകൾ നടത്തുന്നതിനുപകരം ലക്ഷ്യബദ്ധമായ ഫയൽ പ്രവർത്തനങ്ങൾ തിരഞ്ഞെടുക്കാൻ അതിനെ സഹായിക്കാനുമായി ഞങ്ങൾ കണ്ടെയ്നറും ഫയലും(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) APIകൾ നിർമ്മിച്ചു.
ഒരു സാധാരണ ആന്റി-പാറ്റേൺ എന്നത് എല്ലാ ഇൻപുട്ടും നേരിട്ട് പ്രോംപ്റ്റ് സന്ദർഭത്തിലേക്ക് പാക്ക് ചെയ്യുന്നതാണ്. ഇൻപുട്ടുകൾ വളരുമ്പോൾ, പ്രോംപ്റ്റ് അതിരുകടന്ന് നിറയ്ക്കുന്നത് ചെലവേറിയതും മോഡലിന് നാവിഗേറ്റ് ചെയ്യാൻ പ്രയാസകരവുമാകുന്നു. ഒരു മികച്ച പാറ്റേൺ എന്നത് കണ്ടെയ്നർ ഫയൽ സിസ്റ്റത്തിൽ റിസോഴ്സുകൾ സ്റ്റേജ് ചെയ്യുകയും, ഷെൽ കമാൻഡുകൾ ഉപയോഗിച്ച് എന്ത് തുറക്കണം, പാഴ്സ് ചെയ്യണം, അല്ലെങ്കിൽ ട്രാൻസ്ഫോം ചെയ്യണം എന്ന് മോഡൽ തീരുമാനിക്കാൻ അനുവദിക്കുകയും ചെയ്യുന്നതാണ്. മനുഷ്യരെപ്പോലെ, മോഡൽ ക്രമീകരിച്ച വിവരങ്ങളോടെ കൂടുതൽ മികച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നു.
കണ്ടെയ്നർ കോൺടെക്സ്റ്റിന്റെ രണ്ടാം ഭാഗം ഡാറ്റാബേസുകളാണ്. പല സാഹചര്യങ്ങളിലും, ഡെവലപ്പർമാർ ഘടനാപരമായ ഡാറ്റ ഡാറ്റാബേസുകളിൽ SQLite ആയി സംഭരിച്ച് അവ ക്വറി ചെയ്യണമെന്ന് ഞങ്ങൾ നിർദ്ദേശിക്കുന്നു. മുഴുവൻ ഒരു സ്പ്രെഡ്ഷീറ്റ് പ്രോംപ്റ്റിലേക്ക് പകർത്തുന്നതിനുപകരം, ഉദാഹരണത്തിന്, പട്ടികകളുടെ ഒരു വിവരണം—ഏത് കോളങ്ങൾ നിലവിലുണ്ട്, അവ എന്താണ് അർത്ഥമാക്കുന്നത്—മോഡലിന് നൽകാം, തുടർന്ന് അതിന് ആവശ്യമായ വരികൾ അത് എടുത്തുകൊള്ളട്ടെ.
ഉദാഹരണത്തിന്, നിങ്ങൾ “ഈ പാദവര്ഷത്തില് ഏതെല്ലാം ഉൽപ്പന്നങ്ങളുടെ വിൽപ്പന കുറഞ്ഞു?” എന്ന് ചോദിച്ചാൽ, മോഡലിന് മുഴുവൻ സ്പ്രെഡ്ഷീറ്റ് സ്കാൻ ചെയ്യുന്നതിനുപകരം പ്രസക്തമായ നിരകൾ മാത്രം ക്വറി ചെയ്യാൻ കഴിയും. ഇത് വേഗതയേറിയതും, വിലകുറഞ്ഞതും, വലിയ ഡാറ്റാസെറ്റുകളിലേക്ക് കൂടുതൽ വിന്യസിക്കാന് കഴിയുന്നതുമാണ്.
കണ്ടെയ്നർ കോൺടെക്സ്റ്റിന്റെ മൂന്നാം ഭാഗം നെറ്റ്വർക്ക് ആക്സസ് ആണ്, ഏജന്റ് വർക്ക്ലോഡുകളുടെ ഒരു അനിവാര്യ ഭാഗം. ഏജന്റ് വർക്ക്ഫ്ലോയ്ക്ക് ലൈവ് ഡാറ്റ ഫെച്ച് ചെയ്യേണ്ടി വരാം, ബാഹ്യ API-കൾ വിളിക്കേണ്ടി വരാം, അല്ലെങ്കിൽ പാക്കേജുകൾ ഇൻസ്റ്റാൾ ചെയ്യേണ്ടി വരാം. അതേസമയം, കണ്ടെയ്നറുകൾക്ക് നിയന്ത്രണമില്ലാത്ത ഇന്റർനെറ്റ് ആക്സസ് നൽകുന്നത് അപകടകരമായിരിക്കാം: ഇത് വിവരങ്ങളെ ബാഹ്യ വെബ്സൈറ്റുകളിലേക്ക് എത്തിക്കാം, അറിയാതെ സെൻസിറ്റീവ് ആയതോ ആന്തരികമോ അല്ലെങ്കിൽ മൂന്നാം കക്ഷി സിസ്റ്റങ്ങളുമായി ഇടപഴകാം, അല്ലെങ്കിൽ ക്രെഡൻഷ്യൽ ചോർച്ചകളും ഡാറ്റ എക്സ്ഫിൽട്രേഷനും തടയുന്നത് കൂടുതൽ ബുദ്ധിമുട്ടാക്കാം.
ഏജന്റുകളുടെ പ്രയോജന സാധ്യത പരിമിതപ്പെടുത്താതെ ഈ ആശങ്കകൾ പരിഹരിക്കാൻ, സൈഡ്കാർ ഇഗ്രെസ് പ്രോക്സി ഉപയോഗിക്കുന്നതിനായി ഞങ്ങൾ ഹോസ്റ്റഡ് കണ്ടെയ്നറുകൾ നിർമ്മിച്ചു. എല്ലാ ഔട്ട്ബൗണ്ട് നെറ്റ്വർക്ക് അഭ്യർത്ഥനകളും അനുവദിക്കൽ പട്ടികകളും ആക്സസ് നിയന്ത്രണങ്ങളും നടപ്പിലാക്കുകയും ട്രാഫിക് നിരീക്ഷണയോഗ്യമായി നിലനിർത്തുകയും ചെയ്യുന്ന ഒരു കേന്ദ്രീകൃത നയ പാളിയിലൂടെ ഒഴുകുന്നു. ക്രെഡൻഷ്യലുകൾക്കായി, egress-ൽ ഞങ്ങൾ domain-scoped secret injection ഉപയോഗിക്കുന്നു. മോഡലും കണ്ടെയ്നറും പ്ലേസ്ഹോൾഡറുകൾ മാത്രമേ കാണുന്നുള്ളൂ, എന്നാൽ അസംസ്കൃത സീക്രട്ട് മൂല്യങ്ങൾ മോഡലിന് ദൃശ്യമാകുന്ന കോൺടെക്സ്റ്റിന് പുറത്തുതന്നെ തുടരുകയും അംഗീകൃത ലക്ഷ്യസ്ഥാനങ്ങൾക്കായി മാത്രമേ പ്രയോഗിക്കപ്പെടുകയും ചെയ്യുന്നു. ഇത് ലീക്കേജിന്റെ അപകടസാധ്യത കുറയ്ക്കുന്നതിനൊപ്പം, ഓതന്റിക്കേറ്റഡ് ബാഹ്യ കോളുകൾ ഇപ്പോഴും സാധ്യമാക്കുന്നു.
ഷെൽ കമാൻഡുകൾ ശക്തമാണ്, പക്ഷേ പല ടാസ്കുകളും അതേ മൾട്ടി-സ്റ്റെപ്പ് പാറ്റേണുകൾ ആവർത്തിക്കുന്നു. ഏജൻ്റുകൾക്ക് ഓരോ റണ്ണിലും വർക്ക്ഫ്ലോ വീണ്ടും കണ്ടെത്തേണ്ടിവരുന്നു—വീണ്ടും പ്ലാൻ ചെയ്യുക, കമാൻഡുകൾ വീണ്ടും പുറപ്പെടുവിക്കുക, കൺവെൻഷനുകൾ വീണ്ടും പഠിക്കുക—ഇത് അസംഗതമായ ഫലങ്ങളിലേക്കും പാഴായ എക്സിക്യൂഷനിലേക്കും നയിക്കുന്നു. ഏജൻ്റ് കഴിവുകൾ(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ആ പാറ്റേണുകളെ പുനരുപയോഗിക്കാവുന്നതും സംയോജിപ്പിക്കാവുന്നതുമായ നിർമാണഘടകങ്ങളായി പാക്കേജ് ചെയ്യുന്നു. കൃത്യമായി പറഞ്ഞാൽ, ഒരു സ്കിൽ എന്നത് ‘SKILL.md(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു)’ ഉൾപ്പെടുന്ന ഒരു ഫോൾഡർ ബണ്ടിലാണ് (മെറ്റാഡാറ്റയും നിർദ്ദേശങ്ങളും ഉൾക്കൊള്ളുന്ന) കൂടാതെ API സ്പെസിഫിക്കേഷനുകളും UI ആസറ്റുകളും പോലുള്ള ഏതെങ്കിലും പിന്തുണയ്ക്കുന്ന സ്രോതസ്സുകളും.
ഈ ഘടന ഞങ്ങൾ മുമ്പ് വിശദീകരിച്ച റൺടൈം ആർക്കിടെക്ചറുമായി സ്വാഭാവികമായി പൊരുത്തപ്പെടുന്നു. കണ്ടെയ്നർ സ്ഥിരമായ ഫയലുകളും നിർവഹണ കോൺടെക്സ്റ്റും നൽകുന്നു, ഷെൽ ടൂൾ നിർവഹണ ഇന്റർഫേസ് നൽകുന്നു. ഇവ രണ്ടും സജ്ജമായാൽ, മോഡലിന് ആവശ്യമായപ്പോൾ ഷെൽ കമാൻഡുകൾ (`ls`, `cat`, etc.) ഉപയോഗിച്ച് സ്കിൽ ഫയലുകൾ കണ്ടെത്താനും, നിർദ്ദേശങ്ങൾ വ്യാഖ്യാനിക്കാനും, അതേ ഏജന്റ് ലൂപ്പിൽ സ്കിൽ സ്ക്രിപ്റ്റുകൾ പ്രവർത്തിപ്പിക്കാനും കഴിയും.
OpenAI പ്ലാറ്റ്ഫോമിലെ സ്കില്ലുകൾ മാനേജ് ചെയ്യുന്നതിനായി ഞങ്ങൾ APIs(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) നൽകുന്നു. ഡെവലപ്പർമാർ സ്കിൽ ഫോൾഡറുകൾ പതിപ്പുകള് ആക്കിയ ബണ്ടിളുകളായി അപ്ലോഡ് ചെയ്ത് സംഭരിക്കുന്നു, പിന്നീട് അവ സ്കിൽ ID ഉപയോഗിച്ച് വീണ്ടെടുക്കാനാകും. മോഡലിലേക്ക് പ്രോംപ്റ്റ് അയയ്ക്കുന്നതിന് മുമ്പ്, Responses API സ്കിൽ ലോഡ് ചെയ്ത് അത് മോഡൽ കോൺടെക്സ്റ്റിൽ ഉൾപ്പെടുത്തുന്നു. ഈ സീക്വൻസ് നിശ്ചിതമാണ്:
- പേരും വിവരണവും ഉൾപ്പെടെ സ്കിൽ മെറ്റാഡാറ്റ ലഭ്യമാക്കുക.
- സ്കിൽ ബണ്ടിൽ ലഭ്യമാക്കുക, അത് കണ്ടെയ്നറിലേക്ക് പകർത്തുക, തുടർന്ന് അത് അൺപാക്ക് ചെയ്യുക.
- സ്കിൽ മെറ്റാഡാറ്റയും കണ്ടെയ്നർ പാത്തും ഉപയോഗിച്ച് മോഡൽ സന്ദർഭം അപ്ഡേറ്റ് ചെയ്യുക.
ഒരു സ്കിൽ പ്രസക്തമാണോ എന്ന് തീരുമാനിക്കുമ്പോൾ, മോഡൽ ക്രമാനുഗതമായി അതിന്റെ നിർദ്ദേശങ്ങൾ പരിശോധിക്കുകയും, കണ്ടെയ്നറിലെ ഷെൽ കമാൻഡുകൾ വഴി അതിന്റെ സ്ക്രിപ്റ്റുകൾ നടപ്പിലാക്കുകയും ചെയ്യുന്നു.
എല്ലാ ഘടകങ്ങളും ഒന്നിച്ച് ചേർത്താൽ: Responses API ഓർക്കസ്ട്രേഷൻ നൽകുന്നു, ഷെല് ടൂള് നിർവഹിക്കാവുന്ന പ്രവർത്തനങ്ങൾ നൽകുന്നു, hosted container സ്ഥിരമായ റൺടൈം സന്ദർഭം നൽകുന്നു, സ്കില്സ് ലെയർ പുനരുപയോഗിക്കാവുന്ന വർക്ക്ഫ്ലോ ലജിക് നൽകുന്നു, കൂടാതെ compaction ഒരു ഏജന്റിന് ആവശ്യമായ സന്ദർഭത്തോടൊപ്പം ദീർഘകാലം പ്രവർത്തിക്കാൻ അനുവദിക്കുന്നു.
ഈ പ്രിമിറ്റീവുകൾ ഉപയോഗിച്ച്, ഒരു ഒറ്റ പ്രോംപ്റ്റ് എൻഡ്-ടു-എൻഡ് വർക്ക്ഫ്ലോയായി വിപുലീകരിക്കാം: ശരിയായ സ്കിൽ കണ്ടെത്തുക, ഡാറ്റ ഫെച്ച് ചെയ്യുക, അത് ലോക്കൽ സ്ട്രക്ചേർഡ് സ്റ്റേറ്റായി പരിവർത്തനം ചെയ്യുക, അത് കാര്യക്ഷമമായി ക്വറി ചെയ്യുക, കൂടാതെ ദീർഘകാലം നിലനിൽക്കുന്ന ആർട്ടിഫാക്റ്റുകൾ സൃഷ്ടിക്കുക.
താഴെയുള്ള ഡയഗ്രം ലൈവ് ഡാറ്റയിൽ നിന്ന് ഒരു സ്പ്രെഡ്ഷീറ്റ് സൃഷ്ടിക്കുന്നതിന് ഈ സിസ്റ്റം എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്ന് കാണിക്കുന്നു.
Responses API ഒരു ഏജന്റിക് ടാസ്ക് ഏകോപിപ്പിക്കുന്നു
എൻഡ്-ടു-എൻഡ് വർക്ക്ഫ്ലോകൾക്കായി ഷെൽ ടൂളും കമ്പ്യൂട്ടർ പരിതസ്ഥിതിയും സംയോജിപ്പിക്കുന്നതിന്റെ വിശദമായ ഒരു ഉദാഹരണത്തിനായി, ഒരു സ്കിൽ പാക്കേജ് ചെയ്യുന്നതും Responses API വഴി അത് പ്രവർത്തിപ്പിക്കുന്നതും വിശദീകരിക്കുന്ന ഞങ്ങളുടെ ഡെവലപ്പർ ബ്ലോഗ് പോസ്റ്റ്(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ഉം കുക്ക്ബുക്ക്(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ഉം കാണുക.
ഈ പ്രിമിറ്റീവുകളുടെ ഈ സെറ്റ് ഉപയോഗിച്ച് ഡെവലപ്പർമാർ എന്താണ് നിർമ്മിക്കുന്നതെന്ന് കാണാൻ ഞങ്ങൾ ആവേശഭരിതരാണ്. ഭാഷാ മോഡൽ ടെക്സ്റ്റ്, ചിത്രങ്ങൾ, ഓഡിയോ എന്നിവ സൃഷ്ടിക്കുന്നതിലുപരി കൂടുതൽ കാര്യങ്ങൾ ചെയ്യാനാണ് ഉദ്ദേശിച്ചിരിക്കുന്നത്–വലിയ തോതിൽ സങ്കീർണ്ണമായ, യഥാർത്ഥ ലോക ടാസ്കുകൾ കൈകാര്യം ചെയ്യുന്നതിൽ കൂടുതൽ കഴിവുള്ളതാകാൻ ഞങ്ങൾ ഞങ്ങളുടെ പ്ലാറ്റ്ഫോം തുടർച്ചയായി വികസിപ്പിക്കും.
