અમે OWL કેવી રીતે બનાવ્યું, અમારા ChatGPT‑આધારિત બ્રાઉઝર Atlas પાછળની નવી આર્કિટેક્ચર

Ken Rockot, Member of the Technical Staff અને Ben Goodger, Head of Engineering, ChatGPT Atlas દ્વારા

ગયા અઠવાડિયે, અમે ChatGPT Atlas લોન્ચ કર્યું⁠, ChatGPT ને તમારી બાજુમાં રાખીને વેબ બ્રાઉઝ કરવાની નવી રીત. સંપૂર્ણ સુવિધાવાળા વેબ બ્રાઉઝર હોવા ઉપરાંત, Atlas ભવિષ્યની ઝલક પણ આપે છે: એવી દુનિયા જ્યાં તમે ChatGPT ને આખા ઇન્ટરનેટ પર તમારી સાથે લઈ જઈ શકો છો, પ્રશ્નો પૂછવા, સૂચનો મેળવવા અને તમારા માટે કાર્યો પૂર્ણ કરવા માટે. આ પોસ્ટમાં, અમે પ્રોડક્ટના સૌથી જટિલ એન્જિનિયરિંગ પાસાઓમાંથી એકને સમજાવીએ છીએ: અમે ChatGPT ને એવો બ્રાઉઝર કેવી રીતે બનાવ્યો જે તમે આગળ વધો તેમ વધુ ઉપયોગી બનતો જાય.

ChatGPT ને વેબ માટે સાચો કો-પાઇલટ બનાવવાનો અર્થ હતો બ્રાઉઝરની સંપૂર્ણ આર્કિટેક્ચરને ફરીથી કલ્પવી: Atlas ને Chromium runtime થી અલગ કરવું. આ માટે Chromium ને એક નવા રીતે એકીકૃત કરવું પડ્યું, જેથી અમે અમારા પ્રોડક્ટ લક્ષ્યો પૂરાં કરી શકીએ: તાત્કાલિક સ્ટાર્ટઅપ, વધુ tabs ખોલો ત્યારે પણ પ્રતિસાદક્ષમતા, અને agentic ઉપયોગ કિસ્સાઓ માટે મજબૂત પાયો બનાવવો.

Chromium સ્વાભાવિક building block હતું. તે મજબૂત security model, સ્થાપિત performance credentials અને બેમિસાલ web compatibility સાથે અદ્યતન web engine આપે છે. ઉપરાંત, તેનું વિકાસ વૈશ્વિક community દ્વારા થાય છે જે સતત તેમાં સુધારો કરે છે. આધુનિક desktop web browsers માટે તે સામાન્ય પસંદગી છે.

અમારી પ્રતિભાશાળી design ટીમે અમારા user experience માટે મહત્ત્વાકાંક્ષી લક્ષ્યો નક્કી કર્યા હતા, જેમાં Agent mode જેવી સુવિધાઓ માટે સમૃદ્ધ animations અને visual effects પણ સામેલ હતા. આ માટે અમારી engineering ટીમને UI માટે સૌથી આધુનિક native frameworks (SwiftUI, AppKit અને Metal) નો ઉપયોગ કરવો જરૂરી હતો, માત્ર open source Chromium UX ને નવા દેખાવ સાથે રજૂ કરવાની જગ્યાએ. પરિણામે, Atlas નું UI સમગ્ર application UX નું વ્યાપક પુનર્નિર્માણ છે.

