Манай ChatGPT‑д суурилсан Atlas браузерын ар дахь шинэ архитектур OWL-ийг бид хэрхэн бүтээсэн бэ

Техникийн багийн гишүүн Ken Rockot болон ChatGPT Atlas инженерийн албаны дарга Ben Goodger нар

Өнгөрсөн долоо хоногт бид ChatGPT Atlas-ыг танилцуулсан⁠. Энэ нь ChatGPT‑ийг хажуудаа байлган вэбээр аялах шинэ арга юм. Atlas нь бүрэн боломжтой вэб браузер байхаас гадна ирээдүйн нэг өнгө төрхийг харуулдаг: та ChatGPT‑ийг интернет даяар авч явж, асуулт асуух, санал авах, мөн даалгавраа гүйцэтгүүлэх ертөнц. Энэ нийтлэлээр бид бүтээгдэхүүний инженерчлэлийн хамгийн төвөгтэй талуудын нэгийг задлан тайлбарлана: ChatGPT‑ийг хэрхэн явц ахих тусам илүү хэрэгтэй болдог браузер болгосон тухай.

ChatGPT‑ийг вэбийн жинхэнэ хамтран жолоодогч болгоно гэдэг нь браузерын бүх архитектурыг дахин төсөөлнө гэсэн үг байсан: Atlas-ыг Chromium runtime-ээс салгах. Үүний тулд Chromium-ийг нэгтгэх шинэ аргыг хөгжүүлсэн бөгөөд энэ нь манай бүтээгдэхүүний зорилгыг биелүүлэх боломж олгосон: агшин зуур асаалт, олон таб нээсэн ч хариу үйлдэлтэй байх, мөн агент хэрэглээний тохиолдлуудад зориулсан бат бөх суурь бий болгох.

Chromium бол байгалийн сонголт байсан. Энэ нь орчин үеийн вэб хөдөлгүүр, бат бөх аюулгүй байдлын загвар, нотлогдсон гүйцэтгэл, хосгүй вэб нийцтэй байдлыг санал болгодог. Түүнчлэн үүнийг дэлхий даяарх хамт олон тасралтгүй сайжруулж хөгжүүлдэг. Тиймээс энэ нь орчин үеийн десктоп вэб браузеруудын түгээмэл суурь болдог.

Манай чадварлаг дизайны баг хэрэглэгчийн туршлагад өндөр зорилт тавьсан. Үүнд Agent mode зэрэг боломжуудад зориулсан баялаг анимейшн, дүрсний эффектүүд багтсан. Үүний тулд манай инженерийн баг Chromium-ийн нээлттэй эхийн UX-ийг зүгээр л шинэчлэн будахын оронд UI-д зориулсан хамгийн орчин үеийн native framework-уудыг (SwiftUI, AppKit, Metal) ашиглах шаардлагатай болсон. Үүний дүнд Atlas-ийн UI нь бүх аппликейшний UX-ийг иж бүрнээр нь дахин бүтээсэн хувилбар болсон.

Мөн бидэнд хурдан асаалт, гүйцэтгэлийг унагахгүйгээр хэдэн зуун таб дэмжих зэрэг бусад бүтээгдэхүүний зорилго байсан. Эдгээр зорилтыг Chromium-ийг шууд ашиглаад хэрэгжүүлэхэд хэцүү байсан, учир нь тэр boot sequence, threading model, tab model зэрэг олон нарийн зүйл дээр өөрийн хатуу шийдэлтэй. Бид энд томоохон өөрчлөлт хийхийг бодож үзсэн ч Chromium дээрх patch-уудынхаа цар хүрээг аль болох чиглэсэн байлгаж, шинэ хувилбаруудыг хурдан нэгтгэхийг хүссэн. Хөгжүүлэлтийн хурдаа дээд зэргээр нэмэхийн тулд Chromium runtime-ийг нэгтгэж, ажиллуулах өөр арга сэдэх хэрэгтэй болсон.

Манай техникийн хөрөнгө оруулалтын шалгуур нь зөвхөн илүү хурдан туршилт, давталт, шинэ боломжийн нийлүүлэлтийг дэмжихэд бус, OpenAI-ийн инженерийн соёлын нэг гол хэсгийг хадгалах ёстой байсан: эхний өдөрт нь нийлүүлэх. Шинэ инженер бүр эхний өдрийнхөө үдээс хойш жижиг өөрчлөлт хийж, merge хийдэг. Chromium-ийг checkout хийж build хийхэд хэдэн цаг ордог байсан ч энэ боломжтой хэвээр байх ёстой байв.

Эдгээр сорилтын хариу нь бидний OWL: OpenAI’s Web Layer гэж нэрлэдэг шинэ архитектурын давхаргыг бүтээх явдал байлаа. OWL бол Chromium-ийг нэгтгэсэн манай шийдэл бөгөөд Chromium-ийн browser process-ийг үндсэн Atlas аппын process-оос гадуур ажиллуулдгаараа онцлог.

