AutoSynthData: 엔터프라이즈 에이전트를 위한 학습 데이터 생성, 실패를 커리큘럼으로 전환하다

ServiceNow CoreAI는 10월 2일 AutoSynthData를 공개하며, 두 건의 엔터프라이즈 에이전트 실험에서 약 4,000개의 합성 과제를 통해 성과를 거뒀다고 발표했다. AutoSynthData: 엔터프라이즈 에이전트를 위한 학습 데이터 생성은 모델 실패에서 출발해, 이러한 약점을 실행 가능하고 검증 가능한 학습 사례로 전환한다. 충돌 지점은 분명하다. 합성 데이터는 빠르게 규모를 키울 수 있지만, 생성된 과제가 잘못된 행동을 학습시킬 수도 있다.

이 때문에 AutoSynthData는 모델에게 프롬프트를 만들어 달라고 요청하는 또 하나의 시스템 이상이다. 이 접근법은 대상 에이전트와 그 운영 환경, 그리고 더 강력한 교사 모델을 중심으로 폐쇄형 학습 루프를 구축하려 한다. 승인된 모든 과제에는 초기 시스템 상태, 사용자 요청, 성공적인 궤적, 최종 상태를 평가하는 검증기가 포함된다.

ServiceNow는 이 접근법이 두 EnterpriseOps Gym 도메인에서 Gemma 대상 모델의 성능을 개선했다고 밝혔다. 다만 이러한 성과는 커리큘럼을 구성한 동일한 벤치마크 계열 내의 통제된 실험에서 나왔다. 이 결과는 정적이고 사람이 작성한 데이터세트에 의존하는 팀에 압박을 가하는 한편, 외부 환경으로의 전이와 실제 운영 신뢰성은 여전히 미해결 과제로 남긴다.

AutoSynthData: 엔터프라이즈 에이전트를 위한 학습 데이터 생성은 실패에서 시작한다

핵심 변화는 ServiceNow가 에이전트 실패를 다음에 생성할 학습 데이터에 대한 지침으로 다룬다는 점이다.

전통적인 합성 데이터 파이프라인은 대개 주제, 템플릿 또는 시드 사례에서 출발한다. 이러한 입력을 더 큰 컬렉션으로 확장하고, 결과를 필터링한 뒤, 살아남은 샘플을 학습에 사용한다. 이 과정은 새 데이터가 모델의 실제 약점을 해결한다는 증거 없이도 규모를 만들어낼 수 있다.

AutoSynthData는 이 순서를 뒤집는다. 먼저 운영 환경 안에서 대상 모델을 평가하고, 모델이 실패하는 지점을 분석한다. 더 강력한 교사 모델은 같은 진단 과제를 시도하며, 실패한 행동과 성공한 행동을 비교할 수 있게 한다.

이 시스템은 관련 역량, 필요한 도구, 워크플로 구조, 그리고 성공으로 간주되는 최종 상태를 분석한다. 또한 핵심 역량을 훼손하지 않으면서 변경할 수 있는 세부 사항도 식별한다. 이러한 관찰은 ServiceNow가 정제된 역량 명세 카드라고 부르는 형태가 된다.

이 카드는 원래 평가 프롬프트, 엔터티, 궤적 또는 검증기 세부 정보를 노출하지 않고 생성을 안내한다. 이러한 분리는 직접적인 벤치마크 유출을 줄이기 위한 것이다. 또한 생성기가 시험 문제를 단순히 바꿔 쓰는 대신 새로운 상황을 만들도록 강제한다.

과제 형식은 서로 연결된 세 부분으로 구성된다. 시스템 명세는 정책, 사용 가능한 작업, 초기 환경 상태를 정의한다. 사용자 프롬프트는 요청된 결과를 명시하고, 검증기는 에이전트가 허용 가능한 최종 상태에 도달했는지 판단한다.

이 구조가 중요한 이유는 엔터프라이즈 업무가 텍스트 답변으로 끝나는 경우가 드물기 때문이다. IT 서비스 에이전트는 인시던트를 검토하고, 권한을 확인하고, 레코드를 업데이트하며, 감사 추적을 보존해야 할 수 있다. 유창한 응답만으로는 이러한 작업이 올바르게 수행됐다는 사실을 증명할 수 없다.