અમારા બીજા પ્રોડક્ટ લક્ષ્યો પણ હતા, જેમ કે ઝડપી startup times અને performance પર અસર કર્યા વગર સૈંકડો tabs ને support કરવી. Chromium out-of-the-box સાથે આ લક્ષ્યો હાંસલ કરવું મુશ્કેલ હતું, કારણ કે Chromium boot sequence, threading model અને tab models જેવી ઘણી વિગતો વિશે નક્કર અભિગમ ધરાવે છે. અમે અહીં મોટા ફેરફારો કરવાનો વિચાર કર્યો, પરંતુ Chromium સામેના અમારા patches ને મર્યાદિત રાખવા માગતા હતા જેથી અમે નવી versions ઝડપથી integrate કરી શકીએ. અમારી development velocity ને શક્ય તેટલી વધારે ઝડપ આપવા માટે, Chromium runtime ને integrate અને drive કરવાની અલગ રીત શોધવી જરૂરી હતી.

અમારા ટેક્નિકલ રોકાણ માટેનો સાચો કસોટીબિંદુ માત્ર એટલો જ નહોતો કે તે ઝડપી experimentation, iteration અને નવી features ની delivery સક્ષમ બનાવશે – તે OpenAI ની engineering culture ના એક મૂળભૂત ભાગને જાળવવામાં પણ મદદ કરશે: પ્રથમ જ દિવસે ship કરવું. દરેક નવા engineer પોતાના પ્રથમ દિવસની બપોરે નાનો ફેરફાર કરે છે અને તેને merge કરે છે. Chromium ને check out અને build કરવામાં કલાકો લાગી શકે છે, છતાં આ શક્ય રહે તેની ખાતરી કરવી અમારે માટે જરૂરી હતી.

આ પડકારોનો અમારો જવાબ હતો નવી architectural layer બનાવવી જેને અમે OWL: OpenAI’s Web Layer કહીએ છીએ. OWL એ Chromium નું અમારું integration છે, જેમાં Chromium ની browser process મુખ્ય Atlas app process ની બહાર ચલાવવી સામેલ છે.

આને આ રીતે વિચારો: Chromium એ tabs ને અલગ processes માં ખસેડીને browsers માં ક્રાંતિ લાવી. અમે એ વિચારને આગળ લઈ જઈ રહ્યા છીએ, Chromium ને જ મુખ્ય application process માંથી બહાર કાઢીને અલગ service layer માં ખસેડીને. આ ફેરફાર ઘણા ફાયદા ખોલે છે:

• સરળ, આધુનિક એપ: Atlas લગભગ સંપૂર્ણ રીતે SwiftUI અને AppKit માં બનાવાયેલું છે. એક ભાષા, એક tech stack, એક સ્વચ્છ codebase.
• ઝડપી સ્ટાર્ટઅપ: Chromium પાછળના ભાગમાં અસંક્રમ રીતે boot થાય છે. Atlas રાહ જોતું નથી — pixels લગભગ તરત જ સ્ક્રીન પર દેખાય છે.
• અટકણ અને ક્રેશથી અલગાવ: Chromium શક્તિશાળી અને જટિલ web engine છે. તેનું main thread અટકી જાય તો પણ Atlas અટકતું નથી. તે ક્રેશ થાય તો પણ Atlas ચાલુ રહે છે.
• ઓછા merge headache: કારણ કે અમે Chromium open source UI ના એટલા મોટા ભાગ પર build નથી કરતા, upstream Chromium સામેનો અમારો diff ઘણો નાનો અને જાળવવામાં સરળ છે.
• ઝડપી iteration: મોટાભાગના engineers ને Chromium સ્થાનિક રીતે build કરવાની જરૂર પડતી નથી. OWL આંતરિક રીતે prebuilt binary તરીકે ship થાય છે, તેથી Atlas builds કલાકો નહીં પણ મિનિટોમાં થાય છે.

કારણ કે અમારી ટીમના મોટા ભાગના engineers નિયમિત રીતે Chromium ને source માંથી build કરતા નથી, development ઘણું ઝડપી બની શકે છે—નવા ટીમ સભ્યો પણ તેમની પ્રથમ બપોરે સરળ ફેરફારો merge કરી શકે છે.