Үүнийг ингэж төсөөлж болно: Chromium табуудыг тусдаа process руу шилжүүлснээр браузеруудыг шинэчилсэн. Харин бид энэ санааг цааш нь хөгжүүлж, Chromium-ийг өөрийг нь үндсэн аппликейшний process-оос гарган тусгаарлагдсан service layer руу шилжүүлж байна. Энэ өөрчлөлт нь дараах олон давуу талыг нээж өгдөг:

• Илүү энгийн, орчин үеийн апп: Atlas бараг бүхэлдээ SwiftUI болон AppKit дээр бүтээгдсэн. Нэг хэл, нэг технологийн стек, нэг цэвэр кодын сан.
• Илүү хурдан асаалт: Chromium ар талд асинхроноор ачаалдаг. Atlas хүлээхгүй — дүрс бараг агшин зуур дэлгэцэнд гарна.
• Саатал ба crash-ээс тусгаарлалт: Chromium бол хүчирхэг бөгөөд төвөгтэй вэб хөдөлгүүр. Хэрэв түүний үндсэн thread гацвал Atlas гацаxгүй. Хэрэв тэр crash хийвэл Atlas ажилласаар байна.
• Merge хийхэд цөөн толгой өвтгөх асуудал: Бид Chromium-ийн нээлттэй эхийн UI-ийн ихэнх дээр суурилан бүтээхгүй байгаа тул upstream Chromium-тай харьцуулсан diff маань хамаагүй бага, арчлахад амархан.
• Илүү хурдан давталт: Ихэнх инженерүүдэд Chromium-ийг локал дээр build хийх шаардлага гардаггүй. OWL нь дотооддоо урьдчилан build хийсэн binary байдлаар нийлүүлэгддэг тул Atlas-ын build цаг хэдэн цагаар биш, хэдхэн минутаар хэмжигдэнэ.

Манай багийн ихэнх инженерүүд Chromium-ийг source-оос тогтмол build хийдэггүй учраас хөгжүүлэлт илүү хурдан явагддаг—шинэ багийн гишүүд хүртэл эхний өдрийнхөө үдээс хойш энгийн өөрчлөлтүүдийг merge хийж чадна.

Өндөр түвшинд авч үзвэл Atlas браузер нь OWL Client, харин Chromium-ийн browser process нь OWL Host юм. Эдгээр нь IPC-ээр, тодруулбал Chromium-ийн өөрийн мессеж дамжуулах систем болох Mojo⁠(шинэ цонхонд нээгдэнэ)-гоор харилцдаг. Бид Mojo-д зориулсан тусгай Swift (тэр ч байтугай TypeScript) binding-уудыг бичсэн тул манай Swift апп host талын интерфэйсүүдийг шууд дуудаж чаддаг.

OWL client library нь host-ын service layer-ээс ил гардаг хэд хэдэн гол ойлголтыг хийсвэрлэсэн энгийн public Swift API-г санал болгодог:

• Session: Host-ыг глобал түвшинд тохируулах, удирдах
• Profile: Тодорхой хэрэглэгчийн профайлын browser state-ийг удирдах
• WebView: Тус тусын web content-ийг удирдах, шигтгэх (ж. render, input, navigate, zoom гэх мэт)
• WebContentRenderer: Input event-үүдийг Chromium-ийн rendering pipeline руу дамжуулж, renderer-ээс буцах мэдээлэл хүлээн авах
• LayerHost/Client: UI болон Chromium-ийн хооронд compositing мэдээлэл солилцох

Мөн bookmarks, downloads, extensions, autofill зэрэг өндөр түвшний боломжуудыг удирдах өргөн хүрээний service endpoints бас бий.

Client апп дотор харилцан үл давхцах presentation space хуваалцдаг WebView-үүдийг нэг shared compositing container дотор ээлжлэн оруулж, гаргадаг. Жишээлбэл, browser цонхонд ихэвчлэн нэг shared container харагдаж байдаг бөгөөд tab strip дээр таб сонгоход тухайн табын WebView тэр container руу солигдон ордог. Chromium талд энэ container нь эцсийн дүндээ CALayer-аар тулгуурлагдсан gfx::AcceleratedWidget-тай таарна. Бид тэр layer-ийн context ID-г client-д ил гаргаж, тэнд NSView нь private CALayerHost API ашиглан үүнийг шигтгэдэг.

<select> dropdown эсвэл өнгө сонгогч зэрэг Chromium тусдаа popup widget дээр рэндэрлэдэг онцгой тохиолдлууд ч мөн ижил аргыг ашигладаг. Тэдэнд content::WebContents байхгүй ч өөрийн gfx::AcceleratedWidget-тай content::RenderWidgetHostView байдаг тул ижил delegated rendering загвар үйлчилнэ.