AutoSynthData 출시 발표는 두 가지 생성 단계를 설명한다. 대상 단계는 식별된 역량 격차를 중심으로 구축된 핵심 사례를 생성하고 검증한다. 증식 단계는 승인된 대상 샘플에서 새로운 변형을 만든다.

각 변형에는 자체 요청, 엔터티, 초기 상태, 참조 궤적, 검증기가 부여된다. 증식된 샘플은 다른 증식 샘플의 시드가 될 수 없다. 이 제한은 여러 세대의 합성 확장이 검증된 핵심에서 벗어나는 것을 방지하도록 설계됐다.

이 파이프라인은 중앙 생성 제어와 환경별 실행을 분리한다. 컨트롤러는 범위, 품질 검사, 데이터세트 구성을 관리한다. 어댑터는 도구를 실행하고, 상태를 관리하며, 참조 솔루션을 재생하고, 에이전트를 평가하고, 결정론적 검증을 적용한다.

이러한 분리는 접근법이 하나의 벤치마크를 넘어설 수 있는 경로를 제공한다. 기업은 이론적으로 공통 컨트롤러를 유지하면서 자체 시스템용 어댑터를 작성할 수 있다. 하지만 모든 새 어댑터에는 정확한 도구, 현실적인 상태 전이, 신뢰할 수 있는 성공 기준이 필요하다.

따라서 이 소식의 핵심은 ServiceNow가 단순히 합성 과제를 생성했다는 데 있지 않다. 이 회사는 현재 모델의 약점에 따라 과제를 선택하는 프로세스를 구축했다. 이후 그 약점이 변함에 따라 학습 목표도 함께 이동시킨다.

이 적응형 루프는 정적 데이터세트 개발에 도전장을 던진다. 모델이 고정된 컬렉션의 대부분을 해결하면 그 가치는 낮아진다. 반면 AutoSynthData는 사례가 여전히 어렵지만 학습 가능한 모델의 현재 역량 경계 부근을 탐색한다.

이 아이디어는 평가 실패가 의미하는 바도 바꾼다. 실패는 단순한 점수나 버그 보고서에 그치지 않고, 사후 학습을 위한 원재료가 된다. 같은 환경이 약점을 진단하고, 표적화된 연습 문제를 생성하며, 업데이트된 모델을 테스트할 수 있다.

이 루프가 AutoSynthData: 엔터프라이즈 에이전트를 위한 학습 데이터 생성의 핵심 주장이다. ServiceNow는 아직 이것이 서로 무관한 엔터프라이즈 환경 전반에서 작동한다는 점을 입증하지는 못했다. 그럼에도 무차별적인 합성 데이터 확장에 대한 구체적인 대안을 제시했다.

정적 에이전트 데이터세트는 이제 움직이는 목표에 직면한다

AutoSynthData는 각 샘플이 빠진 역량을 가르치는지 측정하지 않은 채 광범위한 학습 데이터를 수집하는 팀에 압박을 가한다.

엔터프라이즈 에이전트 개발자는 어려운 데이터 문제에 직면한다. 운영 레코드에는 유용한 워크플로 패턴이 담겨 있지만, 개인정보, 기밀 비즈니스 데이터, 일관되지 않은 결과도 포함할 수 있다. 사람이 작성한 과제는 일부 개인정보 우려를 피할 수 있지만, 충분히 다양하고 검증 가능한 사례를 만드는 일은 비용이 많이 든다.

합성 데이터는 규모를 제공하지만, 규모만으로는 적절한 학습 내용을 고르지 못한다. 이미 비밀번호 재설정 요청을 처리할 수 있는 모델은 수천 건의 유사 사례에서 얻는 것이 거의 없다. 이 모델에는 정책 확인, 다중 시스템 계획, 안전한 거절과 같은 미해결 문제를 드러내는 과제가 필요하다.

EnterpriseOps Gym은 ServiceNow의 실험에 사용된 통제된 환경을 제공한다. 해당 벤치마크 논문은 에이전트가 도구 전반에서 추론하고, 기저 시스템을 올바른 상태로 남겨야 하는 상태 기반 과제를 설명한다. 이는 최종 텍스트 응답만 채점하는 벤치마크와 다르다.