ઉચ્ચ સ્તરે, Atlas browser એ OWL Client છે, અને Chromium browser process એ OWL Host છે. તેઓ IPC દ્વારા વાતચીત કરે છે, ખાસ કરીને Mojo⁠(નવી વિન્ડોમાં ખૂલે છે), જે Chromium ની પોતાની message-passing system છે. અમે Mojo માટે custom Swift (અગાઉ TypeScript પણ) bindings લખ્યાં છે, જેથી અમારી Swift app સીધા host-side interfaces ને call કરી શકે.

OWL client library એક સરળ public Swift API પ્રદાન કરે છે, જે host ની service layer દ્વારા exposed થયેલા કેટલાક મુખ્ય concepts ને abstract કરે છે:

• Session: host ને વૈશ્વિક સ્તરે configure અને control કરો.
• Profile: ચોક્કસ user profile માટે browser state સંચાલિત કરો.
• WebView: વ્યક્તિગત web contents ને control અને embed કરો (જેમ કે render, input, navigate, zoom, વગેરે).
• WebContentRenderer: input events ને Chromium ની rendering pipeline માં આગળ ધપાવો અને renderer પાસેથી feedback મેળવો.
• LayerHost/Client: UI અને Chromium વચ્ચે compositing information નો વિનિમય કરો.

bookmarks, downloads, extensions અને autofill જેવી ઉચ્ચ-સ્તરની સુવિધાઓ સંચાલિત કરવા માટે service endpoints ની પણ વિશાળ શ્રેણી છે.

WebViews, જે client app માં પરસ્પર એકમાત્ર presentation space વહેંચે છે, shared compositing container માં અંદર-બહાર swap થાય છે. ઉદાહરણ તરીકે, browser window માં ઘણીવાર એક જ shared container દેખાતો હોય છે અને tab strip માં tab પસંદ કરતાં તે tab નું WebView container માં swap થાય છે. Chromium બાજુએ, આ container એક gfx::AcceleratedWidget ને અનુરૂપ છે, જેને અંતે CALayer આધાર આપે છે. અમે તે layer નો context ID client સુધી પહોંચાડીએ છીએ, જ્યાં NSView private CALayerHost API નો ઉપયોગ કરીને તેને embed કરે છે.

<select> dropdowns અથવા color pickers જેવા ખાસ કિસ્સાઓ, જેને Chromium અલગ popup widgets માં render કરે છે, એ જ રીત અપનાવે છે. તેમની પાસે content::WebContents નથી, પરંતુ તેમની પાસે પોતાનું gfx::AcceleratedWidget ધરાવતું content::RenderWidgetHostView તો હોય જ છે, તેથી તે જ delegated rendering model લાગુ પડે છે.

OWL અંદરથી view geometry ને Chromium બાજુ સાથે sync માં રાખે છે, જેથી GPU compositor ને અનુકૂળ રીતે update કરી શકાય અને તે હંમેશા યોગ્ય size અને device scale નું layer content બનાવી શકે.

અમે આ જ ટેક્નિકનો ફરીથી ઉપયોગ કરીને Chromium ના પોતાના native Views UI ના કેટલાક elements ને પસંદગીપૂર્વક Atlas માં project કરીએ છીએ (આ SwiftUI માં scratch થી replacements બનાવ્યા વગર permission prompts જેવી features ઝડપથી bootstrap કરવા માટે પણ ઉપયોગી છે). આ ટેક્નિક macOS પર installable web apps માટે Chromium ના હાજર infrastructure પરથી ઘણું ઉધાર લે છે.

Chromium UI platform events (જેમ કે macOS NSEvents) ને renderers સુધી મોકલતા પહેલાં Blink ના WebInputEvent model માં અનુવાદ કરે છે. પરંતુ OWL Chromium ને hidden process માં ચલાવે છે, તેથી અમે તે અનુવાદ Swift client library અંદર જ કરીએ છીએ અને પહેલેથી અનુવાદિત events ને Chromium સુધી forward કરીએ છીએ.

