agentic-systems

2 개의 포스트

github3분 읽기큐레이션 요약

GitHub Copilot CLI가 작업 위임을 더 선별적으로 하도록 만든 방법

GitHub는 Copilot CLI가 단순한 작업까지 불필요하게 서브에이전트에 위임해 발생하던 검색 반복, 도구 실패, 대기 시간을 줄이기 위해 위임 정책을 개선했다. 핵심은 좁고 명확한 작업은 메인 에이전트가 직접 처리하고, 독립적인 탐색·복잡한 조사·병렬 실행이 필요한 경우에만 서브에이전트를 활용하는 것이다. 그 결과 도구 실패가 23% 감소하고 P95 사용자 대기 시간이 5% 줄었으며, 품질 저하 없이 Copilot CLI 전체 트래픽에 적용됐다. ### 서브에이전트 위임은 항상 효율적이지 않다 - 서브에이전트는 복잡한 작업을 분해하고 여러 조사를 병렬로 수행하는 데 유용하다. - 하지만 단순한 파일 수정까지 위임하면 오히려 다음과 같은 비용이 발생한다. - 불필요한 에이전트 간 인계와 조정 - 동일하거나 겹치는 저장소 검색 - 메인 에이전트가 결과를 기다리는 시간 - 오래된 파일 경로, 잘못된 상대 경로, 워크스페이스 불일치에 따른 도구 실패 - 특히 메인 에이전트가 이미 충분한 맥락을 알고 있는데도 탐색 서브에이전트를 실행하면, 서브에이전트가 저장소를 다시 검색하면서 작업이 지연된다. ### 데이터 분석으로 불필요한 위임 패턴 식별 - GitHub는 에이전트의 전체 실행 궤적을 LLM으로 분석해 위임이 실제로 도움이 되는지 확인했다. - 분석 결과, 다음과 같은 작업에 서브에이전트가 과도하게 사용되고 있었다. - 범위가 좁고 명확한 작업 - 필요한 정보가 이미 핸드오프에 포함된 작업 - 파일을 찾고 읽은 뒤 한 곳을 수정하는 작업 - 이를 바탕으로 “간단한 탐색과 수정은 메인 에이전트가 직접 처리한다”는 방향을 개선 목표로 삼았다. ### 좁은 작업은 직접 처리하고 복잡할 때만 위임 - Copilot CLI의 새로운 정책은 가장 간단한 실행 경로에서 시작한다. - 파일 찾기 - 파일 읽기 - 특정 부분 수정 - 변경 사항 검증 - 다음과 같은 경우에는 서브에이전트 위임이 효과적이다. - 익숙하지 않은 대규모 저장소 탐색 - 서로 독립적인 코드 영역 조사 - 장시간 실행되는 명령 수행 - 여러 작업을 동시에 진행할 수 있는 경우 - 작업이 복잡하거나 불확실할 때 위임하고, 다시 작업 범위가 좁아지면 메인 에이전트가 직접 처리하도록 한다. - 서브에이전트는 메인 에이전트를 멈추게 하는 “일시정지 버튼”이 아니라, 독립 작업을 병렬화하는 도구로 사용해야 한다. ### 구체적인 핸드오프와 병렬 실행 - 서브에이전트를 실행할 때는 핸드오프에 다음 내용을 명확히 포함해야 한다. - 사용자가 요청한 전체 목표 - 메인 에이전트가 이미 파악한 정보 - 서브에이전트가 담당할 범위 - 반환해야 하는 결과의 형태 - 메인 에이전트는 서브에이전트의 결과를 기다리기만 하지 않고, 그동안 독립적으로 수행할 수 있는 작업을 계속 진행해야 한다. - 이 방식은 중복 검색과 순차적 대기를 줄이고, 실제로 병렬 처리가 가능한 작업에서 위임의 이점을 높인다. ### 오프라인 평가와 운영 환경 A/B 테스트 - GitHub는 자동 생성 회귀 테스트와 기존 벤치마크를 이용해 정책 변경을 먼저 오프라인에서 검증했다. - 이후 내부 사용자와 공개 사용자를 대상으로 A/B 테스트를 진행했다. - 평가 항목은 다음과 같았다. - 도구 안정성 - 사용자 응답성과 대기 시간 - 서브에이전트 사용량 - 최종 결과 품질 - 성능 향상은 개별 LLM 호출 자체를 빠르게 만든 결과가 아니라, 불필요한 서브에이전트 실행을 줄여 오케스트레이션 비용을 낮춘 결과였다. ### 측정된 개선 효과 - 세션당 도구 실패가 **23% 감소** - 검색 도구 실패: **27% 감소** - 편집 도구 실패: **18% 감소** - 사용자 대기 시간 개선 - P95: **5% 감소** - P75: **3% 감소** - 품질 저하는 관찰되지 않았다. - 개선된 위임 기능은 Copilot CLI 운영 트래픽의 100%에 배포됐다. - 사용자는 `/update` 명령으로 Copilot CLI **1.0.42 이상**으로 업데이트하면 적용된 기능을 사용할 수 있다. 간단한 작업에는 직접 실행을 우선하고, 서브에이전트는 독립성·복잡성·병렬성 때문에 실제 이득이 있을 때만 사용하는 것이 효율적이다. 이를 위해 위임 여부뿐 아니라 핸드오프의 구체성, 메인 에이전트의 병렬 진행 여부까지 함께 설계해야 한다.