ServiceNow는 EnterpriseOps Gym이 8개 비즈니스 도메인을 포괄한다고 설명한다. 관련 환경에는 512개의 기능적 도구와 164개의 상호 연결된 데이터베이스 테이블이 포함된다. 이러한 리소스는 IT 서비스 관리, 고객 서비스, 인사 등을 아우르는 워크플로를 지원한다.

ServiceNow에 따르면 더 넓은 벤치마크에는 1,150개의 엔터프라이즈 과제가 포함된다. 이 과제들은 연결된 시스템 전반의 계획 수립, 정책 준수, 상태 변경을 테스트한다. 공개 데이터세트는 외부 연구자에게도 벤치마크 자료를 제공한다.

이러한 수치는 표적 생성이 중요한 이유를 보여준다. 하나의 워크플로는 여러 도구, 레코드, 정책, 종속성을 결합할 수 있다. 초기 상태의 작은 변화도 어떤 순서가 유효한지, 또는 요청된 작업이 애초에 수행돼야 하는지를 바꿀 수 있다.

ServiceNow는 이전에 전문가 과제 계획을 제공했을 때 어려운 엔터프라이즈 도메인에서 성능이 15%에서 35% 향상됐다고 보고했다. 이 결과는 에이전트가 개별 도구를 올바르게 호출할 수 있어도 계획 수립이 여전히 주요 제약임을 시사한다. AutoSynthData는 이러한 계획 격차를 반복적인 학습 기회로 전환하려 한다.

첫 번째 압박은 정적 평가 팀에 가해진다. 고정된 테스트 세트는 약점을 식별할 수 있지만, 이를 해결하는 커리큘럼을 자동으로 만들지는 않는다. 연구자들은 여전히 실패를 다양한 사례, 유효한 솔루션, 신뢰할 수 있는 채점 로직으로 전환해야 한다.

두 번째 압박은 범용 모델 제공업체에 가해진다. 강력한 벤치마크 평균은 지역 정책, 테이블 구조, 워크플로 규칙으로 인한 실패를 가릴 수 있다. 기업에는 모델이 단지 자체 시스템에 관한 질문에 답하는 것이 아니라, 그 시스템 안에서 작동할 수 있다는 증거가 필요하다.

세 번째 압박은 에이전트 플랫폼을 구축하는 기업에 가해진다. 적응형 학습이 유용하다는 점이 입증되면, 평가 인프라는 최종 품질 관문이 아니라 모델 개발의 일부가 된다. 플랫폼에는 재현 가능한 환경, 과제 생성, 실행 로그, 상태 기반 검증이 필요해진다.

이러한 요구는 운영 시뮬레이터나 디지털 트윈을 보유한 조직에 유리하다. Salesforce는 시뮬레이션된 엔터프라이즈 환경에서 비즈니스 워크플로에 대한 에이전트를 평가하는 CRMArena-Pro를 통해 유사한 방향을 추진해 왔다. 이러한 중첩은 실행 가능하고 환경에 기반한 에이전트 테스트로의 더 광범위한 이동을 시사한다.

다만 두 경로는 동일하지 않다. 벤치마크는 모델을 수정하지 않고도 비교할 수 있지만, AutoSynthData는 벤치마크 실패를 활용해 사후 학습 데이터를 생성한다. 하나는 역량을 측정하고, 다른 하나는 이를 향상시키려 한다.

이 구분은 엔터프라이즈 구매자에게 중요하다. 리더보드는 명시된 조건에서 가장 강력한 모델을 식별한다. 적응형 커리큘럼은 더 저렴하거나 작은 대상 모델이 조직의 반복적인 자체 과제에서 개선될 수 있는지를 묻는다.

ServiceNow가 보고한 결과는 이 가능성을 구체화하지만, 아직 결론이 난 것은 아니다. 대상 모델은 학습 후에도 IT 서비스 과제의 소수만 완료했다. 기준선보다 나아졌다는 것은 감독 없는 운영 접근에 준비됐다는 뜻이 아니다.

