AutoSynthData: 엔터프라이즈 에이전트 학습 데이터 생성

기업들은 자체 환경에서 잘 작동하는 에이전트를 필요로 합니다. 이들이 요청하는 작업은 기업이 사용하는 시스템, 따르는 규칙, 그리고 데이터 상태에 의해 형성됩니다. 모델이 광범위하게 능력이 있어도 특정 환경에서는 어려움을 겪을 수 있습니다. 즉, 처리하기 어려운 워크플로우, 오용하는 도구 조합, 또는 준수하지 못하는 제약 조건 같은 것입니다. 이것들이 기업이 개선해야 할 약점들입니다.

어려운 점은 이러한 약점을 학습 데이터로 전환하는 것입니다. 개별적인 실패는 무언가를 알려주지만, 모델을 훈련시키려면 동일한 능력을 다양한 상황에서 연습할 수 있는 많은 새로운 작업이 필요합니다. 또한 이 작업들은 환경 내에서 완료 가능해야 하고, 누군가 실제로 요청할 법한 작업을 닮았으며, 에이전트가 성공했는지 확인할 수 있는 신뢰할 수 있는 방법이 있어야 합니다.

ServiceNow CoreAI에서는 이러한 능력 격차를 학습 데이터로 전환하기 위해 AutoSynthData를 구축했습니다. 이는 타겟 모델의 실패와 더 강력한 교사(teacher)의 성공을 활용하여 모델이 다음에 무엇을 배워야 할지 결정하고, 그 능력을 연습하는 새로운 작업을 생성하고 검증합니다. 모델이 개선됨에 따라 커리큘럼은 여전히 어려운 부분으로 이동합니다. 우리는 공개된 데이터셋을 사용하여 EnterpriseOps Gym (Malay et al., 2026) 환경으로 이 파이프라인을 설명합니다. 먼저 에이전트가 작동하는 환경과 작업이 학습에 유용한 이유를 설명하며 시작합니다.

에이전트적 환경(agentic environment)은 에이전트가 작동하는 세계를 정의합니다: 관찰하고 수정할 수 있는 상태, 호출할 수 있는 도구 및 API, 그리고 그 행동으로 인해 생성되는 상태 전이입니다.

작업(task)은 이 환경 내에서 인스턴스화됩니다. 우리는 다음의 추상화를 사용합니다:

task = (시스템 명세, 사용자 프롬프트, 검증기)

시스템 명세는 에이전트가 작동하는 제약 조건을 정의하며, 여기에는 시스템 지침(system instructions), 환경 정책(environment policies), 그리고 적용 가능한 경우 시드된 데이터베이스 상태나 지식 문서 세트와 같은 작업별 초기화가 포함됩니다.

명세는 환경의 도구(tools), 상태(state), 그리고 지원되는 동작(actions)과 호환되어야 한다. 그 지침은 명확해야 하며, 단순히 난이도를 인위적으로 만들기 위해 도입된 임의의 제약 조건은 피해야 한다.

사용자 프롬프트는 사용자가 에이전트에게 달성하기를 원하는 목표와 사용자 수준의 모든 제약 조건을 지정한다. 생성된 작업(task)은 세 가지 속성을 만족해야 한다.

실현 가능성 (Feasibility). 현재 환경에서 사용자 프롬프트를 만족시키고 시스템 명세를 존중하는 궤적(trajectory)이 최소한 하나 존재해야 한다. 이는 사용 불가능한 도구, 접근 불가능한 지식, 불가능한 상태 전이(state transitions), 또는 정책에 의해 금지된 동작에 의존하는 작업을 배제한다.

현실성 (Realism). 사용자 프롬프트는 대상 환경에서 사용자가 그럴듯하게 요청할 만한 내용과 유사해야 한다. 실행 가능한 행동 공간은 일반적으로 현실적인 워크플로우의 공간보다 훨씬 크다.

난이도 (Difficulty). 학습을 위해, 작업은 현재 에이전트의 약점을 노출해야 한다. 이미 안정적으로 해결된 작업은 새로운 훈련 신호(training signal)를 거의 제공하지 못한다. 따라서 유용한 영역은 실현 가능하고 현실적이지만 아직 일관되게 해결되지 않은 작업이다.

검증기(verifier)는 결과적인 궤적이 작업을 성공적으로 완료했는지 여부를 결정한다. 검증기는 세 가지 속성을 만족해야 한다.