원문 읽기(새 탭에서 열림)
microsoft원문

마이크로소프트 규모의 멀 (새 탭에서 열림)

대규모 프로덕션 환경에서 멀티모달 에이전트의 사후 학습(Post-training)은 표준적인 강화학습 알고리즘이 예상하지 못한 지점에서 실패하는 경우가 많으며, 특히 전체 보상 지표가 상승함에도 불구하고 실제 성능은 퇴보하는 '침묵하는 실패'가 빈번하게 발생합니다. Microsoft Copilot 팀은 이러한 문제를 해결하기 위해 정책 경사 추정치(Policy gradient estimator)의 정보력을 유지하는 데 초점을 맞춘 공학적 및 알고리즘적 개입 방법을 개발했습니다. 이를 통해 수백만 명의 사용자를 대상으로 하는 복잡한 도구 조작 및 멀티모달 추론 태스크에서 성능 안정성과 모델의 견고성을 확보할 수 있었습니다. ### 단계적 목적 함수 커리큘럼을 통한 조기 전문화 방지 * **문제점**: 단순한 스칼라 보상을 최적화할 경우, 모델은 달성하기 쉬운 지표에만 매몰되어 장기 실행 능력이나 견고성이 필요한 복잡한 행동을 포기하는 조기 전문화(Premature specialization) 현상이 나타납니다. * **검증 및 선호 신호 분리**: 보상 신호를 '검증 가능 신호(도구 구문, 형식 준수 등)'와 '선호도 신호(품질 등)'로 분리하고, 학습 초기 30% 구간에서는 검증 가능 신호에만 집중하여 기본기를 다지게 합니다. * **엔트로피 하한선(Entropy Floor)**: 단순한 엔트로피 보너스 대신, 정책의 엔트로피가 특정 임계값 아래로 떨어질 때만 활성화되는 KL 페널티 형태의 '하한선'을 도입하여 학습 후반부까지 정책의 다양성을 강제로 유지합니다. ### 추정치 건강도에 따른 적응형 커리큘럼 * **ESS(유효 샘플 크기) 모니터링**: 전체 배치 중 실제로 유의미한 그래디언트 업데이트에 기여하는 궤적의 비율인 ESS를 실시간으로 추적합니다. ESS가 20% 미만으로 떨어지면 향후 학습 정체가 일어날 것임을 미리 예측할 수 있습니다. * **근접 실패(Near-miss) 주입**: ESS 수치가 위험 수준에 도달하면 저장소 버퍼에서 '근접 실패' 궤적을 학습 배치에 주입합니다. 이는 모델이 정답과 오답 사이의 미세한 차이를 학습하게 하여 배치 내 결과의 대비(Contrast)를 복구합니다. * **동적 KL 페널티 조절**: 추정치의 건강도가 낮아질 때 일시적으로 KL 페널티를 높여 정책의 급격한 변화를 방지하고, 에스티메이터가 회복될 시간을 확보합니다. ### 구조적 변산성을 고려한 분산 교정 정규화 * **문제점**: 표준적인 태스크별 정규화는 태스크 내의 변산성 구조를 무시합니다. 특히 100토큰 내외의 짧은 궤적과 2000토큰 이상의 긴 궤적 사이에는 거대한 분산 차이가 존재하며, 긴 궤적이 전체 그래디언트 신호를 왜곡하는 현상이 발생합니다. * **길이 기반 보정**: 궤적의 길이에 따라 변산성이 선형적으로 증가하는 특성을 반영하여 정규화 로직을 개선함으로써, 특정 유형의 작업이 전체 학습 방향을 독점하지 않도록 조정합니다. 실제 운영 환경에서의 AI 에이전트 학습은 대시보드상의 요약 지표와 실제 사용자 경험 사이의 괴리를 줄이는 것이 핵심입니다. 특히 ESS와 같은 추정치 건전성 지표를 상시 모니터링하고, 학습 초기 단계에서 모델이 기본 형식을 먼저 마스터할 수 있도록 보상 신호의 투입 시점을 제어하는 전략이 대규모 멀티모달 시스템의 안정적인 배포에 결정적인 역할을 합니다.