지식 품질 역시 현실적인 제약으로 남는다. 에이전트는 누락됐거나, 모순되거나, 접근할 수 없는 정책을 따를 수 없다. 검색 가능한 지식 베이스를 구축하는 팀도 생성된 학습 과제가 실제 업무를 반영하기 전에 명확한 소스 자료를 갖춰야 한다.

따라서 AutoSynthData는 병목을 제거하기보다 이동시킨다. 팀은 사람이 직접 작성해야 하는 변형의 수를 줄일 수 있지만, 신뢰할 수 있는 환경과 정밀한 검증이 필요하다. 에이전트가 고객, 직원 또는 인프라 레코드를 변경할 수 있는 상황에서는 이 교환이 결정적이 된다.

이 메커니즘은 실행 가능한 과제와 엄격한 검증기에 의존한다

AutoSynthData는 생성된 요청, 참조 솔루션, 검증기가 성공의 의미에 합의할 때만 작동한다.

이 파이프라인은 대상 모델과 더 강력한 교사 모델을 구분하는 과제를 식별하는 것으로 시작한다. 보고된 구성에서 ServiceNow는 대상 모델이 세 번의 시도에서 한 번 이하로 해결한 후보를 우선한다. 더 강력한 해결 모델은 세 번의 시도 중 최소 두 번 완료해야 한다.

이 필터는 유용한 난이도 구간을 목표로 한다. 두 모델 모두 해결하지 못하는 과제는 신뢰할 수 있는 시연을 제공하지 못한다. 두 모델 모두 일관되게 해결하는 과제는 명확한 약점을 겨냥하지 않은 채 학습 용량을 소모한다.

후보가 파이프라인에 들어오면 AutoSynthData는 그 참조 궤적을 실행한다. 궤적은 요청된 상태에 도달하기 위해 사용되는 도구 호출과 작업의 순서다. 이후 검증기는 과제의 성공 조건에 따라 결과를 검사한다.

이 긍정적 검사는 의도한 솔루션이 실제로 작동하는지 묻는다. 이는 유효하지 않은 초기 상태, 사용할 수 없는 도구, 깨진 작업 순서, 또는 요청과 검증기 사이의 불일치를 드러낼 수 있다. 그럴듯해 보이는 사례라도 실행을 견디지 못하면 실패한다.

파이프라인은 부정 검증도 수행한다. 예상 결과를 변형하고, 잘못된 상태가 통과하지 않는지 확인한다. 이 단계는 약한 검증기가 필수 작업을 건너뛰거나 중요한 제약을 위반한 에이전트에 보상을 줄 수 있기 때문에 중요하다.

영향을 받은 직원에게 해결을 확인한 뒤에만 IT 인시던트를 종료해 달라는 요청을 생각해 보자. 인시던트 상태만 확인하는 검증기는 안전하지 않은 지름길을 허용할 수 있다. 더 강력한 검증기는 확인 기록과 필수 메모도 요구해야 한다.

여러 해법이 유효할 때도 같은 문제가 나타난다. 검증기는 하나의 정확한 참조 순서를 요구하지 않으면서 허용 가능한 결과를 인식해야 한다. ServiceNow는 이를 요청과의 일관성 및 잘못된 행동의 적절한 거부와 함께 완전성의 문제로 설명한다.

이러한 요구사항은 어려운 균형을 만든다. 지나치게 관대한 검증기는 불완전한 작업에 보상한다. 지나치게 협소한 검증기는 정당한 전략에 불이익을 주고 모델이 임의의 순서를 모방하도록 학습시킨다.

실패한 후보는 제한된 비평 및 복구 루프에 들어간다. 비평가는 작업 구성, 초기 상태, 해법, 검증 로직을 검토한다. 시스템은 표적 수정 사항을 적용하고 관련 게이트를 다시 실행한 뒤 수정된 후보를 수용하거나 거부한다.

기존 후보를 복구하면 유용한 작업을 보존할 수 있다. 또한 한 구성 요소에 수정 가능한 결함이 있을 때마다 생성을 처음부터 다시 시작하지 않아도 된다. 재시도 한도는 시스템이 수익이 낮은 작업군에 무제한의 리소스를 쓰지 않도록 한다.

