Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
컴퓨터 사용 에이전트가 스크린샷에만 의존하는 대신, OS의 접근성 트리(Accessibility Tree)를 활용하여 효율성을 높이는 방안을 제시합니다. 트리를 통한 결정론적 조회를 우선시하면 속도와 비용 측면에서 큰 이점을 얻을 수 있습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 r/OpenAI Codex (search)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기컴퓨터 사용 (computer use) 능력이 시각적 품질 (vision quality)에 의해 병목 현상을 겪고 있다는 견해는 대체로 맞지만, 더 저렴한 해결책을 간과하고 있다고 생각합니다. 에이전트가 데스크톱에서 수행하는 대부분의 작업은 버튼을 찾아 클릭하는 것이며, Windows와 Mac에서는 접근성 트리 (accessibility tree)가 이미 이름과 역할 (role)을 포함하여 해당 요소를 노출하고 있습니다. 전체 화면을 스크린샷으로 찍고 모델에게 픽셀 공간 (pixel space)에서 버튼을 찾도록 요청하는 것은, OS가 이미 구조적으로 해결한 문제에 대해 시각 기능 (vision) 비용을 지불하는 것과 같습니다.
우리는 AX/UIA 트리를 먼저 읽고, 요소를 진정으로 해결할 수 없을 때만 모델 호출로 넘어가는 자동화 시스템을 구축하며 이 길을 걸어왔습니다. 놀라웠던 점은 정확도가 아니라 속도였습니다. 결정론적 트리 조회 (deterministic tree lookups)는 CPU 속도로 실행되므로, 모델이 매 단계마다 실행 루프 (hot loop)에 머물지 않고 복구 작업 시에만 나타나게 됩니다.
읽을 수 있는 트리가 없는 캔버스 앱 (canvas apps), 게임, 커스텀 드로잉 UI (custom-drawn UIs)의 경우 시각 기능 (vision)은 여전히 제 역할을 다합니다. 제가 계속 고민하는 부분은 그 경계선이 실제로 어디에 있느냐 하는 것입니다. Operator 스타일의 에이전트가 충분히 저렴해지면, 사람들이 트리를 읽으려 할까요, 아니면 트리 API가 더 친숙해지는 속도보다 토큰 가격이 더 빠르게 하락하기 때문에 단순히 원시 시각 기능 (raw vision)으로 무차별 대입 (brute-force)하게 될까요.
submitted by /u/Deep_Ad1959 to r/OpenAI
[link] [comments]