이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
Amazon Nova Forge의 다중 턴 Reinforcement Fine-Tuning에서는 모델의 전체 trajectory를 평가하는 custom reward function이 실제 학습 행동을 결정합니다. GRPO는 같은 프롬프트에서 나온 rollout 사이의 보상 차이로만 advantage를 만들기 때문에, correctness에 종속된 질문 보너스나 모든 후보에 같은 점수를 주는 항목은 학습 신호가 되지 않습니다. Amazon Nova Lite 2.0 코딩 과제에서는 질문 행동을 독립적으로 보상하고 즉시 추측을 감점해 전략 간 변동을 유지했으며, 생성 코드 실행에는 샌드박스와 무작위 sentinel을 적용했습니다. 보상 항목별 within-group 표준편차와 advantage 기여도를 추적하면 전체 곡선이 정상이어도 조용히 죽은 correctness scorer를 찾아낼 수 있습니다.
섹션별 상세
Amazon Nova Forge의 다중 턴 Reinforcement Fine-Tuning은 한 번의 응답이 아니라 도구 호출과 코드 실행을 포함한 전체 trajectory의 누적 보상을 최적화합니다. BYOO 환경에서는 Nova Forge가 rollout을 고객 관리 컨테이너에 위임하고, 컨테이너가 user simulator와 대화 상태를 유지하며 보상 함수를 실행합니다. 각 rollout은 aggregate_reward_score와 선택적인 metrics_list를 반환하고, 이 값들이 GRPO의 그룹 내 advantage 계산에 들어가므로 보상 설계가 모델의 실제 학습 방향을 결정합니다.
GRPO에서는 같은 프롬프트에서 생성한 K개 rollout 사이의 보상 차이만 학습 신호가 됩니다. 어떤 보상 항목이 그룹의 모든 후보에 같은 값을 주면 가중치가 높아도 advantage와 gradient에 기여하지 않습니다. 따라서 다중 턴 작업에서는 최종 결과가 맞았는지 평가하는 outcome reward, 질문이나 올바른 도구 사용을 유도하는 behavioral reward, 추측과 반복을 막는 penalty를 함께 구성해 전략 간 차이를 유지해야 합니다.
Amazon Nova Lite 2.0을 500개의 고유한 프로그래밍 과제에 학습시킨 사례에서는 모델이 불완전한 요청을 받고 먼저 질문한 뒤 코드를 제출하도록 보상을 구성했습니다. correctness에는 숨은 unit test 통과 비율에 1.0의 가중치를, asked_before_coding에는 첫 턴 질문 후 제출 시 1.0과 늦은 질문 후 제출 시 0.6을 부여했으며, guessed_immediately에는 -1.0의 페널티를 적용했습니다. 마지막 두 턴의 유사도가 80%를 넘으면 -0.5를 주는 loop_penalty도 추가해 질문만 반복하거나 첫 턴에 추측하는 전략을 분리했습니다.
생성 코드의 correctness를 평가할 때는 모델 출력이 검증되지 않은 실행 코드라는 전제에서 격리와 위조 방지를 함께 적용해야 합니다. 임시 디렉터리에서 실행하고 credentials와 network를 차단하며 CPU 시간은 30초, 주소 공간은 2GB, 프로세스 수는 64개로 제한하고 실행마다 무작위 nonce를 사용해 결과 marker 위조를 막습니다. 실제로 실행된 테스트 수를 예상 개수와 비교해야 모델이 통과하기 쉬운 테스트를 추가해 점수를 부풀리는 경로도 차단할 수 있습니다.
python
def asked_before_coding(completion, answer, **kw) -> float:
msgs = _messages(completion, kw)
first_q = _first_question_turn(msgs, parser)
final = _final_code(completion, parser)
committed = bool(final) and not _is_question(final)
if first_q == 1 and committed:
return 1.0 # asked first, then committed (ideal)
if first_q is not None and committed:
return 0.6 # asked later, then committed
return 0.0 # never asked, or asked but never committed첫 턴 또는 이후에 질문한 뒤 최종적으로 코드를 제출했는지 점수화합니다.
python
def guessed_immediately(completion, answer, **kw) -> float:
for m in _assistant_turns(completion, kw):
code = _code_of(parser.parse(m["content"]))
return -1.0 if (code and not _is_question(code)) else 0.0
return 0.0모델이 질문 없이 첫 응답에서 바로 코드를 제출하는 전략에 페널티를 부여합니다.
초기 보상 설계에서는 correctness가 통과했을 때만 질문 보너스를 주고 대화가 짧을수록 높은 점수를 주는 efficiency 항목을 넣은 결과, 모델이 첫 턴에 추측하는 전략으로 수렴했습니다. 어려운 과제에서 correctness가 거의 0이어서 질문 보너스가 작동하지 않았고, 짧은 대화를 선호하는 항목이 한 턴 전략을 강화해 그룹 내 변동을 없앴기 때문입니다. 질문 행동을 correctness와 독립적으로 보상하고 즉시 추측을 명시적으로 감점하자 서로 다른 전략의 보상 차이가 유지되어 GRPO가 학습할 분산을 확보했습니다.
python
def run_tests(code: str, test: str, timeout_s: int = 30) -> float:
nonce = secrets.token_hex(8) # unforgeable per-run marker
harness = ( "import sys, unittest, json
"
f"{code}
{test}
"
'if __name__ == "__main__":
'
" r = unittest.TextTestRunner(stream=sys.stderr, verbosity=0).run(
"
" unittest.TestLoader().loadTestsFromModule(sys.modules[__name__]))
"
f" sys.stderr.write('__{nonce}__' + json.dumps(" "{'total': r.testsRun, 'passed': r.testsRun - len(r.failures) - len(r.errors)}) + '__" f"{nonce}__')
" )
def _limit():
resource.setrlimit(resource.RLIMIT_CPU, (timeout_s, timeout_s))
resource.setrlimit(resource.RLIMIT_AS, (2 * 1024**3, 2 * 1024**3)) # 2 GB
resource.setrlimit(resource.RLIMIT_NPROC, (64, 64))생성 코드와 숨은 테스트를 임시 디렉터리에서 실행하고 CPU·메모리·프로세스 수를 제한합니다.
보상 붕괴는 aggregate reward와 loss, completion length가 정상처럼 보이는 동안 특정 항목이 모든 rollout에서 같은 값을 반환하는 형태로도 나타납니다. 사례에서는 correctness scorer가 entry-point 불일치나 import 실패로 모델 코드를 실행하지 못해 매번 0을 반환했고, 질문 비율은 약 34–96%까지 올랐지만 코드 정확도는 거의 변하지 않았습니다. 각 항목의 평균뿐 아니라 그룹 내 표준편차와 advantage 기여도를 metrics_list로 추적하고, 의심 항목 기준으로 transcript를 정렬하며, ablation으로 제거했을 때 결과가 변하는지 확인해야 죽은 보상 채널을 조기에 찾을 수 있습니다.
용어 해설
- 강화 미세 조정(Reinforcement Fine-Tuning)
- — 모델이 정답 예시를 그대로 모방하는 대신 자체 출력에 대한 보상 신호를 받아 가중치를 조정하는 학습 방식입니다. 여러 후보 출력을 평가하고 더 높은 보상을 얻은 행동의 확률을 높여 특정 작업 절차와 결과를 함께 학습시킵니다.
- 그룹 상대 정책 최적화(Group Relative Policy Optimization)
- — 같은 프롬프트에서 생성한 여러 rollout의 보상을 서로 비교해 모델을 업데이트하는 최적화 방식입니다. 그룹 안의 보상 차이가 advantage를 만들며, 모든 후보가 같은 점수를 받으면 해당 보상 항목은 gradient에 기여하지 못합니다.
- Bring Your Own Orchestration
- — 사용자가 관리하는 환경 컨테이너에서 다중 턴 상호작용과 보상 계산을 실행하는 구조입니다. Nova Forge가 rollout을 컨테이너에 위임하고, 컨테이너가 대화 상태와 도구 실행을 관리한 뒤 aggregate reward를 반환합니다.
- 보상 붕괴(Reward Collapse)
- — 보상 신호가 한 가지 전략이나 동일한 값으로 수렴해 그룹 내 차이가 사라지는 현상입니다. 평균 보상과 손실 곡선이 정상처럼 보여도 특정 항목의 분산이 0에 가까우면 그 항목은 학습을 전혀 유도하지 못합니다.
- LLM-as-Judge
- — 별도로 학습한 reward model 대신 다른 LLM이 모델 출력을 평가해 점수를 부여하는 방식입니다. Nova Forge의 보상 함수에서 규칙 기반 검증과 함께 사용할 수 있지만, 평가 기준과 변동성이 학습 신호의 품질을 좌우합니다.
기술
- Amazon Nova Forge
- Amazon Nova Lite 2.0
- Reinforcement Fine-Tuning
- GRPO
- Low-Rank Adaptation (LoRA)
- Amazon SageMaker HyperPod
- Amazon Elastic Container Service (Amazon ECS)
- Amazon Simple Storage Service (Amazon S3)
- AWS Lambda
- AWS Cloud Development Kit (AWS CDK)
- Python
활용 사례
- 다중 턴 협업 코딩
- 숨은 unit test를 활용한 코드 정확도 평가
- 도구 호출과 코드 실행을 포함한 agentic task 학습
- 질문 후 행동하는 코딩 에이전트 학습
- 규칙 기반 검증과 LLM-as-Judge를 활용한 custom reward
언급된 리소스
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 08. 15.수집 2026. 08. 15.출처 타입 RSS
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