그런 다음 AutoSynthData는 전체 배치의 품질을 검토한다. 개별적으로 유효한 예제도 반복적인 데이터셋을 형성할 수 있다. 생성기는 정책, 도구 또는 시스템 상태의 어려운 조합을 무시한 채 익숙한 워크플로를 과도하게 생성할 수 있다.

컨트롤러는 수용 및 거부된 샘플, 반복 패턴, 역량 커버리지, 반복적으로 나타나는 비평 결과를 추적한다. 과도하게 대표된 영역에서는 생성을 줄이고, 부족한 부분으로 노력을 재배치한다. 이는 개별 작업 수준을 넘어선 피드백을 만든다.

target 및 multiply 단계는 이 전략을 뒷받침한다. target 샘플은 특정 역량 공백 주변에서 검증된 작업군을 구축한다. multiply 샘플은 이전 변형을 재귀적으로 확장하지 않으면서 표현, 엔터티, 도구 조합, 환경 상태를 달리한다.

이 설계는 합성 데이터의 흔한 위험 하나를 줄인다. 재귀적 생성은 새 샘플이 다른 생성 샘플의 가정을 물려받으면서 작은 오류를 증폭할 수 있다. 모든 변형을 검증된 target 예제에 고정하면 이 연쇄를 제한할 수 있다.

이 접근법은 기업에 더 방어 가능한 감사 추적도 제공한다. 각 학습 예제는 초기 상태, 의도한 작업 순서, 검증기, 검증 결과와 연결될 수 있다. 이는 실행 가능한 맥락 없이 프롬프트만 담긴 폴더보다 더 유용하다.

그러나 결정론적 검사는 의미 있는 모든 품질 차원을 인코딩할 수 없다. 최종 데이터베이스 상태는 에이전트가 그 과정에서 민감한 정보를 노출했더라도 올바르게 보일 수 있다. 또 다른 실행 경로는 기대 상태를 복원하기 전에 불필요한 변경을 만들 수 있다.

실행 로그와 정책 인식 검사는 여전히 필요하다. ServiceNow 자체의 agent evaluation 도구는 데이터셋, 실행 기록, 여러 품질 차원을 강조한다. AutoSynthData는 이러한 철학을 학습 데이터 생산으로 확장한다.

이 메커니즘은 교사 모델에도 의존한다. 더 강력한 모델은 성공적인 행동을 시연할 수 있지만, 그 행동은 여전히 사용 가능한 도구와 인코딩된 정책을 반영한다. 위험한 지름길을 택하는 교사 모델은 그 행동을 지도 미세 조정에 전파할 수 있다.

이는 거버넌스 문제를 제기한다. 기업은 누가 유효한 행동을 정의하는지, 환경이 어떤 정책을 구현하는지, 검증기 변경을 어떻게 검토하는지 알아야 한다. 그렇지 않으면 자동화된 생성은 눈치채지 못한 명세 오류를 대규모로 확산할 수 있다.

AutoSynthData: Generating Training Data for Enterprise Agents는 실행 가능한 데이터를 위한 논거로서 가장 강력하다. 생성기가 주목받지만, 시스템의 신뢰성은 상당 부분 환경과 검증기에 달려 있다. 이들이 없다면 합성 작업은 입증된 학습 예제가 아니라 그럴듯한 이야기로 남는다.

보고된 개선 효과는 의미 있지만 여전히 제한적이다

ServiceNow는 분명한 벤치마크 개선을 보고했지만, 실험이 프로덕션 신뢰성이나 광범위한 전이를 입증하지는 않는다.

첫 번째 실험은 EnterpriseOps Gym의 Hybrid 도메인에서 Gemma-4-26B-A4B-it를 대상 모델로 사용했다. Qwen3.8-27B가 교사 모델 역할을 했다. AutoSynthData는 약 18시간 동안 2,000개의 합성 학습 예제를 생성했다.