OWL нь дотроо view geometry-г Chromium талтай синк байлгадаг тул GPU compositor зохих ёсоор шинэчлэгдэж, үргэлж зөв хэмжээ ба device scale-тай layer агуулгыг гаргаж чадна.

Мөн бид энэ аргыг Chromium-ийн өөрийн native Views UI-ийн элементүүдийг сонгон Atlas руу проекцлохдоо дахин ашигладаг (энэ нь SwiftUI дээр орлуулах хувилбаруудыг эхнээс нь бүтээхгүйгээр permission prompt зэрэг боломжуудыг хурдан босгоход бас тустай). Энэ арга нь macOS дээрх installable web app-уудад зориулсан Chromium-ийн одоо байгаа дэд бүтцээс ихээхэн санаа авсан.

Chromium UI нь platform event-үүдийг (жишээ нь macOS NSEvent) Blink-ийн WebInputEvent загвар руу хөрвүүлээд renderer-ууд руу дамжуулдаг. Харин OWL нь Chromium-ийг далд process дотор ажиллуулдаг тул бид энэ хөрвүүлэлтийг Swift client library дотроо өөрсдөө хийж, аль хэдийн хөрвүүлэгдсэн event-үүдийг Chromium руу дамжуулдаг.

Тэндээс тэд жинхэнэ input event-үүд web content-д ердийн үед дагах амьдралын мөчлөгийг яг адилхан дагана. Үүнд тухайн хуудас event-ийг боловсруулаагүй гэдгээ илэрхийлэх үед event-үүдийг client руу буцаан илгээх нь ч багтана. Ийм зүйл болоход бид NSEvent-ийг дахин синтезлэж, аппын үлдсэн хэсэгт энэ input-ийг боловсруулах боломж олгодог.

Atlas-ийн агент браузинг боломж нь рэндэрлэлт, input event дамжуулалт, өгөгдөл хадгалалтын талаарх манай арга барилд өвөрмөц сорилтуудыг бий болгодог.

Манай computer use загвар нь оролт болгон дэлгэцийн нэг зураг хүлээдэг. Гэхдээ <select> dropdown зэрэг зарим UI элементүүд табын хилээс гадуур тусдаа цонхонд рэндэрлэгддэг. Agent mode-д бид тэдгээр popup-уудыг үндсэн хуудасны зураг руу зөв координатаар нь дахин нэгтгэдэг бөгөөд ингэснээр загвар нэг frame дотор бүх контекстийг хардаг.

Оролтын хувьд бид ижил зарчмыг баримталдаг: агентын үүсгэсэн event-үүд privileged browser layer-ээр хэзээ ч дамжихгүй, шууд renderer рүү чиглүүлэгддэг. Ингэснээр автомат удирдлагын үед ч sandbox boundary хадгалагдана. Жишээлбэл, ийм төрлийн event-үүд браузераар тухайн харуулж буй web content-той холбоогүй зүйл хийлгэх keyboard shortcut-уудыг синтезлэхийг бид хүсдэггүй.

Agent browsing нь мөн түр зуурын "logged-out" контекстэд ажиллаж болно. Төлөв алдагдах эрсдэлтэй тул хэрэглэгчийн одоо байгаа Incognito профайлыг хуваалцахын оронд бид Chromium-ийн StoragePartition дэд бүтцийг ашиглан тусгаарлагдсан, санах ойд хадгалагдах store-уудыг үүсгэдэг. Агент session бүр цэвэр эхэлдэг бөгөөд дуусахад нь бүх cookie болон сайтын өгөгдөл устгагдана. Та олон "logged-out" agent session-ийг зэрэг ажиллуулж болно, тус бүр нь өөрийн browser tab дотор, мөн бусдаасаа бүрэн тусгаарлагдсан байна.

Энэ бүхэн дэлхий даяарх Chromium хамт олон болон орчин үеийн вэбийн суурийг бүтээсэн тэдний гайхалтай ажлын ачаар боломжтой болсон. OWL энэ суурин дээр шинэ аргаар бүтэж байна: хөдөлгүүрийг апп-аас салгах, дэлхийн түвшний вэб платформыг орчин үеийн native framework-уудтай хослуулах, мөн илүү хурдан, уян хатан архитектурыг нээх.

Браузер Chromium-ийг хэрхэн агуулдгийг дахин бодсоноор бид шинэ төрлийн туршлагуудад орон зай бий болгож байна: илүү жигд асаалт, илүү баялаг UI, OS-ийн бусад хэсэгтэй илүү нягт уялдаа, мөн санааны хурдаар хөдөлдөг хөгжүүлэлтийн цикл. Хэрэв энэ нь танд сонирхолтой сорилт мэт санагдаж байвал Software Engineer, Atlas⁠, Software Engineer, iOS⁠, мөн бусад⁠ ажлын байртай танилцаарай.

Atlas-ыг chatgpt.com/atlas⁠⁠(шинэ цонхонд нээгдэнэ) дээр туршаад үзээрэй.