일관성 (Consistency). 사용자 프롬프트, 시스템 명세, 그리고 작업별 환경 상태에 동의해야 한다.

건전성 (Soundness). 작업을 만족시키지 못하거나 관련 제약 조건을 위반하는 궤적은 거부해야 한다.

완전성 (Completeness). 특정 참조 궤적(reference trajectory)을 인코딩하기보다는 유효한 해답을 수용해야 한다.

이러한 속성들은 훈련 중에 직접적으로 중요하다. 느슨한 검증기(lax verifier)는 잘못된 행동에 보상을 줄 수 있는 반면, 지나치게 제한적인 검증기는 유효한 해답에 페널티를 부과할 수 있다.

환경과 목표 모델이 주어지면, AutoSynthData는 시스템 사양(system specification), 사용자 프롬프트(user prompt), 검증기(verifier)로 구성된 학습 과제를 생성합니다. 이렇게 생성된 과제들은 환경에 기반하며 현재 모델에게 유용한 학습 신호(training signal)를 제공하도록 선택됩니다.

AutoSynthData는 먼저 진단 과제(diagnostic tasks)를 사용하여 환경 내에서 목표 모델을 평가하고, 이 과정에서 어려움을 겪는 과제의 패턴을 식별합니다. 더 강력한 교사(teacher)가 존재하면 어떤 과제가 해결 가능한지, 그리고 성공적인 행동이 무엇인지 특성화하는 데 도움이 됩니다. AutoSynthData는 이렇게 얻은 역량 격차(capability gaps)를 새로운 실행 가능 과제로 변환하고, 환경에서 각 과제를 확인하며, 수락된 샘플을 후속 학습(post-training)에 사용합니다. 업데이트된 모델을 평가하면 어떤 격차가 남아 있는지 밝혀내고 다음 라운드의 생성을 안내할 수 있습니다.

AutoSynthData는 목표 환경에서의 평가 실행(evaluation runs)을 사용하여 모델이 다음에 무엇을 배워야 하는지 식별합니다. 저희의 EnterpriseOps Gym 실험에서는 목표 모델과 더 강력한 교사 모두를 평가 과제에서 실행합니다. 우리는 이러한 실행들을 검토하여 다음 사항들을 식별합니다:

• 테스트되는 역량(capability);
• 관련된 도구 및 워크플로우 구조(tools and workflow structure);
• 목표 모델이 실패하는 지점과 교사가 성공하는 방식;
• 올바른 최종 상태가 충족해야 하는 속성(properties);
• 테스트되는 역량을 보존하면서 변화할 수 있는 차원(dimensions).

우리는 이러한 발견들을 정제된 역량 사양 카드(sanitized capability specification cards)로 추출합니다. 평가 과제가 모델이 무엇을 배워야 할지 안내하지만, 생성기(generator)는 원래의 프롬프트, 엔티티, 궤적 또는 검증기 세부 정보를 받지는 않습니다. 대신 카드를 받고 이를 사용하여 다른 프롬프트, 상태 및 해결 경로를 가진 새로운 과제를 만듭니다.

역량 격차를 식별하는 것은 무엇을 가르쳐야 하는지 알려주지만, 학습에는 그것을 연습시키는 다양하고 많은 과제가 필요합니다. AutoSynthData는 사양 카드를 사용하여 이러한 과제들을 생성합니다.

만약 목표 모델이 다음 워크플로우가 필요한 과제에서 어려움을 겪는다고 가정해 봅시다:

생성기(generator)는 이 워크플로우를 활용하는 새로운 태스크들을 생성하며, 엔티티(entities), 초기 환경 상태(initial environment state), 워크플로우 구성(workflow composition), 도구 조합(tool combinations), 문구(wording), 그리고 난이도를 변화시킵니다. 이후 더 강력한 교사 모델(teacher)은 각 태스크에 대한 성공적인 궤적(trajectory)을 시연합니다. 지도 미세 조정(Supervised Fine-Tuning, SFT)의 경우, 이러한 시연들은 대상 모델(target model)에게 새로운 상황에서 해당 역량을 적용하는 방법을 가르칩니다.

AutoSynthData는 두 단계에 걸쳐 데이터셋을 구축합니다: 첫째로 핵심 샘플을 생성하고 검증한 다음, 이를 새로운 변형으로 확장합니다.