ServiceNow는 성공적인 예제를 모방하도록 모델을 학습하는 지도 미세 조정으로 Gemma를 미세 조정했다. 보고된 최상의 체크포인트는 다섯 번째 에포크에서 나왔다. 에포크는 학습 데이터셋 전체를 한 번 완전히 통과하는 것을 의미한다.

회사에 따르면 평균 Pass@1은 7.2%포인트 향상됐다. ServiceNow는 이 변화를 35%의 상대적 개선으로 설명한다. 검증기 성공률도 63.01%에서 68.55%로 증가했다.

회사는 결과 체크포인트가 Gemma와 참조 모델 사이의 기존 Pass@1 격차 중 59%를 해소했다고 말한다. 이 결과는 표적화된 합성 예제가 하나 이상의 측정 지표에 영향을 미쳤음을 시사한다. 다만 모델이 테스트 환경 밖에서 어떻게 행동했는지는 보여주지 않는다.

두 번째 실험은 IT 서비스 관리에 초점을 맞췄다. 다시 Gemma-4-26B-A4B-it를 대상으로 사용했고, DeepSeek-V4.1-Flash가 교사 모델 역할을 했다. 파이프라인은 66시간에 걸쳐 1,994개의 수용된 샘플을 생성했다.

ITSM 평가에서 평균 Pass@1은 18.77%에서 27.18%로 올랐다. 이는 8.41%포인트 증가다. 동시에 벤치마크의 채점 방식에서는 학습된 모델이 첫 시도의 대부분에서 여전히 실패한다는 의미이기도 하다.

남아 있는 이 격차는 핵심 맥락이다. 실험은 표적화된 합성 미세 조정이 모델을 개선할 수 있다는 주장을 뒷받침한다. 그러나 그 결과 에이전트가 비즈니스 시스템에서 독립적으로 운영될 준비가 됐다는 주장을 뒷받침하지는 않는다.

ServiceNow는 Hybrid 생성기가 원래 평가 프롬프트, 엔터티, 실행 경로 또는 검증기 세부 정보를 전혀 받지 않았다고 말한다. 대신 평가 행동에서 추출한 역량 명세를 받았다. 이러한 분리는 명백한 형태의 테스트 세트 오염 하나를 줄인다.

그러나 커리큘럼은 여전히 EnterpriseOps Gym 내에서 관찰된 실패에서 비롯됐다. 따라서 학습과 평가는 환경, 도구 구조, 전반적인 작업 분포를 공유했다. 해당 환경 내 개선이 관련 없는 소프트웨어나 비공개 기업 구성으로의 전이를 입증하지는 않는다.

보고된 수치는 시스템을 설계한 팀에서 나온 것이기도 하다. 독립적인 재현은 결과를 더 강화할 것이다. 연구자들은 파이프라인을 재현하기 위해 충분한 코드, 생성 설정, 수용된 샘플, 평가 세부 정보가 필요하다.

Artificial Analysis는 현재 EnterpriseOps Gym을 기반으로 한 독립 리더보드를 운영한다. 이 평가 역시 상태를 갖는 다단계 작업과 최종 데이터베이스 상태를 강조한다. 이 외부 하니스는 학습된 체크포인트를 보다 독립적으로 테스트할 수 있는 한 가지 장을 제공한다.

환경 간 평가는 훨씬 더 많은 정보를 제공할 수 있다. 하나의 ITSM 구성에서 학습된 모델을 변경된 정책, 이름이 바뀐 도구, 수정된 스키마, 익숙하지 않은 레코드 분포에 대해 테스트할 수 있다. 이러한 변화 속의 성능은 모델이 역량을 학습했는지, 환경 패턴을 암기했는지를 보여줄 것이다.

안전성도 별도 측정이 필요하다. ServiceNow는 앞서 사용할 수 없는 리소스, 누락된 권한, 정책 위반과 관련된 실행 불가능한 벤치마크 작업 30개를 설명했다. 보고에 따르면 가장 강력한 테스트 모델조차 그중 약 절반만 실행 불가능한 작업으로 인식했다.

AutoSynthData는 그러한 실패를 표적으로 삼을 수 있지만, 현재 릴리스는 전용 안전 거부 결과를 제시하지 않는다. 모델이 거부해야 하는 상황에서도 더 기꺼이 행동하게 된다면 작업 완료율 개선은 새로운 위험을 만들 수 있다.

