마이크로소프트 MagenticLite 공개 — 소형 모델 기반 에이전트와 컴퓨터 조작 모델 Fara 1.5

핵심 메시지

• 마이크로소프트 리서치가 소형 언어 모델에 맞춰 다시 만든 에이전트 MagenticLite와 이를 움직이는 두 모델을 함께 공개했다. 기존 Magentic-UI의 다음 세대라는 설명이다.
• 오케스트레이터 모델은 계획 수립과 코드 작성, 하위 에이전트 위임을 한 모델이 맡는다. 흔히 가장 큰 모델을 쓰는 자리인데, 작은 모델로도 가능하다는 것을 보이려 했다는 설명이다.
• 오케스트레이터 학습은 다단계 기법 없이 평범한 지도 미세조정으로 이뤄졌고, 대신 도구 호출 데이터와 터미널 작업 데이터를 적절한 비율로 섞는 데이터 배합이 핵심이었다고 밝혔다.
• 컴퓨터 조작 모델 Fara 1.5는 4B, 9B, 27B 세 규모로 나왔고, 발표에 따르면 온라인 벤치마크에서 9B 모델이 이전 세대 7B의 35%에서 65% 가까이로 성능을 끌어올렸다.
• 학습 데이터는 사람의 조작 기록 없이 합성으로 생성한다. 실제 웹과 합성 웹사이트를 환경으로 두고 교사 에이전트가 과제를 수행한 뒤, 정확성과 효율성과 사용자 안전성을 각각 심사해 통과한 것만 학습에 쓴다.

쉽게 이해하기

마이크로소프트 리서치의 AI 프런티어 랩이 연구 포럼 세션에서 MagenticLite를 공개했다. 지난해 내놓은 에이전트 애플리케이션 Magentic-UI의 다음 세대로, 에이전트 하네스를 소형 언어 모델 위에서 효율적으로 돌아가도록 다시 짰다는 것이 핵심이다. 발표팀은 브라우저와 로컬 파일 시스템을 하나의 작업 흐름 안에서 다루면서도 매 단계에서 사용자가 통제권을 쥐도록 설계했다고 설명했다.

데모에서는 사용자가 지정한 폴더의 회의 노트를 읽어 할 일을 정리하고, 가상 머신 안에서 돌아가는 자체 브라우저로 자료를 모아 문서를 작성하는 과정이 이어졌다. 브라우저를 격리된 환경에 두는 이유로는 데이터 유출 위험을 줄이기 위해서라고 밝혔다. 이메일 발송 단계에서 로그인이 필요해지자 에이전트가 작업을 멈추고 사용자를 호출했고, 사용자가 브라우저를 넘겨받아 로그인한 뒤 작업이 이어졌다.

시스템을 묶는 것은 오케스트레이터 모델이다. 치과 예약을 잡고 일정에 넣어 달라는 식의 뭉뚱그린 요청을 구체적인 계획으로 바꾸고, 단계마다 알맞은 도구나 하위 에이전트를 고르며, 코드가 답인 상황에서는 직접 코드를 쓰고, 중간에 실패하면 복구한다. 발표자는 이 자리에 보통 가장 큰 모델을 쓰지만 작은 모델로 밀어 넣어도 능력을 포기하지 않을 수 있음을 보이고 싶었다고 말했다.

학습 방식은 의외로 단순하다. 화려한 다단계 기법 없이 평범한 지도 미세조정을 썼고, 성패를 가른 것은 데이터 배합이었다는 설명이다. 한쪽은 도구를 파이썬 객체로 정의해 그래프의 노드로 삼고 그 위의 경로 하나를 하나의 다중 턴 궤적으로 만드는 방식으로 생성한 도구 호출 데이터이고, 다른 한쪽은 터미널에서 생각하고 명령을 실행하고 결과를 읽어 다음을 정하는 코딩 작업 궤적이다. 도구 호출만 배운 모델은 모든 문제를 도구로 밀어붙이려 하기 때문에, 두 유형을 섞어야 언제 무엇을 꺼낼지 배운다고 했다.

브라우저를 직접 조작하는 모델은 Fara 1.5다. 화면을 캡처해 과거 스크린샷과 행동, 사용자 메시지와 함께 문맥에 넣고 다음 행동을 예측하는 구조이며, 좌표 클릭과 키 입력 같은 조작에 더해 수백 단계에 걸쳐 사실을 기억하는 도구와 사용자에게 승인이나 선호를 묻는 도구를 갖췄다. 데이터는 실제 웹과 합성 웹사이트를 환경으로 두고 교사 에이전트와 사용자 시뮬레이터가 과제를 풀게 한 뒤, 과제를 제대로 수행했는지와 얼마나 효율적이었는지, 정보를 지어내거나 되돌릴 수 없는 행동을 사람 확인 없이 했는지를 각각 심사해 걸러 낸다.

주요 인사이트

• 이 발표의 초점은 모델 크기가 아니라 스택 전체의 재설계에 있다. 데이터 생성부터 모델 설계, 하네스 오케스트레이션, 사용자 경험까지 함께 손대야 작은 모델로 실제 업무가 굴러간다는 주장이다.
• 오케스트레이션을 작은 모델로 내리려는 시도가 의미 있는 이유는 비용 구조 때문이다. 계획과 복구는 실패 비용이 커서 가장 큰 모델을 쓰기 쉬운 자리인데, 이 부분이 작아지면 전체를 로컬에서 돌릴 여지가 생긴다.
• 데이터 배합이 곧 능력의 경계라는 점이 분명하게 드러난다. 도구 호출만 학습한 모델은 깔끔한 도구가 없는 요청까지 도구로 처리하려 들기 때문에, 코드로 푸는 습관을 따로 가르쳐야 한다.
• 합성 데이터 파이프라인에서 검증기의 설계가 결과 품질을 좌우한다. 정확성뿐 아니라 최단 경로로 갔는지, 사용자 안전을 해쳤는지까지 나눠 심사한 궤적만 학습에 넣는 구조다.
• 벤치마크보다 실제 쓰임을 먼저 정하고 평가를 직접 만들었다는 대목이 눈에 띈다. 사람들이 실제로 원하는 과제를 먼저 정하고 그에 맞춘 평가로 개선 신호를 얻었다는 것이 팀의 설명이다.

자주 묻는 질문

관련 AI 소식