Cómo hemos creado OWL, la nueva arquitectura detrás de Atlas, nuestro navegador basado en ChatGPT

Por Ken Rockot, miembro del personal técnico, y Ben Goodger, jefe de ingeniería de ChatGPT Atlas

La semana pasada lanzamos ChatGPT Atlas⁠, una nueva forma de navegar por la web con ChatGPT a tu lado. Además de ser un navegador web con todas las funciones, Atlas ofrece un vistazo al futuro: un mundo en el que puedes llevar a ChatGPT contigo a través de Internet para hacer preguntas, dar sugerencias y completar tareas por ti. En esta publicación, analizamos uno de los aspectos de ingeniería más complejos del producto: cómo hemos convertido ChatGPT en un navegador que, con el uso, se vuelve cada vez más útil.

Convertir ChatGPT en un auténtico copiloto para la web supuso rediseñar toda la arquitectura de un navegador: separar Atlas del tiempo de ejecución de Chromium. Esto implicó desarrollar una nueva forma de integrar Chromium que nos permitiera cumplir con los objetivos de nuestro producto: inicio instantáneo, capacidad de respuesta incluso al abrir más pestañas y creación de una base sólida para casos de uso de agente.

Chromium era un componente básico natural. Ofrece un motor web de última generación con un sólido modelo de seguridad, credenciales de rendimiento consolidadas y una compatibilidad web sin igual. Además, está desarrollado por una comunidad global que se dedica a mejorarlo continuamente. Es una opción habitual para los navegadores web de escritorio modernos.

Nuestro profesional equipo de diseño tenía ambiciosos objetivos para la experiencia de usuario, que incluían animaciones y efectos visuales sofisticados para funciones como el modo Agente. Esto requirió que nuestro equipo de ingeniería aprovechara los marcos nativos más modernos para nuestra interfaz de usuario (SwiftUI, AppKit y Metal), en lugar de simplemente cambiar la apariencia de la experiencia de usuario de Chromium de código abierto. Como resultado, la interfaz de usuario de Atlas es una reconstrucción completa de toda la experiencia de usuario de la aplicación.

También teníamos otros objetivos de producto, como tiempos de inicio rápidos y compatibilidad con cientos de pestañas sin penalizar el rendimiento. Estos objetivos eran difíciles de alcanzar utilizando Chromium tal cual, que es muy exigente con muchos detalles, desde la secuencia de arranque hasta el modelo de subprocesos y los modelos de pestañas. Consideramos realizar cambios sustanciales aquí, pero queríamos mantener nuestro conjunto de parches para Chromium específicos, de modo que pudiéramos integrar rápidamente las nuevas versiones. Para garantizar que nuestra velocidad de desarrollo se acelerara al máximo, necesitábamos encontrar una forma diferente de integrar e impulsar el tiempo de ejecución de Chromium.

La prueba de fuego para nuestra inversión técnica no solo era que permitiera una experimentación, iteración y entrega de nuevas funciones más rápidas, sino que también nos permitiera mantener una parte fundamental de la cultura de ingeniería de OpenAI: el lanzamiento desde el primer día. Cada nuevo ingeniero realiza y fusiona un pequeño cambio durante la tarde de su primer día. Teníamos que asegurarnos de que esto fuera posible, aunque Chromium puede tardar horas en comprobarse y compilarse.

Nuestra respuesta a estos retos fue crear una nueva capa arquitectónica que llamamos OWL: OpenAI’s Web Layer (la capa web de OpenAI). OWL es nuestra integración de Chromium, que implica ejecutar el proceso del navegador Chromium fuera del proceso principal de la aplicación Atlas.

Piensa en ello de esta manera: Chromium revolucionó los navegadores al trasladar las pestañas a procesos separados. Estamos llevando esa idea más allá al trasladar el propio Chromium fuera del proceso principal de la aplicación y a una capa de servicio aislada. Este cambio ofrece una serie de ventajas:

• Una app más simple y moderna: Atlas está desarrollada casi en su totalidad en SwiftUI y AppKit. Un lenguaje, una pila tecnológica, una base de código limpia.
• Inicio más rápido: Chromium se inicia de forma asíncrona en segundo plano. Atlas no espera: los píxeles aparecen en la pantalla casi al instante.
• Aislamiento de fallos y bloqueos: Chromium es un motor web potente y complejo. Si su hilo principal se cuelga, Atlas no lo hace. Si se bloquea, Atlas sigue funcionando.
• Menos dolores de cabeza con las fusiones: Como no estamos construyendo tanto sobre la interfaz de usuario de código abierto de Chromium, nuestras diferencias con respecto al Chromium estándar son mucho menores y más fáciles de mantener.
• Iteración más rápida: La mayoría de los ingenieros nunca necesitan compilar Chromium localmente. OWL se distribuye internamente como un binario precompilado, por lo que las compilaciones de Atlas tardan minutos, no horas.

Dado que la mayoría de los ingenieros de nuestro equipo no compilan Chromium desde el código fuente de forma habitual, el desarrollo puede ser mucho más rápido, incluso los nuevos miembros del equipo pueden fusionar cambios sencillos en su primera tarde.

A alto nivel, el navegador Atlas es el cliente OWL y el proceso del navegador Chromium es el host OWL. Se comunican a través de IPC, concretamente Mojo⁠(se abre en una ventana nueva), el sistema de transmisión de mensajes propio de Chromium. Escribimos enlaces Swift (e incluso TypeScript) personalizados para Mojo, de modo que nuestra aplicación Swift pueda llamar directamente a las interfaces del lado del host.