교사-대상 모델 관계도 면밀히 살펴볼 필요가 있다. Hybrid 실험은 비교적 가까운 모델 크기 조합을 사용한 반면, ITSM 실행은 훨씬 더 큰 교사 모델을 사용했다. ServiceNow에 따르면 처리량 최적화 이전에 ITSM 실행이 먼저 이뤄졌기 때문에 생성 기간도 크게 달랐다.

이러한 차이는 직접 비교를 어렵게 만든다. 두 도메인은 서로 다른 교사 모델, 처리 시간, 그리고 아마도 서로 다른 역량 분포를 포함했다. 증거는 두 환경에서의 반복 가능성을 보여줄 뿐, 시스템의 모든 구성 요소를 통제한 연구는 아니다.

절제 연구가 없다는 점도 해석을 제한한다. 공개 결과는 실패 표적화, 교사 시연, 검증기 필터링, 작업 증식, 배치 수준 균형 조정 중 어느 요소가 얼마나 개선에 기여했는지 분리하지 않는다. 각 구성 요소는 그럴듯해 보이지만, 개별 기여도는 여전히 불분명하다.

상업적 수치를 붙이지 않더라도 비용과 리소스 사용은 또 다른 미해결 문제다. 수천 개의 작업을 생성하려면 반복적인 모델 호출, 환경 실행, 솔버 시도, 비평, 복구, 검증이 필요하다. 수용된 데이터셋은 전체 시도 작업량이 아니라 결과물만 나타낸다.

기업은 이 작업량을 대안과 비교해야 한다. 사람이 작성한 예제는 더 느릴 수 있지만 검토하기는 더 쉬울 수 있다. 검색 및 오케스트레이션 변경은 모델 가중치를 업데이트하지 않고도 일부 실패를 해결할 수 있다.

워크플로는 모델에 추론 능력이 부족해서가 아니라 지식이 불완전해서 실패할 수도 있다. 더 나은 knowledge blending은 일부 공백을 더 직접적으로 해소할 수 있다. 학습이 실패한 모든 에이전트 실행에 대한 기본 대응이 되어서는 안 된다.

신중한 해석은 여전히 고무적이다. AutoSynthData는 관찰된 약점을 중심으로 선택한 작업에서 측정 가능한 개선을 만들어 냈다. 적응형 합성 커리큘럼이 더 안전한 프로덕션 에이전트로 일반화된다는 더 강한 주장은 아직 입증되지 않았다.

AutoSynthData가 벤치마크를 넘어 의미를 갖는지 결정할 세 가지 신호

다음 증거는 원래 환경 내부의 또 다른 높은 점수만이 아니라 재현성, 전이, 더 안전한 행동을 보여줘야 한다.

첫 번째 신호는 독립적으로 재현 가능한 릴리스다. ServiceNow는 EnterpriseOps Gym 자료를 공개했지만, 연구자들에게는 AutoSynthData 구현과 완전한 실험 레시피가 필요하다. 해당 패키지에는 역량 카드 구성, 생성 설정, 검증기 테스트, 거부 기준, 체크포인트 평가가 포함돼야 한다.

독립 팀은 동일한 진단 실패로부터 비교 가능한 데이터셋을 재생성할 수 있어야 한다. 여러 실행에서 유사한 개선이 나타난다면 유리한 샘플링에 대한 우려를 줄일 수 있다. 거부된 작업 통계를 공개하면 최종 데이터셋에 얼마나 많은 필터링이 필요했는지도 드러날 것이다.

이 신호의 가장 강력한 형태에는 절제 연구가 포함된다. 연구자들은 부정 검증, 배치 균형 조정, 증식 또는 실패 표적화를 한 번에 하나씩 제거할 수 있다. 그에 따른 성능 차이는 어떤 메커니즘이 개선을 만드는지 식별할 것이다.

독립 재현에 성공한다면 ServiceNow의 핵심 기술 주장을 강화할 것이다. 개선 효과가 실행마다 크게 달라진다면, 그 결과는 파이프라인이 여전히 생성기, 교사 모델 또는 선택 방식에 민감하다는 점을 시사할 것이다.