ત્યારબાદ, તે web content માટે સાચા input events સામાન્ય રીતે જે lifecycle અનુસરે છે તે જ અનુસરે છે. તેમાં page દર્શાવે કે તેણે event હેન્ડલ કર્યો નથી ત્યારે events ને client પાસે પાછા મોકલવામાં આવવું પણ સામેલ છે. જ્યારે આવું થાય છે, ત્યારે અમે NSEvent ને ફરીથી synthesize કરીએ છીએ અને app ના બાકીના ભાગને input હેન્ડલ કરવાની તક આપીએ છીએ.

Atlas ની agentic browsing સુવિધા rendering, input event forwarding અને data storage માટેના અમારા અભિગમોમાં કેટલીક અનન્ય મુશ્કેલીઓ ઊભી કરે છે.

અમારું computer use model input તરીકે સ્ક્રીનની એક જ image અપેક્ષે છે. પરંતુ <select> dropdowns જેવા કેટલાક UI elements, tab ની હદ બહાર અલગ windows માં render થાય છે. Agent mode માં, અમે તે popups ને યોગ્ય coordinates પર ફરીથી main page image માં composite કરીએ છીએ જેથી મોડલને એક જ frame માં સંપૂર્ણ context દેખાય.

Input માટે, અમે એ જ સિદ્ધાંત અપનાવીએ છીએ: agent દ્વારા બનાવાયેલા events સીધા renderer સુધી જ પહોંચાડવામાં આવે છે, privileged browser layer દ્વારા ક્યારેય નહીં. આથી automated control હેઠળ પણ sandbox boundary જળવાઈ રહે છે. ઉદાહરણ તરીકે, અમે નથી ઇચ્છતા કે આ પ્રકારના events એવા keyboard shortcuts synthesize કરે જે browser ને બતાવાતી web content સાથે અસંબંધિત કામ કરવા મજબૂર કરે.

Agent browsing તાત્કાલિક "logged-out" context માં પણ ચાલી શકે છે. user ની હાજર Incognito profile સાથે state leak થઈ શકે છે, તેથી અમે તેને share કરતા નથી; તેના બદલે Chromium ના StoragePartition infrastructure નો ઉપયોગ કરીને અલગ, in-memory stores ઉભા કરીએ છીએ. દરેક agent session નવા રીતે શરૂ થાય છે, અને તે પૂરું થાય ત્યારે બધા cookies અને site data કાઢી નાખવામાં આવે છે. તમે અનેક "logged-out" agent sessions ચલાવી શકો છો, દરેક પોતપોતાના browser tab માં અને એકબીજાથી સંપૂર્ણ રીતે અલગ.

આમાંથી કશું પણ વૈશ્વિક Chromium community અને આધુનિક વેબ માટે પાયો બાંધવાના તેમના અદ્ભુત કાર્ય વિના શક્ય ન હોત. OWL એ પાયા પર નવી રીતે નિર્માણ કરે છે: engine ને app થી અલગ કરીને, વિશ્વ-સ્તરીય web platform ને આધુનિક native frameworks સાથે ભેળવીને, અને વધુ ઝડપી, વધુ લવચીક આર્કિટેક્ચર ખોલીને.

બ્રાઉઝર Chromium ને કેવી રીતે ધરાવે છે તેનો ફરી વિચાર કરીને, અમે નવી પ્રકારના અનુભવો માટે જગ્યા બનાવી રહ્યા છીએ: વધુ મસૃણ startups, વધુ સમૃદ્ધ UI, બાકીના OS સાથે વધુ કડક integration, અને વિચારોની ઝડપે આગળ વધતો development loop. જો આ તમને ગમતું પડકાર લાગે, તો Atlas પર કામ કરવા માટે અમારી openings જુઓ: Software Engineer, Atlas⁠, Software Engineer, iOS⁠, અને વધુ⁠.

Atlas અજમાવો chatgpt.com/atlas⁠⁠(નવી વિન્ડોમાં ખૂલે છે) પર.