Dentro de nuestra nueva arquitectura de procesos, que le ofrece una forma más rápida e inteligente de usar la web.
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 completo, Atlas ofrece una visión del futuro: un mundo donde puedes llevar ChatGPT contigo por internet para hacer preguntas, 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 convertimos ChatGPT en un navegador que se vuelve más útil con el uso.
Para convertir ChatGPT en un verdadero copiloto para la web, fue necesario reimaginar por completo la arquitectura del navegador: separar Atlas del entorno de ejecución de Chromium. Esto implicó desarrollar una nueva forma de integrar Chromium que nos permite alcanzar nuestros objetivos de producto: inicio instantáneo, capacidad de respuesta incluso al abrir varias pestañas y la creación de una base sólida para casos de uso basados en agentes.
Dando forma a los cimientos
Chromium fue un componente fundamental. Proporciona un motor web de última generación con un modelo de seguridad robusto, un rendimiento comprobado y una compatibilidad web inigualable. Además, lo desarrolla una comunidad global que lo mejora continuamente. Es una opción común para los navegadores web de escritorio modernos.
Repensando la experiencia del navegador
Nuestro talentoso equipo de diseño tenía objetivos ambiciosos para la experiencia de usuario, incluyendo animaciones y efectos visuales sofisticados para funciones como el modo Agente. Esto requirió que nuestro equipo de ingeniería aprovechara los frameworks nativos más modernos para nuestra interfaz de usuario (SwiftUI, AppKit y Metal), en lugar de simplemente modificar la interfaz de usuario de Chromium, de código abierto. Como resultado, la interfaz de usuario de Atlas es una reconstrucción completa de la experiencia de usuario de toda 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 afectar el rendimiento. Lograr estos objetivos era un reto con Chromium en su configuración predeterminada, ya que impone ciertas preferencias en cuanto a detalles como la secuencia de arranque, el modelo de subprocesos y los modelos de pestañas. Consideramos realizar cambios sustanciales, pero queríamos que nuestro conjunto de parches se centrara en Chromium para poder integrar rápidamente nuevas versiones. Para garantizar la máxima aceleración de nuestro desarrollo, necesitábamos encontrar una forma diferente de integrar y controlar el entorno de ejecución de Chromium.
Una prueba decisiva para nuestra inversión tecnológica no solo consistía en que permitiera una experimentación, iteración y entrega de nuevas funcionalidades más rápidas, sino también en que nos permitiera mantener un pilar fundamental de la cultura de ingeniería de OpenAI: el lanzamiento desde el primer día. Cada nuevo ingeniero realiza e integra un pequeño cambio durante la tarde de su primer día. Necesitábamos asegurarnos de que esto fuera posible, incluso aunque Chromium pueda tardar horas en compilarse y probarse.
Nuestra solución: BÚHO
Nuestra respuesta a estos desafíos fue construir una nueva capa arquitectónica que llamamos OWL: OpenAI’s Web Layer . OWL es nuestra integración de Chromium, que implica ejecutar el proceso del navegador Chromium fuera del proceso principal de la aplicación Atlas.
Piénsalo así: Chromium revolucionó los navegadores al separar las pestañas en procesos independientes. Nosotros vamos un paso más allá, trasladando el propio Chromium fuera del proceso principal de la aplicación y a una capa de servicio aislada. Este cambio genera una serie de ventajas:
- Una aplicación más sencilla y moderna: Atlas está desarrollada casi por completo con SwiftUI y AppKit. Un solo lenguaje, una sola pila tecnológica, un código base limpio.
- 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 frente a problemas y fallos: Chromium es un motor web potente y complejo. Si su hilo principal se bloquea, Atlas no. Si falla, Atlas sigue funcionando.
- Menos problemas de fusión: Como no nos basamos tanto en la interfaz de usuario de código abierto de Chromium, nuestra diferencia con respecto a la versión original de Chromium es mucho menor y más fácil 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.
Como 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 incorporar cambios sencillos en su primera tarde.
Cómo funciona OWL
En términos generales, el navegador Atlas es el cliente OWL y el proceso del navegador Chromium es el host OWL . Se comunican a través de IPC, específicamente mediante Mojo . (se abre en una ventana nueva)Mojo es el sistema de mensajería propio de Chromium. Creamos enlaces personalizados en Swift (e incluso TypeScript) para Mojo, de modo que nuestra aplicación Swift pueda llamar directamente a las interfaces del host.
La biblioteca cliente OWL expone una API pública simple en 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: Controla e integra contenidos web individuales (por ejemplo, renderizar, introducir datos, navegar, hacer zoom, etc.).
- WebContentRenderer: Reenvía los eventos de entrada al proceso de renderizado de Chromium y recibe comentarios del renderizador.
- LayerHost/Client: Intercambio de información de composición entre la interfaz de usuario y Chromium.
También existe una amplia gama de puntos de conexión de servicio para gestionar funciones de alto nivel como marcadores, descargas, extensiones y autocompletado.
Renderizado: Obtención de píxeles a través del límite del proceso
Las WebViews, que comparten un espacio de presentación mutuamente exclusivo 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 visible un único contenedor compartido, y al seleccionar una pestaña en la barra de pestañas, la WebView de esa pestaña se muestra en el contenedor. En Chromium, este contenedor corresponde a un WebView gfx::AcceleratedWidgetque, en última instancia, está respaldado por un WebView CALayer. Exponemos el ID de contexto de esa capa al cliente, donde un WebView lo integra mediante la API NSViewprivada .CALayerHost
Los casos especiales, como <select>los menús desplegables o los selectores de color, que Chromium renderiza en widgets emergentes separados, utilizan el mismo enfoque. No tienen un componente `<div>` content::WebContents, pero sí un componente `<div>` content::RenderWidgetHostViewcon su propio componente `<div>` gfx::AcceleratedWidget, por lo que se aplica el mismo modelo de renderizado delegado.
Internamente, OWL mantiene la geometría de la vista sincronizada con la parte de Chromium, de modo que el compositor de la GPU se pueda actualizar en consecuencia y siempre pueda producir contenido de capas del tamaño y la escala del dispositivo correctos.
También reutilizamos esta técnica para proyectar selectivamente elementos de la interfaz de usuario nativa Views de Chromium en Atlas (esto resulta útil para inicializar rápidamente funciones como las solicitudes de permisos sin tener que crear reemplazos 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ío
La interfaz de usuario de Chromium traduce los eventos de la plataforma (como los NSEvents de macOS) al modelo WebInputEvent de Blink antes de enviarlos a los renderizadores. Sin embargo, dado que OWL ejecuta Chromium en un proceso oculto, realizamos esa traducción internamente en la biblioteca cliente de Swift y reenviamos los eventos ya traducidos a Chromium.
A partir de ahí, siguen el mismo ciclo de vida que los eventos de entrada reales para contenido web. Esto incluye la devolución de eventos al cliente cuando una página indica que no los ha procesado. En ese caso, resintetizamos un NSEvent y damos al resto de la aplicación la oportunidad de procesar la entrada.
Modo agente: Casos especiales
La función de navegación agentiva de Atlas plantea algunos desafíos únicos para nuestros enfoques de renderizado, reenvío de eventos de entrada y almacenamiento de datos.
Nuestro modelo de uso del ordenador espera una única imagen de la pantalla como entrada. Sin embargo, algunos elementos de la interfaz, como <select> 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 en la imagen de la página principal, colocándolas 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 dirigen directamente al renderizador, nunca a través de la capa privilegiada del navegador. Esto preserva el límite del entorno aislado incluso bajo control automatizado. Por ejemplo, no queremos que este tipo de eventos sintetice atajos de teclado que hagan que el navegador realice acciones ajenas al contenido web que se muestra.
La navegación del agente también puede ejecutarse en un contexto efímero de «sesión cerrada». En lugar de compartir el perfil de incógnito del usuario, lo que podría revelar información, utilizamos StoragePartitionla infraestructura de Chromium para crear almacenes aislados en memoria. Cada sesión del agente comienza desde cero y, al finalizar, se eliminan todas las cookies y los datos del sitio. Se pueden ejecutar varias sesiones de agente «sin conexión», cada una en su propia pestaña del navegador y completamente aisladas de las demás.
Una nueva forma de usar la web
Nada de esto sería posible sin la comunidad global de Chromium y su increíble trabajo en la creación de las bases de la web moderna. OWL se basa en esas bases de una forma novedosa: separando el motor de la aplicación, combinando una plataforma web de primer nivel con modernos frameworks nativos y desbloqueando una arquitectura más rápida y flexible.
Al replantearnos cómo un navegador gestiona Chromium, estamos creando espacio para nuevas experiencias: inicios más fluidos, interfaces de usuario más ricas, una integración más estrecha con el resto del sistema operativo y un ciclo de desarrollo que avanza al ritmo de las ideas. Si este tipo de reto te interesa, consulta nuestras vacantes para trabajar en Atlas como Ingeniero / a de Software, Ingeniero /a de Software para iOS y más .
Prueba Atlas en chatgpt.com/atlas(se abre en una ventana nueva).
OpenAI News. K. R. Y B. G. Traducido al español