대상 단계(target phase)에서는 역량 사양(capability specifications)으로부터 핵심 학습 샘플 세트를 만듭니다. 워커들(workers)은 독립적인 태스크들을 병렬로 생성하며, 하나를 완료하면 새로운 대상을 가져옵니다. 각 후보는 수락되기 전에 검증(validation), 실행(execution), 솔버 평가(solver evaluation), 그리고 복구(repair) 과정을 거칩니다. 그 결과는 대상 모델이 학습해야 할 것을 중심으로 구축된 일련의 검증된 예시 배치입니다.

곱셈 단계(multiply phase)에서는 수락된 대상 샘플들의 새로운 변형을 생성하여 데이터셋을 확장합니다. 각 변형은 자체적인 사용자 요청(user request), 환경 상태, 엔티티 구성, 참조 궤적(reference trajectory), 그리고 검증기(verifier)를 가지며, 동일한 검증 및 실행 검사를 통과해야 합니다. 곱셈된 샘플은 다른 곱셈된 샘플의 시드(seed)가 될 수 없습니다. 이는 확장을 검증된 대상 세트에 고정시키고 세대 간 드리프트(drift)를 제한합니다.

두 단계를 모두 지원하기 위해, AutoSynthData는 생성 제어(generation control)와 환경별 실행을 분리합니다. 공유 컨트롤러(shared controller)가 생성, 품질 관리(quality control), 커버리지(coverage), 그리고 데이터셋 구축을 조정하는 동안, 어댑터(adapter)는 환경 실행, 태스크 및 상태 관리, 참조 리플레이(reference replay), 결정론적 검증(deterministic verification), 솔버 실행, 그리고 태스크 프로파일링을 처리합니다.

이처럼 병렬 대상 생성과 곱셈은 학습 규모의 데이터셋으로 가는 길을 제공합니다. 이들의 유용성은 모든 후보에 적용되는 검사들, 즉 태스크가 실행 가능해야 하고, 해결책이 작동해야 하며, 검증기가 성공과 실패를 구별할 수 있어야 한다는 점에 달려 있습니다.

그럴듯한 요청을 생성하는 것만으로는 유용한 학습 데이터를 만들기에 충분하지 않습니다. 특정 작업이 목표 환경에서 불가능할 수도 있고, 그 참조 해답이 실행될 때 실패할 수도 있으며, 검증기가 잘못된 최종 상태에 보상을 줄 수도 있습니다. AutoSynthData는 이러한 속성들을 확인한 후에 작업을 학습에 수용합니다.

AutoSynthData는 두 가지 수준에서 품질을 검토합니다: 개별 후보군은 검증을 통과해야 하며, 배치(batches)는 유용한 커버리지와 다양성을 제공해야 합니다.

각 후보군은 훈련 데이터셋에 들어가기 전에 품질 관리 루프를 거쳐야 합니다. 우리는 난이도를 측정하기 위해 솔버 평가(solver evaluation)로 시작합니다. 여기서 사용된 설정에서는, 목표 모델이 세 번의 시도 중 최대 한 번만 해결하는 작업을 선호하며, 더 강력한 솔버가 세 번의 시도 중 최소 두 번은 해결해야 합니다. 후보군은 또한 긍정 및 부정 검증과 경계 제어 복구(bounded repair) 과정을 거칩니다.

'긍정 게이트(positive gate)'는 다음과 같이 질문합니다: 의도된 해답이 생성된 작업을 해결하는가?

파이프라인은 목표 환경에서 참조 궤적(reference trajectory)을 실행하고, 그 결과 상태를 후보군의 검증기와 비교하여 확인합니다. 이를 통해 프롬프트, 초기 상태, 해답, 성공 기준 간의 불일치를 밝혀냅니다.

'부정 게이트(negative gate)'는 다음과 같이 질문합니다: 관련 있는 잘못된 결과가 실패하는가?

예를 들어, 예상되는 결과의 일부 부분을 변형하여 해당 상태들이 더 이상 검증을 통과하지 못함을 확인합니다. 이는 의도된 동작을 요구하지 않으면서 성공에 보상을 주는 약한 검증기를 잡아냅니다.

실패한 후보군은 폐기되기 전에 크리틱(critic)에게 전달됩니다. 크리틱은 샘플과 그 실패를 검토하며, 일관성 없는 상태, 불가능한 워크플로우, 잘못된 작업 구성, 나쁜 참조 궤적, 약한 검증기 로직 또는 의도된 능력과의 불일치를 찾습니다. 크리틱의 발견 사항들은 복구를 안내하며, 재시도에는 고정된 제한이 있습니다:

