[한영자막] 스스로 개선되는 AI 에이전트는 어떻게 만들었을까요? | Weights & Biases

한 줄 핵심

ARIA를 프로덕션 트레이스와 오프라인 평가를 하나의 플라이휠로 연결해 스스로 개선하는 에이전트로 만들기 위해, 동일한 하네스·샌드박스·평가 파이프라인을 운영하는 방법을 설명한다.

시간별 요약

1. 0:00
   도입: 에이전트 ARIA 구축 Weights & Biases에서 출시한 ARIA 에이전트와, 이를 평가·개선하는 전체 프레임워크를 소개한다. 핵심은 ARIA가 자기 연구를 수행하며 스스로 성능을 끌어올리는 구조다.
2. 0:34
   자체 에이전트 하네스를 구축하는 이유 에이전트의 도구 호출 방식과 패키징에 따라 성능이 크게 달라지므로, 단순히 모델을 풀어두는 방식보다 별도의 하네스가 필요하다. 연구용 에이전트를 플랫폼 안에서 안정적으로 돌리기 위해 자체 하네스를 만든다.
3. 1:14
   벤치마크, 평가, 에이전트의 공변성 문제 벤치마크, 평가, 에이전트 설정은 서로 공변하므로 하나만 고정해 두고 나머지를 바꾸면 측정이 흔들린다. 따라서 프로덕션과 오프라인 환경 모두에서 실제 성능을 같은 기준으로 재야 한다.
4. 1:49
   프로덕션 및 오프라인 트레이싱을 위한 Weave Weave를 에이전트 관측 플랫폼으로 활용해 오프라인 시뮬레이션과 프로덕션 트레이스를 같은 형식으로 기록한다. 이렇게 모은 트레이스를 서로 이동시키며 오류를 고치고 성능을 올리는 플라이휠을 만든다.
5. 2:39
   라이브 데모: ARIA의 자체 자동 연구 수행 ARIA에게 자기 자신을 개선할 연구를 맡기고, 코드베이스·평가 프레임워크·프로덕션 트레이스를 바탕으로 새 변형을 찾게 한다. 실행과 평가에는 시간이 걸리지만, 결과는 Weave에 축적되어 이후 개선에 재사용된다.
6. 3:23
   프로덕션 트레이스를 평가 태스크로 전환하기 프로덕션에서 관측된 실제 대화를 오프라인 평가 태스크로 가져와 동일한 기준으로 다시 실행한다. 이를 통해 실제 문제를 그대로 재현하고, 후보 에이전트와 현재 에이전트를 비교해 개선점을 찾는다.
7. 4:33
   야간 CI 평가 파이프라인 매일 밤 CI 잡을 돌려 프로덕션 형식의 에이전트와 후보 변형을 반복 평가한다. 시간이 지나며 성능 추이를 비교할 수 있고, CI가 깨졌을 때도 빠르게 원인을 찾을 수 있다.
8. 4:58
   시뮬레이션 환경 구축하기 강화학습식 접근보다 프롬프트 엔지니어링과 스킬 개선이 더 중요한 시점이므로, 에이전트가 연습할 수 있는 시뮬레이션 환경을 만든다. 환경을 잘 설계해야 실제 업무 능력도 안정적으로 끌어올릴 수 있다.
9. 5:33
   프로덕션과 연구 환경의 동일한 에이전트 유지 연구용 코드와 프로덕션 코드가 완전히 같도록 설계하고, 4시간 동기화 작업으로 드리프트를 막는다. 덕분에 배포 환경과 오프라인 벤치마크 환경에서 같은 에이전트를 같은 방식으로 비교할 수 있다.
10. 6:23
    대규모 트레이스 수집과 패턴 분석 많은 트레이스를 모은 뒤, 그 안에서 반복되는 행동 패턴과 실패 패턴을 수동 분석하거나 에이전트 스스로 검토하게 한다. 핵심은 데이터를 많이 쌓고, 그 데이터에서 무엇을 강화할지 정하는 일이다.
11. 6:58
    모델 독립적 하네스와 YAML 기반 변형 관리 특정 모델에 종속되지 않도록 하네스를 설계해 여러 모델을 같은 방식으로 비교한다. 설정은 YAML로 분리해 여러 변형을 병렬로 실험하고, 더 많은 실험을 통해 더 나은 통찰을 얻는다.
12. 7:47
    제약 없는 샌드박스 환경 에이전트가 병렬 실행이나 자기 연구 루프 같은 새로운 행동을 스스로 시도할 수 있도록 제약이 적은 샌드박스를 둔다. 자유도가 높을수록 예상치 못한 유용한 행동이 나타날 가능성이 커진다.
13. 8:37
    평가 파이프라인 아키텍처 YAML 설정을 불러오고, 환경을 준비하고, 필요 시 런타임 데이터를 다시 주입한 뒤, 에이전트를 실행하고 점수화하는 DAG 구조를 사용한다. 이 중 가장 중요한 부분은 결과를 얼마나 견고하게 측정하느냐이다.
14. 9:57
    평가 점수화: 절대 평가와 상대 평가 평가는 과제를 통과했는지 보는 절대 평가와, 두 변형 중 어느 쪽이 더 나은지 보는 상대 평가로 나뉜다. 병렬 평가를 돌린 뒤에는 자원 충돌을 막기 위해 반드시 정리 단계가 필요하다.
15. 10:37
    YAML 기반 886개 평가 태스크 평가 태스크는 사용자 흐름을 흉내 낸 여러 시나리오로 구성되며, 단일 지시문·멀티턴 대화·사용자 페르소나 시뮬레이션으로 나뉜다. 현재는 886개의 태스크를 수준별로 관리하며 팀과 공유해 타당성을 검토한다.
16. 11:46
    실행 궤적(Trajectory)과 평가 플라이휠 프로덕션과 오프라인에서 생성된 실행 궤적이 개선의 핵심 데이터가 된다. 성공 사례와 실패 사례를 모두 태스크로 바꿔 다시 돌리는 구조가 평가 플라이휠을 만든다.
17. 12:36
    데모 결과: ARIA가 스스로 버그를 해결한 방식 ARIA는 프로덕션 트레이스를 평가 태스크로 바꾸고, 문제의 원인이 된 SDK 호출 오류를 찾아 수정 방향까지 제안한다. 이후 여러 변형을 돌려 후보와 프로덕션의 차이를 비교하며 자기 개선을 수행한다.
18. 14:26
    인간의 루프 참여와 시스템 개선 집중 자동화가 강력해도 개선 방향을 설계하는 판단은 인간의 몫으로 남는다. 도구가 자기 자신을 개선하게 만들면, 사람은 반복 작업 대신 시스템을 더 좋게 만드는 설계에 집중할 수 있다.
19. 16:05
    마무리 및 요약 프로덕션에서 수집한 트레이스를 시뮬레이션으로 옮기고, 같은 에이전트를 오프라인에서 다시 평가해 개선하는 구조가 핵심이다. 결국 좋은 에이전트는 관측, 평가, 개선이 하나의 루프로 연결될 때 만들어진다.

실무 인사이트

• 프로덕션 트레이스를 곧바로 오프라인 태스크로 전환하는 체계를 만들면, 실제 사용자 문제를 빠르게 재현하고 개선 속도를 높일 수 있다.
• 연구용과 프로덕션용 에이전트를 분리하지 말고 코드와 설정을 최대한 동일하게 유지해야 평가 드리프트를 줄일 수 있다.
• 평가 품질은 태스크 수보다 측정 설계에 달려 있으므로, 절대 평가와 상대 평가를 함께 운영해 변형 간 차이를 안정적으로 비교해야 한다.