두 번째 신호는 환경 간 전이다. 학습된 모델은 기본 역량은 보존하면서 도구, 엔터티, 정책, 스키마가 바뀐 워크플로를 마주해야 한다. 이 테스트는 일반적 학습과 EnterpriseOps Gym 구조에 대한 친숙함을 구분할 것이다.

유용한 실험은 하나의 ITSM 환경에서 학습하고 추가 미세 조정 없이 다른 환경에서 평가하는 방식일 수 있다. 또 다른 실험은 단일 도메인 워크플로에서 고객, 직원, 자산 데이터를 요구하는 교차 도메인 작업으로 옮길 수 있다.

기업은 ServiceNow 중심 시스템을 넘어서는 어댑터도 주시해야 합니다. AutoSynthData의 컨트롤러-어댑터 아키텍처는 이식 가능성을 시사하지만, 소프트웨어 설계가 실제 호환성을 보장하지는 않습니다. 새로운 환경마다 실행 가능한 작업과 신뢰할 수 있는 검증이 필요합니다.

크로스 플랫폼에서 성공적인 결과가 나온다면 이 방법은 훨씬 더 넓은 에이전트 시장에서 의미를 가질 수 있습니다. 반대로 전이 성능이 약하다면, 그 역할은 엄격하게 정의된 환경을 위한 효율적인 맞춤화 파이프라인으로 좁혀질 것입니다.

세 번째 신호는 거부와 정책 준수 능력을 약화하지 않으면서 작업 완료 성능이 개선되는지 여부입니다. 엔터프라이즈 에이전트는 행동하지 말아야 할 때를 알아야 합니다. 권한이 없거나 지시가 상충하는 상황에서도 자신 있게 실행하도록 학습을 유도한다면, 더 높은 Pass@1 점수만으로는 충분하지 않습니다.

향후 평가에서는 실행 불가능한 작업의 탐지, 무단 상태 변경, 정책 위반, 불필요한 도구 호출을 보고해야 합니다. 또한 최종 데이터베이스 상태뿐 아니라 중간 작업도 점검해야 합니다. 최종 상태가 복원되었다고 해서 안전하지 않은 작업 순서가 없었다는 뜻은 아닙니다.

영향이 큰 워크플로에서는 사람의 검토가 여전히 중요합니다. 검토자는 직원 기록, 접근 제어, 고객 권한, 보안 사고, 되돌릴 수 없는 변경과 관련된 샘플을 살펴봐야 합니다. 자동 검증기는 이 과정을 지원할 수 있지만, 책임 있는 감독 없이 정책을 결정해서는 안 됩니다.

따라서 향후 1~3개월 안에는 실행 가능한 파이프라인 코드, 환경 간 테스트, 안전성에 특화된 결과라는 세 가지 구체적인 증거가 나와야 합니다. 각각은 현재 공개된 내용에 남아 있는 서로 다른 불확실성을 해소할 것입니다.

AutoSynthData: Generating Training Data for Enterprise Agents는 평가 실패를 표적화된 실습으로 전환하기 위한 신뢰할 만한 메커니즘을 제시합니다. 보고된 성과는 특히 실행 가능한 워크플로 환경을 갖춘 팀이 이 아이디어에 주목할 가치가 있음을 보여줍니다.

이제 더 큰 결정은 엔터프라이즈 AI 구축자들에게 달려 있습니다. 이들은 자신의 에이전트 실패 사례를 재현 가능한 상태, 유효한 궤적, 검증 가능한 결과로 표현할 수 있는지 물어야 합니다. 그렇지 않다면 더 많은 작업을 생성하는 일은 모호성만 확장할 뿐입니다.

이러한 기반이 갖춰져 있다면 적응형 커리큘럼은 평가를 훨씬 더 유용하게 만들 수 있습니다. 무엇이 실패했는지 보여주고, 집중적인 학습을 생성하며, 같은 약점이 계속 남아 있는지 측정할 수 있습니다. 다음 증명은 이 루프가 그것을 만들어낸 환경 밖에서도 유지된다는 점을 보여줘야 합니다.