candidate
↓
failure
...

복구된 작업은 관련 검사를 다시 통과해야 합니다. 이 진단(diagnosis)은 처음부터 생성을 시작할 필요 없이 기존 후보군에 복구를 안내합니다.

이러한 검사들을 통과하면 샘플은 학습에 적합해지지만, 개별적으로 유효한 샘플들만으로는 여전히 반복적이거나 불균형한 데이터셋을 형성할 수 있습니다. 따라서 AutoSynthData는 배치(batch) 수준에서도 생성을 검토합니다.

배치는 몇 가지 쉬운 태스크 패밀리(task family)를 과도하게 대표하거나, 특정 역량을 놓치거나, 낮은 효율의 패턴에 너무 많은 생성 노력을 투입할 수 있습니다.

메타 리뷰(meta-review)는 각 배치에 걸쳐 승인된 샘플, 거부된 샘플, 그리고 생성 행동을 검토합니다. 이는 다음과 같은 질문들을 던집니다:

• 어떤 태스크 패밀리가 과도하게 대표되었고, 어떤 역량 차원(capability dimension)이 누락되었는가?
• 동일한 종류의 예시들이 반복적으로 나타나고 있는가?
• 특정 목표물은 계속해서 생성에 실패하는가?
• 비평(critique)에서 체계적인 문제가 나타나고 있는가?
• 다음 배치를 위해 어떤 가이드라인이 변경되어야 하는가?

컨트롤러는 승인된 데이터셋의 커버리지(coverage)를 추적하고, 과도하게 대표되는 영역에서의 생성을 줄이며, 격차(gap) 쪽으로 더 많은 작업을 유도합니다. 특정 영역에서 반복적으로 낮은 후보군을 생성할 경우, 비평과 메타 리뷰가 생성 전략의 변경을 안내합니다. 이러한 조정들은 사용 가능한 생성 예산 및 데이터셋 크기 요구사항 내에서 유용한 학습 신호, 태스크 품질, 커버리지, 다양성, 그리고 낮은 중복성을 균형 있게 맞춥니다.

이러한 피드백 루프(feedback loop)들은 개별 태스크와 그들이 형성하는 데이터셋 모두를 개선합니다. 샘플 수준의 검사는 후보군 수리(candidate repair)를 안내하고, 배치 수준의 리뷰는 미래의 생성을 안내합니다.

유용한 학습 분포는 모델이 개선됨에 따라 변화합니다. AutoSynthData는 합성 데이터 생성을 타겟 모델의 역량 경계 근처에서 태스크를 탐색하는 것으로 간주합니다. 즉, 약점을 노출시키기에는 충분히 어렵지만, 교사(teacher)가 신뢰할 수 있는 시연을 제공하기에는 충분히 해결 가능한 난이도를 갖는 것입니다.

후속 학습(post-training) 후, 우리는 업데이트된 모델을 동일한 환경에서 평가합니다. 이제 모델이 안정적으로 해결하는 태스크들은 다음 훈련 라운드에 덜 유용하며, 지속적인 실패는 여전히 주의가 필요한 역량을 가리킵니다. 이러한 결과들은 다음 생성 라운드를 안내할 수 있습니다.

우리의 실험은 SFT에 초점을 맞추고 있지만, 동일한 메커니즘이 강화학습(RL)도 지원할 수 있습니다. 즉, 현재 정책에 도전하는 작업을 생성하고 신뢰할 수 있는 학습 신호를 제공하며, 훈련을 진행한 후 업데이트된 정책과 함께 생성 목표를 이동시키는 방식입니다. 우리는 SFT를 넘어 이러한 움직이는 난이도 보정 경계면(difficulty-calibrated frontier)을 테스트할 계획입니다.

우리는 EnterpriseOps Gym을 사용하여 이 접근 방식이 상태 기반의 엔터프라이즈 환경 내 작업에서 모델 성능을 향상시키는지 테스트합니다. 우리는 Gym의 Hybrid 및 ITSM 환경에서 훈련 작업을 생성하고, 수락된 샘플로 타겟 모델을 미세 조정(fine-tune)한 다음, 그 결과로 나온 체크포인트를 평가합니다.

우리는 EnterpriseOps Gym의 Hybrid 도메인에 대해 Gemma-4-26B-A4B-it를 타겟 모델로, Qwen3.8-27B를 교사(teacher) 모델로 사용하여 이 파이프라인을 테스트했습니다.