La biblioteca cliente OWL expone una sencilla API pública Swift, que abstrae varios conceptos clave expuestos por la capa de servicio del host:

• Sesión: configurar y controlar el host globalmente
• Perfil: gestionar el estado del navegador para un perfil de usuario específico
• WebView: controlar e integrar contenidos web individuales (por ejemplo, renderizar, introducir información, navegar, ampliar, etc.)
• WebContentRenderer: reenviar eventos de entrada al canal de renderizado de Chromium y recibir comentarios del renderizador
• LayerHost/Client: intercambio de información de composición entre la interfaz de usuario y Chromium.

También hay una amplia gama de puntos finales de servicio para gestionar funciones de alto nivel como marcadores, descargas, extensiones y autocompletar.

Las WebViews, que comparten un espacio de presentación mutuamente excluyente en la aplicación cliente, se intercambian dentro y fuera de un contenedor de composición compartido. Por ejemplo, una ventana del navegador suele tener un único contenedor compartido visible y, al seleccionar una pestaña en la barra de pestañas, se intercambia la WebView de esa pestaña en el contenedor. En el lado de Chromium, este contenedor se corresponde con un gfx::AcceleratedWidget que, en última instancia, está respaldado por un CALayer. Exponemos el ID de contexto de esa capa al cliente, donde un NSView lo incrusta utilizando la API privada CALayerHost.

Los casos especiales, como los menús desplegables o los selectores de color, que Chromium renderiza en widgets emergentes separados, utilizan el mismo enfoque. No tienen un content::WebContents, pero sí tienen un content::RenderWidgetHostView con su propio gfx::AcceleratedWidget, por lo que se aplica el mismo modelo de renderizado delegado.OWL mantiene internamente la geometría de la vista sincronizada con el lado de Chromium, de modo que el compositor de la GPU se puede actualizar en consecuencia y siempre puede producir contenidos de capa del tamaño y la escala de dispositivo correctos.También reutilizamos esta técnica para proyectar selectivamente elementos de la interfaz de usuario nativa de Chromium en Atlas (esto también es útil para iniciar rápidamente funciones como las solicitudes de permiso sin tener que crear sustitutos desde cero en SwiftUI). Esta técnica se basa en gran medida en la infraestructura existente de Chromium para aplicaciones web instalables en macOS.Eventos de entrada: descifrado y reenvíoLa interfaz de usuario de Chromium traduce los eventos de la plataforma (como los NSEvents de macOS) al modelo WebInputEvent de Blink antes de reenviarlos a los renderizadores. Pero como OWL ejecuta Chromium en un proceso oculto, nosotros mismos realizamos esa traducción dentro de la biblioteca cliente Swift y reenviamos los eventos ya traducidos a Chromium.A partir de ahí, siguen el mismo ciclo de vida que seguirían normalmente los eventos de entrada reales para el contenido web. Esto incluye devolver los eventos al cliente cada vez que una página indica que no ha gestionado el evento. Cuando esto ocurre, volvemos a sintetizar un NSEvent y damos al resto de la aplicación la oportunidad de gestionar la entrada.Modo agente: casos especialesLa función de navegación con agente de Atlas plantea algunos retos únicos para nuestros enfoques de renderización, reenvío de eventos de entrada y almacenamiento de datos.Nuestro modelo de uso del ordenador espera una sola imagen de la pantalla como entrada. Pero algunos elementos de la interfaz de usuario, como los menús desplegables , se renderizan fuera de los límites de la pestaña en ventanas separadas. En el modo agente, componemos esas ventanas emergentes de nuevo en la imagen de la página principal en las coordenadas correctas para que el modelo vea el contexto completo en un solo fotograma.

Para la entrada, aplicamos el mismo principio: los eventos generados por el agente se envían directamente al renderizador, nunca a través de la capa privilegiada del navegador. Eso preserva el límite del entorno aislado incluso bajo control automatizado. Por ejemplo, no queremos que esta clase de eventos sintetice atajos de teclado que hagan que el navegador realice acciones no relacionadas con el contenido web que se muestra.

La navegación con agente también puede ejecutarse en un contexto efímero «desconectado». En lugar de compartir el perfil de incógnito existente del usuario, que podría filtrar información, utilizamos la infraestructura StoragePartition de Chromium para crear almacenes aislados en memoria. Cada sesión del agente comienza desde cero y, cuando finaliza, se descartan todas las cookies y los datos del sitio. Puedes ejecutar varias sesiones «desconectadas» del agente, cada una en su propia pestaña del navegador y totalmente aisladas unas de otras.

Nada de esto sería posible sin la comunidad global de Chromium y su increíble trabajo para sentar las bases de la web moderna. OWL se basa en esos cimientos de una forma innovadora: desacoplando el motor de la aplicación, combinando una plataforma web de primer nivel con marcos nativos modernos y desbloqueando una arquitectura más rápida y flexible.

Al replantearnos la forma en que un navegador aloja Chromium, estamos creando espacio para nuevos tipos de experiencias: inicios más fluidos, una interfaz de usuario más rica, una integración más estrecha con el resto del sistema operativo y un ciclo de desarrollo que avanza a la velocidad de las ideas. Si te parece un reto interesante, echa un vistazo a nuestras ofertas de trabajo para trabajar en Atlas como ingeniero de software de Atlas⁠, ingeniero de software de iOS⁠, y mucho más⁠.

Prueba Atlas en chatgpt.com/atlas⁠⁠(se abre en una ventana nueva).